Надежный UDP с первого взгляда: те решения RUDP, которые могут заменить TCP

задний план:

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

Поэтому нужно провести некоторое исследование UDP.

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

Следовательно, это может быть оптимальным направлением миграции TCP для использования надежного UDP.

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

Введение в UDP:

TCP — это ориентированный на соединение, надежный протокол транспортного уровня, в то время как UDP — это ненадежный, неупорядоченный транспортный протокол, ориентированный на дейтаграммы, поэтому UDP не устанавливает никаких соединений.

Какие факторы определяют размер дейтаграммы, отправляемой каждый раз по протоколу UDP?

• Сам протокол UDP имеет длину пакета UDP 16 бит, поэтому длина пакета UDP не может превышать 2^16=65536;

• Длина кадра данных Ethernet, MTU (максимальная единица передачи) канального уровня;

• Размер буфера отправки UDP сокета.

Длина пакета самого протокола UDP составляет 2 ^ 16 - 1, заголовок UDP занимает 8 байт, а заголовок пакета после инкапсуляции самого протокола IP занимает 20 байт, поэтому окончательная длина: 2 ^ 16 - 1 - 20 - 8 = 65507 байт.
Поскольку UDP — ненадежный протокол, мы должны стараться избегать фрагментации пакетов данных во время передачи. Таким образом, существует очень важное понятие MTU, то есть максимальная единица передачи.
Значение MTU в Интернете составляет 576 байт, поэтому в Интернете используется протокол UDP, а максимальное количество байтов на дейтаграмму составляет: 576 - 20 - 8 = 548.

Ссылаться наКаков максимальный размер пакета в UDP?, В тексте предполагается, что данные UDP должны контролироваться ниже 1472 байтов в среде LAN, а данные UDP должны контролироваться ниже 548 байтов во время программирования через Интернет.

Что может вызвать потерю пакетов UDP? :

• Повторная сборка фрагментации дейтаграммы потеряна:Размер, указанный самим протоколом UDP, составляет 64 КБ, но на канальном уровне существует ограничение MTU, и размер составляет около 5 КБ, поэтому при отправке большого пакета UDP пакет будет фрагментирован на уровне IP, а затем собран . Этот процесс может привести к потере фрагментированных пакетов. Сам UDP имеет механизм обнаружения CRC, который отбрасывает потерянные пакеты UDP;

• Буфер UDP заполняется:Когда UDP-буфер заполнен, получатель еще не обработал эту часть UDP-датаграммы, в это время негде хранить пришедшие дейтаграммы, и они, естественно, отбрасываются.

Клиент дважды отправляет UDP данные, первый 500 байт, второй 300 байт, сервер получает пакет в режиме блокировки, первый recvfrom(1000), то ли 1000 получает, то ли 500, то ли 300, то ли еще что?
Из-за ограниченного характера UDP-связи полученное может быть только 500 или 300, а из-за беспорядка и ненадежности UDP полученное может быть 300 или 500, или оно может быть заблокировано при вызове recvfrom до тех пор, пока не вернется тайм-аут (что то есть ничего не получено).

Предполагая, что пакеты данных не потеряны и поступают в соответствии с порядком отправки, серверная сторона принимает пакеты в режиме блокировки и вызывает три раза: recvfrom(200), recvfrom(1000), recvfrom(1000). прием??
Из-за ограниченного характера связи UDP первый recvfrom(200) получит первый 500-байтовый пакет данных, но поскольку буфер пользовательского пространства составляет всего 200 байт, он вернет только первые 200 байтов, оставив 300-словный раздел. быть отброшены. Второй recvfrom(1000) вернет 300 байт, а третий recvfrom(1000) заблокирует.

• Буфер сокета UDP слишком мал: если пакет UDP, отправленный клиентом, велик, а буфер сокета слишком мал для размещения пакета UDP, пакет будет потерян.

• Срок действия кэша ARP истекает: Время кэширования ARP составляет около 10 минут.Если в списке кэша APR нет MAC-адреса другой стороны или срок действия кэша истек, будет отправлен запрос ARP для получения MAC-адреса.До того, как MAC-адрес будет получен, UDP-пакет, отправленный пользователем, будет кэшироваться ядром в очереди arp_queue.По умолчанию кэшируется не более 3 пакетов, а избыточные UDP-пакеты будут отбрасываться.

После стольких лет развития TCP имеет достаточно алгоритмов и оптимизаций, и в случае хорошего состояния сети общая производительность TCP лучше, чем UDP.
Итак, когда мы должны использовать UDP?

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

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

• требуется NATпройти через

Ниже представлены некоторые надежные транспортные протоколы, связанные с UDP или подобные UDP.

1. КВИК

Полное название Quick UDP Internet Connections — это протокол, предложенный Google, который использует UDP для нескольких одновременных передач.

преимущество:

• Низкая задержка для установления соединения:

Процесс установления соединения полного рукопожатия HTTPS требует 3 RTT. Даже для возобновления сеанса требуется как минимум 2 RTT.
А как же QUIC? Поскольку он основан на UDP и реализует безопасное рукопожатие 0RTT, в большинстве случаев для передачи данных требуется только 0 RTT.На основе прямого шифрования и вероятность успеха 0RTT аналогична Намного выше, чем у Sesison Ticket TLS.

• Улучшенный контроль заторов:

В настоящее время протокол QUIC по умолчанию использует алгоритм управления перегрузкой Cubic протокола TCP, а также поддерживает такие алгоритмы управления перегрузкой, как CubicBytes, Reno, RenoBytes, BBR и PCC. Изменения в управлении перегрузкой могут быть реализованы без простоя приложений и обновлений.

• Мультиплексирование без блокировки начала строки:

Мультиплексирование QUIC похоже на HTTP2. Несколько HTTP-запросов (потоков) могут быть отправлены одновременно по одному соединению QUIC. Но мультиплексирование QUIC имеет большое преимущество перед HTTP2.
QUIC не имеет зависимостей между несколькими потоками в соединении. Таким образом, если поток 2 потеряет пакет udp, это повлияет только на обработку потока 2. Не влияет на обработку потоков до и после stream2.

• Миграция подключения:

Так как же QUIC обеспечивает миграцию соединения? Проще говоря, любое соединение QUIC больше не идентифицируется четверкой IP и порта, а 64-битным случайным числом в качестве идентификатора, так что даже если IP или порт изменится, пока идентификатор остается прежним, соединение остается Поддерживаемым, бизнес-логика верхнего уровня не воспринимает изменений и не будет прерываться, поэтому повторное подключение не требуется.

Поскольку этот идентификатор генерируется клиентом случайным образом и имеет длину 64 бита, вероятность коллизии очень мала.

вопрос:

Несмотря на то, что он популяризируется и применяется уже много лет, протокол QUIC еще не достиг стадии массовой популяризации.QUIC в IETFЭто все еще черновик, и существует два типа нестабильных соглашений: Google QUIC и IETF QUIC.

• 1) Маршрутизация блокирует UDP-порт 443 (это порт, развернутый QUIC);

• 2) слишком много UDP-пакетов будет принято поставщиком услуг за атаку из-за ограничения QS, и UDP-пакеты будут отброшены;

• 3) Ни маршрутизаторы, ни брандмауэры в настоящее время не готовы для QUIC.

Браузер Chrome экспериментально поддерживает протокол QUIC с 2014 года. Вы можете сделать это, набрав в браузере Chromechrome://flags Найдите слово quic, чтобы узнать, поддерживается ли quic.

В настоящее время веб-сервисы, поддерживающие протокол QUIC, доступны только после версии 0.9.Caddy. Другие распространенные веб-службы, такие как nginx, apache и т. д., не поддерживаются.

Реализация с открытым исходным кодом:

• Chromium:
  

  Это официально поддерживается. Достоинств естественно много.В официальной поддержке гугла ям в принципе нет.Вы можете следить за хромом,чтобы обновиться до последней версии в любое время. Однако компиляция Chromium более хлопотна, и у него есть отдельный набор инструментов для компиляции. Пока не рекомендуется рассматривать этот вариант.

• proto-quic:
  

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

• goquic:
  

  goquic инкапсулирует языковой пакет libquic go, и libquic также отделен от chromium. Он не поддерживается в течение нескольких лет. Он поддерживает только quic-36. goquic предоставляет обратный прокси. Тест показал, что из-за низкой версии QUIC последний браузер Chrome не поддерживает. Рассматривать этот вариант не рекомендуется.

• quic-go:
  

  quic-go – это стек протоколов QUIC, полностью написанный на языке go. Он активно развивается и используется в Caddy. Он лицензирован MIT и в настоящее время кажется лучшим решением.

Для мобильных устройств нет реализации с открытым исходным кодом. Однако вы можете использовать динамическую библиотеку из мобильного терминала Chromium, у Tencent есть демоверсия,GitHub.com/52IM/Минет - Иди.... Ссылаться наДелаем Интернет быстрее: обмен технической практикой нового поколения протокола QUIC в Tencent.

2. WebRTC и DataChannel

WebRTC, название происходит от аббревиатуры Web Real-Time Communication (Web Real-Time Communication), представляет собой технологию, которая поддерживает голосовые вызовы в реальном времени или видеочаты в веб-браузерах, была приобретена Google в 2010 году за 68,2 миллиона долларов. , технология.

WebRTC обеспечивает базовую технологию аудио и видео в реальном времени, включая сбор аудио и видео, кодирование и декодирование, передачу по сети, отображение и другие функции, а также поддерживает кроссплатформенность: windows, linux, mac, android.
Хотя целью WebRTC является реализация межплатформенной веб-аудио- и видеосвязи в режиме реального времени, из-за нативного, высококачественного и связанного характера кода основного уровня разработчикам легко мигрировать и применять другие чем веб-платформа. Долгое время WebRTC был единственной технологией высококачественной аудио- и видеосвязи в реальном времени, доступной бесплатно в отрасли.

преимущество:

• Поддержка браузера Chrome, кроссплатформенная, бесплатная;

• Отличные алгоритмы и технологии, аудио и видео алгоритмы, алгоритм контроля перегрузки GCC/BBR;

• Мощная способность пробивать отверстия.

вопрос:

• Отсутствие разработанных и развернутых серверных решений. Можно обратиться к сторонним программам, таким как Kurento, Janus, Licode.

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

• Недостаточно поддержки для нативной разработки. Демо на стороне Android не обновлялось с 2016 года, но интерфейс изменился. Документация не исчерпывающая. Из-за того, что задействовано больше знаний в предметной области (сбор аудио и видео, обработка, кодирование и декодирование, передача в реальном времени и т. д.), вся конструкция фреймворка относительно сложна, а гранулярность API относительно хороша, что затрудняет даже компиляцию. инженерные проекты. В первые дни из-за отсутствия поддержки кодека H.264 мобильный терминал мог использовать только программный кодек VP8 (собственный стандарт кодека Google) в течение длительного времени, что приводило к низкой производительности на недорогих мобильных телефонах. Из-за фрагментарного характера самого Android сложно обеспечить единый пользовательский интерфейс, если он не адаптирован для разных моделей.

Надежен ли WebRTC?

В общем, WebRTC надежен:

• Обеспечивает кроссплатформенную, кроссбраузерную коммуникацию и значительно ускоряет процесс, что является основной причиной популярности Google WebRTC;

• За ними следуют крупные производители, от базовых производителей микросхем до производителей приложений верхнего уровня, таких как Intel, ARM, Microsoft, Apple, Polycom, Vidyo и т. д.;

• На базе WebRTC разрабатываются отечественные производители аудио- и видеосервисов PaaS и SaaS, в том числе QQ, WeChat и мелкие партнеры из Tencent и YY;

• Google успешно применил Hangout и Duo на основе WebRTC;

• WebRTC очень подходит для сценариев прямых трансляций: WebRTC используется для потоковой передачи, а существующие решения CDN используются для просмотра.Комбинированное использование, Huajiao Live и Qianfan Live — лучшие случаи;

• Также есть много примеров извлечения части модуля отдельно для использования.

А вот для небольших команд сложность не маленькая:

• Код WebRTC огромен, конфигурация среды сложна, а порог относительно высок;

• WebRTC — это просто клиент, он больше подходит для 1-к-1, не подходит для видеозвонков «многие ко многим», например видеоконференций, если вы хотите поддерживать несколько сторон, вы должны использовать другие серверы, но это это техническая работа с большим количеством барьеров;

• Хотя WebRTC обеспечивает большую обработку сигналов, эхоподавление, кодек, но напрямую, я хочу достичь уровня QQ и WeChat, но мне нужно пойти на его оптимизацию, иначе это всего лишь 6-7 баллов WeChat;

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

SDK стороннего облачного аудио- и видеосервиса в режиме реального времени:

• 1. Тенсент SDK;

• 2. Shengwang, команда YY;

• 3. То есть команда QQ;

• 4. Команда из трех человек, WebEx/Cisco;

• 5. Zoom, команда Cisco;

• 6, Видё, ногтей для поставщиков решений;

• 7. Century Dingdian, поставщик решений Inke;

• 8. Одна штука, sdk еще не предоставили, но технология действительно хороша;

• 9. любой РТК.

Ссылаться наНадежно ли разрабатывать аудио и видео в реальном времени на основе WebRTC с открытым исходным кодом? Что такое сторонние SDK?

Ссылаться наАрхитектура WebRTC для разработки аудио и видео в реальном времени с открытым исходным кодом, подробное и практическое описание.

Ссылаться наАудио- и видеотехнология WebRTC в реальном времени на веб-странице: выглядит красиво, но сколько ям нужно заполнить в рабочем приложении?

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

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

DataChannel можно использовать как надежный канал UDP для отправки данных. Он основан на протоколе SCTP, а QUIC может использоваться в качестве альтернативы протоколу SCTP и в настоящее время проходит испытания.

webrtc использует улучшенную версию протокола SCTP. Изначально протокол SCTP находится на транспортном уровне, на том же уровне, что и UDP.Можно увидеть, что SCTP здесь на самом деле является SCTP поверх UDP. Поскольку протокол SCTP поддерживается протоколом DTLS, функция множественной адресации SCTP не используется в канале данных webrtc.

Есть два черновика, описывающих улучшенный метод WebRTC "draft-ietf-rtcweb-data-channel-13", "draft-ietf-rtcweb-data-protocol-09", согласно описанию webrtc Согласно фактической сцене, представленной : надежный режим передачи, частично надежный режим передачи, ненадежный режим передачи и т. д.

Аудио- и видеоканалы WebRTC реализованы на основе протокола SRTP, а алгоритмы управления перегрузкой, такие как GCC/BBR, реализованы на SRTP. DataChannel, естественно, не может использовать эти алгоритмы управления перегрузкой.

Чтобы использовать надежный UDP, стоимость внедрения WebRTC немного высока.

3. СКТР

SCTP (протокол передачи управления по потоковым управлением) представляет собой 2000, определяемый IETF, расположен в транспортном уровне транспортных слоев, а также на уровне транспортировки протокола TCP / UDP, который оба характеристики TCP и UDP.

• TCP передается в байтах, SCTP передается в блоках данных

• TCP обычно является однопутевой передачей, SCTP может быть многоканальной передачей.

• TCP — это однопоточная упорядоченная передача, SCTP может передавать несколько потоков независимо упорядоченных/неупорядоченных.

• Для установления соединения TCP требуется трехэтапное рукопожатие, а для установления соединения SCTP требуется четырехэтапное рукопожатие.

• SCTP имеет механизм сердцебиения для управления доступностью путей.

SCTP был включен в ядро ​​Linux в версии 2.6. (Но некоторые маршрутизаторы не поддерживают этот протокол транспортного уровня?)

Самая ранняя STCP - это узкополосная связьСигнал №7В IP-протокол вводится надежный механизм передачи, а также предлагается оптимизировать ограничение TCP-протокола, которое нельзя разбивать на кадры. Поскольку он появился поздно, а SCTP изначально был разработан для передачи сигналов, он в основном адаптирован для многопотоковых приложений и больше используется в сфере телекоммуникаций. Но он редко используется в терминале, и даже Windows не поддерживает этот протокол, поэтому широко не используется.

В сочетании с опытом WebRTC не рекомендуется напрямую использовать STCP, предоставляемый стандартным интерфейсом сокета.SCTP over UDPэто мудрый выбор. Однако проектов с открытым исходным кодом в этой области очень мало, а экология очень скудная.

Далее идет решение с открытым исходным кодом Reliable UDP.

4. ККП

github: Github.com/skywind3000... 7.7k stars

TCP предназначен для трафика (сколько килобайт данных может быть передано в секунду) и предназначен для полного использования полосы пропускания. Хотя KCP рассчитан на скорость потока (сколько времени требуется для отправки одного пакета из одного конца в другой), он обеспечивает на 30–40 % более высокую скорость передачи, чем TCP, за счет потери пропускной способности на 10–20 %. . Канал TCP — это большой канал с очень медленным течением, но большим потоком в секунду, тогда как KCP — это небольшой поток с быстрым течением.

Чтобы обеспечить масштабируемость, KCP предоставляет самые основные возможности надежного UDP, поэтому он реализован с помощью чистых алгоритмов и не отвечает за передачу и прием базовых протоколов (таких как UDP), предоставляемых KCP. Даже часы нужно передавать извне, а внутри не будет никаких системных вызовов. Мультиплексирование поддерживается.

KCP эквивалентен оптимизации некоторых алгоритмов управления потоком TCP. Его наибольшее значение заключается в перемещении конфигурации этих алгоритмов на прикладной уровень для обеспечения внешней масштабируемости и настраиваемости.

Также существует множество библиотек расширений и приложений, основанных на KCP.

Случай:

• Завтрашняя Империя: игра K17 "Tomorrow Empire" (Google Play), использующая KCP для ускорения игровых новостей, что позволяет глобальным игрокам беспрепятственно подключаться.

• Сказочная битва: 4399 игр MOBA с использованием KCP для оптимизации синхронизации игр.

• CC: NetEase CC использует kcp для ускорения потоковой передачи видео, эффективно улучшая беглость.

• BOBO: NetEase BOBO использует kcp для ускорения стримеров

• Юнфан ускоряется: Используйте KCP, чтобы ускорить передачу файлов и потоковую передачу видео и оптимизировать гладкость потоковых тайваньских анкеров

• SpatialOS: движок распределенного игрового сервера для массовых многопользовательских игр, преемник BigWorld, использует KCP для ускорения передачи данных.

• Lantern: Лучший VPN, 50000 звезд Github, ускорение с kcpgo

5. УДТ

Официальный сайт:источник forge.net/projects/UD…

UDT (протокол передачи данных на основе UDP) в основном предлагается для низкой производительности текущего TCP при передаче больших объемов данных на большие расстояния.Он построен поверх UDP, вводит новый контроль перегрузки и надежность, а также поддерживает надежную потоковую передачу (аналогично в TCP) и частично надежный транспорт дейтаграмм (расширенный UDP).

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

6. Энет

github: lsalzman/enet 1.5k stars

Введение на официальном сайте:о, он.bevideos.org/features.contracts…

• Обеспечивает дополнительную надежность доставки пакетов

• Производительность находится между TCP и UDP

7. Ракнет

github: facebookarchive/RakNet 2.8k stars

Официальный сайт:Woohoo. Jenkins software.com/features. Контракты…

Raknet изначально был сетевой библиотекой, предназначенной для многопользовательских боевых игр, и с тех пор постоянно совершенствовался и стал использоваться в коммерческих целях. В 2014 году он был открыт в соответствии с соглашением BSD (вы можете свободно использовать его и изменять исходный код). Помимо поддержки надежной и многоканальной передачи, Raknet также включает общие функции для игр в приложениях, такие как отправка и получение http,речевой трансивер, проникновение через NAT, отправку электронной почты и шифрование информации и т. д.

преимущество:

• Кроссплатформенность

• Безопасная передача RakNet автоматически использует SHA1, AES128, SYN в вашем коде и использует RSA, чтобы избежать атак передачи.

• Передача звука При кодировании и декодировании Speex 8-битный звук необходимо передавать только со скоростью 500 байт в секунду.

• Удаленный терминал С помощью RakNet вы можете удаленно управлять своими программами, включая настройки программ, управление паролями и журналами.

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

Raknet добавляет к одному соединению концепцию канала передачи (мультиплексированного сокета) для повышения эффективности передачи данных. Канал передачи ориентирован только на отправителя, и получатель не видит понятия канала.

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

Ссылаться наРакнет Исследования.

недостаток:

• Raknet теоретически может поддерживать пинг-понговый тест со скоростью 4 Вт сообщений в секунду между несколькими клиентами и серверами. Однако он нестабилен, если сообщения по какой-то причине будут накапливаться, это серьезно повлияет на время отклика отправки и получения, которое достигнет второго уровня.

• Последнее обновление было в 2015 году.

• Многие функции бизнес-уровня и отсутствие обслуживания в основном находятся в состоянии заброшенности.

8. Аэрон

гитхаб:real-logic/aeron 4.9k stars

Официальный сайт:real-logic.co.uk/

Aeron предназначен для целей связи IPC UDP одноадресных, многоадресных и больших объемов данных. Предоставление Java / C ++ /. NET очень эффективно передавать клиент данных, несколько клиентов могут эффективно между различными компьютерами или IPC таким же образом на компьютере. Дальнейшее поток сообщений может быть заархивирован настойчивым модулем хранения вниз для воспроизведения позже (или в режиме реального времени).

The Aeron protocol is designed to be run directly over many different types of transmission media, including shared memory/IPC, InfiniBand/RDMA, UDP, TCP, Raw IP, HTTP, WebSocket, BLE, etc.

Производительность является ключевым направлением деятельности Aeron, целью которой является достижение максимальной пропускной способности и минимальной предсказуемой задержки среди всех систем обмена сообщениями. Утверждается, что модуль двоичного кодирования SBE в 8 раз быстрее, чем Google ProtoBuf. Кроме того, Aeron утверждает, что превосходит лучших из лучших по пропускной способности и 90% лучших коммерческих продуктов по задержке. Он может передавать 40-байтовые небольшие пакеты сообщений со скоростью 6 миллионов в секунду.

Цели и сценарии использования Aeron следующие:

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

• Поддержка нескольких сред передачи (UDP/InfiniBand/общая память и т. д.)

• Поддерживает несколько потоков и может предоставлять различные QoS

• Эффективные алгоритмы управления потоком для одноадресной и многоадресной рассылки

• Программа-приемник может управлять скоростью потока

Aeron относительно современен и использует такие протоколы, как SPDY, HTTP2 и WebSocket.

В настоящее время у Aeron относительно мало китайских документов, но официальные документы очень подробные, а техническое обслуживание относительно сильное. обратитесь к немуОпределение транспортного протокола.

Он может реализовывать различные алгоритмы управления перегрузкой в ​​соответствии со своими потребностями.В настоящее время предоставляется только алгоритм управления перегрузкой Cubic.

Ссылаться наAeron: Do We Really Need Another Messaging System?.

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

9. RSокет

гитхаб:rsocket/rsocket

RSocket — это новый сетевой протокол прикладного уровня, разработанный инженерами Facebook, Netifi и Pivotal и обеспечивающий реализацию на таких языках, как Java, Kotlin, JavaScript, Go, .NET и C++. RSocket может использовать различные базовые транспортные уровни, включая TCP, WebSocket иAeron. TCP подходит для взаимодействия между различными компонентами распределенной системы, WebSocket — для взаимодействия между браузерами и серверами, а Aeron — метод передачи, основанный на протоколе UDP, что обеспечивает возможность адаптации RSocket к различным сценариям.

Четыре режима взаимодействия, поддерживаемые RSocket:

Режим связи RSocket - одноранговая связь.Это больше не находится между традиционным пониманием режима Клиент -> Сервер.В RSocket нет этой концепции.Статус всех равен, и все они могут быть на стороне сервера. Я звоню в вашу службу, и вы тоже можете звонить в мою службу.

Сценарии применения и экология:

• RSocket && dubbo, Dubbo in3.0.0-SNAPSHOTВерсия обеспечивает поддержку реактивного программирования на основе RSocket, и пользователи могут легко использовать синтаксис RSocket.

• RSOceet && Spring, Sprach Framework 5.2 собирается использовать RSOcept в качестве протокола связи по умолчанию, который также поддерживается в SpringBoot.

• RSocket && Microservices, основное препятствие RSocket заключается в том, что приложения должны использовать RSocket для связи. После популярности микросервисов, чтобы «упростить» связь между микросервисами, вводится множество уровней технологических стеков.

Ссылаться наРеактивная передача данных с помощью RSocket,Новый Завет реактивного программирования: RSocket.

Резюме: RSocket — это инкапсуляция некоторых надежных протоколов сетевой передачи на уровне приложения, предоставляющая очень удобный API для использования на верхнем уровне и может легко реализовать переключение протоколов между транспортным уровнем и уровнем приложений, таким как TCP/WebSocket/UDP. В распределенной системной интеграции хорошим выбором является RSocket.

Сравнение производительности решений RUDP с открытым исходным кодом

Сравнение производительности передачи между TCP и RUDP в случае слабой потери сетевых пакетов:

Горизонтальная ось представляет RTT (время приема-передачи), а вертикальная ось представляет долю выполненного вывода. Легенда в правом верхнем углу особо подчеркивает преимущества RUDP в сетевой среде с высокой скоростью потери пакетов: RUDP завершает около 70% передачи данных в течение [50-150] миллисекунд, в то время как передача, выполненная TCP, равномерно распределяется в каждая задержка. Согласно остальным трем графикам данных, он может лучше отражать то, что RUDP завершает передачу большей части данных с меньшей задержкой, чем TCP.

1. ракнет против либенета:

логика сервераОдиночный процесс работает с частотой кадров 1 мкс и передает обратно клиенту пакеты данных.

клиентская логикаКаждый процесс работает случайным образом с частотой 30 мс:

1. Подключение реконструкции с целевым сервером

2. Отправить ping-пакет проверки активности на целевой сервер

3. Комбинированные параметры, такие как режим случайной передачи и канал передачи, отправляют неупорядоченные пакеты на целевой сервер.

2. Сравнение UDT, KCP, ENet (оригинальный документ):

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

тестовая среда:

• Тестовый сервер развернут в Интернете, а пропускная способность составляет 5 МБ.

• Запустите клиент на компьютере, пропускная способность ADSL 10M

• Вышеуказанные два значения пропускной способности намного больше, чем фактическая требуемая пропускная способность (примерно в 10 раз)

• Клиент будет отправлять 500 каждые 50 мс
  bytes
  Данные отправляются в виде пакета. (другой тест 50 байт)

• Сервер отправляет данные обратно после получения пакета.

Результаты теста:

UDT:

• UDT плохо работает в PvP-играх в реальном времени.

• Но в нормальных условиях задержка идеальна

• UDT плохо работает, когда возникает задержка в сети

• Тяжелые случаи — это задержки более чем на несколько секунд или даже на десять секунд. и не ожидается восстановления

Энет:

• В играх PVP в реальном времени enet работает лучше, чем UDT.

• Время задержки enet составляет около 1 секунды. И от задержки до восстановления требуется всего несколько секунд

• Хуже, чем kcp, но в некоторых играх допускается задержка в 1 секунду

ККП:

• Задержка kcp всегда меньше 1 секунды.

• kcp лучше, чем UDT и enet. Когда возникает задержка в сети, задержка KCP составляет менее 2 секунд.

Суммировать:

• kcp — лучший выбор для PvP-игр в реальном времени (документация на китайском языке).

• Когда возникает задержка в сети, задержка kcp составляет менее 1 секунды, а эффективность в 3 раза выше, чем у enet.

• Если ваша игра допускает 2-секундную задержку, то enet — хороший выбор (меньше документации для enet).

3. Сравнение KCP и RakNet (оригинальный документ, серверный движок для массовой многопользовательской игрыSpatialOS):

В ненадежных сетях KCP превосходит TCP и RakNet с точки зрения задержки. Для 25 объектов максимальное значение RTT для 436271 пакета составляет 51 мс по сравнению со 114 мс для RakNet.

Для 50 объектов KCP работает лучше. 99,8% данных, RTT KCP составляет 44 мс, а RTT RakNet — 243 мс. Максимальное значение RTT для KCP составляет 83 мс, а для RakNet — 327 мс.

4. Углубленный тест enet в облачной игре Tencent (исходный адрес):

Первоначальный enet сохраняет функцию экспоненциального избегания повторной передачи tcp. Интервал повторной передачи по-прежнему умножается на 2. Значение rto по умолчанию также выше. Это может быть основной причиной того, что enet не работает так же хорошо, как kcp в приведенном выше тесте. код enet немного подкорректирован, что в итоге?

Автор вносит некоторые коррективы в libenet — rtt по умолчанию настраивается с 500 мс до 50 мс, а стратегия экспоненциального избегания повторной передачи по тайм-ауту удалена.

С точки зрения среднего отклика недостаток протокола TCP не очевиден: при задержке 30 мс и коэффициенте потери пакетов 1 % среднее значение rtt улучшенного enet составляет 69 мс, среднее значение rtt исходного enet — 67 мс, и средний rtt tcp составляет 67 мс, но из ответа Глядя на долю времени, превышающего 300 мс, когда задержка составляет 30 мс, а уровень потери пакетов составляет 1%, улучшенный rtt enet, превышающий 300 мс, равен 0, в то время как rtt tcp превышает 300 мс. превышает 2%, если он есть в игре, эта производительность может значительно повлиять на игровой процесс. Результаты показывают, что tcp имеет относительно большую проблему, когда сеть немного нестабильна, а улучшенный enet имеет очевидные преимущества.

Приложения

Применение Xuebajun и Юань Жунси:

• Вопросы и ответы 1V1 в режиме реального времени с глобальной задержкой в ​​250 миллисекунд используют схему интеллектуальной маршрутизации RUDP + многоточечная ретрансляция.

• Видеосоединение 1080P 500 мс и интерактивная система микрофона используют схему планирования передачи RUDP + PROXY.

• 6-сторонняя система синхронной записи в реальном времени использует надежную технологию передачи RUDP + журнал повторов.

• Система экранной передачи Pad 720P при слабом сетевом WIFI использует технологию управления потоком в реальном времени RUDP+ GCC.

• Крупномасштабная система распределения P2P в прямом эфире экономит более 75% полосы пропускания распределения благодаря технологии многоточечной параллельной ретрансляции RUDP +.

Ссылаться наRUDP транспортирует эти вещи.

Классы MOBA и игры «поедание курицы» используют UDP. Ссылаться наnuggets.capable/post/684490…

Суммировать:

TCP разрабатывался много лет и является более стабильным, чем UDP. Однако, если есть более высокие требования к задержке и пропускной способности, некоторые решения RUDP также считаются заменой TCP. Автор резюмирует эти библиотеки RUDP следующим образом:

• KCP больше используется в некоторых многопользовательских боевых играх, экология относительно полная, а возможности настройки также очень сильны.
• Aeron — это относительно современное решение RUDP, его целью является не RUDP, а эффективная передача данных между концами, и его документация также очень обширна. Однако его внутренняя реализация более сложна и требует определенных затрат на использование и настройку.
  
• RSocket эквивалентен инкапсуляции Aeron, предназначен для двухточечной связи и имеет поддержку среды Spring. Если есть потребность в бизнесе, удобнее переключить и мигрировать протокол передачи между TCP/WebSocket/RUDP. Однако такая сильно инкапсулированная библиотека, естественно, будет иметь плохие возможности настройки базового протокола передачи.
• DataChannel WebRTC можно использовать как RUDP, но это реализация STCP поверх UDP, и его возможности настройки относительно плохи. Более того, стоимость внедрения сложной технической инфраструктуры, такой как WebRTC, для использования RUDP очень высока.
• SCTP через UDP в краткосрочной перспективе невозможен.
• QUIC также является относительно сложным протоколом, и его возможности настройки немного хуже, однако на бизнес-уровне можно настроить различные алгоритмы управления перегрузкой, а внутренняя реализация также очень продвинута и современна. Но отсутствие экологии.
• Обновление UDT/ENet/raknet не очень хорошее, такое ощущение, что его забросили.

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