WebSockets пинг-понг, почему бы не TCP keepalive?

Question

WebSockets пинг-понг, почему бы не TCP keepalive?

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

после получения кадра Ping конечная точка должна отправить кадр Pong
ответ, если он уже не получил близкий кадр. Он должен
ответьте с рамкой понг, как только это практично.

TCP предложит нечто подобное в форме keepalive:

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

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

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

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

Так почему же вы хотите использовать WebSocket ping / pong вместо TCP keepalive?

892 4

tcp websocket keep-alive

4 ответов:

Comments

Ничего не найдено.

user207421 · Accepted Answer · 2015-11-18 11:21:48

проблемы с TCP keepalive являются:

по умолчанию он выключен.

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

он работает между прокси, а не от начала до конца.

Matthias247 · Accepted Answer · 2014-04-23 12:54:35

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

vtortola · Accepted Answer · 2014-04-23 13:20:20

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

.3.4 рамки для пинг-понга

спецификация протокола WebSocket определяет рамки для пинг-понга, которые может использоваться для поддержания жизни, сердцебиения, зондирования состояния сети, КИПиА задержки и так далее. В настоящее время не подвергается в API.

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

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

mlom · Accepted Answer · 2014-10-15 13:24:30

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