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

Question

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

Answer 1

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

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

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

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

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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

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

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

Answer 6

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

Answer 7

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

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

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

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

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

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

Answer 8

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

Answer 9

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

rtpchecksums=yes ; or no if you prefer 

Ура!

Answer 10

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

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

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