- PVSM.RU - https://www.pvsm.ru -
Когда кому-то или чему-то становится плохо, то требуется нечто большее, чем просто констатация данного факта.
Первое — это диагностика проблемы, определение причин сбоя.
Взять и измерить давление, сделать пальпацию, проверить уровень масла в двигателе и так далее, и тому подобное.
А что если проблемы возникли при передаче данных в интернет/интранет-сети?
Тут, по-видимому, потребуются особые средства диагностики.
В особенности будут полезны средства, которые позволяют проводить статистический анализ большого количества данных.
Существует множество разных инструментов.
Часть из них можно найти в такой замечательной программе, как Wireshark.
В меню Statistics (Статистика) Wireshark представлен богатый набор функциональности.
При этом результаты могут представляться не только в общем, но и графическом виде.
Как раз о графическом виде и хочется поговорить.
Рассказать о наборе из пяти графиков статистики TCP StreamGraph.
Позволяют легко и эффективно проводить анализ и диагностику TCP-соединений.
Но прежде чем начинать говорить о графиках, для их лучшего понимания рассмотрим основы теории TCP.
Ниже приведена картинка с частным случаем TCP обмена данных.
Следует рассматривать как упрощенный вариант.
В примере, нумерация сегментов начинается с единицы.
Хотя в действительности это не совсем так.
Однако то же самое показывает и Wireshark при дефолтных [9] настройках.
Отправитель шлет два сегмента (Seq=1 и Seq=6), содержащих по пять байт данных каждый.
Получатель отвечает, что все байты до 10 получены успешно и ожидается следующий 11-й сегмент (Ack=11).
Отправитель передает еще два (Seq=11 и Seq=16), один из которых теряется в сети (Seq=11).
Получатель констатирует, что в потоке принятых данных возник разрыв.
Сообщает, что начиная с первого байта непрерывно приняты только 10 байт и он по-прежнему ждет 11-й сегмент (Ack=11).
Однако одновременно с этим в подтверждающем сегменте указывает SACK (Selective acknowledgment [10], выборочное подтверждение) блок, с диапазоном байт, полученных после разрыва. Благодаря SACK отправитель повторно передаст только пропавший сегмент (Seq=11). Без SACK потребовалось бы повторять Seq=16 тоже. Использование SACK должно поддерживаться обеими сторонами обмена.
А теперь рассмотрим процесс передачи данных в TCP-соединении через TCP StreamGraph в Wireshark.
Однако, чтобы не описывать графики просто так, сделаю это на простом и понятном примере.
Загружу файл с тестового сервера на свой компьютер, используя протокол HTTP.
Для этого воспользуюсь утилитой curl, а не веб-браузером.
curl поможет создать некоторые проблемы, которые увидим на графиках.
Проблемы возникнут вследствие того, что загрузка будет вестись напрямую в консоль, а не в файл.
Итак, запускаю Wireshark, включаю захват трафика.
Загружаю утилитой curl тестовый файл размером 10Мб с сервера v4.speedtest.reliableservers.com [11] (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) выглядит как наклонная кривая, состоящая из точек.
Координаты каждой точки графика — это значение 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) напоминает предыдущий график и предназначен для более полного анализа возможных проблем. В нем все так же выводятся значения 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 выглядит как множество точек, иногда расположенных весьма хаотично.
Координаты каждой точки — это расчетная скорость перемещения сегмента в потоке данных (ось Y — Байт/сек) и время его захвата (ось X — секунды).
Если быть точным, для сглаживания колебаний на графике фиксируются не реальные, а усредненные значения скорости.
Используется усредняющая функция скользящего среднего (Moving Average [12], MA) на 20 значений за предыдущий период.
По коду Wireshark, средняя скорость N-го сегмента равна сумме длин всех сегментов от N до N-20, деленная на дельту по времени между их захватом.
Как следствие, две задержки в передаче данных, вызванные уменьшением размера окна (Win), привели к падению Throughput в проблемные моменты времени. В остальное время скорость закачки варьировалась в пределах диапазона от 1.4 до 3.4 МБайт.
Round Trip Time [13] (RTT) — это время, прошедшее между отправкой сегмента с данными и получением подтверждения о его успешной доставке.
Round Trip Time Graph показывает RTT (ось Y — секунды) по каждому сегмента из потока данных.
Идентификатором сегмента выступает его Sequence number (ось X — Байты).
При нормальных условиях большая часть точек концентрируется в нижней части графика.
В примере RTT почти все время не превышает 0.1 сек., за исключением проблемных моментов, когда RTT подскакивала до 0.4 сек.
Все графики связаны между собой формулой Throughput = Window size / RTT
Координаты каждой точки Window Scaling Graph — это размер окна Windowsize (ось Y — Байты) сегмента на момент времени его захвата (ось X — секунды).
В текущем графике направленность изменена на обратную потоку данных (клиент --> сервер). В нем анализируются только подтверждающие сегменты.
В Window Scaling Graph присутствует информация о двех проблемных случаях сокращения размера окна до критичных размеров.
Это полностью подтверждает показаниями на Time-Sequence Graph.
Ну вот, кажется, и все. Что хотел — сказал.
Информации по теме гораздо больше. В статье были изложены только основы, помогающие лучше понять графики из TCP StreamGraph, Wireshark.
Эти графики очень полезны в своем практическом применении и позволяют делать всесторонний обзор любого TCP-соединения, выявлять сетевые проблемы.
Конечно, есть и другие инструменты, подобные TCP StreamGraph, например, tcptrace [14], captcp [15].
Не стоит забывать и о IO Graph [16] того же Wireshark. Он обладает более обширной функциональностью выходящей далеко за пределы TCP StreamGraph.
Надеюсь, статья окажется полезна всем тем, кто интересуется сетевыми технологиями или изучает протокол TCP.
Автор: trusted
Источник [17]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/tcp/85609
Ссылки в тексте:
[1] Transmission Control Protocol: https://ru.wikipedia.org/wiki/TCP
[2] HTTP: https://ru.wikipedia.org/wiki/HTTP
[3] FTP: https://ru.wikipedia.org/wiki/FTP
[4] SMTP: https://ru.wikipedia.org/wiki/SMTP
[5] TELNET: https://ru.wikipedia.org/wiki/Telnet
[6] сегменты: https://ru.wikipedia.org/wiki/TCP#.D0.97.D0.B0.D0.B3.D0.BE.D0.BB.D0.BE.D0.B2.D0.BE.D0.BA_.D1.81.D0.B5.D0.B3.D0.BC.D0.B5.D0.BD.D1.82.D0.B0_TCP
[7] Sequence number: http://packetlife.net/blog/2010/jun/7/understanding-tcp-sequence-acknowledgment-numbers/
[8] Window: http://packetlife.net/blog/2010/aug/4/tcp-windows-and-window-scaling/
[9] дефолтных: https://wiki.wireshark.org/TCP_Relative_Sequence_Numbers
[10] Selective acknowledgment: http://packetlife.net/blog/2010/jun/17/tcp-selective-acknowledgments-sack
[11] v4.speedtest.reliableservers.com: http://v4.speedtest.reliableservers.com
[12] Moving Average: https://ru.wikipedia.org/wiki/%D0%A1%D0%BA%D0%BE%D0%BB%D1%8C%D0%B7%D1%8F%D1%89%D0%B0%D1%8F_%D1%81%D1%80%D0%B5%D0%B4%D0%BD%D1%8F%D1%8F
[13] Round Trip Time: http://en.wikipedia.org/wiki/Round-trip_delay_time
[14] tcptrace: http://www.tcptrace.org
[15] captcp: http://research.protocollabs.com/captcp/index.html
[16] IO Graph: https://www.wireshark.org/docs/wsug_html_chunked/ChStatIOGraphs.html
[17] Источник: http://habrahabr.ru/post/252819/
Нажмите здесь для печати.