Après avoir fini de lire la spécification HTTP / 2 , je pense que HTTP / 2 fait des websockets obsolètes pour la plupart des cas d'utilisation, mais peut-être pas tous.
PUSH_PROMISE
(familièrement connu sous le nom de serveur push) n'est pas le problème ici. Ce n'est qu'une optimisation des performances.
Le principal cas d'utilisation des Websockets dans un navigateur est d'activer le streaming bidirectionnel de données. Donc, je pense que la question de l'OP devient de savoir si HTTP / 2 fait un meilleur travail d'activation du streaming bidirectionnel dans le navigateur, et je pense que oui, c'est le cas.
Tout d' abord, il est bi-di. Lisez simplement 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 au sein d'une connexion HTTP / 2. Les flux ont plusieurs caractéristiques importantes:
Une seule connexion HTTP / 2 peut contenir plusieurs flux ouverts simultanément, avec des trames entrelacées de point 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 terminaux.
Des articles comme celui-ci (liés dans une autre réponse) se trompent sur 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 lancer un flux régulier, seulement un flux push. Mais une fois que le client ouvre un flux en envoyant une demande, les deux parties peuvent envoyer des trames de données à travers un socket persistant à tout moment - bidirectionnel complet.
Ce n'est pas très différent des websockets: le client doit également initier une demande de mise à niveau du websocket avant que le serveur puisse 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 obtiennent des identifiants et comment les trames portent l'ID du flux sur lequel elles se trouvent. HTTP / 2 définit également la sémantique de contrôle de flux pour hiérarchiser les flux. Ceci est important dans la plupart des applications réelles de bidi.
(Ce mauvais article dit également que la norme Websocket a le multiplexage. Non, ce n'est pas le cas. Ce n'est pas vraiment difficile à découvrir, ouvrez simplement le Websocket RFC 6455 et appuyez sur ⌘-F, et tapez "multiplex". Après avoir lu
Le protocole se veut extensible; les futures versions introduiront probablement des concepts supplémentaires tels que le multiplexage.
Vous constaterez qu'il existe un projet d'extension 2013 pour le multiplexage Websocket. Mais je ne sais pas quels navigateurs, le cas échéant, prennent en charge cela. Je n'essaierais pas de construire ma webapp SPA sur le dos de cette extension, en particulier avec l'arrivée de HTTP / 2, le support peut ne jamais arriver).
Le multiplexage est exactement le genre de chose que vous devez normalement faire vous-même chaque fois que vous ouvrez une websocket pour bidi, par exemple, pour alimenter une application à page unique à mise à jour réactive. Je suis content 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, regardez simplement gRPC. gRPC est implémenté via HTTP / 2. Examinez spécifiquement les options de streaming semi-duplex et full duplex que gRPC offre. (Notez que gRPC ne fonctionne pas actuellement dans les navigateurs, mais c'est en fait parce que les navigateurs (1) n'exposent pas le cadre HTTP / 2 au javascript du client et (2) ne prennent généralement pas en charge les remorques, qui sont utilisées dans la spécification gRPC.)
Où les websockets pourraient-ils encore avoir leur place? Le gros est le serveur-> les données binaires poussées par le navigateur. HTTP / 2 autorise les données binaires poussées par le serveur-> navigateur, mais elles ne sont pas exposées dans JS du navigateur. Pour des applications telles que la transmission d'images audio et vidéo, c'est une raison pour utiliser des Websockets.
Édition: 17 janv.2020
Au fil du temps, cette réponse a progressivement atteint le sommet (ce qui est bien, car cette réponse est plus ou moins correcte). Cependant, il y a encore des commentaires occasionnels disant que ce n'est pas correct pour diverses raisons, généralement liées à une certaine confusion PUSH_PROMISE
ou à la façon de consommer réellement le serveur orienté message -> push client dans une application d'une seule page. Et, il existe un cas d'utilisation pour les websockets dans un navigateur, qui sont des données binaires poussées par le serveur. Pour les données textuelles, y compris JSON, n'utilisez pas de Websockets, utilisez SSE.
Pour récapituler: le protocole HTTP / 2 est bi-di complet. Cependant, les navigateurs Web modernes n'exposent pas le protocole HTTP / 2 orienté cadre à JavaScript . Néanmoins, si vous effectuez plusieurs requêtes vers la même origine via une connexion HTTP / 2, sous le capot, tout ce trafic est multiplexé sur une connexion (et c'est ce qui nous intéresse!).
Donc, si vous devez créer une application de chat en temps réel, disons, où vous devez diffuser de nouveaux messages de chat à tous les clients de la salle de chat qui ont des connexions ouvertes, vous pouvez (et devriez probablement) le faire sans websockets.
Vous utiliseriez les événements envoyés par le serveur pour pousser les messages vers le bas et l' api Fetch pour envoyer les demandes vers le haut. Les événements envoyés par le serveur (SSE) sont une API peu connue mais bien prise en charge qui expose un flux serveur à client orienté message. Bien qu'il ne ressemble pas au JavaScript du client, sous le capot, votre navigateur (s'il prend en charge HTTP / 2) réutilisera une seule connexion TCP pour multiplexer tous ces messages. Il n'y a aucune perte d'efficacité et en fait c'est un gain sur les websockets. Besoin de plusieurs flux? Ouvrez plusieurs EventSources! Ils seront automatiquement multiplexés pour vous.
En plus d'être plus efficaces en termes de ressources et d'avoir moins de latence initiale qu'une poignée de main websocket, les événements envoyés par le serveur ont la belle propriété de se replier automatiquement et de fonctionner sur HTTP / 1.1. Mais lorsque vous avez une connexion HTTP / 2, ils fonctionnent incroyablement bien.
Voici un bon article avec un exemple concret de réalisation du SPA réactualisé.