Ne HTTP UDP?
Cela peut être une question bête:
- HTTP jamais utiliser le Protocole de Datagramme Utilisateur?
Par exemple:
Si l'un est streaming MP3 ou vidéo en utilisant le protocole HTTP, n'en interne l'utilisation d'UDP pour le transport?
- Que voulez-vous dire par: "le web"? Tu veux dire à l'aide d'un navigateur? Ou sur le réseau internet public?
- Ce que je voulais dire a été de dire qu'il est un mp3 hébergé sur une URL, quelque chose comme someserver/somemusic.mp3. Si c'est diffusé à tout client de navigateur, appareil etc. comment fonctionne le transfert de http présent. Si j'ai bien compris les réponses ci-dessous correctement, c'est déléguée à des RTP.
- Le Port 80 UDP est également réservé pour HTTP, que je trouve amusant que je ne l'ai jamais vu utilisé, ni ai-je pu imaginer un bon usage.
- Il est réservé parce que le comité de l'IANA a un moyen plus souple de l'imagination que vous faites. 😉 Ils ont l'image qu'il pourrait être une bonne utilisation. En outre, de ne pas réserver le port 80 pour UDP/HTTP laisser ouvert pour un autre protocole UDP, ce qui pourrait causer de la confusion lorsque l'on parle le port 80.
Vous devez vous connecter pour publier un commentaire.
Généralement, no.
Streaming est rarement utilisé sur HTTP lui-même, et HTTP fonctionne rarement au dessus de UDP. Voir, cependant, RTP.
Pour quelque chose que votre exemple (dans les commentaires), vous n'êtes pas en montrant un protocole pour la ressource. Si ce protocole HTTP, alors je ne dirais pas l'accès "streaming"; même si dans un certain sens de la parole est puisque c'est l'envoi d'une (peut-être grand) de la ressource en série sur un réseau. Généralement, la ressource sera enregistré sur le disque local avant d'être joué en arrière, de sorte que le réseau de transfert n'est pas ce qui est généralement traduit par "streaming".
Comme les commentateurs l'ont souligné, si, il est certainement possible de diffuser sur HTTP, et qui est fait par certains.
server push, où la connexion HTTP envoyer MJPEG (plusieurs images JPEG) comme une partie distincte d'un MIME multipart réponse à la requête HTTP. Chaque image JPEG arrive et remplace le précédent dans l'affichage. Mais vous avez raison @détendez-vous, ce qui est rarement le cas aujourd'hui, puisque RTP/RTSP fonctionne mieux.De La RFC 2616:
Ainsi, bien que cela ne soit pas explicitement le dire, UDP n'est pas utilisé car il n'est pas un "transport fiable".
MODIFIER - plus récemment, le QUIC protocole (ce qui est plus strictement un pseudo-transport ou une session de protocole de couche) n'utilisent UDP pour la réalisation de HTTP/2.0 trafic et beaucoup de Google trafic utilise déjà ce protocole. Il est actuellement en progrès vers la normalisation HTTP/3.
Peut-être juste un peu de trivia, mais UPnP utilisera HTTP messages formatés sur UDP pour la découverte du périphérique.
METHODsont différentes. Après cela, UPnP utilise d'autres protocoles (et généralement TCP) pour le reste de ce qu'il fait.Oui, HTTP, comme un protocole d'application, peuvent être transférés sur UDP protocole de transport.
Voici quelques-uns des services qui utilisent UDP et un sous-jacent protocole HTTP pour le transfert de données et de les diffuser à l'utilisateur final:
Cet article contient de plus amples détails sur streaming sur UDP et fiables sur-ensemble, la RUDP: Fiable UDP (RUDP): La Prochaine Grande Protocole de Streaming?
Bien sûr, il ne doit pas nécessairement être transmises sur TCP. J'ai mis en place le protocole HTTP sur le dessus de UDP, pour une utilisation dans la TÉLÉVISION par Satellite de Radiodiffusion de l'industrie.
Peut-être un peu de changement sur ce sujet avec QUIC
Si vous êtes en streaming un mp3 ou une vidéo qui ne peuvent pas nécessairement être sur HTTP, en fait, je serais surpris si elle l'était. Il serait probablement un autre protocole sur TCP, mais je ne vois aucune raison pourquoi vous ne pouvez pas diffuser sur UDP.
Si vous ne vous devez prendre en compte qu'il n'existe aucune certitude que vos données vont arriver à l'autre extrémité, mais je peux prendre ce que tu connais sur le protocole UDP.
Pour répondre à votre question, Non, HTTP ne PAS utiliser UDP.
Pour ce que vous parlez bien, mp3/streaming vidéo POURRAIT arriver sur UDP et à mon avis ne devrait jamais se produire sur HTTP.
En théorie, oui, il est possible d'utiliser UDP, http, mais qui pourrait être problématique. Dire, par exemple, dans votre exemple, un mp3 ou une vidéo est diffusée il y aura des problème de commande et de certains bits peut aller de l'absence d'UDP n'est pas orienté connexion il n'y a pas de mécanisme de retransmission.
UDP is not connection oriented there is no retransmit mechanism.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 le protocole UDP, offrant sans doute plus rapide de communication fiable que TCP. Le démon du serveur et un client serait évidemment nécessaire à l'appui de ce nouveau protocole. Quake 2 protocole prouve que UDP peuvent être utilisés sur TCP pour fournir une base pour un système de communication structuré et assurer le contrôle de flux (par exemple, bloc id).
Essayez d'exécuter HTTP sur le port UDP avec nœud-httpp:
https://github.com/InstantWebP2P/node-httpp
Je pense que certaines réponses sont manquantes, un point important. Le choix entre UDP et TCP doit pas être basé sur le type de données (par exemple, audio ou vidéo) ou si la demande commence à jouer avant le transfert est terminé ("streaming"), mais qu'il est temps réel. Des données en temps réel est (par définition) un retard sensible, de sorte qu'il est souvent préférable envoyés via le protocole RTP/UDP (Real Time Protocol UDP).
Le retard n'est pas un problème avec les données stockées à partir d'un fichier, même si c'est de l'audio et/ou vidéo, de sorte qu'il est probablement le meilleur envoyés sur TCP, donc toute les pertes de paquets peuvent être corrigées. L'expéditeur peut lire à l'avance et garder le canal de réseau complet et le récepteur peut également utiliser des lots de diffusion, de mise en mémoire tampon de sorte qu'il ne sera pas interrompue par l'occasionnels de retransmission TCP ou momentanée ralentissement du réseau. Le cas limite est l'endroit où l'enregistrement est transféré avant le début de la lecture. Cela élimine tout risque d'une lecture de décrochage, mais est souvent peu pratique.
Le problème avec le protocole TCP pour les données en temps réel n'est pas retransmissions tellement excessive de mise en mémoire tampon TCP essaie d'utiliser le tuyau aussi efficacement que possible, sans égard à la latence. UDP conserve paquet de demande de frontières et n'a pas de mémoire de stockage interne, de sorte qu'il n'introduit pas de temps de latence.
http sur le port udp est utilisé par certains torrent tracker implémentations (et supporteb par tous les principaux clients)
(C'est une vieille question, mais il mérite une mise à jour de réponse.)
Dans tous les probabilité, HTTP/3 sera à l'aide de la QUIC protocole, qui est décrit comme
Donc, à partir d'un certain point de vue., on pourrait dire que HTTP/3 sera en utilisant UDP.
UDP est le meilleur protocole pour la diffusion, parce qu'il ne veut pas faire des demandes pour les paquets manquants, comme TCP. Et si ça n'a pas de demandes, le débit est beaucoup plus rapide et sans mise en mémoire tampon.
Même les flux de retard est moindre que TCP. C'est parce que TCP (comme beaucoup plus sécurisé protocole) fait des demandes pour les paquets manquants, remplacer les existants.
TCP est un protocole trop avancé pour être utilisé pour le streaming.