☰

Каковы допустимые значения «ack»?

tag-icon • tag-icon tcp
Каковы допустимые значения «ack»?

у меня проблема с поставщиком, который утверждает, что причиной проблемы является недопустимое значение 'ack' в данных tcp. Я использую java, поэтому я не писал этот уровень. Я использовал snoop для захвата трафика в сети и использую wireshark для отображения данных. Вот что происходит. После получения сообщения multi-packet(5) я вижу ответ multi-pack(3). Первый пакет в ответе имеет значение 'ack', которое отличается от значения 'ack' в двух других пакетах. Поставщик утверждает, что эти данные подозрительны. Я предоставил пример данных ниже. Я не эксперт по tcp, поэтому не знаю, является ли это проблемой или нет. Я пытался найти что-нибудь о допустимых значениях ack, и мне кажется, что значение должно быть 80018, но это не значит, что 78345 неверно. Я нашел это в Интернете, и, похоже, это применимо, но я не уверен: "значение ack любого сегмента данных считается действительным, пока оно не подтверждает данные перед отправкой следующего сегмента". Спасибо за помощь. Насколько я понимаю, поставщик написал свой собственный уровень tcp.

    источник seq ack len время
    я 10734 75465 190 ггггммдд 09:18:21.785757
    продавец 75465 10924 0 ггггммдд 09:18:21.789319
    продавец 75465 10924 1440 ггггммдд 09:18:34.196661
    продавец 76905 10924 1440 ггггммдд 09:18:34.196762
    продавец 78345 10924 1440 ггггммдд 09:18:34.196901
    продавец 79785 10924 233 ггггммдд 09:18:34.196915
    я 10924 78345 0 ггггммдд 09:18:34.196968
    я 10924 80018 0 ггггммдд 09:18:34.197102
    я 10924 80018 197 ггггммдд 09:18:34.579479

решение1

http://en.wikipedia.org/wiki/Протокол_управления_передачейговорит

Номер подтверждения (32 бита) – если установлен флаг ACK, то значение этого поля – следующий порядковый номер, который ожидает получатель. Это подтверждает получение всех предыдущих байтов (если таковые имеются). Первый ACK, отправленный каждым концом, подтверждает сам начальный порядковый номер другого конца, но не данные.

Это говорит о том, что первый ответный пакет подтверждает получение первых трех пакетов отпродавец(seq 76905 + len 1440 = 78345)

Второй ответный пакет подтверждает получение 4-го и 5-го пакетов отпродавец(seq 79785 + len 233 = 80018)

Третий ответный пакет указывает, что никаких дополнительных данных отпродавец(тот же ack) и содержит полезную нагрузку в 197 байт.

Мне это кажется приемлемым.

Если ваши данные — это весь разговор, то первоначальное подтверждение будет неверным, поскольку оно должно подтверждать первый пакет отпродавецс подтверждением 75465 (seq 75465 + 1 = 75466).

Вот последовательность, которую я записал с помощью Wireshark. Сначала мы видим трехстороннее рукопожатие, затем передачу HTTP-запроса GET, за которым следует HTTP-ответ.

Источник Флаги Seq Ack Len  
клиент SYN 0 - 0  
сервер SYN,ACK 0 1 0  
клиент ACK 1 1 0  
клиент - 1 1 429 Получить ...
сервер ACK 1 430 0  
сервер - 1 430 1456 HTML ответ
сервер - 1457 430 1456  
клиент ACK 430 2913 0  
...

Номера последовательности и подтверждения являются относительными (к случайно выбранному начальному номеру каждого конца)

Использование одного соединения для последовательности запросов является распространенной оптимизацией. Она была добавлена ​​в HTTP в версии 1.1 и известна какпостоянные соединения. Установление и разрыв TCP-соединений имеет свою стоимость.

решение2

Вкратце, поле ACK используется для указания следующего порядкового номера, который получатель ожидает получить от отправителя. То есть порядковый номер последнего полученного сегмента + длина этого сегмента. (Есть и другие варианты использования, связанные с потерей/повторными передачами, но мы пока их не будем рассматривать).

TCP разработан таким образом, что несколько сегментов могут быть подтверждены в одном ответе. Это позволяет более эффективно использовать каналы с высокой задержкой. СмотретьRFC1122иRFC2581, в частности разделы об отложенных подтверждениях.

Что касается вашего конкретного вопроса: стек TCP всегда будет иметь некоторый уровень чередования; то есть, даже если последний пакет (seq 79785) был помещен в приемный буфер, он мог не быть обработан за отведенное время до того, как ACK должен был быть отправлен обратно на другой конец соединения. Заголовки, которые вы предоставили, как мне кажется, описывают совершенно нормальный TCP-диалог. Объяснение вашего поставщика кажется в лучшем случае сомнительным.

Связанный контент