Pourquoi utiliser AJAX lorsque WebSockets est disponible?

J'utilise WebSockets depuis un certain temps maintenant, j'ai choisi de créer un outil de gestion de projet Agile pour mon projet de dernière année à l'Université en utilisant le serveur Node et WebSockets. J'ai trouvé que l'utilisation de WebSockets permettait une augmentation de 624% du nombre de demandes par seconde que ma demande pouvait traiter.

Cependant, depuis le démarrage du projet, j'ai lu des failles de sécurité et certains navigateurs choisissant de désactiver WebSockets par défaut.

Cela m'amène à la question:

Pourquoi utiliser AJAX alors que WebSockets semble faire un si bon travail de réduction de la latence et de la surcharge des ressources, AJAX fait-il mieux que WebSockets?

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

Le but de WebSockets est de fournir une connexion à faible latence, bidirectionnelle, duplex intégral et de longue durée entre un navigateur et un serveur. WebSockets ouvre de nouveaux domaines d'application aux applications de navigation qui n'étaient pas vraiment possibles à l'aide de HTTP et AJAX (jeux interactifs, flux multimédias dynamiques, passerelles aux protocoles réseau existants, etc.).

Cependant, il y a certainement un chevauchement d'objectif entre WebSockets et AJAX / Comet. Par exemple, lorsque le navigateur souhaite être informé des événements du serveur (c'est-à-dire push), les techniques Comet et WebSockets sont certainement des options viables. Si votre application a besoin d'événements push à faible latence, ce serait un facteur en faveur de WebSockets. D'un autre côté, si vous avez besoin de coexister avec les frameworks existants et les technologies déployées (OAuth, API RESTful, proxys, équilibreurs de charge), alors ce serait un facteur en faveur des techniques Comet (pour l'instant).

Si vous n'avez pas besoin des avantages spécifiques fournis par 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 vaste écosystème d'outils, de technologies et de mécanismes de sécurité existants. , des bases de connaissances (c.-à-d. beaucoup plus de personnes sur stackoverflow connaissent HTTP / Ajax / Comet que WebSockets), etc.

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

En outre, certaines réponses indiquent que l'un des inconvénients de WebSockets est la prise en charge limitée / mixte du serveur et du navigateur. Permettez-moi de diffuser cela un peu. Alors qu'iOS (iPhone, iPad) prend toujours en charge l'ancien protocole (Hixie), la plupart des serveurs WebSockets prennent en charge Hixie et la version HyBi / IETF 6455 . La plupart des autres plates-formes (si elles ne disposent pas déjà d'un support intégré) peuvent obtenir un support WebSockets via web-socket-js (polyfill basé sur Flash). Cela couvre la grande majorité des internautes. De plus, si vous utilisez Node pour le serveur principal, envisagez d'utiliser Socket.IO qui inclut web-socket-js comme solution de repli et si même cela n'est pas disponible (ou désactivé), il reviendra à utiliser la technique Comet disponible pour le navigateur donné.

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

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.

Cependant, cela ne signifie pas que Websockets a réussi à remplacer AJAX, du moins pas complètement, d'autant que l'adaptation HTTP / 2 est en augmentation.

La réponse courte est que AJAX est toujours idéal pour la plupart des applications REST, même lors de l'utilisation de Websockets. Mais Dieu est dans les détails, alors ...:

AJAX pour le sondage?

L'utilisation d'AJAX pour l'interrogation (ou l'interrogation longue) est en train de disparaître (et elle devrait l'être), mais elle reste utilisée pour deux bonnes raisons (principalement pour les petites applications Web):

1. Pour de nombreux développeurs, AJAX est plus facile à coder, en particulier 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é, permettant aux appels AJAX d'être assez performants, en particulier pour la publication et le téléchargement de données.

Cependant, Websocket push est de loin supérieur à AJAX (pas besoin de ré-authentifier ou de renvoyer les en-têtes, pas besoin d'aller-retour «pas de données», etc.). Cela a été discuté à plusieurs reprises.

AJAX pour REST?

Une meilleure utilisation d'AJAX est les appels d'API REST. Cette utilisation simplifie la base de code et empêche la connexion Websocket de se bloquer (en particulier lors de téléchargements de données de taille moyenne).

Il existe un certain nombre de raisons impérieuses de préférer AJAX pour les 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 c'est un excellent ajustement.

2. Les appels et les téléchargements REST utilisant AJAX sont beaucoup plus faciles à coder, à la fois sur le client et sur le backend.

3. À mesure que la charge utile des données augmente, les connexions Websocket peuvent être bloquées à moins que la logique de fragmentation / multiplexage des messages ne soit codée.

   Si un téléchargement est effectué dans un seul sendappel Websocket , il peut bloquer un flux Websocket jusqu'à la fin du téléchargement. Cela réduira les performances, en particulier sur les clients plus lents.

Une conception courante utilise de petits messages bidirectionnels transférés sur les Websockets tandis que le REST et les téléchargements de données (client vers serveur) tirent parti de la facilité d'utilisation d'AJAX pour empêcher le Websocket de se bloquer.

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 soit interrompue et rétablie (rappelez-vous que le 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 difficile était de coder la chose).

Qu'en est-il du HTTP / 2 push?

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

Cela avait déjà été discuté ici auparavant, mais il suffit de mentionner qu'une seule connexion HTTP / 2 dessert l'ensemble du navigateur (tous les onglets / fenêtres), donc les données poussées par HTTP / 2 ne savent pas à quel onglet / fenêtre il appartient, éliminant sa capacité à remplacer la capacité de Websocket à envoyer des données directement vers un onglet / une fenêtre de navigateur spécifique.

Alors que les Websockets sont parfaits pour les petites communications de données bidirectionnelles, AJAX comportait toujours un certain nombre d'avantages - en particulier lorsque l'on considère des charges utiles plus importantes (téléchargements, etc.).

Et la sécurité?

Eh bien, en général, plus un programmeur bénéficie de la confiance et du contrôle, plus l'outil est puissant ... et plus les problèmes de sécurité augmentent.

AJAX, par nature, aurait le dessus, car sa sécurité est intégrée au code du navigateur (ce qui est parfois discutable, mais il est toujours là).

D'un autre côté, les appels AJAX sont plus sensibles aux attaques de type "homme au milieu", tandis que les problèmes de sécurité Websockets sont généralement des bogues dans le code d'application qui ont introduit une faille de sécurité (généralement la logique d'authentification principale est l'endroit où vous les trouverez).

Personnellement, je ne trouve pas que ce soit une si grande différence, si je pense que les Websockets sont un peu mieux, surtout quand vous savez ce que vous faites.

Mon humble avis

À mon humble avis, j'utiliserais des Websockets pour tout sauf les appels d'API REST. Importations de données volumineuses Je fragmenterais et enverrais par Websockets lorsque cela est possible.

L'interrogation, à mon humble avis, devrait être interdite, le coût du trafic réseau est horrible et Websocket push est assez facile à gérer même pour les nouveaux développeurs.

En plus des problèmes avec les navigateurs plus anciens (y compris IE9, car les WebSockets seront pris en charge à partir d'IE10), il y a encore de gros problèmes avec les intermédiaires réseau ne prenant pas encore en charge les WebSockets, y compris les proxys transparents, les proxys inverses et les équilibreurs de charge. Certains opérateurs mobiles bloquent complètement le trafic WebSocket (c'est-à-dire après la commande HTTP UPGRADE).

Au fil des années, les WebSockets seront de plus en plus pris en charge, mais en attendant, vous devriez toujours avoir une méthode de secours basée sur HTTP pour envoyer des données aux navigateurs.

La plupart des plaintes que j'ai lues sur les sockets Web et la sécurité proviennent de fournisseurs de sécurité d'outils de sécurité de navigateur Web et de pare-feu. Le problème est qu'ils ne savent pas comment analyser la sécurité du trafic websockets, car une fois qu'il a effectué la mise à niveau de HTTP vers le protocole binaire websocket, le contenu du paquet et sa signification sont spécifiques à l'application (en fonction de 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. :)

Les WebSockets ne fonctionnent pas dans les anciens navigateurs Web, et ceux qui le prennent en charge ont souvent des implémentations différentes. C'est à peu près la seule bonne raison pour laquelle ils ne sont pas utilisés tout le temps à la place d'AJAX.

Je ne pense pas que nous puissions faire une comparaison claire des Websockets et HTTP car ils ne sont pas des rivaux et ne résolvent pas les mêmes problèmes.

Les Websockets sont un excellent choix pour gérer le streaming de données bidirectionnelles à longue durée de vie en temps quasi réel, tandis que REST est idéal pour les communications occasionnelles. L'utilisation de websockets est un investissement considérable, c'est donc une surpuissance pour les connexions occasionnelles.

Vous pouvez constater que les Websockets fonctionnent mieux en cas de charges élevées, HTTP est légèrement plus rapide dans certains cas car il peut utiliser la mise en cache. Comparer REST avec Websockets, c'est comme comparer des pommes à des oranges.

Nous devons vérifier laquelle offre la meilleure solution pour notre application, laquelle correspond le mieux à nos cas d'utilisation.

Un exemple des différences entre HTTP et Websockets sous la forme d'une bibliothèque de taille client qui peut gérer le point de terminaison Websocket comme les API REST et les points de terminaison RESTful comme les Websockets sur le client. https://github.com/mikedeshazer/sockrest Aussi, pour ceux qui essaient de consommer une API websocket sur le client ou vice versa comme ils sont habitués. Le fichier libs / sockrest.js montre clairement les différences (ou plutôt est censé le faire).