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

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

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

Что вызывает дублирующие ACK-записи?

Дополнительная информация, если она поможет:

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

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

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

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

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

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

Спасибо,

Сэм

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

Краткий обзор последовательности 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 не всегда обусловлена сетевыми проблемами в транзите; иногда это бывает результатом ограничений процессора или диска на сервере… и иногда из-за некоторой проблемы на клиентском ПК. Я гонялся за этой проблемой неделями, углубляясь в следы Wireshark, и только отказался и нашел проблему относительно быстро с помощью mtr, или проверяя другие метрики хоста, такие как использование процессора и диска.

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

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

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

Увидев много [TCP segment of reassembled 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) подтверждения диапазона” сервер должен указать последнюю подтвержденную часть (0) в заголовке TCP. Wireshark отмечает подтверждения диапазонов (SACK) как [TCP Dup ACK …], потому что все эти подтверждения диапазона имеют одинаковое значение последней подтвержденной части в заголовке TCP (Ack=872619 в вашем случае).

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

В моем случае коренной причиной была связь между двумя коммутаторами. Коммутатор с восходящим каналом 1Gbit/s подключен к коммутатору, который поддерживал только нисходящий канал 10Git/s, используя модуль RJ45 SFP+.

В таких ситуациях второй коммутатор будет иметь пакеты управления потоком, такие как RxPause или TxPause.

Такие неправильно настроенные сети на уровне оборудования могут привести ко всевозможным проблемам и проблемам с производительностью.

Пакеты замедляются приостановленными кадрами, как определено в IEEE 802.1Qbb. И это, вероятно, вызовет повторную передачу пакетов.

Короче говоря, убедитесь, что все соединения в вашей сети правильные на обеих сторонах, особенно если вы используете оборудование, поддерживающее не только 1Gbit/s, как, например, возможно, у вас есть оборудование на 2.5Gbit/s, 5Gbit/s и 10Gbit/s. В зависимости от оборудования коммутатор может поддерживать или не поддерживать более низкие скорости соединения. Особенно когда вы имеете дело с модулями SFP+ трансиверов.