listado - WebSockets ping/pong, ¿por qué no TCP keepalive?

tcp ports range

Question

WebSockets tiene la opción de enviar pings al otro extremo, donde se supone que el otro extremo responde con un pong.

Al recibir una trama Ping, un punto final DEBE enviar una trama Pong en respuesta, a menos que ya haya recibido una trama Cerrar. DEBE responder con el marco Pong tan pronto como sea práctico.

TCP ofrece algo similar en forma de keepalive:

[Y] le envía a su compañero un paquete de sonda de actividad sin datos y el indicador ACK está activado. Puede hacer esto debido a las especificaciones de TCP / IP, como una especie de ACK duplicado, y el punto final remoto no tendrá argumentos, ya que TCP es un protocolo orientado a la transmisión. Por otro lado, recibirá una respuesta del host remoto (que no necesita ser compatible con keepalive, solo TCP / IP), sin datos y el ACK establecido.

Creo que TCP keepalive es más eficiente, ya que puede manejarse dentro del kernel sin la necesidad de transferir datos al espacio del usuario, analizar un marco websocket, crear un marco de respuesta y devolverlo al kernel para su transmisión. También es menos tráfico de red.

Además, los WebSockets se especifican explícitamente para ejecutarse siempre sobre TCP; no son agnósticos de la capa de transporte, por lo que TCP keepalive está siempre disponible:

El protocolo WebSocket es un protocolo independiente basado en TCP.

Entonces, ¿por qué alguien querría usar WebSocket ping / pong en lugar de TCP keepalive?

Answer 1

Además de la respuesta de EJP, creo que también podría estar relacionado con los mecanismos de proxy HTTP. Las conexiones de Websocket también pueden ejecutarse a través de un servidor proxy (HTTP). En tales casos, el keepalive de TCP solo verificará la conexión al proxy y no a la conexión de extremo a extremo.

Answer 2

Los problemas con TCP keepalive son:

1. Está apagado por defecto.
2. Funciona a intervalos de dos horas de forma predeterminada, en lugar de bajo demanda según lo que proporciona el protocolo Ping / Pong.
3. Opera entre proxies en lugar de extremo a extremo.

Answer 3

TCP keepalive no se pasa a través de un proxy web. El websocket ping / pong se reenviará a través de proxies web. TCP keepalive está diseñado para supervisar una conexión entre puntos finales TCP. Los puntos finales de socket web no son iguales a los puntos TCP. Una conexión websocket puede usar varias conexiones TCP entre dos puntos finales websocket.

Answer 4

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

.3.4 cuadros de ping y pong

La especificación del protocolo WebSocket define las tramas Ping y Pong que se pueden usar para mantener vivo, los latidos del corazón, el sondeo del estado de la red, la instrumentación de latencia , etc. Estos no están actualmente expuestos en la API.

Los agentes de usuario pueden enviar marcos ping y ping no solicitados, según lo desee, por ejemplo, en un intento de mantener las asignaciones de NAT de la red local, detectar conexiones fallidas o mostrar métricas de latencia al usuario . Los agentes de usuario no deben usar pings o pongs no solicitados para ayudar al servidor; se supone que los servidores solicitarán pongs cuando sea apropiado para las necesidades del servidor.

Los WebSockets se han desarrollado pensando en RTC, por lo que cuando veo la funcionalidad ping / pong, también veo una forma de medir la latencia. El hecho de que el pong debe devolver la misma carga útil que el ping, hace que sea muy conveniente enviar una marca de hora y luego calcular la latencia del cliente al servidor o viceversa.