Les sockets Web rendent-ils obsax / CORS?

Les sockets Web utilisés dans tous les navigateurs Web rendront-ils obsax le ajax?

Si je pouvais utiliser des sockets Web pour récupérer des données et mettre à jour des données en temps réel, pourquoi aurais-je besoin d’ajax? Même si j’utilise ajax pour simplement récupérer des données une fois au démarrage de l’application, il se peut que je veuille toujours voir si ces données ont changé après un certain temps.

Et les sockets Web seront-ils possibles dans les domaines croisés ou uniquement avec la même origine?

WebSockets ne rendra pas AJAX entièrement obsolète et WebSocket pourra le faire entre plusieurs domaines.

AJAX

Les mécanismes AJAX peuvent être utilisés avec des serveurs Web simples. Au niveau le plus élémentaire, AJAX est juste un moyen pour une page Web de faire une requête HTTP. WebSockets est un protocole de niveau beaucoup plus bas et nécessite un serveur WebSockets (intégré au serveur Web, autonome ou envoyé par proxy depuis le serveur Web vers un serveur autonome).

Avec WebSockets, le cadrage et la charge utile sont déterminés par l’application. Vous pouvez envoyer du HTML / XML / JSON entre le client et le serveur, mais vous n’êtes pas obligé de le faire. AJAX est HTTP . WebSockets a une prise en charge conviviale HTTP, mais WebSockets n’est pas HTTP . WebSockets est un protocole bidirectionnel plus proche des sockets raw (intentionnellement) que du protocole HTTP. Les données utiles WebSockets sont codées en UTF-8 dans la version actuelle du standard, mais elles seront probablement modifiées / étendues dans les futures versions.

Il y aura donc toujours une place pour les requêtes de type AJAX même dans un monde où tous les clients supportent nativement WebSockets. WebSockets essaie de résoudre des situations où AJAX n’est pas capable ou marginalement capable (parce que WebSockets a une surcharge bidirectionnelle et beaucoup plus faible). Mais WebSockets ne remplace pas tout ce qui est utilisé par AJAX.

Domaine croisé

Oui , WebSockets prend en charge les domaines croisés. La prise de contact initiale pour configurer la connexion communique les informations de politique d’origine. La page wikipedia montre un exemple de poignée de main typique: http://en.wikipedia.org/wiki/WebSockets

Je vais essayer de décomposer ceci en questions:

Les sockets Web utilisés dans tous les navigateurs Web rendront-ils obsax le ajax?

Absolument pas. WebSockets sont des connexions socket brutes au serveur. Cela vient avec ses propres problèmes de sécurité . Les appels AJAX sont simplement asynchrones. Les requêtes HTTP pouvant suivre les mêmes procédures de validation que le rest des pages.

Si je pouvais utiliser des sockets Web pour récupérer des données et mettre à jour des données en temps réel, pourquoi aurais-je besoin d’ajax?

Vous utiliseriez AJAX pour des tâches plus faciles à gérer. Tout le monde ne veut pas avoir à sécuriser une connexion socket pour autoriser simplement les requêtes asynchrones. Cela peut être traité assez simplement.

Même si j’utilise ajax pour simplement récupérer des données une fois au démarrage de l’application, il se peut que je veuille toujours voir si ces données ont changé après un certain temps.

Bien sûr, si ces données changent . Vous ne pouvez pas avoir les données changeantes ou constamment rafraîchissantes. Encore une fois, il s’agit d’ une surcharge de code dont vous devez tenir compte.

Et les sockets Web seront-ils possibles dans les domaines croisés ou uniquement avec la même origine?

Vous pouvez avoir des WebSockets interdomaines mais vous devez coder votre serveur WS pour les accepter. Vous avez access à l’en-tête de domaine (hôte) que vous pouvez ensuite utiliser pour accepter / refuser des demandes. Cela peut cependant être falsifié par quelque chose d’aussi simple que nc . Afin de sécuriser réellement la connexion, vous devrez authentifier la connexion par d’autres moyens.

Les Websockets ont quelques gros inconvénients en termes d’évolutivité que ajax évite. Comme ajax envoie une requête / réponse et ferme la connexion (ou peu de temps après) si quelqu’un rest sur la page Web, il n’utilise pas les ressources du serveur lorsqu’il est inactif. Les Websockets sont destinés à renvoyer des données au navigateur, et ils associent les ressources du serveur pour ce faire. Le nombre de connexions simultanées que les serveurs peuvent garder ouvertes simultanément est limité. Sans parler de la technologie côté serveur, ils peuvent attacher un thread pour gérer le socket. Les websockets ont donc besoin de plus de ressources pour les deux côtés par connexion. Vous pourriez facilement épuiser tous vos threads desservant les clients et puis aucun nouveau client ne pourrait venir si beaucoup d’utilisateurs sont juste assis sur la page. C’est là que nodejs, vertx, netty peuvent vraiment aider, mais même ceux-ci ont également des limites.

Il y a aussi la question de l’état de la socket sous-jacente, et l’écriture du code des deux côtés qui mènent la conversation avec état, ce qui n’est pas quelque chose que vous avez à faire avec le style ajax parce qu’il est sans état. Les Websockets vous obligent à créer un protocole de bas niveau qui est résolu pour vous avec ajax. Des choses comme le battement de cœur, la fermeture de connexions inactives, la reconnexion sur des erreurs, etc. sont désormais d’une importance capitale. Ce sont des choses que vous n’avez pas à résoudre lorsque vous utilisez AJAX, car il était sans état. L’état est très important pour la stabilité de votre application et surtout pour la santé de votre serveur. Ce n’est pas sortingvial. Pré-HTTP nous avons construit beaucoup de protocoles TCP avec état (FTP, telnet, SSH), puis HTTP est arrivé. Et personne ne le faisait beaucoup plus car même avec ses limitations, HTTP était étonnamment plus facile et plus robuste. Les Websockets ramènent les bons et les mauvais des protocoles avec état. Vous apprendrez assez tôt si vous n’avez pas reçu une dose de ce dernier.

Si vous avez besoin de streaming de données en temps réel, cette surcharge est justifiée car l’interrogation du serveur pour obtenir des données diffusées est pire, mais si vous ne faites qu’interaction utilisateur-> request-> response-> update UI, ajax est plus facile et utilisera moins de ressources, car une fois la réponse envoyée, la conversation est terminée et aucune ressource serveur supplémentaire n’est utilisée. Donc, je pense que c’est un compromis et l’architecte doit décider quel outil correspond à leur problème. AJAX a sa place et les websockets ont leur place.

Mettre à jour

Donc, l’architecture de votre serveur est ce qui compte quand on parle de threads. Si vous utilisez un serveur (ou des processus) traditionnellement multi-thread, où chaque connexion de socket reçoit son propre thread pour répondre aux requêtes, alors les Websockets comptent pour vous. Donc, pour chaque connexion, nous avons un socket, et éventuellement le système d’exploitation tombera si vous en avez trop, et il en va de même pour les threads (plus encore pour les processus). Les threads sont plus lourds que les sockets (en termes de ressources). Nous essayons donc de conserver le nombre de threads exécutés simultanément. Cela signifie qu’il faut créer un pool de threads qui ne soit qu’un nombre fixe de threads partagés par tous les sockets. Mais une fois qu’une socket est ouverte, le thread est utilisé pour toute la conversation. La durée de ces conversations détermine la rapidité avec laquelle vous pouvez réutiliser ces threads pour les nouveaux sockets entrant. La durée de votre conversation détermine le volume que vous pouvez adapter. Cependant, si vous diffusez en streaming, ce modèle ne fonctionne pas bien pour la mise à l’échelle. Vous devez briser le design du thread / socket.

Le modèle de demande / réponse de HTTP le rend très efficace pour retourner les threads pour les nouveaux sockets. Si vous voulez juste utiliser la requête / réponse, utilisez HTTP déjà construit et beaucoup plus facile que de réimplémenter quelque chose comme ça dans les websockets.

Étant donné que les websockets ne doivent pas nécessairement être des requêtes / réponses en tant que HTTP et peuvent diffuser des données si votre serveur dispose d’un nombre fixe de threads dans son pool de threads et que vous avez le même nombre de threads avec des conversations actives, vous pouvez Ne rendez pas de nouveaux clients! Vous avez atteint votre capacité maximale. C’est là que la conception de protocole est également importante avec les Websockets et les threads. Votre protocole peut vous permettre de desserrer le thread par socket par modèle de conversation de manière à ce que les personnes qui sont juste assis là n’utilisent pas de thread sur votre serveur.

C’est là qu’interviennent les serveurs asynchrones à thread unique. En Java, nous appelons souvent ce NIO pour les IO non bloquants. Cela signifie que c’est une API différente pour les sockets où l’envoi et la réception de données ne bloquent pas le thread effectuant l’appel.

Si le blocage des sockets est traditionnel lorsque vous appelez socket.read () ou socket.write (), ils attendent que les données soient reçues ou envoyées avant de redonner le contrôle à votre programme. Cela signifie que votre programme est bloqué en attendant que les données du socket entrent ou sortent jusqu’à ce que vous puissiez faire autre chose. C’est pourquoi nous avons des threads afin que nous puissions travailler simultanément (en même temps). Envoyez ces données au client X pendant que j’attends les données du client Y. Les devises sont le nom du jeu lorsque nous parlons de serveurs.

Dans un serveur NIO, nous utilisons un seul thread pour gérer tous les clients et enregistrer les rappels pour être averti lorsque des données arrivent. Par exemple

 socket.read( function( data ) { // data is here! Now you can process it very quickly without waiting! }); 

L’appel à socket.read () retournera immédiatement sans lire aucune donnée, mais notre fonction que nous vous avons fournie sera appelée dès son entrée. Cette conception modifie radicalement la manière dont vous construisez et architectez votre code, car si vous êtes suspendu, vous pouvez attendre Je ne reçois aucun nouveau client. Vous avez un fil unique, vous ne pouvez pas vraiment faire deux choses à la fois! Vous devez garder ce fil en mouvement.

NIO, Asynchronous IO, Event based program est un système beaucoup plus compliqué, et je ne vous suggérerais pas d’essayer de l’écrire si vous commencez. Même les programmeurs très expérimentés trouvent très difficile de construire des systèmes robustes. Puisque vous êtes asynchrone, vous ne pouvez pas appeler les API qui bloquent. Tout comme la lecture des données du DB ou l’envoi de messages à d’autres serveurs doivent être effectués de manière asynchrone. Même la lecture / écriture à partir du système de fichiers peut ralentir votre thread unique en réduisant votre évolutivité. Une fois que vous êtes en mode asynchrone, tout est asynchrone si vous souhaitez que le seul thread continue à bouger. C’est là que cela devient difficile car, éventuellement, vous rencontrerez une API, comme les bases de données, qui n’est pas asynchrone et vous devez adopter plus de threads à un certain niveau. Donc, une approche hybride est commune même dans le monde asynchrone.

La bonne nouvelle est qu’il existe d’autres solutions utilisant cette API de niveau inférieur que vous pouvez utiliser. NodeJS, Vertx, Netty, Apache Mina, Framework de jeu, Python tordu, Python Stackless, etc. Il pourrait y avoir une bibliothèque obscure pour C ++, mais honnêtement je ne m’en ferais pas. La technologie de serveur ne requirejs pas les langages les plus rapides, car elle est plus liée à IO qu’à un processeur. Si vous êtes un vrai casse-tête, utilisez Java. Il a une énorme communauté de code à tirer et sa vitesse est très proche (et parfois meilleure) de C ++. Si vous le détestez, optez pour Node ou Python.

Oui oui :RÉ

Les réponses précédentes manquent d’imagination. Je ne vois plus de raison d’utiliser AJAX si les websockets sont à votre disposition.