Мы рассматриваем перехваты 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 через общедоступный интернет? Что-то другое?
источник
mtr(илиpathpingв Windows) на каждой из затронутых машин и посмотреть, есть ли какие-либо общие скачки на пути к серверу, которые, похоже, испытывают потерю пакетов. Есть ли у вас система мониторинга сети, которую вы можете использовать для просмотра данных порта коммутатора?Пока вы изолируете, в чем проблема, думайте о дампе пакетов как об одном из симптомов ... Как аналогия, если кто-то входит в кабинет врача с болями в груди, доктор не потратит три часа на изучение характера боль. Он тратит на это около двух минут, а затем знает, что 95% причин - это изжога или стенокардия ... Точно так же, если вы видите дубликаты ACK, не сразу делайте ямки на сорняках следа. ,
После установления соединения низкая производительность TCP не всегда из-за проблем транзитной сети; иногда это происходит из-за ограничений процессора или диска сервера ... а иногда из-за проблем на клиентском ПК. Я неделями гнался за своим хвостом, копаясь в сорняках следов проволочной акулы, только чтобы сдаться и относительно быстро найти проблему с помощью mtr или путем просмотра других показателей хоста, таких как процессор и дисковый ввод-вывод.
Ваша первая задача - доказать, является ли это проблемой сети или проблемой уровня хоста. Фокус на отправку реального трафика через сеть и доказать ли вы очереди / проигрышные / повторный заказ Примечание 1 это; это всегда является конечной целью для потенциальной сетевой проблемы, подобной этой .
Я бы делал
pingвыборку в течение длительного промежутка времени (обычно для меня часа) между клиентом и сервером, пока возникает проблема пропускной способности; для этого вы можете использовать mtr или ping plotter freeware . Если вы последовательно теряете пакеты при некотором скачке, и все скачки впоследствии теряют столько же или больше , то у вас есть потенциальный подозреваемый в сети. Имейте в виду, что ограничение скорости ICMP устройства может привести к появлению некоторых скачков, из-за которых они теряют пакеты ... вот почему вы хотите искать тенденцию, начиная с этого скачка и последующих.Примечание 1 Если вы переупорядочиваете трафик, он будет довольно быстро отображаться в информационном поле эксперта, которое предоставляет wireshark
источник
wiresharkдо такой степени, что нам нравится смотреть в микроскоп слишком долго. Я хотел бы кратко взглянуть на тоpcap, после чего вам лучше тратить циклы на инструментарий потери пакетов, циклы ЦП и дисковый ввод-вывод, чем углубляться в историю TCP. Есть время для этого, но обычно это не на данном этапе анализа.mtrили все равно, и последние 15 лет я так же решал проблемы. Как только я сфокусировался на конкретном устройстве, мы можем взглянуть на счетчики паденийВидя множество [сегмента 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 в сочетании с низкой производительностью сети для меня звучит как проблема перегрузки сети. Посмотрите на объем и скорость широковещательного трафика в сети. Обязательно посмотрите трансляции физического уровня и сетевого уровня, а также многоадресные рассылки.
источник