Низкая задержка: 4 участника самого важного актива вашей сети

Ты водишь? Я делаю… почти каждый день, отвожу своих дочерей в школу и в детский сад. В некоторые дни я могу не торопиться, но в другие дни мы опаздываем, и я бы хотел, чтобы мы могли просто телепортироваться — практически без задержки — в места, где мне нужно их получить.

Но мы не живем в мире «Звездного пути»… по крайней мере, пока… насколько я знаю.

Каждое утро я должен сесть в машину с девочками и отправиться в путь. Есть несколько разных дорог, по которым мне приходится ехать от дома до школы моей старшей дочери.

Есть проселочные дороги, главные дороги, шоссе, переулки –

Все виды дорог!

Это заставляет меня думать о сети.

У вас есть локальные сети, глобальные сети, городские сети, домашние сети, сети общего пользования…

Это продолжается и продолжается!

Точно так же, как сеть важна для приложений, работающих поверх нее, дороги очень важны для таких людей, как вы и я, которые ездят по ним.

Самое важное для меня на этих дорогах — это то, насколько быстро я смогу безопасно проехать по этим дорогам, чтобы доставить своих дочерей туда, где они должны быть. Иметь дороги, которые могут доставить вас туда, где вам нужно, как можно быстрее и безопаснее — это большое преимущество.

Я считаю, что самым важным активом сети является то же самое.

Как быстро пакеты могут передаваться по сети из одного места в другое?

Для этого сеть должна иметь низкую задержку. Пакеты должны быть быстро обработаны, поставлены в очередь, сериализованы и распространены по сети, чтобы достичь этого.

Есть четыре компонента, которые способствуют задержке сети. Но давайте сначала немного поговорим о задержке…

Задержка Heeere!

Таким образом, сетевая задержка — это время, которое требуется пакетам для прохождения от одного конца сети по всем путям до другого конца.

Эти пакеты проходят через множество различных устройств в разных частях сети, точно так же, как каждое утро я прохожу через множество уличных фонарей и знаков на разных дорогах, доставляя своих детей туда, где они должны быть.

В идеале вы хотите, чтобы сетевая задержка была как можно ближе к нулю.

Но, как я уже говорил ранее, если вы не знаете чего-то, чего не знаю я, телепортации из «Звездного пути» пока нет (хотя я читал, что IBM и другие работают над этим с помощью квантовой телепортации).

Интересный материал!

Хорошо. Таким образом, задержка не будет близкой к нулю, если только другой конец сети не находится рядом с пользователем, или если вы не читаете это через столетия и не используете квантовую телепортацию.

Таким образом, из-за отсутствия телепортации доставка моих дочерей туда, где они должны быть, займет некоторое время, точно так же, как потребуется некоторое время для передачи пакетов по сети.

Сколько времени зависит от четырех основных компонентов задержки задержки.

#1: Обработка

Первым из этих компонентов является задержка обработки.

Эта форма задержки представляет собой время, необходимое устройству в вашей сети для обработки пакета, пришедшего на один из его интерфейсов. Устройство — будь то маршрутизатор или коммутатор — должно определить на основе заголовков пакетов, куда идут данные и как доставить их к следующей остановке, перемещая пакет ближе к месту назначения.

Когда я везу своих дочерей утром, мне нужно выехать на шоссе. На дорогах, по которым я выезжаю на шоссе, есть несколько уличных знаков и фонарей, которые помогают мне понять, куда мне нужно направить машину, чтобы добраться до шоссе и, в конечном итоге, до места назначения.

Некоторые знаки просты, но другие могут быть немного сложными.

Чем больше времени мне требуется, чтобы обработать знаки, тем больше времени мне требуется, чтобы добраться до следующей дороги на пути к месту назначения моих детей.

Ваши сетевые устройства должны иметь необходимые ресурсы для максимально быстрой обработки пакетов, чтобы доставить их на следующую остановку. Аппаратное и программное обеспечение не должно быть узким местом для ваших маршрутизаторов и коммутаторов.

# 2: Очередь

Следующим ключевым компонентом задержки является задержка в очереди.

Эта форма задержки представляет собой время, в течение которого пакет ожидает в очереди сетевого устройства на сетевом пути, прежде чем его можно будет передать.

В вашей сети, скорее всего, происходит много всего: отправляются электронные письма, загружаются файлы или просматриваются веб-сайты. Все это может генерировать большой сетевой трафик и, следовательно, большое количество пакетов.

Чтобы избежать перегрузки в сети, каждый пакет не может быть отправлен одновременно. В противном случае у вас также будет много потерянных пакетов в вашей сети.

А этого никто не хочет!

Таким образом, сетевые устройства должны поставить их в очередь, прежде чем они смогут работать. Это делается с помощью алгоритмов очередей.

В сетевых устройствах используются два распространенных типа алгоритмов: «первым пришел – первым обслужен» (FIFO) и равноправная организация очередей. Я не буду вдаваться в подробности этих алгоритмов, но время, которое пакеты проводят в очереди устройства с использованием любого алгоритма организации очереди, увеличивает сквозную задержку, с которой сталкивается приложение.

Таким образом, способ уменьшить этот вклад в задержку — использовать более быстрые и эффективные алгоритмы организации очередей для вашей сети.

№ 3: Трансмиссия

Следующим компонентом задержки является задержка сериализации.

Эта задержка также известна как задержка передачи, потому что это время, необходимое для помещения битов данных в канал сети, чтобы их можно было передать.

Именно здесь для приложения важна пропускная способность сетевого канала. Скорость вашего канала определяет, насколько быстро биты сетевого пакета могут быть помещены в канал.

Допустим, у вас есть соединение T3 WAN со скоростью около 45 Мбит/с. И у вас есть приложение, которое должно отправить пользователю файл размером 1 МБ.

Давайте посчитаем

Файл размером 1 МБ будет отправлен по сети в виде потока примерно из 667 пакетов, каждый из которых будет иметь размер около 1500 байт.

Теперь у вас есть 667 пакетов, которые необходимо передать по этому каналу на 45 Мбит/с.

Ожидается, что для передачи каждого пакета по каналу потребуется около 0,27 миллисекунды. И это без учета каких-либо предыдущих факторов задержки.

Таким образом, всего 1 МБ данных приложения будет помещено в ссылку за 0,18 секунды.

Это может показаться немного, но если учесть, что все больше и больше пользователей ожидают, что приложения будут отвечать в течение 1 или 2 секунд, 0,18 секунды могут составлять почти 20% этого времени. Этот пост от поставщика APM Dynatrace обсуждает это.

Как вы можете уменьшить это?

Как вы, вероятно, можете видеть из этого примера, два лучших способа уменьшить задержку сериализации — это отправлять меньше данных или увеличивать пропускную способность вашей сети.

Я бы порекомендовал сделать комбинацию обоих, если это возможно. Но если бы вы могли сделать только один, отправьте меньше данных. Это может означать изменения в приложениях, которые используются в сети, или использование различных механизмов кэширования.

# 4: Распространение

Последним и, безусловно, не менее важным фактором задержки является задержка распространения.

Из всех четырех факторов, влияющих на задержку, это единственный, который нельзя уменьшить напрямую.

Задержка распространения — это время, которое требуется битам данных для перемещения с одной стороны сети на другую. Это просто результат расстояния между клиентом и сервером.

Если у вас есть сервер в Нью-Йорке в США и пользователь в Хайдарабаде, Индия, вы ничего не можете сделать, чтобы уменьшить расстояние между ними. У нас есть эти неприятности, называемые океанами и континентами, которые мешают. Так что это усложняет их сближение.

В отличие от других участников, мы не можем напрямую сократить расстояние с помощью более совершенных технологий. И «непосредственно» здесь ключевое слово.

Распространение пакетов

Задержка распространения от Нью-Йорка до Хайдарабада зависит от расстояния между восточным побережьем США и Индией. Более совершенные технологии не сделают две страны физически ближе друг к другу.

При скорости света в вакууме около 186 000 миль в секунду — или 300 000 км в секунду — свету потребуется примерно 10 миллисекунд, чтобы пройти 1000 миль и обратно. Это теоретическое значение только для задержки распространения! Он не учитывает другие формы задержки или что-либо еще, что может замедлить сетевой пакет от клиента к серверу.

Таким образом, если в Хайдарабаде есть пользователь, использующий приложение на сервере, расположенном в Нью-Йорке, который находится примерно в 8 047 милях (12 950 км), ожидается, что задержка распространения составит около 81 миллисекунды для перехода от одной стороны к другой. и назад.

И это в лучшем случае, потому что сетевые пути редко бывают прямыми. Вы только посмотрите на эту карту подводных кабелей.

Сколько прямых путей вы видите?

Таким образом, хотя вы не можете напрямую уменьшить задержку распространения, вы можете сделать что-то косвенно.

Вы можете использовать сети доставки контента (CDN) таких компаний, как Akamai, Amazon, Cloudflare и многих других. Вы также можете использовать устройства оптимизации WAN, чтобы уменьшить объем данных, передаваемых на это расстояние, или отказаться от отправки всех данных, поскольку они были кэшированы.

Или вы можете просто перенести сервер из Нью-Йорка и поставить его в Индию. Перемещение самого сервера ближе к пользователям всегда возможно. Это может быть не самый экономичный или экономичный вариант, но всегда следует учитывать этот вариант.

Подводя итог всему!

Так что независимо от того, управляете ли вы всей сетью или администрируете ее часть, я всегда говорю, что ее самым большим преимуществом является низкая задержка.

Вы должны проанализировать свою сеть, чтобы убедиться, что вы оптимизируете четыре фактора задержки:

• Вы должны убедиться, что обработка не является узким местом ни на одном из ваших сетевых устройств, чтобы вы могли максимально снизить задержку обработки.
• Убедитесь, что вы используете наиболее оптимальный алгоритм организации очереди, который подходит для вашей сети и работающих в ней устройств, чтобы задержка очереди не замедляла работу сетевых приложений.
• Убедитесь, что у вас есть соответствующий уровень пропускной способности в вашей сети, в которой работают приложения, чтобы задержка сериализации была максимально быстрой.
• Убедитесь, что расстояние между клиентом и сервером является оптимальным, чтобы задержка распространения минимально влияла на приложения.

В сети с низкой задержкой по всем направлениям приложения, как правило, будут работать лучше, и вы будете иметь более довольных пользователей.

И меньше звонков в службу поддержки о сбое сети.

Кто этого не хочет?!

==

Фото предоставлено: Флойдиан, Хотроднз, Геральт, Вегпафф и Грег Малкнехт