Назад | Перейти на главную страницу

Уже подтвержденный порядковый номер данных постоянно возвращается как нулевой байт

Существует сервер обработки транзакций (TP-Server), к которому подключается мое приложение (клиент). Мы наблюдаем странную последовательность пакетов, когда TP-Server отправляет PUSH-пакет с нулевыми (0) байтами данных, но порядковый номер этого пакета неверен; порядковый номер - это номер последнего полученного байта.

Пожалуйста, посмотрите данные дампа TCP здесь
http://pastebin.com/5UBXWazy

172.250.10.10.13824 - это TP-сервер.

172.11.105.5.49524 - Клиент.

«TP-Server» не в моей власти, не знаю, на какой ОС он работает. «Клиент» - это мое платежное приложение, работающее в Debian Squeeze.

Вы можете видеть, что TP-Server отправляет нулевые байтовые данные в следующем пакете.

20:52:34.472819 IP (tos 0x0, ttl 59, id 51820, offset 0, flags [DF], proto TCP (6), length 53)
    172.250.10.10.13824 > 172.11.105.5.49524: Flags [P.], cksum 0xe36f (correct), seq 1457045850:1457045851, ack 3097912286, win 17680, options [nop,nop,TS val 646012206 ecr 73190886], length 1
    0x0000:  4500 0035 ca6c 4000 3b06 a941 acfa 0a0a  E..5.l@.;..A....
    0x0010:  ac0b 6905 3600 c174 56d8 c15a b8a6 63de  ..i.6..tV..Z..c.
    0x0020:  8018 4510 e36f 0000 0101 080a 2681 5d2e  ..E..o......&.].
    0x0030:  045c cde6 00                             .\...

Порядковый номер вышеуказанных данных нулевого байта отмечен как 1457045850. Но то же самое было получено намного раньше, как показано ниже.

20:50:22.506267 IP (tos 0x0, ttl 59, id 51817, offset 0, flags [DF], proto TCP (6), length 607)
    172.250.10.10.13824 > 172.11.105.5.49524: Flags [P.], cksum 0x6460 (correct), seq 1457045296:1457045851, ack 3097912253, win 17680, options [nop,nop,TS val 645999009 ecr 73187775], length 555

В случае неправильного порядкового номера Клиент отвечает флажком, указывающим на неправильный порядковый номер.

20:52:34.472864 IP (tos 0x0, ttl 64, id 1172, offset 0, flags [DF], proto TCP (6), length 64)
    172.11.105.5.49524 > 172.250.10.10.13824: Flags [.], cksum 0x4501 (correct), seq 3097912286, ack 1457045851, win 2003, options [nop,nop,TS val 73220891 ecr 646012206,nop,nop,sack 1 {1457045850:1457045851}], length 0

Те же данные нулевого байта повторно посылаются TP-Server еще 7 раз с тем же неправильным порядковым номером. И Клиент любезно отвечает мешком.

20:58:29.024492 IP (tos 0x0, ttl 59, id 51827, offset 0, flags [DF], proto TCP (6), length 53)
    172.250.10.10.13824 > 172.11.105.5.49524: Flags [P.], cksum 0x04bf (correct), seq 1457045850:1457045851, ack 3097912308, win 17680, options [nop,nop,TS val 646047661 ecr 73277952], length 1
    0x0000:  4500 0035 ca73 4000 3b06 a93a acfa 0a0a  E..5.s@.;..:....
    0x0010:  ac0b 6905 3600 c174 56d8 c15a b8a6 63f4  ..i.6..tV..Z..c.
    0x0020:  8018 4510 04bf 0000 0101 080a 2681 e7ad  ..E.........&...
    0x0030:  045e 2200 00                             .^"..

20:58:29.024553 IP (tos 0x0, ttl 64, id 1179, offset 0, flags [DF], proto TCP (6), length 64)
    172.11.105.5.49524 > 172.250.10.10.13824: Flags [.], cksum 0x602c (correct), seq 3097912308, ack 1457045851, win 2003, options [nop,nop,TS val 73309529 ecr 646047661,nop,nop,sack 1 {1457045850:1457045851}], length 0

Однако в 8-й раз происходит то же самое, Клиент перестает подтверждать. TP-Server продолжает отправлять нулевые байтовые данные еще 5 раз, ни один из которых Клиент не отвечает подтверждением. Такое поведение происходит на уровне сетевого стека, и мое бедное клиентское приложение не получает никаких ошибок сокета и только в момент времени «21:18:59» оно получило getsocketopt err: 110 (которое, как мне кажется, является ETIMED_OUT). Итак, мое клиентское приложение подождало еще немного и попыталось повторно подключиться в 21:21:38 (вы можете увидеть пакеты SYN). Однако после этого TP-Server не отвечал. После перезагрузки «Клиентского» ПК через несколько минут TP-Server принял новые соединения. Но те же пакеты с нулевым байтом снова начинают появляться. Иногда случалось так, что у клиента было несколько периодических пакетов данных, которые нужно было отправлять на TP-сервер с интервалом примерно в 10 секунд, и это поддерживало соединение, независимо от того, что нулевые байты все еще происходят, и клиент отвечает мешками.

Мои вопросы:

Какова причина отправки этих нулевых байтов данных с неправильным порядковым номером?
Должен ли я что-нибудь делать с сетевым стеком Debian для обработки этого сценария, чтобы поддерживать соединение?

tcpip tcpdump