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

Мы рассматриваем перехваты Wireshark с нескольких клиентских компьютеров, которые показывают несколько дублированных записей ACK, которые затем запускают повторную передачу и пакеты вне последовательности.

Они показаны на следующем снимке экрана. .26 - это клиент, а .252 - это сервер.

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

Больше информации, если это поможет:

Мы исследуем проблемы пропускной способности сети на одном конкретном клиентском сайте. С точки зрения пользовательского интерфейса проблема заключается в том, что данные передаются медленно, несмотря на недостаточно используемое соединение WAN 1 Гбит / с.

Почти все клиентские машины имеют ту же проблему, протестированную на более чем 20 машинах. Мы нашли две машины, у которых нет проблем. Мы находимся в процессе выявления того, что отличается в их конфигурации. Мы заметили, что на двух машинах, у которых нет проблемы, мы видели только одну дублированную запись ACK. На компьютерах, на которых возникла проблема, обычно есть три дублированных записи ACK. Одно заметное отличие состоит в том, что все машины, которые работают нормально, принадлежат членам группы сетевых операций, а все остальные машины предназначены для «обычных» сотрудников. Машины должны быть стандартными, но сетевые администраторы могли внести изменения в свои локальные системы, что является еще одним аспектом, который мы исследуем.

Мы попытались изменить настройку TcpMaxDupAcks на сервере, но нам действительно нужно значение 5, а допустимый диапазон - только 1-3.

Сервер - Windows Server 2003. Все клиенты - Windows XP, управляемая предприятием. На всех клиентах, включая двух работающих, установлен антивирус Symantec.

Это единственный клиентский сайт из сотен, который продемонстрировал эту проблему.

pathping показывает RTT 56 мс и постоянную потерю пакетов 0/100 даже на проблемных компьютерах.

Благодарность,

Сэм

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример:

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

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

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

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