Коли доцільно використовувати UDP замість TCP? [зачинено]

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

Я припускаю, що UDP швидше, оскільки він не має накладних витрат на створення та підтримку потоку, але чи не це буде неактуально, якщо деякі дані ніколи не досягають свого призначення?

Це одне з моїх улюблених питань. UDP настільки неправильно зрозуміла.

У ситуаціях, коли ви дійсно хочете швидко отримати просту відповідь на інший сервер, UDP найкраще працює. Загалом, ви хочете, щоб відповідь містилася в одному пакеті відповідей, і ви готові реалізувати власний протокол для надійності або для повторного надсилання. DNS - ідеальний опис цього випадку використання. Витрати на налаштування з'єднання занадто високі (але DNS також підтримує режим TCP).

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

Інший випадок, коли ви керуєте величезною кількістю стану і хочете уникати використання TCP, оскільки ОС не може обробити стільки сеансів. Сьогодні це рідкісний випадок. Насправді, тепер існують TCP-стеки користувачів наземних, які можна використовувати так, що програма для запису програм може мати більш тонкий контроль над ресурсами, необхідними для цього стану TCP. До 2003 року UDP була справді єдиною грою в місті.

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

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

Приклади включають потокове відео і особливо VoIP (наприклад, Skype ). Однак у цих випадках відкинутий пакет не така вже й велика справа: наші почуття не є ідеальними, тому ми можемо навіть не помітити. Ось чому ці типи додатків використовують UDP замість TCP.

"Ненадійність" UDP - це формалізм. Трансмісія не гарантована абсолютно. Як практична справа, вони майже завжди проникають. Вони просто не визнаються та повторюються після закінчення тайм-ауту.

Витрати на переговори про TCP-розетку та рукостискання пакетів TCP величезні. Дійсно величезна. Немає помітних накладних витрат.

Найголовніше, що ви можете легко доповнити UDP деяким надійним рукостисканням, яке менше, ніж на TCP. Читайте це: http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

UDP корисний для трансляції інформації в додатку, який публікує та підписується. IIRC, TIBCO активно використовує UDP для повідомлення про зміну стану.

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

Системні повідомлення "серцебиття" або "я живий" - також хороший вибір. Відсутній - це не криза. Пропущено півдесятка (поспіль) є.

Я працюю над продуктом, який підтримує як UDP (IP), так і TCP / IP зв’язок між клієнтом і сервером. Він розпочався з IPX понад 15 років тому, підтримка IP додана 13 років тому. Ми додали підтримку TCP / IP 3 або 4 роки тому. Дивна здогадка: співвідношення коду UDP та TCP, ймовірно, приблизно 80/20. Продукт є сервером баз даних, тому надійність є критичною. Нам доводиться вирішувати всі проблеми, нав'язані UDP (втрата пакету, подвоєння пакетів, замовлення пакетів тощо), вже згадані в інших відповідях. Проблеми рідко виникають, але вони трапляються іноді, і тому їх потрібно вирішувати. Перевага для підтримки UDP полягає в тому, що ми можемо трохи налаштувати його під власне використання та досягти трохи більшої продуктивності.

Кожна мережа буде іншою, але протокол зв'язку UDP, як правило, трохи швидший для нас. Скептичний читач справедливо запитає, чи правильно ми все реалізували. Плюс, чого ви можете очікувати від хлопця з двозначною реплікацією? Тим не менш, я щойно пройшов випробування з цікавості. Тест прочитав 1 мільйон записів (виберіть * з деяких таблиць). Я встановив кількість записів для повернення з кожним окремим запитом клієнта на 1, 10, а потім 100 (три проби з кожним протоколом). Сервер був лише за два стрибки через 100 Мбіт локальної мережі. Цифри, здавалося б, узгоджуються з тим, що виявили інші в минулому (UDP на 5% швидше в більшості ситуацій). Загальний час у мілісекундах для цього конкретного тесту був таким:

1. 1 запис
   • IP: 390,760 мс
   • TCP: 416903 мс
2. 10 записів
   • IP: 91,707 мс
   • TCP: 95 662 мс
3. 100 записів
   • IP: 29 664 мс
   • TCP: 30,968 мс

Загальна кількість переданих даних була приблизно однаковою як для IP, так і для TCP. У нас є додаткові накладні витрати на комунікації з UDP, оскільки у нас є деякі ті самі речі, які ви отримуєте для "безкоштовно" з TCP / IP (контрольні суми, порядкові номери тощо). Наприклад, Wireshark показав, що запитом для наступного набору записів було 80 байт з UDP і 84 байти з TCP.

Тут вже багато хороших відповідей, але я хотів би додати один дуже важливий фактор, а також резюме. UDP може досягти значно більшої пропускної здатності за допомогою правильної настройки, оскільки він не використовує контроль перевантаженості . Контроль заторів у TCP дуже дужеважливий. Він контролює швидкість і пропускну здатність з'єднання з метою мінімізації перевантаженості мережі, намагаючись оцінити поточну потужність з'єднання. Навіть коли пакети надсилаються через дуже надійні посилання, наприклад, в основній мережі, маршрутизатори мають буфери обмеженого розміру. Ці буфери заповнюються до своєї ємності і пакети потім скидаються, і TCP помічає це падіння через відсутність отриманого підтвердження, тим самим зменшуючи швидкість з'єднання для оцінки ємності. TCP також використовує щось, що називається повільним запуском , але пропускну здатність (насправді вікно заторів) повільно збільшується до падіння пакетів, а потім знижується і знову повільно збільшується, поки пакети не скидаються і т. д. Це призводить до того, що пропускна здатність TCP коливатиметься. Це ви добре бачите, коли завантажуєте великий файл.

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

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

Результат полягає в тому, що UDP може:

• Досягайте більшої пропускної здатності, ніж TCP, якщо швидкість падіння мережі знаходиться в межах, з якими може працювати програма.
• Доставка пакетів швидше, ніж TCP, з меншою затримкою.
• Налаштуйте з'єднання швидше, оскільки не існує початкових рукостискань для налаштування з'єднання
• Передайте пакети багатоадресної передачі, тоді як TCP повинні використовувати декілька з'єднань.
• Передайте пакети фіксованого розміру, тоді як TCP передає дані в сегментах. Якщо ви передасте пакет UDP об'ємом 300 байт, ви отримаєте 300 байт на іншому кінці. За допомогою TCP ви можете подати сокет відправлення 300 байт, але приймач зчитує лише 100 байт, і вам доведеться якось зрозуміти, що на шляху є ще 200 байт. Це важливо, якщо ваша програма передає повідомлення фіксованого розміру, а не потік байтів.

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

UDP має менші накладні витрати, і це добре робити такі речі, як потокове передавання даних у режимі реального часу, як-от аудіо чи відео, або в будь-якому випадку, якщо це нормально, якщо дані втрачаються.

UDP є протоколом без з’єднання і використовується в таких протоколах, як SNMP і DNS в яких пакети даних, що виходять з ладу, є прийнятною і негайне передавання пакета даних має значення.

Він використовується в SNMP, оскільки управління мережею потрібно часто виконувати, коли мережа перебуває в напрузі, тобто коли надійну передачу даних, керовану перевантаженням важко досягти.

Він використовується в DNS, оскільки не передбачає встановлення з'єднання, тим самим уникаючи затримок встановлення з'єднання.

ура

Одна з найкращих відповідей, яку я знаю на це питання, отримує від користувача zAy0LfpBZLC8mAC в Hacker News . Ця відповідь така гарна, що я просто процитую її як є.

TCP блокує пряму чергу, оскільки це гарантує повну та замовлену доставку, тому, коли пакет втрачається під час транзиту, він повинен чекати повторної передачі відсутнього пакету, тоді як UDP доставляє пакети до програми, коли вони надійдуть. , включаючи дублікати і без жодної гарантії, що пакет прибуває взагалі або в якому порядку вони надходять (це насправді фактично IP з номерами портів та додається (необов'язково) контрольна сума корисного навантаження), але це добре для телефонії, наприклад, там, де зазвичай просто не має значення, коли пропадає кілька мілісекунд аудіо, але затримка дуже дратує, тому ви не турбуєтесь з повторними передачами, ви просто кидаєте будь-які дублікати, сортуєте впорядковані пакети в потрібному порядку за кілька сотень мілісекунд буфера джиттера , і якщо пакети не з’являються вчасно або зовсім, вони просто пропускаються,можливо інтерпольований, коли підтримується кодеком.

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

На додаток до додатків у режимі реального часу / низької затримки, UDP має сенс для дійсно невеликих транзакцій, таких як пошук DNS, просто тому, що він не має встановлення TCP-з’єднання та викриття накладних витрат, як з точки зору затримки, так і з точки зору використання пропускної здатності. Якщо ваш запит менший, ніж типовий MTU, і, можливо, також є repsonse, ви можете зробити це за один перехід, без необхідності зберігати будь-який стан на сервері, а також замовляти контроль потоків і все, що, ймовірно, не особливо корисно для таких застосувань.

І тоді, ви можете використовувати UDP, щоб створити власні заміни TCP, але, мабуть, це не гарна ідея без глибокого розуміння мережевої динаміки, сучасні алгоритми TCP досить складні.

Крім того, я думаю, слід зазначити, що існує більше, ніж UDP і TCP, таких як SCTP і DCCP. Єдина проблема в даний час полягає в тому, що Інтернет (IPv4) переповнений NAT-шлюзами, які унеможливлюють використання протоколів, відмінних від UDP та TCP, у додатках для кінцевих користувачів.

Потокове відео - ідеальний приклад використання UDP.

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

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

Велика річ, яку люди забувають, це те, що udp базується на пакетах, а tcp - на байтестре, немає гарантії, що надісланий вами пакет tcp - це той пакет, який з’являється на іншому кінці, і його можна розібрати на стільки пакетів як бажання маршрутизаторів і стеків. Таким чином, ваше програмне забезпечення має додаткові накладні витрати на розбір байтів назад у корисні шматки даних, що може зайняти неабияку кількість накладних витрат. UDP може вийти з ладу, тому вам доведеться пронумерувати ваші пакети або скористатися іншим механізмом, щоб переупорядкувати їх, якщо ви хочете зробити це. Але якщо ви отримаєте цей udp-пакет, він надходить з усіма тими ж байтами в тому ж порядку, що і залишився, ніяких змін. Отже, термін udp пакет має сенс, але tcp пакет не обов'язково. TCP має власний механізм повторної спроби та замовлення, прихований від вашої програми,

UDP набагато простіше написати код для обох кінців, в основному тому, що вам не потрібно робити і підтримувати з'єднання «точка-точка». Моє запитання, як правило, в яких ситуаціях ви хочете отримати надмірні витрати TCP? І якщо ви приймаєте ярлики, як припустимо, отриманий tcp "пакет" є повним надісланим пакетом, то вам краще? (Ви, ймовірно, викинете два пакети, якщо будете намагатися перевірити довжину / вміст)

Мережеве спілкування для відеоігор майже завжди здійснюється через UDP.

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

Ключове питання стосувалося "в яких ситуаціях кращий вибір стане UDP [over tcp]"

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

Із масовим зростанням мобільних додатків та парадигмами, що «час від часу підключаються» або «час від часу відключаються», звичайно виникають ситуації, коли накладні спроби TCP підтримувати зв’язок, коли з’єднання важко провести, призводить до сильного випадку для UDP та його "орієнтованого на повідомлення" характеру.

Зараз у мене немає математики / досліджень / чисел щодо цього, але я створив додатки, які працювали надійніше, використовуючи ACK / NAK та нумерацію повідомлень через UDP, ніж це можна було досягти за допомогою TCP, коли зв’язок був загалом слабким і поганим старим TCP щойно витратив час і гроші мого клієнта просто намагався підключитися. Ви отримуєте це в регіональних та сільських районах багатьох західних країн….

У деяких випадках, які інші підкреслили, гарантований прихід пакетів не важливий, а значить, використання UDP є прекрасним. Є й інші випадки, коли UDP є кращим перед TCP.

Один унікальний випадок, коли ви хочете використовувати UDP замість TCP - це тунелювання TCP через інший протокол (наприклад, тунелі, віртуальні мережі тощо). Якщо ви тунелюєте TCP через TCP, контроль перевантаженості кожного буде заважати один одному. Отже, один, як правило, віддає перевагу тунелю TCP через UDP (або якийсь інший протокол без стану). Дивіться статтю TechRepublic: Розуміння TCP Over TCP: Ефекти тунелювання TCP на пропускну здатність і затримку .

UDP можна використовувати, коли додаток піклується про дані в режимі реального часу замість точної реплікації даних. Наприклад, VOIP може використовувати UDP, і додаток буде турбуватися про переупорядкування пакетів, але врешті-решт, VOIP не потребує кожного окремого пакету, але, що важливіше, потрібен постійний потік багатьох з них. Можливо, вам тут "глюк" в якості голосу, але головна мета полягає в тому, щоб ви отримали повідомлення, а не те, що воно відтворене ідеально з іншого боку. UDP також використовується в ситуаціях, коли витрати на створення з'єднання та синхронізацію з TCP перевищують корисне навантаження. Записи DNS - прекрасний приклад. Один пакет, один пакет назад, за запит. Якщо використовувати TCP, це було б набагато інтенсивніше. Якщо ви не отримаєте відповідь DNS, ви просто спробуйте.

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

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

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

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

Це також доречно, коли ви хочете транслювати ту саму інформацію багатьом користувачам.

В іншому випадку це доцільно, коли ви надсилаєте послідовні дані, але якщо деякі з них відсутні, ви не надто стурбовані (наприклад, програма VOIP).

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

Приклади того, де він / може бути використаний 1) Сервер часу, який передає правильний час на купу машин в локальній мережі. 2) протоколи VOIP 3) пошук DNS 4) запит на послуги локальної мережі, наприклад, де ви знаходитесь? 5) Інтернет-радіо 6) та багато інших ...

На unix ви можете ввести grep udp / etc / services, щоб отримати список протоколів UDP, реалізованих сьогодні ... їх сотні.

Подивіться розділ 22.4 мережевого програмування Стівена Unix , "Коли використовувати UDP замість TCP".

Також дивіться цю іншу відповідь про помилкове уявлення про те, що UDP завжди швидший, ніж TCP .

Те, що говорить Стівен, можна підсумувати наступним чином:

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

Ми знаємо, що UDP - це протокол, що не потребує з'єднання, так це і є

1. підходить для процесу, що вимагає простого зв'язку-відповіді на запит.
2. підходить для процесу, який має внутрішній потік, контроль помилок
3. підходить для широкого кастингу та багатоадресної передачі

Конкретні приклади:

• використовується в SNMP
• використовується для деяких протоколів оновлення маршрутів, таких як RIP

Порівнюючи TCP з UDP, протоколи без з'єднання, такі як UDP, забезпечують швидкість, але не надійність передачі пакетів. Наприклад, у відеоіграх зазвичай не потрібна надійна мережа, але швидкість є найважливішою, а використання UDP для ігор має перевагу зменшення затримки в мережі.

Ви хочете використовувати UDP через TCP у тих випадках, коли втрата частини даних по дорозі не повністю знищить дані, що передаються. Багато його використання використовується в реальному часі, таких як ігри (наприклад, FPS, де вам не завжди потрібно знати, де знаходиться кожен гравець у будь-який момент часу, і якщо ви втратите кілька пакетів по дорозі, нові Дані точно підкажуть, де в будь-якому випадку є програвачі) та потокове відео в режимі реального часу (один пошкоджений кадр не збирається зруйнувати перегляд).

У нас є веб-сервіс, який налічує тисячі клієнтів Winforms на стільки ПК. Комп'ютери не мають зв’язку з резервним сервером БД, весь доступ здійснюється через веб-сервіс. Тому ми вирішили розробити центральний сервер реєстрації даних, який прослуховує порт UDP, і всі клієнти надсилають пакет журналів помилок xml (використовуючи додаток UDP log4net), який потрапляє до таблиці БД після отримання. Оскільки нас насправді не хвилює, чи пропущено кілька журналів помилок, і з тисячами клієнтів це швидко, якщо спеціалізований сервіс реєстрації не завантажує основну веб-службу.

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

Єдиний випадок, коли я можу придумати, де потрібен UDP, - це трансляція протоколів. У випадках, коли у програмі задіяні два відомих хости, UDP, ймовірно, пропонує лише граничні переваги від продуктивності за істотно збільшених витрат на складність коду.

Використовуйте UDP, лише якщо ви дійсно знаєте, що робите. УДП сьогодні є вкрай рідкісними випадками, але кількість (навіть дуже досвідчених) експертів, які намагалися б її дотримуватися скрізь, здається, не пропорційно. Можливо, їм подобається реалізовувати код керування помилками та підтримку з'єднання самостійно.

TCP слід очікувати набагато швидше за допомогою сучасних мережевих інтерфейсних карт завдяки тому, що відомо як відбиток контрольної суми . Дивно, але при високій швидкості з'єднання (наприклад, 1 Гбіт / с) обчислення контрольної суми було б великим навантаженням для процесора, тому він завантажується на апаратне забезпечення NIC, яке розпізнає пакети TCP для відбитка, і воно не запропонує вам ту саму послугу.

UDP ідеально підходить для VoIP-адреси, куди потрібно надіслати пакет даних, зважаючи на меншу надійність ... Відео-чат - це приклад UDP (ви можете перевірити це шляхом зйомки мережею проводів під час будь-якого відеочаті). Також TCP не працює з Протоколи DNS та SNMP. У UDP немає накладних витрат, тоді як у TCP багато накладних витрат