HTTP / 2 rend-il les sockets Web obsolètes?

J'apprends le protocole HTTP / 2. C'est un protocole binaire avec de petits télégrammes. Il permet le multiplexage de flux sur une seule connexion TCP. Conceptuellement, cela semble très similaire aux WebSockets.

Est-il prévu de rendre les sockets Web 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 les WebSockets compléteront-ils HTTP / 2?

D'après ce que j'ai compris, HTTP / 2 ne remplace pas websocket mais vise à standardiser le protocole SPDY.

Dans HTTP / 2, la poussée du serveur est utilisée 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 l'API qui est capable de consommer et d'envoyer des messages avec une connexion full-duplex unique.

Ce ne sont pas les mêmes choses et elles devraient se compléter.

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_PROMISEou à 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é.

Je dis non (les Websockets ne sont pas obsolètes ).

Le premier problème, le plus souvent ignoré, est que la diffusion HTTP / 2 n'est pas exécutoire et peut être ignorée par les mandataires, les routeurs, d'autres intermédiaires ou même le navigateur.

c'est-à-dire (du projet HTTP2):

Un intermédiaire peut recevoir des push du serveur et choisir de ne pas les transmettre au client . En d'autres termes, la manière d'utiliser les informations transmises dépend de cet intermédiaire. De même, l'intermédiaire peut choisir de faire des push supplémentaires au client, sans aucune action de la part du serveur.

Par conséquent, HTTP / 2 Push ne peut pas remplacer WebSockets.

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 de meilleures performances, il est prévu que les clients ne ferment pas les connexions jusqu'à ce qu'il soit déterminé qu'aucune autre communication avec un serveur n'est nécessaire (par exemple, lorsqu'un utilisateur s'éloigne d'une page Web particulière) ou jusqu'à ce que le serveur ferme la connexion.

Mais...

Les serveurs sont encouragés à maintenir des connexions ouvertes aussi longtemps que possible, mais sont autorisés à mettre fin aux connexions inactives si nécessaire. Lorsque l'un des points d'extrémité choisit de fermer la connexion TCP de la couche de transport, le point d'extrémité de terminaison DEVRAIT d'abord envoyer une trame GOAWAY (section 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 terminer correctement ou terminer les tâches restantes nécessaires.

Même si la même connexion permet de pousser le contenu pendant qu'il est ouvert et même si HTTP / 2 résout certains des problèmes de performances introduits par la «persistance» de HTTP / 1.1 ... Les connexions HTTP / 2 ne sont pas ouvertes indéfiniment .

Une page Web ne peut pas non plus rétablir une connexion HTTP / 2 une fois fermée (à moins que nous ne soyons de retour à une longue traction, c'est-à-dire).

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 qu'ils pushne sauront jamais à quel onglet / fenêtre il appartient, éliminant ainsi l'utilisation pushen remplacement des Websockets.

EDIT (2020)

Je ne sais pas pourquoi les gens ont commencé à voter contre la réponse. En fait, les années écoulées depuis la publication de la réponse ont prouvé que HTTP / 2 ne peut pas remplacer WebSockets et n'a pas été conçu pour le faire.

Certes, HTTP / 2 peut être utilisé pour tunnel connexions WebSocket, mais ces connexions Tunneled , il faudra encore le protocole WebSocket et ils auront un effet sur la façon dont les HTTP / 2 se comporte de conteneurs.

La réponse est non. Les objectifs entre les deux sont très différents. Il existe même un RFC pour WebSocket sur HTTP / 2 qui vous permet d'établir plusieurs connexions WebSocket sur un seul canal TCP HTTP / 2.

WS sur HTTP / 2 sera un jeu de conservation des ressources en réduisant le temps pour ouvrir de nouvelles connexions et en permettant plus de canaux de communication sans le coût supplémentaire de plus 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 article d' InfoQ :

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 proactivement des ressources au cache client. Cependant, il ne permet pas de transférer des données vers l'application cliente elle-même. Les push du serveur sont uniquement traités par le navigateur et n'apparaissent pas dans le code de l'application, ce qui signifie qu'il n'y a pas d'API pour que l'application reçoive des notifications pour ces événements.

Et donc la poussée HTTP2 est vraiment quelque chose entre votre navigateur et votre serveur, tandis que les Websockets exposent vraiment les API qui peuvent être utilisées par le client (javascript, s'il fonctionne sur le navigateur) et le code d'application (exécuté sur le serveur) pour transférer des données en temps réel.

L'échange de messages et le streaming simple (pas le streaming audio, 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 surcharge d'en-têtes. Voici un bel article sur le sujet .

À ce jour, non.

HTTP / 2, par rapport à HTTP, vous permet de maintenir une connexion avec un serveur. De là, vous pouvez avoir plusieurs flux de données en même temps. Le but est que vous puissiez pousser plusieurs choses en même temps sans que le client ne le demande. Par exemple, lorsqu'un navigateur demande unindex.html , le serveur peut également vouloir pousser index.csset index.js. Le navigateur ne l'a pas demandé, mais le serveur peut le fournir sans qu'on le lui demande, car il peut supposer que vous voudrez en quelques secondes.

C'est plus rapide que l'alternative HTTP / 1 d'obtenir index.html, d'analyser, de découvrir ses besoins index.jsetindex.css et puis la construction de 2 autres demandes de ces fichiers. HTTP / 2 permet au serveur d'envoyer des données que le client n'a même pas demandées.

Dans ce contexte, il est similaire à WebSocket, mais pas vraiment par conception. WebSocket est censé permettre une communication bidirectionnelle similaire à une connexion TCP ou une connexion série. C'est une prise où les deux communiquent. De plus, la principale différence est que vous pouvez envoyer des paquets de données arbitraires en octets bruts, non encapsulés dans le protocole HTTP. Les concepts d'en-têtes, de chemins, de chaînes de requête ne se produisent que pendant la prise de contact, mais WebSocket ouvre un flux de données.

L'autre différence est que vous obtenez un accès beaucoup plus fin à WebSocket en Javascript, alors qu'avec HTTP, il est géré par le navigateur. Tout ce que vous obtenez avec HTTP est tout ce que vous pouvez intégrer dans XHR/ fetch(). Cela signifie également que le navigateur se rendre à intercepter et de modifier les en- têtes HTTP sans que vous puissiez le contrôler (par exemple: Origin, Cookies, etc.). De plus, ce que HTTP / 2 est capable de pousser est envoyé au navigateur. Cela signifie que JS ne sait pas toujours (voire jamais) que les choses sont poussées. Encore une fois, cela a du sens pour index.csset index.jsparce que le navigateur le mettra en cache, mais pas tant pour les paquets de données.

C'est vraiment tout dans le nom. HTTP signifie HyperText Transfer Protocol. Nous sommes axés sur le concept de transfert d'actifs. WebSocket consiste à créer une connexion socket où les données binaires sont transmises bidirectionnellement.

Celui dont nous ne discutons pas vraiment est SSE (Server-Sent Events). Pousser des données vers l'application (JS) n'est pas l'intention de HTTP / 2, mais c'est pour SSE. SSE est vraiment renforcé avec HTTP / 2. Mais ce n'est pas un véritable remplacement pour WebSockets lorsque ce qui est important, ce sont les données elles-mêmes, pas les points de terminaison variables atteints. Pour chaque noeud final avec WebSocket, un nouveau flux de données est créé, mais avec SSE, il est partagé entre la session HTTP / 2 déjà existante.

Voici les objectifs de chacun:

• HTTP - Répondre à une demande avec un élément
• HTTP / 2 - Répondre à une demande avec plusieurs actifs
• SSE - Répondre avec un flux d'événements de texte unidirectionnel (UTF-8)
• WebSocket - Créer un flux de données binaires bidirectionnel

Il y aura une implémentation WebSocket dans HTTP / 2. https://tools.ietf.org/html/rfc8441

Pour le moment, avril 2020, HTTP / 2 ne rend pas les WebSockets obsolètes. Le plus grand avantage de WebSockets sur HTTP2 est que

HTTP/2 works only on Browser Level not Application Level

Signifie que HTTP / 2 n'offre aucune API JS comme WebSockets pour permettre la communication et transférer une sorte de JSON ou d'autres données vers le serveur directement depuis l'Application (par exemple le site Web). Donc, pour autant que je le pense, HTTP / 2 ne rendra WebSockets obsolète que s'il commence à proposer des API comme WebSockets pour parler au serveur. Jusqu'à ce qu'il soit juste une version mise à jour et plus rapide de HTTP 1.1.