HTTP использует UDP?


104

Это может быть глупый вопрос:

  • Использует ли HTTP когда-либо протокол дейтаграмм пользователя?

Например:

Если кто-то транслирует MP3 или видео по HTTP, использует ли он внутренне UDP для транспорта?


Что вы имеете в виду под «сетью»? Вы имеете в виду использование браузера? Или через общедоступный Интернет?
benc

Я хотел спросить, что есть mp3, размещенный по URL-адресу, например someserver / somemusic.mp3 . Если это передается на любой клиент - браузер, устройство и т. Д., Как http передает это. Если я правильно понимаю приведенные ниже ответы, это делегируется RTP.
Sesh

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

1
Это зарезервировано, потому что у комитета IANA более гибкое воображение, чем у вас. ;-) Они думают, что это может быть полезно. Кроме того, если не зарезервировать порт 80 для UDP / HTTP, это оставит его открытым для другого протокола UDP, что вызовет путаницу при разговоре о порте 80.
Джесси Чизхолм

Ответы:


43

Обычно нет.

Потоковая передача редко используется через сам HTTP, а HTTP редко выполняется через UDP. См., Однако, RTP .

Для чего-то вроде вашего примера (в комментарии) вы не показываете протокол для ресурса. Если бы этим протоколом был HTTP, я бы не назвал доступ «потоковым»; даже если это в каком-то смысле этого слова, поскольку он последовательно отправляет (возможно, большой) ресурс по сети. Обычно ресурс перед воспроизведением сохраняется на локальный диск, поэтому передача по сети - это не то, что обычно подразумевается под «потоковой передачей».

Однако, как отмечали комментаторы, действительно можно передавать поток через HTTP, и некоторые это делают.


16
Очевидно, что неправильно, в HTTP нет ничего, что препятствовало бы потоковой передаче, это просто не так эффективно, как был бы выделенный протокол. HTTP Dyanmic Streaming с использованием чанков: adobe.com/products/httpdynamicstreaming HTTP Pseudo-Streaming: longtailvideo.com/support/jw-player/jw-player-for-flash-v5/…
Steve-o

14
потоки YouTube через http.

6
@ snowcrash09 Даже удалить сам не могу, так как принято. Это странно. Переписал, надеюсь теперь меньше обидно.
расслабьтесь

1
Просто педантично относиться к HTTP и потоковой передаче - еще в темные времена видео QuickTime было server push, когда HTTP-соединение отправляло MJPEG (несколько изображений JPEG), каждое как отдельная часть многостраничного ответа MIME на HTTP-запрос. Каждое изображение JPEG приходит и заменяет предыдущее на дисплее. Но вы правы, @unwind, сегодня это делается редко, так как RTP / RTSP работает лучше.
Джесси Чизхолм

3
@nos Youtube не транслируется. Браузер загружает файл в кэш и начинает воспроизведение с файла до того, как он будет полностью загружен. Хотя это имитирует потоковую передачу, это не так.
SimonStiph

114

Из RFC 2616 :

Связь HTTP обычно осуществляется через соединения TCP / IP. Порт по умолчанию - TCP 80, но можно использовать и другие порты. Это не препятствует реализации HTTP поверх любого другого протокола в Интернете или других сетях. HTTP предполагает только надежный транспорт; может использоваться любой протокол, который предоставляет такие гарантии; отображение структур запроса и ответа HTTP / 1.1 на транспортные блоки данных рассматриваемого протокола выходит за рамки данной спецификации.

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

РЕДАКТИРОВАТЬ - в последнее время протокол QUIC (который является более строго псевдотранспортным или протоколом сеансового уровня) действительно использует UDP для передачи трафика HTTP / 2.0, и большая часть трафика Google уже использует этот протокол. В настоящее время он продвигается к стандартизации как HTTP / 3 .


Существуют ли какие-либо веб-серверы, которые можно настроить для приема соединений, отличных от TCP?
Spidey

1
Здесь есть модификация apache pel.cis.udel.edu для использования протокола SCTP вместо TCP.

@nos Ага, и у Google тоже есть SPDY. Однако оба являются надежными транспортными механизмами.
Alnitak

5
@Alnitak SPDY - это протокол прикладного уровня, а не протокол транспортного уровня.
Walking Wiki

@WalkingWiki, конечно, вы правы - в этом контексте SPDY заменяет HTTP, а не TCP.
Alnitak

37

Может быть, это просто мелочь, но UPnP будет использовать сообщения в формате HTTP поверх UDP для обнаружения устройств.


4
Чтобы быть более конкретным, часть UPnP, которая использует UDP и HTTP-подобные сообщения, называется SSDP (Simple Service Discovery Protocol). Структура сообщения такая же, но METHODнабор другой. После этого UPnP использует другие протоколы (и обычно TCP) для всего остального.
Джесси Чизхолм

20

Да, HTTP, как протокол приложения, может передаваться по транспортному протоколу UDP. Вот некоторые из служб, которые используют UDP и базовый протокол для передачи данных HTTP и их потоковой передачи конечному пользователю:

  • Метод передачи UDP Jingle Raw в XMPP
  • Номер для служб, использующих UDT --- протокол передачи данных на основе UDP, который является расширенным набором протокола UDP.
  • Протокол безопасности транспортного уровня (TLS), инкапсулирующий HTTP, а также вышеупомянутый XMPP и другие прикладные протоколы имеют реализацию, которая использует UDP на своем транспортном уровне; эта реализация называется безопасностью транспортного уровня дейтаграмм (DTLS).
  • Push-уведомления в GNUTella - это HTTP-запросы, отправляемые через транспорт UDP.

Эта статья содержит дополнительные сведения о потоковой передаче по UDP и ее надежному расширенному набору, RUDP: надежный UDP (RUDP): следующий большой протокол потоковой передачи?


1
Другой вопрос: поддерживают ли основные веб-браузеры веб-страницы HTTP через UDP?
user2284570

да, потому что HTTP находится на уровне приложений, а UDP - на транспортном уровне. браузеры не записывают пакеты TCP или UDP. Они также не пишут IP-пакеты. Они обрабатываются ОС и драйверами. Уровень Ethernet настолько низкий, что в этот момент он может быть в микросхеме, близком к MAC.
Ян Беллаванс

@yanbellavance, это совершенно неверно. В то время как браузеры и веб - серверы действительно не создают сырые TCP кадров (ни те , UDP для этого вещества) , они действительно должны выбрать транспорт для использования, а также для нормального HTTP , который всегда TCP. Однако новый псевдопротокол QUIC использует UDP.
Alnitak

18

Конечно, это не обязательно должно передаваться по TCP. Я реализовал HTTP поверх UDP для использования в индустрии спутникового ТВ.


6

Может быть какое-то изменение по этой теме с QUIC

QUIC (Quick UDP Internet Connections, произносится быстро) - это экспериментальный сетевой протокол транспортного уровня, разработанный Google и реализованный в 2013 году. QUIC поддерживает набор мультиплексированных соединений между двумя конечными точками по протоколу дейтаграмм пользователя (UDP) и был разработан для обеспечения защиты эквивалент TLS / SSL, вместе с уменьшенной задержкой соединения и транспорта, а также оценкой пропускной способности в каждом направлении, чтобы избежать перегрузки. Основная цель QUIC - оптимизировать ориентированные на соединение веб-приложения, в настоящее время использующие TCP.


4

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

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

Чтобы ответить на ваш вопрос, нет, HTTP НЕ использует UDP. Тем не менее, о чем вы говорите, потоковая передача mp3 / видео МОЖЕТ происходить через UDP и, на мой взгляд, никогда не должна происходить через HTTP.


1
«Потоковая передача» по HTTP обычно называется (что я считаю наиболее точным) «псевдопотоковой передачей» - регулируемой скоростью передачи данных по HTTP. Как и многое в нашем мире, маркетологи злоупотребляют номенклатурой, в результате чего люди, ориентированные на детали, как мы, цепляются за особенности.
Стю Томпсон

4

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


1
Ну отметил: UDP is not connection oriented there is no retransmit mechanism.
ivanleoncz

4

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

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

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


3

Ответ: да

Причина: см. Модель OSI.

Объяснение:

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


1
Вы не можете победить TCP вручную без большего количества информации, чем вы должны иметь на этом уровне.
Джошуа

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


2

http over udp используется некоторыми реализациями торрент-трекеров (и поддерживается всеми основными клиентами)


4
Пожалуйста, включите ссылки в поддержку ваших утверждений.
Макс Леске

1
Я читал, что протокол Torrent UDP Tracker является двоичным и НЕ отформатирован как HTTP. xbtt.sourceforge.net/udp_tracker_protocol.html
Джесси

2

(Это старый вопрос, но он заслуживает обновленного ответа.)

По всей вероятности , HTTP / 3 будет использовать протокол QUIC , который описывается как

мультиплексированный транспорт через UDP

Итак, с определенной точки зрения можно сказать, что HTTP / 3 будет использовать UDP.


1

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

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

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


3
это не отвечает на вопрос, однако это может быть поводом для ответа.
Hawken

2
re: «лучший протокол для потоковой передачи», учитывая, что «скорость отдельных блоков данных» важнее, чем «прохождение всех данных». Если ваш поток не может легко восстановиться из отсутствующих фрагментов, вам лучше использовать TCP. Многие протоколы безопасности видео выбирают TCP по этой причине - надежность важнее чистой скорости.
Джесси Чизхолм
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.