Що ви використовуєте, коли вам потрібен надійний UDP?

Якщо у вас ситуація, коли TCP-з'єднання потенційно занадто повільне, а UDP-з'єднання потенційно занадто ненадійне, що ви використовуєте? Існують різні стандартні надійні протоколи UDP, який досвід ви маєте з ними?

Будь ласка, обговоріть один протокол на кожну відповідь, і якщо хтось інший вже згадав той, який ви використовуєте, то подумайте про те, щоб проголосувати за нього та використати коментар для деталізації, якщо потрібно.

Мене цікавлять різні варіанти тут, з яких TCP знаходиться на одному кінці шкали, а UDP - на іншому. Доступні різні надійні опції UDP, кожна з яких додає деякі елементи TCP до UDP.

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

Щоб уникнути сумнівів, більше інформації немає, це гіпотетичне запитання, і, на яке я сподівався, з’явиться перелік відповідей, у яких детально описуються різні варіанти та альтернативи, доступні тому, хто повинен прийняти рішення.

Важко відповісти на це питання без додаткової інформації про область проблеми. Наприклад, який обсяг даних ви використовуєте? Як часто? Яка природа даних? (наприклад, це унікальні, разові дані? Або це потік зразкових даних? тощо) Для якої платформи ви розробляєте? (наприклад, робочий стіл / сервер / вбудований) Для визначення того, що ви маєте на увазі під словом «занадто повільний», який мережевий носій ви використовуєте?

Але загалом (дуже!), Я думаю, вам доведеться по-справжньому постаратися перемогти tcp на швидкість, якщо ви не зможете зробити певних твердих припущень щодо даних, які ви намагаєтеся надіслати.

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

Але якщо ви не можете терпіти втрату одного пакета, то вам доведеться розпочати впровадження типів методів надійності, які вже є у tcp. І, не докладаючи розумного обсягу роботи, ви можете виявити, що починаєте вбудовувати ці елементи в рішення простору користувача з усіма властивими проблемами швидкості.

А як щодо SCTP . Це стандартний протокол IETF (RFC 4960)

Він має можливість шматування, що може допомогти швидкості.

Оновлення: порівняння між TCP та SCTP показує, що продуктивність порівнянна, якщо не можна використовувати два інтерфейси.

Оновлення: приємна вступна стаття .

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

Я працював з ENET як надійний протокол UDP і написав асинхронну версію розетки для мого клієнта, який використовує його на своїх серверах. Це працює досить добре, але мені не подобаються накладні витрати, які пінг-рівний пінг додає до інших простоїв з'єднань; коли у вас багато зв’язків, регулярно перевіряти їх усі - це дуже напружена робота.

ENET надає вам можливість надсилати кілька "каналів" даних, а дані, що надсилаються, бути ненадійними, надійними або послідовними. Сюди також входить вищезазначений пірінг-пінг, який виконує функції збереження життя.

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

RUDP - надійний протокол датаграм користувачів

Це забезпечує:

• Підтвердження отриманих пакетів
• Контроль за вікнами та заторами
• Повторна передача втрачених пакетів
• Надбуферизація (швидше, ніж потокове передавання в реальному часі)

Це здається дещо більш налаштованим щодо збереження живих, ніж ENet, але це не дає вам стільки варіантів (тобто всі дані є надійними та мають послідовність, а не лише ті біти, які, на вашу думку, мають бути). Це виглядає досить прямо в реалізації.

Як зазначали інші, ваше запитання є дуже загальним, і чи є щось швидшим, ніж TCP, багато в чому залежить від типу програми.

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

Є легка золота середина. Алгоритм Nagle - це частина 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");

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

Хороший стрибковий пункт для QUIC - тут , у блозі Chromium.

Поточний проектний документ QUIC можна знайти тут .

Якщо у вас ситуація, коли TCP-з'єднання потенційно занадто повільне, а UDP-з'єднання потенційно занадто ненадійне, що ви використовуєте? Існують різні стандартні надійні протоколи UDP, який досвід ви маєте з ними?

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

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

Протокол DCCP, стандартизований у RFC 4340 , "Протокол управління перевантаженнями дейтаграм", може бути саме тим, що ви шукаєте.

Здається, це реалізовано в Linux .

Можливо RFC 5405 , "Вказівки щодо використання Unicast UDP для дизайнерів програм" будуть корисними для вас.

Ви розглядали можливість стиснення ваших даних?

Як зазначено вище, нам не вистачає інформації про точний характер вашої проблеми, але стиснення даних для їх транспортування може допомогти.

РУДП . Багато серверів сокетів для ігор реалізують щось подібне.

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