Czy HTTP używa UDP?

103

To może być głupie pytanie:

  • Czy HTTP używa kiedykolwiek protokołu datagramów użytkownika?

Na przykład:

Jeśli ktoś przesyła strumieniowo MP3 lub wideo za pomocą protokołu HTTP, czy wewnętrznie używa UDP do transportu?

Sesh
źródło
Co masz na myśli mówiąc: „sieć”? Masz na myśli przeglądarkę? Lub przez publiczny Internet?
benc
Chodziło mi o to, żeby powiedzieć, że pod adresem URL znajduje się plik mp3, na przykład someserver / somemusic.mp3 . Jeśli jest to przesyłane strumieniowo do dowolnego klienta - przeglądarki, urządzenia itp., W jaki sposób http to przekazuje. Jeśli poprawnie zrozumiem poniższe odpowiedzi, zostanie to przekazane firmie RTP.
Sesh
Port 80 UDP jest również zarezerwowany dla HTTP, co uważam za zabawne, ponieważ nigdy nie widziałem, aby był używany, ani nie wyobrażałem sobie dobrego użycia.
Joshua,
1
Jest to zastrzeżone, ponieważ komitet IANA ma bardziej elastyczną wyobraźnię niż ty. ;-) Wyobrażają sobie, że po prostu może się to przydać. Poza tym, aby nie zapasowego portu 80 dla protokołu UDP / HTTP zostawi go otworzyć z jakiegoś innego protokołu UDP, który właśnie przyczyną zamieszania, gdy mówimy o porcie 80.
Jesse Chisholm

Odpowiedzi:

42

Zazwyczaj nie.

Przesyłanie strumieniowe jest rzadko używane przez sam protokół HTTP, a protokół HTTP rzadko jest obsługiwany przez UDP. Zobacz jednak RTP .

Na przykład (w komentarzu) nie pokazujesz protokołu zasobu. Gdyby tym protokołem był HTTP, nie nazywałbym dostępu „przesyłaniem strumieniowym”; nawet jeśli w jakimś sensie tego słowa dzieje się tak, ponieważ wysyła szeregowo (prawdopodobnie duży) zasób przez sieć. Zwykle zasób zostanie zapisany na dysku lokalnym przed odtworzeniem, więc transfer sieciowy nie jest tym, co zwykle rozumie się przez „przesyłanie strumieniowe”.

Jednak, jak zauważyli komentatorzy, z pewnością możliwe jest przesyłanie strumieniowe przez HTTP, a niektórzy to robią.

rozwijać
źródło
16
Oczywiście nie tak, nie ma nic w HTTP, co uniemożliwia przesyłanie strumieniowe, po prostu nie jest tak wydajne, jak byłby dedykowany protokół. Strumieniowanie dynamiczne HTTP przy użyciu fragmentów: adobe.com/products/httpdynamicstreaming HTTP Pseudo-streaming: longtailvideo.com/support/jw-player/jw-player-for-flash-v5/ ...
Steve-o
14
YouTube przesyła strumieniowo przez http.
nr
6
@ snowcrash09 Nie mogę go nawet usunąć, ponieważ został zaakceptowany. To jest dziwne. Napisałem go ponownie, mam nadzieję, że teraz jest mniej obraźliwy.
odpocząć
1
Po prostu pedantycznie podchodząc do HTTP i przesyłania strumieniowego - w ciemnych wiekach wideo QuickTime było server push, gdy połączenie HTTP wysyła MJPEG (wiele obrazów JPEG), każdy jako oddzielną część wieloczęściowej odpowiedzi MIME na żądanie HTTP. Każdy obraz JPEG pojawia się i zastępuje poprzedni na wyświetlaczu. Ale masz rację @unwind, dziś rzadko się to robi, ponieważ RTP / RTSP działa lepiej.
Jesse Chisholm
3
@nos Youtube nie transmituje strumieniowo. Przeglądarka pobiera plik do pamięci podręcznej i rozpoczyna odtwarzanie z pliku, zanim zostanie całkowicie pobrany. Chociaż symuluje to przesyłanie strumieniowe, tak nie jest.
SimonStiph
113

Z RFC 2616 :

Komunikacja HTTP odbywa się zwykle za pośrednictwem połączeń TCP / IP. Domyślny port to TCP 80, ale można używać innych portów. Nie wyklucza to możliwości implementacji protokołu HTTP ponad jakimkolwiek innym protokołem w Internecie lub w innych sieciach. HTTP zakłada tylko niezawodny transport; można zastosować dowolny protokół, który zapewnia takie gwarancje; odwzorowanie struktur żądań i odpowiedzi HTTP / 1.1 na jednostki danych transportowych omawianego protokołu nie wchodzi w zakres niniejszej specyfikacji.

Więc chociaż nie jest to wyraźnie powiedziane, UDP nie jest używany, ponieważ nie jest "niezawodnym transportem".

EDYCJA - ostatnio protokół QUIC (który jest ściślej pseudotransportem lub protokołem warstwy sesji) używa UDP do przenoszenia ruchu HTTP / 2.0, a większość ruchu Google już korzysta z tego protokołu. Obecnie postępuje w kierunku standaryzacji jako HTTP / 3 .

Alnitak
źródło
Czy istnieją serwery WWW, które można skonfigurować tak, aby akceptowały połączenia inne niż TCP?
Spidey
1
Jest tu modyfikacja apache pel.cis.udel.edu, aby używała protokołu SCTP zamiast TCP.
nr
@nos Tak, a Google też ma SPDY. Oba są jednak niezawodnymi mechanizmami transportu.
Alnitak
5
@Alnitak SPDY to protokół warstwy aplikacji, a nie protokół warstwy transportowej.
Walking Wiki
@WalkingWiki masz oczywiście rację - w tym kontekście SPDY zastępuje HTTP, a nie TCP.
Alnitak
36

Może tylko trochę ciekawostek, ale UPnP będzie używał wiadomości sformatowanych przez HTTP przez UDP do wykrywania urządzeń.

Frank Schwieterman
źródło
4
Mówiąc dokładniej, część protokołu UPnP, która używa komunikatów typu UDP i HTTP, nosi nazwę SSDP (Simple Service Discovery Protocol). Struktura wiadomości jest taka sama, ale METHODzestaw jest inny. Następnie UPnP używa innych protokołów (i zwykle TCP) do pozostałej części tego, co robi.
Jesse Chisholm
20

Tak, HTTP, jako protokół aplikacji, może być przesyłany przez protokół transportowy UDP. Oto niektóre usługi korzystające z protokołu UDP i bazowego protokołu do przesyłania danych HTTP i przesyłania ich strumieniowego do użytkownika końcowego:

  • Metoda transportu Jingle Raw UDP firmy XMPP
  • Liczba usług korzystających z protokołu UDT --- UDP Data Transfer Protocol, który jest nadzbiorem protokołu UDP.
  • Protokół Transport Layer Security (TLS) hermetyzujący HTTP, jak również wyżej wspomniane XMPP i inne protokoły aplikacji mają implementację, która wykorzystuje UDP w swojej warstwie transportowej; implementacja ta nosi nazwę Datagram Transport Layer Security (DTLS).
  • Powiadomienia push w GNUTella to żądania HTTP wysyłane przez transport UDP.

Ten artykuł zawiera dalsze szczegóły na temat przesyłania strumieniowego przez UDP i jego niezawodnego supersetu, RUDP: Reliable UDP (RUDP): The Next Big Streaming Protocol?

Egzotyczny hadron
źródło
1
Kolejne pytanie: czy główne przeglądarki internetowe obsługują strony internetowe HTTP przez UDP?
user2284570
tak, ponieważ protokół HTTP znajduje się w warstwie aplikacji, a UDP w warstwie transportowej. przeglądarki nie zapisują pakietów TCP ani UDP. Nie piszą też pakietów IP. Są one obsługiwane przez system operacyjny i sterowniki. Warstwa Ethernet jest tak niska, że ​​w tym momencie może znajdować się w chipie blisko MAC.
yan bellavance
@yanbellavance to całkowicie niepoprawne. Choć przeglądarek internetowych i serwerów rzeczywiście nie generują surowych ramek TCP (NOR te UDP dla tej sprawy), że nie trzeba wybierać transport do użytku, a dla normalnego HTTP to zawsze TCP. Nowszy pseudo-protokół QUIC używa jednak UDP.
Alnitak
18

Oczywiście niekoniecznie musi być przesyłane przez TCP. Zaimplementowałem HTTP jako dodatek do UDP, do użytku w branży nadawania telewizji satelitarnej.

jkc
źródło
6

Może jakaś zmiana w tym temacie z QUIC

QUIC (Quick UDP Internet Connections, wymawiane szybko) to eksperymentalny protokół sieciowy warstwy transportowej opracowany przez Google i wdrożony w 2013 roku. QUIC obsługuje zestaw multipleksowanych połączeń między dwoma punktami końcowymi za pośrednictwem protokołu User Datagram Protocol (UDP) i został zaprojektowany w celu zapewnienia ochrony bezpieczeństwa odpowiednik TLS / SSL, wraz ze zmniejszonym opóźnieniem połączenia i transportu oraz szacowaniem przepustowości w każdym kierunku, aby uniknąć przeciążenia. Głównym celem QUIC jest optymalizacja aplikacji internetowych zorientowanych na połączenia, które obecnie używają protokołu TCP.

Sébastien
źródło
4

Jeśli przesyłasz strumieniowo plik mp3 lub wideo, które niekoniecznie muszą być przesyłane przez HTTP, w rzeczywistości byłbym zaskoczony, gdyby tak było. Prawdopodobnie byłby to inny protokół przez TCP, ale nie widzę powodu, dla którego nie można przesyłać strumieniowo przez UDP.

Jeśli tak, musisz wziąć pod uwagę, że nie ma pewności, że Twoje dane dotrą na drugi koniec, ale mogę przyjąć, że wiesz o UDP.

Odpowiadając na pytanie: Nie, protokół HTTP NIE korzysta z protokołu UDP. Jednak o czym mówisz, strumieniowanie mp3 / wideo MOGŁO się odbywać przez UDP i moim zdaniem nigdy nie powinno odbywać się przez HTTP.

Henry B.
źródło
1
„Przesyłanie strumieniowe” przez HTTP jest powszechnie nazywane (co uważam za najdokładniejsze) „pseudostrumieniowaniem” - regulowaną przepływnością danych przez HTTP. Podobnie jak w naszym świecie, typy marketingu nadużywały nazewnictwa, pozostawiając ludzi zorientowanych na szczegóły, takich jak my, szukających szczegółów.
Stu Thompson
4

Teoretycznie tak, możliwe jest użycie UDP dla http, ale może to być problematyczne. Załóżmy na przykład, że w Twoim przykładzie jest przesyłane strumieniowo mp3 lub wideo, że wystąpi problem z kolejnością i niektóre bity mogą zniknąć, ponieważ UDP nie jest zorientowany na połączenie, nie ma mechanizmu retransmisji.

HM Manya
źródło
1
Dobrze wymienić: UDP is not connection oriented there is no retransmit mechanism.
ivanleoncz
4

Myślę, że w niektórych odpowiedziach brakuje ważnego punktu. Wybór między UDP a TCP nie powinien być oparty na typie danych (np. Audio lub wideo) ani na tym, czy aplikacja zacznie je odtwarzać przed zakończeniem przesyłania („przesyłanie strumieniowe”), ale na tym, czy jest to czas rzeczywisty . Dane czasu rzeczywistego są (z definicji) wrażliwe na opóźnienia, dlatego często najlepiej je przesyłać przez RTP / UDP (protokół czasu rzeczywistego przez UDP).

Opóźnienie nie jest problemem w przypadku przechowywanych danych z pliku, nawet jeśli jest to dźwięk i / lub wideo, więc prawdopodobnie najlepiej jest przesyłać je przez TCP, aby wszelkie straty pakietów można było skorygować. Nadawca może czytać z wyprzedzeniem i utrzymywać pełny potok sieciowy, a odbiornik może również korzystać z dużej ilości buforowania odtwarzania, aby nie zostało przerwane przez sporadyczną retransmisję TCP lub chwilowe spowolnienie sieci. Ograniczeniem jest sytuacja, w której całe nagranie jest przesyłane przed rozpoczęciem odtwarzania. Eliminuje to ryzyko zatrzymania odtwarzania, ale często jest niepraktyczne.

Problem z TCP dla danych w czasie rzeczywistym nie jest tak bardzo retransmisją, jak nadmiernym buforowaniem, ponieważ TCP próbuje wykorzystać potok tak efektywnie, jak to możliwe, bez względu na opóźnienia. UDP zachowuje granice pakietów aplikacji i nie ma pamięci wewnętrznej, więc nie wprowadza żadnych opóźnień.

Phil Karn
źródło
3

Odpowiedź: tak

Powód: zobacz model OSI.

Wyjaśnienie:

HTTP to protokół warstwy aplikacji, który może być hermetyzowany protokołem używającym UDP, zapewniając prawdopodobnie szybszą i niezawodną komunikację niż TCP. Demon serwera i klient musiałyby oczywiście obsługiwać ten nowy protokół. Protokół Quake 2 udowadnia, że ​​UDP może być używany przez TCP jako podstawa dla ustrukturyzowanego systemu komunikacyjnego zapewniającego kontrolę przepływu (np. Identyfikatory fragmentów).

rozumieć
źródło
1
Nie możesz pokonać TCP ręką bez większej ilości informacji, niż powinieneś mieć na tym poziomie.
Joshua,
1
„UDP może być używany przez TCP”. Oba są protokołami warstwy transportowej, więc jest to jeden lub drugi.
opyate
2

protokół http over udp jest używany przez niektóre implementacje trackerów torrentów (i jest obsługiwany przez wszystkich głównych klientów)

user2946342
źródło
4
Proszę dołączyć odniesienia na poparcie swoich oświadczeń.
Max Leske
1
Jak to czytałem, protokół Torrent UDP Tracker jest binarny i wcale NIE jest sformatowany jak HTTP. xbtt.sourceforge.net/udp_tracker_protocol.html
Jesse Chisholm,
1

UDP to najlepszy protokół do przesyłania strumieniowego, ponieważ nie wymaga brakujących pakietów, takich jak TCP. A jeśli nie stawia wymagań, przepływ jest znacznie szybszy i bez buforowania.

Nawet opóźnienie strumienia jest mniejsze niż TCP. Dzieje się tak, ponieważ TCP (jako znacznie bezpieczniejszy protokół) stawia żądania dotyczące brakujących pakietów, nadpisując istniejące.

Zatem TCP jest protokołem zbyt zaawansowanym, aby można go było używać do przesyłania strumieniowego.

Pavel
źródło
3
to nie odpowiada na pytanie, jednak może być powodem odpowiedzi.
Hawken
2
re: „najlepszy protokół przesyłania strumieniowego”, biorąc pod uwagę, że „prędkość poszczególnych fragmentów danych” jest ważniejsza niż „wszystkie dane przechodzące”. Jeśli Twój strumień nie może łatwo odzyskać brakujących fragmentów, lepiej skorzystaj z TCP. Z tego powodu wiele protokołów bezpieczeństwa wideo wybiera TCP - niezawodność jest ważniejsza niż sama szybkość.
Jesse Chisholm