Чи є UDP ще краще, ніж TCP, для ігор у реальному часі, важких для даних?

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

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

Це змушує мене задатися питанням: чи UDP все ще переважає з точки зору швидкості та затримки? Чи не змогли нещодавні оптимізації TCP зробити TCP краще, ніж UDP?

67
UDP краще, ніж TCP, якщо і тільки якщо ви в змозі (= досвідчений програміст низького рівня) повторно реалізувати тільки ті функції TCP, які вам потрібні в ньому ефективно. Скидання непотрібних функцій TCP для виконання.
додано Автор tetranz, джерело
Швидше реалізувати, але не потрібно швидше
додано Автор Eytan Levit, джерело
@nathan Простіше розробити свою програму за допомогою TCP, ніж UDP. Я хочу знати, чи всі оптимізації TCP зробили TCP кращим варіантом з точки зору продуктивності.
додано Автор Eytan Levit, джерело
Перегляньте SCTP .
додано Автор The How-To Geek, джерело
TCP не викидає з'єднання під час пакетної помилки, і для UDP немає з'єднання ...
додано Автор JFA, джерело
@nathan: Re: Ваш перший коментар ... це трохи вводить в оману, оскільки протокол не гарантує доставку, будь то TCP або UDP або що-небудь ще.
додано Автор grawity, джерело
TCP = з'єднання відкидається, якщо є одна невелика помилка (програма не має права), UDP = додаток вирішує, коли відмовитися від з'єднання (це означає, що UDP добре підходить для передачі даних, наприклад, онлайн-ігри, де підключення може бути схематичним). TCP є більш повільним, ніж UDP, але є більш надійним, оскільки UDP - це безперервний потік, в якому немає TCP (відповідь має бути отримана з іншого кінця, щоб повернути щось).
додано Автор marioman960, джерело
це вже 2016 рік, вже є деякі альтернативні протоколи, доступні ІМО. напр. "a = href =" noreferrer "> ця стаття перераховує деякі.
додано Автор dmyung, джерело
З UDP немає ніякої гарантії, що ваші пакети будуть отримані або навіть замовлені, що робить UDP швидше, ніж TCP.
додано Автор Tim Scarborough, джерело
@KaareZ Що ви маєте на увазі швидше реалізувати?
додано Автор Tim Scarborough, джерело
@KaareZ Я не експерт, але давайте подумаємо про це. Як TCP може бути кращим у термінах продуктивності і як і раніше бути надійним протоколом? Ви не можете мати все. TCP створений для надійності. Реальне питання полягає в тому, чому ви хочете використовувати TCP у вашій грі?
додано Автор Tim Scarborough, джерело
FYI WOW використовує TCP IIRC
додано Автор Cubic, джерело
Кілька років старі статті можуть бути 100% точними навіть сьогодні. Хоча незначні зміни були внесені як в TCP, так і в UDP, основні відмінності між ними такі ж, як і три десятиліття тому. Будь-які зміни в рекомендаціях щодо вибору між TCP і UDP частіше виникатимуть від введення нових протоколів, ніж від змін до TCP або UDP. Хоча з урахуванням поточного стану Інтернету, будь-які успішні нові протоколи, швидше за все, реалізуються як бібліотека поверх UDP, ніж як автономний транспортний протокол.
додано Автор Daithi, джерело
Одне з ключових питань, яке слід задати, це наступне: Ви б хотіли отримати 99% пакетів після 1 RTT або 99.99% після 2 RTTs? Якщо у вас є термін, після якого ви збираєтеся відхилити пізні пакети, то UDP підходить.
додано Автор Daithi, джерело
@wondra Дати UDP з особливостями TCP не потрібно робити з нуля. Див. бібліотеки C/C ++ , C# бібліотеки і Бібліотеки Java .
додано Автор Chris Steele, джерело
@KaareZ Ви відповіли на запитання? TCP є більш безпечним для використання в термінах втрати даних.
додано Автор Bálint, джерело
Тільки тому, що UDP не гарантує, що він надіслано, це не означає, що ви не можете гарантувати його. Ви можете самостійно розгортати дані, посилаючи дані на сервер. І ваш сервер відправляє зворотний виклик. Якщо ваш клієнт передає дані і не отримує зворотного виклику, це 50% шанс, що він не вдався. (Іншим є можливість, що сервер отримав його, але не зміг відправити зворотний виклик.) TCP також може знадобитися аналогічний зворотний виклик. Все, що ви знаєте - це не вдалося надіслати дані. Але ви все ще не знаєте, чи приймач опрацьовував його правильно. Отже, необхідно мати систему зворотного виклику, якщо ви хочете забезпечити надійність.
додано Автор Strukt, джерело

10 Відповіді

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

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

  1. Виявлено втрату першого оновлення.
  2. Запитується повторна передача першого оновлення.
  3. оновлено та оброблено повторну передачу.

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

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

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

EDIT - Додавання додаткової інформації для включення/розгляду деяких коментарів:

Як правило, швидкість втрати пакетів на Ethernet дуже низька, але вона стає набагато вищою після того, як задіяний WiFi або якщо користувач має завантаження/завантаження. Припустимо, що ми маємо абсолютно рівномірну втрату пакетів на 0,01% (один шлях, а не туди-назад). На шутер від першої особи клієнти повинні надсилати оновлення, коли щось відбувається, наприклад, коли курсор миші повертає гравця, що відбувається приблизно 20 разів на секунду. Вони також можуть відправляти оновлення на кадр або на фіксований інтервал, який буде 60-120 оновлень в секунду. Оскільки ці оновлення надсилаються в різний час, вони повинні/повинні бути відправлені в одному пакеті за кожне оновлення. На 16-ігровій грі всі 16 гравців відправляють ці 20-120 пакетів в секунду на сервер, в результаті чого загалом 320-1920 пакетів в секунду. З нашою швидкістю втрати пакетів 0,01%, ми очікуємо втратити пакети кожні 5,2-31,25 секунди. У цьому прикладі ми ігноруємо пакети, відправлені з сервера гравцям для простоти.

На кожен пакет, який ми отримуємо після втраченого пакета, ми надішлемо DupAck і після 3-го DupAck відправник буде повторно передавати втрачений пакет . Таким чином, час TCP вимагає, щоб ініціювати повторну передачу, це 3 пакети, плюс час, який потрібно для останньої DupAck, щоб прийти до відправника. Потім ми повинні чекати ретрансляції, щоб прийти, так що в цілому ми чекаємо 3 пакети + 1 затримка. Затримка на зворотному шляху зазвичай становить 0-1 мс у локальній мережі і 50-200 мс в Інтернеті. 3 пакети, як правило, надходять через 25 мс, якщо ми надсилаємо 120 пакетів в секунду, і в 150 мс, якщо ми надсилаємо 20 пакетів в секунду.

На відміну від UDP ми відновлюємося від втраченого пакета, як тільки отримаємо наступний пакет, тож втрачаємо 8,3 мс, якщо надсилати 120 пакетів в секунду, і 50 мс, якщо надсилати 20 пакетів в секунду.

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

114
додано
@Peter ви забуваєте, що в TCP кожен пакет скинув всі пакунки. З 100 мс пінг він може легко бути 300-500ms, перш ніж цей пакет повторно передається і отримав, так що це 6-10 пакетів, які затримуються кожні 33 секунди. Це буде безумовно помітним у фокусі, подібному до землетрусу.
додано Автор DLS3141, джерело
"Один клієнт, повинен знати принаймні про 15 інших, це 300 повідомлень в секунду." Повідомлення! = Packets, будьте обережні. Тим не менш, звичайно, UDP є переважною системою для гри з поштовхом.
додано Автор lethargicpanda, джерело
З грою, як Quake, втрата першого пакета не має значення. У FAR менше часу, ніж вам знадобиться для виявлення втрати і повторної передачі першого пакета, ви повинні вже передавати другий пакет, який у будь-якому випадку робить перший пакет застарілим. Це та сама причина, чому багато голосових і відеододатків реального часу також використовують UDP. Якщо пакет опускається, ви досить просто втратите 0,02 секунди звуку, ніж затримати весь потік на повну секунду або більше. Як правило, це стосується ігор у реальному часі, якщо ви хочете знати, де знаходиться об'єкт зараз , а не 1,5 секунди тому.
додано Автор Ashley, джерело
У багатьох реалізаціях TCP перший тайм-аут після пропущеного ack займе повну секунду. Це довгий час. Якщо пакети невеликі, UDP може легко згладжуватися через пропущену передачу або дві, просто маючи кожен пакет включати дані з двох останніх оновлень, щоб програма отримала необхідні дані, перш ніж відправник або одержувач могли знати, що перший пакет пропав.
додано Автор Brad Roekle, джерело
@NateKerkhofs Так, це те, що я намагаюся передати - ймовірність того, що потрібно чекати повторної передачі втраченого пакета TCP.
додано Автор Chris Steele, джерело
"Якщо ви надсилаєте 2 оновлення на TCP, а пакет першого оновлення втрачається" Правда, але які шанси виникають? Відповідно до pingman : "Все, що втратило більше 2% пакетів протягом періоду часу сильний індикатор проблем. "
додано Автор Chris Steele, джерело
@mucaho Ці оновлення, ймовірно, не єдині оновлення, і вони можуть складатися з більш ніж 1 пакета. якщо кожне інше оновлення має невдалий пакет, я погоджуюся, що у вас виникли проблеми. але це більше схоже на 1 у 50 або 1 на 100 оновлень, якщо це не так.
додано Автор Yei, джерело
Примітка: UDP може транслювати локальну мережу (можлива перевага), і оскільки Vista вимагає від адміністратора запуску сервера/трансляції на UDP (недолік) (UAC/брандмауер, як правило, не повідомляє про необхідність дії користувача).
додано Автор shanef22, джерело

Ми погоджуємося, що як протоколи TCP, так і UDP - це протоколи, побудовані на основі IP , чи не так? IP визначає, як повідомлення доставляються через Інтернет, але ніщо не стосується структури повідомлень, формату. Тут приходять протоколи TCP і UDP. Вони використовують властивості IP, але дозволяють програмісту зосередитися на обміні повідомленнями, не турбуючись про нижчі шари мережевого зв'язку. І це здорово, тому що справа з аналоговими сигналами в проводах безпосередньо буде болючою.

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

  • З іншого боку, UDP - це протокол, орієнтований на керування користувачами. Використовуючи UDP для відправки дейтаграм , ми не можемо бути впевнені, що датаграма ніколи не прийде до місця призначення або не буде (ми маємо на увазі математичну впевненість: коли ми надсилаємо пакет, він, ймовірно, прибуде, але ми не можемо бути впевнені на 100%). Крім того, коли пакет втрачається, він не буде виявлений і не буде відправлений знову.

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

BUT, look beyond. The only advantage UDP gives us is its speed, and that's right the one thing we really want. A UDP packet is just crafted, sumchecked and sent without any particular controls, because that's how UDP protocol works. A TCP packet must be crafted, labeled, sumchecked, and when it arrives an ACK is sent back to tell the sender "packet x is here, keep going", and when this signal is not sent then that means such packet x must be sent again.

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

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

TCP викликає тремтіння, коли затримка достатньо висока, UDP не:

<div class="snippet" data-lang="js" data-hide="false" data-console="false" data-babel="false"> <div class="snippet-code">

</div> </div>

Це змушує мене дивуватися, якщо UDP все ще переважає з точки зору швидкості та затримки.

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

17
додано
@supercat: WiFi є дешевим, тому що це нерозумно, але правильним рішенням було б приховати свої фізичні проблеми з IP-шару. Тобто, повинні бути буфери і повторно функціонувати на обох кінцях бездротового каналу. Немає сенсу повторно пересилати пакет з іншої сторони світу тільки тому, що остання посилання відкинула його. Наприклад, мережа Ethernet могла мовчки пересилати пакети ще в 1990 році.
додано Автор Jon Schneider, джерело
-1. Це найбільш плутане мікспояснення на різниці TCP і UDP. TCP - це протокол, орієнтований на з'єднання, він створює віртуальний сокет (надійний, упорядкований, двосторонній потік) між двома машинами через мережу з комутацією пакетів. TCP не має нічого спільного з повідомленнями або дейтаграмами. І я не думаю, що ви маєте чітке розуміння різниці між затримкою або швидкістю.
додано Автор DevSolar, джерело
@supercat Хм ... Ви можете мати рацію щодо сучасних розширень, хоча це, звичайно, не є частиною оригінального стандарту TCP. ACK просто має порядковий номер. Я припускаю, що реалізація TCP, як правило, почне повторну передачу всього вікна відправки, якщо пакет опускається, а не чекає весь RTT для кожного пакета. Це додасть величезну кількість затримок, якщо декілька послідовних пакетів було втрачено для дуже невеликого посилення.
додано Автор Ashley, джерело
@Giorgio IP нічого не говорить про аналогові сигнали. Це робиться на фізичному рівні. IP працює два шари вище, ніж на мережевому рівні. IP-протокол не турбує, чи біти переходять через оптоволоконний зв'язок, супутниковий зв'язок або комутований модем на 14,4 кбіт/с. UDP і TCP є шаром від IP, на транспортному шарі. Крім того, як і суперкадр, TCP представляє потоковий інтерфейс до програми, а не інтерфейс дейтаграми, як UDP.
додано Автор Ashley, джерело
@supercat На жаль, TCP не має жодного способу повідомити відправника, які саме пакети він зробив і не отримав. Вона має лише механізм для "Я отримав усі байти по x порядковий номер". Якщо відправник повторно передає пакети, які приймач вже отримав, він просто ігнорує копії.
додано Автор Ashley, джерело
@reirab: Я думав, що є деякі сучасні розширення, які включали цю функцію, хоча навіть без того, що я думаю, що реалізація, яка посилала дані до байту # 1,050,000, але тільки отримала acks для даних до 1000000, після другої без слухання будь-який акк для будь-якого минулого 1000000, почніть з відправки блоку даних від 1 000 000 до 1 500 500 чи так, а потім чекайте відповіді. Якщо він отримує дані для аж до 1,000,500, він може повторно передати більше даних; якщо він отримує дані для даних до 1050 000, він може пропустити повторні передачі.
додано Автор Brad Roekle, джерело
TCP використовує потоки байтів, а не дейтаграми. UDP використовує дейтаграми. Хороші реалізації TCP зберігатимуть пакети, які надходять з ладу, але вміст пакета не може бути доступним для програми, якщо або поки не будуть отримані всі попередні пакети. Таким чином, якщо один пакет втрачається, відправник може не потребувати повторної передачі всього, що слідує за втраченим пакетом, але прийомна програма не побачить нічого, що пройшло через втрачений пакет, доки цей пакет не буде повторно переданий (після чого програма миттєво побачить вміст цього пакета) пакет і після нього).
додано Автор Brad Roekle, джерело
... які викликають резервне копіювання або відкидання пакетів, навіть якщо немає перевантажень, і немає сенсу, щоб шар TCP був зашифрований для повторної передачі копії даних, які все ще сидять у черзі передачі на рівні WiFi; На жаль, для TCP-шару не існує способу дізнатися, які пакети успішно залишили локальну машину, навіть думаючи, що він буде знати, що він.
додано Автор Brad Roekle, джерело
@reirab: Я б не очікував, що реалізація чекає весь RTT після кожного пакета (метою цього вікна є уникнути цього), але після тайм-ауту тимчасово зменшує ефективний розмір вікна до вартості пакета, доки хтось не почує щось з віддаленого кінця, часто буде мати хороші ефекти і рідко мати якісь значні погані. Якщо виявиться, що пропущено лише один пакет, вам не доведеться повторно передавати щось інше, ніж пропущений пакет. Я думаю, що загальна концепція "мережевого стека" є поганою для багатьох сучасних технологій (оскільки WiFi може мати умови ...
додано Автор Brad Roekle, джерело
@MSalters: Є буфери і повторно функціональність на обох кінцях посилання. Проблема полягає в тому, що якщо резервне коротке відставання зросте більше, ніж тайм-аут пакета, це призведе до того, що кожен пакет повинен бути надісланий два рази, що призведе до подальшого зростання обсягів повернення.
додано Автор Brad Roekle, джерело
@reirab: суперкарт, безумовно, має рацію. RFC 2018 "https://tools.ietf.org/html/rfc793" rel = "nofollow noreferrer"> RFC 793 ), як зазначено Стаття Вікіпедії для" Ретрансляції (мережі передачі даних) ". Таким чином, це не було в TCP в 1981 році, але це було приблизно з 1996 року, так що багато людей були навчені, що сучасні реалізації TCP можуть отримати детальну інформацію про успішні пакети, щоб вони не повинні бути повторюються.
додано Автор Jeff Dik, джерело

TCP <- Transmission Control Protocol. It's made to control transmission.

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

  • Приймач виявляє відсутній пакет, сповіщає відправника про сповільнення (Удвічі скоротіть ставку).
  • Приймач виявляє неправильний вхідний порядок пакетів (можливо, вони приймають різні мережеві шляхи), повідомляє відправника про сповільнення - і btw, приймач не прийме додаткові пакети, поки не ввійде у відсутність. вимагає часу.
  • Відправник виявляє перевантаженість мережі (наприклад, повільний час повернення), додає затримку.
  • Приймач не може встигати за швидкістю (буфер вводу стає занадто повний), просить відправника додати затримку (контроль потоку).
  • Серед приймачів є один повільний приймач (високошвидкісний скарбниця, плачук, що вони називають), затримка (може бути), додана в домогосподарстві.

Додатково

  • Алгоритм Нагеля може тримати дані відправника на утриманні, поки не буде s більше для відправки (для більш ефективного використання кадрів даних). Часові дані затримуються.
  • Я вважаю, що звичайні домашні маршрутизатори з wlan можуть робити розумні речі (сповільнювати), щоб згладити пропускну здатність TCP між декількома клієнтами (інтерфейс wlan є вузьким місцем, навіть якщо гра не використовується). Відноситься до мовлення/багатоадресної передачі, тобто. "інші" дані можуть зменшити пропускну здатність TCP.
  • TCP ACKnowledge (Всесвідчення про призначення) - все, що не є необхідним для ігрового середовища. Існує ніякого сенсу в ACKing кожного окремого оновлення фізики. Досить знати, наприклад, один раз в секунду або аналогічно. Якщо клієнт (або сервер) довше мовчить, то настав час реагувати.

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

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

9
додано
Це протокол контролю передачі .
додано Автор jhappoldt, джерело
Примітка: алгоритм Nagle можна вимкнути, наприклад для linux .
додано Автор Chris Steele, джерело
Введіть ці слова мільйон разів ... thx - фіксовано.
додано Автор Stormwind, джерело
Nagle може працювати проти (і може бути відхилено, встановивши кожен пакет на "натискання" за допомогою програми), в той час як Delayed Ack працює в користь TCPs, це дозволяє відправнику покласти більше байтів на дріт, поки вікно відправки не буде заповнене як буфер прийому знаходиться з іншої сторони), незалежно від того, було видно ack.
додано Автор Jcr, джерело

Можна порівняти першу діаграму RFC 768 (UDP) з першою діаграмою RFCP 793 (TCP) сторінка 15 .

Both show 16 bits for a “source port” followed by 16 bits for a “destination port”. Both show 16 bits for a “checksum”. According to RFC 768, UDP's “checksum procedure is the same as is used in TCP.”

Whereas UDP's Length wraps up the details of UDP's diagram, TCP's length is part of a “a 96 bit pseudo header” described on page 15 and 16.

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

The other reason is that TCP's “three way handshake” means that the sender must wait for a response. This requirement introduces additional overhead that UDP doesn't handle. There's a reason why most of your Internet communications start with some UDP communication. Basic DNS uses UDP because a request and a response can be completed in fewer steps than TCP's “three way handshake” process. TCP's feature of keeping track of lost packets is rather unexciting, because a computer could simply make a new request rather than trying to let a remote system know that there is an unfulfilled prior request.

3
додано
Ви маєте на увазі 16 біт, а не байти!
додано Автор Zeppelin, джерело
О, дурний мені. Це приклад того, чому технічно точні відповіді хороші; їх легко визначити та побачити правильну інформацію. Я виправив відповідь. Дякуємо @jcaron
додано Автор Jeff Dik, джерело
Хоча англійські резюме (як видно в деяких інших відповідях) приємні, просто наявність точних і точних описів може бути найпростішим.
додано Автор Jeff Dik, джерело

У MPG з високою пропускною здатністю, ви не дбаєте, якщо ви пропустили пакет, що дає вам розташування і здоров'я монстра # 425, тому що ви будете отримувати інше оновлення в деякі частки секунди. Це і приклад, де UDP робить TCP виглядати нерозумно, тому що ви чекаєте миттєво застарілих даних.

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

Ось простий опис того, що відбувається.

UDP - Ізолювати шматок O'data.
   Зробіть пакет.
   Інкапсулювати в IP.
   Судно.

TCP - Виділення потоку O'data.
   Зробіть пакет з фронту потоку.
   Інкапсулювати в IP.
   Зачекайте пробіл у вікні TCP.
   Судно    Продовжуйте повторне надсилання, доки не буде отримано квитанцію або таймаут    Залишайтеся в вікні TCP, доки не буде отримано квитанцію або таймаут.

Доставка просто означає, що вона зробила це через місцеві NIC, не більше.

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

Повторне надсилання (трохи) збільшує ймовірність можливого отримання.

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

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

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

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

P. (Я не можу додавати коментарі до відповідей на коментарі)   UDP також добре підходить для даних, які є бажаними, але не потрібними. Попередня корекція помилок є прикладом цього, багато непотрібних, але бажаних пакетів.

2
додано
Ваша думка про "застарілі" дані - хороша. TCP добре підходить для даних "краще пізно, ніж ніколи", але UDP хороший для даних, які будуть корисні, якщо він швидко досягне призначення, але марно, якщо цього не станеться.
додано Автор Brad Roekle, джерело

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

Ваші припущення неправильні. TCP і UDP відрізняються насамперед тим, яку модель вони представляють (ненадійні дейтаграми проти надійного віртуального потоку).

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

За наявності втрати пакетів, два роблять відмінності в латентності, але тільки в такому стані. В іншому випадку TCP має таку ж низьку затримку, що і UDP (дає або може приймати кілька десятків наносекунд, тому що мережевий стек має трохи більше логіки, але це досить незначний). Існує незначна різниця в розмірі заголовка, тому технічно більше байтів повинно зробити це через дроти на послідовних лініях, але це досить несуттєво. Це дійсно важливо лише для масових переказів, і тоді це приблизно 0,5% різниці. Більшість людей, що мають домашній DSL доступ до Інтернету, передають весь свій трафік через банкомат, який додає до 10% накладних витрат протоколу (5 байтів для 48 байтів корисного навантаження, а також часткові кадри), і ніхто навіть не помічає.

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

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

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

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

Note by the way that packet loss is a normal condition. While IP is generally "quite reliable", packets occasionally being dropped can happen, and will happen. While packets being lost is normally rather on the rare side (<1% here), it is not something extraordinary or theoretical, or an indication that something is broken. It is perfectly normal.
Every TCP bulk transfer will necessarily include lost packets, for example (it's how the congestion control works).

2
додано

Подумайте, що відбувається на мить. Щоб спростити сценарії, у вас є два варіанти, коли ви намагаєтеся відправити зміну стану (наприклад, ваш гравець просто змінив напрямок, або вистрілив пістолет, або якийсь інший гравець просто випустив бомбу):

  1. Відкрити сеанс TCP, а коли вимкнути бомбу, відправте повідомлення всім гравцям (якщо це можливо, див. нижче)
  2. Прослуховувати порт UDP, а коли вимкнути бомбу, відправте повідомлення UDP всім гравцям незалежно від стану з'єднання

Припускаючи, що не було оновлення, необхідне перед ним, час, коли це єдине оновлення прибуває в 1 vs 2 не буде дуже різним. Це одна поїздка від сервера до клієнта. Але, скажімо, замість того, щоб вибухати бомба, ви намагаєтеся постійно передавати активність когось, що біжить по лабіринту; ткацтво, утеплення, зйомка тощо. У випадку UDP кожна дія буде відправлена ​​в дейтаграмі, як тільки це станеться. У випадку TCP кожна дія буде надіслана в пакеті, тільки якщо серверу дозволено відправляти. Що говорить, що дозволено відправляти? Маючи кімнату у вікні TCP (якщо активована затримка ack), то повідомлення можна поставити на дріт. Якщо ні, то він повинен чекати, поки ack прибуде від клієнта перед відправкою.

Скільки довго? При розробці мультиплеєра від першої особи стрілялка в кінці 90-х і на початку 2000-х років зв'язки з низькою затримкою не були поширеними. Модем модему буде мати типову односторонню затримку 180ms. Чекаючи на акк перед тим, як відправити інше оновлення, що фактично подвоїло цей час до 360мс, було боляче; навіть початківці користувачі могли відчути різницю. Коли широкосмугові підключення потрапили в дію, вони значно зменшили затримку, але все ще зберігалися, коли пропускна здатність була недостатньою (досить часто в деяких областях). Таким чином, переваги для найменшої можливої ​​затримки зберігалися.

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

2
додано
Час затримки буде достатньо низьким, за винятком того, що за промовчанням запису TCP надсилаються лише тоді, коли відбувається перетинання певних даних або перевищення часу (зазвичай 200-1000мс). Якщо вам потрібен протокол TCP на системі з низькою затримкою з малою пропускною спроможністю, ви повинні вимкнути цю функцію і переконайтеся, що ви не записуєте окремі байти весь час (наприклад, ви більше не обробляєте потік TCP як потік, і ви робите вигляд, що ви маєте справу з окремими повідомленнями). Вам не доведеться чекати ACK, якщо ваші буфери не заповнені, що навряд чи відбудеться в типовій грі в реальному часі.
додано Автор user42225, джерело
@Luaan Введіть: прапор TCP PSH. Коли програма подає його вниз по стеку, пакет відправляється негайно без очікування додаткових даних. Багато програм використовують це успішно (наприклад, telnet і ssh).
додано Автор Jcr, джерело

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

Порівняння протоколів

Взагалі кажучи, UDP (User Datagram Protocol) надає найменшу кількість функцій. Це спрощується тим, що ви надсилаєте дані без будь-якого отримання/підтвердження.

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


Приклад: Skype конференц-дзвінок

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

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


Вибір реалізації

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

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

1
додано

Чи зробили всі маршрутизатори, оптимізовані для TCP, краще виконання TCP, ніж UDP?

Ще одне питання: чи означає "дані важкі" означає, що ви часто завантажуєте сцени?

If yes, you may need to send large pieces of data (>1k) intensively in which TCP may be much more efficient because especially on the server side the NICs will provide various offloads which same lot of cycles. A user space application may issue large writes with TCP while in UDP an attempt to send more than MTU-headers size bytes will cause IP fragmentation and other overheads which will kill performance

1
додано
Це "воксельна" гра, так що так, вона повинна буде відправити багато даних сцени.
додано Автор Eytan Levit, джерело
@KaareZ Добре, ви, напевно, хочете відправити їх у вигляді окремих незалежних повідомлень у цьому випадку так чи інакше, за допомогою власних механізмів ретрансляції. Minecraft почав працювати на TCP, і через Інтернет було неможливо відтворити; перехід на UDP був щасливим приводом для більшості людей. Основна ідея полягає в тому, що коли ви надсилаєте 20 шматочків воксельних даних, а перша "втрачається", вона не повинна блокувати інші 19 блоків від показу, як тільки отримаєте дані; коли ви виявите, що перша відсутня, ви повторно пересилаєте. На TCP всі ці 19 припиняються, принаймні, і передаються в найгіршому випадку.
додано Автор user42225, джерело
@Luaan Minecraft не перейшов до UDP для фактичного ігрового процесу. Навіть останні версії все ще використовують TCP. Ніякого щасливого випадку ... :( Єдина частина Minecraft, яка використовує UDP, є списком серверів, для того, щоб пінгувати окремі сервери і визначити, чи є вони онлайн.
додано Автор Alex G.P., джерело

Я помітив багато коментарів, коли люди вважають, що TCP-пакети більше, ніж UDP-пакети. Не просто довіряйте мені, читайте документацію. Протокол є наступним: кілька байт для заголовка Ethernet (2 байти типу повідомлення, 48 біт MAC, 6 байт) (для Wifi, заголовок може відрізнятися) 20 байтів для IP 20 байтів для TCP або UDP x байтів для даних x від 0 до 1500 (див. MTU) Нарешті, контрольна сума, щоб переконатися, що не було корупції в цьому пакеті Ethernet.

TCP дозволяють відправляти більший "потік" пакета близько 64К. Цей "великий" блок фактично рубається в багатьох дрібних пакетах Ethernet.

1
додано
Ви намагаєтеся припустити, що заголовки UDP і TCP мають однаковий розмір?
додано Автор Marja Erwin, джерело
IT KPI C/С++ новым годом
IT KPI C/С++ новым годом
747 учасників

Чат обсуждения С/С++. - Вопросы "напишите за меня лабу" - это оффтоп. - Оффтоп, флуд, оскорбления и вбросы здесь не приняты. - За нарушение - предупреждение или mute на неделю. - За спам и рекламу - ban. Все чаты IT KPI: https://t.me/itkpi/1147