WebSocketshabe die Option Senden von Pings an das andere Ende, wo das andere Ende mit einem Pong antworten soll.

Bei Empfang eines Ping-Frames MUSS ein Endpunkt als Antwort einen Pong-Frame senden, es sei denn, er hat bereits einen Close-Frame erhalten. Es sollte mit Pong-Rahmen reagieren, sobald es praktisch ist.

TCPbietet etwas ähnliches in Form von Keepalive:

[Y] Sie senden Ihrem Peer ein Keepalive-Testpaket ohne Daten, und das ACK-Flag ist aktiviert. Sie können dies aufgrund der TCP / IP-Spezifikationen als eine Art doppeltes ACK ausführen, und der Remote-Endpunkt hat keine Argumente, da TCP ein stream-orientiertes Protokoll ist. Auf der anderen Seite erhalten Sie eine Antwort vom Remote-Host (der Keepalive überhaupt nicht unterstützen muss, nur TCP / IP), ohne Daten und mit dem eingestellten ACK.

Ich würde denken, dass TCP Keepalive effizienter ist, da es innerhalb des Kernels gehandhabt werden kann, ohne dass Daten in den Benutzerbereich übertragen, ein Websocket-Frame analysiert, ein Antwort-Frame erstellt und zur Übertragung an den Kernel zurückgegeben werden muss. Es ist auch weniger Netzwerkverkehr.

Darüber hinaus WebSocketssind ausdrücklich angegeben immer über TCP laufen; Sie sind nicht unabhängig von der Transportschicht, daher ist TCP-Keepalive immer verfügbar:

Das WebSocket-Protokoll ist ein unabhängiges TCP-basiertes Protokoll.

Warum sollte man also jemals WebSocket Ping / Pong anstelle von TCP Keepalive verwenden wollen?