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

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

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

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

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

Так что UDP - очевидный выбор в подобных случаях.

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

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

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

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

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

UDP используется везде, где отправляются данные, которые не нужно точно получать на цель или где не требуется стабильное соединение.

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

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

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

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

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

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

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

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

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

Остальные верны, однако на самом деле они не говорят вам НАСТОЯЩУЮ причину, почему. Сауа как бы намекает на это, но вот более полный ответ.

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

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

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

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

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

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

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

rtpchecksums=yes ; or no if you prefer

Ваше здоровье!

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

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

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

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

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