Les sockets Web rendent ajax / CORS obsolète?
Les sockets Web, lorsqu'ils sont utilisés dans tous les navigateurs Web, rendront-ils ajax obsolète?
Parce que si je pouvais utiliser des sockets Web pour récupérer des données et les mettre à jour en temps réel, pourquoi aurais-je besoin d'ajax? Même si j'utilise ajax pour extraire les données une seule fois lorsque l'application a démarré, je voudrais quand même voir si ces données ont changé après un certain temps.
Et les sockets web seront-ils possibles dans plusieurs domaines ou uniquement pour la même origine?
WebSockets ne rendra pas AJAX entièrement obsolète et les WebSockets peuvent faire plusieurs domaines.
AJAX
Les mécanismes AJAX peuvent être utilisés avec des serveurs Web simples. À son 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 (soit intégré au serveur Web, autonome) , ou 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 dans les deux sens entre le client et le serveur, mais vous n'êtes pas obligé de le faire. AJAX est HTTP . WebSockets a une poignée de main conviviale HTTP, mais WebSockets n'est pas HTTP . WebSockets est un protocole bidirectionnel qui est plus proche des sockets bruts (intentionnellement) que de HTTP. Les données de charge utile WebSockets sont encodées en UTF-8 dans la version actuelle de la norme, mais cela est susceptible d'être modifié/étendu dans les versions futures.
Il y aura donc probablement toujours une place pour les demandes de type AJAX même dans un monde où tous les clients prennent en charge WebSockets nativement. WebSockets essaie de résoudre les situations où AJAX est pas capable ou marginalement capable (parce que WebSockets sa surcharge bidirectionnelle et beaucoup plus faible.) Mais WebSockets ne remplace pas tout AJAX est utilisé pour.
Cross-domaine
Oui , WebSockets prend en charge plusieurs domaines. 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 cela en questions:
Les sockets Web, lorsqu'ils sont utilisés dans tous les navigateurs Web, rendront-ils ajax obsolète?
Absolument pas. Les WebSockets sont des connexions de socket brutes au serveur. Cela vient avec ce sont ses propres problèmes de sécurité . AJAX les appels sont simplement asynchrones. Les requêtes HTTP peuvent suivre les mêmes procédures de validation que le reste des pages.
Parce que si je pouvais utiliser des sockets Web pour récupérer des données et les mettre à jour en temps réel, pourquoi aurais-je besoin d'ajax?
Vous utiliseriez AJAX pour des tâches plus simples et plus faciles à gérer. Tout le monde ne veut pas avoir la surcharge de sécuriser une connexion socket pour autoriser simplement les demandes asynchrones. Cela peut être géré assez simplement.
Même si j'utilise ajax pour extraire les données une seule fois lorsque l'application a démarré, je voudrais quand même voir si ces données ont changé après un certain temps.
Bien sûr, si ces données changent . Il est possible que les données ne changent pas ou ne soient pas constamment actualisées. Encore une fois, c'est la surcharge de code dont vous devez tenir compte.
Et les sockets web seront-ils possibles dans plusieurs domaines ou uniquement pour la même origine?
Vous pouvez avoir des WebSockets interdomaines mais vous devez coder votre serveur WS pour les accepter. Vous avez accès à l'en-tête de domaine (hôte) que vous pouvez ensuite utiliser pour accepter/refuser les demandes. Cependant, cela peut être usurpé par quelque chose d'aussi simple que nc. Afin de vraiment sécuriser la connexion, vous devrez authentifier la connexion par d'autres moyens.
Les Websockets ont quelques gros inconvénients en termes d'évolutivité qu'ajax évite. Depuis ajax envoie une demande/réponse et ferme la connexion (.. ou peu de temps après) si quelqu'un reste sur la page Web, il n'utilise pas les ressources du serveur lors de la marche au ralenti. Les Websockets sont destinés à renvoyer des données vers le navigateur, et ils bloquent les ressources du serveur pour ce faire. Les serveurs ont une limite dans le nombre de connexions simultanées qu'ils peuvent garder ouvertes en même temps. Sans parler de la technologie de votre serveur, ils peuvent bloquer un fil pour gérer le socket. Les connexions Web ont donc des besoins en ressources plus importants des deux côtés par connexion. Vous pouvez facilement épuiser tous vos threads desservant les clients, puis aucun nouveau client ne peut entrer si de nombreux utilisateurs sont simplement assis sur la page. C'est là que nodejs, vertx, netty peuvent vraiment aider, mais même ceux-ci ont également des limites supérieures.
Il y a aussi la question de l'état de la socket sous-jacente et de l'écriture du code des deux côtés qui poursuit la conversation avec état, ce qui n'est pas quelque chose que vous avez à faire avec le style ajax car il est sans état. Les Websockets nécessitent que vous créiez un protocole de bas niveau qui est résolu pour vous avec ajax. Des choses comme les battements de cœur, la fermeture des connexions inactives, la reconnexion en cas d'erreur, etc. sont maintenant d'une importance vitale. Ce sont des choses que vous n'avez pas eu à résoudre en utilisant 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 trivial. Avant HTTP, nous avons construit beaucoup de protocoles TCP TCP (FTP, telnet, SSH), puis HTTP est arrivé. Et personne ne faisait plus ce genre de choses car même avec ses limites, HTTP était étonnamment plus facile et plus robuste. Les Websockets ramènent le bon et le 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 diffuser des données en temps réel, cette surcharge supplémentaire est justifiée car l'interrogation du serveur pour obtenir des données en streaming est pire, mais si tout ce que vous faites est une interaction utilisateur-> demande-> réponse-> mettre à jour l'interface utilisateur, 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. Je pense donc 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.
Mise à jour
L'architecture de votre serveur est donc ce qui compte lorsque nous parlons de threads. Si vous utilisez un serveur (ou processus) multi-threads traditionnel où chaque connexion socket obtient son propre thread pour répondre aux demandes, alors les websockets comptent beaucoup pour vous. Donc, pour chaque connexion, nous avons un socket, et finalement 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 que nous exécutons simultanément. Cela signifie créer un pool de threads qui n'est qu'un nombre fixe de threads partagé entre toutes les sockets. Mais une fois le socket ouvert, le thread est utilisé pour toute la conversation. La durée de ces conversations détermine la rapidité avec laquelle vous pouvez réaffecter ces threads pour les nouvelles sockets entrant. La longueur de votre conversation détermine le montant que vous pouvez mettre à l'échelle. Cependant, si vous diffusez en continu ce modèle ne fonctionne pas bien pour la mise à l'échelle. Vous devez casser la conception filetage/douille.
Le modèle de requête/réponse de HTTP le rend très efficace pour retourner des threads pour de nouvelles sockets. Si vous allez simplement utiliser la requête/réponse, utilisez HTTP, c'est 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 être des requêtes/réponses en HTTP et peuvent diffuser des données si votre serveur a un nombre fixe de threads dans son pool de threads et que vous avez le même nombre de websockets liant tous vos threads avec des conversations actives, vous pouvez 't service de nouveaux clients qui arrivent! Vous avez atteint votre capacité maximale. C'est là que la conception du 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 façon à ce que les gens 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 des E/S non bloquantes. 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 effectuer l'appel.
Si traditionnels dans le blocage des sockets lorsque vous appelez socket.read () ou socket.write (), ils attendent que les données soient reçues ou envoyées avant de retourner 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. Concurrencies est 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 les 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 de données, mais notre fonction que nous avons fournie sera appelée quand elle entrera. Cette conception change radicalement la façon dont vous construisez et architecturez votre code parce que si vous êtes raccroché en attendant quelque chose, vous pouvez 'recevoir aucun nouveau client. Vous avez un seul fil, vous ne pouvez pas vraiment faire deux choses à la fois! Vous devez garder ce fil en mouvement.
NIO, Asynchronous IO, programme basé sur des événements, comme cela est connu sous le nom de, est une conception de système beaucoup plus compliquée, et je ne vous suggérerais pas d'essayer de l'écrire si vous commencez. Même les programmeurs très seniors 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 de la base de données 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, ce qui réduit votre évolutivité. Une fois que vous devenez asynchrone, tout est asynchrone tout le temps si vous voulez garder le thread unique en mouvement. C'est là que cela devient difficile, car vous finirez par exécuter une API, comme les bases de données, qui n'est pas asynchrone et vous devez adopter plus de threads à un certain niveau. Les approches hybrides sont donc courantes même dans le monde asynchrone.
La bonne nouvelle est qu'il existe d'autres solutions qui utilisent cette API de niveau inférieur déjà construite que vous pouvez utiliser. NodeJS, Vertx, Netty, Apache Mina, Play Framework, Twisted Python, Stackless Python, etc. Il pourrait y avoir une bibliothèque obscure pour C++, mais honnêtement, je ne m'embêterais pas. La technologie serveur ne nécessite pas les langages les plus rapides car elle est IO liée plus que liée au processeur. Si vous êtes un écrou de performance, utilisez Java. Il a une énorme communauté de code à extraire et sa vitesse est très proche (et parfois meilleure) que C++. Si vous détestez simplement, allez avec Node ou Python.