HTTP utilizza UDP?

Questa potrebbe essere una domanda stupida:

• HTTP utilizza mai il protocollo datagramma utente?

Per esempio:

Se uno sta trasmettendo MP3 o video utilizzando HTTP, utilizza internamente UDP per il trasporto?

Di solito no.

Lo streaming viene utilizzato raramente su HTTP stesso e HTTP è raramente eseguito su UDP. Vedi, tuttavia, RTP .

Per qualcosa come il tuo esempio (nel commento), non stai mostrando un protocollo per la risorsa. Se quel protocollo fosse HTTP, non chiamerei l'accesso "streaming"; anche se in un certo senso la parola è poiché sta inviando una risorsa (possibilmente grande) in serie su una rete. In genere, la risorsa verrà salvata sul disco locale prima di essere riprodotta, quindi il trasferimento di rete non è ciò che di solito si intende per "streaming".

Come hanno sottolineato i commentatori, tuttavia, è certamente possibile eseguire lo streaming su HTTP, e questo è fatto da alcuni.

Da RFC 2616 :

La comunicazione HTTP di solito avviene tramite connessioni TCP / IP. La porta predefinita è TCP 80, ma è possibile utilizzare altre porte. Ciò non preclude l'implementazione di HTTP su qualsiasi altro protocollo su Internet o su altre reti. HTTP presume solo un trasporto affidabile; può essere utilizzato qualsiasi protocollo che fornisca tali garanzie; la mappatura delle strutture di richiesta e risposta HTTP / 1.1 sulle unità di dati di trasporto del protocollo in questione esula dallo scopo di questa specifica.

Quindi, anche se non lo dice esplicitamente, UDP non viene utilizzato perché non è un "trasporto affidabile".

MODIFICA - più recentemente, il protocollo QUIC (che è più strettamente uno pseudo-trasporto o un protocollo a livello di sessione) utilizza UDP per trasportare il traffico HTTP / 2.0 e gran parte del traffico di Google utilizza già questo protocollo. Attualmente sta procedendo verso la standardizzazione come HTTP / 3 .

Forse solo un po 'di curiosità, ma UPnP utilizzerà i messaggi in formato HTTP su UDP per il rilevamento dei dispositivi.

Sì, HTTP, come protocollo dell'applicazione, può essere trasferito tramite il protocollo di trasporto UDP. Di seguito sono riportati alcuni dei servizi che utilizzano UDP e un protocollo sottostante per il trasferimento di dati HTTP e lo streaming all'utente finale:

• Metodo di trasporto Jingle Raw UDP di XMPP
• Un numero per i servizi che utilizzano UDT --- Protocollo di trasferimento dati basato su UDP, che è un superset del protocollo UDP.
• Il protocollo Transport Layer Security (TLS) che incapsula HTTP così come il summenzionato XMPP e altri protocolli applicativi ha un'implementazione che utilizza UDP nel suo livello di trasporto; questa implementazione è chiamata Datagram Transport Layer Security (DTLS).
• Le notifiche push in GNUTella sono richieste HTTP inviate tramite il trasporto UDP.

Questo articolo contiene ulteriori dettagli sullo streaming su UDP e sul suo affidabile superset, il RUDP: Reliable UDP (RUDP): The Next Big Streaming Protocol?

Ovviamente non deve essere necessariamente trasmesso su TCP. Ho implementato HTTP su UDP, per l'utilizzo nel settore della trasmissione TV satellitare.

Forse qualche cambiamento su questo argomento con QUIC

QUIC (Quick UDP Internet Connections, pronunciato veloce) è un protocollo di rete a livello di trasporto sperimentale sviluppato da Google e implementato nel 2013. QUIC supporta una serie di connessioni multiplex tra due endpoint su UDP (User Datagram Protocol) ed è stato progettato per fornire protezione di sicurezza equivalente a TLS / SSL, insieme a una minore latenza di connessione e trasporto e stima della larghezza di banda in ciascuna direzione per evitare la congestione. L'obiettivo principale di QUIC è ottimizzare le applicazioni web orientate alla connessione che attualmente utilizzano TCP.

Se stai trasmettendo in streaming un mp3 o un video che potrebbe non essere necessariamente su HTTP, in effetti sarei sorpreso se lo fosse. Probabilmente sarebbe un altro protocollo su TCP, ma non vedo motivo per cui non è possibile eseguire lo streaming su UDP.

Se lo fai, devi tener conto che non c'è certezza che i tuoi dati arrivino dall'altra parte, ma posso presumere che tu sappia dell'UDP.

Per rispondere alla tua domanda, No, HTTP NON usa UDP. Per quello di cui parli, lo streaming di mp3 / video POTREBBE accadere su UDP e secondo me non dovrebbe mai accadere su HTTP.

In teoria sì, è possibile utilizzare UDP per http, ma potrebbe essere problematico. Supponiamo, ad esempio, che nel tuo esempio un mp3 o un video venga trasmesso in streaming, ci saranno problemi di ordinamento e alcuni bit potrebbero scomparire poiché UDP non è orientato alla connessione, non esiste un meccanismo di ritrasmissione.

Penso che alcune delle risposte manchino di un punto importante. La scelta tra UDP e TCP non dovrebbe essere basata sul tipo di dati (es. Audio o video) o se l'applicazione inizia a riprodurli prima che il trasferimento sia completato ("streaming"), ma se è in tempo reale . I dati in tempo reale sono (per definizione) sensibili al ritardo, quindi spesso è meglio inviarli tramite RTP / UDP (Real Time Protocol over UDP).

Il ritardo non è un problema con i dati memorizzati da un file, anche se si tratta di audio e / o video, quindi probabilmente è meglio inviarlo tramite TCP in modo che eventuali perdite di pacchetti possano essere corrette. Il mittente può leggere in anticipo e mantenere il tubo di rete pieno e il destinatario può anche utilizzare un sacco di buffering di playout in modo che non venga interrotto dalla ritrasmissione TCP occasionale o dal rallentamento momentaneo della rete. Il caso limite è il trasferimento dell'intera registrazione prima che inizi la riproduzione. Questo elimina ogni rischio di uno stallo della riproduzione, ma spesso non è pratico.

Il problema con TCP per i dati in tempo reale non è tanto la ritrasmissione quanto l'eccessivo buffering poiché TCP cerca di utilizzare il pipe nel modo più efficiente possibile senza riguardo alla latenza. UDP preserva i limiti dei pacchetti dell'applicazione e non ha memoria interna, quindi non introduce alcuna latenza.

La risposta: sì

Motivo: vedere il modello OSI.

spiegazione:

HTTP è un protocollo a livello di applicazione, che potrebbe essere incapsulato con un protocollo che utilizza UDP, fornendo una comunicazione affidabile e probabilmente più veloce del TCP. Il demone del server e il client dovrebbero ovviamente supportare questo nuovo protocollo. Il protocollo di Quake 2 dimostra che UDP può essere usato su TCP per fornire una base per un sistema di comunicazione strutturato che assicura il controllo del flusso (ad es. Chunk ids).

Prova a eseguire HTTP su UDP con Node-Httpp:

https://github.com/InstantWebP2P/node-httpp

http su udp è utilizzato da alcune implementazioni di tracker torrent (e supportato da tutti i client principali)

(Questa è una vecchia domanda, ma merita una risposta aggiornata.)

Con ogni probabilità , HTTP / 3 utilizzerà il protocollo QUIC , descritto come

trasporto multiplex su UDP

Quindi, da un certo punto di vista , potresti dire che HTTP / 3 userà UDP.

UDP è il miglior protocollo per lo streaming, perché non richiede pacchetti mancanti come TCP. E se non fa richieste, il flusso è molto più veloce e senza alcun buffering.

Anche il ritardo del flusso è inferiore a TCP. Questo perché TCP (come protocollo molto più sicuro) richiede pacchetti mancanti, sovrascrivendo quelli esistenti.

Quindi TCP è un protocollo troppo avanzato per essere utilizzato per lo streaming.