prises Web font ajax / CORS obsolète?

Question

Will prises Web lorsqu'ils sont utilisés dans tous les navigateurs web font ajax obsolète?

Parce que si je pouvais utiliser les sockets Web pour extraire des données et des données de mise à jour en temps réel, pourquoi aurais-je besoin ajax? Même si j'utilise ajax juste récupérer les données une fois que lorsque l'application a commencé, je pourrais encore vouloir voir si ces données a changé après un certain temps.

et que vous prises web soient possibles dans des domaines transversaux ou seulement à la même origine?

Answer 1

WebSockets ne fera pas AJAX entièrement obsolète et WebSockets peut faire interdomaine.

AJAX

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 pour faire une requête HTTP. WebSockets est un protocole de niveau beaucoup plus faible et nécessite un serveur WebSockets (soit intégré dans le serveur web, autonome ou proxy du serveur Web à un serveur autonome).

Avec WebSockets, le cadrage et la charge utile est déterminée par l'application. Vous pouvez envoyer HTML / XML Retour / JSON-et-vient entre le client et le serveur, mais vous n'êtes pas obligé de. AJAX est HTTP . WebSockets a une poignée de main amicale HTTP, mais WebSockets n'est pas HTTP . WebSockets est un protocole bidirectionnel qui est plus proche de sockets bruts (intentionnellement) que de HTTP. Les données de charge utile de WebSockets est UTF-8 codé dans la version actuelle de la norme, mais cela est susceptible d'être modifié / étendu dans les versions futures.

Donc il y aura 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 tente de résoudre des situations où AJAX ne sont pas en mesure ou peu capable (parce WebSockets ses frais généraux bidirectionnel et beaucoup plus bas). Mais WebSockets ne remplace pas tout AJAX est utilisé pour.

Cross-Domain

Oui cross-domain , Websockets supports. La poignée de main initiale pour configurer la connexion communique des informations sur les politiques d'origine. La page wikipedia montre un exemple d'une poignée de main typique: http://en.wikipedia.org/wiki/WebSockets

Answer 2

Je vais essayer de le décomposer en questions:

  

Will prises Web lorsqu'ils sont utilisés dans tous les navigateurs web font ajax obsolète?

Absolument pas. WebSockets sont des connexions socket premières vers le serveur. Cela vient avec il ses propres problèmes de sécurité . appels AJAX sont tout simplement async. les requêtes HTTP qui peuvent suivre les mêmes procédures de validation que le reste des pages.

  

Parce que si je pouvais utiliser les sockets Web pour extraire des données et des données de mise à jour en temps réel, pourquoi aurais-je besoin ajax?

Vous devez utiliser AJAX pour des tâches plus simples plus faciles à gérer. Pas tout le monde veut avoir les frais généraux d'assurer une connexion de socket pour permettre simplement async demandes. Cela peut être manipulé assez simplement.

  

Même si j'utilise ajax juste récupérer les données une fois que lorsque l'application a commencé, je pourrais encore vouloir voir si ces données a changé après un certain temps.

Bien sûr, si ces données change . Vous ne pouvez pas avoir les données ou changer constamment rafraîchissant. Encore une fois, cela est Code surcharge que vous devez compte.

  

et que vous prises web soient possibles dans des domaines transversaux ou seulement à la même origine?

Vous pouvez avoir plusieurs domaines WebSockets mais vous devez coder votre serveur WS pour les accepter. Vous avez accès au domaine (hôte) en-tête que vous pouvez ensuite utiliser pour accepter / refuser les demandes. Toutefois, cela peut être usurpée par quelque chose d'aussi simple que nc. Pour vraiment sécuriser la connexion que vous aurez besoin pour authentifier la connexion par d'autres moyens.

Answer 3

Websockets ont deux grands inconvénients en termes d'évolutivité que les ajax évite. Depuis ajax envoie une demande / réponse et ferme la connexion (..ou peu après) si quelqu'un reste sur la page web, il n'utilise pas les ressources du serveur lors de la marche au ralenti. Websockets sont destinés à flux de données au navigateur, et ils mobilisent des ressources de serveur pour le faire. Les serveurs ont une limite dans le nombre de connexions simultanées, ils peuvent garder ouverts à un moment donné. Sans parler en fonction de votre technologie côté serveur, ils peuvent attacher un fil pour gérer la prise. Donc websockets ont plus de ressources pour les besoins intensifs des deux côtés par connexion. Vous pouvez facilement épuiser tous vos fils servent des clients et pas de nouveaux clients pourrait venir si beaucoup d'utilisateurs sont juste assis sur la page. C'est là nodejs, VertX, Netty peut vraiment aider, mais même ceux qui ont des limites supérieures aussi bien.

Il y a également la question de l'état de la prise sous-jacente, et l'écriture du code des deux côtés qui portent sur la conversation stateful qui n'est pas quelque chose que vous avez à faire avec le style ajax parce qu'il est apatride. Websockets vous besoin de créer un protocole de bas niveau qui est résolu pour vous avec ajax. Des choses comme les battements de coeur, la fermeture des connexions inactives, rebranchement sur les erreurs, etc sont d'une importance vitale maintenant. Ce sont des choses que vous n'avez pas à résoudre lors de l'utilisation d'AJAX, car il était apatride. Etat est très important pour la stabilité de votre application et surtout la santé de votre serveur. Ce n'est pas trivial. Pré-HTTP nous avons construit un grand nombre de protocoles TCP stateful (FTP, telnet, SSH), puis HTTP est arrivé. Et personne ne fait ce genre de choses beaucoup plus parce que même avec ses limites HTTP a été étonnamment facile et plus robuste. Websockets ramener le bon et le mauvais des protocoles stateful. Vous apprendrez assez vite si vous n'avez pas reçu une dose de cette dernière tout le monde.

Si vous avez besoin continu de données en temps réel cette surcharge supplémentaire est justifiée parce que l'interrogation du serveur pour obtenir des données en flux continu est pire, mais si tout ce que vous faites est facile à utiliser interaction-> request-> response-> interface utilisateur de mise à jour, est plus facile ajax et utilisera moins de ressources car une fois que la réponse est envoyée la conversation est terminée et aucune ressource de serveur supplémentaires sont utilisés. Je pense donc qu'il est un compromis entre l'architecte et doit décider quel outil correspond à leur problème. AJAX a sa place, et websockets ont leur place.

Mise à jour

l'architecture de votre serveur est ce qui importe quand nous parlons de threads. Si vous utilisez un serveur traditionnellement multithread (ou processus) où chaque connexion socket obtient son propre fil pour répondre aux demandes Websockets alors beaucoup d'importance pour vous. Donc, pour chaque connexion, nous avons une prise, et éventuellement le système d'exploitation tomber si vous avez un trop grand nombre d'entre eux, et de même pour les fils (plus pour les processus). Les threads sont plus lourds que les prises (en termes de ressources) Nous essayons et conserver le nombre de threads que nous avons en cours d'exécution simultanément. Cela signifie la création d'un pool de threads qui est juste un nombre fixe de threads qui est partagée entre toutes les prises. Mais une fois qu'un socket est ouvert le fil est utilisé pour la conversation. La longueur de ces conversations régissent la rapidité avec laquelle vous pouvez réutiliser ces fils pour de nouvelles prises de courant à venir. La longueur de votre gouverne de conversation combien vous pouvez faire évoluer. Toutefois, si vous êtes en train de diffuser ce modèle ne fonctionne pas bien mise à l'échelle. Vous devez casser la conception de fil / prise.

modèle demande / réponse de HTTP rend très efficace en tournant sur le filetage de nouvelles prises. Si vous allez juste à la demande d'utilisation / utilisation de réponse HTTP son déjà construit et beaucoup plus facile que réimplémentant quelque chose comme ça dans websockets.

Depuis websockets ne doit pas être requête / réponse HTTP et peut diffuser des données si votre serveur a un nombre fixe de threads dans son pool de threads et vous avez le même nombre de websockets tying toutes vos discussions avec des conversations actives, vous ne pouvez pas servir de nouveaux clients venant! Vous avez atteint votre capacité maximale. C'est là la conception du protocole est important aussi avec websockets et fils. Votre protocole peut vous permettre de desserrer le fil par socket par modèle de conversation que les gens de façon juste assis là ne pas utiliser un fil sur votre serveur.

C'est là unique des serveurs de fil asynchrone entrent en jeu. En Java nous appelons souvent cette NIO pour IO non bloquante. Cela signifie qu'il est une API différente pour les sockets où l'envoi et la réception de données ne bloque pas le thread exécutant l'appel.

traditionnelle dans le blocage des prises lorsque vous appelez socket.read () ou socket.write () ils attendent que les données sont reçues ou envoyées avant le contrôle de retourner à votre programme. Cela signifie que votre programme est bloqué en attente pour les données de socket à venir ou aller jusqu'à ce que vous pouvez faire quoi que ce soit d'autre. Voilà pourquoi nous avons des fils afin que nous puissions faire en même temps que le travail (en même temps). Envoyer ces données au client X, tandis que je sur les données du client Y. est le nom concurrences du jeu quand on parle de serveurs.

Dans un serveur NIO nous utilisons un seul thread pour gérer tous les clients et callbacks vous inscrire pour être informé 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 () retourne immédiatement sans lire toutes les données, mais notre fonction, nous avons fourni sera appelé quand il entre en jeu. Cette conception change radicalement la façon dont vous construisez et architecte votre code parce que si vous vous attardez en attente sur quelque chose que vous ne pouvez pas recevoir de nouveaux clients. Vous avez un seul thread vous ne pouvez pas vraiment faire deux choses à la fois! Vous devez garder un fil que mouvement.

NIO, entrées-sorties asynchrones, programme basé sur l'événement que tout cela est connu sous le nom, est une conception de système beaucoup plus compliqué, et je ne vous suggère d'essayer et d'écrire si vous débutez. Même les programmeurs de très haut rang trouvent qu'il est très difficile de construire un système robuste. Puisque vous êtes asynchrone, vous ne pouvez pas appeler des API qui bloquent. Comme la lecture des données de la base de données ou envoyer des messages à d'autres serveurs doivent être exécutés de façon asynchrone. lecture / écriture Même à partir du système de fichiers peut ralentir votre seul fil vers le bas en réduisant votre évolutivité. Une fois que vous allez asynchrone, il est tout tout le temps asynchrone si vous voulez garder le déplacement seul fil. C'est là que ça devient défi parce que finalement vous lancer dans une API, comme blocs de données, qui ne sont pas asynchrone et vous devez adopter plusieurs threads à un certain niveau. Ainsi, une approche hybride sont communes, même dans le monde asynchrone.

Les bonnes nouvelles sont qu'il existe d'autres solutions qui utilisent cette API de niveau inférieur déjà intégré que vous pouvez utiliser. NodeJS, Vertx, Netty, Apache Mina, jouer Framework, Twisted Python, Stackless Python, etc. Il pourrait y avoir une bibliothèque obscure pour C ++, mais honnêtement, je ne dérange pas. La technologie de serveur ne nécessite pas les langues les plus rapides, car il est lié IO plus de CPU lié. Si vous êtes un dur écrou de performance meurent utiliser Java. Il a une énorme communauté de code à tirer de sa vitesse et il est très proche (et parfois mieux) que C ++. Si vous détestez juste aller avec nœud ou Python.

Answer 4

Oui, oui, il le fait. : D

Les réponses antérieures manquent d'imagination. Je ne vois aucune raison de plus d'utiliser AJAX si websockets sont à votre disposition.