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


268

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?


Je pense que la réponse acceptée est correcte, les Websockets sont toujours la solution préférée pour que les applications Web communiquent avec le serveur de manière bidirectionnelle, y compris les messages poussés par le serveur. HTTP est utilisé pour plus que des navigateurs et lorsque le client et le serveur peuvent utiliser une API de bas niveau, ils n'ont pas besoin de websockets. La plupart des gens utilisent encore HTTP pour les applications Web et se préoccupent surtout des API exposées à JavaScript. Si les modérateurs pensent que la réponse acceptée devrait être différente, je ne m'y oppose pas car cette question génère apparemment beaucoup de points de vue et mon opinion pourrait être fausse.
vbezhenar

Réponses:


162

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.


3
Merci Guillaume pour ta réponse. Cependant, je me demande si vous (ou quelqu'un) pourriez ajouter une référence à partir de la spécification HTTP / 2. Ce que j'ai lu sur les blogs et ainsi de suite - avec HTTP / 2, il y a une vraie communication bidirectionnelle?
Martin Meeser

3
Je ne suis pas sûr que la spécification HTTP / 2 soit le bon endroit pour donner des détails sur les origines de HTTP / 2 et en quoi il diffère de websocket. Cependant, vous pouvez facilement voir qu'avec HTTP / 2 nous utilisons une communication bidirectionnelle: goo.gl/IJVxWS (page 6 et 13)
Guillaume D.

27
HTTP / 2 est en effet bidirectionnel mais pas symétrique, ce qui signifie que seul le client peut envoyer une demande appropriée et le serveur peut envoyer des réponses et demander des promesses (push). Cela rend les websockets différentes dans le sens où les deux parties sont plus "égales" en termes de ce qu'elles sont autorisées à envoyer / recevoir.
George Antoniadis du

3
Il existe un excellent podcast sur la Software Engineering Radio de l'IEEE sur les origines de HTTP2. Je pense que c'est ça: se-radio.net/2015/07/episode-232-mark-nottingham-on-http2
Max Murphy

2
une réponse similaire avec une justification complète peut être trouvée dans cet article InfoQ ici: infoq.com/articles/websocket-and-http2-coexist
mantrid

153

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


21
Cette réponse est partiellement en désaccord avec les autres, y compris celle acceptée, et c'est aussi la meilleure réponse car elle est basée sur des sources directes.
sudo

7
Je suis entièrement d'accord avec cette réponse et le commentaire. HTTP / 2 est bidirectionnel streambased.
Martin Meeser

3
Réponse réellement correcte, le gars a pris la peine de vérifier les sources et l'application du monde réel (grpc)
Vladimir Akopyan

1
Dans les websockets, le serveur ne peut pas commencer à envoyer des octets arbitraires tant que le client n'a pas initié une demande de mise à niveau du websocket, mais il peut alors pousser à tout moment. Dans HTTP / 2, le serveur ne peut pas commencer à pousser des octets jusqu'à ce que le client lance une connexion de données, mais il peut alors pousser des octets à tout moment. Quelle est la différence fonctionnelle? Comme je l'ai souligné, la capacité PUSH_PROMISE est un hareng rouge. Ce n'est pas la raison pour laquelle HTTP / 2 remplace les sockets Web. Il ne s'agit que d'une optimisation mineure des performances. Cela n'a rien à voir avec le cœur de HTTP / 2, qui est le streaming bidi.
Masonk

1
Cette réponse est tout simplement fausse. Cela confond tellement d'aspects que c'est facilement déroutant. Cependant, le nœud du problème est que les flux HTTP / 2 "bidi" sont pilotés par les réponses aux demandes (et en nombre limité), tandis que le protocole WebSockets est un véritable protocole bidi basé sur les messages (il n'est pas basé sur les réponses aux requêtes, sauf pour la phase de prise de contact). Il s'agit d'une énorme différence qui ne peut pas être corrigée simplement en lisant mal la spécification (comme @masonk semble l'avoir fait involontairement).
Myst

65

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.


4
Les sockets WS ne resteront pas ouvertes pour toujours non plus. Les différences sont les flux; HTTP / 2 vous fournit plusieurs flux de flux, ce qui signifie que le contrôle de flux sur le serveur est très différent et souvent sans verrouillage. WS (en tant que protocole) doit avoir un traitement entrant non réglementé. Le contrôle de flux est implémenté plus haut dans la pile. Pour la sécurité et l'intégrité du serveur, HTTP / 2 est bien meilleur que WS.
lien

4
@bond, je conviens que HTTP / 2 présente de nombreux avantages en tant que couche de transport (le partage d'une seule connexion sur de nombreux onglets de navigateur n'est qu'un exemple). Cependant, il n'est pas conçu comme une couche de communication . C'est une question fonctionnelle. Les deux protocoles répondent à des besoins différents. c'est-à-dire que la mise en place d'un sshterminal sur le navigateur est un jeu d'enfant lors de l'utilisation de Websockets. Ce serait un casse-tête total sur HTTP / 2, surtout si plus d'un onglet est ouvert. Et si le navigateur (ou l'un des proxys HTTP / 2) fermait la connexion? Le client peut-il simplement supposer qu'aucune nouvelle donnée n'est disponible? nous sommes de retour au scrutin.
Myst

1
Le navigateur peut tout aussi bien fermer votre connexion WS. C'est la vie avec tout type de réseautage. Pour être honnête, le multiplexage dans HTTP / 2 est exagéré. Le protocole n'en avait vraiment pas besoin. Avec l'ouverture de plusieurs flux, vous commencez à rencontrer des problèmes avec les tampons TCP limitant le débit. Je suis d'accord avec vous que WS est meilleur dans ce qu'il fait que HTTP / 2. Fondamentalement, WS est quelque chose qui a besoin de beaucoup de contrôles de niveau supérieur pour empêcher les utilisateurs de faire de mauvaises choses.
lien

2
Pour citer l'oncle Ben (Spider-Man): "Souvenez-vous, avec une grande puissance vient une grande responsabilité". Oui, @bond, tu as très raison. Les Websockets, étant un protocole très "brut", nécessitent une conception de serveur plus responsable. Et oui, WS peut être fermé aussi facilement que HTTP / 2, mais WS prend en charge le oncloserappel, donc aucune interrogation n'est nécessaire. Quant au multiplexage, je pense que c'était une nécessité plutôt qu'un choix. keep-alivea échoué et le seul moyen d'éviter le hit de performance "premier en ligne" était de risquer le multiplexage. Le temps nous le dira :)
Myst

1
Du point de vue de la conception du serveur, le multiplexage sortant est un problème compliqué et coûteux. Cela nécessite que les mécaniciens d'E / S interrogent en interne, ce qui coûte très cher. À moins que vous ne diffusiez des documents volumineux, le multiplexage ne fonctionnera même pas, car la demande aura probablement répondu et mis en mémoire tampon entièrement en interne avant même que le second ne soit disponible et le multiplexage ne fonctionnera pas. RTMP a un multiplexage sortant, mais seul le serveur d'Adobe le fait. Il est étonnant de voir à quel point HTTP / 2 est proche de RTMP.
lien

40

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


C'est incroyable! Existe-t-il un exemple public d'un client Javascript qui a implémenté cela? Je ne trouve aucun exemple. Que devrais-je faire? Est-ce une bonne ressource? Undertow.io/blog/2015/04/27/An-in-depth-overview-of-HTTP2.html
RaisinBranCrunch

Quelqu'un connaît-il une source des revendications ci-dessus concernant 1) la recherche de la longueur de l'en-tête, 2) le bas de la casse des noms de champ?
Pim Heijden

@PimHeijden pour détecter la longueur d'en-tête dans HTTP / 1.x nécessite de parcourir tous les octets à la recherche du marqueur de fin de 4 octets. C'est très cher. La non-casse des noms de champ signifie également que toute correspondance de champ doit être effectuée pour les versions majuscules et minuscules des caractères. Cela nécessite une connaissance de l'ensemble du jeu de caractères en majuscules et minuscules pour les vérifications. Dans 2.x, vous pouvez supposer qu'ils sont en minuscules.
lien

@RaisinBranCrunch Vous ne pouvez pas contrôler tout cela à partir de Javascript. Le navigateur fait tout pour vous.
lien

@bond J'utilise actuellement HTTP / 2 avec Nginx et proxy_pass pour envoyer des connexions Websocket à un serveur de socket, mais lorsque j'ai un seul utilisateur ouvert plusieurs onglets sur le site Web, le serveur de socket le traite comme plusieurs connexions. Je suppose que si HTTP / 2 multiplexe des connexions sur un canal TCP, le serveur le traiterait comme une seule connexion. Est-ce mal? Existe-t-il un moyen de vérifier que le serveur n'effectue pas de connexions inutiles supplémentaires?
RaisinBranCrunch

23

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.


5

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 .


3

À 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

SSE sur HTTP / 2 souffre-t-il de la même limitation que sur HTTP1.1: un nombre limité de connexions actives par domaine? (la limitation est dans les navigateurs Web, environ 5 connexions simultanées au même nom d'hôte de serveur, donc si vous avez 3 connexions SSE du client à votre my-server.com, vous ne disposez que de 2 connexions pour les requêtes HTTP régulières vers le même my-server.com).
Paul-Sebastian Manole il y a

2

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


Non, il n'y en aura pas ... la connexion WebSocket sera tunnelée via HTTP / 2, mais HTTP / 2 ne remplacera pas le protocole, ni ne deviendra obsolète.
Myst

@Myst J'ai dit ça?
Dzintars

2
Non, vous ne l'avez pas dit, je l'ai fait. Vous avez écrit qu'il y aura une implémentation de WebSocket dans HTTP / 2, que mon humble avis semblait trop court et quelque peu trompeur en raison de l'omission de détails importants.
Myst

2

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.