WebSockets ping / pong, why not TCP keepalive?

Question

WebSockets have the option of sending pings to the other end, where the other end should respond pong.

After receiving a Ping frame, the endpoint MUST send a Pong frame in response if it has not already received a Close frame. You should answer with the Pong frame as soon as it becomes practical.

TCP offers something similar in the form of keepalive:

[Y] you send your peer a keepalive control packet with no data in it and the ACK flag is turned on. You can do this because of the TCP / IP specifications, as a kind of duplicate ACK, and the remote endpoint will not have any arguments, because TCP is a flow-oriented protocol. On the other hand, you will receive a response from a remote host (which should not support keepalive at all, only TCP / IP), without data and an ACK.

I would think that TCP keepalive is more efficient because it can be processed in the kernel without the need to transfer data to user space, parse the websocket frame, process the response frame and pass it to the kernel for the gearbox. It also reduces network traffic.

In addition, WebSockets are explicitly specified to always work over TCP; they are not aggregated transport layers, so TCP keepalive is always supported:

The WebSocket protocol is an independent TCP protocol.

So why would you ever want to use ping / pong WebSocket instead of TCP keepalive?

Answer 1

Problems with keepalive TCP:

• Disabled by default.
• It works at two-hour intervals by default, and not on request using the Ping / Pong protocol.
• It works between proxies, not end to end.

Answer 2

Besides the EJP response, I think it can also be related to HTTP proxy mechanisms. Websocket connections can also be made through a proxy server (HTTP). In such cases, TCP keepalive will only check the proxy connection, not the end-to-end connection.

Answer 3

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

.3.4 Ping and Pong Ramps

The WebSocket protocol specification defines the Ping and Pong framework that can be used to support life, heartbeats, network sensing, delay equipment , etc. They are not currently exposed in the API.

User agents can send ping and unsolicited frames with an awning at will, for example, in an attempt to maintain NAT mappings of the local network to detect failed connections or display time-out indicators for the user . User agents should not use ping or unwanted pong to help the server; It is assumed that servers will request pongs when necessary for the server needs.

WebSockets were designed with RTC in mind, so when I look at the ping / pong functionality, I also see a way to measure latency. The fact that pong should return the same payload as ping is very convenient to send a timestamp, and then calculate the delay from the client to the server or vice versa.

Answer 4

TCP keepalive does not go through a web proxy. Web ping / pong will be redirected via web proxy. TCP keepalive is designed to control the connection between TCP endpoints. Web socket endpoints are not equal to TCP endpoints. A web connection can use multiple TCP connections between two websocket endpoints.