круговая задержка сети что это
Что такое задержка сети и как ее исправить?
Задержка сети — это время между действием пользователя и полученным ответом. На практике задержка — это время между действием пользователя и ответом веб-сайта, или приложения на это действие, например задержка между переходом пользователя по ссылке на веб-страницу и отображением этой веб-страницы в браузере.
Хотя данные в Интернете распространяются со скоростью света, последствия расстояний и задержек, вызванных оборудованием инфраструктуры интернета, означают, что задержки никогда не могут быть полностью устранены. Однако их можно и нужно свести к минимуму. Большое количество задержек приводит к низкой производительности веб-сайта, негативно влияет на SEO и может побудить пользователей покинуть сайт или приложение в целом.
Что вызывает задержку интернета?
Одной из основных причин задержки сети является расстояние, в частности расстояние между клиентскими устройствами, выполняющими запросы, и серверами, отвечающими на эти запросы. Если веб-сайт размещен в центре обработки данных в Колумбусе, штат Огайо, он будет довольно быстро реагировать на запросы пользователей в Цинциннати (около 100 миль), вероятно, в течение 10-15 миллисекунд. Пользователи в Лос-Анджелесе (около 2200 миль), с другой стороны, столкнутся с более длительными задержками, ближе к 50 миллисекундам.
Увеличение на несколько миллисекунд может показаться не очень большим, но это усугубляется всей обратной связью, необходимой клиенту и серверу для установления соединения, общим размером и временем загрузки страницы, а также любыми проблемами с сетевым оборудованием, через которое проходят данные на этом пути. Время, необходимое для ответа на клиентское устройство после запроса клиента, называется временем приема-передачи (RTT).
Данные, проходящие через интернет, как правило, должны пересекать не одну, а несколько сетей. Чем больше сетей должен пройти HTTP-ответ, тем больше возможностей для задержек. Например, когда пакеты данных пересекают сети, они проходят через точки обмена интернет (IXP). Там маршрутизаторы должны обрабатывать и маршрутизировать пакеты данных, а иногда маршрутизаторам может потребоваться разбить их на более мелкие пакеты, все из которых добавляет несколько миллисекунд к RTT.
Кроме того, способ создания веб-страниц может привести к снижению производительности. Веб-страницы, которые содержат много тяжелого контента или загружают контент от нескольких третьих сторон, могут работать вяло, потому что браузеры должны загружать большие файлы для их отображения. Пользователь может находиться рядом с центром обработки данных, на котором размещен веб-сайт, к которому он обращается, но, если веб-сайт содержит несколько изображений высокой четкости (например), при загрузке изображений может сохраняться некоторая задержка.
Задержка, bandwidth, throughput
Задержка, throughput (характеристика процесса передачи информации) и bandwidth (ширина полосы) взаимосвязаны, и они измеряют разные вещи. Bandwidth — это максимальный объем данных, который может пройти через сеть в любой момент времени. Throughput — это средний объем данных, который фактически проходит через определенный период времени. Throughput не обязательно эквивалентна bandwidth, поскольку на нее влияет задержка. Задержка — это измерение времени, а не объема данных, загружаемых с течением времени.
Как можно уменьшить задержку?
Использование CDN (сети доставки контента) является важным шагом на пути к сокращению задержки. CDN кэширует статическое содержимое, чтобы значительно уменьшить RTT. Серверы CDN распределены в нескольких местах, так что контент хранится ближе к конечным пользователям и не нужно путешествовать так далеко, чтобы добраться до них. Это означает, что загрузка веб-страницы займет меньше времени, улучшая скорость и производительность веб-сайта.
Веб-разработчики также могут минимизировать количество ресурсов, блокирующих рендеринг (например, загрузка JavaScript), оптимизировать изображения для более быстрой загрузки и уменьшить размеры файлов, где это возможно. Минификация кода — это один из способов уменьшения размера файлов JavaScript и CSS.
Возможно, для уменьшения задержки, стратегически загрузки определенных ресурсов. Веб-страницу можно настроить так, чтобы она сначала загружала верхнюю часть, чтобы пользователи могли начать взаимодействовать со страницей еще до ее завершения (над сгибом отображается то, что отображается в окне браузера перед прокруткой вниз). Веб-страницы также могут загружать ресурсы только по мере необходимости, используя метод, известный как отложенная загрузка. Эти подходы на самом деле не улучшают задержку сети, но они улучшают восприятие пользователем скорости страницы.
Как пользователи могут исправить задержку на своей стороне?
Иногда, задержка сети вызвана проблемами на стороне пользователя, а не на стороне сервера. Потребители всегда имеют возможность приобрести больше пропускной способности, если задержка является постоянной проблемой, хотя пропускная способность не является гарантией производительности веб-сайта. Переключение на провод вместо WiFi приведет к более последовательному подключению к интернету и, как правило, улучшает скорость интернета. Пользователи также должны убедиться, что их интернет-оборудование обновлено, регулярно применяя обновления прошивки и заменяя оборудование в целом по мере необходимости.
На видео: Устройство интернет сети за 15 минут.
RFC6349: какие параметры необходимо учитывать при измерении пропускной способности сети?
Каждый из нас задавался вопросом, почему фильм или файл качается со скоростью ниже, чем скорость, заявленная провайдером. Например, скорость 50 Мбит/сек, а скорость в программе для скачивания не более 5-6 Мбит/сек.
Многие приложения работают на основе транспортного протокола TCP, например, HTTP, HTTPS, FTP и т. д. И не многие знают, что на производительность приложения в целом влияет не только канальный (MAC) или сетевой уровень (IP), но и транспортный (TCP или UDP), да и все другие. Так как пользовательский компьютер или сервер могут и умеют тормозить. Для решения этой проблемы и принимая во внимание, что корпоративные приложений практически все работают на основе TCP, в 2010 году собрались представители VIAVI Solutions, Bell Canada и Deutsche Telecom и создали рекомендацию RFC 6349.
В рекомендации RFC6349 описаны параметры, которые влияют на пропускную способность канала связи, как провести необходимые измерения в полевых условиях и интерпретировать результаты:
Опишем каждый из этих этапов более подробно.
Определение MTU по RFC 4821
Протокол TCP использует технологию определения максимального размера полезного блока данных одного пакета (PMTUD) на основе протокола Internet Control Message Protocol (ICMP). Каждый из нас может проверить MTU на пути следования к какому либо ресурсу. Для этого достаточно выполнить Ping с дополнительными параметрами:
Если сетевому устройству необходимо передать пакет без его фрагментации, то в IP заголовке есть специальное поле, которое разрешает или запрещает использовать фрагментацию (DF).
Если на пути следования такого пакета появится маршрутизатор с параметром MTU меньше, чем длина передаваемого нефрагментируемого пакета, то маршрутизатор его отброс ит и должен отправить ICMP сообщение об этом с указанием параметра MTU для повторной передачи и разбиение пакета отправителем до необходимого размера.
Базовая круговая задержка и минимальная пропускная способность
Базовая круговая задержка (baseline round-trip time, RTT) — это время, необходимое для передачи полного TCP сегмента: от первого бита до последнего. Данный параметр измеряется в момент минимальной нагрузки на каналы связи. Если тестирование выполняется в период активной нагрузки, то измерения надо сделать несколько раз и выбрать минимальное время для того чтобы принять его как базовое. Как можно измерить базовую круговую задержку:
Минимальная пропускная способность (bottleneck bandwidth, BB) измеряется в обоих направлениях, особенно если каналы асимметричны и в разные периоды дня, чтобы взять именно минимальное значение. Для этого можно выполнить классический тест в соответствии с RFC2544 или Y.1564.
Далее эти два параметра используются для расчета минимально требуемого размера окна TCP (TCP receive window, RWND) и размера буфера для оптимальной производительности на TCP уровне:
BDP (bits) = RTT (sec) * BB (bps)
Min TCP RWND = BDP(bits) / 8
После определения минимального размера TCP окна мы можем рассчитать пропускную способность на TCP уровне:
TCP Throughput = TCP RWND * 8 / RTT
Например, мы арендуем канал 100 Мбит/сек и круговая задержка составляет 10 мсек, а размер окна настроен на 64 Кбайт, тогда пропускная способность составит:
TCP Throughput = 64000*8/0,01 = 51,2 Мбит/сек
Для того чтобы рассчитать максимально возможную пропускную способность необходимо воспользоваться формулой:
FPS – Frame per second на физическом уровне. Для Ethernet рассчитывается следующим образом:
FPS = (Speed (Mbps) / (1538 Bytes * 8 bits))
Как получается 1538 байта = 1500 (MTU) + 14 (заголовок Ethernet) + 4 (CRC32) + 12 (Inter-Frame Gap) + 7 (преамбула) + 1 ( Start of Frame Delimiter).
Таким образом, для канала 100 Мбит/сек максимальное значение составит:
FPS = (100/ (1538*8)) = 8127 бит/сек
Таким образом, можно сделать вывод, что для увеличения пропускной способности мы можем или сократить круговую задержку или увеличить размер TCP окна, т.е. передать больше данных до получения подтверждения о его доставке. В большинстве случаев размер буфера для отправки данных и окно получения не оптимально настроены на компьютерах и это требует внимания для увеличения производительности именно приложений при передаче по арендуемым вами каналам связи.
Что такое время приема-передачи (RTT)?
Время приема передачи(RTT) — это длительность в миллисекундах (МС), которая требуется для сетевого запроса, чтобы перейти от начальной точки к месту назначения, и обратно к начальной точке. РТТ является важным показателем при определении состояния подключения по локальной сети или интернет, и обычно используется сетевыми администраторами для диагностики скорости и надежности сетевого соединения.
Сокращение RTT является основной целью CDN. Улучшение задержки можно измерить сокращением времени оборота и устранением случаев, когда требуются циклические вызовы, например, путем изменения стандартного подтверждения связи TLS/SSL.
Утилита ping, доступная практически на всех компьютерах, является методом оценки времени в оба конца.
Как работает время приема-передачи?
Время в пути туда и обратно представляет собой время, необходимое данным для перехода в другое место. Например, пользователь в Нью-Йорке хочет связаться с сервером в Сингапуре.
Когда пользователь в Нью-Йорке делает запрос, сетевой трафик передается через много различных маршрутизаторов в различных физических местоположениях, перед завершением на сервере в Сингапуре. Сервер в Сингапуре затем отправляет ответ обратно, через интернет в расположение в Нью-Йорке. После того, как запрос завершается в Нью-Йорке, можно сделать приблизительную оценку количества времени, которое требуется, чтобы пройти путь туда и обратно между двумя местоположениями.
Важно иметь в виду, что время приема-передачи является оценкой, а не гарантией. Путь между этими двумя местоположениями может измениться с течением времени, и другие факторы, такие как перегрузка сети, могут вступить в игру, влияя на общее время транзита. Несмотря на это, RTT является важной метрикой в понимании, может ли соединение быть сделано, и если да, то примерно, сколько времени потребуется, чтобы совершить путь.
Каковы общие факторы, влияющие на RTT
Компоненты инфраструктуры, сетевой трафик и физическое расстояние вдоль пути между источником и назначением являются факторами, которые могут повлиять на RTT.
Список факторов, влияющих на РТТ:
• Природа средств передачи данных – путь, в котором сделаны соединения, влияет на то, как быстро соединение проходит. Подключения по оптическому волокну будет отличаться от подключения по меди. Аналогично, соединение, выполненное по беспроводной частоте, будет вести себя иначе, чем спутниковая связь.
• Трафик локальной сети (LAN) — объем трафика в локальной сети может стать узким местом для соединения до того, как оно достигнет большего интернета. Например, при одновременном использовании многими пользователями сервиса с видео, время приема-передачи может быть ограничено, даже если внешняя сеть имеет избыточную емкость и функционирует нормально.
• Время ответа сервера — время, необходимое серверу для обработки и ответа на запрос, является местом задержки сети. Когда сервер перегружен запросами, например, во время DDoS-атаки, его способность эффективно реагировать может быть заблокирована, что приводит к увеличению RTT.
• Количество узлов и перегрузка — в зависимости от пути, по которому проходит соединение, может быть маршрутизировано или «перескочить» через другое количество промежуточных узлов. Проще говоря, чем больше узлов коснется соединение, тем медленнее оно будет. Узел может также испытать перегрузку сети от другого сетевого трафика, который замедлит соединение и увеличит RTT.
• Физическое расстояние — хотя соединение, оптимизированное CDN, часто может уменьшить количество прыжков, требуемых для достижения пункта назначения, нет никакого способа обойти ограничение, наложенное скоростью света. Расстояние между начальной и конечной точкой является ограничивающим фактором в сетевом подключении, которое может быть уменьшено только путем перемещения контента ближе к запрашивающим пользователям. Чтобы преодолеть это препятствие, CDN кэширует содержимое ближе к запрашивающим пользователям, тем самым уменьшая RTT.
Как CDN может улучшить RTT
Поддерживая серверы внутри точек обмена данными и предпочитая отношения с поставщиками услуг интернета, и другими сетевыми операторами, CDN может оптимизировать сетевые пути между местоположениями, что приводит к снижению RTT и улучшению задержки для посетителей, получающих доступ к содержимому, кэшированному внутри CDN.
На видео: Что такое CDN и как оно работает?
Качество сетей передачи данных. Программные и аппаратные измерения
Я бы хотел опубликовать цикл статей об измерениях характеристик систем связи и сетей передачи данных. Эта статья вводная и в ней будут затронуты лишь самые основы. В дальнейшем планирую более глубокое рассмотрение в стиле «как это сделано».
Покупая продукт или услугу мы часто оперируем таким понятием как качество. Что же такое качество? Если мы обратимся к словарю Ожегова, то там увидим следующее: «совокупность существенных признаков, свойств, особенностей, отличающих предмет или явление от других и придающих ему определенность». Перенося определение на область сетей связи, приходим к выводу, что нам требуется определить «существенные признаки, свойства и особенности», позволяющие однозначно определить отличие одной линии или сети связи от другой. Перечисление всех признаков и свойств обобщаются понятием «метрика». Когда кто-то говорит о метриках сетей связи, он имеет в виду те характеристики и свойства, которые позволят точно судить о системе связи в целом. Потребность в оценке качества лежит большей частью в экономической области, хотя и техническая её часть не менее интересна. Я же попробую балансировать между ними, чтобы раскрыть все самые интересные аспекты этой области знаний.
Всех заинтересовавшихся прошу под кат.
Мониторинг и диагностика систем связи
Как я писал выше, метрики качества определяют экономическую составляющую владения сетью или системой связи. Т.е. стоимость аренды или сдачи в аренду линии связи напрямую зависит от качества этой самой линии связи. Стоимость, в свою очередь, определяется спросом и предложением на рынке. Дальнейшие закономерности описаны у Адама Смита и развиты Милтоном Фридманом. Даже во времена СССР, когда была плановая экономика, а о «рынке» думали, как о преступлении против власти и народа, существовал институт госприемки, как для военных, так и гражданских целей, призванный обеспечить надлежащее качество. Но вернемся в наше время и попробуем определить эти метрики.
Рассмотрим сеть на основе Ethernet, как самой популярной технологии на данный момент. Не будем рассматривать метрики качества среды передачи данных, поскольку они мало интересуют конечного потребителя (разве что материал самой среды иногда бывает интересен: радио, медь или оптика). Самая первая метрика, которая приходит в голову — пропускная способность (bandwidth), т.е. сколько данных мы можем передать в единицу времени. Вторая, связанная с первой,- пакетная пропускная способность (PPS, Packets Per Second), отражающая сколько фреймов может быть передано в единицу времени. Поскольку сетевое оборудование оперирует фреймами, метрика позволяет оценить, справляется ли оборудование с нагрузкой и соответствует ли его производительность заявленной.
Третья метрика — это показатель потери фреймов (frame loss). Если невозможно восстановить фрейм, либо восстановленный фрейм не соответствует контрольной сумме, то принимающая, либо промежуточная система его отвергнет. Здесь имеется ввиду второй уровень системы OSI. Если рассматривать подробнее, то большинство протоколов не гарантируют доставку пакета получателю, их задача лишь переслать данные в нужном направлении, а те кто гарантирует (например, TCP) могут сильно терять в пропускной способности как раз из-за перепосылок фреймов (retransmit), но все они опираются на L2 фреймы, потерю которых учитывает эта метрика.
Четвертая — задержка (delay, latency),- т.е. через сколько пакет отправленный из точки A оказаться в точке B. Из этой характеристики можно выделить еще две: односторонняя задержка (one-trip) и круговая (round-trip). Фишка в том, что путь от A к B может быть один, а от B к A уже совсем другим. Просто поделить время не получится. А еще задержка время от времени может меняться, или “дрожать”,- такая метрика называется джиттером (jitter). Джиттер показывает вариацию задержки относительно соседних фреймов, т.е. девиацию задержки первого пакета относительно второго, или пятого относительно четвертого, с последующим усреднением в заданный период. Однако если требуется анализ общей картины или интересует изменение задержки в течении всего времени теста, а джиттер уже не отражает точно картину, то используется показатель вариации задержки (delay variation). Пятая метрика — минимальный MTU канала. Многие не придают важности этому параметру, что может оказаться критичным при эксплуатации “тяжелых” приложений, где целесообразно использовать jumbo-фреймы. Шестой, и малоочевидный для многих параметр — берстность — нормированная максимальная битовая скорость. По этой метрике можно судить о качестве оборудования, составляющего сеть или систему передачи данных, позволяет судить о размере буфера оборудования и вычислять условия надежности.
Об измерениях
Поскольку с метриками определились, стоит выбрать метод измерения и инструмент.
Задержка
Известный инструмент, поставляемый в большинстве операционных систем — утилита ping (ICMP Echo-Request). Многие ее используют по нескольку раз на дню для проверки доступности узлов, адресов, и т.п. Предназначена как раз для измерения RTT (Round Trip Time). Отправитель формирует запрос и посылает получателю, получатель формирует ответ и посылает отправителю, отправитель замеряя время между запросом и ответом вычисляет время задержки. Все понятно и просто, изобретать ничего не нужно. Есть некоторые вопросы точности и они рассмотрены в следующем разделе.
Но что, если нам надо измерить задержку только в одном направлении? Здесь все сложнее. Дело в том, что помимо просто оценки задержки пригодится синхронизировать время на узле отправителе и узле-получателе. Для этого придуман протокол PTP (Precision Time Protocol, IEEE 1588). Чем он лучше NTP описывать не буду, т.к. все уже расписано здесь, скажу лишь то, что он позволяет синхронизировать время с точностью до наносекунд. В итоге все сводится к ping-like тестированию: отправитель формирует пакет с временной меткой, пакет идет по сети, доходит до получателя, получатель вычисляет разницу между временем в пакете и своим собственным, если время синхронизировано, то вычисляется корректная задержка, если же нет, то измерение ошибочно.
Если накапливать информацию об измерениях, то на основании исторических данных о задержке можно без труда построить график и вычислить джиттер и вариацию задержки — показатель важный в сетях VoIP и IPTV. Важность его связана, прежде всего, с работой энкодера и декодера. При “плавающей” задержке и адаптивном буфере кодека повышается вероятность не успеть восстановить информацию, появляется “звон” в голосе (VoIP) или “перемешивание” кадра (IPTV).
Потери фреймов
Проводя измерения задержки, если ответный пакет не был получен, то предполагается, что пакет был потерян. Так поступает ping. Вроде тоже все просто, но это только на первый взгляд. Как написано выше, в случае с ping отправитель формирует один пакет и отправляет его, а получатель формирует свой собственный о отправляет его в ответ. Т.е. имеем два пакета. В случае потери какой из них потерялся? Это может быть не важно (хотя тоже сомнительно), если у нас прямой маршрут пакетов соответствует обратному, а если это не так? Если это не так, то очень важно понять в каком плече сети проблема. Например, если пакет дошел до получателя, то прямой путь нормально функционирует, если же нет, то стоит начать с диагностики этого участка, а вот если пакет дошел, но не вернулся, то точно не стоит тратить время на траблшутинг исправного прямого сегмента. Помочь в идентификации могла бы порядковая метка, встраиваемая в тестовый пакет. Если на обоих концах стоят однотипные измерители, то каждый из них в любой момент времени знает количество отправленных и полученных им пакетов. Какие именно из пакетов не дошли до получателя можно получить сравнением списка отправленных и полученных пакетов.
Минимальный MTU
Измерение этой характеристики не то чтобы сложно, скорее оно скучно и рутинно. Для определения минимального размера MTU (Maximum transmission unit) следует лишь запускать тест (тот же ping) с различными значениями размеров кадра и установленным битом DF (Don’t Fragmentate), что приведет к непрохождению пакетов с размером кадра больше допустимого, ввиду запрета фрагментации.
Например, так не проходит:
А так уже проходит:
Не часто используемая метрика с коммерческой точки зрения, но актуальная в некоторых случаях. Опять же, стоит отметить, что при асимметричном пути следования пакетов, возможен различный MTU в разных направлениях.
Пропускная способность
Наверняка многим известен факт, что количество переданной полезной информации в единицу времени зависит от размера фрейма. Связано это с тем, что фрейм содержит довольно много служебной информации — заголовков, размер которых не меняется при изменении размера фрейма, а изменяется поле “полезной” части (payload). Это значит, что несмотря на то, что даже если мы передаем данные на скорости линка, количество полезной информации переданной за тот же период времени может сильно варьироваться. Поэтому несмотря на то, что существуют утилиты для измерения пропускной способности канала (например iperf), часто невозможно получить достоверные данные о пропускной способности сети. Все дело в том, что iperf анализирует данные о трафике на основе подсчета той самой «полезной» части, окруженной заголовками протокола (как правило UDP, но возможен и TCP), следовательно нагрузка на сеть (L1,L2) не соответствует подсчитанной (L4). При использовании аппаратных измерителей скорость генерации трафика устанавливается в величинах L1, т.к. иначе было бы не очевидно для пользователя почему при измерении размера кадра меняется и нагрузка, это не так заметно, при задании ее в %% от пропускной способности, но очень бросается в глаза при указании в единицах скорости (Mbps, Gbps). В результатах теста, как правило, указывается скорость для каждого уровня (L1,L2,L3,L4). Например, так (можно переключать L2, L3 в выводе):
Пропускная способность в кадрах в секнду
Если говорить о сети или системе связи как о комплексе линий связи и активного оборудования, обеспечивающего нормальное функционирование, то эффективность работы такой системы зависит от каждого составляющего ее звена. Линии связи должны обеспечивать работу на заявленных скоростях (линейная скорость), а активное оборудование должно успевать обрабатывать всю поступающую информацию.
У всех производителей оборудования заявляется параметр PPS (packets per second), прямо указывающий сколько пакетов способно «переварить» оборудование. Ранее этот параметр был очень важен, поскольку подавляющее число техники просто не могло обработать огромное количество “мелких” пакетов, сейчас же все больше производители заявляют о wirespeed. Например, если передаются малые пакеты, то времени на обработку тратится, как правило, столько же, сколько и на большие. Поскольку содержимое пакета оборудованию не интересно, но важна информация из заголовков — от кого пришло и кому передать.
Сейчас все большее распространение в коммутирующем оборудовании получают ASIC (application-specific integrated circuit) — специально спроектированные для конкретных целей микросхемы, обладающие очень высокой производительностью, в то время как раньше довольно часто использовались FPGA (field-programmable gate array) — подробнее об их применении можно прочитать у моих коллег здесь и послушать здесь.
Бёрстность
Стоит отметить, что ряд производителей экономит на компонентах и использует малые буферы для пакетов. Например заявлена работа на скорости линка (wirespeed), а по факту происходят потери пакетов, связанные с тем, что буфер порта не может вместить в себя больше данных. Т.е. процессор еще не обработал скопившуюся очередь пакетов, а новые продолжают идти. Часто такое поведение может наблюдаться на различных фильтрах или конвертерах интерфейсов. Например предполагается, что фильтр принимает 1Gbps поток и направляет результаты обработки в 100Mbps интерфейс, если известно, что отфильтрованный трафик заведомо меньше 100Mbps. Но в реальной жизни случается так, что в какой-то момент времени может возникнуть «всплеск» трафика более 100Mbps и в этой ситуации пакеты выстраиваются в очередь. Если величина буфера достаточна, то все они уйдут в сеть без потерь, если же нет, то просто потеряются. Чем больше буфер, тем дольше может быть выдержана избыточная нагрузка.