Что вызывает дублирование записей ACK?

Примечание: я предполагаю, что этот захват был сделан на клиентской машине.

Краткое описание последовательности TCP: TCP надежно доставляет потоки байтов между двумя приложениями. «Надежно» в этом случае означает, что, помимо прочего, TCP гарантирует, что никогда не будет доставлять данные с нарушением порядка в прослушивающее приложение.

На заказ надежная доставка осуществляется за счет использования порядковых номеров. Каждому пакету в каждом потоке назначается 32-битный порядковый номер (помните, что TCP фактически представляет собой два независимых потока данных, A-> B и B-> A). Если A отправляет ACK в B, значение в поле ACK является следующим порядковым номером, который A ожидает увидеть от B.

Из вышесказанного следует, что по крайней мере один сегмент TCP, отправляемый с сервера на клиент, был потерян. Три последовательных повторяющихся ACK - это попытка клиента инициировать быстрая ретрансляция. Когда отправитель TCP получает 3 повторяющихся подтверждения для одного и того же фрагмента данных (то есть 4 ACK для одного и того же сегмента, который не является последним отправленным фрагментом данных), он может разумно предположить, что сегмент сразу после того, как сегмент, который был подтвержден, был потерян. в сети, что приводит к немедленной повторной передаче.

В этом случае повторная передача проходит и определяется Wireshark как неисправная.

Как упоминалось Joeqwerty, потеря пакетов чаще всего вызвана перегрузкой. Это также может быть результатом CRC или других ошибок в ссылке из-за плохой интерфейсной карты, ослабленного кабеля и т. Д. Я бы посмотрел статистику каждой ссылки на пути, чтобы увидеть, используются ли какие-либо и / или испытывают большое количество ошибок.

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

Какого рода WAN-соединение здесь используется? Это выделенная линия? Ссылка MPLS VPN? IPsec VPN через общедоступный Интернет? Что-то другое?

Пока вы изолируете причину проблемы, думайте о выгрузке пакетов как об одном из симптомов ... В качестве аналогии, если кто-то войдет в кабинет врача с болью в груди, доктор не потратит три часа, исследуя природу боль. Он тратит на это около двух минут, а затем знает, что 95% причин - либо изжога, либо стенокардия ... Точно так же, если вы видите повторяющиеся ACK, не пытайтесь сразу же пробить сорняки следа. .

После установления соединения низкая производительность TCP не всегда связана с проблемами транзитной сети; иногда это происходит из-за ограничений ЦП сервера или диска ... а иногда из-за некоторых проблем на клиентском ПК. Я преследовал свой хвост в течение нескольких недель, копаясь в зарослях следов wirehark, только чтобы сдаться и относительно быстро найти проблему с mtrили путем просмотра других показателей хоста, таких как ЦП и дисковый ввод-вывод.

Ваша первая задача - доказать, является ли это проблемой сети или проблемой на уровне хоста. Сосредоточьтесь на отправке реального трафика через вашу сеть и убедитесь, что вы в очереди / теряете / переупорядочиваете ^{Примечание 1} Это; это всегда является основной причиной такой потенциальной сетевой проблемы.

Я бы сделал ping отбор проб в течение длительного периода времени (для меня обычно час) между клиентом и сервером, пока возникает проблема с пропускной способностью; ты можешь использовать mtr или свободное ПО для ping плоттера для этого. Если вы постоянно теряете пакеты на каком-то прыжке, и весь хмель потом теряет столько же или больше, значит, у вас есть потенциальный подозреваемый в сети. Имейте в виду, что ограничение скорости ICMP устройства может привести к появлению некоторых прыжков, из-за которых они теряют пакеты ... вот почему вы хотите искать тенденцию, начиная с этого прыжка и следующих за ним.

^{Примечание 1} Если вы переупорядочиваете трафик, это довольно быстро отобразится в информация эксперта поле, которое предоставляет wirehark

Увидев много [Сегмент TCP повторно собранного PDU] без ACK - я бы сказал, что эти ACK, вероятно, отображаются как [TCP Dup ACK ...] из-за Выборочное подтверждение (также известное как SACK).

Пример:

• клиент отправляет части данных (..., 0,1,2,3,4,5,6, ...)

• сервер подтвержден (0), затем получил (2,4,3), затем (5), затем (6) и не получил (1)

В приведенном выше сценарии сервер может законно выбрать сначала (2-4) диапазон, затем (2-5) диапазон, затем (2-6) диапазон. При формировании пакета "(A-B) range ack" сервер должен указать последнюю подтвержденную часть (0) в заголовке TCP. Wireshark помечает запросы диапазона (SACK) как [TCP Dup ACK ...] потому что все эти подтверждения диапазона имеют одинаковое значение последней подтвержденной части в заголовке TCP (Ack = 872619 в вашем случае).

Дублирование ACK в сочетании с низкой производительностью сети для меня звучит как проблема с перегрузкой сети. Посмотрите объем и скорость широковещательного трафика в сети. Обязательно изучите широковещательные и многоадресные рассылки на физическом и сетевом уровнях.