Почему приложения потокового аудио и видео используют протокол udp вместо tcp

Обновлено: 17.05.2024

Я только что вернулся домой с экзамена по сетевому программированию, и один из вопросов, которые они нам задали, был " Если вы собираетесь транслировать видео, вы бы использовали TCP или UDP? Дайте объяснение как для сохраненного видео, так и для живых видеопотоков". На этот вопрос они просто ожидали короткого ответа TCP для сохраненного видео и UDP для живого видео, но я думал об этом по дороге домой, и обязательно лучше использовать UDP для потокового видео? Я имею в виду, если у вас есть пропускная способность для это, и скажем, вы транслируете футбольный матч или концерт, если на то пошло, вам действительно нужно использовать UDP?

допустим, что во время потоковой передачи этого концерта или чего-либо еще с помощью TCP вы начинаете терять пакеты (что-то плохое произошло в какой-то Сети между вами и отправителем), и в течение целой минуты вы не получаете никаких пакетов. Видеопоток приостановится, и после того, как минута прошла, пакеты начнут проходить снова (IP нашел для вас новый маршрут). Что бы тогда произошло, это TCP будет ретранслировать минуту, которую вы потеряли, и продолжать отправлять вам прямой эфир. Как предположение, пропускная способность выше, чем скорость передачи битов в потоке, и пинг не слишком высок, поэтому за короткое время одна минута, которую вы потеряли, будет действовать как буфер для потока для вас, таким образом, если потеря пакетов произойдет снова, вы не заметите.

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

Итак, это подводит меня к моему вопросу. Есть ли какие-либо недостатки, о которых я не знаю об использовании TCP для потоковой передачи? Или так и должно быть? если у вас есть пропускная способность для него, вы должны пойти на TCP, учитывая, что он" лучше " для сети (flow-control)?

недостатки использования TCP для живого видео:

обычно живые видео-потоковые устройства не разработаны с учетом потоковой передачи TCP. При использовании TCP ОС должна буферизировать неподтвержденные сегменты для каждого клиента. Это нежелательно, особенно в случае живых событий; предположительно, ваш список одновременных клиентов длинный из-за сингулярности события. Предварительно записанные видео-слепки обычно не имеют такой большой проблемы с этим, потому что зрители шатаются их активность воспроизведения; поэтому TCP более подходит для воспроизведения видео по требованию.
IP multicast значительно снижает требования к пропускной способности видео для больших аудиторий; TCP предотвращает использование IP multicast, но UDP хорошо подходит для IP multicast.
Live video обычно является потоком с постоянной пропускной способностью, записанным с камеры; предварительно записанные видеопотоки снимаются с диска. Динамика потери-отдачи TCP затрудняет обслуживание живого видео, когда исходные потоки находятся в постоянной полосе пропускания (как и в случае live-event). Если вы буфера на диск с камеры, убедитесь, что у вас есть достаточный буфер для непредсказуемых сетевых событий и переменной передачи TCP/частота переключений. UDP дает вам гораздо больше контроля для этого приложения, так как UDP не заботится о снижениях уровня сетевого транспорта.

FYI, пожалуйста, не используйте слово "пакеты" при описании сетей. Сети отправляют "пакеты".

но во время футбольного матча, или концерт, какое это имеет значение, если вы в одной минуте позади ручья?

для некоторых футбольных болельщиков, совсем немного. Было отмечено, что задержки даже на несколько секунд, присутствующие в цифровых видеопотоках из-за кодирования (или что-то еще), могут быть очень раздражающими, когда во время громких событий, таких как матчи Кубка мира, вы можете услышать приветствия и стоны от парней по соседству (которые смотрят некрашеную аналоговую программу) прежде чем вы получите, чтобы увидеть игру движется, что вызвало их.

Я думаю, что для кого-то, кто много заботится о спорте (и это самая большая группа платных клиентов для цифрового телевидения, по крайней мере, здесь, в Германии), быть на минуту позади в прямом эфире было бы совершенно неприемлемо (например, они переключились бы на вашего конкурента, где этого не происходит).

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

Если ваш живой поток использует TCP / IP, то это будет заставили ждать тех упавших пакетов до он может продолжить обработку новых данных.

это вдвойне плохо:

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

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

для записанного потока ситуация немного по-другому: вы, вероятно, будете буферизировать намного больше (возможно, несколько минут!) и предпочел бы, чтобы данные передавались повторно, чем некоторые артефакты из-за потерянных пакетов. В этом случае TCP является хорошим совпадением (это все еще может быть реализовано в UDP, конечно, но TCP не имеет столько недостатков, сколько для случая live stream).

есть несколько вариантов использования, подходящих для UDP-транспорта, и другие, подходящие для TCP-транспорта.

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

при использовании многоадресной рассылки для доставки видео вашим клиентам используется UDP.

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

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

unicast (TCP) workflow позволяет серверу проверять учетные данные клиента и разрешать только действительные подписки. Даже разрешить только определенное количество одновременное подключение.

Многоадресная рассылка не включена через интернет.

для доставки видео через интернет необходимо использовать TCP. Когда UDP используется, разработчики в конечном итоге повторно реализуют повторную передачу пакетов, например. Протокол BitTorrent P2P live.

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

"IP multicast значительно уменьшает требования к пропускной способности видео для больших аудиторий"

Это верно для частных сетей, Многоадресная рассылка не включена через интернет.

"обратите внимание, что если TCP теряет слишком много пакетов, соединение умирает; таким образом, UDP дает вам гораздо больше контроля для этого приложения, так как UDP не заботится о снижении уровня сетевого транспорта."

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

"обычно видеопоток несколько отказоустойчив"

закодированное видео не отказоустойчивость. При передаче через ненадежный транспорт, то вперед исправление ошибок добавляется в контейнер видео. Хорошим примером является контейнер MPEG-TS, используемый в спутниковой трансляции видео, которые несут несколько аудио, видео, EPG и т. д. потоки. Это необходимо, поскольку спутниковая связь не является дуплексной связью, то есть приемником не удается запросить повторную передачу потерянных пакетов.

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

в любом случае потерянные пакеты неприемлемы. Пропущенные кадры в порядке в исключительных случаях, когда пропускная способность препятствовать.

результатом пропущенных пакетов являются артефакты, подобные этому:

некоторые декодеры могут разбить на потоки отсутствующие пакеты в критических местах.

Я рекомендую вам посмотреть на новый P2P live protocol Bittorent Live.

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

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

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

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

есть несколько основных причин, почему TCP не масштабируется хорошо:

один из самый большой компромисс TCP-это вариативность пропускной способности, достижимая между отправителем и получателем. При потоковой передаче видео через Интернет видеопакеты должны проходить через несколько маршрутизаторов через Интернет, каждый из этих маршрутизаторов связан с различными скоростными соединениями. Алгоритм TCP начинается с малого окна TCP, затем растет до тех пор, пока не будет обнаружена потеря пакета, потеря пакета считается признаком перегрузки, и TCP реагирует на нее, резко уменьшая размер окна, чтобы избежать затор. Таким образом в свою очередь уменьшающ эффективный объем немедленно. Теперь представьте себе сеть с передачей TCP с использованием 6-7 маршрутизаторов, переходящих к клиенту (очень нормальный сценарий), если какой-либо из промежуточных маршрутизаторов потеряет какой-либо пакет, TCP для этой ссылки уменьшит скорость передачи. На самом деле поток трафика между маршрутизаторами следует за формой песочных часов; всегда гонг вверх и вниз между одним из промежуточных маршрутизаторов. Оказание эффективной помощи гораздо ниже по сравнению с наилучшие усилия UDP.

Как вы уже знаете, TCP является протоколом на основе подтверждения. Например, скажем, отправитель находится на расстоянии 50 мс (т. е. задержка между двумя точками). Это означало бы, что время, необходимое для отправки пакета получателю и получателю для отправки подтверждения, будет 100 мс; таким образом, максимальная пропускная способность по сравнению с передачей на основе UDP уже уменьшена вдвое.

TCP не поддерживает многоадресную передачу или новую появляющуюся стандарт многоадресной AMT. Это означает, что у CDNs нет возможности уменьшить сетевой трафик путем репликации пакетов-когда многие клиенты смотрят один и тот же контент. Это само по себе является достаточно большой причиной для CDNs (например, Akamai или Level3), чтобы не идти с TCP для живых потоков.

для пропускной способности потокового видео, вероятно, ограничение на системе. Используя многоадресную рассылку, вы можете значительно уменьшить объем используемой восходящей полосы пропускания. С UDP вы можете легко многоадресной рассылки пакетов на все подключенные терминалы. Вы также можете использовать надежный многоадресный протокол, который называется Pragmatic General Multicast (PGM), я ничего не знаю об этом, и я думаю, что он не распространен в его использовании.

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

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

помимо всех других причин, UDP может использовать многоадресную рассылку. Поддерживая 1000S пользователей TCP все передачи на тех же частотах отходов данных. Однако есть еще одна важная причина для использования TCP.

TCP может гораздо легче пройти через брандмауэры и NATs. В зависимости от вашего NAT и оператора вы даже не сможете получить поток UDP из-за проблем с пробивкой отверстий UDP.

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

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

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

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

UDP FTW при потоковой передаче.

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

Случай 1: последовательные пакеты теряются в течение нескольких секунд. => live video остановится на стороне клиента независимо от транспортного уровня (TCP или UDP). Когда сеть восстановится: - если используется TCP, клиентский видеоплеер может перезапустить поток при первом потерянном пакете (timeshift) или удалить все поздние пакеты и перезапустить видеопоток без таймшифта. - если UDP используется, нет выбора на стороне клиента, перезапуск видео в прямом эфире без какого-либо сдвига времени. = > TCP равен или лучше.

случай 2: некоторые пакеты случайно и часто теряются в сети. - если используется TCP, эти пакеты будут немедленно ретранслированы и с правильным буфером дрожания, не будет никакого влияния на качество/задержку видеопотока. - если используется UDP, качество видео будет низким. => Протокол TCP намного лучше

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

Чем отличается протокол TCP от UDP

Всем привет сегодня расскажу чем отличается протокол TCP от UDP. Протоколы транспортного уровня, следующие в иерархии за IP, используются для передачи данных между прикладными процессами, реализующимися в сетевых узлах. Пакет данных, поступивший от одного компьютера другому через Интернет, должен быть передан процессу-обработчику, и именно по конкретному назначению. Транспортный уровень принимает на себя ответственность за это. На этом уровне два основных протокола – TCP и UDP.

Что означают TCP и UDP

TCP – транспортный протокол передачи данных в сетях TCP/IP, предварительно устанавливающий соединение с сетью.

Напоминаю, что оба протокола работают на транспортном уровне модели OSI или TCP/IP, и понимание того чем они отличаются очень важно.

Разница между протоколами TCP и UDP

Разница между протоколами TCP и UDP – в так называемой “гарантии доставки”. TCP требует отклика от клиента, которому доставлен пакет данных, подтверждения доставки, и для этого ему необходимо установленное заранее соединение. Также протокол TCP считается надежным, тогда как UDP получил даже именование “протокол ненадежных датаграмм. TCP исключает потери данных, дублирование и перемешивание пакетов, задержки. UDP все это допускает, и соединение для работы ему не требуется. Процессы, которым данные передаются по UDP, должны обходиться полученным, даже и с потерями. TCP контролирует загруженность соединения, UDP не контролирует ничего, кроме целостности полученных датаграмм.

Tcp Udp отличия

Давайте рассмотрим основные отличия tcp от udp.

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

Примерами UDP приложений, например можно привести, передачу DNS зон, в Active Directory, там не требуется надежность. Очень часто такие вопросы любят спрашивать на собеседованиях, так, что очень важно знать tcp и udp отличия.

Заголовки TCP и UDP

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

Заголовок UDP

Заголовок TCP

Размер окна позволяет экономить трафик, рассмотрим когда его значение равно 1, тут на каждый отправленный ответ, отправитель ждет подтверждения, не совсем рационально.

При размере окна 3, отправитель отправляет уже по 3 кадра, и ждет от 4, который подразумевает, что все три кадра у него есть, +1.

Говоря о безопасности информации, мы имеем в виду конфиденциальность, целостность и доступность информации в каждый момент времени. И если с конфиденциальностью и доступностью все понятно, то как обеспечить целостность информации при ее передаче по сети? Для решения этой задачи нам пригодится знание сетевых протоколов.

В данной статье мы рассмотрим протоколы TCP и UDP: что из себя представляет каждый из этих протоколов, в чем их отличие и когда целесообразнее использовать UDP подключение, а когда TCP.Они входят в стек протоколов TCP/IP, относятся к транспортному уровню модели OSI и используются для передачи информации от узла к узлу.

UDP protocol – протокол, обеспечивающий передачу данных (датаграмм) без предварительного создания соединения между хостами. При отправке датаграмм нет уверенности в существовании получателя и его готовности к обмену. Сетевой протокол UDP не обеспечивает также упорядочивание датаграмм при получении. Он используется приложениями для которых существенное значение имеет время доставки, когда нет возможности ждать задержавшиеся или запрашивать потерянные пакеты, например, в системах реального времени. Датаграммы могут доставляться не в заданном порядке, дублироваться или вовсе не доставляться. Поэтому протокол UDP называют «ненадёжным протоколом датаграмм».

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

Протокол передачи данных TCP – протокол обеспечивающий надежную доставку пакетов данных, он обеспечивает установку соединения между двумя хостами методом «рукопожатия», после которого может осуществляться обмен данными.

Перед началом передачи пакетов через TCP соединение устанавливается сессия с получателем, в рамках которой затем производится передача данных. Это позволяет убедиться в том, что получатель существует и готов принимать данные. После завершения передачи сессия закрывается, получатель извещается о том, что данных больше не будет, а отправитель извещается о том, что получатель извещён.

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

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

TCP и UDP отличия

Означает ли это, что протокол UDP не стоит использовать? Вовсе нет. За счет отсутствия «гарантии доставки» протокол UDP обеспечивает более высокую скорость передачи данных, чем TCP. По этой причине UDP оптимален для сетевых и онлайн игр, просмотра потокового видео, организации видео-связи и IP телефонии.

Как сделать выбор: TCP или UDP для vpn?

Программа Whoer VPN по умолчанию использует TCP-протокол, но при необходимости вы можете сменить его на UDP в Настройках одним кликом.

Наши клиенты часто спрашивают, какой протокол лучше: tcp или udp для vpn. Прочитав этой статье о tcp и udp протоколах, вы сами можете решить, какой из них лучше подходит именно вам. OpenVPN приложения работают как с UDP, так и с TCP, и оба протокола безопасны и обеспечивают анонимность. Какой из них использовать, зависит от того, для чего вы используете VPN.

В дополнение к собственному впн-клиенту, мы предоставляем нашим пользователям Openvpn конфиги для использования с любым подходящим клиентом на выбранной платформе. Рекомендуем вам посмотреть видео-инструкцию Меняем TCP на UDP в OpenVPN на нашем youtube-канале, если вы используете OpenVPN клиент.

Подписывайтесь на нас в соцсетях, задавайте вопросы и делитесь полезной информацией с друзьями и близкими!

Хотите улучшить этот вопрос? Обновите вопрос, чтобы он соответствовал теме переполнения стека.

Закрыто 3 года назад .

Так как TCP гарантирует доставку пакетов и поэтому может считаться «надежным», тогда как UDP ничего не гарантирует, и пакеты могут быть потеряны. В чем преимущество передачи данных с использованием UDP в приложении, а не через поток TCP? В каких ситуациях UDP будет лучшим выбором и почему?

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

Помимо того, что UDP страдает от возможной потери пакетов, он не гарантирует, что вы получите пакет только один раз. Если у вас запутанные или плохо настроенные сети, вы можете получать один и тот же пакет несколько раз. Просто один на один, потому что люди склонны забывать это! TCP не гарантирует доставку , он просто гарантирует, что если он сможет доставить пакеты, они будут в том же порядке, в котором они были отправлены. Кстати, я часто вижу, как люди приравнивают надежность / порядок доставки к повторным передачам TCP. Эти «эксперты» скажут вам, что для преодоления ошибок передачи по UDP, вы будете переопределять TCP (плохо), и поэтому вы могли бы также использовать TCP. Это неправда. Существуют и другие методы восстановления после ошибок, которые не страдают задержкой или экспоненциально сниженной пропускной способностью в результате небольших, но ненулевых частот ошибок. TCP также гарантирует, что вы будете знать, если пункт назначения не получил пакеты.

Это один из моих любимых вопросов. UDP так неправильно поняли.

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

Другой случай - когда вы доставляете данные, которые могут быть потеряны, потому что поступающие более новые данные заменят эти предыдущие данные / состояние. На ум приходят данные о погоде, потоковое видео, сервис биржевых котировок (не используется для реальной торговли) или игровые данные.

Другой случай, когда вы управляете огромным количеством состояний и хотите избежать использования TCP, потому что ОС не может обработать такое количество сеансов. Это редкий случай сегодня. Фактически, в настоящее время существуют пользовательские стеки TCP, которые можно использовать для того, чтобы разработчик приложений мог иметь более точный контроль над ресурсами, необходимыми для этого состояния TCP. До 2003 года UDP был действительно единственной игрой в городе.

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

Спасибо за интересный ответ. У нас есть сервер, который в настоящее время выполняет все в UDP (требование высокой пропускной способности), что нормально, потому что на самом деле есть один переход (маршрутизация отключена, . ), но мы заметили, что переупорядочение пакетов может стать проблемой на некоторых неисправных сетевых картах. Какой пользовательский стек TCP (или какой-либо другой поток, управляемый в пользовательском режиме) вы предлагаете? @dashesy - вы можете избавиться от требования заказа? Есть ли монотонно увеличивающееся число внутри полезной нагрузки, которое вы можете использовать? Если это так, вам не нужен полноценный стек TCP пользователя. @ drudru- да есть порядковый номер, мне, возможно, придется буферизоваться и де-джиттер сам. Спасибо, исключение еще одного варианта всегда здорово.

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

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

Я думаю, что у вас есть это задом наперед. TCP переупорядочивает пакеты так, чтобы данные доставлялись в отправленном порядке. UDP не переупорядочивает и доставляет данные в том порядке, в котором он их получил. UDP не гарантирует порядок, однако вы можете нумеровать пакеты и переупорядочивать их после получения. @ Stephan202: Думаю, мне не следует соглашаться с тем, чтобы не замечать пропущенные пакеты в Skype ;-) @ Кугель: Просто знайте, что вы можете реализовать новый стек TCP. Вряд ли вы справитесь с этой задачей лучше, чем ОС. @erikkallen: Если бы кто-то использовал UDP для реализации протокола более высокого уровня с теми же требованиями, которым был разработан протокол TCP, вряд ли он будет намного лучше, чем существующие протоколы. С другой стороны, некоторые приложения выигрывают от добавления в протокол нескольких функций, которые оболочка UDP могла бы обрабатывать лучше, чем TCP.

«Ненадежность» UDP - это формализм. Передача не абсолютно гарантирована. На практике они почти всегда проходят. Они просто не признаются и повторяются после тайм-аута.

Затраты на согласование сокета TCP и квитирование TCP-пакетов огромны. Действительно огромный. Нет заметных накладных расходов UDP.

«На практике они почти всегда проходят». Сильно зависит от более низкого уровня надежности сети кроме того, есть ли разница между планированием «нескольких» потерь пакетов и «слишком больших» потерь пакетов? потеря есть потеря. Вы все равно должны планировать это.

Я работаю над продуктом, который поддерживает как UDP (IP), так и TCP / IP связь между клиентом и сервером. Он начался с IPX более 15 лет назад с поддержкой IP, добавленной 13 лет назад. Мы добавили поддержку TCP / IP 3 или 4 года назад. Подходят дикие предположения: отношение кода UDP к TCP, вероятно, составляет около 80/20. Продукт является сервером базы данных, поэтому надежность имеет решающее значение. Мы должны решить все проблемы, связанные с UDP (потеря пакетов, удвоение пакетов, порядок пакетов и т. Д.), Уже упомянутые в других ответах. Есть редко какие-либо проблемы, но они иногда случаются и поэтому должны быть обработаны. Преимущество поддержки UDP состоит в том, что мы можем немного настроить его для нашего собственного использования и немного повысить его производительность.

Каждая сеть будет отличаться, но протокол связи UDP, как правило, немного быстрее для нас. Скептически настроенный читатель справедливо спросит, правильно ли мы все реализовали Кроме того, что вы можете ожидать от парня с 2-значным повторением? Тем не менее, я только что провела испытание из любопытства. Тест прочитал 1 миллион записей (выберите * из sometable). Я устанавливаю количество записей, которое нужно возвращать с каждым индивидуальным клиентским запросом, равным 1, 10, а затем 100 (три запуска теста с каждым протоколом). Сервер находился всего в двух прыжках по 100 Мбит локальной сети. Цифры, похоже, согласуются с тем, что другие находили в прошлом (в большинстве случаев UDP работает примерно на 5% быстрее). Общее время в миллисекундах было следующим для этого конкретного теста:

1 запись
- IP: 390 760 мс
- TCP: 416 903 мс
10 записей
- IP: 91,707 мс
- TCP: 95 662 мс
100 записей
- IP: 29,664 мс
- TCP: 30 968 мс

Общий объем передаваемых данных был примерно одинаковым для IP и TCP. У нас есть дополнительные накладные расходы на связь UDP, потому что у нас есть некоторые из тех вещей, которые вы получаете «бесплатно» с TCP / IP (контрольные суммы, порядковые номера и т. Д.). Например, Wireshark показал, что запрос следующего набора записей составляет 80 байтов с UDP и 84 байта с TCP.

Что если бы вы разработали его только для TCP и купили бы более качественное оборудование, а не в 5 раз больше усилий по программированию? Спасибо за конкретные цифры! Улучшение на 5% немного разочаровывает сложностью, которую он добавляет. Вероятно, 5%, потому что отправляется в локальной сети (две надежды)? Я думаю, что чем дальше, тем выше разница.

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

В результате UDP может:

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

Когда сети становятся достаточно перегруженными, чтобы вызвать потерю пакетов, TCP пытается минимизировать его влияние на других пользователей сети, в то время как многие реализации на основе UDP этого не делают. Это позволяет им захватить большую долю уменьшающегося пирога, но также уменьшает общий объем доступного периода полезной полосы пропускания (например, вследствие ненужной повторной передачи в случаях, когда данные фактически будут доставлены, но отправитель не поймет этого) Прежде всего, спасибо за отличный ответ, я действительно многому научился от него! Но у меня есть вопрос: не происходит ли сегментация на уровне 3 (IP) из-за ограничений адаптера Ethernet для всех пакетов, полученных с уровня 4 (как TCP, так и UDP)? Вы имеете в виду любой другой вид сегментации, который происходит в TCP, но не происходит в UDP? Буду очень признателен, если вы мне это объясните. @Freezy. Вы правы, фрагментация пакетов, которые превышают MTU канала (уровень 2), происходит на уровне 3-IP. Однако TCP - это потоковый протокол, который обрабатывает данные как поток байтов. TCP отправляет свои данные в сегментах, чтобы соответствовать внутренним IP-пакетам, размер которых соответствует MSS, поэтому сегментация также происходит в TCP. Сколько данных TCP помещает в сегмент или сколько данных читает ваш сокет, зависит от многих факторов; это может быть 1 байт или байты MSS. При использовании UDP получатель всегда получает точное количество байтов, отправленных передатчиком, если пакет не потерян в пути.

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

UDP является протоколом без установления соединения и используется в таких протоколах, как SNMP и DNS, в которых пакеты данных, поступающие не по порядку, являются приемлемыми и имеет значение немедленная передача пакета данных.

Он используется в SNMP, так как управление сетью часто должно выполняться, когда сеть находится в состоянии стресса, то есть когда надежная передача данных, контролируемая перегрузкой, затруднена.

Он используется в DNS, поскольку он не включает установление соединения, что позволяет избежать задержек при установлении соединения.

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

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

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

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

Кроме того, я думаю, следует упомянуть, что существует больше, чем UDP и TCP, такие как SCTP и DCCP. Единственная проблема в настоящее время состоит в том, что Интернет (IPv4) полон шлюзов NAT, которые делают невозможным использование протоколов, отличных от UDP и TCP, в приложениях конечного пользователя.

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

Протоколы UDP и TCP – в чем разница?

Несмотря на то, что протоколы UDP и TCP ориентированы на выполнение одной задачи – передачу данных, между ними существует ряд принципиальных отличий.

Что такое TCP?

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

Чтобы обеспечить надежное соединение, протокол TCP предусматривает трехэтапный запуск сеанса связи. Клиент и сервер должны передавать значения ISN и порта. Еще одна отличительная особенность протокола TCP заключается в использовании контрольной суммы, с помощью которой система проверяет, правильно ли передана информация конечному пользователю.

Приложения для TCP

Протокол TCP используют следующие приложения:

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

С одной стороны, специалисты в области компьютерных сетей вполне заслуженно считают UDP ненадежным протоколом. С другой, это не просто важное, а незаменимое решение для приложений, работающих в режиме реального времени, интернет-телевидения, технологии VOIP, игр по сети и так далее. Благодаря возможностям протокола UDP пропадает необходимость проводить первичную проверку соединения, соблюдения целостности и порядка структуры данных. Если какая-либо датаграмма (пакет без проверки) потеряется, происходит ее автоматический сброс. Это положительно сказывается на скорости передачи данных через сеть интернет.

Приложения для UDP

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

Применение TCP

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

Применение UDP

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

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

Выводы

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

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

Пожалуйста, опубликуйте ваши комментарии по текущей теме статьи. За комментарии, подписки, дизлайки, отклики, лайки огромное вам спасибо!

Читайте также: