WebSockets est définitivement l'avenir maintenant.
L'interrogation longue est une solution de rechange sale pour éviter de créer des connexions pour chaque demande comme le fait AJAX - mais l'interrogation longue a été créée lorsque les WebSockets n'existaient pas. Maintenant, grâce aux WebSockets, l'interrogation longue est le départ pas plus.
WebRTC permet la communication de pair à pair.
Je recommande d'apprendre WebSockets .
Comparaison :
des différentes techniques de communication sur le web
-
AJAX - request response . Crée une connexion avec le 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.
-
Long sondage - request wait response . Crée une connexion avec le serveur comme AJAX, mais maintient une connexion "keep-alive" 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 des délais d'attente ou de l'absence de données. Du côté du serveur, il est toujours traité comme une demande HTTP, comme AJAX, sauf que la réponse à la demande se produira maintenant ou à un moment dans le futur, défini par la logique de l'application. tableau de soutien (complet) | _wikipedia_
-
WebSockets - client server . Créez une connexion TCP avec le 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 poignée de main compatible HTTP. S'il réussit, le serveur et le client peuvent échanger des données dans les deux sens à tout moment. Cette méthode est efficace si l'application nécessite un échange fréquent de données dans les deux sens. Les WebSockets disposent d'un encadrement des données qui comprend le masquage de chaque message envoyé du client au serveur, de sorte que les données sont simplement cryptées. tableau de soutien (très bon) | _wikipedia_
-
WebRTC - peer peer . Transport pour établir la communication entre les clients et est agnostique en matière de transport, il peut donc utiliser UDP, TCP ou même des couches plus abstraites. Il est généralement utilisé pour le transfert de gros volumes de données, comme le streaming vidéo/audio, où la fiabilité est secondaire et où quelques images ou une réduction de la progression de la qualité peuvent être sacrifiées en faveur du temps de réponse et, au moins, d'un certain transfert de données. Les deux parties (pairs) peuvent se transmettre des données de manière indépendante. Bien qu'il puisse être utilisé de manière totalement indépendante de tout serveur centralisé, il nécessite tout de même un moyen d'échanger les données des points d'extrémité, où dans la plupart des cas, les développeurs utilisent encore des serveurs centralisés pour "relier" les pairs. Cela n'est nécessaire que pour échanger les données essentielles à l'établissement d'une connexion, après quoi un serveur centralisé n'est plus nécessaire. tableau de support (moyen) | wikipedia
-
É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 veut envoyer des données au serveur, il doit utiliser une autre technologie/un autre protocole pour le faire. Ce protocole est compatible avec HTTP et simple à mettre en œuvre dans la plupart des plates-formes côté serveur. Il est préférable d'utiliser ce protocole à la place de Long Polling. carte de support (bonne, sauf IE) | _wikipedia_
Avantages :
Le principal avantage de WebSockets côté serveur, c'est qu'il ne s'agit pas d'une requête HTTP (après poignée de main), mais d'un véritable protocole de communication basé sur des messages. Ce 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'elles puissent chacune 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 comme PHP). Vous pouvez stocker les données dans la RAM, ou même les republier directement entre les sockets.
Considérations relatives à la sécurité
Les gens s'inquiètent souvent de la sécurité des WebSockets. En réalité, il y a peu de différence, voire même une meilleure option pour les WebSockets. Tout d'abord, avec AJAX, il y a une plus grande probabilité de MITM car chaque demande est une nouvelle connexion TCP qui traverse l'infrastructure Internet. Avec les WebSockets, une fois la connexion établie, il est beaucoup plus difficile de l'intercepter entre les deux, avec un masquage de trame supplémentaire lorsque les données sont transmises en continu du client au serveur, ainsi qu'une compression supplémentaire, ce qui exige plus d'efforts pour sonder les données. Tous les protocoles modernes supportent les deux : 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 de mise en réseau. plus comme les jeux en temps réel l'ont fait pendant tout ce temps, et non comme le http.
