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

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

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

I'm interested in the various options here, of which TCP is at one end of the scale and UDP is at the other. Various reliable UDP options are available and each brings some elements of TCP to UDP.

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

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

 nullptr14 нояб. 2014 г., 15:17
Тем, кто считает TCP лучшим во всех случаях, читайте:en.wikipedia.org/wiki/Bandwidth-delay_product
 Eugene Beresovsky26 февр. 2015 г., 06:16
Википедия имеет хорошийtable comparing various aspects of UDP, UDP Lite, TCP, Multipath TCP, SCTP, DCCP, and RUDP, SCTP поддерживает большинство функций в этом списке.
 Dave Hillier23 сент. 2014 г., 21:00
Этот вопрос кажется не по теме, потому что это опрос технологий
 Eugene Beresovsky25 июл. 2017 г., 00:06
@MichaelIvanov Усыновление действительно низкое. Но если вы намереваетесь использовать его внутри своего центра обработки данных, вам не нужно принимать его извне, если коммутаторы и маршрутизаторы не вызывают проблем (которые в центре обработки данных не должны возникать) и у вас установлена ОС. и поддержка библиотеки, которая может быть проблемой, как описано вone ответа на вопрос, с которым вы связаны.
 Michael IV24 июл. 2017 г., 20:19
@EugeneBeresovsky Я провел небольшое исследование относительно SCTP, большая часть информации, в том числе из ответов SO, датирована 2013 годом и ранее. Большинство людей тогда писали, что принятие SCTP было очень низким. Интересно, как оно сегодня?stackoverflow.com/questions/1171555/…

Ответы на вопрос(13)

RFC 4340, «Протокол управления перегрузкой дейтаграмм» может быть то, что вы ищете.

Похоже на тореализовано в Linux.

and a UDP 'connection' is potentially too unreliable what do you use? There are various standard reliable UDP protocols out there, what experiences do you have with them?

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

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

 14 нояб. 2014 г., 15:11
@ 17 из 26, я согласен с Леном Холгейтом, в некоторых случаях TCP будет работать медленнее, чем надежный UDP. Как и в случае сети с высоким BDP, предположим, что у вас есть интернет-соединение в 1 Гбит / с из Китая в Нью-Йорк, я уверен, что TCP будет использовать всю скорость почти 1 Гбит / с. TCP лучше подходит для большинства соединений на земле, но не для сети с продуктом с высокой пропускной способностью.
 24 янв. 2009 г., 22:27
Учитывая известную функцию надежности, иногда поток UDP может быть настроен вручную, чтобы превзойти поток TCP в ОС. Редкий, хотя.
 Len Holgate21 сент. 2008 г., 19:16
Да, Эндрю Эджкомб сказал то же самое, но, как я уже сказал, я заинтересован в плюсах и минусах ЧТО есть альтернативы. Без этого списка альтернатив, их плюсов и минусов, трудно решить, что лучше.

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

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

Acknowledgment of received packets Windowing and congestion control Retransmission of lost packets Overbuffering (Faster than real-time streaming)

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

 Len Holgate16 июл. 2014 г., 19:33
Нет извините. Я не заканчивал тем, что использовал это в конце и всегда собирался сделать реализацию с нуля.
 16 июл. 2014 г., 16:02
Я смотрел на это, но, кажется, не так много реализаций. Есть рекомендации?

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

 02 дек. 2011 г., 01:02
Особенно с современными библиотеками сжатия. Некоторые так же быстры, как memcpy. например LZ4.

RFC 5405, & quot; Руководство по использованию одноадресного UDP для разработчиков приложений & quot; будет полезно для вас.

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

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

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

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

int opt = -1;
if (setsockopt(sock_fd, IPPROTO_TCP, TCP_NODELAY, (char *)&opt, sizeof(opt)))
  printf("Error disabling Nagle's algorithm.\n");
 02 дек. 2011 г., 00:55
Быстрый ответ не обязательно равен высокой пропускной способности.
 22 сент. 2008 г., 16:06
Если вы хотите быть педантичным, большинство обсуждаемых протоколов построены поверх UDP.
 02 дек. 2011 г., 01:01
Я не согласен. Когда nagle используется в протоколах на основе TCP с большим количеством меньших пакетов, он объединяет их вместе и создает более крупные пакеты. Это вызывает небольшую задержку при отправке, поэтому задержка может немного увеличиться. Однако пропускная способность может быть ниже при выключенном nagle, потому что больше пакетов = больше заголовков пакетов = больше служебных данных. Пакеты, отбрасываемые в локальной сети, обычно больше связаны с заполнением входных буферов. Если у вас много клиентов, отправляющих данные на один и тот же хост, это может иметь нулевую разницу. Я не верю, что выключение и включение nagle на практике повлияют на это.
 Len Holgate21 сент. 2008 г., 20:28
Как я уже сказал, при условии, что TCP находится на одном конце шкалы, а UDP - на другом, что еще есть.
 23 июн. 2009 г., 10:11
Предположение, что TCP находится на одном конце, а UDP на другом конце, неверно. например UDP не имеет управления потоком, вы можете легко отправлять пакеты слишком быстро, в результате чего промежуточный маршрутизатор отбрасывает их все. Тогда что ты делаешь? Игнорировать потерянные пакеты или отправить их? Повторная отправка их, и вы в конечном итоге переопределите TCP более или менее. Другой вариант для надежной связи - SCTP.
Решение Вопроса

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

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

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

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

 11 июл. 2009 г., 06:42
@Ajaxx, вы очень правы в этом отношении, однако, TCP / IP делает это нарочно из-за последнего обвала интернета. Если вы используете протокол с высокой скоростью передачи данных без какого-либо контроля перегрузки, ну, в общем, позор вам. Если вы владеете сетью, то без ума.
 Len Holgate20 сент. 2008 г., 11:22
Хорошо, я уточню вопрос. Меня больше интересуют плюсы и минусы различных надежных протоколов UDP, а не использование TCP. ответ ;)
 27 февр. 2009 г., 04:41
Кроме того, TCP ужасно страдает при использовании через WAN-соединение (проблемы с дальней связью). Почему просто. TCP использует окна, где пакеты в окне должны быть подтверждены. Протоколы ACK страдают из-за задержки из-за расстояния линии. Google: WAN TCP "скорость света"
 14 дек. 2008 г., 18:29
@ Andrew - очень легко победить TCP в двух случаях: (1) ваше приложение предъявляет более строгие требования к надежности, чем «все данные, всегда в порядке, без дубликатов, без чрезмерной очереди». Или (2) вы используете многоадресную рассылку. Надежный UDP очень распространен для многоадресных сред.
 05 сент. 2012 г., 17:47
«где частота дискретизации значительно выше, чем частота Найквиста»; - частота дискретизации всегда в два раза превышает частоту Найквиста по определению.

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

У него есть возможность чанкинга, которая может помочь в скорости.

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

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

 Len Holgate22 сент. 2008 г., 11:19
Спасибо за обновление и сравнение!
 Len Holgate22 авг. 2011 г., 22:38
Да ... Но то, что построено поверх UDP, а не на том же уровне, что и UDP, вероятно, будет легче реализовать в пользовательском пространстве, по крайней мере, в Windows ...
 15 июн. 2009 г., 16:36
SCTP может быть туннелирован по UDP.tools.ietf.org/id/draft-ietf-sigtran-sctptunnel-00.txt
 Len Holgate20 сент. 2008 г., 12:23
Это хорошо, меня больше интересуют вещи, которые могут быть построены поверх UDP, а не построены поверх IP, но это, безусловно, то, что вписывается в пространство решения.
 05 окт. 2008 г., 22:10
SCTP имеет много замечательных функций (таких как множественная адресация) и с расширением частичной надежности (RFC 3758) это невероятно гибкий вариант. Он включен в последние версии ядра Linux, но для Windows вам придется установить свой собственный стек SCTP.

кто решит, что приведенного выше списка недостаточно, и что он хочет разработать свой собственный надежный UDP, должен обязательно взглянуть на спецификацию Google QUIC, поскольку она охватывает множество сложных угловых случаев и потенциальных атак типа "отказ в обслуживании". Я еще не играл с реализацией этого, и вы, возможно, не хотите или не нуждаетесь во всем, что оно предоставляет, но этот документ стоит прочитать, прежде чем приступать к новому «надежному». UDP дизайн.

Хорошая отправная точка для QUICВот, в блоге Chromium.

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

RUDP, Многие сокет-серверы для игр реализуют нечто подобное.

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

http://enet.bespin.org/

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

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

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

 17 авг. 2011 г., 15:01
Можете ли вы рассказать о своих клиентах и их случаях использования, особенно в оборонном секторе? Вероятно, нет, но это стоит того. На самом деле я отказался от идеи для моего начальства о UDT в приложении для передачи файлов, но оно пока никуда не ушло.

Ваш ответ на вопрос