Quel est l'inconvénient d'utiliser websocket/socket.io là où ajax fera l'affaire?
Des questions similaires ont déjà été posées et toutes ont abouti à la conclusion que AJAX ne deviendrait pas obsolète. Mais en quoi ajax est-il meilleur que les websockets?
Avec socket.io, il est facile de revenir à une interrogation rapide ou longue, la compatibilité du navigateur ne semble donc pas être un problème.
Les Websockets sont bidirectionnels. Lorsque ajax effectuerait une demande asynchrone, le client Websocket enverrait un message au serveur. Les paramètres POST/GET peuvent être codés en JSON.
Alors, quel est le problème avec l'utilisation de 100% websockets? Si chaque visiteur maintient une connexion Websocket persistante au serveur, est-ce que ce serait plus une perte de temps que de faire quelques requêtes ajax tout au long de la session de visite?
Je pense que ce serait plus de gaspillage. Pour chaque client connecté, vous avez besoin d'une sorte d'objet/fonction/code/quel que soit le serveur jumelé avec ce client. Un gestionnaire de socket, un descripteur de fichier ou votre serveur est configuré pour gérer les connexions.
Avec AJAX, vous n'avez pas besoin de mapper 1: 1 des ressources côté serveur sur le client. Votre nombre de clients peut évoluer de manière moins dépendante que vos ressources côté serveur. Même node.js a ses limites quant au nombre de connexions qu’il peut gérer et garder ouvertes.
L'autre chose à considérer est que certaines réponses AJAX peuvent également être mises en cache. Au fur et à mesure de votre évolution, vous pouvez ajouter un cache HTTP afin de réduire la charge liée aux demandes fréquentes AJAX.
Réponse courte
Maintenir un websocket actif a un coût, à la fois pour le client et le serveur, si Ajax n’aura un coût qu’une seule fois, en fonction de ce que vous en ferez.
Longue réponse
Les Websockets sont souvent mal compris à cause de cet ensemble "Hey, utilise Ajax, ça ira!". Non, les Websockets ne remplacent pas Ajax. Ils peuvent potentiellement être appliqués aux mêmes champs, mais il y a des cas où l'utilisation de Websocket est absurde.
Prenons un exemple simple: une page dynamique qui charge des données après le chargement de la page côté client. C'est simple, faites un appel Ajax. Nous n'avons besoin que d'une direction, du serveur au client. Le client demandera ces données, le serveur les enverra au client, c'est fait. Pourquoi voudriez-vous implémenter websockets pour une telle tâche? Vous n'avez pas besoin que votre connexion soit ouverte tout le temps, vous n'avez pas besoin du client pour demander constamment au serveur, vous n'avez pas besoin du serveur pour informer le client. La connexion restera ouverte, elle gaspillera des ressources, car pour garder une connexion ouverte, vous devez la vérifier en permanence.
Maintenant, pour une application de chat, les choses sont totalement différentes. Vous devez que votre client soit averti par le serveur au lieu de le forcer à demander au serveur toutes les x secondes ou millisecondes si quelque chose est nouveau. Cela n'aurait aucun sens.
Pour mieux comprendre, voyez cela comme deux personnes. L'un des deux est le serveur, le plus est le client. Ajax est comme envoyer une lettre. Le client envoie une lettre, le serveur répond avec une autre lettre. Le fait est que, pour une application de chat, la conversation serait la suivante:
"Hey Server, tu as quelque chose pour moi?
- Non.
- Salut Serveur, tu as quelque chose pour moi?
- Non.
- Salut Serveur, tu as quelque chose pour moi?
- Oui c'est ici."
Le serveur ne peut pas réellement envoyer une lettre au client, si le client n'a jamais demandé de réponse. C'est un énorme gaspillage de ressources. Parce que pour chaque demande Ajax, même si elle est mise en cache, vous devez effectuer une opération côté serveur.
Maintenant, le cas que j'ai discuté plus tôt avec les données chargées avec Ajax. Imaginez que le client est au téléphone avec le serveur. Garder la connexion active a un coût. Cela coûte de l'électricité et vous devez payer votre opérateur. Maintenant, pourquoi auriez-vous besoin d'appeler quelqu'un et de le garder au téléphone pendant une heure, si vous voulez juste que cette personne vous dise 3 mots? Envoyez une putain de lettre.
_ {En conclusion, les Websockets ne remplacent pas totalement Ajax!} _
Parfois, vous aurez besoin Ajax, où l'utilisation de Websocket est absurde.
Édition: l'affaire SSE)
Cette technologie n’est pas très largement utilisée, mais elle peut être utile. Comme son nom l'indique, les événements envoyés par le serveur sont un Push unidirectionnel du serveur vers le client. Le client ne demande rien, le serveur envoie simplement les données.
En bref :
- Unidirectionnel à partir du client: Ajax
- Unidirectionnel à partir du serveur: SSE
- Bidirectionnel: Websockets
Personnellement, je pense que les Websockets seront de plus en plus utilisés dans les applications Web au lieu d’AJAX. Ils ne sont pas bien adaptés aux sites Web où la mise en cache et le référencement Web sont une préoccupation majeure, mais ils feront des merveilles pour les applications Web.
Des projets tels que DNode et socketstream aident à éliminer la complexité et permettent un codage simple de style RPC. Cela signifie que votre code client appelle simplement une fonction sur le serveur, en transmettant toutes les données à cette fonction. Et le serveur peut appeler une fonction sur le client et lui transmettre également des données. Vous n'avez pas besoin de vous préoccuper des dernières technologies de TCP.
De plus, il y a beaucoup de temps système avec les appels AJAX. Par exemple, une connexion doit être établie et des en-têtes HTTP (cookies, etc.) sont transmis à chaque demande. Les Websockets éliminent une grande partie de cela. Certains disent que les Websockets sont plus de gaspillage, et ils ont peut-être raison. Mais je ne suis pas convaincu que la différence soit vraiment si importante.
J'ai répondu à une autre question connexe en détail, y compris de nombreux liens vers des ressources connexes. Vous pourriez le vérifier:
Je pense que, tôt ou tard, les frameworks basés sur Websocket vont commencer à apparaître non seulement pour écrire des discussions en temps réel, comme des éléments d'applications Web, mais également comme des frameworks Web autonomes. Une fois la connexion permanente créée, elle peut être utilisée pour recevoir toutes sortes de contenus, y compris des parties d'interface utilisateur d'une application Web, qui sont désormais desservies, par exemple, par le biais de AJAX requêtes. Cette approche peut nuire au référencement d'une manière ou d'une autre, bien qu'elle puisse réduire la quantité de trafic et la charge générée par les requêtes asynchrones, notamment les en-têtes HTTP redondants.
Cependant, je doute que les Websockets remplacent ou mettent en danger AJAX, car il existe de nombreux scénarios dans lesquels les connexions permanentes sont inutiles ou indésirables. Par exemple, les applications composites qui utilisent (une fois) un seul objectif REST ne nécessitent pas de connexion permanente avec les clients.
Il n'y a rien de "faux" à ce sujet.
La seule différence est principalement la lisibilité. Le principal avantage d'Ajax est qu'il vous permet un développement rapide car la plupart des fonctionnalités sont écrites pour vous.
Le fait de ne pas avoir à réinventer la roue à chaque fois que vous souhaitez ouvrir une prise présente un grand avantage.
Les connexions WS: // ont beaucoup moins de temps système que les demandes "AJAX".
Si vous voulez que la connexion au serveur soit ouverte et si la scrutation continue vers le serveur sera là, optez pour des sockets, sinon vous pouvez utiliser ajax.
Analogie simple: Ajax pose des questions (requêtes) au serveur et le serveur donne des réponses (réponses) à ces questions. Maintenant, si vous voulez poser des questions continues, ajax ne fonctionnera pas, il aura une surcharge importante qui nécessitera des ressources aux deux extrémités.
Comme d'autres personnes l'ont dit, le maintien de la connexion ouverte peut s'avérer excessif dans certains cas où vous n'avez pas besoin de notifications serveur à client, ou lorsque la demande client à serveur se produit avec une faible fréquence.
Mais un autre inconvénient est que Websockets est un protocole de bas niveau, n'offrant pas de fonctionnalités supplémentaires à TCP une fois la prise de contact initiale effectuée. Ainsi, lorsque vous implémenterez un paradigme requête-réponse sur des websockets, vous manquerez probablement de fonctionnalités proposées par HTTP (une famille de protocoles très mature et étendue) , comme la mise en cache (caches client et partagé), la validation (requêtes conditionnelles), sécurité et idempotence (avec conséquences sur le comportement de l'agent), demandes de plage, types de contenu, codes d'état, ...
En d’autres termes, vous réduisez la taille des messages à un coût.
Donc, mon choix est AJAX pour la demande-réponse, les websockets pour le transfert du serveur et la messagerie haute fréquence et basse latence