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

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

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

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

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

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

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

Ответ 4

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

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

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

Ответ 5

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

Ответ 6

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

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

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

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

Ответ 7

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

Ответ 8

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

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

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

Ответ 9

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

Ответ 10

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

rtpchecksums=yes ; or no if you prefer

Ура!

Ответ 11

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

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