Tcp dup ack wireshark что
Что вызывает дублирование записей ACK?
Мы рассматриваем перехваты Wireshark с нескольких клиентских компьютеров, которые показывают несколько дублированных записей ACK, которые затем запускают повторную передачу и пакеты вне последовательности.
Что вызывает дублирование записей ACK?
Больше информации, если это поможет:
Мы исследуем проблемы пропускной способности сети на одном конкретном клиентском сайте. С точки зрения пользовательского интерфейса проблема заключается в том, что данные передаются медленно, несмотря на недостаточно используемое соединение WAN 1 Гбит / с.
Почти все клиентские машины имеют ту же проблему, протестированную на более чем 20 машинах. Мы нашли две машины, у которых нет проблем. Мы находимся в процессе выявления того, что отличается в их конфигурации. Мы заметили, что на двух машинах, у которых нет проблемы, мы видели только одну дублированную запись ACK. На компьютерах, на которых возникла проблема, обычно есть три дублированных записи ACK. Одно заметное отличие состоит в том, что все машины, которые работают нормально, принадлежат членам группы сетевых операций, а все остальные машины предназначены для «обычных» сотрудников. Машины должны быть стандартными, но сетевые администраторы могли внести изменения в свои локальные системы, что является еще одним аспектом, который мы исследуем.
Это единственный клиентский сайт из сотен, который продемонстрировал эту проблему.
pathping показывает RTT 56 мс и постоянную потерю пакетов 0/100 даже на проблемных компьютерах.
Примечание: я предполагаю, что этот захват был сделан на клиентском компьютере.
Краткое описание последовательности TCP: TCP надежно доставляет потоки байтов между двумя приложениями. «Надежно» в этом случае означает, что, помимо прочего, TCP гарантирует, что никогда не доставит данные из строя в прослушивающее приложение.
В этом случае повторная передача проходит и определяется Wireshark как вышедшая из строя.
Если вы не видите никаких очевидных кандидатов, выполните одновременный захват пакетов в нескольких точках пути, чтобы попытаться определить, где происходит потеря.
Какой тип WAN-соединения используется здесь? Это выделенная линия? MPLS VPN ссылка? IPsec VPN через общедоступный интернет? Что-то другое?
TCP Retransmissions – что это и как их анализировать с помощью Wireshark?
Наиболее частая ошибка, которую видит любой ИТ-специалист, установивший Wireshark и захвативший трафик, это повторная передача TCP пакета (TCP Retransmission). Даже в самой быстрой и правильно настроенной сети происходят потери пакетов и как следствие неполучение подтверждений доставки пакетов от получателя отправителю или обратно.
Это нормально и алгоритмы протокола TCP позволяют отрулить данные ошибки. Поэтому важно понимать, что TCP Retransmission – это симптом, а не причина болезни. Причины могут быть в ошибках на интерфейсах, перегрузке процессоров на сервере или пользовательском ПК, проблемы в пропускной способности каналов связи или фрагментирование пакетов и работа с этим на пути следования пакетов. Внимание надо уделить тому, как много повторных передач и часто они возникают, а не их наличию в принципе.
Анализатор протоколов Wireshark в зависимости от поведения определяет несколько типов повторных передач:
Быстрая идентификация повторных передач (TCP Retransmissions) с помощью Wireshark
Первая возможность – это воспользоваться фильтром: tcp.analysis.retransmission:
На экране будут отображены все повторные передачи и указан их тип.
Вторая возможность – это графический анализ повторных передач, когда на графике мы можем выводить несколько графиков и сравнивать их во времени. Также можно сравнить два разных получателя трафика и сделать вывод, в каком сегменте сети происходят больше всего повторных передач вследствие перегрузки сети или оборудования.
Заходим в раздел Statistics – I/O Graph:
На экране откроется окно с графиком, на котором будет отображаться общее количество передач во времени с момента начала захвата трафика. Единица измерения PPS – количество пакетов в секунду.
Далее в окошке под графиком можно добавлять дополнительные графики в зависимости от введенного фильтра и менять стиль вывода информации – график, гисторгамма и т.д. Тут добавлен знакомый нам фильтр: tcp.analysis.retransmission
Далее мы можем провести сравнительный анализ проблем с повторными передачами в сети в целом и между разными пользователями, указав фильтр: ip.src == xxx.xxx.xxx.xxx && tcp.analysis.retransmission
На наш взгляд, анализ повторных передач лучше делать именно в графическом виде, когда мы можем сравнить разные части сети или, например, как здесь можно сделать предположение, что всплески трафика приводят к росту повторных передач, что приводит к возникновению ошибок. Графики интерактивны и кликая на разные участки можно быстро перемещаться во времени, существенно ускоряя поиск.
Напоследок ещё раз напомним – повторные передачи это нормально до тех пор, пока их количество не начинает зашкаливать!
Tcp dup ack wireshark что
By default, Wireshark’s TCP dissector tracks the state of each TCP session and provides additional information when problems or potential problems are detected. Analysis is done once for each TCP packet when a capture file is first opened. Packets are processed in the order in which they appear in the packet list. You can enable or disable this feature via the “Analyze TCP sequence numbers” TCP dissector preference.
For analysis of data or protocols layered on top of TCP (such as HTTP), see Section 7.8.3, “TCP Reassembly”.
Figure 7.7. “TCP Analysis” packet detail items
 |
TCP Analysis flags are added to the TCP protocol tree under “SEQ/ACK analysis”. Each flag is described below. Terms such as “next expected sequence number” and “next expected acknowledgement number” refer to the following”:
TCP ACKed unseen segment
Set when the expected next acknowledgement number is set for the reverse direction and it’s less than the current acknowledgement number.
TCP Dup ACK #
Set when all of the following are true:
TCP Fast Retransmission
Set when all of the following are true:
Supersedes “Out-Of-Order” and “Retransmission”.
TCP Keep-Alive
Set when the segment size is zero or one, the current sequence number is one byte less than the next expected sequence number, and any of SYN, FIN, or RST are set.
Supersedes “Fast Retransmission”, “Out-Of-Order”, “Spurious Retransmission”, and “Retransmission”.
TCP Keep-Alive ACK
Set when all of the following are true:
Supersedes “Dup ACK” and “ZeroWindowProbeAck”.
TCP Out-Of-Order
Set when all of the following are true:
TCP Port numbers reused
Set when the SYN flag is set (not SYN+ACK), we have an existing conversation using the same addresses and ports, and the sequence number is different than the existing conversation’s initial sequence number.
TCP Previous segment not captured
Set when the current sequence number is greater than the next expected sequence number.
TCP Spurious Retransmission
Checks for a retransmission based on analysis data in the reverse direction. Set when all of the following are true:
Supersedes “Fast Retransmission”, “Out-Of-Order”, and “Retransmission”.
TCP Retransmission
Set when all of the following are true:
TCP Window Full
Set when the segment size is non-zero, we know the window size in the reverse direction, and our segment size exceeds the window size in the reverse direction.
TCP Window Update
Set when the all of the following are true:
TCP ZeroWindow
Set when the receive window size is zero and none of SYN, FIN, or RST are set.
The window field in each TCP header advertises the amount of data a receiver can accept. If the receiver can’t accept any more data it will set the window value to zero, which tells the sender to pause its transmission. In some specific cases this is normal — for example, a printer might use a zero window to pause the transmission of a print job while it loads or reverses a sheet of paper. However, in most cases this indicates a performance or capacity problem on the receiving end. It might take a long time (sometimes several minutes) to resume a paused connection, even if the underlying condition that caused the zero window clears up quickly.
TCP ZeroWindowProbe
Set when the sequence number is equal to the next expected sequence number, the segment size is one, and last-seen window size in the reverse direction was zero.
If the single data byte from a Zero Window Probe is dropped by the receiver (not ACKed), then a subsequent segment should not be flagged as retransmission if all of the following conditions are true for that segment: * The segment size is larger than one. * The next expected sequence number is one less than the current sequence number.
This affects “Fast Retransmission”, “Out-Of-Order”, or “Retransmission”.
TCP ZeroWindowProbeAck
Set when the all of the following are true:
Supersedes “TCP Dup ACK”.
TCP Ambiguous Interpretations
Some captures are quite difficult to analyze automatically, particularly when the time frame may cover both Fast Retransmission and Out-Of-Order packets. A TCP preference allows to switch the precedence of these two interpretations at the protocol level.
Русские Блоги
Wireshark analysis art [описание чтения]
Wireshark analysis art [описание чтения]
1. Фактическая работа Wireshark
Анализ работы интерфейса
Один из трех приемов: просмотр статистики и атрибутивной информации
Одна из трех осей анализа производительности:
Определите, высокий или низкий расход, и не перегружен ли он
Второй из трех способов: просмотр и анализ экспертной информации.
Анализ производительности по трем осям:
Проверьте, есть ли такая информация, как примечания, предупреждения, ошибки, проверьте наличие связанных предупреждений и ошибок, оцените качество сети, нарушение повторной передачи и т. Д.
Три хитрости: просмотрите время ответа службы
Третий из трех приемов анализа производительности:
Проверьте время отклика службы для каждой операции, чтобы определить, не перегружена ли она.
Используйте относительные значения для seq вместо истинных значений
Правка-> Настройки-> Протоколы-> TCP, отметьте относительные порядковые номера.
Это относительное значение до включения.
Просмотр TCP StreamGraph
Проверьте ситуацию передачи данных, например, является ли передача ровной, есть ли TCP Zero Windows и т. Д.
Значение поля и подсказка
1，[Packer size limited during caputre]
2，[TCP ACKed unseen segment]
3，[TCP Previous segment not captured]
При передаче данных TCP, в дополнение к трехэтапному и четырехстороннему рукопожатию, сегмент данных, отправленный одним и тем же компьютером, должен быть непрерывным, то есть Seq следующего пакета равен Seq + Len предыдущего пакета. Это правильная ситуация; если Если будет обнаружено, что Seq последнего пакета больше, чем Seq + Len предыдущего пакета, это означает, что часть данных потеряна в середине. Если потерянные данные не найдены во всем сетевом пакете, Wireshark предложит [TCP Previous segment not captured] ，
В этой ситуации есть две возможности:
4，[TCP Out-of-Order]
При передаче данных TCP, в дополнение к трехэтапному и четырехэтапному рукопожатию, сегмент данных, отправленный одной и той же машиной, должен быть непрерывным, то есть Seq следующего пакета равняется Seq + Len предыдущего пакета, что должно быть правильным случаем; или Говорят, что Seq последнего пакета должен быть больше или равен Seq + Len предыдущего пакета. Если Wireshark обнаруживает, что Seq последнего пакета меньше, чем Seq + Len предыдущего пакета, то он считается неисправным, и он запрашивает [TCP Out-of-Order] 。
5，[TCP Dup ACK]
6，[TCP Fast Retransmission]
Когда отправитель получает 3 или более подряд [TCP Dup ACK] В то время я понял, что ранее отправленный пакет может быть потерян, поэтому он начнет быстро повторно передавать в соответствии с RFC. [TCP Dup ACK] Это получатель отвечает отправителю, поэтому отправитель может его воспринять и начать быструю повторную передачу, когда он получает более трех сообщений подряд.
Алгоритм быстрой повторной передачи предусматривает, что, пока отправитель получает 3 повторяющихся подтверждения подряд, он должен немедленно повторно передать сегмент сообщения, который другой стороной не получил, не дожидаясь истечения установленного времени счетчика повторной передачи.
7，[TCP Retransmission]
Если пакет действительно потерян, и никакие последующие пакеты не могут вызвать [Dup Ack] на получателе, тогда быстрая повторная передача не будет включена.В этом случае отправитель может только дождаться тайм-аута перед отправкой повторной передачи. Пакет будет отмечен wirehark и подсказкой [TCP Retransmission]
Тайм-аут TCP и повторная передача должны быть одними из самых сложных частей TCP. Тайм-аут повторной передачи является основой TCP для обеспечения надежной передачи. Когда TCP отправляет данные, данные и подтверждение могут быть потеряны, поэтому TCP решает эту проблему, устанавливая таймер при отправке. Если таймер переполняется и не получил подтверждения, он повторно передает данные. Ключевым моментом является стратегия тайм-аута и повторной передачи. Необходимо учитывать два аспекта:
В более поздних версиях ядра Linux, таких как 3.15, есть как минимум 9 таймеров: таймер повторной передачи тайм-аута, непрерывный таймер, таймер задержки ER, таймер PTO, таймер задержки ACK, таймер SYNACK, Таймер поддержания активности, таймер FIN_WAIT2, таймер TIME_WAIT.
8，[TCP zerowindow]
Как правило, размер окна следует постепенно уменьшать до заполнения буфера.
9，[TCP window Full]
[TCP window Full] и указанное выше [TCP zerowindow] легко перепутать. Первое означает, что отправитель этого пакета не имеет возможности отправлять какие-либо данные в данный момент; второй означает, что отправитель этого пакета больше не может получать данные; оба будут Приостановить передачу данных
10，[TCP segment of reassembled PDU]
Доступно только в меню Edit-> Preferences-> Protocols-> TCP Allow sub dissector to reassemble TCP streams После этого можно получить это приглашение. Это представление может виртуально собирать TCP-пакеты, принадлежащие одному PDU прикладного уровня.
11，[Continuation to #]
Закрывается только в меню Edit-> Preferences-> Protocols-> TCP Allow sub dissector to reassemble TCP streams После этого можно получить это приглашение.
12，[Time-to-live-exceeded(Fragment reasembly time execeeded)]
(Превышено время повторной сборки фрагмента) указывает на то, что отправитель этого пакета уже получил некоторые фрагменты раньше, но по некоторым причинам сборка задерживалась.
Например, если некоторые фрагменты потеряны во время передачи, получатель не может их собрать, а затем отправитель уведомляется этим методом ICMP.
Во-вторых, Wireshark анализирует протокол TCP.
Основы протокола захвата пакетов TCP
Поле управления TCP
На уровне TCP есть поле FLAGS со следующими идентификаторами: SYN, FIN, ACK, PSH, RST, URG.
Форма поля управления, отображаемого при захвате пакета, следующая:
[SYN]: установить соединение, запустить пакет [FIN]: закрыть соединение, завершить пакет [PSH]: передача данных DATA [ACK]: ответ ACK [RST]: RESET, сброс соединения
Два других часто используемых поля:
[Len]: длина пакета [Seq]: порядковый номер пакета.
ACK может использоваться одновременно с SYN, FIN и т. Д. Например, SYN и ACK могут быть 1 одновременно, это означает, что ответ после установления соединения, если это только один SYN, это означает, что установлено только соединение
Когда появляется пакет FIN или RST, мы думаем, что клиент отключен от сервера. Когда появляются пакеты SYN и SYN + ACK, мы думаем, что клиент установил соединение с сервером.
Направление захвата пакета (клиент или сервер)
TCP Ack
Например, ACK пакета 97 = 65701 и Seq + Len = 64273 + 1428 = 65701 пакета 96, тогда это означает, что ACK 97 является ответом на 96, то есть другие ACK до 96 не отображаются. Фактически, пакеты прошли ACK пакета 97, поэтому отправитель также знает, что все пакеты, отправленные до 96, были получены и подтверждены другой стороной.
MSL、TTL、RTT
RTT (время приема-передачи), что означает время, необходимое для передачи данных от клиента к серверу и обратно. TCP содержит алгоритм для динамической оценки RTT.
Разрешение MAC-адреса
Протокол = ARP Источник и место назначения имеют формат MAC-адреса, например 00: 60: 48: ff: 12: 31.
При анализе захвата пакетов, если сеть заблокирована, ACK не может быть получен и т. Д., Необходимо дополнительно проверить правильность MAC-адреса каждого пакета.Напротив, есть некоторые проблемы, вызванные несколькими MAC-адресами.
Протокол установления связи TCP и волновой протокол
Пакет трехстороннего подтверждения TCP и ответного суждения
Соглашение о трехстороннем рукопожатии
Захват пакетных данных, как определить, является ли пакет пакетом возврата предыдущего пакета? Согласно протоколу TCP, если значение Ack следующего пакета равно Seq + Len предыдущего пакета, это означает, что пакет возвращается.
Во время трехстороннего рукопожатия все MSS будут объявлены друг другу.
ПТС четыре раза махнул и трижды
Четырехволновой протокол TCP
Обычно таких волн будет четыре, но если есть задержка с подтверждением, тогда четыре волны станут тремя волнами, сохраняя вторую сумку из четырех волн.
Алгоритм контроля перегрузки TCP
Количество байтов в пути
Перегрузка сети
Окно отправки
Алгоритм TCP Nagle и отложенный ACK
Это необходимо для уменьшения количества небольших пакетов в глобальной сети, тем самым уменьшая вероятность перегрузки сети;
Преимущество этого алгоритма в том, что он адаптивен. Чем быстрее приходит подтверждение, тем быстрее будут отправлены данные. В низкоскоростной глобальной сети, которая хочет уменьшить количество небольших пакетов, будет отправлено меньше пакетов;
Если tcp отправляет подтверждение подтверждения для каждого пакета данных, то отправка подтверждения для одного пакета данных обходится дороже, поэтому TCP будет задерживаться на определенный период времени. Если в течение этого периода на противоположный конец будут отправлены данные, они будут отправлены с совмещением. ack, если будет обнаружено, что подтверждение не было отправлено при срабатывании таймера отложенного подтверждения, оно будет отправлено отдельно немедленно;
Преимущества отложенного ACK:
(1) Избегайте синдрома запутанного окна; (2) При отправке данных отправляйте подтверждение с совмещением вместо отправки подтверждения отдельно; (3) Если Если в течение времени задержки поступает несколько сегментов данных, стеку протоколов разрешается отправить подтверждение для подтверждения нескольких сегментов сообщения;
Используйте параметр сокета TCP TCP_NODELAY, чтобы отключить параметр сокета;
Рассмотрите возможность отключения алгоритма Нэгла в следующих случаях:
(1) Противоположный конец не отправляет данные на локальный конец, и операция более чувствительна к задержке; этот вид операции не может переносить подтверждение; (2) Операция записи-записи-чтения, как указано выше; В этом случае вместо отключения алгоритма Нэгла предпочтительнее использовать другие методы:
Разница и сравнение TCP и UDP
Главное отличие
Разница между TCP и UDP в том, что TCP надежен, а UDP ненадежен, но какова реальная производительность? Что ненадежно? В чем разница между ACK конкретного протокола?
Независимо от того, TCP это или UDP, он может быть фрагментированным, что определяется MSS Ethernet; разница заключается в обработке фрагментированной передачи:
UDP больше подходит для голоса, чем TCP
Сценарий голосового вызова заключается в том, что задержка не может быть принята, но качество звука немного хуже. В этом случае во время передачи UDP, если некоторые пакеты потеряны, прикладной уровень может игнорировать и продолжать передавать другие пакеты. Потеря некоторых пакетов повлияет только на качество звука, но обеспечит плавность. Что касается TCP, каждый пакет будет передан повторно, и пока пакет будет потерян, он будет повторно передаваться. Это вызовет определенную задержку. Если есть задержка в голосе, это нежелательно.
Следовательно, TCP и UDP имеют свои подходящие сценарии. Для голоса и видео больше подходит UDP.Как голосовая сеть и linphone, UDP используется для обработки аудио и видео. TCP должен использоваться при взаимодействии базового и основного протоколов.
Эффективность TCP и UDP
Пример: по дороге взад и вперед едет только одна машина. Процесс возврата эквивалентен пустому пробегу (обратный путь эквивалентен ACK TCP), поэтому эффективность TCP, конечно, низкая. Однако, если вы попытаетесь увеличить количество транспортных средств при отсутствии заторов, транспортные средства на дороге будут просто заполнены, поэтому общая эффективность передачи улучшится, а ACK обратного рейса не будет затронут.
Фрагментация пакетов, MTU, MSS
Фрагментация и повторная сборка пакетов
Но следует отметить, что в некоторых сетях в настоящее время есть такие устройства, как Jumbo Frame (jumbo frame) или PPPOE, поэтому их MTU не составляет 1500 байтов. В настоящее время у отправителя нет хорошего механизма для определения оптимального размера фрагмента, и он должен стараться поддерживать согласованность MTU устройств в сети. Если MTU устройств в сети несовместимо, как протокол TCP адаптируется к MTU? Мы знаем, что когда TCP устанавливает соединение, сначала должно быть выполнено трехстороннее рукопожатие. TCP взаимно объявит свой собственный MSS в первых двух пакетах подтверждения. Если клиентская сторона объявляет свой собственный MSS = 8960 (jumbo-фрейм), а серверная сторона объявляет свой собственный MSS = 1460, то клиент знает MSS сервера после трехстороннего рукопожатия, поэтому, когда клиент хочет отправить пакет, превышающий MSS сервера Будет предпринята инициатива по уменьшению собственного MSS до размера MSS на стороне сервера, чтобы адаптироваться к MTU получателя. Видно, что уровень протокола TCP проделал большую оптимизацию и обработку.
Настоящая битва MTU
Если MTU клиента = 9000, а MTU сервера = 1500, тогда, когда клиент запрашивает сервер, пакет клиента будет либо потерян, либо фрагментирован при прохождении через маршрутизатор. Если этот пакет jumbo-кадра несет на сетевом уровне флаг DF (Don’t Fragment), он будет отброшен (его установка означает, что фрагментация не разрешена), если он не установлен, будет выполнена передача фрагмента. Следует отметить, что в этом случае, если пакет потерян, а повторная передача все еще отбрасывается, он становится черной дырой.
В тесте вы можете смоделировать эту ситуацию с помощью команды ping:
Особый контроль потока и пропускная способность
Существует своего рода «кадр паузы», который может удовлетворить это требование: когда буфер коммутатора собирается заполниться, на сервер отправляется кадр паузы, и сервер некоторое время ждет, чтобы отправить его снова, чтобы избежать переполнения и потери пакетов. Повторная передача после потери пакета. Время ожидания на стороне сервера определяется параметром pause_time в кадре паузы, так что серверная сторона начнет отправку после ожидания pause_time. Конечно, коммутатор также может отправить на сервер кадр паузы с pause_time = 0, чтобы сообщить серверу, что я его обработал и могу отправить немедленно.
Обратите внимание, что управление потоком здесь отличается от управления потоком TCP.
В-третьих, используйте методологию анализа Wireshark.
Чтобы устранить проблему с помощью wirehark, вам необходимо проанализировать сетевой пакет, найти некоторые подсказки в сетевом пакете, а затем сделать вывод на основе сетевого протокола, затем отменить один за другим и, наконец, найти проблему.
Необходимо уметь понимать основной протокол TCP и смысл каждого поля.
Используйте некоторые инструменты статистики и анализа Wireshark, фильтры и т. Д.
Существует большая разница между отправкой и получением захвата пакетов
Используйте «три оси» рабочего процесса и шагов для анализа проблемы.