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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если говорить о пропускной способности - управление потоком данных 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/ (обязательно прочитайте комментарии (!)).

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

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

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

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

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

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

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

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

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

SCTP

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

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

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

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

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

• https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

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

• https://en.wikipedia.org/wiki/QUIC

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

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

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

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

1. Вы можете найти здесь очень хорошую статью о TCP против UDP в контексте разработки игр.
2. Кроме того, iperf ( jperf extension iperf с графическим интерфейсом) является очень хорошим инструментом для самостоятельного ответа на ваш вопрос путем измерения.
3. Я реализовал тест в Python (см. Этот вопрос так ). В среднем из 10 ^ 6 итераций разница для отправки 8 байтов составляет около 1-2 микросекунд для UDP.