Пинг / понг WebSockets, почему не TCP keepalive?
У WebSockets есть возможность отправки пингов на другой конец, где другой конец должен отвечать понгом.
После получения кадра Ping конечная точка ДОЛЖНА отправлять кадр Pong в ответ, если она уже не приняла кадр Close. Он ДОЛЖЕН ответить рамкой Pong, как только это станет практически возможным.
TCP предлагает нечто подобное в форме keepalive:
[Y] Вы отправляете своему партнеру пакет проверки активности, в котором нет данных, а флаг ACK включен. Вы можете сделать это из-за спецификаций TCP/IP, как своего рода дубликат ACK, и удаленная конечная точка не будет иметь аргументов, так как TCP является потоково-ориентированным протоколом. С другой стороны, вы получите ответ от удаленного хоста (который вообще не должен поддерживать keepalive, только TCP/IP), без данных и установленного ACK.
Я думаю, что TCP keepalive более эффективен, потому что он может обрабатываться в ядре без необходимости передавать данные в пространство пользователя, анализировать кадр веб-сокета, создавать кадр ответа и передавать его обратно в ядро для передачи. Это также меньше сетевого трафика.
Кроме того, WebSockets явно указываются, чтобы всегда работать через TCP; они не зависят от транспортного уровня, поэтому TCP keepalive всегда доступен:
Протокол WebSocket является независимым протоколом на основе TCP.
Так почему же нужно использовать пинг / понг WebSocket вместо поддержки активности TCP?
5 ответов
Проблемы с TCP keepalive:
- По умолчанию он выключен.
- По умолчанию он работает с двухчасовым интервалом, а не по требованию, как обеспечивает протокол Ping/Pong.
- Он работает между прокси, а не сквозным.
Помимо ответа EJP, я думаю, что это также может быть связано с механизмами HTTP-прокси. Соединения Websocket также могут проходить через (HTTP) прокси-сервер. В таких случаях протокол поддержки активности TCP будет проверять только соединение с прокси, а не сквозное соединение.
http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html
.3.4 Рамки для пинг-понга
Спецификация протокола WebSocket определяет кадры Ping и Pong, которые можно использовать для поддержания активности, сердцебиения, проверки состояния сети, измерения задержек и т. Д. В настоящее время они не представлены в API.
Пользовательские агенты могут отправлять ping и незапрошенные кадры pong по желанию, например, в попытке поддерживать сопоставления NAT локальной сети, обнаруживать неудачные соединения или отображать метрики задержки для пользователя. Пользовательские агенты не должны использовать пинг или нежелательные понги для помощи серверу; Предполагается, что серверы будут запрашивать понг всякий раз, когда это соответствует потребностям сервера.
WebSockets были разработаны с учетом RTC, поэтому, когда я смотрю на функциональность пинг-понга, я также вижу способ измерения задержки. Тот факт, что понг должен возвращать ту же полезную нагрузку, что и пинг, делает очень удобным отправку метки времени, а затем вычисляет задержку от клиента к серверу или наоборот.
TCP keepalive не передается через веб-прокси. Пинг / понг веб-сокета будет пересылаться через веб-прокси. Протокол TCP keepalive предназначен для контроля соединения между конечными точками TCP. Конечные точки веб-сокета не равны конечным точкам TCP. Соединение websocket может использовать несколько TCP-соединений между двумя конечными точками websocket.
обновление: хотя существуют реализации HTTP/1.1 через UDP, протокол веб-сокета НЕ работает через UDP (для этого требуется надежный транспорт).
оригинальный (неправильный) ответ следующий:
В дополнение ко всем ответам, которые указывают на действительные проблемы с поддержкой активности TCP (в основном, на то, что он не проходит через прокси-серверы), имейте в виду, что HTTP (и WebSocket в расширении) был разработан для работы также через UDP.