HTTP использует UDP?
Это может быть глупый вопрос:
- Использует ли HTTP когда-либо протокол дейтаграмм пользователя?
Например:
If one is streaming MP3 or video using HTTP, does it internally use UDP for transport?
Я хотел спросить, что есть mp3, размещенный по URL-адресу, например, someserver / somemusic.mp3. Если это передается любому клиенту - браузеру, устройству и т. д., Как http передает это? Если я правильно понимаю приведенные ниже ответы, это делегируется RTP.
Порт 80 UDP также зарезервирован для HTTP, что я нахожу забавным, поскольку никогда не видел, чтобы он использовался, и я не мог представить себе хорошего его использования.
Это зарезервировано, потому что у комитета IANA более гибкое воображение, чем у вас. ;-) Они думают, что это могло бы быть хорошим применением. Кроме того, если не зарезервировать порт 80 для UDP / HTTP, это оставит его открытым для какого-либо другого протокола UDP, что вызовет путаницу при разговоре о порте 80.
Ответы 14
Обычно нет.
Потоковая передача редко используется через сам HTTP, а HTTP редко выполняется через UDP. См., Однако, RTP.
Для чего-то вроде вашего примера (в комментарии) вы не показываете протокол для ресурса. Если бы этим протоколом был HTTP, я бы не назвал доступ «потоковым»; даже если это в некотором смысле этого слова, поскольку он последовательно отправляет (возможно, большой) ресурс по сети. Обычно ресурс перед воспроизведением сохраняется на локальный диск, поэтому передача по сети - это не то, что обычно подразумевается под «потоковой передачей».
Однако, как отмечают комментаторы, действительно можно передавать поток через HTTP, и некоторые это делают.
Очевидно, неправильно, в HTTP нет ничего, что препятствовало бы потоковой передаче, это просто не так эффективно, как был бы выделенный протокол. HTTP-динамическая потоковая передача с использованием блоков: adobe.com/products/httpdynamicstreaming HTTP-псевдопотоковая передача: longtailvideo.com/support/jw-player/jw-player-for-flash-v5/…
потоки YouTube через http.
@ snowcrash09 Даже сам удалить не могу, так как принято. Это странно. Переписал, надеюсь теперь меньше обидно.
Просто педантично относиться к HTTP и потоковой передаче - еще в темные времена видео QuickTime был server push, где HTTP-соединение отправляло MJPEG (несколько изображений JPEG), каждое как отдельная часть многостраничного ответа MIME на HTTP-запрос. Каждое изображение JPEG приходит и заменяет предыдущее на дисплее. Но вы правы, @unwind, сегодня это делается редко, так как RTP / RTSP работает лучше.
@nos Youtube не транслируется. Браузер загружает файл в кэш и начинает воспроизведение с файла до того, как он будет полностью загружен. Хотя это имитирует потоковую передачу, это не так.
Не уверен, насколько авторитетен этот сайт, но сайт это поддерживает то, что говорит @SimonStiph
Новый HTTP / 3.
Может быть, это просто мелочь, но UPnP будет использовать сообщения в формате HTTP поверх UDP для обнаружения устройств.
Чтобы быть более конкретным, часть UPnP, которая использует UDP и HTTP-подобные сообщения, называется SSDP (Simple Service Discovery Protocol). Структура сообщения такая же, но набор METHOD другой. После этого UPnP использует другие протоколы (и обычно TCP) для всего остального.
Если вы транслируете mp3 или видео, которые не обязательно могут передаваться через HTTP, на самом деле я был бы удивлен, если бы это было так. Вероятно, это будет другой протокол через TCP, но я не вижу причин, по которым вы не можете передавать поток через UDP.
Если вы это сделаете, вы должны принять во внимание, что нет уверенности в том, что ваши данные будут доставлены на другой конец, но я могу считать, что вы знаете о UDP.
Чтобы ответить на ваш вопрос, нет, HTTP НЕ использует UDP. Для того, о чем вы говорите, потоковая передача mp3 / видео МОЖЕТ происходить через UDP и, на мой взгляд, никогда не должна происходить через HTTP.
«Потоковая передача» по HTTP обычно называется (что я считаю наиболее точной) «псевдопотоковой передачей» - регулируемой скоростью передачи данных по HTTP. Как и многое в нашем мире, маркетологи злоупотребляют номенклатурой, в результате чего люди, ориентированные на детали, как мы, цепляются за особенности.
От RFC 2616:
HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80, but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet, or on other networks. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used; the mapping of the HTTP/1.1 request and response structures onto the transport data units of the protocol in question is outside the scope of this specification.
Таким образом, хотя об этом прямо не говорится, UDP не используется, потому что это не «надежный транспорт».
РЕДАКТИРОВАТЬ - в последнее время протокол QUIC (который является более строго псевдотранспортным или протоколом сеансового уровня) действительно использует UDP для передачи трафика HTTP / 2.0, и большая часть трафика Google уже использует этот протокол. В настоящее время он продвигается к стандартизации как HTTP / 3.
Существуют ли какие-либо веб-серверы, которые можно настроить для приема соединений, отличных от TCP?
Здесь есть модификация apache pel.cis.udel.edu для использования протокола SCTP вместо TCP.
@nos Ага, и у Google тоже есть SPDY. Однако оба являются транспортными механизмами надежный.
@Alnitak SPDY - это протокол прикладного уровня, а не протокол транспортного уровня.
@WalkingWiki, конечно, вы правы - в этом контексте SPDY заменяет HTTP, а не TCP.
Google экспериментирует с SPDY через UDP, чтобы уменьшить задержку, они называют это QUIC. Сборка Chrome dev поддерживает это. Не знаю, какие веб-серверы его используют. blog.chromium.org/2013/06/experimenting-with-quic.html
@ColonelPanic да, я это видел - стоит следить!
Согласно следующей статье в Википедии, SPDY является сеансовым уровнем: en.wikipedia.org/wiki/OSI_model
@MemetOlsen, возможно, вы правы, но в наши дни вряд ли кто-то говорит о уровнях 5 и 6 модели OSI ...
Ответ: Да
Причина: См. Модель OSI.
Объяснение:
HTTP - это протокол прикладного уровня, который может быть инкапсулирован с протоколом, использующим UDP, обеспечивая, возможно, более быструю надежную связь, чем TCP. Очевидно, что демон сервера и клиент должны поддерживать этот новый протокол. Протокол Quake 2 доказывает, что UDP можно использовать поверх TCP, чтобы обеспечить основу для структурированной системы связи, обеспечивающей управление потоком (например, идентификаторы блоков).
Вы не можете победить TCP вручную, не имея большего количества информации, чем предполагалось на этом уровне.
«UDP можно использовать поверх TCP». Они оба являются протоколами транспортного уровня, так что это один или другой.
UDP - лучший протокол для потоковой передачи, потому что он не требует недостающих пакетов, таких как TCP. И если он не требует, поток будет намного быстрее и без какой-либо буферизации.
Даже задержка потока меньше, чем у TCP. Это потому, что TCP (как гораздо более безопасный протокол) требует недостающих пакетов, перезаписывая существующие.
Так что TCP - это слишком продвинутый протокол, чтобы его можно было использовать для потоковой передачи.
это не отвечает на вопрос, однако это может быть поводом для ответа.
re: «лучший протокол для потоковой передачи», учитывая, что «скорость отдельных блоков данных» важнее, чем «прохождение всех данных». Если ваш поток не может легко восстановить из-за отсутствующих фрагментов, вам лучше использовать TCP. Многие протоколы безопасности видео выбирают TCP по этой причине - надежность важнее чистой скорости.
Попробуйте запустить HTTP через UDP с помощью node-httpp:
Конечно, это не обязательно должно передаваться по TCP. Я реализовал HTTP поверх UDP для использования в индустрии спутникового ТВ.
Да, HTTP, как протокол приложения, может передаваться по транспортному протоколу UDP. Вот некоторые из служб, которые используют UDP и базовый протокол для передачи данных HTTP и их потоковой передачи конечному пользователю:
- Метод передачи UDP Jingle Raw в XMPP
- Номер для служб, использующих UDT --- протокол передачи данных на основе UDP, который является расширенным набором протокола UDP.
- Протокол безопасности транспортного уровня (TLS), инкапсулирующий HTTP, а также вышеупомянутый XMPP и другие прикладные протоколы имеют реализацию, которая использует UDP на своем транспортном уровне; эта реализация называется безопасностью транспортного уровня дейтаграмм (DTLS).
- Push-уведомления в GNUTella - это HTTP-запросы, отправляемые через транспорт UDP.
Эта статья содержит дополнительные сведения о потоковой передаче по UDP и его надежному расширенному набору, RUDP: Надежный UDP (RUDP): следующий большой протокол потоковой передачи?
Другой вопрос: поддерживают ли основные веб-браузеры веб-страницы HTTP через UDP?
да, потому что HTTP находится на уровне приложений, а UDP - на транспортном уровне. браузеры не записывают пакеты TCP или UDP. Они также не пишут IP-пакеты. Это обрабатываются ОС и драйверами. Уровень Ethernet настолько низкий, что в этот момент он может быть в микросхеме, близком к MAC.
@yanbellavance, это совершенно неверно. Хотя браузеры и веб-серверы действительно не генерируют TCP-фреймы сырой (ни UDP, если на то пошло), делать должен выбрать транспорт для использования, а для обычного HTTP это всегда TCP. Однако более новый псевдопротокол QUIC использует UDP.
http over udp используется некоторыми реализациями торрент-трекеров (и поддерживается всеми основными клиентами)
Пожалуйста, включите ссылки в поддержку ваших утверждений.
Я читал, что протокол Torrent UDP Tracker является двоичным и НЕ отформатирован как HTTP. xbtt.sourceforge.net/udp_tracker_protocol.html
Может какие-то изменения по этой теме с QUIC
QUIC (Quick UDP Internet Connections, pronounced quick) is an experimental transport layer network protocol developed by Google and implemented in 2013. QUIC supports a set of multiplexed connections between two endpoints over User Datagram Protocol (UDP), and was designed to provide security protection equivalent to TLS/SSL, along with reduced connection and transport latency, and bandwidth estimation in each direction to avoid congestion. QUIC's main goal is to optimize connection-oriented web applications currently using TCP.
Теоретически да, можно использовать UDP для http, но это может быть проблематично. Скажем, например, в вашем примере транслируется mp3 или видео, возникнет проблема с упорядочением, и некоторые биты могут отсутствовать, поскольку UDP не ориентирован на соединение, нет механизма повторной передачи.
Хорошо упомянуто: UDP is not connection oriented there is no retransmit mechanism.
Я думаю, что в некоторых ответах упущен важный момент. Выбор между UDP и TCP должен быть основан на нет на основе типа данных (например, аудио или видео) или от того, начинает ли приложение их воспроизводить до завершения передачи («потоковая передача»), но от того, является ли это реальное время. Данные в реальном времени (по определению) чувствительны к задержкам, поэтому их лучше всего отправлять через RTP / UDP (протокол реального времени через UDP).
Задержка не является проблемой для сохраненных данных из файла, даже если это аудио и / или видео, поэтому, вероятно, лучше всего отправлять их по TCP, чтобы можно было исправить любые потери пакетов. Отправитель может заранее читать и поддерживать сетевой канал заполненным, а получатель также может использовать много буферизации воспроизведения, чтобы не прерываться случайной повторной передачей TCP или кратковременным замедлением работы сети. Предельный случай - когда вся запись передается до начала воспроизведения. Это исключает любой риск остановки воспроизведения, но это часто непрактично.
Проблема с TCP для данных в реальном времени заключается не столько в повторных передачах, сколько в чрезмерной буферизации, поскольку TCP пытается использовать канал как можно более эффективно без учета задержки. UDP сохраняет границы пакетов приложений и не имеет внутренней памяти, поэтому не вызывает задержек.
(Это старый вопрос, но он заслуживает обновленного ответа.)
По всей вероятности, HTTP / 3 будет использовать Протокол QUIC, который описывается как
multiplexed transport over UDP
Итак, с определенной точки зрения, можно сказать, что HTTP / 3 будет использовать UDP.
Что вы имеете в виду под «сетью»? Вы имеете в виду использование браузера? Или через общедоступный Интернет?