встретил вопрос сегодня,Обновленный блог (20200520):

1. Детали пакета данных

Панель сведений о пакетеСодержание следующее,В основном используется для анализа подробной информации о пакетах.

Кадр: физический уровень, канальный уровень

Пакет: сетевой уровень

Сегмент: транспортный уровень, прикладной уровень

1）Frame

Обзор фрейма данных физического уровня

2）Ethernet II

Информация заголовка кадра Ethernet уровня канала передачи данных

3）Internet Protocol Version 4

Информация заголовка IP-пакета уровня Интернета

IP-заголовок:

4）Transmission Control Protocol

Информация заголовка сегмента данных транспортного уровня, вот протокол TCP.

TCP-заголовок:

5）Hypertext Transfer Protocol

Информация уровня приложения, вот протокол HTTP

2. Правила раскрашивания

В Wireshark по умолчанию имеется набор правил раскраски. Вы можете развернуть часть кадра пакета на панели «Сведения о пакете», чтобы просмотреть правила раскраски.

В меню «Просмотр | Правила раскраски» откройте окно правил раскраски, и вы сможете создавать, удалять, выбирать и удалять их самостоятельно.

3. Советы по Wireshark

1. Предыдущий сегмент TCP потерян (Предыдущий сегмент TCP потерян)
2. Потерянный сегмент Tcpacked (потерян ответ TCP)
3. Обновление окна TCP (обновление окна TCP)
4. TCP dup ack (повторный ответ TCP)
5. TCP поддерживает жизнь (TCP поддерживает жизнь)
6. Повторная передача TCP (повторная передача TCP)
7. Невидимый сегмент TCP ACKed (ответ подтверждения невидимого TCP)
8. повторное использование номеров TCP-портов (повторное использование номеров TCP-портов)
9. повторная передача TCP (повторная передача TCP)
10. TCP быстрая повторная передача (TCP быстрая повторная передача)
11. Предыдущий сегмент TCP потерян (сегмент данных отправителя потерян)
12. Ложная повторная передача TCP (псевдоповторная передача TCP)

1）Packet size limited during capture

Это означает, что помеченный пакет захвачен не полностью. Обычно это вызвано методом захвата пакетов. Некоторые операционные системы по умолчанию захватывают только первые 96 байтов каждого кадра.

Общая длина пакета №4 составляет 171 байт, но было захвачено только 96 байт.

2）TCP Previous segment not captured

Если Wireshark обнаружит, что Seq последнего пакета больше, чем Seq+Len, он узнает, что в середине отсутствует раздел.

Если недостающий сегмент не может быть найден во всем сетевом пакете (нарушение порядка исключено), появится подсказка.

Seq пакета № 6 равен 1449, что больше, чем Seq+Len=1+1=1 пакета № 5, что указывает на то, что в середине находится пакет размером 1448 байт, который не был перехвачен, что «Seq=1, Len=1448».

‘

175: SEQ=4675 больше, чем 174: SEQ=Seq(4381)+0 (длина)

Предыдущий сегмент TCP не был перехвачен. Когда TCP-соединение установлено, пакет SYN содержит максимальную длину TCP-сегментов друг друга, то есть флаг MSS, который обычно равен 1460. Если отправленный пакет длиннее максимальной длины сегмента, он будет фрагментирован и будет Фрагментированные пакеты будут помечены как «TCP-сегмент повторно собранного PDU». Эти фрагменты пакетов имеют одинаковый номер подтверждения, а порядковый номер каждого фрагмента различен.

Эти фрагменты обычно должны приниматься непрерывно, то есть следующий порядковый номер, указанный предыдущим фрагментом, является порядковым номером следующего полученного фрагмента. Если порядковый номер следующего полученного сегмента не является продолжением предыдущего сегмента, Wireshark пометит этот сегмент как TCP. Предыдущий сегмент не захвачен. Как показано на рисунке ниже, TCP-пакет с номером подтверждения 705 разделяется на несколько фрагментов и отправляется. Один из фрагментов длиной 1408 не был захвачен.

3）TCP ACKed unseen segment

Когда Wireshark обнаружит, что пакет Acked не был перехвачен, он выдаст запрос.

Seq+Len=6889+1448=8337 пакета №32, что указывает на то, что следующий пакет Seq=8337.

Мы видим Seq=11233 пакета №35, что означает, что данные с 8337 по 11232 не были захвачены.

4）TCP Out-of-Order

Вообще говоря, перегрузка сети приводит к тому, что последовательные пакеты приходят в разное время, задержки становятся слишком длительными или пакеты теряются, что требует повторной сборки блоков данных, поскольку они могут поступать на ваш компьютер по разным путям.

Когда Wireshark обнаружит, что Seq-номер следующего пакета меньше, чем Seq+Len предыдущего пакета, он посчитает его неисправным и выдаст приглашение.

Seq пакета № 3362 меньше Seq пакета 3360, поэтому он не в порядке.

Wireshark определяет, что TCP не по порядку, на основании того факта, что номер SEQ в TCP-пакете не является следующим номером SEQ, который ожидается получить, поэтому он определяется как не по порядку. Таким образом, когда происходит нарушение порядка TCP, вполне вероятно, что TCP вышел из строя или пакеты потеряны, что приводит к прерыванию порядкового номера на принимающей стороне. Как показано на рисунке ниже, в четвертом пакете данных после того, как клиент получил SYN ACK от сервера, сервер снова отправляет SYN ACK, и Wireshark помечает этот пакет как вышедший из строя.

Как показано на рисунке ниже, седьмой пакет данных должен был получить TCP-пакет с порядковым номером 1366882, но вместо этого получил пакет 1044834. Этот пакет данных должен был прийти с опозданием, поэтому Wireshark пометил его как вышедший из строя. .

5）TCP Dup ACK

Дублирование TCP-подтверждения XXX#X: То есть принимающая сторона требует, чтобы отправитель неоднократно отвечал на потерянное сообщение с порядковым номером XXX. X после # указывает, сколько раз оно было потеряно.

В случае нарушения порядка или потери пакетов получатель получит некоторые пакеты с порядковыми номерами, превышающими ожидаемые. Если такой пакет не получен, ожидаемое значение Seq будет подтверждено, а отправитель будет обналичен.

Следующий Seq=30763, ожидаемый пакетом № 7, но Seq=32223 для пакета № 8, указывает, что пакет Seq=30763 был потерян. Пакет № 9 отправил Ack=30763, что означает «Я хочу Seq=30763». .

Номера 10, 12 и 14 больше 30763, поэтому, если вы его не получите, вы ответите подтверждением.

Повторить подтверждение. При возникновении беспорядка или потери пакетов в сети порядковый номер, полученный принимающей стороной, будет прерывистым. В это время принимающая сторона ответит отправляющей стороне повторным подтверждением, а значение подтверждения — это следующий порядковый номер, который, как ожидается, будет получен. Повторные подтверждения, превышающие или равные 3 раза, вызовут быструю повторную передачу. Как показано ниже, 315, клиент отправляет серверу ответ ack=126951, ожидая получить TCP-пакет seq=126951 в следующем пакете. Но следующим полученным пакетом был TCP-пакет с seq=128211. Поскольку seq был прерывистым, Wireshark пометил пакет как TCP. Предыдущий сегмент не захвачен. 317, клиент повторно отправляет пакет ack=126951 на сервер и отправляет его повторно в первый раз, с 1 после #. 318, клиент получает TCP-пакет с seq=126951. 319 пакетов, все TCP-пакеты до seq=129471 были получены, поэтому клиент ответил обратной связью ack=129471.

6）TCP Fast Retransmission

Когда отправитель получает 3 или более [TCP Dup ACKs], он понимает, что ранее отправленный пакет мог быть потерян, и быстро передает его повторно.

Быстрая повторная передача TCP. Протокол TCP устанавливает механизм быстрой повторной передачи, чтобы избежать влияния чрезмерно медленных запусков на скорость передачи. Быстрая повторная передача запускается при получении 3 или более повторяющихся подтверждений. Быстрая повторная передача не требует ожидания тайм-аута RTO. Как показано ниже. 325, клиент отправляет серверу ответ ack=133251, указывая, что он ожидает получить следующий пакет с seq=133251 от сервера; В пакете 326 сервер отправил пакет данных с seq=135771 клиенту, что не соответствовало ожиданиям клиента. Поэтому клиент повторно передал пакет с ack=133251 в пакете 327 и еще раз заявил, что ожидал этого. получить пакет с seq=133251. Wireshark помечает повторное подтверждение как TCP Dup ACK, а число, за которым следует #, указывает количество повторных передач. 328, сервер отправил пакет данных с seq=137031 клиенту, который все еще не оправдал ожиданий клиента. Клиент повторно передал пакет с ack=133251 в пакете 329. 330, сервер получил 3 повторных подтверждения, инициировал быструю повторную передачу и повторно передал TCP-фрагмент с seq=133251.

7）TCP Retransmission

Если пакет действительно потерян и нет последующего пакета, который может вызвать [Dup Ack] на получателе, он не будет быстро повторно передан.

В этом случае отправителю придется дождаться истечения тайм-аута, прежде чем повторить передачу.

После отправки пакета № 1053 он так и не дождался соответствующего подтверждения и смог повторно передать его только через более чем 100 миллисекунд.

TCP-ретрансляция. Когда один и тот же пакет данных захватывается дважды, Wireshark определяет, что произошла повторная передача. В то же время Wireshark не фиксирует подтверждение обратной связи исходного пакета передачи. Таким образом, Wireshark определяет, что повторная передача действительна, и помечает ее как TCP. Ретрансляция. В соответствии с механизмом программного определения, если точка захвата пакета находится на клиенте, повторная передача TCP обычно представляет собой пакет восходящей линии связи, поскольку в это время клиент не получает подтверждения обратной связи от сервера и не имеет возможности узнать, был ли сервер получил первоначальный пакет передачи. RTO Trigger повторная передача клиента после таймаута. В настоящее время возможны две ситуации, а именно: 1) сервер получил первоначальный пакет передачи, но отправленный пакет подтверждения обратной связи был потерян, и клиент его не получил. 2) Сервер не получил начальный пакет передачи, поэтому он; Подтверждение обратной связи не было отправлено. В первом случае, если точка захвата пакетов находится на сервере, Wireshark, скорее всего, пометит пакет повторной передачи от клиента как ложную повторную передачу TCP. Как показано на рисунке ниже, пакет TCP в красной линии представляет собой пакет повторной передачи. Wireshark добавляет причину повторной передачи пакета, которая связана с тайм-аутом TRO, а также порядковый номер исходного пакета передачи 45 и выдает текущий номер. Время ожидания RTO.

8）TCP zerowindow

«Win» в пакете представляет размер окна приема. Когда Wireshark обнаруживает «win=0» в пакете, он выдает приглашение.

Скользящее окно TCP равно 0. Когда скорость отправки пакетов отправителя превышает скорость приема получателя, окно TCP получателя становится все меньше и меньше. Когда размер окна = 0, передаваемый получателем в подтверждении обратной связи, Wireshark отмечает TCP Zero. окно. В это время отправляющая сторона приостановит отправку данных до тех пор, пока не получит знак размера окна! = 0 от принимающей стороны.

9）TCP window Full

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

Это приглашение выдается, когда Wireshark подсчитывает, что на Ближнем Востоке имеется 65535 неподтвержденных байтов.

【TCP window Full】Указывает, что отправитель временно не можетОтправить данные；

【TCP zerowindow】Указывает, что отправитель временно не можетполучать данные。

Окно TCP заполнено. Это означает, что данные, отправленные отправителем, достигли верхнего предела окна приема. Отправитель приостанавливает отправку и ожидает уведомления о новом окне получения. Как показано на рисунке ниже, клиент отправляет подтверждение подтверждения на сервер и ожидает, что следующий пакет получит seq=288961, но окно приема составляет только 960. Сервер отправил 960 байтов данных после получения подтверждения, и окно TCP полно. Обратите внимание, что len=1004 — это длина всего IP-пакета, и нужно вычесть 44 байта IP-заголовка, что составляет 960 байт.

10）TCP segment of a reassembled PDU

Wireshark может виртуально собирать TCP-пакеты, принадлежащие PDU одного уровня приложений.

Уровень TCP получает большие порции сообщений от верхнего уровня и разбивает их на сегменты перед отправкой. Когда хост отвечает на запрос или команду, если ему необходимо ответить большим количеством данных (информации), а объем данных превышает допустимый. максимальное MSS TCP,

Хост передает эти данные, отправляя несколько пакетов (примечание: эти пакеты не фрагментированы).

11）Time-to-live exceeded（Fragment reassembly time exceeded）

Указывает, что отправитель этого пакета ранее получал некоторые фрагменты, но по какой-то причине не смог их собрать.

12. TCP window update

Обновление окна TCP. Когда окно TCP получателя изменяется, получатель информирует другую сторону о текущем размере окна приема через сообщение обновления окна TCP. Как показано на рисунке ниже, окно TCP Update также содержит подтверждение обратной связи. Порядковый номер подтверждения такой же, как и предыдущий порядковый номер подтверждения обратной связи, но это не дублирующее подтверждение.

Строка 109:

Сервер отправляет клиенту обновление окна TCP, указывая, что буфер очищен. И подсказывает, что на сервере теперь достаточно размера окна 43320.

Обновление окна TCP — это состояние TCP-связи. Это может произойти по многим причинам, но в конечном итоге все сводится к тому, что отправитель передает данные быстрее, чем получатель может их прочитать, что приводит к тому, что получатель освобождает некоторое пространство в буфере. установите отправленные данные, а затем отправьте Центр обновления Windows отправителю, сообщив отправителю, как быстро следует отправлять данные, чтобы передача и прием данных могли вернуться в нормальное состояние.

13. TCP acked unseen segment

ACK обратной связи указывает на неизвестный сегмент TCP. Это означает, что ответ ACK представляет собой TCP-пакет, которого нет в Wireshark. Возможно, Wireshark пропустил этот пакет, но перехватил пакет ACK, о котором сообщил партнер. Как показано на рисунке ниже, пакет, помеченный как ack unseen сегмент, возвращает ack=2721. Похоже, что пакет seq=1361 возвращается, но на самом деле этот ack также возвращает пакет seq=1, поскольку пакет seq=. 1 не захватывается, поэтому Wireshark помечает подтверждение обратной связи как подтвержденный невидимый сегмент. На рисунке ниже мы также видим, что, поскольку узел уже вернул ack=2721, это означает, что пакет с seq=1, отправленный отправителем, также был получен узлом, но Wireshark мог его пропустить.

14. TCP RST

Сброс TCP. Это способ протокола TCP завершить ненормальное соединение с помощью отметки сброса = 1 во флагах. Если TCP-соединение не может быть разорвано обычным четыре раза, одна сторона может завершить TCP-соединение, отправив TCP-пакет, содержащий флаг сброса. Как показано на рисунке ниже, отправитель отправляет данные через два потока TCP. На снимке экрана получатель сначала отправляет отправителю сообщение TCP window=0, позволяя отправителю приостановить отправку данных, а затем отправляет метку TCP RST для освобождения. TCP-соединение. Предполагается, что программа-получатель внезапно вышла из строя, из-за чего данные кэша невозможно было очистить, а затем система-получатель отправила сброс TCP, чтобы освободить TCP-соединение.

вопрос

С чем мы столкнулись: Клиент воспроизводит звук во время загрузки, Серьезные отставания ветра, когда сеть слаба:

Причины отставания: 1. MTU по умолчанию для http — 1400, а размер каждого пакета tcp — 1400, но TCP не может гарантировать, что данные поступят в порядке первыми. После того, как клиент получает все данные, он сортирует пакеты данных, а затем передает упорядоченные данные на прикладной уровень http. 2. TCP-пакеты будут передаваться повторно, если сеть неисправна. 3. Клиент играет во время получения, то есть он воспроизводит в соответствии с последовательностью пакета данных. Если для определенного пакета происходит повторная передача TCP, клиент должен дождаться получения пакета, прежде чем он сможет продолжить воспроизведение. Поэтому происходит отставание. 4. Мы не видели этого на Wireshark Пакет с seq=29401 не обязательно означает, что сервер его не доставил. Подсказка Wireshark: TCP Previous segment not captured。 Wireshark, возможно, не поймал этот пакет. Решение: В настоящее время он воспроизводится во время приема. При слабой сети вероятность повторной передачи TCP очень высока, что приведет к зависаниям. Возобновление загрузки и воспроизведения после отключения электроэнергии значительно уменьшит задержку.

1. Потеря посылки:

Сначала Wireshark перехватывает пакет и видит сообщение: TCP Предыдущий сегмент не захвачен, что указывает на отсутствие пакета данных:

501： seq=28001, ACK=140

502: seq=30801, ACK=140 (TCP Previous segment not captured)

То есть пакеты данных seq=29401 и ACK=140 были потеряны.

503: seq=40, ACK=29401 требует, чтобы сервер отправил этот пакет,

504: seq=32201, пришёл пакет данных ACK=140,

505, 507, 509 (TCP Dup ACK) всегда отправляется на сервер, чтобы сообщить, что пакет потерян.

2. Повторно передайте пакет данных: В результате только в 547 сервер повторно передал TCP-пакет.

Во время периода ожидания воспроизведение звука должно зависать.

3. Продолжайте запрашивать повторную передачу:seq=30801, ACK=140,（550,552,554...TCP Dup ACK）.

На самом деле этот пакет уже был отправлен раньше, и клиент не кэшировал эти данные.

4. Повторно передайте пакет данных: в результате только в 573 сервер повторно передал TCP-пакет.

Воспроизведение звука на клиенте сильно тормозит.