WebSockets est définitivement l'avenir.
L'interrogation longue est une solution de contournement pour éviter de créer des connexions pour chaque demande comme AJAX - mais l'interrogation longue a été créée lorsque les WebSockets n'existaient pas. Maintenant, grâce aux WebSockets, les longs sondages disparaissent.
WebRTC permet la communication d'égal à égal.
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 demande avec des données facultatives, obtient une réponse du serveur et ferme la connexion.
Pris en charge dans tous les principaux navigateurs.
Sondage long - request→ wait→ response. Crée une connexion au serveur comme le fait AJAX, mais maintient une connexion permanente ouverte pendant un certain temps (pas longtemps cependant). 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élais d'attente ou de données eof. Côté serveur, elle est toujours traitée comme une requête HTTP, comme AJAX, sauf que la réponse sur demande se produira maintenant ou dans le futur, définie par la logique de l'application.
tableau de support (complet) | Wikipédia
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 prise de contact compatible HTTP. S'il réussit, le serveur et le client peuvent à tout moment échanger des données dans les deux sens. Il est efficace si l'application nécessite un échange de données fréquent dans les deux sens. Les WebSockets ont un encadrement des données qui inclut un masquage pour chaque message envoyé du client au serveur, donc les données sont simplement chiffrées.
tableau de support (très bon) | Wikipédia
WebRTC - peer↔ tableau de support (moyen) | Wikipédiapeer . Le transport pour établir la communication entre les clients et est indépendant du transport, il peut donc utiliser des couches UDP, TCP ou encore plus abstraites. Ceci est généralement utilisé pour le transfert de données à haut volume, comme le streaming vidéo / audio, où la fiabilité est secondaire et quelques images ou la réduction de la progression de la qualité peuvent être sacrifiées en faveur du temps de réponse et, au moins, certains transferts de données. Les deux côtés (homologues) peuvent se transmettre des données indépendamment. 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 de points d'extrémité, où dans la plupart des cas, les développeurs utilisent toujours des serveurs centralisés pour «lier» leurs homologues. Cela n'est nécessaire que pour échanger des données essentielles pour établir une connexion, après quoi un serveur centralisé n'est pas nécessaire.
Événements envoyés par le serveur - client← server. Le client établit une connexion persistante et à long terme avec le serveur. Seul le serveur peut envoyer des données à un client. Si le client souhaite envoyer des données au serveur, il faudrait pour cela utiliser une autre technologie / protocole. Ce protocole est compatible HTTP et simple à implémenter dans la plupart des plateformes côté serveur. Il s'agit d'un protocole préférable à utiliser au lieu de l'interrogation longue. graphique de support (bon, sauf IE) | Wikipédia
Avantages:
Le principal avantage de WebSockets côté serveur, c'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 les messages approprié. Cela 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 qu'ils puissent chacun accéder aux 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 comme 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é des WebSockets. La réalité est que cela fait peu de différence ou même met WebSockets comme meilleure option. Tout d'abord, avec AJAX, les chances de MITM sont plus élevées , 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 supplémentaire lorsque les données sont transmises du client au serveur ainsi qu'une compression supplémentaire, qui nécessite plus d'efforts pour sonder les données. Tous les protocoles modernes prennent en charge à la fois: HTTP et HTTPS (crypté).
PS
N'oubliez pas que les WebSockets ont généralement une approche très différente de la logique de mise en réseau , plus comme les jeux en temps réel avaient tout ce temps, et pas comme http.
