HTTP utilise-t-il UDP?

Cela pourrait être une question idiote:

• HTTP utilise-t-il déjà le protocole de datagramme utilisateur?

Par exemple:

Si quelqu'un diffuse des fichiers MP3 ou vidéo en utilisant HTTP, utilise-t-il en interne UDP pour le transport?

En règle générale, non.

Le streaming est rarement utilisé sur HTTP lui-même, et HTTP est rarement exécuté sur UDP. Voir, cependant, RTP .

Pour quelque chose comme votre exemple (dans le commentaire), vous ne montrez pas de protocole pour la ressource. Si ce protocole devait être HTTP, alors je n'appellerais pas l'accès "streaming"; même si, dans un certain sens du terme, c'est parce qu'il envoie une ressource (éventuellement importante) en série sur un réseau. En règle générale, la ressource sera enregistrée sur le disque local avant d'être lue, de sorte que le transfert réseau n'est pas ce que l'on entend habituellement par «streaming».

Comme les commentateurs l'ont souligné, cependant, il est certainement possible de vraiment diffuser sur HTTP, et cela est fait par certains.

À partir de la RFC 2616 :

La communication HTTP a généralement lieu via des connexions TCP / IP. Le port par défaut est TCP 80, mais d'autres ports peuvent être utilisés. Cela n'empêche pas que HTTP soit implémenté par-dessus tout autre protocole sur Internet ou sur d'autres réseaux. HTTP suppose uniquement un transport fiable; tout protocole offrant de telles garanties peut être utilisé; le mappage des structures de demande et de réponse HTTP / 1.1 sur les unités de données de transport du protocole en question sort du cadre de cette spécification.

Donc, bien qu'il ne le dise pas explicitement, UDP n'est pas utilisé car ce n'est pas un "transport fiable".

EDIT - plus récemment, le protocole QUIC (qui est plus strictement un pseudo-transport ou un protocole de couche de session) utilise UDP pour transporter le trafic HTTP / 2.0 et une grande partie du trafic de Google utilise déjà ce protocole. Il progresse actuellement vers la normalisation en tant que HTTP / 3 .

Peut-être juste un peu de trivial, mais UPnP utilisera des messages au format HTTP sur UDP pour la découverte de périphériques.

Oui, HTTP, en tant que protocole d'application, peut être transféré via le protocole de transport UDP. Voici quelques-uns des services qui utilisent UDP et un protocole sous-jacent pour transférer des données HTTP et les diffuser à l'utilisateur final:

• Méthode de transport Jingle Raw UDP de XMPP
• Un numéro pour les services qui utilisent UDT --- protocole de transfert de données basé sur UDP, qui est un sur-ensemble du protocole UDP.
• Le protocole TLS (Transport Layer Security) encapsulant HTTP ainsi que le protocole XMPP mentionné ci-dessus et d'autres protocoles d'application ont une implémentation qui utilise UDP dans sa couche de transport; cette implémentation est appelée Datagram Transport Layer Security (DTLS).
• Les notifications push dans GNUTella sont des requêtes HTTP envoyées via le transport UDP.

Cet article contient plus de détails sur le streaming sur UDP et son sur-ensemble fiable, le RUDP: Reliable UDP (RUDP): The Next Big Streaming Protocol?

Bien sûr, il ne doit pas nécessairement être transmis via TCP. J'ai implémenté HTTP sur UDP, pour une utilisation dans l'industrie de la diffusion de télévision par satellite.

Peut-être un changement sur ce sujet avec QUIC

QUIC (Quick UDP Internet Connections, prononcé quick) est un protocole de réseau de couche de transport expérimental développé par Google et mis en œuvre en 2013. QUIC prend en charge un ensemble de connexions multiplexées entre deux points de terminaison via le protocole UDP (User Datagram Protocol), et a été conçu pour fournir une protection de sécurité équivalent à TLS / SSL, avec une latence de connexion et de transport réduite et une estimation de la bande passante dans chaque direction pour éviter la congestion. L'objectif principal de QUIC est d'optimiser les applications Web orientées connexion utilisant actuellement TCP.

Si vous diffusez un mp3 ou une vidéo qui n'est pas nécessairement via HTTP, en fait, je serais surpris si c'était le cas. Ce serait probablement un autre protocole sur TCP, mais je ne vois aucune raison pour laquelle vous ne pouvez pas diffuser sur UDP.

Si vous le faites, vous devez tenir compte du fait qu'il n'y a aucune certitude que vos données arriveront à l'autre bout, mais je peux comprendre que vous connaissez UDP.

Pour répondre à votre question, non, HTTP n'utilise PAS UDP. Pour ce dont vous parlez cependant, le streaming mp3 / vidéo POURRAIT se produire sur UDP et à mon avis ne devrait jamais se produire sur HTTP.

En théorie, oui, il est possible d'utiliser UDP pour http mais cela peut poser problème. Par exemple, dans votre exemple, un mp3 ou une vidéo est diffusé en continu, il y aura un problème de commande et certains bits pourraient manquer car UDP n'est pas orienté connexion, il n'y a pas de mécanisme de retransmission.

Je pense que certaines des réponses manquent un point important. Le choix entre UDP et TCP ne doit pas être basé sur le type de données (par exemple, audio ou vidéo) ou si l'application commence à les lire avant la fin du transfert ("streaming"), mais si elles sont en temps réel . Les données en temps réel sont (par définition) sensibles aux délais, il est donc souvent préférable de les envoyer via RTP / UDP (Real Time Protocol over UDP).

Le retard n'est pas un problème avec les données stockées à partir d'un fichier, même s'il s'agit d'audio et / ou de vidéo, il est donc probablement préférable de l'envoyer via TCP afin que toute perte de paquet puisse être corrigée. L'expéditeur peut lire à l'avance et garder le canal réseau plein et le récepteur peut également utiliser beaucoup de mémoire tampon de lecture afin qu'il ne soit pas interrompu par la retransmission TCP occasionnelle ou le ralentissement momentané du réseau. Le cas limite est celui où l'intégralité de l'enregistrement est transférée avant le début de la lecture. Cela élimine tout risque de blocage de la lecture, mais est souvent peu pratique.

Le problème avec TCP pour les données en temps réel n'est pas tant les retransmissions que la mise en mémoire tampon excessive, car TCP essaie d'utiliser le canal aussi efficacement que possible sans tenir compte de la latence. UDP préserve les limites des paquets d'application et n'a pas de stockage interne, donc il n'introduit aucune latence.

La réponse: oui

Raison: voir le modèle OSI.

Explication:

HTTP est un protocole de couche application, qui pourrait être encapsulé avec un protocole qui utilise UDP, fournissant sans doute une communication fiable plus rapide que TCP. Le démon serveur et le client devraient évidemment prendre en charge ce nouveau protocole. Le protocole Quake 2 prouve qu'UDP peut être utilisé sur TCP pour fournir une base pour un système de communication structuré assurant le contrôle de flux (par exemple, des identifiants de bloc).

Essayez d'exécuter HTTP sur UDP avec node-httpp:

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

http sur udp est utilisé par certaines implémentations de tracker torrent (et supporté par tous les principaux clients)

(C'est une vieille question, mais elle mérite une réponse mise à jour.)

Selon toute vraisemblance , HTTP / 3 utilisera le protocole QUIC , qui est décrit comme

transport multiplexé sur UDP

Donc, d'un certain point de vue , on pourrait dire que HTTP / 3 utilisera UDP.

UDP est le meilleur protocole pour le streaming, car il ne demande pas de paquets manquants comme TCP. Et si cela ne demande pas, le flux est beaucoup plus rapide et sans aucune mise en mémoire tampon.

Même le délai de flux est inférieur à TCP. C'est parce que TCP (en tant que protocole beaucoup plus sécurisé) demande des paquets manquants, écrasant les paquets existants.

TCP est donc un protocole trop avancé pour être utilisé pour le streaming.