возникла проблема с поставщиком, который утверждает, что причиной проблемы является недопустимое значение «ack» в данных tcp. Я использую java, поэтому я не писал этот слой. Я использовал snoop для захвата трафика на проводе и использую wirehark для отображения данных. Вот что происходит. После получения сообщения с несколькими пакетами (5) я вижу ответ с несколькими пакетами (3). Первый пакет в ответе имеет значение «ack», которое отличается от значения «ack» в двух других пакетах. Производитель утверждает, что эти данные сомнительны. Ниже я привел примеры данных. Я не эксперт по tcp, поэтому не знаю, проблема в этом или нет. Я попытался найти что-то по действительным значениям ack, и мне кажется, что значение должно быть 80018, но это не значит, что 78345 неправильный. Я нашел это в сети, и кажется, что это применимо, но я не уверен: «значение подтверждения любого сегмента данных считается действительным, если оно не подтверждает данные перед отправкой следующего сегмента». Спасибо за вашу помощь. Насколько я понимаю, поставщик написал свой собственный слой tcp.
source seq ack len time
me 10734 75465 190 yyyymmdd 09:18:21.785757
vendor 75465 10924 0 yyyymmdd 09:18:21.789319
vendor 75465 10924 1440 yyyymmdd 09:18:34.196661
vendor 76905 10924 1440 yyyymmdd 09:18:34.196762
vendor 78345 10924 1440 yyyymmdd 09:18:34.196901
vendor 79785 10924 233 yyyymmdd 09:18:34.196915
me 10924 78345 0 yyyymmdd 09:18:34.196968
me 10924 80018 0 yyyymmdd 09:18:34.197102
me 10924 80018 197 yyyymmdd 09:18:34.579479
http://en.wikipedia.org/wiki/Transmission_Control_Protocol говорит
Номер подтверждения (32 бита) - если установлен флаг ACK, то значение этого поля является следующим порядковым номером, который ожидает получатель. Это подтверждает получение всех предыдущих байтов (если есть). Первый ACK, отправленный каждой стороной, подтверждает сам начальный порядковый номер другой стороны, но не данные.
Это говорит о том, что первый ответный пакет подтверждает получение первых трех пакетов от продавец (seq 76905 + len 1440 = 78345)
Второй ответный пакет подтверждает получение 4-го и 5-го пакетов от продавец (seq 79785 + len 233 = 80018)
Третий ответный пакет указывает, что дальнейшие данные не были получены от продавец (тот же ack) и содержит полезную нагрузку 197 байтов.
Мне это кажется нормальным.
Если ваши данные - это весь диалог, первоначальное подтверждение будет неправильным, поскольку оно должно подтверждать первый пакет из продавец с подтверждением 75465 (seq 75465 + 1 = 75466).
Вот последовательность, которую я записал с помощью wirehark: сначала мы видим трехстороннее рукопожатие, затем передачу HTTP-запроса на получение, за которым следует HTTP-ответ.
Source Flags Seq Ack Len client SYN 0 - 0 server SYN,ACK 0 1 0 client ACK 1 1 0 client - 1 1 429 Get ... server ACK 1 430 0 server - 1 430 1456 HTML response server - 1457 430 1456 client ACK 430 2913 0 ...
Порядковые номера и номера подтверждений являются относительными (относительно случайно выбранного начального номера каждого конца).
Использование одного соединения для последовательности запросов - обычная оптимизация. Он был добавлен в HTTP в версии 1.1 и известен как постоянные соединения. За установку и разрыв TCP-соединений приходится платить.
Вкратце, поле ACK используется для указания следующего порядкового номера, который получатель ожидает получить от отправителя. То есть порядковый номер последнего полученного сегмента + длина этого сегмента. (Есть и другие варианты использования, связанные с потерей / повторной передачей, но мы пока их опустим).
TCP спроектирован таким образом, что в одном ответе может быть подтверждено несколько сегментов. Это позволяет более эффективно использовать ссылки с высокой задержкой. Видеть RFC1122 и RFC2581, в частности, разделы об отложенных подтверждениях.
Что касается вашего конкретного вопроса: стек TCP всегда будет иметь некоторый уровень чередования; то есть, даже если последний пакет (seq 79785) был помещен в приемный буфер, он не мог быть обработан в течение разрешенного времени до того, как ACK нужно было отправить обратно на другой конец соединения. Заголовки, которые вы предоставили, кажутся мне совершенно обычным TCP-диалогом. Объяснение вашего поставщика в лучшем случае кажется сомнительным.