L'envoi d'une grande quantité de messages entraîne-t-il une surcharge importante par rapport à l'envoi de grands messages avec des WebSockets ?

Question

Je sais qu'avec le HTML et l'envoi de données, il est conseillé d'envoyer beaucoup de données peu fréquemment en raison des frais généraux associés aux en-têtes, au contenu, aux balises, aux dates d'expiration, aux cookies, etc. Pour une meilleure expérience utilisateur et moins de décalage, il vaut mieux envoyer de gros messages peu fréquemment que de petites mises à jour fréquemment.

Mais est-ce le cas avec les WebSockets ? Sur ma page web, j'envoie actuellement beaucoup de données de pixels muy fréquemment pour que les clients ne ressentent pas trop de hachage. Cependant, serait-il préférable que j'envoie des mises à jour moins souvent ?

Je suppose que ma question se résume à : "Avec les WebSockets, est-il toujours plus efficace d'envoyer de gros messages peu fréquemment que de petits messages fréquents ?" Je crois avoir entendu dire que la technologie s'est débarrassée de la plupart des frais généraux associés à l'envoi et à la réception de messages, car elle maintient une connexion constante et est full duplex, etc.

Merci de votre lecture.

Edit : aider un ordinateur

Answer 1

Ce que j'aimerais surtout souligner, c'est que les interfaces bavardes ou épaisses ne sont pas limitées à une pile technologique (WebSockets, HTTP, UDP, autres protocoles liés au réseau). Elles partagent toutes les mêmes propriétés et les effets de nombreuses requêtes par rapport à des requêtes plus importantes devront être évalués de manière similaire (si ce n'est identique). Voici un excellent article pour plus de lecture sur le sujet.

La dernière chose à noter est que c'est la nature de votre demande qui influencera le plus votre décision. Un système de négociation boursière en temps réel sera beaucoup plus bavard qu'un simple formulaire d'entrée utilisateur.

EDIT

Voici une question similaire concernant les performances de WebSocket : HTTP et Websockets en ce qui concerne les frais généraux

Answer 2

L'overhead de l'envoi d'un message WebSocket (client à serveur) de taille <=125 octets de charge utile est de 6 octets. Jusqu'à 64k de charge utile, il sera de 8 octets, et au-delà de 14 octets.

Étant donné que WebSocket est un protocole basé sur TCP, en raison des ajustements de la taille des fenêtres dynamiques et de la diffusion en continu, l'envoi rapide de nombreux petits messages se transformera de toute façon en segments TCP et en paquets IP de grande taille. Sur le fil, ce sera similaire à l'envoi de gros messages WS plus lentement.

Bien entendu, cela ne s'applique que lorsque l'envoi est effectué de manière asynchrone, c'est-à-dire sans attendre une réponse pour un message envoyé avant d'en envoyer un autre.