Pourquoi utiliser AJAX alors que WebSockets est disponible ?

Question

J'utilise les WebSockets depuis un certain temps maintenant, j'ai choisi de créer un outil de gestion de projet Agile pour mon projet de fin d'études à l'université en utilisant le serveur Node et les WebSockets. J'ai constaté que l'utilisation des WebSockets a permis d'augmenter de 624 % le nombre de demandes par seconde que mon application pouvait traiter.

Cependant, depuis le début du projet, j'ai lu des informations sur les failles de sécurité, et certains navigateurs ont choisi de désactiver les WebSockets par défaut

Cela m'amène à la question suivante :

Pourquoi utiliser AJAX alors que WebSockets semble faire un si bon travail en réduisant la latence et l'encombrement des ressources, y a-t-il quelque chose qu'AJAX fait mieux que WebSockets ?

Answer 1

WebSockets n'est pas destiné à remplacer AJAX et n'est même pas strictement un remplacement de Comet/long-poll (bien qu'il y ait de nombreux cas où cela a du sens).

L'objectif des WebSockets est de fournir une connexion à faible latence, bidirectionnelle, full-duplex et longue durée entre un navigateur et un serveur. Les WebSockets ouvrent aux applications de navigateur de nouveaux domaines d'application qui n'étaient pas vraiment possibles avec HTTP et AJAX (jeux interactifs, flux de médias dynamiques, passerelles vers les protocoles de réseau existants, etc.)

Cependant, il y a certainement un chevauchement d'objectifs entre les WebSockets et AJAX/Comet. Par exemple, lorsque le navigateur veut être informé des événements du serveur (c.-à-d. push), les techniques Comet et WebSockets sont certainement deux options viables. Si votre application a besoin d'événements push à faible latence, ce facteur plaide en faveur des WebSockets. D'autre part, si vous devez coexister avec des cadres existants et des technologies déployées (OAuth, API RESTful, proxies, équilibreurs de charge), les techniques Comet seront privilégiées (pour l'instant).

Si vous n'avez pas besoin des avantages spécifiques qu'offrent les WebSockets, il est probablement préférable de s'en tenir aux techniques existantes comme AJAX et Comet, car cela vous permet de réutiliser et d'intégrer un énorme écosystème existant d'outils, de technologies, de mécanismes de sécurité, de bases de connaissances (c'est-à-dire que beaucoup plus de personnes sur stackoverflow connaissent HTTP/Ajax/Comet que WebSockets), etc.

D'autre part, si vous créez une nouvelle application qui ne fonctionne pas bien avec les contraintes de latence et de connexion de HTTP/Ajax/Comet, envisagez d'utiliser les WebSockets.

Par ailleurs, certaines réponses indiquent que l'un des inconvénients des WebSockets est le support limité/mixte du serveur et du navigateur. Permettez-moi d'éclaircir un peu ce point. Alors que iOS (iPhone, iPad) supporte toujours l'ancien protocole (Hixie), la plupart des serveurs WebSockets supportent à la fois Hixie et le protocole HyBi/. IETF 6455 version. La plupart des autres plates-formes (si elles n'ont pas déjà un support intégré) peuvent obtenir un support WebSockets via web-socket-js (polyfill basé sur Flash). Cela couvre la grande majorité des utilisateurs du web. De plus, si vous utilisez Node pour le serveur dorsal, envisagez d'utiliser le module Socket.IO qui inclut web-socket-js comme solution de repli et si même cela n'est pas disponible (ou désactivé), il se rabattra sur la technique Comet disponible pour le navigateur donné.

Mise à jour iOS 6 prend désormais en charge la norme actuelle HyBi/IETF 6455.

Answer 2

Avance rapide jusqu'en décembre 2017, Les websockets sont pris en charge par (pratiquement) tous les navigateurs. et leur utilisation est très courante.

Toutefois, cela ne signifie pas que les Websockets ont réussi à remplacer AJAX, du moins pas complètement, d'autant plus que l'adaptation à HTTP/2 est en plein essor.

La réponse courte est qu'AJAX est toujours excellent pour la plupart des applications REST, même en utilisant les Websockets. Mais tout est dans les détails, alors... :

AJAX pour les sondages ?

L'utilisation d'AJAX pour les sondages (ou les longs sondages) est en train de disparaître. (et il devrait l'être), mais il reste encore utilisé pour deux bonnes raisons (principalement pour les petites applications web) :

1. Pour de nombreux développeurs, AJAX est plus facile à coder, surtout lorsqu'il s'agit de coder et de concevoir le backend.

2. Avec HTTP/2, le coût le plus élevé lié à AJAX (l'établissement d'une nouvelle connexion) a été éliminé, ce qui permet aux appels AJAX d'être assez performants, notamment pour l'affichage et le téléchargement de données.

Cependant, La poussée par websocket est de loin supérieure à AJAX (pas besoin de se réauthentifier ou de renvoyer les en-têtes, pas besoin d'aller-retour "sans données", etc'). Ce site a été discuté à plusieurs reprises.

AJAX pour REST ?

Les appels d'API REST constituent une meilleure utilisation d'AJAX. Cette utilisation simplifie la base de code et empêche la connexion Websocket de se bloquer (notamment pour les téléchargements de données de taille moyenne).

Il existe un certain nombre de des raisons convaincantes de préférer AJAX aux appels d'API REST et les téléchargements de données :

1. L'API AJAX a été pratiquement conçue pour les appels d'API REST et elle est parfaitement adaptée.

2. Les appels REST et les téléchargements utilisant AJAX sont nettement plus faciles à coder, tant sur le client que sur le backend.

3. Lorsque la charge utile des données augmente, les connexions Websocket peuvent se bloquer, à moins que la logique de fragmentation et de multiplexage des messages ne soit codée.

   Si un téléchargement est effectué dans une seule Websocket send il pourrait bloquer un flux Websocket jusqu'à ce que le téléchargement soit terminé. Cela réduit les performances, notamment sur les clients les plus lents.

Une conception courante utilise de petits messages bidi transférés sur des Websockets, tandis que REST et les téléchargements de données (client à serveur) tirent parti de la facilité d'utilisation d'AJAX pour éviter le blocage du Websocket.

Cependant, sur des projets plus importants, la flexibilité offerte par les Websockets et l'équilibre entre la complexité du code et la gestion des ressources feront pencher la balance en faveur des Websockets.

Par exemple, les téléchargements basés sur Websocket pourraient offrir la possibilité de reprendre des téléchargements volumineux après qu'une connexion a été interrompue et rétablie (vous vous souvenez de ce film de 5 Go que vous vouliez télécharger ?)

En codant la logique de fragmentation du téléchargement, il est facile de reprendre un téléchargement interrompu (la partie la plus difficile était de coder la chose).

Qu'en est-il de la poussée HTTP/2 ?

Je devrais probablement ajouter que la fonction "push" de HTTP/2 ne remplace pas (et ne peut probablement pas remplacer) les Websockets.

Cela a été discuté ici mais il suffit de mentionner qu'une seule connexion HTTP/2 sert l'ensemble du navigateur (tous les onglets/fenêtres). Les données poussées par HTTP/2 ne savent donc pas à quel onglet/fenêtre elles appartiennent, ce qui élimine sa capacité à remplacer la capacité de Websocket à pousser des données directement vers un onglet/fenêtre spécifique du navigateur.

Si les Websockets sont parfaits pour les petites communications de données bidirectionnelles, AJAX présente encore un certain nombre d'avantages, surtout lorsqu'il s'agit de charges utiles plus importantes (téléchargements, etc.).

Et la sécurité ?

Eh bien, en général, plus la confiance et le contrôle sont offerts à un programmeur, plus l'outil est puissant... et plus les problèmes de sécurité se multiplient.

Par nature, AJAX aurait le dessus, puisque la sécurité est intégrée au code du navigateur (ce qui est parfois discutable, mais c'est toujours le cas).

D'autre part, les appels AJAX sont plus sensibles aux attaques de type "man in the middle", tandis que les problèmes de sécurité des Websockets sont généralement des bogues dans le code de l'application qui ont introduit une faille de sécurité (c'est généralement dans la logique d'authentification dorsale que vous les trouverez).

Personnellement, je ne trouve pas qu'il y ait une si grande différence, je pense même que les Websockets sont légèrement mieux lotis, surtout quand on sait ce que l'on fait.

Mon humble avis

À mon avis, j'utiliserais les Websockets pour tout sauf les appels d'API REST. Je fragmenterais les téléchargements de données volumineuses et les enverrais par Websockets lorsque c'est possible.

Les sondages, à mon avis, devraient être interdits, le coût en trafic réseau est horrible et le push Websocket est assez facile à gérer, même pour les nouveaux développeurs.

Answer 3

Outre les problèmes liés aux anciens navigateurs (y compris IE9, car les WebSockets seront pris en charge à partir d'IE10), de gros problèmes subsistent avec les intermédiaires de réseau qui ne prennent pas encore en charge les WebSockets, notamment les proxys transparents, les reverse proxys et les équilibreurs de charge. Certains opérateurs mobiles bloquent complètement le trafic WebSocket (c'est-à-dire après la commande HTTP UPGRADE).

Avec les années, les WebSockets seront de plus en plus prises en charge, mais en attendant, vous devez toujours disposer d'une méthode de repli basée sur HTTP pour envoyer des données aux navigateurs.

Answer 4

La plupart des plaintes que j'ai lues au sujet des websockets et de la sécurité proviennent de vendeurs d'outils de sécurité pour les navigateurs web et les pare-feu. Le problème est qu'ils ne savent pas comment analyser la sécurité du trafic des websockets, parce qu'une fois la mise à niveau de HTTP vers le protocole binaire websocket effectuée, le contenu du paquet et sa signification sont spécifiques à l'application (basés sur ce que vous programmez). C'est évidemment un cauchemar logistique pour ces entreprises dont le gagne-pain est basé sur l'analyse et la classification de tout votre trafic internet. :)

Answer 5

Les WebSockets ne fonctionnent pas dans les anciens navigateurs web, et ceux qui le soutiennent ont souvent des mises en œuvre différentes. C'est à peu près la seule bonne raison pour laquelle ils ne sont pas utilisés systématiquement à la place d'AJAX.