Tcp retransmission wireshark что это
Tcp retransmission 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.
Как вычислить RTO (Retransmission timeout) для TCP соединений
Что определяет tcp_retries1 и tcp_retries1
Значение RTO в совокупности со значениями в параметрах ядра Linux net.ipv4.tcp_retries1 и net.ipv4.tcp_retries2 используется для определения числа попыток, а также тайм-аута повторной передачи неподтверждённых TCP-пакетов по уже установленному TCP-соединению, после истечения которого передача сбрасывается.
В документации сказано:
$ man tcp
.
tcp_retries1 (integer; default: 3; since Linux 2.2)
The number of times TCP will attempt to retransmit a packet on an established connection normally, without the extra effort of getting the network layers involved. Once we exceed this number of retransmits, we first have the network layer update the route if possible before each new retransmit. The default is the RFC specified minimum of 3.
tcp_retries2 (integer; default: 15; since Linux 2.2)
The maximum number of times a TCP packet is retransmitted in established state before giving up. The default value is 15, which corresponds to a duration of approximately between 13 to 30 minutes, depending on the retransmission timeout. The RFC 1122 specified minimum limit of 100 seconds is typically deemed too short.
tcp_retries1 и tcp_retries2 определяет число попыток повторной передачи.
В первом случае ( tcp_retries1 ), после 3 (по умолчанию) попыток повторной передачи будет обновлён сетевой маршрут прежде чем сделать последующие попытки.
Ок, а как определить начальную величину RTO?
Как рассчитать RTO (Retransmission timeout)
4.2.3.1 Retransmission Timeout Calculation
A host TCP MUST implement Karn’s algorithm and Jacobson’s algorithm for computing the retransmission timeout («RTO»).
o Jacobson’s algorithm for computing the smoothed round-trip («RTT») time incorporates a simple measure of the variance [TCP:7].
o Karn’s algorithm for selecting RTT measurements ensures that ambiguous round-trip times will not corrupt the calculation of the smoothed round-trip time [TCP:6].
This implementation also MUST include «exponential backoff» for successive RTO values for the same segment. Retransmission of SYN segments SHOULD use the same algorithm as data segments.
Однако несмотря на значение RTT и прочие факторы, например RTT при пинге может быть » rtt min/avg/max/mdev = 77.108/78.227/80.600/1.414 ms «, начальное RTO из определённых соображений самого разработчика ОС ограничено определёнными минимальным и максимальным значениями.
Например для ОС систем на базе ядра Linux минимальное и максимальное значения RTO зашиты в константах » TCP_RTO_MIN » и » TCP_RTO_MAX «:
HZ равно 1000 мс или 1 сек, таким образом TCP_RTO_MIN = 200 мс и TCP_RTO_MAX = 120 сек.
Для ОС Windows минимальное-максимальное RTO составляет 300-65535 мс.
Более же полная формула калькуляции RTO описана в RFC 793:
Retransmission Timeout
Because of the variability of the networks that compose an internetwork system and the wide range of uses of TCP connections the retransmission timeout must be dynamically determined. One procedure for determining a retransmission time out is given here as an illustration.
An Example Retransmission Timeout Procedure
Measure the elapsed time between sending a data octet with a particular sequence number and receiving an acknowledgment that covers that sequence number (segments sent do not have to match segments received). This measured elapsed time is the Round Trip Time (RTT). Next compute a Smoothed Round Trip Time (SRTT) as:
SRTT = ( ALPHA * SRTT ) + ((1-ALPHA) * RTT)
and based on this, compute the retransmission timeout (RTO) as:
Отталкиваясь от вышеизложенного, если сумма значений параметров tcp_retries1 и tcp_retries2 будет равна 15, то взяв в качестве начального RTO минимальное значение в 200 мс увеличение таймаута между каждой попыткой повторной передачи будет выглядеть следующим образом:
Как узнать RTO для TCP соединений
Начальное RTO для большинства TCP-соединений как правило составляет 300-400 мс.
Ссылки по теме RTO
Рекомендуемый контент
А тут же ж мог быть рекомендуемый контент от гугла 🙂 Для отображения рекомендуемого контента необходимо в браузере разрешить выполнение JavaScript скриптов, включая скрипты с доменов googlesyndication.com и doubleclick.net
Вы не любите рекламу!? Напрасно!:) На нашем сайте она вовсе ненавязчивая, а потому для нашего сайта можете полностью отключить AdBlock (uBlock/uBlock Origin/NoScript) и прочие блокировщики рекламы! AdBlock/uBlock может препятствовать нормальной работе системы поиска по сайту, отображению рекомендуемого контента и прочих сервисов Google. Рекомендуем полностью отключить блокировщик рекламы и скриптов, а также разрешить фреймы (aka iframe).
Русские Блоги
Основное использование Wireshark
Возьмите сообщение:
После загрузки и установки Wireshark запустите Wireshark и выберите имя интерфейса в списке интерфейсов, а затем начните захват пакетов на этом интерфейсе. Например, если вы хотите захватить трафик в беспроводной сети, щелкните по беспроводному интерфейсу. Нажмите «Параметры захвата», чтобы настроить дополнительные свойства, но в этом нет необходимости.
Каждая строка на верхней панели соответствует сетевому сообщению.По умолчанию отображается время приема сообщения (относительно времени, когда начинается выборка), IP-адреса источника и получателя, а также информация о протоколе и сообщении. Нажмите на строку, чтобы увидеть больше информации в двух окнах ниже. Значок «+» показывает подробную информацию для каждого слоя в сообщении. В нижнем окне перечислены сообщения в шестнадцатеричном и ASCII-кодах.
Когда вам нужно прекратить захват сообщений, нажмите кнопку остановки в верхнем левом углу.
Цветовая идентификация:
Пример сообщения:
Например, если вы установили Wireshark дома, но нет никаких интересных сообщений для наблюдения в среде домашней сети, вы можете перейти на вики Wireshark, чтобы загрузить файл примера сообщения.
Открыть файл захвата довольно просто, просто нажмите «Открыть» в главном интерфейсе и просмотрите файл. Вы также можете сохранить свой собственный файл захвата пакета в Wireshark и открыть его позже.
Фильтровать сообщения:
Если вы пытаетесь проанализировать проблему, например, сообщение, отправленное программой при вызове, вы можете закрыть все другие приложения, которые используют сеть, чтобы уменьшить трафик. Однако, все еще может быть большое количество пакетов, которые необходимо отфильтровать.В этом случае используется фильтр Wireshark.
Вы также можете нажать меню «Анализ» и выбрать «Показать фильтры», чтобы создать новые условия фильтрации.
Вы увидите все разговоры между сервером и целью.
Проверьте сообщение:
Выбрав сообщение, вы можете углубиться в его содержание.
Универсальное обучение Wireshark (2): используйте Wireshark для наблюдения основных сетевых протоколов
TCP / IP устанавливает соединение посредством трехстороннего рукопожатия. Три типа сообщений в этом процессе: SYN, SYN / ACK, ACK.
Примечание. Найти пакет также можно использовать для поиска шестнадцатеричных символов, таких как сигналы вредоносных программ, или строк поиска, таких как команды протокола в файлах захвата пакетов.
На этом шаге появится окно отображения сеанса, по умолчанию содержит код ASCII сеанса TCP, клиентское сообщение красного цвета, что указывает на то, что сообщение сервера синего цвета.
Это окно похоже на окно, показанное на рисунке ниже, что очень полезно для чтения полезных данных протокола, таких как HTTP, SMTP, FTP.
Перейдите в режим шестнадцатеричного дампа, чтобы просмотреть шестнадцатеричный код загрузки, как показано ниже:
Закройте всплывающее окно, Wireshark отобразит только выбранный поток TCP-пакетов. Теперь легко различить 3 сигнала рукопожатия.
Примечание. Здесь Wireshark автоматически создает фильтр отображения для этого сеанса TCP. В этом примере: (ip.addr eq 192.168.1.2 и ip.addr eq 209.85.227.19) и (tcp.port eq 80 и tcp.port eq 52336)
SYN сообщение:
Сообщение № 5, показанное на рисунке, является сообщением SYN, отправленным клиентом на сервер.Это сообщение используется для установления синхронизации с сервером, чтобы гарантировать, что связь между клиентом и сервером передается в порядке. Заголовок сообщения SYN имеет 32-битный порядковый номер. Нижнее диалоговое окно показывает некоторую полезную информацию о сообщении, такую как тип сообщения и серийный номер.
Сообщение SYN / ACK:
Сообщение № 7 является ответом сервера. Как только сервер получает клиентское сообщение SYN, он читает порядковый номер сообщения и использует этот номер в качестве ответа, то есть он информирует клиента о том, что сервер получил сообщение SYN, добавляя один И реализован в виде номера ответа, после которого клиент узнает, что сервер может получить сообщение.
ACK сообщение:
ARP & ICMP：
Запустите захват пакетов Wireshark. Откройте окно консоли Windows и используйте инструмент командной строки ping для просмотра состояния соединения с соседним компьютером.
После остановки захвата пакета Wireshark показан на рисунке ниже. Пакеты ARP и ICMP довольно сложно идентифицировать, и они создают условия фильтрации, которые отображают только ARP или ICMP.
ARP сообщение:
Протокол разрешения адресов, или ARP (протокол разрешения адресов), основан наIP-адресполучитьФизический адресОдин изПротокол TCP / IP, Его функция:главная ЭВМARP запросвещанияПерейти ко всем хостам в сети и получить ответное сообщение, чтобы определить цельIP-адресФизический адрес IP-адреса и аппаратный адрес сохраняются в локальном ARP-кэше одновременно, и ARP-кэш напрямую запрашивается при следующем запросе.
Запрос ARP, первоначально отправленный с ПК, определяет MAC-адрес IP-адреса 192.168.1.1 и получает ответ ARP от соседней системы. После запроса ARP вы увидите сообщение ICMP.
ICMP-сообщение:
Протокол управляющих сообщений Интернета (ICMP) используется дляTCP/IPУправляющие сообщения отправляются по сети для обеспечения обратной связи по различным проблемам, которые могут возникнуть в коммуникационной среде.С помощью этой информации менеджеры могут диагностировать возникшие проблемы и затем принимать соответствующие меры для их решения.
ПК отправляет эхо-запрос и получает эхо-ответ, как показано выше. Сообщение ping помечается как Тип 8, а ответное сообщение помечается как Тип 0.
Если вы пингуете одну и ту же систему несколько раз и удаляете кэш ARP на ПК, после использования следующей команды ARP будет сгенерирован новый запрос ARP.
HTTP：
Протокол HTTP в настоящее время является наиболее широко используемым базовым протоколом. Это связано с тем, что многие приложения в настоящее время основаны на WEB-методе. Он прост в реализации, а разработка и развертывание программного обеспечения просты. Нет необходимости в дополнительном клиенте. Вы можете использовать браузер. Этот процесс начинается с запроса сервера о передаче сетевых файлов.
Как видно из приведенного выше рисунка, сообщение содержит команду GET. После того как HTTP отправляет начальную команду GET, TCP продолжает процесс передачи данных. Во время следующего процесса соединения HTTP запрашивает данные с сервера и использует TCP для передачи данных обратно клиенту. Перед передачей данных сервер информирует клиента о том, что запрос действителен, отправив сообщение HTTP OK. Если у сервера нет разрешения на отправку цели клиенту, он вернет 403 Запрещено. Если сервер не может найти цель, запрошенную клиентом, он возвращает 404.
Если данных больше нет, соединение может быть прервано, подобно сообщениям SYN и ACK трехстороннего сигнала квитирования TCP, где отправляются сообщения FIN и ACK. Когда сервер заканчивает передачу данных, он отправляет FIN / ACK клиенту. Это сообщение указывает на окончание соединения. Затем клиент возвращает сообщение ACK и увеличивает порядковый номер в FIN / ACK. Это прекращает связь со стороны сервера. Чтобы завершить этот процесс, клиент должен снова запустить этот процесс на стороне сервера. Процесс FIN / ACK должен быть инициирован и подтвержден как на клиенте, так и на сервере.
Используйте графические инструменты Wireshark IO для анализа потоков данных
Основные графики ввода-вывода:
Для удобства объяснения, нажмите на образец пакета или нажмите Статистика-IO Графики с вашим собственным wireshark. Этот захват пакета является случаем, когда загрузка HTTP сталкивается с потерей пакета.
Примечание: условие фильтра пусто, этот график показывает весь поток.
Это отображение по умолчанию не очень полезно в большинстве случаев устранения неполадок. Измените ось Y на бит / тик, чтобы вы могли видеть трафик в секунду. Из этого рисунка видно, что пиковая скорость составляет около 300 кбит / с. Если вы видите, что поток падает до нуля в некоторых местах, это может быть проблемой. Эту проблему легко найти на графике, но она может быть не столь очевидной при просмотре списка сообщений.
Фильтр:
Каждый график может применять условие фильтра. Здесь создаются два разных графика, один HTTP и один ICMP. Можно видеть, что График 1 использует «http», а График 2 использует «icmp» в условиях фильтрации. Вы можете увидеть некоторые пробелы в красном потоке ICMP на рисунке для дальнейшего анализа.
Общие условия устранения неполадок фильтра:
Это очень полезно для устранения сетевых задержек / проблем приложений с некоторыми фильтрами:
tcp.analysis.lost_segment: Указывает, что при перехвате пакетов был замечен прерывистый серийный номер. Потерянные пакеты вызовут дублирование ACK, что приведет к повторной передаче.
tcp.analysis.duplicate_ack：Отображает сообщения, которые были подтверждены более одного раза. Повторные ACK Далянга являются признаком высокой задержки между конечными точками TCP.
tcp.analysis.retransmission：Показать все повторные передачи в захвате пакета. Это нормально, если количество повторных передач невелико, и могут быть проблемы с несколькими передачами. Обычно это означает низкую производительность приложения и / или потерю пользовательских пакетов.
tcp.analysis.window_update：Графически отображать размер окна TCP во время передачи. Если вы видите, что размер окна упал до нуля, это означает, что отправитель вышел и ждет, пока получатель подтвердит все переданные данные. Это может указывать на то, что принимающая сторона уже перегружена.
tcp.analysis.bytes_in_flight：Количество неподтвержденных байтов в сети в определенный момент времени. Число неподтвержденных байтов не может превышать размер вашего окна TCP (определенный в начальном 3 рукопожатии TCP), чтобы максимизировать пропускную способность, которую вы хотите максимально приблизить к размеру окна TCP. Если вы видите, что он постоянно меньше размера окна TCP, это может означать потерю пакетов или другие проблемы на пути, которые влияют на пропускную способность.
tcp.analysis.ack_rtt：Измерьте полученные TCP-пакеты и соответствующий ACK. Если этот интервал времени больше, это может указывать на некоторый тип задержки в сети (потеря сообщения, перегрузка и т. Д.).
Примените некоторые из вышеупомянутых условий фильтра в захвате пакета:
Как видно из этого рисунка: по сравнению с общим HTTP-трафиком много повторных передач и дубликатов ACK. На этом графике вы можете увидеть моменты времени, в которые произошли эти события, и долю общего трафика.
Функция:
IO Graphs имеет шесть доступных функций: SUM, MIN, AVG, MAX, COUNT, LOAD.
MIN( ), AVG( ), MAX( )
Сначала посмотрите на минимальное, среднее и максимальное время между кадрами. Это очень полезно для просмотра задержки между кадрами / сообщениями. Мы можем объединить эти функции «frame.time_delta”Условия фильтрации четко видят задержку кадра и делают задержку прохождения сигнала в оба конца более очевидной. Если файл захвата пакета содержит несколько сеансов между разными хостами, и вы хотите знать только одну из пары, вы можете изменить «frame.time_delta«Комбинированные условия исходного и целевого хоста похожи на« ip.addr == x.x.x.x && ip.addr == y.y.y.y ». Как показано на рисунке ниже:
Мы сделали следующие шаги:
Как видно из приведенного выше рисунка, MAX frame.delta_time потока данных достигает 0,7 секунды при 106 секундах, что является серьезной задержкой и вызывает потерю пакетов. Если вы хотите углубиться в изучение, просто нажмите на эту точку на картинке, и она перейдет к соответствующему кадру. Это соответствует 1003-му пакету в файле захвата пакета в этом примере. Если вы видите, что средняя задержка между кадрами относительно невелика, но внезапно в какой-то момент возникает очень длительная задержка, вы можете щелкнуть этот кадр, чтобы увидеть, что произошло в это время.
Count( )
Эта функция подсчитывает количество событий, произошедших в течение интервала, и полезна при просмотре идентификаторов анализа TCP, таких как повторные передачи. Пример изображения выглядит следующим образом:
Sum( )
Эта функция подсчитывает совокупную стоимость событий. Существует два распространенных варианта использования, в которых рассматривается сбор данных TCP и проверка серийного номера TCP. Давайте посмотрим на первый пример длины TCP. Создайте две диаграммы: одну с использованием IP-адреса клиента 192.168.1.4 в качестве источника, а другую с использованием IP-адреса клиента в качестве адреса назначения. Для каждого рисунка мы объединяем функцию sum () с условием фильтра tcp.len. Разбивая на два разных графика, мы видим количество данных, движущихся в одном направлении.
Из графика видно, что объем данных, отправляемых клиенту (условие фильтрации IP.DST == 192.168.1.4), превышает объем данных от клиента. Это показано красным цветом на рисунке. Черная полоса показывает данные от клиента к серверу, а относительный объем данных очень мал. Это имеет смысл, потому что клиент только запрашивает файл и отправляет данные подтверждения после получения, в то время как сервер отправляет большой файл. Очень важно, что если вы меняете порядок изображений и используете IP-адрес клиента в качестве адреса назначения на рисунке 1 и IP-адрес клиента в качестве адреса источника на рисунке 2, вы можете не увидеть правильное отображение данных при использовании FBAR. Поскольку меньшее число цифр означает, что оно отображается на переднем плане, более высокое число цифр может быть перезаписано.
Теперь давайте посмотрим на порядковый номер TCP одинаковых потерь и задержки пакетов.
Вы можете увидеть некоторые пики и падения на рисунке, что указывает на проблему с передачей TCP. По сравнению с обычными TCP-пакетами:
На этом рисунке вы можете видеть, что порядковый номер TCP неуклонно увеличивается, указывая на то, что передача стабильна без множественных передач или потери пакетов.