Pourquoi utiliser AJAX lorsque WebSockets est disponible?
J'utilise WebSockets depuis un certain temps et j'ai choisi de créer un outil de gestion de projet Agile pour mon projet de dernière année à l'université, à l'aide du serveur Node et des WebSockets. J'ai constaté que l'utilisation de WebSockets fournissait une augmentation de 624% du nombre de requêtes par seconde que ma demande pouvait traiter.
Cependant, depuis le début du projet, j'ai lu des failles dans la sécurité et certains navigateurs ont choisi de désactiver WebSockets par défaut.
Cela m'amène à la question:
Pourquoi utiliser AJAX lorsque WebSockets semble faire un travail remarquable en réduisant la latence et la surcharge des ressources, y a-t-il quelque chose que AJAX fait mieux que WebSockets?
WebSockets n'est pas destiné à remplacer AJAX et n'est même pas strictement le remplacement de Comet/long-poll (bien que cela soit logique dans de nombreux cas).
WebSockets a pour objet de fournir une connexion bidirectionnelle, en duplex intégral et longue durée entre un navigateur et un serveur. WebSockets ouvre de nouveaux domaines d'applications aux navigateurs qui n'étaient pas vraiment possibles avec HTTP et AJAX (jeux interactifs, flux multimédias dynamiques, pontage vers les protocoles réseau existants, etc.).
Cependant, il y a certainement un chevauchement des objectifs entre WebSockets et AJAX/Comet. Par exemple, lorsque le navigateur souhaite être averti des événements du serveur (par exemple, Push), les techniques Comet et WebSockets sont certainement des options viables. Si votre application a besoin d'événements Push à faible temps de latence, cela serait un facteur favorable à WebSockets. D'un autre côté, si vous devez coexister avec des infrastructures existantes et des technologies déployées (OAuth, API RESTful, proxy, équilibreurs de charge), alors ce serait un facteur favorable aux techniques Comet (pour le moment).
Si vous n'avez pas besoin des avantages spécifiques offerts par WebSockets, il est probablement préférable de vous en tenir aux techniques existantes telles que AJAX et Comet, car cela vous permet de réutiliser et d'intégrer un vaste écosystème existant de outils, technologies, mécanismes de sécurité, bases de connaissances (beaucoup plus de personnes connaissant HTTP/Ajax/Comet que WebSockets), etc., etc.
D'autre part, si vous créez une nouvelle application qui ne fonctionne tout simplement pas dans les contraintes de latence et de connexion de HTTP/Ajax/Comet, 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 simplement de le diffuser un peu. Bien qu'iOS (iPhone, iPad) prenne encore 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 utilisateurs Web. De même, si vous utilisez Node pour le serveur, envisagez d’utiliser Socket.IO , qui inclut Web-socket-js en tant que solution de secours et même si cette option n’est pas disponible (ou désactivé), il utilisera ensuite la technique Comet disponible pour le navigateur donné.
Mise à jour : iOS 6 prend désormais en charge le standard actuel HyBi/IETF 6455.
Avance rapide jusqu'en décembre 2017, Les Websockets sont supportés par (pratiquement) tous les navigateurs et leur utilisation est très courante.
Toutefois, cela ne signifie pas que Websockets a réussi à remplacer AJAX, du moins pas complètement, d'autant plus que l'adaptation HTTP/2 est à la hausse.
La réponse courte est que AJAX est toujours idéal pour la plupart des applications REST, même si vous utilisez Websockets. Mais dieu est dans les détails, alors ...:
AJAX pour le vote?
L'utilisation de AJAX pour l'interrogation (ou l'interrogation longue) est en train de disparaître (et ce devrait être le cas), mais il reste toujours utilisé pour deux bonnes raisons (principalement pour les applications Web plus petites ):
Pour de nombreux développeurs, AJAX est plus facile à coder, en particulier lorsqu'il s'agit de coder et de concevoir le backend.
Avec HTTP/2, le coût le plus élevé lié à AJAX (établissement d'une nouvelle connexion) a été éliminé, ce qui permet aux appels AJAX d'être assez performants, notamment 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.). Ceci a été discuté plusieurs fois.
AJAX pour le repos?
Une meilleure utilisation de AJAX est REST appels d'API. Cette utilisation simplifie la base de code et empêche le blocage de la connexion Websocket (en particulier pour les téléchargements de données de taille moyenne).
Il y a un certain nombre de raisons impérieuses de préférer AJAX pour REST appels d'API et le téléchargement de données:
L'API AJAX a été pratiquement conçue pour les appels d'API REST. C'est un choix idéal.
Les appels et les envois REST à l'aide de AJAX sont nettement plus faciles à coder, à la fois sur le client et sur le serveur.
À mesure que la charge de données augmente, les connexions Websocket peuvent être bloquées sauf si la logique de fragmentation/multiplexage des messages est codée.
Si un téléchargement est effectué dans un seul appel Websocket
send, il peut bloquer un flux Websocket jusqu'à la fin du téléchargement. Cela réduira les performances, en particulier sur les clients les plus lents.
Une conception commune utilise de petits messages bidirectionnels transférés sur Websockets tandis que REST et les téléchargements de données (client à serveur) exploitent la facilité d'utilisation d'AJAX pour empêcher le blocage de Websocket.
Cependant, sur les projets plus importants, la flexibilité offerte par Websockets et l’équilibre entre complexité du code et gestion des ressources feront pencher la balance en faveur de Websockets.
Par exemple, les téléchargements basés sur Websocket pourraient offrir la possibilité de reprendre des téléchargements volumineux une fois la connexion établie et rétablie (rappelez-vous que le film de 5 Go que vous souhaitez télécharger?).
En codant la logique de fragmentation du téléchargement, il est facile de reprendre un téléchargement interrompu (le plus difficile était de coder le contenu).
Qu'en est-il de HTTP/2 push?
Je devrais probablement ajouter que la fonctionnalité HTTP/2 Push ne remplace pas (et ne peut probablement pas) remplacer Websockets.
Cela avait été discuté ici auparavant, mais il suffit de mentionner qu'une seule connexion HTTP/2 sert à l'ensemble du navigateur (tous les onglets/fenêtres), de sorte que les données envoyées par HTTP/2 ne savent pas lequel onglet/fenêtre auquel il appartient, éliminant ainsi sa capacité à remplacer la capacité de Websocket à transmettre des données directement à un onglet/fenêtre de navigateur spécifique.
Alors que les Websockets sont parfaits pour la communication de données bidirectionnelle de petite taille, AJAX comportait encore un certain nombre d'avantages, en particulier pour les charges utiles plus importantes (uploads, etc.).
Et la sécurité?
En règle générale, plus un programmeur a confiance et est contrôlé, plus l'outil est puissant ... et plus les problèmes de sécurité augmentent.
AJAX aurait naturellement l'avantage, car sa sécurité est intégrée au code du navigateur (ce qui est parfois discutable, mais il est toujours là).
D'autre part, les appels AJAX sont plus susceptibles d'attaques de type "homme du milieu", tandis que les problèmes de sécurité de Websockets sont généralement des bogues dans le code de l'application qui introduit une faille de sécurité (généralement, la logique Je les trouverai).
Personnellement, je ne trouve pas que cela soit une si grande différence, si tout ce que je pense, Websockets est légèrement mieux loti, surtout quand vous savez ce que vous faites.
Mon humble avis
IMHO, j'utiliserais Websockets pour tout sauf les appels d'API REST. Big data uploads je fragmenter et envoyer sur Websockets lorsque cela est possible.
Les sondages, à mon humble avis, devraient être interdits, le coût du trafic réseau est horrible et Websocket Push est assez facile à gérer, même pour les nouveaux développeurs.
Outre les problèmes rencontrés avec les anciens navigateurs (notamment IE9, WebSockets étant pris en charge à partir de IE10), il existe encore de gros problèmes avec les intermédiaires réseau ne prenant pas encore en charge WebSockets, notamment les proxys transparents, les proxys inversés 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 prises en charge, mais entre-temps, vous devriez toujours avoir une méthode de secours basée sur HTTP pour l'envoi de données aux navigateurs.
La plupart des plaintes que j'ai lues au sujet des sockets Web et de la sécurité proviennent des fournisseurs de sécurité des 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 la mise à niveau de HTTP au protocole binaire websocket effectuée, 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 les moyens de subsistance reposent sur l’analyse et la classification de tout votre trafic Internet. :)
Les WebSockets ne fonctionnent pas dans les navigateurs Web plus anciens 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 entre Websockets et HTTP car ils ne sont pas des rivaux ni ne résolvent les mêmes problèmes.
Les Websockets sont un excellent choix pour gérer en temps quasi réel la transmission en continu de données en continu bidirectionnelles, alors que REST est idéal pour les communications occasionnelles. L'utilisation de websockets représente un investissement considérable et constitue donc une surcapacité pour les connexions occasionnelles.
Vous constaterez peut-être que Websockets fait mieux en présence de charges élevées. HTTP est légèrement plus rapide dans certains cas, car il peut utiliser la mise en cache. Comparer REST à Websockets revient à comparer des pommes à des oranges.
Nous devrions vérifier quelle solution offre la meilleure solution pour notre application, laquelle convient le mieux à notre cas d'utilisation.
Exemple des différences entre HTTP et Websockets sous la forme d'une bibliothèque de taille client pouvant gérer un noeud final Websocket tel que REST API et des noeuds finaux RESTful comme Websockets sur le client. https://github.com/mikedeshazer/sockrest De même, pour ceux qui essaient de consommer une API websocket sur le client ou inversement, de la manière dont ils sont habitués. Le libs/sockrest.js montre assez clairement les différences (ou est supposé le faire).