Tcp dup ack wireshark что это
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
Замечания по исследованию Wireshark и анализ результатов захвата пакетов
1．[Packet size limited during capture]
Когда вы видите это приглашение, это означает, что помеченный пакет не захвачен. В качестве примера возьмем пакет № 4 на рисунке 1. Он имеет общую длину 171 байт, но были захвачены только первые 96 байт, поэтому Wireshark дал это приглашение.
Эта ситуация обычно вызвана перехватом пакетов. В некоторых операционных системах по умолчанию tcpdump захватывает только первые 96 байтов каждого кадра. Мы можем использовать параметр «-s», чтобы указать количество байтов, которые мы хотим захватить.
2.［TCP Previous segment not captured］
Кстати, проанализируйте сетевой пакет на рисунке 2, который был перехвачен клиентом при ненормальной передаче HTTPS. Поскольку небольшой пакет «Len: 667» (то есть пакет 6) может быть доставлен, но большой пакет «Len: 1448» потерян, что указывает на то, что на пути может быть сетевое устройство с меньшим MTU, и он отбросит большой пакет. Более поздние решения подтвердили это предположение, пока MTU всего сетевого пути оставался неизменным, проблема исчезла.
3．[TCP ACKed unseen segment]
Указывает, что пакет TCP ACK был перехвачен, но фактические данные, полученные и подтвержденные, не были перехвачены. Это, вероятно, самый распространенный совет Wireshark, но, к счастью, он почти всегда незначителен. Взяв рисунок 3 в качестве примера, Seq Len = 6889 1448 = 8337 для пакета 32, указывая, что следующий пакет, отправленный сервером, должен быть Seq = 8337. То, что мы видим, является Seq = 11233 пакета 35, что означает, что данные с 8337 по 11232 не были захвачены. Этот фрагмент данных должен был появиться до 34-го числа, поэтому Wireshark запросил [TCP ACKed unseen segment].
Нетрудно представить, что вы часто будете видеть это приглашение в начале сетевого пакета, потому что перехватывается только обратный Ack, а передний пакет не перехватывается.
Во время передачи TCP (исключая трехстороннее рукопожатие и четырехстороннюю волну) пакеты данных, отправленные одним и тем же хостом, должны быть непрерывными, то есть номер Seq последнего пакета равен Seq Len предыдущего пакета. Можно также сказать, что Seq последнего пакета будет больше или равно Seq предыдущего пакета. Когда Wireshark обнаружит, что номер Seq следующего пакета меньше, чем Seq Len предыдущего пакета, он будет считаться неупорядоченным, поэтому будет выдан запрос [TCP Out-of-Order]. Как показано на рисунке 4, Seq = 2685642 для пакета 3362 меньше, чем Seq = 2712622 для пакета 3360, поэтому он вышел из строя.
Беспорядок малого промежутка имеет небольшой эффект: например, если исходный порядок равен 1, 2, 3, 4 и 5, а пакеты разбиты на 2, 1, 3, 4, 5, все будет хорошо. Однако непоследовательность с большим промежутком может инициировать быструю повторную передачу, например, когда она перетасовывается в 2, 3, 4, 5, 1, будет запущено достаточное количество Dup ACK, что приведет к повторной передаче пакета 1.
В случае нарушения порядка или потери пакетов получатель получит некоторые пакеты с номерами Seq, превышающими ожидаемые. Он будет подтверждать ожидаемое значение Seq каждый раз, когда получает такой пакет, таким образом, чтобы напомнить отправителю, поэтому он генерирует некоторый дубликат Ack. Wireshark пометит [TCP Dup ACK] на этом повторном подтверждении.
Взяв рисунок 5 в качестве примера, 7-й пакет, полученный сервером, представляет собой «Seq = 29303, Len = 1460», поэтому он ожидает, что следующий пакет должен быть Seq Len = 29303, 1460 = 30763, но не ожидал, что он фактически получил 8-й Пакет Seq = 32223 указывает, что пакет с Seq = 30763 может быть потерян. Поэтому сервер немедленно отправил Ack = 30763 на 9-й пакет, указав «Я хочу Seq = 30763». Поскольку 10-е, 12-е и 14-е, полученные сервером, больше, чем Seq = 30763, он будет отвечать Ack = 30763 каждый раз, когда его получает 1. Из рисунка видно, что Wireshark пометил эти ответы [ TCP Dup ACK.
6．[TCP Fast Retransmission]
Когда отправитель получает 3 или более [TCP Dup ACK], он понимает, что ранее отправленный пакет может быть потерян, поэтому он быстро ретранслирует его (это правило RFC). Взяв рисунок 6 в качестве примера, клиент получает 4 Ack = 991851, поэтому он повторно передает Seq = 991851 в пакете 1177.
Если пакет действительно потерян, и нет последующего пакета, который может вызвать [Dup Ack] в приемнике, он не будет повторно передан быстро. В этом случае отправитель должен ждать тайм-аута для повторной передачи, и такие пакеты повторной передачи будут помечены [TCP Retransmission] Wireshark. Взяв рисунок 7 в качестве примера, после того, как клиент отправил исходный пакет (номер пакета 1053), он не может ждать соответствующего Ack, поэтому он может быть повторно передан только после более чем 100 миллисекунд (пакет номер 1225).
Сверхурочная ретрансляция является очень технической точкой знаний. Например, продолжительность времени ожидания очень усвоена. Эта статья не будет детализирована. В конце концов, очень мало людей, которые должны это понимать.
«Win =» в пакете TCP представляет размер окна приема, которое указывает, сколько буферной области отправитель этого пакета может в настоящее время принимать данные. Когда Wireshark находит в пакете «win = 0», он помечает его как «нулевое окно TCP», указывая, что область буфера заполнена и больше не может принимать данные. Например, на рисунке 8 показано, что буфер сервера заполнен, поэтому уведомите клиента, чтобы он больше не отправлял данные. Мы даже можем видеть, как процесс его окна постепенно уменьшается с 3258 до 3263 пакетов, то есть с win = 15872 до win = 1472.
Когда Wireshark помещает флаг [TCP window Full] в пакет, это означает, что отправитель этого пакета исчерпал окно приема, объявленное другой стороной. Взяв в качестве примера рисунок 9, Британия всегда заявляла, что ее окно приема составляет всего 65535, а это означает, что Ближний Восток может отправлять ему максимум 65535 байтов данных без подтверждения, то есть «транзитные байты» не более 65535 байтов. Когда Wireshark находится в упаковкерасчетЭто сообщение будет отправлено, когда на Ближнем Востоке будет неподтверждено 65535 байт. Что касается того, как Wireshark вычисляет, пожалуйста, обратитесь к статье «Расчет» Количество байтов в пути «».
[TCP window Full] легко спутать с [TCP zerowindow], на самом деле они имеют сходство. Первый указывает, что отправитель этого пакета временно не может отправить данные, а последний указывает, что отправитель этого пакета временно не может получить данные, что означает, что оба означают, что передача приостановлена, и на оба следует обратить внимание.
10．[TCP segment of a reassembled PDU]
Если вы внимательно сравните рисунок 10 и рисунок 11, вы обнаружите, что ответ Read считан в заголовке пакета № 48 на рисунке 10 и рассчитан в заголовке пакета № 39 на рисунке 11. Это приведет к странному результату: время отклика на чтение, показанное на рисунке 10, составляет 2,528 миллисекунды (разница во времени между пакетами 38 и 48), а время отклика на чтение, показанное на рисунке 11, составляет 2,476 миллисекунды (разница во времени между пакетами 38 и 39). ). Который правильный? На этот вопрос сложно ответить. Если вас интересует фактическая общая производительность, посмотрите на первое, если вы хотите проигнорировать потерю протокола TCP / IP и посмотреть на скорость ответа сервера, то посмотрите на второе. В некоторых особых случаях разница между ними очень велика, поэтому ее необходимо уточнить.
12．［Time-to-live exceeded (Fragment reassembly time exceeded)］
ICMP сообщает о многих видах ошибок, которые нетрудно понять, поэтому мы возьмем только одну из них в качестве примера. [Превышено время повторной сборки фрагмента] указывает, что отправитель этого пакета уже получил некоторые фрагменты, но по какой-то причине он не смог собрать. Например, на рисунке 12 некоторые пакеты, отправленные из Шанхая в Пекин, передаются фрагментами, а некоторые из них теряются в пути, поэтому пекинская сторона не может собрать его, поэтому она должна использовать эту ошибку ICMP для информирования шанхайской стороны.
2. Анализ результатов захвата пакетов
(tcp.flags.syn == 1) && (tcp.analysis.retransmission) Отфильтровать запросы на повторную передачу рукопожатия
Отслеживание потока tcp
10.21.4.33:58964 просит 10.11.2.17:8080 отключиться.
10.11.2.17: 8080 возвращает ACK для подтверждения 10.21.4.33: 58964.
10.11.2.17: 8080 запросил отключение от 10.21.4.33: 58964, tcp повторно передан.
10.21.4.33: 58964 и 10.21.4.33: 8080 происходит переподключение.
(tcp.flags.reset == 1) && (tcp.seq == 1) фильтрует запросы на повторное соединение
Отслеживание потока tcp
10.11.2.17: 8080 запрос на отключение от 10.21.4.33: 57614 не получил подтверждение ACK 10.21.4.33: 57614, что привело к непрерывной повторной передаче tcp.
Интеллектуальная рекомендация
[Leetcode Tour] Array-697. Степень массива
Добавить расширение Redis для PHP7 под Windows
1 Просмотр информации о версии PHP Непосредственно используйте функцию phpinfo (), вывод в браузер в порядке Результаты вывода, в основном, отображают следующую информацию: версия PHP, архитектура, сб.
неправильная причина: Первичный ключ сущности установлен в режим саморазвития, но первичный ключ идентификатора устанавливается для него при сохранении.
работа на прошлой неделе не особенно подходит для различных причин, рисунок слайдера имеет узкое и не будет завершена на этой неделе, но это хорошо, чтобы быть в разработке и продвижении персонажа и д.
Том Зибель технические книги рекомендуется
iOS разработка программного обеспечения 1. Опытный в Objective-C [США] Кит Ли, Су Баолонг Народная почта и телекоммуникационная пресса Эта книга подходит для некоторых разработчиков, которые уже начал.
Что вызывает дублирование записей 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
На наш взгляд, анализ повторных передач лучше делать именно в графическом виде, когда мы можем сравнить разные части сети или, например, как здесь можно сделать предположение, что всплески трафика приводят к росту повторных передач, что приводит к возникновению ошибок. Графики интерактивны и кликая на разные участки можно быстро перемещаться во времени, существенно ускоряя поиск.
Напоследок ещё раз напомним – повторные передачи это нормально до тех пор, пока их количество не начинает зашкаливать!
Автоматизация IP-сети. Часть3 – Мониторинг TCP аномалий
В предыдущей статье рассмотрен мониторинг скорости открытия Веб ресурсов. В качестве параллельного процесса при измерении скорости, для более глубокого понимания возможных причин низкой скорости открытия Веб страниц, было бы интересно провести измерение TCP аномалий. Эту задачу попробуем решить в этой статье.
TCP аномалиями будем считать пакеты, которые свидетельствуют о потери информации в процессе передачи. Пожалуй, наиболее популярным инструментом глубокого анализа сетевого трафика, является утилита Wireshark и ее консольная версия tshark. Поэтому в качестве исходного анализатора будем рассматривать именно ее.
К TCP аномалиям будем относить следующее:
, где
bce0 – это название интерфейса на которому будет производится анализ пакетов. Это название в linux/Unix система можно увидеть командой ifconfig.
1.1.1.1 – IP адрес исследуемого ресурса
В результате вывода команды получаем таблицу, которую в последствии будем обрабатывать и подгружать в базу для построения графиков:
В качесте инструментов как и в прошлой статье будем использовать Cacti и Python3. Модернизируем скрипт из предыдущей статьи, для измерения скорости и TCP аномалий:
Запуск скрипта должен показать следующее (в операционной системе должны быть установлены утилиты tshark, nslookup, wget):
Далее краткая инструкция как модернизировать данные в Cacti для получения двух графиков с одного RRA:
1. Добавляем дополнительную output Fields в Data Input Methods:
2. Добавляем в Data Temlate дополнительную область tcp_error
3. Копируем Graph template и добавляем в него дополнительную информацию, при заведении новых графиков изначально нужно использовать этот Template:
4. Заводим график как показано в предыдущей статье с использование Template выше, график дублируем:
5. в итоге должно получится следующее:
6. Меняем данные в первом графике на правельные. Сначала меняем Template жмем save, затем проверяем что Data Source верный, при необходимости выбираем правильный:
7. Меняем данные для второго графика:
Если все сделано верно, должны получится следующие графики
На этом все, далее по плану при положительных отзывах, в следующих статьях рассмотрим модернизацию данной статистики.