nodejs: Ajax vs Socket.IO, pour et contre

il y a beaucoup de fausses informations communes dans ce fil qui est très inexacte.

TL / DR; WebSocket remplace HTTP pour les applications! Il a été conçu par Google avec l'aide de Microsoft et de nombreuses autres grandes entreprises. Tous les navigateurs le supportent. Il n'y a pas les inconvénients.

SocketIO est construit sur le protocole WebSocket ( RFC 6455). Il a été conçu pour remplacer AJAX entièrement. Il n'a pas de problèmes d'extensibilité quoi qu'il arrive. Il fonctionne plus rapidement QU'AJAX tout en consommant un ordre de grandeur moins de ressources.

AJAX a 10 ans et est construit sur un JavaScript unique XMLHTTPRequest fonction qui a été ajoutée pour permettre les callbacks sur les serveurs sans recharger la page entière.

EN d'autres termes, AJAX est un document de protocole (HTTP) avec une seule fonction JavaScript.

protocole d'application qui a été conçu pour remplacer entièrement HTTP. Lorsque vous mettez à niveau une connexion HTTP (en demandant le protocole WebSocket), vous activez la communication bidirectionnelle en duplex complet avec le serveur et aucun transfert de protocole n'est impliqué quoi qu'il en soit. Avec AJAX, vous devez soit activer keep-alive (qui est le même que SocketIO, seulement un vieux protocole), soit forcer de nouvelles poignées de main HTTP, ce qui bloque le serveur, chaque fois que vous faites une requête AJAX.

Un SocketIO serveur courir sur le dessus du noeud peut gérer 100.000 simultanées connections en mode "keep-alive" utilisant seulement 4 Go de ram et un seul CPU, et cette limite est causée par le moteur V8 de collecte des ordures, pas le protocole. Vous n'y parviendrez jamais avec AJAX, même dans vos rêves les plus fous.

pourquoi SocketIO est tellement plus rapide et consomme tellement moins de ressources

les principales raisons pour cela est encore une fois, WebSocket était conçu pour applications, et AJAX est un work-around pour activer les applications au-dessus d'un protocole de document.

si vous plongez dans le protocole HTTP, et utilisez MVC frameworks, vous verrez qu'une seule requête AJAX transmettra 700-900 octets de charge de protocole juste à AJAX à une URL (sans aucune de vos propres charges utiles). En contraste frappant, WebSocket utilise environ 10 octets, soit environ 70 fois moins de données pour parler avec le serveur.

il y a de la fausse information que a socket connexion port connexion; ce n'est pas le cas. Une connexion socket n'est qu'une entrée dans une table. Très peu de ressources sont consommées, et un seul serveur peut fournir 1.000.000+ connexions WebSocket. Un serveur AWS XXL peut héberger et héberge 1 000 000 de connexions SocketIO.

AJAX connexion gzip / deflate l'ensemble des en-têtes HTTP, decode les en-têtes, encode les en-têtes, et lance un thread de serveur HTTP pour traiter la requête, encore une fois, parce qu'il s'agit d'un protocole de document; le serveur a été conçu pour cracher des documents une seule fois.

en revanche, WebSocket stocke simplement une entrée dans une table pour une connexion, environ 40-80 octets. C'est littéralement ça. Aucune interrogation se produit, à tous.

WebSocket conçu à l'échelle.

dans la mesure du comme si SocketIO était bordélique... Ce n'est pas du tout le cas. AJAX est bordélique, vous avez besoin de promesse/réponse.

avec SocketIO, vous avez simplement des émetteurs et des récepteurs; ils n'ont même pas besoin de savoir l'un de l'autre; aucun système de promesse n'est nécessaire:

pour demander une liste d'utilisateurs, il vous suffit d'envoyer un message au serveur...

socket.emit("giveMeTheUsers");

lorsque le serveur est prêt, il vous renvoie un autre message. Tada, vous avez terminé. Ainsi, pour traiter une liste d'utilisateurs vous dites simplement ce que faire lorsque vous recevez une réponse que vous cherchez...

socket.on("HereAreTheUsers", showUsers(data) );

c'est tout. Où est la pagaille? Eh bien, il n'y en a pas:) Séparation des préoccupations? Fait pour vous. Enfermer le client pour qu'il sache qu'il doit attendre? Ils n'ont pas à attendre :) Vous pourriez obtenir une nouvelle liste d'utilisateurs à chaque fois... Le serveur pourrait même lire toute commande D'interface utilisateur de cette façon... Les Clients peuvent se connecter à l'autre sans même utiliser un serveur avec WebRTC...

système de Chat en SocketIO? 10 lignes de code. Vidéoconférence en temps réel? 80 lignes de code Oui... Luke... Rejoignez-moi. utiliser le bon protocole pour le travail... Si vous écrivez une application... utiliser une application de protocole.

je pense que le problème et la confusion vient ici de gens qui sont habitués à utiliser AJAX et pensée ils ont besoin de tout le protocole de promesse supplémentaire sur le client et D'une API REST à l'arrière... Eh bien non. :) Ce n'est plus nécessaire :)

oui, vous avez bien lu... une API REST N'est plus nécessaire lorsque vous décidez de passer à WebSocket. RESTE est effectivement obsolète. si vous écrivez une application de bureau, communiquez-vous avec le dialogue avec le repos? Non :) c'est assez stupide.

SocketIO, en utilisant WebSocket fait la même chose pour vous... vous pouvez commencer à penser du côté client comme simple la boîte de dialogue de votre application. Vous n'avez plus besoin de REPOS, à tous.

en fait, si vous essayez d'utiliser le repos tandis que en utilisant WebSocket, C'est aussi stupide que D'utiliser REST que le protocole de communication pour une boîte de dialogue de bureau... il n'y a absolument aucun point, à tous.

qu'est-Ce que vous dites Timmy? Qu'en est-il des autres applications qui veulent utiliser votre application? Vous devriez leur donner accès au repos? Timmy... WebSocket est absent depuis 4 ans... Il suffit qu'ils se connectent à votre application en utilisant WebSocket, et qu'ils demandent les messages en utilisant protocole... il consommera 50 fois moins de ressources, sera beaucoup plus rapide, et 10x plus facile à développer... Pourquoi soutenir le passé quand vous créez l'avenir?

bien sûr, il y a des cas d'utilisation pour le repos, mais ils sont tous pour des systèmes plus anciens et périmés... La plupart des gens ne le savent pas encore.

Socket.IO utilise une connexion persistante entre le client et le serveur, de sorte que vous atteindrez une limite maximale de connexions simultanées en fonction des ressources que vous avez du côté du serveur, tandis que plus de requêtes Ajax async peuvent être servies avec les mêmes ressources.

Socket.IO est principalement conçu pour les connexions en temps réel et bidirectionnelles entre le client et le serveur et dans certaines applications, il n'est pas nécessaire de conserver des connexions permanentes. D'autre part Ajax connexions asynchrones devrait passer la phase de configuration de la connexion HTTP et l'envoi des données d'en-tête et de tous les cookies avec chaque requête.

Socket.IO a été conçu comme un serveur de processus unique et peut avoir des problèmes d'évolutivité en fonction des ressources du serveur auxquelles vous êtes lié.

Socket.IO in ne convient pas bien pour les applications lorsque vous êtes mieux pour mettre en cache les résultats des requêtes des clients.

Socket.Les applications IO rencontrent des difficultés avec l'optimisation SEO et le moteur de recherche indexer.

Socket.IO n'est pas une norme et n'est pas équivalent à L'API de Socket Web du W3C, il utilise L'API de Socket Web actuelle si le navigateur prend en charge, socket.io créé par une personne pour résoudre la compatibilité de navigateur croisée dans les applications en temps réel et est si jeune, environ 1 an. Sa courbe d'apprentissage, moins de développeurs et de ressources communautaires par rapport à ajax/jquery, la maintenance à long terme et moins besoin ou de meilleures options à l'avenir peut être important pour les équipes de développeurs de faire leur code basé sur socket.io ou pas.