UDP против TCP, насколько это быстрее? [закрыто]

194

Для обмена сообщениями общего протокола, который может допустить некоторую потерю пакета. Насколько эффективнее UDP по TCP?

Net Citizen
источник
Вы также можете добавить тег "tcp", так как вопрос также касается TCP.
Кристиан Чиупиту
5
Что означает «общий обмен сообщениями протокола»? Вопрос должен уточнить, что такое эффективность. Мы хотим меньше задержки для маленького сообщения? Или мы хотим более высокую пропускную способность для непрерывного потока данных?
Йохан Буле
Tcp обладает более лучшими возможностями, чем UDP, за исключением скорости.
РАДЖКУМАР НАГАРЕТИНАМ
3
Вопрос о скорости TCP / UDP спорен. Вопрос в вашем заголовке на самом деле не соответствует основному вопросу. Пакеты TCP и UDP передаются с одинаковой скоростью на одной и той же среде.
Рон Мопин

Ответы:

86

UDP быстрее, чем TCP, и простая причина заключается в том, что его несуществующий пакет подтверждения (ACK), который разрешает непрерывный поток пакетов, вместо TCP, который подтверждает набор пакетов, рассчитывается с использованием размера окна TCP и времени приема-передачи (RTT).

Для получения дополнительной информации я рекомендую простое, но очень понятное объяснение Skullbox (TCP против UDP)

Фернандо Баррокаль
источник
19
На самом деле во многих случаях TCP работает быстрее, чем UDP. Смотрите мой ответ ниже.
Роберт С. Барнс
2
Что быстрее, зависит полностью от характеристик трафика.
4
Хотя ответ может быть правильным, он не отвечает на вопрос и повторяет знания, упомянутые в других местах неоднократно. Также не упоминается, что надежные методы UDP с ACK могут быть заметно быстрее, чем TCP.
Эллиот Вудс
268

Люди говорят, что главное, что дает TCP, - это надежность. Но это не совсем так. Самая важная вещь, которую TCP дает вам, - это контроль перегрузки: вы можете запустить 100 соединений TCP через канал DSL, все они будут работать на максимальной скорости, и все 100 соединений будут продуктивными, потому что все они «чувствуют» доступную пропускную способность. Попробуйте сделать это с 100 различными UDP-приложениями, посылая все пакеты как можно быстрее, и посмотрите, насколько хорошо у вас все получится.

В более широком масштабе это поведение TCP - то, что удерживает Интернет от «заторов».

Вещи, которые стремятся подтолкнуть приложения к UDP:

  • Семантика групповой доставки: надежную доставку группе людей можно сделать гораздо эффективнее, чем подтверждение TCP-точка-точка.

  • Неупорядоченная доставка: во многих приложениях, пока вы получаете все данные, вам все равно, в каком порядке они поступают; Вы можете уменьшить задержку на уровне приложения, приняв неупорядоченный блок.

  • Недружественность: на вечеринке в локальной сети вам может быть все равно, будет ли ваш веб-браузер работать нормально, пока вы загружаете обновления в сеть так быстро, как только можете.

Но даже если вы заботитесь о производительности, вы, вероятно, не захотите использовать UDP:

  • Теперь вы на пути к надежности, и многие вещи, которые вы могли бы сделать для обеспечения надежности, могут оказаться медленнее, чем то, что уже делает TCP.

  • Теперь вы недружелюбны к сети, что может вызвать проблемы в общих средах.

  • Самое главное, брандмауэры заблокируют вас.

Вы можете потенциально преодолеть некоторые проблемы с производительностью и задержкой TCP, "соединяя" несколько соединений TCP вместе; iSCSI делает это, чтобы обойти контроль перегрузки в локальных сетях, но вы также можете сделать это для создания канала срочных сообщений с малой задержкой (поведение TCP «URGENT» полностью нарушено).

tqbf
источник
18
Хороший ответ, я бы даже пошел более общий, «контроль потока» (в отличие от контроля заторов, который является подмножеством контроля потока). Не только несколько соединений TCP могут совместно использовать одну ссылку, но это также предотвратит переполнение буфера отправителем, если они по какой-либо причине приостановят обработку входящих данных.
Алекс Б
1
@AaronLS: потери пакетов и RTT (время возврата туда и обратно) (которые можно рассматривать как прокси для задержки в очереди ) есть / могут быть (например: сети WiFi могут терять пакеты без реальной перегрузки, что вводит некоторые алгоритмы управления перегрузкой TCP во избежание перегрузки) показатели перегруженности.
ниндзяль
2
UDP - ублюдок, с которым приходится иметь дело ... Я уже облажался. Неважно, что я делаю, я не могу найти баланс между производительностью, задержкой, пропускной способностью и надежностью. Отлично подходит для таких вещей, как таймеры ... но я работаю над заменой TCP, используя UDP и прямое исправление ошибок, и это намного сложнее, чем я думал. Контроль заторов. Универсальная система, которая работает в сетях 1 ГБ и в беспроводных сетях, является произведением искусства. Я чувствую, что пытаюсь собрать пакеты, которые были загружены в дробовик.
Джейсон Нельсон
1
Между прочим, в пользу TCP является то, что он изначально ориентирован на соединение, что значительно упрощает логику обработки клиента приложения ( listen-> accept-> состояние клиента естественно не зависит от других клиентов). Обработка нескольких соединений от одного клиента, в частности, становится сложной с UDP. И точка зрения в пользу UDP заключается в том, что стеки UDP действительно просты в реализации, что является огромным преимуществом для встраиваемых систем (микроконтроллеров, FPGA и т. Д., В частности, реализация TCP для FPGA - это то, что вы просто хотите купить у кого-то другого). и не думать)
Джейсон С
1
Все это стоит только при условии, что мы заинтересованы в доставке значительных данных (не слишком заботясь о задержке). В довольно многих приложениях (игры / VoIP) ситуация кардинально отличается: у нас очень небольшое количество данных, но мы заботимся о задержках ОЧЕНЬ много; Именно эта простая вещь составляет 99% законного использования UDP. И несколько мелочей: (а) групповая доставка НЕ ​​работает через Интернет (и вряд ли когда-либо будет), так что это область только для Интранета; (б) в Google только 8-9% интернет-пользователей имеют проблемы с UDP, (в) «недружелюбная сеть» не распространяется на поток с фиксированной скоростью
No-Bugs Hare
93

В некоторых приложениях TCP работает быстрее (лучше), чем UDP.

Это тот случай, когда выполняется много небольших записей относительно размера MTU. Например, я читал эксперимент, в котором поток 300-байтовых пакетов отправлялся через Ethernet (1500-байтовый MTU), а TCP был на 50% быстрее, чем UDP .

Причина в том, что TCP будет пытаться буферизовать данные и заполнить весь сегмент сети, что позволит более эффективно использовать доступную пропускную способность.

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

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

Роберт С. Барнс
источник
3
Я на самом деле сделал тесты на этот счет. Я отправлял пакеты такого размера, который поддерживал бы UDP, без выдачи исключений (в Java), а TCP был намного быстрее. Я полагаю, что многие оптимизации ОС, драйверов и оборудования также являются частью этого.
Чарли
14
@Myforwik: Во-первых, это не определяется реализацией, это часть протокола TCP. Это называется алгоритм Нейгла. Это помогает предотвратить так называемый синдром Глупого окна. Посмотрите оба условия. Во-вторых, нет концепции пакетов от TCP от pov. Наконец, в книге «Эффективное программирование TCP / IP» целая глава посвящена этой теме, а во многих других главах - соответствующему вопросу о том, когда использовать TCP против UDP. Я поднимаю эту ситуацию (которая на самом деле довольно распространена), потому что ФП задал общий вопрос, и это один из многих возможных ответов.
Роберт С. Барнс
46
@Myforwik. Предлагая моронизм другим, постарайтесь понять, что у всех нас есть пробелы в наших знаниях, включая вас. Так что, в конце концов, это форум для обмена знаниями. Практически все шутеры от первого лица используют UDP, и они редко отправляют пакеты с размерами, близкими к MTU. Если вы хотите пойти и предложить Джону Кармаку, какой он придурок за то, что придумал такой подход, я бы посоветовал вам сначала тщательно изучить себя в этом отношении. 15 лет, и ценность высокопроизводительного сетевого кода отрасли не ложится и не умирает, потому что вы думаете, что он "дебильный".
инженер
2
« Я читал эксперимент, в котором поток 300-байтовых пакетов отправлялся через Ethernet (1500-байтовый MTU), а TCP был на 50% быстрее, чем UDP. » - не могли бы вы связать этот эксперимент?
Левиафан
3
@Leviathan Это в книге Эффективное программирование TCP / IP.
Роберт С. Барнс
31

с потерей терпимости

Вы имеете в виду "с потерей терпимости"?

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

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

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

К счастью, некоторые очень умные люди сделали это, и они назвали это TCP.

Подумайте об этом следующим образом: если пакет пропадает, вы бы предпочли просто получить следующий пакет как можно быстрее и продолжить (использовать UDP), или вам действительно нужны эти пропущенные данные (используйте TCP). Накладные расходы не будут иметь значения, если вы не находитесь в самом крайнем случае.

Орион Эдвардс
источник
1
5 пакетов из 100? Это довольно много. Я думаю, это всего лишь пример. Вопрос: в реальной ситуации сколько пакетов может быть потеряно? Потому что, если это, например, 2 из 10000 (плюс минус 1), я бы об этом не беспокоился.
причудливый
1
@ странно, да, это был просто пример. Фактическая сумма потери пакетов зависит от вашего соединения, восходящих сетей и т. Д. Я играл во многие онлайн-игры, и я обнаружил бы, что если бы я использовал только интернет-соединение, я не получил бы потери пакетов, но как только я запускаю фоновую загрузку, я начинаю получать некоторые (возможно, 10% -20%). Это было около 5 лет назад, и более быстрое подключение к Интернету может помочь.
Орион Эдвардс
2
Интернет-роутеры сбрасывают UDP до tcp
user1496062
19

Какой протокол работает лучше (с точки зрения пропускной способности) - UDP или TCP - действительно зависит от характеристик сети и сетевого трафика. Роберт С. Барнс, например, указывает на сценарий, в котором TCP работает лучше (записи небольшого размера). Теперь рассмотрим сценарий, в котором сеть перегружена и имеет трафик TCP и UDP. Отправители в сети, использующие TCP, будут ощущать «перегрузку» и снижать скорость отправки. Однако UDP не имеет никаких механизмов предотвращения перегрузки или контроля перегрузки, и отправители, использующие UDP, будут продолжать загружать данные с той же скоростью. Постепенно отправители TCP будут снижать свои скорости отправки до минимума, и если у отправителей UDP будет достаточно данных для отправки по сети, они увеличат большую часть доступной пропускной способности. Итак, в таком случае, Отправители UDP будут иметь большую пропускную способность, так как они получают большую долю пропускной способности сети. Фактически, это активная тема исследования - Как улучшить пропускную способность TCP при наличии трафика UDP. Я знаю один способ, с помощью которого приложения TCP могут улучшить пропускную способность, - это открыть несколько соединений TCP. Таким образом, даже если пропускная способность каждого TCP-соединения может быть ограничена, общая сумма пропускной способности всех TCP-соединений может быть больше, чем пропускная способность для приложения, использующего UDP.

gjain
источник
2
Это не правильно, маршрутизаторы сбросят UDP перед TCP. По общему каналу вы можете утонуть по UDP, но то, что может произойти в ситуации избыточного предложения, зависит от технологии, но для UDP довольно легко ухудшиться до такой степени, что его отправляют лишь при коллизиях.
user1496062
Мне нравится ваше объяснение, но не получите одно очко. Если UDP-соединения могут получить весь трафик (если пропускная способность мала или высока скорость передачи данных), в этом случае ваше приложение, использующее TCP, в основном является заложником тех, кто использует UDP. Если все приложения используют TCP, то они «хорошо играют» друг с другом. Тогда зачем разрешать UDP на раутере?
Игорь Чордаш
@PSIXO: Ну, TCP и UDP отвечают различным требованиям приложений, поэтому оба они используются приложениями. Смысл вашего предложения состоит в том, что у нас должна быть другая сетевая инфраструктура для трафика TCP и UDP - дорогое предложение, и, конечно, мы не можем сделать это сейчас, особенно с учетом всех уже сделанных инвестиций. Вот почему исследователи заняты поиском альтернативных способов сбалансировать конфликт в «программном обеспечении».
gjain
По сути, да, наличие двух инфраструктур было бы идеальным решением, но, к сожалению, это неправдоподобно. Что я хотел сказать своим комментарием, так это то, что вы преувеличиваете попадание UDP в TCP, потому что если бы это было так много, люди просто отключили бы UDP на маршрутизаторе (как это иногда делают в компаниях), если им нужен TCP для быстрой работы. Имейте также в виду, что UDP-пакеты имеют более высокую вероятность потери, чем TCP. В отношении остальных фактов в вашем ответе я полностью согласен и считаю его весьма полезным, но я просто думаю, что вы переоцениваете определенные последствия.
Игорь Чордаш
18

Говоря о том, что быстрее, есть как минимум два очень разных аспекта: пропускная способность и задержка.

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

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

После любой потери пакета TCP будет ожидать повторной передачи в течение по крайней мере 200 мс (1 с на параграф 2.4 RFC6298, но практические современные реализации имеют тенденцию уменьшать его до 200 мс). Более того, при использовании протокола TCP даже те пакеты, которые достигли хоста назначения, не будут доставлены в ваше приложение до тех пор, пока не будет получен отсутствующий пакет (т. Е. Вся связь задерживается на ~ 200 мс) - кстати, этот эффект, известный как заголовок Line-Blocking, присущ всем надежным упорядоченным потокам, будь то TCP или надежный + упорядоченный UDP. Что еще хуже - если ретранслируемый пакет также потерян, мы будем говорить о задержке ~ 600 мс (из-за так называемого экспоненциального отката, первая ретрансляция составляет 200 мс, а вторая 200 * 2 = 400 мс). Если у нашего канала потеря пакетов 1% (что неплохо по сегодняшним меркам), и у нас есть игра с 20 обновлениями в секунду - такие задержки 600 мс будут происходить в среднем каждые 8 ​​минут. И поскольку 600 мс более чем достаточно, чтобы убить вас в быстро развивающейся игре - ну, это очень плохо для игрового процесса. Именно из-за этих эффектов разработчики игр предпочитают UDP, а не TCP.

Однако при использовании UDP для уменьшения задержек - важно понимать, что простого "использования UDP" недостаточно для существенного улучшения задержки, все зависит от того, КАК вы используете UDP. В частности, хотя библиотеки RUDP обычно избегают этого «экспоненциального отката» и используют более короткое время повторной передачи - если они используются в качестве «надежно упорядоченного» потока, они все равно должны страдать от блокировки заголовка (так в случае двойной потеря пакетов, вместо этих 600 мс мы получим около 1,5 * 2 * RTT - или для довольно хорошего 80 мс RTT, это задержка ~ 250 мс, что является улучшением, но все еще возможно сделать лучше). С другой стороны, если используются методы, обсуждаемые в http://gafferongames.com/networked-physics/snapshot-compression/ и / или http: // ithare. Возможно полностью исключить блокировку заголовка линии (поэтому при потере двойного пакета в игре с 20 обновлениями в секунду задержка будет составлять 100 мс независимо от RTT).

И как примечание - если вам случается иметь доступ только к TCP, но нет UDP (например, в браузере, или если ваш клиент находится за одним из 6-9% некрасивых брандмауэров, блокирующих UDP), - кажется, есть способ внедрить UDP-over-TCP без больших задержек, см. здесь: http://ithare.com/almost-zero-additional-latency-udp-over-tcp/ (обязательно прочитайте комментарии (!)).

Заяц без ошибок
источник
13

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

Кайл Кронин
источник
Небольшая вероятность отказа и ограничение размера пакета.
11

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

Другой аспект, который следует принять во внимание, это необходимость многоадресной рассылки. Если это так, используйте UDP.

Марсио Агияр
источник
8
UDP также используется, потому что если вы пропустили пакет или два, возможно, в любом случае уже слишком поздно, и вам, вероятно, лучше просто пропустить его и двигаться дальше, чтобы вы могли продолжить просмотр. Небольшой всплеск в видео из-за некоторых пропущенных пакетов намного лучше, чем тонны заторов.
Кибби
1
Правильно - мультикастинг сети довольно редок, большинство маршрутизаторов блокируют его.
user1496062
8

Если вам нужно быстро передать сообщение по сети между двумя IP-адресами, которые еще даже не разговаривали, то UDP прибудет как минимум в 3 раза быстрее, обычно в 5 раз быстрее.

Myforwik
источник
1
Любые ссылки?
Джерард
8

Я просто все проясню. TCP / UDP - это две машины, которые ездят по дороге. предположим, что дорожные знаки и препятствия являются ошибками. TCP заботится о дорожных знаках, уважает все вокруг. Медленная езда, потому что что-то может случиться с машиной. В то время как UDP просто отъезжает, на полной скорости нет уважения к дорожным знакам. Ничего, безумный водитель. У UDP нет восстановления после ошибок. Если есть препятствие, оно просто столкнется с ним и продолжит. В то время как TCP гарантирует, что все пакеты отправлены и получены отлично, ошибок нет, поэтому машина просто преодолевает препятствия, не сталкиваясь. Я надеюсь, что это хороший пример для понимания, почему UDP предпочитают в играх. Играм нужна скорость. TCP предпочтителен при загрузке, иначе загруженные файлы могут быть повреждены.

Ахмед И. Эльсайед
источник
7

По моему опыту, UDP немного быстрее, но ненамного. Выбор должен быть сделан не по производительности, а по содержанию сообщения и методам сжатия.

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

Андрей
источник
5

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

Леон Тиммерманс
источник
5

Была проделана определенная работа, чтобы позволить программисту пользоваться преимуществами обоих миров.

SCTP

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

  • в порядке доставки сообщений
  • автоматическая повторная передача потерянных сообщений с заданными пользователем параметрами

если что-то из этого необходимо для вашего конкретного приложения.

Одна из проблем заключается в том, что установление соединения является сложным (и, следовательно, медленным процессом)

Другие подобные вещи

Еще одна похожая фирменная экспериментальная вещь

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

user7610
источник
3

Говорить о TCP или UDP бессмысленно без учета состояния сети. Если сеть между двумя точками имеет очень высокое качество, UDP абсолютно быстрее, чем TCP, но в некоторых других случаях, таких как сеть GPRS, TCP может быть быстрее и надежнее, чем UDP.

zhanglongpan
источник
1

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

Три вещи, которые я хочу добавить к обсуждению:

  1. Вы можете найти здесь очень хорошую статью о TCP против UDP в контексте разработки игр.
  2. Кроме того, iperf ( jperf extension iperf с графическим интерфейсом) является очень хорошим инструментом для самостоятельного ответа на ваш вопрос путем измерения.
  3. Я реализовал тест в Python (см. Этот вопрос так ). В среднем из 10 ^ 6 итераций разница для отправки 8 байтов составляет около 1-2 микросекунд для UDP.
Майкл Дорнер
источник
1
Чтобы сделать эталонный тест релевантным для реального Интернета, вам необходимо повторно запустить его с помощью симулятора потери пакетов, такого как netem. Если все сделать правильно (и с имитированным RTT, скажем, 100 мс и симулированной потерей пакетов в 1%), результаты будут сильно отличаться. Вкратце - хотя задержки TCP и UDP действительно одинаковы для нулевой потери пакетов, они начинают различаться по LOT для каждого потерянного пакета.
No-Bugs Hare