Когда кому-то или чему-то становится плохо, то требуется нечто большее, чем просто констатация данного факта.
Первое — это диагностика проблемы, определение причин сбоя.
Взять и измерить давление, сделать пальпацию, проверить уровень масла в двигателе и так далее, и тому подобное.
А что если проблемы возникли при передаче данных в интернет/интранет-сети?
Тут, по-видимому, потребуются особые средства диагностики.
В особенности будут полезны средства, которые позволяют проводить статистический анализ большого количества данных.
Существует множество разных инструментов.
Часть из них можно найти в такой замечательной программе, как Wireshark.
В меню Statistics (Статистика) Wireshark представлен богатый набор функциональности.
При этом результаты могут представляться не только в общем, но и графическом виде.
Как раз о графическом виде и хочется поговорить.
Рассказать о наборе из пяти графиков статистики TCP StreamGraph.
Позволяют легко и эффективно проводить анализ и диагностику TCP-соединений.
Но прежде чем начинать говорить о графиках, для их лучшего понимания рассмотрим основы теории TCP.
Минимум, необходимый для общего понимания TCP StreamGraph
- TCP (Transmission Control Protocol) — протокол транспортного уровня, отвечающий за гарантированную доставку данных от одного узла сети к другому. Поверх TCP работают протоколы прикладного уровня, такие как HTTP, FTP, SMTP, TELNET и другие.
- Гарантированность доставки в TCP достигается за счет использования механизмов подтверждений и повторов.
После передачи порции данных отправитель ждет подтверждения от получателя о доставке. Если подтверждение не приходит, выполняется повторная отправка. - Данные, подлежащие отправке, на уровне TCP представляются потоком байт, где каждый байт последовательно пронумерован. TCP делит поток на части — сегменты — и передает их на более низкий (сетевой) уровень для отправки получателю. В заголовке сегмента указывается его номер (Sequence number, Seq) — номер первого байта сегмента в общем потоке.
- Получатель принимает сегменты и собирает из них исходный непрерывный поток байт, отправляет подтверждения.
В заголовке указывает номер подтверждения (Acknowledgment number, Ack) — порядковый номер следующего сегмента, ожидаемого от отправителя. Значение Ack означает, что вся непрерывная последовательность байт с первого до Ack-1 приняты успешно. Согласно спецификации, подтверждение для каждого сегмента не требуется. Одно подтверждение может отправляться сразу на несколько полученных сегментов. - Получатель не только подтверждает входящие данные, но и управляет интенсивностью их поступления.
В заголовке подтверждения указывается размер окна приема (Window, Win).
Отправитель передает сегменты с данными, объем которых не превышает размера Win.
Если получатель сообщает о нулевом Win, передача данных приостанавливается, пока не будет указан больший размер. - Передаче данных между двумя сетевыми приложениями предшествует установка TCP-соединения.
По завершении обмена соединение закрывается.
Соединение уникально идентифицируется парой значений IP-адреса хоста, номер порта приложения.
Приложение, инициирующее соединение (клиент), каждый раз получает в ОС произвольный номер порта и освобождает его после завершения сеанса передачи данных.
Приложение, ожидающее соединений (сервер), всегда использует постоянный номер порта, пока не завершит свою работу.
Ниже приведена картинка с частным случаем 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).
curl ‘http://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 соединению и являются направленными.
Направление указывает, в какую сторону двигался анализируемый поток данных от клиента к серверу или наоборот.
Направление и соединение определяется по пакету, выбранному в интерфейсе Wireshark.
В случае приведенного выше примера выбираю любой пакет из соединения, в котором загружался тестовый файл 10MBtest.bin.
Направление было от сервера к клиенту, поэтому Source пакета должно соответствовать IP-адресу сервера.
Все графики находятся в Wireshark меню Statistics —> TCP StreamGraph.
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.
ссылка на оригинал статьи http://habrahabr.ru/post/252819/
Добавить комментарий