Почему RTP использует UDP вместо TCP?

Question

Я хотел знать, почему UDP используется в RTP, а не TCP? Основные инструменты VoIP использовали только UDP, поскольку я взломал некоторые из VoIP OSS.

Answer 1

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

UDP не заботится о надежности связи и не будет замедлять или повторно передавать данные.

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

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

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

Answer 2

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

По сути, полный поток данных - это хорошая вещь для аудио / видео в реальном времени, но это не является строго необходимым (как отмечали другие):

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

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

Таким образом, RTP выполняет какую-то передачу с максимальным усилием, поскольку он пытается передать все доступные данные вовремя, но не пытается повторно передать данные, которые были потеряны / повреждены во время передачи (*). Он просто продолжается жизнью и надеется, что более важные текущие данные поступают правильно.

(*) на самом деле я не знаю специфики RTP. Возможно, он пытается повторить передачу, но если это произойдет, он не будет таким агрессивным, как TCP (который никогда не примет потерянные данные).

Answer 3

Другие верны, однако на самом деле не говорят вам РЕАЛЬНУЮ причину, почему. Сауа вроде намекает на это, но вот более полный ответ.

Аудио и видео в режиме реального времени. Если вы слушаете радио или смотрите телевизор, и сигнал прерывается, он не улавливает то, с чего вы остановились ... вы просто "наблюдаете" сигнал во время его потоковой передачи, и если вы не можете наблюдать в любой момент вы потеряете его.

Причина проста. Задержка. VOIP изо всех сил старается свести к минимуму задержку с момента, когда кто-то говорит на одном конце, и вы получаете его на свой конец, и ваш ответ обратно. В противном случае при возникновении ошибок величина задержки между тем, когда человек говорил, и моментом получения сигнала будет непрерывно увеличиваться до тех пор, пока он не станет бесполезным.

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

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

RTP может быть ориентирован на соединение, но тогда ему придется отбрасывать (или пропускать) данные, чтобы в любом случае не отставать от ошибок повторной передачи, так зачем беспокоиться о дополнительных издержках?

Answer 4

Технически пакеты RTP могут чередоваться по TCP-соединению. Здесь дано много отличных ответов. Два дополнительных второстепенных пункта:

RFC 4588 описывает, как можно использовать повторную передачу с данными RTP. Большинство клиентов, которые получают потоки RTP, используют буфер для учета дрожания в сети, который обычно длится 1-5 секунд, и это означает, что для повторной передачи есть время, необходимое для получения желаемых данных.

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

Answer 5

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

Answer 6

RTP довольно нечувствителен к потере пакетов, поэтому не требует надежности TCP.

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

UDP также обеспечивает быструю передачу данных.

Таким образом, UDP является очевидным выбором в таких случаях.

Answer 7

Помимо всех остальных хороших и правильных ответов эта статья дает хорошее представление о различиях между TCP и UDP.

Answer 8

Транспортный протокол в реальном времени - это сетевой протокол, используемый для передачи потокового аудио и видео через Интернет, что позволяет использовать протокол голосовой связи через Интернет (VoIP).

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

Answer 9

Я хотел бы быстро добавить к тому, что сказал Мэтт Х в ответ на ответ Стобора. Мэтт Н упомянул, что пакеты RTP поверх UDP можно проверять, чтобы в случае их повреждения они были отправлены повторно. На самом деле это дополнительная функция на большинстве АТС. Например, в Asterisk вы можете включить / отключить контрольные суммы для вашего RTP через UDP-трафик в файле конфигурации rtp.conf со следующей строкой:

rtpchecksums=yes ; or no if you prefer

Ура! * * 1004

Answer 10

просто замечание: Каждому пакету, отправляемому в потоке RTP, присваивается номер на один выше, чем у его предшественника. Это позволяет пункту назначения определить, отсутствуют ли какие-либо пакеты. Если пакет теряет скорость, лучшее действие для получателя состоит в том, чтобы аппроксимировать недостающее значение путем интерполяции. Повторная передача не является проктическим вариантом, поскольку повторно переданный пакет будет слишком поздно, чтобы быть полезным.