Русские Блоги
Когда вы видите это приглашение, это означает, что помеченный пакет не захвачен. В качестве примера возьмем пакет № 4 на рисунке 1. Он имеет общую длину 171 байт, но были захвачены только первые 96 байт, поэтому Wireshark дал это приглашение.
Эта ситуация обычно вызвана перехватом пакетов. В некоторых операционных системах по умолчанию tcpdump захватывает только первые 96 байтов каждого кадра. Мы можем использовать параметр «-s», чтобы указать количество байтов, которые мы хотим захватить.
2.［TCP Previous segment not captured］
В процессе передачи по TCP сегмент данных, отправляемый одним и тем же хостом, должен быть непрерывным, то есть номер Seq последнего пакета равен Seq Len предыдущего пакета (три рукопожатия и четыре колебания являются исключениями). Если Wireshark обнаружит, что номер Seq следующего пакета больше, чем Seq Len предыдущего пакета, он знает, что часть данных отсутствует в середине. Если пропущенные данные не найдены во всем сетевом пакете (то есть неупорядоченные исключены), он выдаст запрос [Предыдущий сегмент TCP не захвачен]. Например, в примере на фиг.2 номер 1449 Seq пакета 6 больше, чем Seq Len = 1 0 = 1 пакета 5, что указывает на то, что пакет, несущий 1448 байтов в середине, не был перехвачен, это «Seq = 1, Len = 1448» .
Есть два случая, когда сетевой пакет не перехвачен: один действительно потерян, другой — то, что он фактически не потерян, но инструмент захвата пакетов пропустил его. Как отличить эти две ситуации в Wireshark? Просто посмотрите на подтверждение (Ack) от другой стороны. Если подтверждение содержит пакет, который не был перехвачен, то просто отсутствует инструмент захвата пакета, в противном случае он действительно потерян.
Кстати, проанализируйте сетевой пакет на рисунке 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.
9．[TCP window Full]
Когда Wireshark помещает флаг [TCP window Full] в пакет, это означает, что отправитель этого пакета исчерпал окно приема, объявленное другой стороной. Взяв в качестве примера рисунок 9, Британия всегда заявляла, что ее окно приема составляет всего 65535, а это означает, что Ближний Восток может отправлять ему максимум 65535 байтов данных без подтверждения, то есть «транзитные байты» не более 65535 байтов. Когда Wireshark находится в упаковкерасчетЭто сообщение будет отправлено, когда на Ближнем Востоке будет неподтверждено 65535 байт. Что касается того, как Wireshark вычисляет, пожалуйста, обратитесь к статье «Расчет» Количество байтов в пути «».
[TCP window Full] легко спутать с [TCP zerowindow], на самом деле они имеют сходство. Первый указывает, что отправитель этого пакета временно не может отправить данные, а последний указывает, что отправитель этого пакета временно не может получить данные, что означает, что оба означают, что передача приостановлена, и на оба следует обратить внимание.
10．[TCP segment of a reassembled PDU]
Когда вы получаете это приглашение, вы должны включить функцию Разрешить субсектору повторную сборку потоков TCP в меню Правка -> Параметры -> Протоколы -> TCP. Это означает, что Wireshark может виртуализировать TCP-пакеты, принадлежащие одному и тому же PDU прикладного уровня (например, SMB’s Read Response и Write Request). Как показано на рисунке 10, этот ответ чтения SMB завершается пакетами с 39 по 48, поэтому Wireshark фактически собирает все пакеты в последнем пакете. Преимущество этого заключается в том, что вы можете щелкнуть правой кнопкой мыши поле внизу рисунка 10 и выбрать «Копировать -> Байты -> Только для печати», чтобы скопировать весь PDU прикладного уровня. Студенты, занимающиеся исследованиями и разработками, могут нуждаться в этой функции больше.
Вы видите это приглашение, указывающее, что Разрешить субсектору повторную сборку потоков TCP была закрыта в меню Edit -> Preferences -> Protocols -> TCP. Например, пакеты на рисунке 10 становятся похожими на рисунок 11, когда они закрыты.
Если вы внимательно сравните рисунок 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.
TCP DUP ACK
Тут представлен пример как не должен работать http сервер. Одна из характерных ошибок случившаяся на начальном этапе внедрения LWIP в наш проект.
Стрелками показаны реально принятые сервером пакеты (остальные потеряны), поэтому и возникает retransmission (повторные передачи от клиента). Но это нормально . Это говорит о том , что наш сервер очень тормозной (оно и неудивительно это на контроллере с ОЗУ 128К).
Пакет retransmission (повторный) ничем не должен отличается от основного , никакими опциями. Но у нас есть огромный непонятный нюанс (должно ли так быть?) : всего 2 пакета надо было передать (содержание 1460 + 885) , клиент делает повторную передачу этих двух пакетов , но содержание их теперь другое (1460 + 1460). Причем сначала 1460 (это от конца 885:2345) и потом 1460 (это с начала 0:1460). Если еще учесть ,что в первом retransmission Seq=886 Ack=1 , а во втором Seq=886 Ack=1, то можно предположить , что это не ошибка клиента и на стороне сервера можно таки собрать содержание передаваемых пакетов корректно. Но LWIP 1.4.1 или 2.1.2 этого не поддерживают (как я понял).
Дальше по коду наш сервер почему-то решает передать на первый пакет в ответ tcp_send_empty_ack , хотя с SYN/ACK мы клиенту указали MSS 2920 , то способны принять 1460*2 (два полноценных пакета) БЕЗ ПОДТВЕРЖДЕНИЯ. Где логика?
Вот тут проблема
Мы (сервер) передаем tcp_send_empty_ack с параметрами Seq=1 Ack=1 и это точно что-то неправильное. Поэтому WinShark помечает этот пакет TCP DUP ACK.
Это надо понимать так : сервер и клиент установили уже соединение (3 первых пакета) . Потом клиент посылает данные 1460+885 (два пакета). Но сервер отвечает ACK с нулевой длиной , что я получил данные с Seq =1. То есть я сервер получил 1 байт. Какой 1 байт непонятно.
What does TCP DUP ACK mean?
There can be several things going on — the most common would be the use of TCP Fast Retransmission which is a mechanism by which a receiver can indicate that it has seen a gap in the received sequence numbers that implies the loss of one or more packets in transit. The repeated acknowledgements at the last known value before the gap signal which packets the sender should retransmit. This can occur without waiting for the acknowledgement timeout for the lost packet to hit on the transmitter — which, as the name implies, means recovering a lot faster.
It’s also possible that the same symptom of gaps in sequence numbers might be seen in a situation where packets are being delivered out of order. As above, if the receiver sees (for example) a segment with sequence #5 followed by another with #7 before seeing sequence #6 then it might try to begin to trigger a fast retransmit. Upon seeing #6 arrive, though, it would stop sending the duplicate acknowledgements.
A less common cause would be certain media problems where certain packets might end up being seen more than once. If this is the case, however, you’re likely to see other problems on the link (. including other packets showing as dupes in Wireshark).
So — if you’re seeing a few random duplicate ACK’s but no (or few) actual retransmissions then it’s likely packets arriving out of order. If you’re seeing a lot more duplicate ACK’s followed by actual retransmission then some amount of packet loss is taking place. Both situations are, unfortunately, entirely possible on the global Internet. If you’re seeing other kinds of duplicate packets as CRC issues and generally slow performance then it might make sense to look at link issues on your own network.
TCP Retransmissions – что это и как их анализировать с помощью Wireshark?
Наиболее частая ошибка, которую видит любой ИТ-специалист, установивший Wireshark и захвативший трафик, это повторная передача TCP пакета (TCP Retransmission). Даже в самой быстрой и правильно настроенной сети происходят потери пакетов и как следствие неполучение подтверждений доставки пакетов от получателя отправителю или обратно.
Это нормально и алгоритмы протокола TCP позволяют отрулить данные ошибки. Поэтому важно понимать, что TCP Retransmission – это симптом, а не причина болезни. Причины могут быть в ошибках на интерфейсах, перегрузке процессоров на сервере или пользовательском ПК, проблемы в пропускной способности каналов связи или фрагментирование пакетов и работа с этим на пути следования пакетов. Внимание надо уделить тому, как много повторных передач и часто они возникают, а не их наличию в принципе.
Анализатор протоколов Wireshark в зависимости от поведения определяет несколько типов повторных передач:
- TCP Retransmission – классический тип повторной передачи пакетов. Анализируя трафик Wireshark видит два пакета с одинаковым порядковым номером (sequence number) и данными с разницей по времени. Отправитель пакета, не получив подтверждения получения от адресата по истечении таймера retransmission timer, отправляет пакет повторно автоматически, предполагая, что он потерян по пути следования. Значение таймера подстраивается гибко и зависит от кругового времени передачи по сети для конкретного канал связи. Как он рассчитывается можно узнать в RFC6298 Computing TCP’s Retransmission Timer.
- TCP Fast Retransmission – отправитель отправляет повторно данные немедленно после предположения, что отправленные пакеты потеряны, не дожидаясь истечения времени по таймеру (ransmission timer). Обычно триггером для этого является получение нескольких подряд (обычно три) дублированных подтверждений получения с одним и тем же порядковым номером. Например, отправитель передал пакет с порядковым номером 1 и получил подтверждение – порядковый номер плюс 1, т.е. 2. Отправитель понимает, что от него ждут следующий пакет с номером два. Предположим, что следующие два пакета потерялись и получатель получает данные с порядковым номером 4. Получатель повторно отправляет подтверждение с номером 2. Получив пакет с номером 5, отправитель все равно отправляет подтверждение с номером 2. Отправитель видит три дублированных подтверждения, предполагает, что пакеты 2, 3 были потеряны и шлет их заново, не дожидаясь таймера.
- TCP Spurious Retransmission – этот тип повторной передачи появился в версии 1.12 сниффера Wireshark и означает, что отправитель повторно отправляет пакеты, на которые получатель уже отправил подтверждение.
Быстрая идентификация повторных передач (TCP Retransmissions) с помощью Wireshark
Первая возможность – это воспользоваться фильтром: tcp.analysis.retransmission:
На экране будут отображены все повторные передачи и указан их тип.
Вторая возможность – это графический анализ повторных передач, когда на графике мы можем выводить несколько графиков и сравнивать их во времени. Также можно сравнить два разных получателя трафика и сделать вывод, в каком сегменте сети происходят больше всего повторных передач вследствие перегрузки сети или оборудования.
Заходим в раздел Statistics – I/O Graph:
На экране откроется окно с графиком, на котором будет отображаться общее количество передач во времени с момента начала захвата трафика. Единица измерения PPS – количество пакетов в секунду.
Далее в окошке под графиком можно добавлять дополнительные графики в зависимости от введенного фильтра и менять стиль вывода информации – график, гисторгамма и т.д. Тут добавлен знакомый нам фильтр: tcp.analysis.retransmission
Далее мы можем провести сравнительный анализ проблем с повторными передачами в сети в целом и между разными пользователями, указав фильтр: ip.src == xxx.xxx.xxx.xxx && tcp.analysis.retransmission
На наш взгляд, анализ повторных передач лучше делать именно в графическом виде, когда мы можем сравнить разные части сети или, например, как здесь можно сделать предположение, что всплески трафика приводят к росту повторных передач, что приводит к возникновению ошибок. Графики интерактивны и кликая на разные участки можно быстро перемещаться во времени, существенно ускоряя поиск.
Напоследок ещё раз напомним – повторные передачи это нормально до тех пор, пока их количество не начинает зашкаливать!
См. также:
- Как включить колонку ACKfor в WireShark?
- Перехват паролей с помощью Wireshark
- Какие параметры и как измеряются при анализе производительности сервисов и приложений?