Pourquoi utiliser AJAX lorsque WebSockets est disponible?


203

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?


2
Voici une liste de moteurs qui prennent en charge les sockets Web. en.wikipedia.org/wiki/…
Dante

Réponses:


209

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.


37
Et maintenant, à l'aube de 2014, WebSockets est pratiquement un standard (RFC 6455) et seul Opera mini ne le prend pas en charge.
Dirk Bester

4
Certes, Opera Mini ne le prend pas en charge, mais le plus embarrassant est le manque de prise en charge du navigateur Android qui le rend un peu plus complexe à utiliser avec les applications basées sur la visualisation Web (Cordova PhoneGap)
Miles M.

2
@kanaka, si les deux font aussi bien les gros fichiers, alors pourquoi ne pas tout envoyer via les websockets? Pourquoi s'embêter à ajuster des pages / données alors que tout peut être envoyé via WebSockets? (Supposons que ce soit déjà 2020 et que tous les navigateurs prennent en charge les WebSockets)
Pacerier

3
@Pacerier une réponse complète serait longue, mais cela se résume essentiellement au fait que vous essayez de réimplémenter des choses que le navigateur fait déjà bien (mise en cache, sécurité, parallélisme, gestion des erreurs, etc.). En ce qui concerne les performances, bien que la vitesse de transfert de gros fichiers bruts à partir de zéro soit similaire, les navigateurs ont eu des années pour affiner la mise en cache du contenu Web (dont une grande partie s'applique aux demandes AJAX), donc en pratique, le passage d'AJAX à WebSockets ne fournira probablement pas beaucoup bénéficier de fonctionnalités existantes. Mais pour la communication bidirectionnelle à faible latence, c'est une énorme victoire.
kanaka

5
Je suis désolé mais pour moi ça ne répond pas à la question. Il dit simplement qu'ils ne sont pas censés se remplacer et que WS n'est pas entièrement pris en charge (il l'est maintenant). Cela ne répond pas pourquoi vous préférez AJAX à WebSocket? Prenons l'exemple de Discord. Discord utilise WS pour pousser les messages et les événements du serveur vers les clients, tandis qu'il utilise les requêtes HTTP du client vers le serveur (envoyer un message, demander des données, etc.). Je suis venu à cette question pour obtenir une réponse pourquoi vous le feriez. Y a-t-il une sorte de raison technique pour laquelle vous mettriez AJAX au-dessus de la connexion WS ouverte?
Charlotte Dunois

63

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.


2
Petite erreur de grammaire 'si quelque chose que je pense ...' pense 😀
spottedmahn

2
@spottedmahn - Merci! Je suppose que c'est ce qui se passe J'utilise mon éditeur de code pour rédiger du texte
Myst

1
Toutes mes excuses, j'étais absent à l'expiration de la prime. Mauvaise planification de ma part. J'ai fixé une autre prime que je vous accorderai après l'expiration des 23 heures.
Duncan Jones

@Myst merci pour cette excellente explication. Que préférez-vous pour les notifications en direct comme fb / stackoverflow? Je conçois un service Web RestFull pour mon application Web, mais très confus, que dois-je utiliser pour la fonction de notification? AJAX ou WebSockets?
TheCoder

Les notifications @puspen sont (à mon humble avis) un excellent choix pour les Websockets. Il y a beaucoup de décisions à prendre lorsque vous concevez une logique de reconnexion et des files d'attente de notification hors ligne, mais la notification réelle est à la fois facile à coder et performante avec les websockets.
Myst

18

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.


Heureusement, la plupart des frameworks WebSocket prennent en charge ces solutions de rechange, y compris l'utilisation de Flash pour les sockets. Socketn.IO et SignalR sont tous deux des cadres décents ... bien que vous soyez vraiment limité, comme vous le mentionnez à cause des proxys et des équilibreurs de charge. Heureusement, Node.JS et le prochain IIS font également un travail décent avec ce rôle.
Tracker1

Curieux: quels transporteurs bloquent WebSocket sur le port 80? Quel bloc WebSocket sécurisé (WSS) sur le port 443? Ce dernier implique des proxys Web MITM forcés et transparents. Jamais vu cela dans les réseaux publics (uniquement les entreprises), car il nécessite l'installation de nouveaux certificats CA dans les navigateurs.
oberstet

Par exemple, pour le moment, Vodafone Italie bloque WS sur le port 80, mais autorise WSS sur le port 443. Vous pouvez tester n'importe quel opérateur assez facilement via notre page d'accueil, à laquelle vous pouvez accéder à la fois en HTTP et en HTTPS. Il essaie les WebSockets et retombe sur HTTP s'ils sont bloqués. Utilisez cette URL pour afficher un widget au milieu qui signale le transport actuel: lightstreamer.com/?s
Alessandro Alinone

17

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. :)


11

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.


8
Une meilleure raison est qu'une demande AJAX est une demande HTTP normale, ce qui signifie qu'elle peut récupérer des ressources HTTP; WebSockets ne peut pas faire ça.
Dan D.

@Dan Que se passe-t-il si, par exemple, des fichiers image sont envoyés en base64, CSS en tant que texte, JavaScript également en tant que texte, puis ajoutés au document? Serait-ce plausible?
Jack

@DanD. +1, je suis d'accord, je suppose que j'abordais la question plus dans le contexte de la diffusion rapide de données comme dans l'exemple de la question, mais c'est certainement correct.
jli

@Dan D - parfois, vous ne voulez pas que toutes ces conneries dépassent la ligne, comme les cookies et les en-têtes ...
vsync

8
@DanD., HTTP et WebSocket sont deux protocoles distincts, bien sûr, nous ne pouvons pas demander des ressources HTTP en utilisant le protocole WebSocket pour la même raison que nous ne pouvons pas demander des ressources WebSocket en utilisant le protocole HTTP! Cela ne signifie pas que le client ne peut pas demander des fichiers html et / ou image envoyés via le protocole Websocket.
Pacerier

2

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.


1
la question concernait AJAX en général, pas REST en particulier. Il est vrai que AJAX peut être utilisé pour REST, mais il est également utilisé pour l'interrogation et l'interrogation longue. Bien que je sois d'accord avec votre conclusion (comme vous pouvez le voir dans ma réponse), je pense que votre réponse pourrait refléter la distinction (notez que les Websockets peuvent également être utilisés pour REST, mais pas en utilisant des méthodes HTTP).
Myst

@Myst, je suis d'accord avec vous.
Gaurav Gandhi

1

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

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.