Что вы используете, когда вам нужен надежный UDP?


93

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

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

Здесь меня интересуют различные варианты, из которых TCP находится на одном конце шкалы, а UDP - на другом. Доступны различные надежные параметры UDP, каждая из которых привносит некоторые элементы TCP в UDP.

Я знаю, что часто TCP является правильным выбором, но наличие списка альтернатив часто помогает прийти к такому выводу. Такие вещи, как Enet, RUDP и т. Д., Которые построены на UDP, имеют различные плюсы и минусы, вы использовали их, каков ваш опыт?

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


1
Этот вопрос, кажется, не по теме, потому что он опрос по технологиям
Дэйв Хиллиер

Тем, кто считает TCP лучше во всех случаях, прочтите: en.wikipedia.org/wiki/Bandwidth-delay_product
nullptr

В Википедии есть хорошая таблица, в которой сравниваются различные аспекты UDP, UDP Lite, TCP, Multipath TCP, SCTP, DCCP и RUDP . SCTP поддерживает большинство функций из этого списка.
Евгений Березовский

@EugeneBeresovsky Я провел небольшое исследование относительно SCTP, большая часть информации, в том числе из ответов SO, датирована 2013 годом и ранее. Большинство людей писали тогда, что принятие SCTP было очень низким. Интересно, как это сегодня? Также см. Эту ветку stackoverflow.com/questions/1171555/…
Майкл IV

@MichaelIvanov Усыновление действительно низкое. Но если вы собираетесь использовать его внутри своего центра обработки данных, вас не волнует внешнее внедрение, пока коммутаторы и маршрутизаторы не вызывают проблем (чего в центре обработки данных они не должны), и у вас есть ОС. и поддержка библиотеки, что может быть проблемой, как описано в одном из ответов на вопрос, на который вы ссылаетесь.
Евгений Березовский

Ответы:


25

На этот вопрос сложно ответить без дополнительной информации по предмету проблемы. Например, какой объем данных вы используете? Как часто? Каков характер данных? (например, это уникальные, одноразовые данные? Или это поток образцов данных? и т. д.) Для какой платформы вы разрабатываете? (например, настольный компьютер / сервер / встроенный) Чтобы определить, что вы имеете в виду под словом «слишком медленный», какой сетевой носитель вы используете?

Но в (очень!) Общих чертах я думаю, вам придется очень постараться, чтобы превзойти tcp по скорости, если только вы не сможете сделать какие-то жесткие предположения относительно данных, которые вы пытаетесь отправить.

Например, если данные, которые вы пытаетесь отправить, таковы, что вы можете допустить потерю одного пакета (например, данные с регулярной выборкой, где частота дискретизации во много раз выше, чем ширина полосы сигнала), вы, вероятно, можете пожертвовать некоторой надежностью передачи, убедившись, что вы можете обнаружить повреждение данных (например, с помощью хорошего CRC)

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


4
Хорошо, я поправлю вопрос. Меня больше интересуют плюсы и минусы различных надежных протоколов UDP, а не ответ «используйте TCP»;)
Лен Холгейт

9
@Andrew - очень ЛЕГКО превзойти TCP в двух случаях: (1) ваше приложение имеет более низкие требования к надежности, чем «все данные всегда в порядке, без дубликатов, без лишних очередей». Или (2) вы используете многоадресную рассылку. Надежный UDP очень распространен в средах многоадресной рассылки.
Том

4
Кроме того, TCP ужасно страдает при использовании через WAN-соединение (проблемы с дальним доступом). Да просто. TCP использует окна, в которых пакеты в окне должны быть подтверждены. Протоколы ACK страдают из-за задержки из-за расстояния линии. Google: WAN TCP "скорость света"
Ajaxx,

3
@Ajaxx, вы очень правы в этом вопросе, однако TCP / IP делает это специально из-за последнего обвала Интернета. Если вы используете протокол с высокой скоростью передачи данных без какого-либо контроля перегрузки, в общем, позор вам. Если вы владеете сетью, то сходите с ума.
Кевин Нисбет,

2
«где частота дискретизации значительно выше, чем частота Найквиста» - по определению, частота дискретизации всегда вдвое превышает частоту Найквиста.
Стив

27

Насчет SCTP . Это стандартный протокол IETF (RFC 4960).

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

Обновление: сравнение TCP и SCTP показывает, что производительность сопоставима, если не могут использоваться два интерфейса.

Обновление: приятная вводная статья .


Это хорошо, меня больше интересуют вещи, которые могут быть построены на основе UDP, а не на основе IP, но это определенно что-то, что вписывается в пространство решений.
Лен Холгейт,

SCTP имеет множество замечательных функций (таких как множественная адресация), а с расширением частичной надежности (RFC 3758) это невероятно гибкий вариант. Он включен в последние версии ядра Linux, но для Windows вам придется установить собственный стек SCTP.
Эндрю Джонсон

6
SCTP может быть туннелирован через UDP. tools.ietf.org/id/draft-ietf-sigtran-sctptunnel-00.txt
Майлз,

Спасибо, Майлз, это полезная ссылка!
Лен Холгейт

1
Да ... Но что-то, что построено на основе UDP, а не на том же уровне, что и UDP, вероятно, будет проще реализовать в пространстве пользователя, по крайней мере, в Windows ...
Лен Холгейт

22

ENET - http://enet.bespin.org/

Я работал с ENET как с надежным протоколом UDP и написал версию, совместимую с асинхронными сокетами, для моего клиента, который использует ее на своих серверах. Он работает довольно хорошо, но мне не нравятся накладные расходы, которые одноранговый ping добавляет к незанятым соединениям; когда у вас много соединений, регулярный пинг всех из них - это очень напряженная работа.

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


14

У нас есть клиенты из оборонной промышленности, которые используют UDT (передача данных на основе UDP) (см. Http://udt.sourceforge.net/ ) и очень им довольны. Я вижу, что у него тоже есть дружественная лицензия BSD.


2
Можете ли вы подробнее рассказать о своих клиентах и ​​их вариантах использования, особенно в оборонном секторе? Наверное, нет, но попробовать стоит. Я на самом деле поделился с начальством идеей о UDT в приложении для передачи файлов, но пока она никуда не делась.
Томас Оуэнс

10

RUDP - надежный протокол дейтаграмм пользователя

Это обеспечивает:

  • Подтверждение полученных пакетов
  • Управление окнами и перегрузкой
  • Повторная передача потерянных пакетов
  • Сверхбуферизация (быстрее потоковой передачи в реальном времени)

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


Я смотрел на это, но, похоже, не было много реализаций. Есть рекомендация?
Николас

Нет извините. Я не стал использовать его в конце концов и всегда собирался делать реализацию с нуля.
Лен Холгейт

9

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

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

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

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

int opt = -1;
if (setsockopt(sock_fd, IPPROTO_TCP, TCP_NODELAY, (char *)&opt, sizeof(opt)))
  printf("Error disabling Nagle's algorithm.\n");

Как я уже сказал, предполагая, что TCP находится на одном конце шкалы, а UDP - на другом, что еще есть.
Лен Холгейт,

Если вы хотите быть педантичным, большинство обсуждаемых протоколов построено на основе UDP.
Smo

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

1
Быстрый ответ не обязательно означает высокую производительность.
Мэтт

1
Я не согласен. Когда Nagle используется в протоколах на основе TCP с большим количеством меньших пакетов, он объединяет их вместе и создает больше больших пакетов. Это вызывает небольшую задержку отправки, поэтому задержка может незначительно увеличиться. Однако пропускная способность может быть ниже при выключенном нагле, потому что больше пакетов = больше заголовков пакетов = больше накладных расходов. Пакеты, отбрасываемые в локальной сети, обычно больше связаны с заполнением входных буферов. Если у вас много клиентов, отправляющих данные на один и тот же хост, это может не иметь никакого значения. Я не верю, что выключение и включение Nagle повлияют на это на практике.
Мэтт

8

Любой, кто решит, что приведенного выше списка недостаточно и что они хотят разработать свой СОБСТВЕННЫЙ надежный UDP, обязательно должен взглянуть на спецификацию Google QUIC, поскольку она охватывает множество сложных угловых случаев и потенциальные атаки отказа в обслуживании. Я еще не играл с реализацией этого, и вы можете не хотеть или нуждаться во всем, что он предоставляет, но документ стоит прочитать, прежде чем приступать к новой «надежной» конструкции UDP.

Хорошая отправная точка для QUIC находится здесь , в блоге Chromium.

Текущий проектный документ QUIC можно найти здесь .


4

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

Ключевое слово в вашем предложении - «потенциально». Я думаю, вам действительно нужно доказать себе, что TCP на самом деле слишком медленный для ваших нужд, если вам нужна надежность в вашем протоколе.

Если вы хотите получить надежность от UDP, вы в основном собираетесь повторно реализовать некоторые функции TCP поверх UDP, что, вероятно, замедлит работу, чем просто использование TCP в первую очередь.


Да, Эндрю Эджкомб сказал об этом, но, как я уже сказал, меня интересуют плюсы и минусы КАКИХ альтернатив. Без этого списка альтернатив и их плюсов и минусов трудно решить, что лучше.
Лен Холгейт,

Учитывая известную функцию надежности, иногда поток UDP можно настроить вручную, чтобы опередить поток TCP в ОС. Однако редко.
Джошуа

1
@ 17 из 26, я согласен с Леном Холгейтом, TCP в некоторых случаях будет медленнее, чем надежный UDP. Как и в сети с высоким BDP, предположим, что у вас есть интернет-соединение со скоростью 1 Гбит / с из Китая в Нью-Йорк, я уверен, что TCP будет отстой, чтобы использовать почти всю скорость 1 Гбит / с. TCP лучше подходит для большинства соединений на Земле, но не для сетей с High Bandwidth Delay Product.
nullptr


3

Может быть RFC 5405 , «Руководство по использованию Unicast UDP для приложений дизайнеров» будет полезно для вас.


2

Вы рассматривали возможность сжатия данных?

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


1
Особенно с современными библиотеками сжатия. Некоторые из них работают так же быстро, как memcpy. например lz4.
Мэтт


-2

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.