Это может быть глупый вопрос:
- Использует ли HTTP когда-либо протокол дейтаграмм пользователя?
Например:
Если кто-то транслирует MP3 или видео по HTTP, использует ли он внутренне UDP для транспорта?
Это может быть глупый вопрос:
Например:
Если кто-то транслирует MP3 или видео по HTTP, использует ли он внутренне UDP для транспорта?
Ответы:
Обычно нет.
Потоковая передача редко используется через сам HTTP, а HTTP редко выполняется через UDP. См., Однако, RTP .
Для чего-то вроде вашего примера (в комментарии) вы не показываете протокол для ресурса. Если бы этим протоколом был HTTP, я бы не назвал доступ «потоковым»; даже если это в каком-то смысле этого слова, поскольку он последовательно отправляет (возможно, большой) ресурс по сети. Обычно ресурс перед воспроизведением сохраняется на локальный диск, поэтому передача по сети - это не то, что обычно подразумевается под «потоковой передачей».
Однако, как отмечали комментаторы, действительно можно передавать поток через HTTP, и некоторые это делают.
server push
, когда HTTP-соединение отправляло MJPEG (несколько изображений JPEG), каждое как отдельная часть многостраничного ответа MIME на HTTP-запрос. Каждое изображение JPEG приходит и заменяет предыдущее на дисплее. Но вы правы, @unwind, сегодня это делается редко, так как RTP / RTSP работает лучше.
Из RFC 2616 :
Связь HTTP обычно осуществляется через соединения TCP / IP. Порт по умолчанию - TCP 80, но можно использовать и другие порты. Это не препятствует реализации HTTP поверх любого другого протокола в Интернете или других сетях. HTTP предполагает только надежный транспорт; может использоваться любой протокол, который предоставляет такие гарантии; отображение структур запроса и ответа HTTP / 1.1 на транспортные блоки данных рассматриваемого протокола выходит за рамки данной спецификации.
Таким образом, хотя об этом прямо не говорится, UDP не используется, потому что это не «надежный транспорт».
РЕДАКТИРОВАТЬ - в последнее время протокол QUIC (который является более строго псевдотранспортным или протоколом сеансового уровня) действительно использует UDP для передачи трафика HTTP / 2.0, и большая часть трафика Google уже использует этот протокол. В настоящее время он продвигается к стандартизации как HTTP / 3 .
Может быть, это просто мелочь, но UPnP будет использовать сообщения в формате HTTP поверх UDP для обнаружения устройств.
METHOD
набор другой. После этого UPnP использует другие протоколы (и обычно TCP) для всего остального.
Да, HTTP, как протокол приложения, может передаваться по транспортному протоколу UDP. Вот некоторые из служб, которые используют UDP и базовый протокол для передачи данных HTTP и их потоковой передачи конечному пользователю:
Эта статья содержит дополнительные сведения о потоковой передаче по UDP и ее надежному расширенному набору, RUDP: надежный UDP (RUDP): следующий большой протокол потоковой передачи?
Может быть какое-то изменение по этой теме с QUIC
QUIC (Quick UDP Internet Connections, произносится быстро) - это экспериментальный сетевой протокол транспортного уровня, разработанный Google и реализованный в 2013 году. QUIC поддерживает набор мультиплексированных соединений между двумя конечными точками по протоколу дейтаграмм пользователя (UDP) и был разработан для обеспечения защиты эквивалент TLS / SSL, вместе с уменьшенной задержкой соединения и транспорта, а также оценкой пропускной способности в каждом направлении, чтобы избежать перегрузки. Основная цель QUIC - оптимизировать ориентированные на соединение веб-приложения, в настоящее время использующие TCP.
Если вы транслируете mp3 или видео, которые не обязательно должны передаваться через HTTP, я бы удивился, если бы это было так. Вероятно, это будет другой протокол через TCP, но я не вижу причин, по которым вы не можете передавать поток через UDP.
Если вы это сделаете, вы должны принять во внимание, что нет уверенности в том, что ваши данные будут доставлены на другой конец, но я могу считать, что вы знаете о UDP.
Чтобы ответить на ваш вопрос, нет, HTTP НЕ использует UDP. Тем не менее, о чем вы говорите, потоковая передача mp3 / видео МОЖЕТ происходить через UDP и, на мой взгляд, никогда не должна происходить через HTTP.
Теоретически да, можно использовать UDP для http, но это может быть проблематично. Скажем, например, в вашем примере транслируется mp3 или видео, возникнет проблема с упорядочиванием, и некоторые биты могут отсутствовать, поскольку UDP не ориентирован на соединение, нет механизма повторной передачи.
UDP is not connection oriented there is no retransmit mechanism
.
Я думаю, что в некоторых ответах упущен важный момент. Выбор между UDP и TCP не должен зависеть от типа данных (например, аудио или видео) или от того, начинает ли приложение их воспроизводить до завершения передачи («потоковая передача»), а от того, происходит ли это в реальном времени . Данные в реальном времени (по определению) чувствительны к задержкам, поэтому их лучше всего отправлять через RTP / UDP (протокол реального времени через UDP).
Задержка не является проблемой для сохраненных данных из файла, даже если это аудио и / или видео, поэтому, вероятно, лучше всего отправлять их по TCP, чтобы можно было исправить любые потери пакетов. Отправитель может заранее читать и поддерживать сетевой канал заполненным, а получатель также может использовать много буферизации воспроизведения, чтобы не прерывать его случайной повторной передачей TCP или кратковременным замедлением сети. Предельный случай - когда вся запись передается до начала воспроизведения. Это исключает любой риск остановки воспроизведения, но это часто непрактично.
Проблема с TCP для данных в реальном времени заключается не столько в повторных передачах, сколько в чрезмерной буферизации, поскольку TCP пытается использовать канал как можно более эффективно без учета задержки. UDP сохраняет границы пакетов приложения и не имеет внутренней памяти, поэтому не вызывает задержки.
Ответ: да
Причина: см. Модель OSI.
Объяснение:
HTTP - это протокол прикладного уровня, который можно инкапсулировать с протоколом, использующим UDP, обеспечивая, возможно, более быструю надежную связь, чем TCP. Демон сервера и клиент, очевидно, должны поддерживать этот новый протокол. Протокол Quake 2 доказывает, что UDP можно использовать поверх TCP, чтобы обеспечить основу для структурированной системы связи, обеспечивающей управление потоком (например, идентификаторы блоков).
Попробуйте запустить HTTP через UDP с помощью node-httpp:
http over udp используется некоторыми реализациями торрент-трекеров (и поддерживается всеми основными клиентами)
(Это старый вопрос, но он заслуживает обновленного ответа.)
По всей вероятности , HTTP / 3 будет использовать протокол QUIC , который описывается как
мультиплексированный транспорт через UDP
Итак, с определенной точки зрения можно сказать, что HTTP / 3 будет использовать UDP.
UDP - лучший протокол для потоковой передачи, потому что он не требует недостающих пакетов, таких как TCP. И если он не требует, поток будет намного быстрее и без какой-либо буферизации.
Даже задержка потока меньше, чем у TCP. Это потому, что TCP (как гораздо более безопасный протокол) требует недостающих пакетов, перезаписывая существующие.
Таким образом, TCP - это слишком продвинутый протокол, чтобы его можно было использовать для потоковой передачи.