Est-ce que HTTP / 2 rend les websockets obsolètes?
J'apprends le protocole HTTP/2. C'est un protocole binaire avec de petites trames de message. Il permet le multiplexage de flux sur une seule connexion TCP. Conceptuellement, cela ressemble beaucoup à WebSockets.
Est-il prévu de Websockets obsolètes et de les remplacer par une sorte de requêtes HTTP/2 sans en-tête et de messages Push lancés par le serveur? Ou bien WebSockets complétera-t-il HTTP/2?
D'après ce que j'ai compris, HTTP/2 ne remplace pas Websocket, mais vise à normaliser le protocole SPDY.
Dans HTTP/2, Server-Push est utilisé en arrière-plan pour améliorer le chargement des ressources par le client à partir du navigateur. En tant que développeur, vous ne vous en souciez pas vraiment pendant votre développement. Cependant, avec Websocket, le développeur est autorisé à utiliser une API capable de consommer un message Push avec une connexion en duplex intégral unique.
Ce ne sont pas les mêmes choses, et elles devraient se compléter.
Après avoir fini de lire HTTP/2 spec , je pense que HTTP/2 ne contient pas de websockets obsolètes, mais peut-être pas tous.
Push_PROMISE (familièrement appelé serveur Push) n'est pas le problème ici. C'est juste une optimisation de la performance.
Le principal cas d'utilisation de Websockets dans un navigateur consiste à activer la diffusion bidirectionnelle de données. Donc, je pense que la question qui se pose à l'OP est de savoir si HTTP/2 fait un meilleur travail en permettant la diffusion en continu bidirectionnelle dans le navigateur, et je pense que oui, c'est le cas.
Tout d’abord, il est bi-di. Il suffit de lire l'introduction à la section des flux :
Un "flux" est une séquence bidirectionnelle indépendante de trames échangées entre le client et le serveur dans une connexion HTTP/2. Les ruisseaux ont plusieurs caractéristiques importantes:
Une seule connexion HTTP/2 peut contenir plusieurs flux ouverts simultanément, avec des images d'entrelacement de points d'extrémité provenant de plusieurs flux.
Les flux peuvent être établis et utilisés unilatéralement ou partagés par le client ou le serveur.
Les flux peuvent être fermés par l'un ou l'autre des points d'extrémité.
Des articles tels que this (lié dans une autre réponse) ont tort à propos de cet aspect de HTTP/2. Ils disent que ce n'est pas bidi. Regardez, il y a une chose qui ne peut pas arriver avec HTTP/2: une fois la connexion ouverte, le serveur ne peut pas initier un flux régulier, mais uniquement un flux Push. Mais une fois que le client ouvre un flux en envoyant une demande, les deux côtés peuvent envoyer des trames de données via un socket persistant à tout moment (full bidi).
Ce n'est pas très différent des websockets: le client doit également lancer une demande de mise à niveau de websocket avant que le serveur puisse également envoyer des données.
La plus grande différence est que, contrairement aux websockets, HTTP/2 définit sa propre sémantique de multiplexage: comment les flux reçoivent-ils des identifiants et comment les trames portent-elles l'identifiant du flux sur lequel elles se trouvent. HTTP/2 définit également la sémantique du contrôle de flux pour la hiérarchisation des flux. Ceci est important dans la plupart des applications réelles de bidi.
(Cet article erroné indique également que la norme Websocket est multiplexée. Non, ce n'est pas difficile. Pour le savoir, ouvrez simplement Websocket RFC 6455 et appuyez sur-F, puis tapez "multiplex". Après avoir lu
Le protocole est destiné à être extensible; les versions futures introduiront probablement d'autres concepts tels que le multiplexage.
Vous constaterez qu'il existe 2013 brouillon d'extension pour le multiplexage Websocket. Mais je ne sais pas quels navigateurs, le cas échéant, supportent cela. Je n'essaierais pas de construire ma webapp SPA sur le dos de cette extension, en particulier avec HTTP/2 à venir, le support risque de ne jamais arriver).
Le multiplexage est exactement le genre de chose que vous devez normalement faire vous-même lorsque vous ouvrez une prise Web pour un bidon, par exemple, pour alimenter une application de page unique à mise à jour réactive. Je suis heureux que ce soit dans la spécification HTTP/2, pris en charge une fois pour toutes.
Si vous voulez savoir ce que HTTP/2 peut faire, il suffit de regarder gRPC. Le gRPC est implémenté sur HTTP/2. Examinez particulièrement les options de streaming semi-duplex et duplex intégral proposées par gRPC. (Notez que gRPC ne fonctionne pas actuellement dans les navigateurs, mais c’est parce que les navigateurs (1) n’exposent pas la trame HTTP/2 au javascript du client, et (2) ne prennent généralement pas en charge les bandes-annonces utilisées les spécifications de gRPC)
Où les websockets pourraient-ils encore avoir une place? Si vous n'avez pas besoin d'aucun des bits supplémentaires spécifiés par HTTP/2 (c'est une spécification énorme et compliquée), alors peut-être que les websockets sont meilleurs. Passant la main sur la difficulté de mise en œuvre, je suis convaincu que le respect du protocole websocket coûtera toujours moins cher en calcul que HTTP/2 - HTTP/2 nécessite simplement que vous fassiez plus de choses.
La taille des cadres est très comparable. Les trames Websocket sont un peu plus petites, soit 2 à 14 octets d’en-tête par image, par rapport à la version 9 fixée de HTTP/2. Parce que websocket a opté pour un en-tête de longueur variable, il peut encoder des images plus grandes HTTP/2 2 ^ 24-1 bits par image). Donc, si vous avez besoin d'une prise pour aspirer quelque chose de gras sans beaucoup de cérémonie, comme, je ne sais pas, peut-être des images vidéo, alors les prises Web peuvent toujours avoir un sens. Pour la plupart des cas d'utilisation, en particulier les éléments liés aux pages Web, je pense que HTTP/2 semble être la voie à suivre.
Je dis non (les Websockets ne sont pas obsolètes).
Le premier problème, le plus souvent ignoré, est le suivant: HTTP/2 Push n'est pas applicable et peut être ignoré par les mandataires, les routeurs, les autres intermédiaires ou même le navigateur.
c'est-à-dire (à partir du brouillon HTTP2):
Un intermédiaire peut recevoir des commandes du serveur et choisir de ne pas les transférer au client. En d'autres termes, l'utilisation de l'information transmise dépend de cet intermédiaire. De même, l'intermédiaire peut choisir de faire des envois supplémentaires au client, sans aucune action du serveur.
De plus, les connexions HTTP/2 se ferment après un certain temps.
Il est vrai que la norme stipule que:
Les connexions HTTP/2 sont persistantes. Pour des performances optimales, les clients ne devraient pas fermer les connexions tant qu'il n'a pas été déterminé qu'aucune autre communication avec un serveur n'est nécessaire (par exemple, lorsqu'un utilisateur quitte une page Web particulière) ou jusqu'à ce que le serveur ferme la connexion.
Mais...
Les serveurs sont encouragés à maintenir les connexions ouvertes aussi longtemps que possible mais sont autorisés à terminer les connexions inactives si nécessaire. Lorsqu'un point d'extrémité choisit de fermer la connexion de couche de transport TCP, le point d'extrémité de terminaison DEVRAIT tout d'abord envoyer une trame GOAWAY (paragraphe 6.8) afin que les deux points d'extrémité puissent déterminer de manière fiable si les trames envoyées précédemment ont été traitées et complétées correctement. mettre fin aux tâches restantes nécessaires.
Même si la même connexion permet de transmettre du contenu pendant son ouverture et même si HTTP/2 résout certains problèmes de performances introduits par la fonctionnalité 'Keep-Alive' de HTTP/1.1 ... les connexions HTTP/2 ne sont pas maintenues ouvertes indéfiniment .
Une page Web ne peut pas non plus ré-initier une connexion HTTP/2 une fois fermée (à moins que nous ne revenions à une longue attente).
EDIT (2017, deux ans plus tard)
Les implémentations de HTTP/2 montrent que plusieurs onglets/fenêtres de navigateur partagent une seule connexion HTTP/2, ce qui signifie que Push ne saura jamais à quel onglet/fenêtre il appartient, éliminant ainsi l'utilisation de Push en remplacement. pour les Websockets.
La réponse est non. Le but entre les deux est très différent. Il existe même un RFC pour WebSocket sur HTTP/2 qui vous permet d’établir plusieurs connexions WebSocket sur un seul canal HTTP/2 TCP.
WS over HTTP/2 sera un jeu de conservation des ressources en réduisant le temps nécessaire pour ouvrir de nouvelles connexions et en permettant davantage de canaux de communication sans la dépense supplémentaire liée à davantage de sockets, d’IRQ logicielles et de tampons.
https://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-01
Eh bien, pour citer cet InfoQ article:
Eh bien, la réponse est clairement non, pour une raison simple: comme nous l'avons vu ci-dessus, HTTP/2 introduit Server Push, qui permet au serveur d'envoyer des ressources de manière proactive au cache du client. Cependant, cela ne permet pas de transmettre des données à l'application cliente elle-même. Les envois serveur ne sont traités que par le navigateur et ne font pas apparaître le code de l'application, ce qui signifie qu'il n'y a pas d'API permettant à l'application de recevoir des notifications pour ces événements.
Et si HTTP2 Push est vraiment quelque chose entre votre navigateur et votre serveur, alors que Websockets expose vraiment les API qui peuvent être utilisées à la fois par le client (javascript, s'il est exécuté sur le navigateur) et le code d'application (exécuté sur le serveur) pour le transfert de données en temps réel.
L'échange de messages et la diffusion simple (pas l'audio ni la vidéo) peuvent être effectués via le multiplexage Http/2 et WebSockets. Il y a donc un certain chevauchement, mais les WebSockets ont un protocole bien établi, beaucoup de frameworks/API et moins de charge d'en-tête. Voici l'article de Nice sur le sujet .
Il y aura une implémentation WebSocket dans HTTP/2. https://tools.ietf.org/html/rfc8441