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

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

Ответ 1

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

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

Ответ 2

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

В более широком масштабе это поведение TCP - это то, что заставляет Интернет блокировать "коллапс пробок".

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

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

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

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

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

Ответ 3

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

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

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

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

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

Ответ 4

с устойчивостью к потерям

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

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

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

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

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

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

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

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

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

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

Однако при использовании UDP для уменьшения латентности важно понять, что просто "использование UDP" недостаточно для существенного улучшения латентности, это все о том, КАК вы используете UDP. В частности, в то время как библиотеки RUDP обычно избегают "экспоненциального отсрочка" и используют более короткие времена повторной передачи - если они используются как "надежный упорядоченный" поток, им все равно придется страдать от блокировки Head-of-Line (поэтому в случае двойной потери пакетов, а не 600 мс, мы получим около 1.5 * 2 * RTT - или для довольно хорошего RTT 80 мс, это задержка 250 мс, что является улучшением, но все же можно сделать лучше). С другой стороны, если использовать методы, описанные в http://gafferongames.com/networked-physics/snapshot-compression/ и/или http://ithare.com/udp-from-mog-perspective/#low-latency- сжатие, возможно полностью исключить блокировку Head-of-Line (так что для потери двух пакетов для игры с 20 обновлениями в секунду задержка будет равна 100 мс независимо от RTT).

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

Ответ 9

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

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

Ответ 10

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

Ответ 11

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

Ответ 12

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

SCTP

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

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

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

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

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

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

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

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

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

Ответ 13

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

Ответ 14

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

Ответ 15

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

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

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