WebSockets, UDP et benchmarks
Les websockets HTML5 utilisent actuellement une forme de communication TCP. Cependant, pour les jeux en temps réel, TCP ne suffit tout simplement pas) (et c'est une excellente raison d'utiliser une autre plate-forme, comme native). Comme j'ai probablement besoin d'UDP pour continuer un projet, je voudrais savoir si les spécifications pour HTML6 ou quoi que ce soit supporteront UDP?
Existe-t-il également des références fiables pour les WebSockets qui compareraient le protocole WS à un protocole de socket direct de bas niveau?
Sur un réseau local, vous pouvez obtenir des temps d'aller-retour pour les messages via WebSocket de 200 microsecondes (du navigateur JS au serveur WebSocket et inversement), ce qui est similaire aux pings ICMP bruts. Sur MAN, c'est environ 10 ms, WAN (sur l'ADSL résidentiel vers le serveur dans le même pays) environ 30 ms, et ainsi de suite jusqu'à environ 120-200 ms via 3,5 G. Le point est: WebSocket ajoute pratiquement aucune latence à celle que vous obtiendrez de toute façon, en fonction du réseau.
La surcharge du niveau de connexion de WebSocket (par rapport au TCP brut) est comprise entre 2 octets (charge utile non masquée de longueur <126 octets) et 14 octets (charge utile masquée de longueur> 64 Ko) par message (les anciens numéros supposent que le message n'est pas fragmenté en plusieurs Cadres WebSocket). Très lent.
Pour une analyse plus détaillée de la surcharge au niveau des câbles WebSocket, veuillez consulter ceci article de blog - cela inclut une analyse couvrant les couches au-delà de WebSocket également.
Plus encore: avec une implémentation WebSocket capable de traiter le streaming, vous pouvez (après la prise de contact WebSocket initiale), démarrer un seul message WebSocket et une trame dans chaque direction, puis envoyer jusqu'à 2 ^ 63 octets sans surcharge. Essentiellement, cela fait de WebSocket un prélude sophistiqué pour TCP brut. Avertissement: les intermédiaires peuvent fragmenter le trafic à leur propre décision. Cependant, si vous exécutez WSS (c'est-à-dire WS = TLS sécurisé), aucun intermédiaire ne peut interférer, et vous voilà: TCP brut, avec un prélude compatible HTTP (WS handshake).
WebRTC utilise RTP (= basé sur UDP) pour le transport multimédia mais a besoin en plus d'un canal de signalisation (qui peut être WebSocket, par exemple). RTP est optimisé pour la perte) tolérant en temps réel média transport. "Jeux en temps réel" signifie souvent transférer non pas des médias, mais des choses comme les positions des joueurs. WebSocket fonctionnera pour cela.
Remarque: Le transport WebRTC peut être effectué sur RTP ou sécurisé lorsqu'il est sur SRTP. Voir "Profils RTP" ici .
Je recommanderais de développer votre jeu à l'aide de WebSockets sur un réseau câblé local, puis de passer à l'API WebRTC Data Channel une fois qu'il sera disponible. Comme @oberstet le note correctement, les latences moyennes de WebSocket sont essentiellement équivalentes à raw TCP ou UDP, en particulier sur un réseau local, donc cela devrait convenir à votre phase de développement. L'API WebRTC Data Channel est conçue être très similaire aux WebSockets (une fois la connexion établie), il devrait donc être assez simple à intégrer une fois qu'il sera largement disponible.
Votre question implique que UDP est probablement ce que vous voulez pour un jeu à faible latence et il y a du vrai. Vous le savez peut-être déjà depuis que vous écrivez un jeu, mais pour ceux qui ne le sont pas, voici une introduction rapide sur TCP vs UDP pour les jeux en temps réel:
TCP est un mécanisme de transport fiable et en ordre et UDP est le meilleur effort. TCP fournira toutes les données envoyées et dans l'ordre dans lequel elles ont été envoyées. Les paquets UDP sont envoyés à leur arrivée, peuvent être en panne et peuvent présenter des lacunes (sur un réseau encombré) , Les paquets UDP sont supprimés avant TCP). TCP sonne comme une grande amélioration, et c'est pour la plupart des types de trafic réseau, mais ces fonctionnalités un coût: un paquet retardé ou abandonné entraîne également le retard de tous les paquets suivants (pour garantir la livraison dans l'ordre).
Les jeux en temps réel ne peuvent généralement pas tolérer le type de retards qui peuvent résulter des sockets TCP afin qu'ils utilisent UDP pour la majeure partie du trafic du jeu et disposent de mécanismes pour faire face aux chutes et aux pannes). données de commande (par exemple, ajouter des numéros de séquence aux données de charge utile). Ce n'est pas un gros problème si vous manquez une mise à jour de position du joueur ennemi parce que quelques millisecondes plus tard, vous recevrez une autre mise à jour de position (et ne le remarquerez probablement même pas) Mais si vous n'obtenez pas de mises à jour de position pendant 500 ms et que vous les retirez soudainement une fois, cela se traduit par un gameplay terrible.
Cela dit, sur un réseau câblé local, les paquets ne sont presque jamais retardés ou abandonnés et donc TCP est parfaitement bien comme cible de développement initial. Une fois que l'API WebRTC Data Channel est disponible, vous pourriez envisager La proposition actuelle a une fiabilité configurable basée sur des tentatives ou des minuteries.
Voici quelques références:
Pour faire court, si vous voulez utiliser TCP pour les jeux multijoueurs, vous devez utiliser ce que nous appelons les techniques de streaming adaptatif. En d'autres termes, vous devez vous assurer que la quantité de données en temps réel envoyées pour synchroniser le monde du jeu entre les clients est régie par la bande passante et la latence actuellement disponibles pour chaque client.
La limitation dynamique, la fusion, la livraison delta et d'autres mécanismes sont des techniques de streaming adaptatif, qui ne rendent pas par magie TCP aussi efficace que UDP, mais le rendent suffisamment utilisable pour plusieurs types de jeux.
J'ai essayé d'expliquer ces techniques dans un article: Optimisation de la synchronisation des jeux 3D multijoueurs sur le Web ( http://blog.lightstreamer.com /2013/10/optimizing-multiplayer-3d-game.html ).
J'ai également donné une conférence sur ce sujet le mois dernier à Conférence des développeurs HTML5 à San Francisco. La vidéo vient d'être mise à disposition sur YouTube: http://www.youtube.com/watch?v=cSEx3mhsoHg
Il n'y a pas de prise en charge UDP pour les Websockets (il devrait vraiment y en avoir), mais vous pouvez apparemment utiliser l'API RTCDataChannel de WebRTC pour une communication de type UDP. Il y a un bon article ici:
http://www.html5rocks.com/en/tutorials/webrtc/datachannels/
RTCDataChannel utilise en fait SCTP qui a une fiabilité configurable et une livraison commandée. Vous pouvez le faire agir comme UDP en lui disant de remettre des messages sans ordre et en définissant le nombre maximal de retransmissions à 0.
Je n'ai pourtant rien essayé de tout cela.
Je voudrais savoir si les spécifications pour HTML6 ou autre prendront en charge UDP?
WebSockets ne le fera pas. L'un des avantages de WebSockets est qu'il superpose la connexion HTTP existante . Cela signifie que pour les proxys et les pare-feu WebSockets ressemble à HTTP afin qu'ils ne soient pas bloqués.
Il est probable que les connexions UDP arbitraires ne feront jamais partie d'une spécification Web en raison de problèmes de sécurité . La chose la plus proche de ce que vous recherchez viendra probablement dans le cadre de WebRTC et elle est associée protocole JSEP .
existe-t-il des points de référence fiables ... qui .. comparent le protocole WS à un protocole de socket direct de bas niveau?
Pas que je sache. Je vais sortir sur un membre et prédire que les WebSockets seront plus lents;)