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

Question

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

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

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

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

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

Answer 9

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

Answer 10

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

rtpchecksums=yes ; or no if you prefer

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

Answer 11

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

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