UDP против TCP, или Будущее сетевого стека (highload обсуждение)

Дата публикации:

Автор:

Раздел сайта:

Что мы знаем об IP-сетях

  • Мы отправляем пакеты
  • черный ящик их пересылает клиенту
  • клиент собирает пакеты

Внутри черного ящика есть уровни:

UDP против TCP, или Будущее сетевого стека (highload обсуждение)

Давайте сравним TCP и UDP. В них сильно отличается структура пакетов:

UDP против TCP, или Будущее сетевого стека (highload обсуждение)

Главное: TCP задуман как протокол надёжной доставки данных, а UDP — нет. Может ли оказаться, что UDP лучше решит задачу надёжной доставки?

Цели на сегодня

  • Как работает сеть
  • Зачем сравнивать TCP или что с ним не так
  • С чем и на чём сравнивать TCP
  • Как это сделал Google
  • Какое будущее сетевых протоколов нас ждёт

Теорию и математику обсуждать не будем. Будем разбирать практические кейсы.

Мобильный мир победил

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

В беспроводных сетях бывают потери пакетов, смена порядка и jitter. Протокол TCP/IP скрывает от нас эти ошибки.

UDP против TCP, или Будущее сетевого стека (highload обсуждение)

Вот средние параметры соединения у пользователей мобильного интернета.

UDP против TCP, или Будущее сетевого стека (highload обсуждение)

Итоги:

  • > 80% используют беспроводной интернет
  • парметры беспроводных сетей постоянно меняются
  • в них высокие показатели packet loss, jitter, reordering
  • фиксированный асимметричный канал, возможна смена IP-адреса

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

Получается, что TCP не очень эффективен для доставки контента.

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

Ошибки уменьшают утилизацию канала, а распараллеливание при ошибках помогает увеличить утилизацию:

UDP против TCP, или Будущее сетевого стека (highload обсуждение)

Почему нам не подходит TCP

Итого: зачем же нужно сравнивать ТCP?

  • беспроводные сети победили и они нестабильны
  • потребление контента зависит от скорости интернета (а мы хотим, чтобы пользователи потребляли больше)
  • TCP плохо утилизирует канл на нестабильных сетях. Распараллеливание помогает, но не всё можно распараллелить.

Что с этим делать?

  • Можно сделать свой протокол рядом с TCP и UDP. И годами ждать, пока его поддержат все участники интернетов.
  • Или сделать свой надёжный протокол поверх UDP в User Space.

получаем smUDP: self-made UDP

У разного контента разные профили потребления сети.

UDP против TCP, или Будущее сетевого стека (highload обсуждение)

HTTP 1.1 и HTTP/2

Конечно же мы должны сравнить протоколы на HTTP 1.1 и HTTP/2.

HTTP 1.1 предлагает использовать по одному соединению на каждую единицу контента. HTTP/2 — одно мультиплексированное соединение.

UDP против TCP, или Будущее сетевого стека (highload обсуждение)

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

UDP против TCP, или Будущее сетевого стека (highload обсуждение)

HTTP/2 лучше:

  • бинарный, со сжатием заголовков;
  • есть мультиплексирование,
  • приоритизация,
  • отмена загрузки,
  • и server push.

Приоритизация позволяет получить приоритетный контент раньше:

UDP против TCP, или Будущее сетевого стека (highload обсуждение)

Server push: сервер может отдать контент, который точно понадобится в будущем.

UDP против TCP, или Будущее сетевого стека (highload обсуждение)

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

UDP против TCP, или Будущее сетевого стека (highload обсуждение)

Сравниваем TCP и smUDP

Итого, на чём нам сравнивать TCP и smUDP

  • Профили сети: WiFi, 3G, LTE
  • Профили потребления:
    • стриминг
    • мультиплексирвоание и приоритизация с отменой загрузки (в HTTP/2)

Простая сеть: bandwidth + RTT

В TCP важен размер буфера отправки. Сервер держит контент в буфере, пока не получит подтверждение (acknowledgement), что контент получен. Но чем больше RTT, тем дольше ждать подтверждения.

UDP против TCP, или Будущее сетевого стека (highload обсуждение)

Если мы увеличим размер буфера, то фактическая ширина канала вырастет.

UDP против TCP, или Будущее сетевого стека (highload обсуждение)

Но всё не так просто. Важны on-the-fly packets. Это те, которые мы отправили, но ещё не получили подтверждения. Если буфер слишком мал, то мы недоиспользуем сеть, как мы уже поняли. Но если буфер слишком большой, то мы приходим к распуханию буфера (bufferbloat). Буфер заполнен кучей on-the-fly пакетов, а скорость снова маленькая.

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

А если у нас свой протокол, то мы можем:

  • уменьшать буфер
  • раньше отправлять более важные пакеты
  • если клиент отправил cancellation, сбросить пакеты из буфера

UDP против TCP, или Будущее сетевого стека (highload обсуждение)

Как это делается? Присваиваем отправляемым пакетам сквозной sequence number.

Итак:

  • размер буфера имеет значение
  • mutable buffer — это хорошо

Сложная сеть: bandwidth + RTT + packet loss

Стандартный алгоритм: если за установленное время сервер не получил acknowledgement, он повторно посылает пакет. Давайте снова будем терять пакеты.

Разберёмся, как работает Congestion Control.

Для начала, TCP window: количество одновременно отправляемых пакетов. Отправитель начинает с 10 и разгоняется, увеличивая количество. Если в какой-то момент пакеты теряются, он уменьшает окно и снова разгоняется.

UDP против TCP, или Будущее сетевого стека (highload обсуждение)

Congestion Control придуман для предотвращения перегрузки сети. Вот где-то в сети есть роутер, который больше всего нагружен. Он умный: не ждёт когда совсем перегрузится, а начинает дропать пакеты чуть раньше, чтобы отправитель уменьшил окно.

UDP против TCP, или Будущее сетевого стека (highload обсуждение)

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

Получается, есть два типа потерь:

  • congestion loss, от переполнения
  • random loss, от плохого беспроводного соединения

Каким бывает Congestion Control

Congestion Control эволюционирует. Нам особенно интересны реализации Cubic и BBR.

UDP против TCP, или Будущее сетевого стека (highload обсуждение)

Если скорсть растёт, BBR схлопывает окно заранее, Cubic дожидается потери пакетов и тогда схлопывает окно.

UDP против TCP, или Будущее сетевого стека (highload обсуждение)

Работают они так:

  • BBR прощупывает размер окна и поддерживает его. За счёт этого получается минимальная задержка. BBR различает congestion loss и random loss.
  • Cubic работает агрессивно: переполняет буфер до потери пакетов, сбрасывает скорость, потом снова постепенно повышает.

Совсем сложная сеть: bandwidth + RTT + packet loss + jitter

Казалось бы, BBR решит все наши проблемы. Но есть ещё и jitter! Он влияет в том числе на получение acknowledgements от получателя. То есть в некоторых случаях пакет доставляется успешно, но отправитель не успевает получить подтверждение и шлёт пакет снова. BBR уязвим к высокому jitter.

Было бы здорово, если бы сервер мог знать jitter клиента. Но в стандартном пакете acknowledgement (ACK Frame) в TCP этой информации нет. Зато мы можем добавить её в smUDP ACK Frame.

UDP против TCP, или Будущее сетевого стека (highload обсуждение)

Мобильные сети асимметричны. Обычно 70% на приём и 30% на отправку. Стоит разделить jitter на приём и отправку.

Какой congestion control выбрать на сервере?

UDP против TCP, или Будущее сетевого стека (highload обсуждение)

А на клиенте всегда Cubic и мы не можем на это повлиять.

Выводы такие:

UDP против TCP, или Будущее сетевого стека (highload обсуждение)

РЕКОМЕНДУЕМ

Файл .htaccess подробное описание, где находится, настройка и оптимизация

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

Убираем показ ошибок на сайте при режиме работы Nginx и PHP-FPM

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

5 лучших плагинов для перевода сайта на WordPress, сравнение и описание

Если вы хотите создать многоязычный сайт WordPress, вам понадобится плагин для перевода WordPress. Но выбор правильного многоязычного плагина WordPress - это важное решение, так как...

Новая сборка OKWP WordPress 1.9.4 для информационных сайтов

Много прошло времени, с момента последнего выхода сборки OkWP Wordpress. За это время я перебрал несколько вариантов сборки, что то добавлялось, что убирал. На...

MyISAM против Innodb MySQL Engine для WordPress что лучше и конвертация таблиц базы данных

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

Эффективные SEO-метрики для отслеживания вовлеченности и эффективности контента

Отслеживание эффективности контента связано с изучением метрики вовлечённости , который раскрывает основные проблемы, связанные с контентом. SEO является ключевым компонентом успеха онлайн-бизнеса. Таким образом,...

UDP против TCP, или Будущее сетевого стека (highload обсуждение)

Что мы знаем об IP-сетях Мы отправляем пакеты черный ящик их пересылает клиенту клиент собирает пакеты Внутри черного ящика есть уровни: Давайте сравним TCP и UDP....

Что такое HTTP/3 – описание и возможности нового протокола на основе UDP

В ноябре 2018 года в Бангкоке состоялась встреча Инженерной рабочей группы по Интернету (IETF), и был принят новый проект Интернет . Транспортный протокол QUIC, преемник HTTP/2 , был переименован в HTTP/3. HTTP/3 основан...
UDP против TCP, или Будущее сетевого стека (highload обсуждение)
Alecs Retin
Работаю в сфере web с 2009 года. Занимался созданием своих проектов в разных тематиках. В основном делаю сайты на Instantcms и Wordpress. Оказываю услуги разработки сайтов и стартапов, инвестирую в интернет проекты и сервисы. Более 10 лет занимаюсь Web разработкой и создание интернет проектов. Интернет магазины, информационные порталы, городские порталы. Оказываю поддержку в развитии и продвижении сайтов.

ПОХОЖИЕ МАТЕРИАЛЫ

Файл .htaccess подробное описание, где находится, настройка и оптимизация

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

Убираем показ ошибок на сайте при режиме работы Nginx и PHP-FPM

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

5 лучших плагинов для перевода сайта на WordPress, сравнение и описание

Если вы хотите создать многоязычный сайт WordPress, вам понадобится плагин для перевода WordPress. Но выбор правильного многоязычного плагина WordPress - это важное решение, так как...

Новая сборка OKWP WordPress 1.9.4 для информационных сайтов

Много прошло времени, с момента последнего выхода сборки OkWP Wordpress. За это время я перебрал несколько вариантов сборки, что то добавлялось, что убирал. На...

MyISAM против Innodb MySQL Engine для WordPress что лучше и конвертация таблиц базы данных

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

Эффективные SEO-метрики для отслеживания вовлеченности и эффективности контента

Отслеживание эффективности контента связано с изучением метрики вовлечённости , который раскрывает основные проблемы, связанные с контентом. SEO является ключевым компонентом успеха онлайн-бизнеса. Таким образом,...