Qu'entendez-vous par: "le Web"? Vous voulez dire utiliser un navigateur? Ou sur Internet public?
benc le
Ce que je voulais demander, c'était de dire qu'il y a un mp3 hébergé sur une URL quelque chose comme someserver / somemusic.mp3 . Si cela est diffusé sur n'importe quel client - navigateur, appareil, etc., comment le http transfère-t-il cela? Si je comprends correctement les réponses ci-dessous, cela est délégué à RTP.
Sesh
Le port 80 UDP est également réservé à HTTP, ce que je trouve amusant car je ne l'ai jamais vu utilisé, et je ne pourrais pas non plus imaginer une bonne utilisation.
Joshua
1
C'est réservé parce que le comité IANA a une imagination plus flexible que vous. ;-) Ils s'imaginent qu'il pourrait bien y avoir une bonne utilisation. En outre, ne pas réserver le port 80 pour UDP / HTTP le laisserait ouvert pour un autre protocole UDP, ce qui ne ferait que semer la confusion en parlant du port 80.
Jesse Chisholm
Réponses:
42
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.
@ snowcrash09 Je ne peux même pas le supprimer moi-même, car il est accepté. C'est bizarre. Je l'ai réécrit, j'espère que c'est moins offensant maintenant.
détendre
1
Juste être pédant sur HTTP et le streaming - à l'époque sombre de la vidéo QuickTime, il y avait server push, où la connexion HTTP envoyait MJPEG (plusieurs images JPEG) chacun comme une partie distincte d'une réponse en plusieurs parties MIME à la requête HTTP. Chaque image JPEG arrive et remplace la précédente dans l'affichage. Mais vous avez raison @unwind, cela se fait rarement aujourd'hui, car RTP / RTSP fonctionne mieux.
Jesse Chisholm
3
@nos Youtube ne diffuse pas. Le navigateur télécharge un fichier dans un cache et commence la lecture à partir du fichier avant qu'il ne soit complètement téléchargé. Bien que cela simule le streaming, ce n'est pas le cas.
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 .
Pour être plus précis, la partie de l'UPnP qui utilise des messages de type UDP et HTTP est appelée SSDP (Simple Service Discovery Protocol). La structure du message est la même, mais l' METHODensemble est différent. Après cela, UPnP utilise d'autres protocoles (et généralement TCP) pour le reste de ce qu'il fait.
Jesse Chisholm
20
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.
Une autre question: les principaux navigateurs Web prennent-ils en charge les pages Web HTTP sur UDP?
user2284570
oui car HTTP est dans la couche application et UDP dans la couche transport. les navigateurs n'écrivent pas de paquets TCP ou UDP. Ils n'écrivent pas non plus de paquets IP. Ceux-ci sont gérés par le système d'exploitation et les pilotes. La couche Ethernet est si basse qu'elle peut être dans la puce proche du MAC à ce stade.
yan bellavance
@yanbellavance c'est complètement incorrect. Alors que les navigateurs et les serveurs Web en effet ne génèrent pas de premières trames TCP (ni les UDP pour cette question) , ils ne doivent choisir le transport à utiliser, et pour HTTP normal est toujours TCP. Le nouveau pseudo-protocole QUIC utilise cependant UDP.
Alnitak le
18
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.
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.
«streaming» sur HTTP est communément appelé (ce que je considère le plus précisément) «pseudo streaming» - un débit binaire régulé de données sur HTTP. Comme c'est souvent le cas dans notre monde, les types de marketing ont abusé de la nomenclature, laissant les gens axés sur les détails comme nous à la recherche de détails.
Stu Thompson
4
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.
Et bien mentionné: UDP is not connection oriented there is no retransmit mechanism.
ivanleoncz
4
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.
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).
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.
cela ne répond pas à la question, mais cela pourrait justifier une réponse.
Hawken
2
re: "meilleur protocole pour le streaming" étant donné que "la vitesse des blocs de données individuels" est plus importante que "toutes les données transitant". Si votre flux ne peut pas facilement récupérer des morceaux manquants, vous feriez mieux d'utiliser TCP. De nombreux protocoles vidéo de sécurité choisissent TCP pour cette raison - la fiabilité est plus importante que la vitesse brute.
Réponses:
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.
la source
server push, où la connexion HTTP envoyait MJPEG (plusieurs images JPEG) chacun comme une partie distincte d'une réponse en plusieurs parties MIME à la requête HTTP. Chaque image JPEG arrive et remplace la précédente dans l'affichage. Mais vous avez raison @unwind, cela se fait rarement aujourd'hui, car RTP / RTSP fonctionne mieux.À partir de la RFC 2616 :
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 .
la source
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.
la source
METHODensemble est différent. Après cela, UPnP utilise d'autres protocoles (et généralement TCP) pour le reste de ce qu'il fait.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:
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?
la source
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.
la source
Peut-être un changement sur ce sujet avec QUIC
la source
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.
la source
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.
la source
UDP is not connection oriented there is no retransmit mechanism.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 source
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).
la source
Essayez d'exécuter HTTP sur UDP avec node-httpp:
https://github.com/InstantWebP2P/node-httpp
la source
http sur udp est utilisé par certaines implémentations de tracker torrent (et supporté par tous les principaux clients)
la source
(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
Donc, d'un certain point de vue , on pourrait dire que HTTP / 3 utilisera UDP.
la source
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.
la source