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

Question

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

Answer 1

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

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

Answer 2

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

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

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

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

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

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

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

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

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

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

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

Answer 3

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

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

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

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

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

Answer 4

с терпимостью к потерям

Вы имеете в виду "с терпимостью к потерям"?

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

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

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

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

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

Answer 5

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

Answer 6

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

Answer 7

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

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

Answer 8

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

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

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

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

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

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

Answer 9

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

Answer 10

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

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

Answer 11

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

Answer 12

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

Answer 13

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

SCTP

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

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

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

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

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

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

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

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

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

Answer 14

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

Answer 15

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

К обсуждению хочу добавить три вещи:

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