Tcp out of order wireshark что это
Tcp out of order 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, фильтры и т. Д.
Существует большая разница между отправкой и получением захвата пакетов
Используйте «три оси» рабочего процесса и шагов для анализа проблемы.
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
На наш взгляд, анализ повторных передач лучше делать именно в графическом виде, когда мы можем сравнить разные части сети или, например, как здесь можно сделать предположение, что всплески трафика приводят к росту повторных передач, что приводит к возникновению ошибок. Графики интерактивны и кликая на разные участки можно быстро перемещаться во времени, существенно ускоряя поиск.
Напоследок ещё раз напомним – повторные передачи это нормально до тех пор, пока их количество не начинает зашкаливать!
Русские Блоги
Анализ пакетов 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 [США] Кит Ли, Су Баолонг Народная почта и телекоммуникационная пресса Эта книга подходит для некоторых разработчиков, которые уже начал.