WebSockets Ping / Pong, warum nicht TCP Keepalive?

73

WebSockets haben die Möglichkeit , Pings an das andere Ende zu senden, wo das andere Ende mit einem Pong antworten soll.

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

TCP bietet etwas Ähnliches in Form von Keepalive:

[Y] Sie senden Ihrem Peer ein Keepalive-Testpaket ohne Daten und mit aktiviertem ACK-Flag. Sie können dies aufgrund der TCP / IP-Spezifikationen als eine Art doppeltes ACK tun, 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 ACK-Set.

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

Darüber hinaus werden WebSockets explizit so angegeben , dass sie immer über TCP ausgeführt werden. Sie sind nicht transportschichtunabhängig, daher ist TCP Keepalive immer verfügbar:

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

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

tcp  websocket  keep-alive 
— Thomas
quelle

Antworten:

77

Die Probleme mit TCP Keepalive sind:

  1. Es ist standardmäßig deaktiviert.
  2. Es arbeitet standardmäßig in zweistündigen Intervallen anstatt auf Abruf, wie es das Ping / Pong-Protokoll vorsieht.
  3. Es arbeitet eher zwischen Proxys als von Ende zu Ende.
  4. Wie von @DavidSchwartz hervorgehoben, funktioniert es zwischen TCP-Stacks und nicht zwischen den Anwendungen.

Der Vergleich mit WebSockets Ping / Pong ist nicht aussagekräftig. TCP Keepalive erfolgt automatisch und zeitgesteuert, wenn es aktiviert ist, während WebSocket Ping / Pong gemäß den Anforderungen der Anwendung ausgeführt wird.

— Marquis von Lorne
quelle
1
Sie können beide pro Verbindung mit ändern setsockopt(2).
— Thomas
3
@Thomas Sie können das Intervall auf einigen Plattformen ändern. Nicht Windows, FreeBSD, Solaris, ...
— Marquis von Lorne
13
Außerdem macht es das Falsche. Wir möchten wissen, ob die Anwendung am anderen Ende aktiv ist. Da TCP-Keepalives, wie Sie bereits erwähnt haben, im Kernel verwaltet werden, sagen sie uns nicht, ob die Anwendung am anderen Ende aktiv ist.
— David Schwartz
1
@ DavidSchwartz Ich glaube, das ist der wichtigste Grund. Vielleicht eine Antwort daraus machen?
— Ashkan Kh. Nazary
In Ubuntu werden etwa alle 30 Sekunden Keepalive-Bestätigungen von Clients mit Standardeinstellungen angezeigt. Es funktioniert (ich kann eine 40-Sekunden-Zeitüberschreitung in den Remote-Nicht-Ubuntu-Server TCP setzen, und die Verbindung bleibt weiterhin bestehen). Ihr Standpunkt zu übermäßig geschichteten Clients, Proxys usw. ist jedoch ein guter Grund, WebSocket-Ping zu bevorzugen.
— personal_cloud
45

Neben der Antwort von EJP könnte dies auch mit HTTP-Proxy-Mechanismen zusammenhängen. Websocket-Verbindungen können auch über einen (HTTP-) Proxyserver ausgeführt werden. In solchen Fällen überprüft das TCP-Keepalive nur die Verbindung zum Proxy und nicht die End-to-End-Verbindung.

— Matthias247
quelle
1
Ich bin hin und her gerissen zwischen dem Akzeptieren dieser oder der Antwort von @ vtortola, die beide gute Gründe sind, aber deine hat noch eine Gegenstimme, also geht es weiter :)
— Thomas
1
@ Thomas Ich finde es merkwürdig, dass Sie eine Antwort akzeptiert haben, die auf einer anderen vollständigeren Antwort basiert. Hier gibt es mehrere Antworten, die diese Informationen wiederholen, und einige, die vollständiger sind.
— Marquis von Lorne
1
Dein ist ... jetzt. Die Proxy-Sache war der Hauptpunkt, den ich vermisst habe, und das war nicht in Ihrer ursprünglichen Antwort.
— Thomas
@ Thomas Ich spreche von mehreren besseren Antworten, nicht nur von einer.
— Marquis von Lorne
20

http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html#ping-and-pong-frames

.3.4 Ping- und Pong-Frames

Die WebSocket-Protokollspezifikation definiert Ping- und Pong-Frames, die für Keep-Alive, Herzschläge, Netzwerkstatusprüfung, Latenzinstrumentierung usw. verwendet werden können. Diese sind derzeit in der API nicht verfügbar.

Benutzeragenten können nach Bedarf Ping- und unerwünschte Pong-Frames senden, beispielsweise um lokale NAT-Zuordnungen des Netzwerks beizubehalten, fehlgeschlagene Verbindungen zu erkennen oder dem Benutzer Latenzmetriken anzuzeigen . Benutzeragenten dürfen keine Pings oder unerwünschten Pongs verwenden, um den Server zu unterstützen. Es wird davon ausgegangen, dass Server Pongs anfordern, wann immer dies für die Anforderungen des Servers angemessen ist.

WebSockets wurden unter Berücksichtigung von RTC entwickelt. Wenn ich mir also die Ping / Pong-Funktionalität anschaue, sehe ich auch eine Möglichkeit, die Latenz zu messen. Die Tatsache, dass das Pong die gleiche Nutzlast wie das Ping zurückgeben muss, macht es sehr bequem, einen Zeitstempel zu senden und dann die Latenz vom Client zum Server oder umgekehrt zu berechnen.

— vtortola
quelle
18

TCP Keepalive wird nicht über einen Webproxy weitergeleitet. Der Websocket-Ping / Pong wird von über Web-Proxys weitergeleitet. TCP Keepalive dient zur Überwachung einer Verbindung zwischen TCP-Endpunkten. Web-Socket-Endpunkte sind nicht gleich TCP-Endpunkten. Eine Websocket-Verbindung kann mehrere TCP-Verbindungen zwischen zwei Websocket-Endpunkten verwenden.

— mlom
quelle
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.