Чому UDP з надійністю (реалізованою на рівні додатків) не замінює TCP?

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

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

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

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

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

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

Якщо програма не вимагає повсюдності (ваше програмне забезпечення працює з обох сторін) або не потребує всіх функцій TCP, багато людей вигідно використовують інші протоколи, часто поверх UDP. Приклади включають TFTP (мінімалістичний, з дійсно неефективним поводженням з помилками, QUIC, який призначений для зменшення накладних витрат (все ще позначений як експериментальний), та бібліотеки, такі як lidgren, які мають тонкозернистий контроль над тим, які саме функції надійності потрібні. [Спасибі коментатори. ]

UDP з надійністю дійсно може бути заміною TCP. У нас уже є приклад цього: він називається QUIC .

З Вікіпедії:

Серед інших додатків, QUIC покращує продуктивність веб-додатків, орієнтованих на з'єднання, які зараз використовують TCP. Це робиться шляхом встановлення декількох мультиплексованих з'єднань між двома кінцевими точками через протокол User Datagram User (UDP).

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

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

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

Однак протоколи над транспортним шаром тут не є темою.

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

UDP може надати додатковому шару більше контролю над трафіком ціною величезної роботи.

Відповідь на ваше запитання: іноді це робиться саме так. Ігри, які вимагають низької затримки, часто роблять саме це. Це набагато більше роботи, але можливість контролювати, скільки саме непогашених пакетів ви можете мати і як часто вони повторюються, часто того вартує.

Загальна відмінність полягає в тому, що TCP - це дуже хороша загальна реалізація цілей, але є конкретні цілі, завдяки яким UDP може зробити це TCP або дуже погано, або зовсім не - наприклад:

• НІКОЛИ не перестаючи (з TCP з'єднання іноді зависає, і вам доведеться розірвати з'єднання і перезапустити його)
• Надіслати швидкий потік пакетів, на які не потрібні відповіді, і ви не заперечуєте пропускати деякі з них (де важливий лише останній пакет, будь-які інші можуть бути відкинуті) - подумайте, що оновлення ігрової позиції - ви можете отримати трохи "Стрибайте", а не кожен крок, але ви отримуєте той же результат швидше і надійніше.
• Робота з iffy мережами, аналізуючи краплі пакетів та динамічно змінюючи, як часто та як швидко ви повторите спробу - можливо навіть максимальний розмір пакету.

Але в цілому це не варто, TCP є досить оптимальним, тому навіщо займатись усією додатковою роботою та додавати (великий) шанс додати помилки та недоліки безпеки?

UDP не швидкий, тому що це UDP. TCP не повільний, оскільки це TCP.

Обидва протоколи розроблені з певними гарантіями, і необроблений TCP має більше гарантій, ніж необроблений UDP.

І головне правило: ціна гарантій - це ефективність .

Ніщо не забороняє вам впроваджувати гарантії TCP над UDP. Але тоді ви отримуєте більше гарантій, і тому вам доведеться платити ціну. Тому ви знижуєте продуктивність до TCP або гірше (через накладні витрати UDP). Якщо ви не знаєте кращої реалізації TCP, що малоймовірно. І якщо ви зробите це (сподіваємось), ви розкриєте це, і ми зробимо стандартний TCP швидше. І ми повернулися з того, з чого почали. :)

Ви також можете пограти з цими гарантіями. Трохи модифікуйте це, трохи змініть це. І тоді ви закінчите протокол типу QUIC, який перебуває над UDP, і він дуже схожий на TCP + TLS. У багатьох випадках це швидше, ніж TCP (хоча, згідно з цією статтею, затримка до 5% та буферизація до 15%, що IMO не є великою справою), але в деяких сценаріях (наприклад, надійна мережа або відсутність потреби в шифруванні) насправді це повільніше (див. пояснення тут ).

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

Ваша ідея була б добрею в глибокому космосі.

Правильна відповідь - "це залежить" і "тому що це може зашкодити мережі в цілому". TCP / IP дуже доброзичливий до мереж і автоматично налаштовується на потрібну швидкість, щоб бути швидкою, але не генерувати тонни повернених пакетів ICMP.

Коли маршрутизатор з недостатньою оперативною пам’яттю раптом отримує багато будь-якого пакету - скажімо, від Tsunami, Bittorrent або FDT - він скидає його і повертає назад до відправника невеликий пакет відхилення підтвердження відмови. Тепер ваш UDP-сервер повинен відстежувати та повторно передавати цю частину вручну. Деякі маршрутизатори провайдерів формують Bittorrent так багато, що шкодить Цунамі?

Протокол Tsunami використовує UDP з каналом управління в TCP. http://tsunami-udp.sourceforge.net/ Я знайшов дослідження, яке показує, що воно відбувається повільніше, ніж те, що називається FDT.

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

UDP використовується ненадійними програмами: потокове аудіо, введення / оновлення гри IO, "ping" насправді ICMP, але це не гарантується, Bittorrent, mosh ssh чудово реагує, VOIP телефонія, багатоадресна передача, DNS надсилається через UDP AFAIK. Все, що не проти дивного пакету, що пропав, і може миттєво "наздогнати".

TCP / IP справді був убивчим винаходом, який дозволив розробникам додатків так просто встановити та забути. Сокет - це пара IP-адреси та порти, і вони були розроблені так, щоб можна було налаштувати і залишатися годинами, днями, навіть тижнями без повторного підключення. Електронна пошта, Інтернет, IRC та буквально всі програми-вбивці використовують TCP. Але ви можете отримати дивні паузи при завантаженні, які раптом проходять швидше ... і в глибокому просторі з’єднання можуть затримати час, завдяки чому передачі в стилі Цунамі найкраще підходять для міжзоряних передач файлів - ви можете бути на чомусь там !!

Підтвердженням є заключні зауваження цього витягу з наукового дослідження, в якому згадується про все більшу відстань, про яку я продовжую займатися: глибокий космос Від: https://uscholar.univie.ac.at/get/o:300623.pdf

Без перевантаженості продуктивність FDT і GridFTP з TCP вище, ніж Цунамі та UDT. Найвища пропускна здатність FDT - 2,34 Гбіт / с при RTT в 1 мс, але вона швидко зменшується після 100 мс порівняно з GridFTP, яка працює краще, ніж FDT, коли RTT зв'язку більше 100 мс. Цікаво, що пропускна здатність цунамі не зменшувалася внаслідок збільшення RTT, показуючи, що він має найбільш ефективний контроль заторів із збільшенням RTT.

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

TCP! = UDP + надійність

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

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

Щоб назвати кілька функцій, TCP має ...

• Створення та припинення з'єднань: виконує рукостискання та закриття з'єднання

• Контроль потоку: забезпечує передачу та одержувач передачі зі швидкістю, коли обидва можуть обробляти швидкість передачі даних.

• Кінцевий контроль перевантаженості: дозволяє кінцевим вузлам придушити пропускну здатність на основі втрат. Прочитайте про повільний старт, уникнення заторів та швидке відновлення.

На мій досвід, UDP використовується, коли швидкість викликає занепокоєння щодо надійності. Ви можете додати деякий рівень надійності на рівні програми, який не на 100% такий надійний, як TCP. Наприклад, якщо ви все ще хочете швидкої продуктивності, ви можете застосувати виправлення помилок вперед (FEC), куди ви передаєте дані не один раз. Ви все одно отримуєте хороші показники та певний рівень надійності (відзначте надійність TCP), не маючи чату назад і вперед, щоб втратити пакети. Робота полягає в тому, що вона збільшує використання мережі, але може бути придатною для додатків у режимі реального часу, таких як ігри чи потокове передавання.