Корзина пуста.
- Новые
- В тренде
Внутри черного ящика есть уровни:
Давайте сравним TCP и UDP. В них сильно отличается структура пакетов:
Главное: TCP задуман как протокол надёжной доставки данных, а UDP — нет. Может ли оказаться, что UDP лучше решит задачу надёжной доставки?
Теорию и математику обсуждать не будем. Будем разбирать практические кейсы.
Важно: сначала появились проводные сети, но беспроводные, которые появились позже, сейчас явно победили. Большая доля трафика — мобильный трафик или хотя бы вайфай.
В беспроводных сетях бывают потери пакетов, смена порядка и jitter. Протокол TCP/IP скрывает от нас эти ошибки.
Вот средние параметры соединения у пользователей мобильного интернета.
Итоги:
Статистика показывает, что потребление мобильного видео зависит от качества канала.
Получается, что TCP не очень эффективен для доставки контента.
Пробовали распараллелить загрузку данных с клиента — использовать несколько одновременных соединений. Получается быстрее.
Ошибки уменьшают утилизацию канала, а распараллеливание при ошибках помогает увеличить утилизацию:
Итого: зачем же нужно сравнивать ТCP?
Что с этим делать?
получаем smUDP: self-made UDP
У разного контента разные профили потребления сети.
Конечно же мы должны сравнить протоколы на HTTP 1.1 и HTTP/2.
HTTP 1.1 предлагает использовать по одному соединению на каждую единицу контента. HTTP/2 — одно мультиплексированное соединение.
При этом в HTTP 1.1 клиент (браузер) обычно использует пул соединений. Проблема в том, что между соединениями есть конкуренция. Картинка, которую пользователь уже пролистал и больше не увидит, конкурирует с другой, которая впереди в ленте. И в HTTP 1.1 сложно отменить загрузку — только закрыть сокет и отменить соединение.
HTTP/2 лучше:
Приоритизация позволяет получить приоритетный контент раньше:
Server push: сервер может отдать контент, который точно понадобится в будущем.
Отмена загрузки: если клиенту уже не понадобится контент, клиент может отказаться от загрузки.
Итого, на чём нам сравнивать TCP и smUDP
В TCP важен размер буфера отправки. Сервер держит контент в буфере, пока не получит подтверждение (acknowledgement), что контент получен. Но чем больше RTT, тем дольше ждать подтверждения.
Если мы увеличим размер буфера, то фактическая ширина канала вырастет.
Но всё не так просто. Важны on-the-fly packets. Это те, которые мы отправили, но ещё не получили подтверждения. Если буфер слишком мал, то мы недоиспользуем сеть, как мы уже поняли. Но если буфер слишком большой, то мы приходим к распуханию буфера (bufferbloat). Буфер заполнен кучей on-the-fly пакетов, а скорость снова маленькая.
Казалось бы, давайте временно увеличивать буфер, когда нам нужно отправить много пакетов. Но буфер нельзя просто так уменьшить.
А если у нас свой протокол, то мы можем:
Как это делается? Присваиваем отправляемым пакетам сквозной sequence number.
Итак:
Стандартный алгоритм: если за установленное время сервер не получил acknowledgement, он повторно посылает пакет. Давайте снова будем терять пакеты.
Разберёмся, как работает Congestion Control.
Для начала, TCP window: количество одновременно отправляемых пакетов. Отправитель начинает с 10 и разгоняется, увеличивая количество. Если в какой-то момент пакеты теряются, он уменьшает окно и снова разгоняется.
Congestion Control придуман для предотвращения перегрузки сети. Вот где-то в сети есть роутер, который больше всего нагружен. Он умный: не ждёт когда совсем перегрузится, а начинает дропать пакеты чуть раньше, чтобы отправитель уменьшил окно.
Вся эта схема придумана давным-давно для проводных сетей. Там потеря пакетов могла означать только одно: где-то перегружен узел, надо снизить скорость. Но в беспроводных сетях не так! Там пакеты теряются просто потому что соединение беспроводное.
Получается, есть два типа потерь:
Congestion Control эволюционирует. Нам особенно интересны реализации Cubic и BBR.
Если скорсть растёт, BBR схлопывает окно заранее, Cubic дожидается потери пакетов и тогда схлопывает окно.
Работают они так:
Казалось бы, BBR решит все наши проблемы. Но есть ещё и jitter! Он влияет в том числе на получение acknowledgements от получателя. То есть в некоторых случаях пакет доставляется успешно, но отправитель не успевает получить подтверждение и шлёт пакет снова. BBR уязвим к высокому jitter.
Было бы здорово, если бы сервер мог знать jitter клиента. Но в стандартном пакете acknowledgement (ACK Frame) в TCP этой информации нет. Зато мы можем добавить её в smUDP ACK Frame.
Мобильные сети асимметричны. Обычно 70% на приём и 30% на отправку. Стоит разделить jitter на приём и отправку.
Какой congestion control выбрать на сервере?
А на клиенте всегда Cubic и мы не можем на это повлиять.
Выводы такие:
Elementor Pro - это новый плагин для создания сайтов для WordPress. Если вы хотите придать своему веб-сайту WordPress и его содержанию индивидуальный дизайн, то инструмент построения страниц часто является наилучшим вариантом. Однако, с таким количеством плагинов для конструктора страниц, доступных для...
Начинаю вести обзоры интересных решений для сайтов на Wordpress. Сегодня в моём обзоре тема Fastor. Тема предназначена для интернет магазина и состоит из полного набора инструментов, позволяющих создавать красивые магазина на Woocommerce. А для тех кто любит использовать готовое имеется...
Время идет и появляются задачи убрать всё что вы накидали в свои видео или запостили в своей группе. Бывает такая задача и у меня на днях она тоже возникла. Пришлось основательно покопаться, так как добавленные когда то 4500 видео в...
WYSIWYG web редакторы, это редакторы, которые используются для работы с контентом сайта. Как правило в каждой из cms идёт свой выбор редакторов, но на самом деле он гораздо больше и сегодня мы представляем полный обзор существующих редакторов, которые были созданы...
