Dans quelles situations la AJAX interrogation longue / courte serait-elle préférable aux WebSockets HTML5?

Question

Je construis une petite application de discussion pour des amis, mais je ne sais pas comment obtenir rapidement des informations qui ne sont ni aussi manuelles ni aussi rudimentaires que de forcer l'actualisation d'une page.

Actuellement, j'implémente cela en utilisant AJAX simple, mais cela présente l'inconvénient de frapper régulièrement le serveur lorsqu'un court délai s'écoule.

En recherchant des interrogations longues/courtes, j'ai parcouru HTML5 WebSockets. Ceci semble facile à mettre en œuvre, mais je ne suis pas sûr s'il existe des inconvénients cachés. Par exemple, je pense que WebSockets est uniquement pris en charge par certains navigateurs. Y a-t-il d'autres inconvénients aux WebSockets dont je devrais être au courant?

Comme il semble que les deux technologies fassent la même chose, dans quels types de scénarios préféreriez-vous utiliser l'une plutôt que l'autre? Plus précisément, HTML5 WebSockets a-t-il rendu AJAX interrogation longue/courte obsolète, ou existe-t-il des raisons impérieuses de préférer AJAX à WebSockets?

moka · Accepted Answer

WebSockets est définitivement l'avenir.

Une interrogation longue est une solution de contournement empêchant la création de connexions pour chaque demande, comme le fait AJAX - mais une interrogation longue a été créée alors que WebSockets n'existait pas. Maintenant, à cause de WebSockets, les longues interrogations vont disparaître.

WebRTC permet une communication entre homologues.

Je recommande d'apprendre WebSockets .

Comparaison:

de différentes techniques de communication sur le web

AJAX - request → response. Crée une connexion au serveur, envoie des en-têtes de requête avec des données facultatives, obtient une réponse du serveur et ferme la connexion. Pris en charge par tous les principaux navigateurs.
Interrogation longue - request → wait → response. Crée une connexion au serveur comme AJAX, mais maintient une connexion persistante ouverte pendant un certain temps (mais pas trop longtemps). Pendant la connexion, le client ouvert peut recevoir des données du serveur. Le client doit se reconnecter périodiquement après la fermeture de la connexion, en raison de dépassements de délai ou de données électroniques. Du côté du serveur, il est toujours traité comme une requête HTTP, identique à AJAX, à ceci près que la réponse à la requête se produira maintenant ou dans le futur, définie par la logique de l'application. tableau de support (complet) | wikipedia
WebSockets - client server. Créez une connexion TCP au serveur et laissez-la ouverte aussi longtemps que nécessaire. Le serveur ou le client peut facilement fermer la connexion. Le client passe par un processus de négociation compatible HTTP. Si cela réussit, le serveur et le client peuvent à tout moment échanger des données dans les deux sens. Il est efficace que l'application nécessite un échange de données fréquent dans les deux sens. Les WebSockets ont un cadrage des données qui inclut le masquage de chaque message envoyé du client au serveur, ainsi les données sont simplement cryptées. support graphique (très bien) | wikipedia
WebRTC - peer peer. Transport pour établir la communication entre les clients et est agnostique pour le transport, il peut donc utiliser des couches UDP, TCP ou même plus abstraites. Ceci est généralement utilisé pour le transfert de gros volumes de données, tel que le streaming vidéo/audio, où la fiabilité est secondaire et quelques images ou réduction de la progression de la qualité peuvent être sacrifiées au profit du temps de réponse et, au moins, de certains transferts de données. Les deux côtés (homologues) peuvent transmettre des données les unes aux autres de manière indépendante. Bien qu'il puisse être utilisé de manière totalement indépendante de tout serveur centralisé, il nécessite toujours un moyen d'échanger des données endPoints, où, dans la plupart des cas, les développeurs utilisent toujours des serveurs centralisés pour "relier" leurs pairs. Ceci est nécessaire uniquement pour échanger des données essentielles pour établir une connexion, après quoi un serveur centralisé n'est plus nécessaire. support graphique (moyen) | wikipedia
Événements envoyés par le serveur - client ← server. Le client établit une connexion persistante et à long terme au serveur. Seul le serveur peut envoyer des données à un client. Si le client souhaite envoyer des données au serveur, cela nécessitera l'utilisation d'une autre technologie/protocole. Ce protocole est compatible HTTP et simple à mettre en œuvre dans la plupart des plateformes côté serveur. C'est un protocole préférable à utiliser au lieu d'une longue interrogation. graphique de support (bon, sauf IE) | wikipedia

Avantages:

Le principal avantage de WebSockets côté serveur est qu’il ne s’agit pas d’une requête HTTP (après la prise de contact), mais d’un protocole de communication basé sur un message approprié. Ceci vous permet d’obtenir d’énormes avantages en termes de performances et d’architecture . Par exemple, dans node.js, vous pouvez partager la même mémoire pour différentes connexions de socket, afin que chacun puisse accéder à des variables partagées. Par conséquent, vous n'avez pas besoin d'utiliser une base de données comme point d'échange au milieu (comme avec AJAX ou Long Polling avec un langage tel que PHP). Vous pouvez stocker des données dans la RAM, ou même republier immédiatement entre les sockets.

Considérations de sécurité

Les gens sont souvent préoccupés par la sécurité de WebSockets. La réalité est que cela fait peu de différence ou même fait de WebSockets une meilleure option. Tout d'abord, avec AJAX, les chances de MITM sont plus grandes, car chaque demande est une nouvelle connexion TCP qui traverse l'infrastructure Internet. Avec WebSockets, une fois connecté, il est beaucoup plus difficile d'intercepter entre les deux, avec un masquage de trame renforcé lorsque les données sont transférées d'un client à un serveur, ainsi qu'une compression supplémentaire, qui nécessite davantage d'effort pour les analyser. Tous les protocoles modernes supportent à la fois HTTP et HTTPS (crypté).

P.S.

N'oubliez pas que les WebSockets ont généralement une approche très différente de la logique pour la mise en réseau , plus semblable aux jeux en temps réel, et non à http.

bmm6o · Answer

Une technologie concurrente que vous avez omise est celle des événements envoyés par le serveur/source d'événements. Que sont les interrogations longues, Websockets, les événements envoyés par le serveur (SSE) et Comet? discute bien de tous ces aspects. Gardez à l'esprit que certaines d'entre elles sont plus faciles à intégrer côté serveur.

Brant Olsen · Answer

Pour les applications de discussion ou toute autre application en conversation constante avec le serveur, WebSockets constitue la meilleure option. Cependant, vous ne pouvez utiliser que WebSockets avec un serveur qui les prend en charge, ce qui peut limiter votre capacité à les utiliser si vous ne pouvez pas installer les bibliothèques requises. Dans ce cas, vous devrez utiliser Long Polling pour obtenir une fonctionnalité similaire.

JSON C11 · Answer

XHR polling Une demande est traitée lorsque l'événement se produit (peut être immédiat ou après un délai). Les demandes ultérieures devront être effectuées pour recevoir d'autres événements.

Le navigateur envoie une requête asynchrone au serveur, ce qui peut attendre que les données soient disponibles avant de répondre. La réponse peut contenir des données codées (généralement XML ou JSON) ou JavaScript à exécuter par le client. À la fin du traitement de la réponse, le navigateur crée et envoie un autre XHR pour attendre le prochain événement. Ainsi, le navigateur conserve toujours une demande en suspens auprès du serveur, à laquelle il doit répondre à chaque événement. Wikipedia
Événements envoyés par le serveur Le client envoie une demande au serveur. Le serveur envoie de nouvelles données à la page Web à tout moment.

Traditionnellement, une page Web doit envoyer une demande au serveur pour recevoir de nouvelles données; c'est-à-dire que la page demande des données au serveur. Avec les événements envoyés par le serveur, un serveur peut envoyer de nouvelles données à une page Web à tout moment, en envoyant des messages sur la page Web. Ces messages entrants peuvent être traités comme des événements + des données dans la page Web. Mozilla
WebSockets Après la prise de contact initiale (via le protocole HTTP). La communication est bidirectionnelle à l'aide du protocole WebSocket.

La poignée de main commence par une requête/réponse HTTP, permettant aux serveurs de gérer les connexions HTTP ainsi que les connexions WebSocket sur le même port. Une fois la connexion établie, la communication bascule vers un protocole binaire bidirectionnel non conforme au protocole HTTP. Wikipedia