WebSockets ping / pong, pourquoi pas TCP keepalive?
WebSockets ont la possibilité d'envoyer des pings à l'autre extrémité, l'autre extrémité étant supposée répondre par un pong.
À la réception d'une trame Ping, un point d'extrémité DOIT envoyer une trame Pong en réponse, sauf s'il a déjà reçu une trame Close. Il DEVRAIT répondre avec le cadre Pong dès que possible.
TCP offre quelque chose de similaire sous la forme de keepalive:
[Vous] envoyez à votre pair un paquet de sonde keepalive ne contenant aucune donnée et l'indicateur ACK activé. Vous pouvez le faire en raison des spécifications TCP/IP, en tant que sorte d’ACK en double, et le point de terminaison distant n’aura pas d’argument, car TCP est un protocole orienté flux. En revanche, , vous recevrez une réponse de l’hôte distant (qui n’a pas besoin de prendre en charge de keepalive, mais uniquement de TCP/IP), sans données et avec l’ensemble ACK.
Je penserais que TCP keepalive est plus efficace, car il peut être manipulé dans le noyau sans qu'il soit nécessaire de transférer des données dans l'espace utilisateur, d'analyser un cadre websocket, de créer un cadre de réponse et retour au noyau pour la transmission, ce qui réduit également le trafic réseau.
De plus, WebSockets sont explicitement spécifiés pour toujours fonctionner sur TCP; ils ne sont pas agnostiques dans la couche de transport, donc TCP keepalive est toujours disponible:
Le protocole WebSocket est un protocole indépendant basé sur TCP.
Alors pourquoi voudrait-on jamais utiliser WebSocket ping/pong au lieu de TCP keepalive?
Les problèmes avec TCP keepalive sont:
- C'est désactivé par défaut.
- Il fonctionne par défaut toutes les deux heures, au lieu d'être à la demande comme le prévoit le protocole Ping/Pong.
- Il fonctionne entre les mandataires plutôt que de bout en bout.
Outre la réponse de EJP, je pense que cela pourrait également être lié aux mécanismes de proxy HTTP. Les connexions Websocket peuvent également s'exécuter via un serveur proxy (HTTP). Dans de tels cas, le TCP keepalive vérifierait uniquement la connexion jusqu'au proxy et non la connexion de bout en bout.
http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html#ping-and-pong-frames
.3.4 Cadres Ping et Pong
La spécification du protocole WebSocket définit les trames Ping et Pong pouvant être utilisées pour les analyses persistantes, de battements de cœur, de vérification de l’état du réseau, de latence , etc. . Celles-ci ne sont pas exposées actuellement dans l'API.
Les agents utilisateurs peuvent envoyer des requêtes ping et des trames Pong non sollicitées, par exemple pour tenter de conserver des mappages de réseau local NAT), afin de détecter les connexions défaillantes ou pour un affichage métriques de latence pour l'utilisateur . Les agents d'utilisateur ne doivent pas utiliser de pings ni de pong non sollicités pour aider le serveur; il est supposé que les serveurs solliciteront des pong à chaque fois que leurs besoins le permettront.
Les WebSockets ont été développés avec RTC à l'esprit, donc quand je regarde la fonctionnalité ping/pong, je vois aussi une façon de mesurer la latence. Le fait que le pong doit renvoyer la même charge utile que ping, rend très pratique l’envoi d’un timestamp, puis calcule la latence client à serveur ou vice-versa.
Keepalive TCP ne passe pas par un proxy web. Le ping/pong websocket sera transmis via des proxies Web. TCP keepalive est conçu pour superviser une connexion entre TCP points de terminaison. Les points de terminaison de socket Web ne sont pas égaux à TCP points de terminaison. A La connexion websocket peut utiliser plusieurs TCP connexions entre deux points finaux websocket.