psh ack что значит
TCP это основа HTTP
Основные промежуточные результаты :
В tcp_active_pcbs хранится указатель на цепочку активных соединений.
Далее если не нашли в tcp_active_pcbs ищем в tcp_tw_pcbs и если находим вызываем tcp_timewait_input и выходим.
И наконец остается только вариант одного из активных соединений. Тут мы вызываем tcp_process и получаем данные (флаг PSH).
Цепочка прослушиваемых портов
Вот в какие состояния переходят в процессе обмена TCP пакетами сервер и клиент:
Клиент передает первый пакет SYN. В пакете клиента Seq установлен в конкретное значение. Ack не становлен (то просто 0).
Все далее со вторым пакетом мы в tcp_listen_input не попадем, а попадем уже в tcp_process для обработки пакета в уже созданном активном соединении.
Цепочка активных соединений
В этих передачах соблюдется особый алгоритм контроля через поля Seq и Ack. Эта технология защищает от путаницы пакетов, первый пришел позже второго и т.д.
Закрытие соединения
После того как клиент запросил данные у HTTP сервера и сервер отдал контент запрашиваемой страницы, клиент посылает команду закрытия соединения с флагом FIN, ACK и сервер отвечает ACK и закрывает соединение со свой стороны. Тут тоже задействован механихм Seq/Ack:
Теперь осталось разобрать только состояние TIME-WAIT соединения.
Цепочка TIME-WAIT соединений
Таймер для соединения TIME_WAIT устанавливается в 1 — 2 минуты. После чего соединение должно быть уничтожено (у сервера). На картинке ниже Хост 1 это наш сервер.
Кстати в нашем случае у нас соединение закрывает клиент и поэтому механизм TIME_WAIT (у сервера) не используется.
Небольшие выводы
Не надо путать Seq клиента и Seq сервера. И не надо путать Ack клиента и Ack сервера.
Файлы для скачивания
Внутренние механизмы ТСР, влияющие на скорость загрузки: часть 1
Ускорение каких-либо процессов невозможно без детального представления их внутреннего устройства. Ускорение интернета невозможно без понимания (и соответствующей настройки) основополагающих протоколов — IP и TCP. Давайте разбираться с особенностями протоколов, влияющих на скорость интернета.
IP (Internet Protocol) обеспечивает маршрутизацию между хостами и адресацию. TCP (Transmission Control Protocol) обеспечивает абстракцию, в которой сеть надежно работает по ненадежному по своей сути каналу.
Протоколы TCP/IP были предложены Винтом Серфом и Бобом Каном в статье «Протокол связи для сети на основе пакетов», опубликованной в 1974 году. Исходное предложение, зарегистрированное как RFC 675, было несколько раз отредактировано и в 1981 году 4-я версия спецификации TCP/IP была опубликована как два разных RFC:
TCP обеспечивает нужную абстракцию сетевых соединений, чтобы приложениям не пришлось решать различные связанные с этим задачи, такие как: повторная передача потерянных данных, доставка данных в определенном порядке, целостность данных и тому подобное. Когда вы работаете с потоком TCP, вы знаете, что отправленные байты будут идентичны полученным, и что они придут в одинаковом порядке. Можно сказать, что TCP больше «заточен» на корректность доставки данных, а не на скорость. Этот факт создает ряд проблем, когда дело доходит до оптимизации производительности сайтов.
Стандарт НТТР не требует использования именно TCP как транспортного протокола. Если мы захотим, мы можем передавать НТТР через датаграммный сокет (UDP – User Datagram Protocol) или через любой другой. Но на практике весь НТТР трафик передается через TCP, благодаря удобству последнего.
Поэтому необходимо понимать некоторые внутренние механизмы TCP, чтобы оптимизировать сайты. Скорее всего, вы не будете работать с сокетами TCP напрямую в своем приложении, но некоторые ваши решения в части проектирования приложения будут диктовать производительность TCP, через который будет работать ваше приложение.
Тройное рукопожатие
Все TCP-соединения начинаются с тройного рукопожатия (рис. 1). До того как клиент и сервер могут обменяться любыми данными приложения, они должны «договориться» о начальном числе последовательности пакетов, а также о ряде других переменных, связанных с этим соединением. Числа последовательностей выбираются случайно на обоих сторонах ради безопасности.
Клиент выбирает случайное число Х и отправляет SYN-пакет, который может также содержать дополнительные флаги TCP и значения опций.
SYN ACK
Сервер выбирает свое собственное случайное число Y, прибавляет 1 к значению Х, добавляет свои флаги и опции и отправляет ответ.
Клиент прибавляет 1 к значениям Х и Y и завершает хэндшейк, отправляя АСК-пакет.
Рис. 1. Тройное рукопожатие.
После того как хэндшейк совершен, может быть начат обмен данными. Клиент может отправить пакет данных сразу после АСК-пакета, сервер должен дождаться АСК-пакета, чтобы начать отправлять данные. Этот процесс происходит при каждом TCP-соединении и представляет серьезную сложность плане производительности сайтов. Ведь каждое новое соединение означает некоторую сетевую задержку.
Например, если клиент в Нью-Йорке, сервер – в Лондоне, и мы создаем новое TCP-соединение, это займет 56 миллисекунд. 28 миллисекунд, чтобы пакет прошел в одном направлении и столько же, чтобы вернуться в Нью-Йорк. Ширина канала не играет здесь никакой роли. Создание TCP-соединений оказывается «дорогим удовольствием», поэтому повторное использование соединений является важной возможностью оптимизации любых приложений, работающих по TCP.
TCP Fast Open (TFO)
Загрузка страницы может означать скачивание сотен ее составляющих с разных хостов. Это может потребовать создания браузером десятков новых TCP-соединений, каждое из которых будет давать задержку из-за хэндшейка. Стоит ли говорить, что это может ухудшить скорость загрузки такой страницы, особенно для мобильных пользователей.
TCP Fast Open (TFO) – это механизм, который позволяет снизить задержку за счет того, что позволяет отправку данных внутри SYN-пакета. Однако и у него есть свои ограничения: в частности, на максимальный размер данных внутри SYN-пакета. Кроме того, только некоторые типы HTTP-запросов могут использовать TFO, и это работает только для повторных соединений, поскольку использует cookie-файл.
Использование TFO требует явной поддержки этого механизма на клиенте, сервере и в приложении. Это работает на сервере с ядром Linux версии 3.7 и выше и с совместимым клиентом (Linux, iOS9 и выше, OSX 10.11 и выше), а также потребуется включить соответствующие флаги сокетов внутри приложения.
Специалисты компании Google определили, что TFO может снизить сетевую задержку при HTTP-запросах на 15%, ускорить загрузку страниц на 10% в среднем и в отдельных случаях – до 40%.
Контроль за перегрузкой
В начале 1984 года Джон Нейгл описал состояние сети, названное им как «коллапс перегрузки», которое может сформироваться в любой сети, где ширина каналов между узлами неодинакова.
Когда круговая задержка (время прохождения пакетов «туда-обратно») превосходит максимальный интервал повторной передачи, хосты начинают отправлять копии одних и тех же датаграмм в сеть. Это приведет к тому, что буферы будут забиты и пакеты будут теряться. В итоге хосты будут слать пакеты по нескольку раз, и спустя несколько попыток пакеты будут достигать цели. Это называется «коллапсом перегрузки».
Нейгл показал, что коллапс перегрузки не представлял в то время проблемы для ARPANETN, поскольку у узлов была одинаковая ширина каналов, а у бэкбона (высокоскоростной магистрали) была избыточная пропускная способность. Однако это уже давно не так в современном интернете. Еще в 1986 году, когда число узлов в сети превысило 5000, произошла серия коллапсов перегрузки. В некоторых случаях это привело к тому, что скорость работы сети падала в 1000 раз, что означало фактическую неработоспособность.
Чтобы справиться с этой проблемой, в TCP были применены несколько механизмов: контроль потока, контроль перегрузки, предотвращение перегрузки. Они определяли скорость, с которой данные могут передаваться в обоих направлениях.
Контроль потока
Контроль потока предотвращает отправку слишком большого количества данных получателю, которые он не сможет обработать. Чтобы этого не происходило, каждая сторона TCP-соединения сообщает размер доступного места в буфере для поступающих данных. Этот параметр — «окно приема» (receive window – rwnd).
Когда устанавливается соединение, обе стороны задают свои значения rwn на основании своих системных значений по умолчанию. Открытие типичной страницы в интернете будет означать отправку большого количества данных от сервера клиенту, таким образом, окно приема клиента будет главным ограничителем. Однако, если клиент отправляет много данных на сервер, например, загружая туда видео, тогда ограничивающим фактором будет окно приема сервера.
Если по каким-то причинам одна сторона не может справиться с поступающим потоком данных, она должна сообщить уменьшенное значение своего окна приема. Если окно приема достигает значения 0, это служит сигналом отправителю, что не нужно более отправлять данные, пока буфер получателя не будет очищен на уровне приложения. Эта последовательность повторяется постоянно в каждом TCP-соединении: каждый АСК-пакет несет в себе свежее значение rwnd для обеих сторон, позволяя им динамически корректировать скорость потока данных в соответствии с возможностями получателя и отправителя.
Рис. 2. Передача значения окна приема.
Масштабирование окна (RFC 1323)
Исходная спецификация TCP ограничивала 16-ю битами размер передаваемого значения окна приема. Это серьезно ограничило его сверху, поскольку окно приема не могло быть более 2^16 или 65 535 байт. Оказалось, что это зачастую недостаточно для оптимальной производительности, особенно в сетях с большим «произведением ширины канала на задержку» (BDP – bandwidth-delay product).
Чтобы справиться с этой проблемой в RFC 1323 была введена опция масштабирования TCP-окна, которая позволяла увеличить размер окна приема с 65 535 байт до 1 гигабайта. Параметр масштабирования окна передается при тройном рукопожатии и представляет количество бит для сдвига влево 16-битного размера окна приема в следующих АСК-пакетах.
Сегодня масштабирование окна приема включено по умолчанию на всех основных платформах. Однако промежуточные узлы, роутеры и сетевые экраны могут переписать или даже удалить этот параметр. Если ваше соединение не может полностью использовать весь канал, нужно начать с проверки значений окон приема. На платформе Linux опцию масштабирования окна можно проверить и установить так:
В следующей части мы разберемся, что такое TCP Slow Start, как оптимизировать скорость передачи данных и увеличить начальное окно, а также соберем все рекомендации по оптимизации TCP/IP стека воедино.
Протокол TCP: что нужно знать специалисту по анализу сетевого трафика!
По нашему опыту, когда дело доходит до низкоуровневого анализа TCP девять из десяти ИТ специалистов в компаниях среднего и крупного бизнеса чувствуют себя неуверенно. Не могут точно сказать, что такое ретрансмиссии, размер окна и т.д. Большинство материалов в интернете по этой теме больше походят на научные работы. В этой статье мы попытаемся донести с практической точки зрения, что же полезного прячет в себе протокол TCP для того, кто занимается анализом сетевого трафика.
В каких случаях нам нужен анализ TCP пакетов?
Как показывает практика, современные системы анализа сетевого трафика имеют большую базу протоколов и готовых шаблонов для программного обеспечения. Это позволяет без труда разбивать транзакции на логические части. К сожалению, далеко не для всех задач бизнеса удаётся найти готовые продукты и в каждой компании обязательно найдётся парочка «самописных» или кастомизированных приложений. Как же анализировать трафик от таких приложений?
База анализатора трафика не имеет информации, в каком бите содержится код реквеста, какой код соответствует респонсу и т.д. В таких ситуациях приходится прибегать к самым азам сетевой науки – TCP анализу. Давайте рассмотрим, что прячет внутри себя этот протокол.
По своей сути TCP является протоколом транспортного уровня. Он позволяет осуществить соединение одного сокета (IP-адрес + порт) хоста источника с сокетом хоста назначения. Заголовок IP будет содержать информацию, связанную с IP-адресами, а заголовок TCP — информацию о порте.
Заголовок TCP
Заголовки TCP перемещаются по сети для установления, поддержки и завершения TCP-соединений, а также передачи данных.
Рисунок 1. Заголовок TCP
В заголовке TCP содержаться следующие поля:
Механизм передачи сообщений TCP
Перед тем, как данные могут быть переданы между двумя узлами, в TCP, в отличие от UDP, предусмотрена стадия установки соединения. Также, после того, как все данные были переданы, наступает стадия завершения соединения. Таким образом, осуществление каждого TCP-соединения можно условно разделить на три фазы:
Установка соединения осуществляется с помощью, так называемого трехстороннего рукопожатия TCP. Инициатором соединения может выступать любая сторона. Однако чтобы упростить рассмотрения данного вопроса в рамках данной статьи, мы рассмотрим пример, когда клиент инициализирует соединение с сервером.
Рисунок 2. Трехстороннее рукопожатие TCP
(Пакет №1). Клиент отправляет пакет с установленным флагом SYN и случайным числом («R1»), включенным в поле порядкового номера (sequence number).
(Пакет №2). При получении пакета №1 сервер в ответ отправляет пакет с установленным флагом SYN, а также с установленным флагом ACK. Поле порядкового номера будет содержать новое случайное число («R2»), а поле номера подтверждения будет содержать значение порядкового номера клиента, увеличенного на единицу (то есть «R1 + 1»). Таким образом, он будет соответствовать следующему порядковому номеру, который сервер ожидает получить от клиента.
(Пакет №3). В ответ на пакет SYN от сервера (пакет №2) клиент отправляет пакет с установленным флагом ACK и полем номера подтверждения с числом «R2 + 1». По аналогии, это число будет соответствовать следующему порядковому номеру, который клиент ожидает получить от сервера.
После инициализации соединения полезная нагрузка будет перемещаться в обоих направлениях TCP-соединения. Все пакеты в обязательном порядке будут содержать установленный флаг ACK. Другие флаги, такие как, например, PSH или URG, могут быть, а могут и не быть установленными.
При нормальном завершении TCP-соединения в большинстве случаев инициализируется процедура, называемая двухсторонним рукопожатием, в ходе которой каждая сторона закрывает свой конец виртуального канала и освобождает все задействованные ресурсы. Обычно эта фаза начинается с того, что один из задействованных процессов приложения сигнализирует своему уровню TCP, что сеанс связи больше не нужен. Со стороны этого устройства отправляется сообщение с установленным флагом FIN (отметим, что этот пакет не обязательно должен быть пустым, он также может содержать полезную нагрузку), чтобы сообщить другому устройству о своем желании завершить открытое соединение. Затем получение этого сообщения подтверждается (сообщение от отвечающего устройства с установленным флагом ACK, говорящем о получении сообщения FIN). Когда отвечающее устройство готово, оно также отправляет сообщение с установленным флагом FIN, и, после получения в ответ подтверждающего получение сообщения с установленным флагом ACK или ожидания определенного периода времени, предусмотренного для получения ACK, сеанс полностью закрывается. Состояния, через которые проходят два соединенных устройства во время обычного завершения соединения, отличаются, потому что устройство, инициирующее завершение сеанса, ведет себя несколько иначе, чем устройство, которое получает запрос на завершение. В частности, TCP на устройстве, получающем начальный запрос на завершение, должен сразу информировать об этом процесс своего приложения и дождаться от него сигнала о том, что приложение готово к этой процедуре. Инициирующему устройству не нужно это делать, поскольку именно приложение и выступило инициатором. Более подробно завершении TCP-соединения смотрите здесь (http://www.tcpipguide.com/free/t_TCPConnectionTermination-2.htm).
Рисунок 3. Завершение TCP-соединения
На уровне TCP нет сообщений типа «keep-alive», и поэтому, даже если сеанс соединения в какой-то момент времени становится неактивным, он все равно будет продолжаться до тех пор, пока не будет отправлен следующий пакет.
Когда мы отправляем HTTP-запрос по сети, нам сразу нужно создать TCP-соединение. Однако в HTTP 1.0 возможность повторного использования соединения по умолчанию закрыта (если заголовок «keep-alive = close» дополнительно не включен в заголовок HTTP), то есть TCP-соединение автоматически закрывается после получения запроса и отправки ответа. Так как процесс создания TCP-соединения относительно затратный (он требует дополнительных затрат процессорных ресурсов и памяти, а также увеличивает сетевой обмен между сервером и клиентом, что особенно становится актуальным при создании защищенных соединений), то все это увеличивает количество лагов и повышает вероятность перегрузки сети. Поэтому для HTTP 1.1 было решено оставлять TCP-соединение открытым до тех пор, пока одна из сторон не решит прекратить его.
С другой стороны, если соединения не будут закрываться после того, как клиенты получат все необходимые им данные, задействованные ресурсы сервера для поддержания этих соединений не будут доступны другим клиентам. Поэтому HTTP-серверы, чтобы обеспечить больший контроль над потоком данных, используют временные интервалы (таймауты) для поддержки функциональности «keep-alive» для неактивных соединений (длящихся по умолчанию, в зависимости от архитектуры и конфигурации сервера, не более нескольких десятков секунд, а то и просто нескольких секунд), а также максимальное число отправляемых запросов «keep-alive», прежде чем сеанс без активного соединения будет остановлен. Более подробно о функциональности «keep-alive» вы можете узнать здесь (https://blog.stackpath.com/glossary/keep-alive/).
Подписывайтесь на рассылку, делитесь статьями в соцсетях и задавайте вопросы в комментариях!
How to prepare TCP
Когда кому-то или чему-то становится плохо, то требуется нечто большее, чем просто констатация данного факта.
Первое — это диагностика проблемы, определение причин сбоя.
Взять и измерить давление, сделать пальпацию, проверить уровень масла в двигателе и так далее, и тому подобное.
А что если проблемы возникли при передаче данных в интернет/интранет-сети?
Тут, по-видимому, потребуются особые средства диагностики.
В особенности будут полезны средства, которые позволяют проводить статистический анализ большого количества данных.
Существует множество разных инструментов.
Часть из них можно найти в такой замечательной программе, как Wireshark.
В меню Statistics (Статистика) Wireshark представлен богатый набор функциональности.
При этом результаты могут представляться не только в общем, но и графическом виде.
Как раз о графическом виде и хочется поговорить.
Рассказать о наборе из пяти графиков статистики TCP StreamGraph.
Позволяют легко и эффективно проводить анализ и диагностику TCP-соединений.
Но прежде чем начинать говорить о графиках, для их лучшего понимания рассмотрим основы теории TCP.
Минимум, необходимый для общего понимания TCP StreamGraph
Ниже приведена картинка с частным случаем TCP обмена данных.
Следует рассматривать как упрощенный вариант.
В примере, нумерация сегментов начинается с единицы.
Хотя в действительности это не совсем так.
Однако то же самое показывает и Wireshark при дефолтных настройках.
Отправитель шлет два сегмента (Seq=1 и Seq=6), содержащих по пять байт данных каждый.
Получатель отвечает, что все байты до 10 получены успешно и ожидается следующий 11-й сегмент (Ack=11).
Отправитель передает еще два (Seq=11 и Seq=16), один из которых теряется в сети (Seq=11).
Получатель констатирует, что в потоке принятых данных возник разрыв.
Сообщает, что начиная с первого байта непрерывно приняты только 10 байт и он по-прежнему ждет 11-й сегмент (Ack=11).
Однако одновременно с этим в подтверждающем сегменте указывает SACK (Selective acknowledgment, выборочное подтверждение) блок, с диапазоном байт, полученных после разрыва. Благодаря SACK отправитель повторно передаст только пропавший сегмент (Seq=11). Без SACK потребовалось бы повторять Seq=16 тоже. Использование SACK должно поддерживаться обеими сторонами обмена.
А теперь рассмотрим процесс передачи данных в TCP-соединении через TCP StreamGraph в Wireshark.
Однако, чтобы не описывать графики просто так, сделаю это на простом и понятном примере.
Загружу файл с тестового сервера на свой компьютер, используя протокол HTTP.
Для этого воспользуюсь утилитой curl, а не веб-браузером.
curl поможет создать некоторые проблемы, которые увидим на графиках.
Проблемы возникнут вследствие того, что загрузка будет вестись напрямую в консоль, а не в файл.
Итак, запускаю Wireshark, включаю захват трафика.
Загружаю утилитой curl тестовый файл размером 10Мб с сервера v4.speedtest.reliableservers.com (10MBtest.bin).
Останавливаю захват трафика.
В полученном сетевом дампе Wireshark ищу HTTP пакет с GET запросом файла 10MBtest.bin и определяю номер TCP–соединения, в котором он загружался. Или ищем по фильтру tcp contains «10MBtest.bin».
Фильтрую весь трафик по номеру TCP-соединения в котором загружался тестовый файл tcp.stream==5.
А вот теперь смотрим TCP StreamGraph.
Важно знать, что все графики из TCP StreamGraph строятся по одному TCP соединению и являются направленными.
Направление указывает, в какую сторону двигался анализируемый поток данных от клиента к серверу или наоборот.
Time-Sequence Graph (Stevens)
Time-Sequence Graph (Stevens) выглядит как наклонная кривая, состоящая из точек.
Координаты каждой точки графика — это значение Sequence number TCP сегмента (ось Y — Байты) и время его захвата (ось X — секунды).
Соответственно, как говорилось ранее, учитываются только сегменты с данными одного TCP-соединения, перемещавшиеся в определенном направлении, от серверу к клиенту (загрузка, download) или наоборот (выгрузка, upload).
Согласно теории Sequence number, это номер первого байта данных сегмента в общем потоке данных.
Поэтому можно сказать, что график показывает динамику загрузки/выгрузки байт данных в TCP соединении по времени.
На любом участке легко рассчитывается скорость передачи данных, (Sequence number деленная на Time, получаем Байт/сек).
Как следствие, по изменениям наклона участков кривой можно судить об изменениях скорости передачи данных.
В идеальных условиях график выглядит как диагональная линия с большим углом наклона.
Однако на практике это не всегда так.
По аномалиям на кривой графика можно выявить задержки в передаче данных, потери сегментов и их повторные отправки (Retransmission).
На приведенном ниже примере графика во время загрузки файла возникли две схожие проблемы с остановкой передачи данных и потерей сегментов.
Горячие клавиши в Windows (краткая справка):
Пошаговое увеличение или уменьшение масштаба графика выполняется через клавиши i/o или прямым выделением участка мышью. Возврат к исходному масштабу, клавиша Home.
Пробел — превращает курсор в перекрестие с вертикальной и горизонтальной вспомогательными линиями.
Цифровые клавиши с 1 по 5 — выбор другого графика из набора.
Ctrl + правая кнопка мыши — появляется окно с увеличенным изображением участка графика из под курсора.
Щелчок мышки на любой точке графика приводит к переходу в интерфейсе Wireshark на соответствующий ей TCP пакет.
Time-Sequence Graph (tcptrace)
По внешнему виду Time-Sequence Graph (tcptrace) напоминает предыдущий график и предназначен для более полного анализа возможных проблем. В нем все так же выводятся значения Sequence number сегментов потока данных на временной шкале.
Однако добавился еще один атрибут сегмента — его размер (TCP Segment Len).
Поэтому сегменты отображаются уже не точками, а вертикальными отрезками с засечками на концах, как английская буква I — «ай». Основание отрезка это Sequence number, а длина — размер сегмента в байтах.
Также на графике выводится информация из обратного потока подтверждающих сегментов, Window (Win), Acknowledgment number (Ack) и SACK. Значения Ack отображаются ступенчатой кривой, проходящей ниже сегментов данных.
Каждая ступень, ее вершина — это момент времени прихода подтверждения об общем количестве непрерывно принятых байт получателем.
Аналогично “ступенчато” отображается размер окна принимающей стороны Win.
Кривая проходит выше потока данных.
Вершина ступени — это сумма значений Ack и Win подтверждающего сегмента.
Синими вертикальными линиями визуализируются SACK блоки.
SACK может присутствовать в подтверждении, если в сплошном потоке полученных данных возникли разрывы.
Синяя линия — это диапазон байт полученных после разрыва.
В общем виде график представляет собой “коридор” из двух ступенчатых кривых, внутри которого перемещаются сегменты с данными. Сужение «коридора» говорит об уменьшении размера окна приема (Win), расширение — об обратном.
На предыдущем графике были обнаружены две проблемы с остановкой передачи данных.
Time-Sequence Graph (tcptrace) внес ясность в причины случившегося.
Уменьшился размер окна (Win) на принимающей стороне.
Отправитель передал максимально допустимое количество сегментов с данными, чтобы не переполнить окно, и остановился.
После того, как получатель сообщил об увеличении размера окна (Window Update), передача данных возобновилась.
Throughput Graph
Throughput Graph выглядит как множество точек, иногда расположенных весьма хаотично.
Координаты каждой точки — это расчетная скорость перемещения сегмента в потоке данных (ось Y — Байт/сек) и время его захвата (ось X — секунды).
Если быть точным, для сглаживания колебаний на графике фиксируются не реальные, а усредненные значения скорости.
Используется усредняющая функция скользящего среднего (Moving Average, MA) на 20 значений за предыдущий период.
По коду Wireshark, средняя скорость N-го сегмента равна сумме длин всех сегментов от N до N-20, деленная на дельту по времени между их захватом.
Как следствие, две задержки в передаче данных, вызванные уменьшением размера окна (Win), привели к падению Throughput в проблемные моменты времени. В остальное время скорость закачки варьировалась в пределах диапазона от 1.4 до 3.4 МБайт.
Round Trip Time Graph
Round Trip Time (RTT) — это время, прошедшее между отправкой сегмента с данными и получением подтверждения о его успешной доставке.
Round Trip Time Graph показывает RTT (ось Y — секунды) по каждому сегмента из потока данных.
Идентификатором сегмента выступает его Sequence number (ось X — Байты).
При нормальных условиях большая часть точек концентрируется в нижней части графика.
В примере RTT почти все время не превышает 0.1 сек., за исключением проблемных моментов, когда RTT подскакивала до 0.4 сек.
Все графики связаны между собой формулой Throughput = Window size / RTT
Window Scaling Graph
Координаты каждой точки Window Scaling Graph — это размер окна Windowsize (ось Y — Байты) сегмента на момент времени его захвата (ось X — секунды).
В Window Scaling Graph присутствует информация о двех проблемных случаях сокращения размера окна до критичных размеров.
Это полностью подтверждает показаниями на Time-Sequence Graph.
Заключение
Ну вот, кажется, и все. Что хотел — сказал.
Информации по теме гораздо больше. В статье были изложены только основы, помогающие лучше понять графики из TCP StreamGraph, Wireshark.
Эти графики очень полезны в своем практическом применении и позволяют делать всесторонний обзор любого TCP-соединения, выявлять сетевые проблемы.
Конечно, есть и другие инструменты, подобные TCP StreamGraph, например, tcptrace, captcp.
Не стоит забывать и о IO Graph того же Wireshark. Он обладает более обширной функциональностью выходящей далеко за пределы TCP StreamGraph.
Надеюсь, статья окажется полезна всем тем, кто интересуется сетевыми технологиями или изучает протокол TCP.