WebSockets ping/pong, почему не TCP keepalive?

WebSockets имеют опцию отправки пингов на другой конец, где другой конец должен отвечать понг.

После получения кадра Ping конечная точка ДОЛЖНА отправить рамку Pong в ответа, если он уже не получил рамку Close. Должно ответьте рамкой Понга, как только это станет практичным.

TCP предлагает нечто подобное в виде keepalive:

[Y] вы отправите своему сверстнику контрольный пакет keepalive без данных в нем и включен флаг ACK. Вы можете сделать это из-за спецификаций TCP/IP, как своего рода дубликат ACK, а удаленная конечная точка не будет иметь никаких аргументов, поскольку TCP - это протокол, ориентированный на поток. С другой стороны, вы получите ответ от удаленного хоста (который не должен поддерживать keepalive вообще, только TCP/IP), без данных и набора ACK.

Я бы подумал, что TCP keepalive более эффективен, потому что он может обрабатываться в ядре без необходимости передавать данные до пользовательского пространства, анализировать фрейм websocket, обрабатывать кадр ответа и передавать его в ядро для коробка передач. Это также снижает сетевой трафик.

Кроме того, WebSockets явно указаны, чтобы всегда работать через TCP; они не являются агрегированными транспортными уровнями, поэтому всегда поддерживается TCP keepalive:

Протокол WebSocket является независимым протоколом TCP.

Итак, почему бы вам когда-нибудь захотеть использовать ping/pong WebSocket вместо TCP keepalive?

Ответ 1

Проблемы с keepalive TCP:

По умолчанию отключено.
Он работает с двухчасовыми интервалами по умолчанию, а не по запросу по протоколу Ping/Pong.
Он работает между прокси, а не от конца до конца.

Ответ 2

Помимо ответа EJP, я думаю, что он также может быть связан с механизмами HTTP-прокси. Соединения Websocket также могут выполняться через прокси-сервер (HTTP). В таких случаях TCP keepalive будет проверять соединение только на прокси, а не на сквозное соединение.

Ответ 3

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

.3.4 Рампы Ping и Pong

Спецификация протокола WebSocket определяет рамки Ping и Pong, которые может использоваться для поддержания жизни, сердечных ударов, зондирования сети, аппаратура задержки и т.д. В настоящее время они не подвергаются воздействию в API.

Пользовательские агенты могут посылать пинговые и незапрошенные кадры с тентом по желанию, для пример в попытке поддерживать сопоставления NAT локальной сети, чтобы обнаружение неудачных подключений или отображение показателей времени ожидания для пользователя. Пользовательские агенты не должны использовать пинг или нежелательные понг, чтобы помочь серверу; предполагается, что серверы будут запрашивать понгсы, когда это необходимо для сервер нуждается.

WebSockets были разработаны с учетом RTC, поэтому, когда я смотрю на функциональность ping/pong, я также вижу способ измерения задержки. Тот факт, что понг должен возвращать ту же полезную нагрузку, что и ping, очень удобно отправлять временную метку, а затем вычислять задержку от клиента к серверу или наоборот.

Ответ 4

TCP keepalive не проходит через веб-прокси. Веб-пинг/понг будет перенаправлен через веб-прокси. TCP keepalive предназначен для контроля соединения между конечными точками TCP. Конечные точки веб-сокетов не равны конечным точкам TCP. Соединение через веб-соединение может использовать несколько TCP-соединений между двумя конечными точками websocket.