AV
Браузер может сохранить tcp соединение с сервером, при наличии keep-Alive хедеров
Keep-Alive? Заголовок? В TCP? Нет, не слышал...
Size: a a a
2019 February 03
ŹR
Не вижу, где я написал что хедеры в tcp
AV
Не вижу, где я написал что хедеры в tcp
Значит я не правильно понял
M
можно долго рассуждать. Но я думаю, что tcp - просто передача пакетов. А WS - это язык общения.
Теперь, после завершения фазы рукопожатия, исходное HTTP-соединение заменяется на WebSocket-соединение, которое использует то же самое базовое TCP/IP-соединение. В этот момент и клиент и сервер могут приступать к отправке данных.
(
Теоретически - я не прав, но фактически websocket это tcp
Демагогия пошла
M
да, лучше закрыть тему
ŹR
После хендшейка с практической точки зрения websocket не отличается от tcp
ŹR
Это то что я хотел сказать
ŹR
Понятно что реализации различаются
M
понятно. На этом и остановимся
DV
Дай бог вам здоровья
AV
HTTP 1.1 регламентирует заголовок Connection, при значении которого, установленного клиентом в keep-alive , сервер не должен закрывать соединение после ответа на запрос
AV
После хендшейка с практической точки зрения websocket не отличается от tcp
Ну как не отличается? Он работает поверх TCP
ŹR
И что он привносит? С практической точки зрения? Туда-сюда поток байт, что там что там
ŹR
Да, там заворачивается во всякие хитрые штуки, но смысл не меняется
AV
И что он привносит? С практической точки зрения? Туда-сюда поток байт, что там что там
Ну например ping-pong фреймы
ŹR
Если я не ошибаюсь, они не регламентированы в протоколе, поддерживаются не всеми браузерами и в принципе можно жить без них
ŹR
И некоторые здорово их реализуют на более высоком уровне
AV
Если я не ошибаюсь, они не регламентированы в протоколе, поддерживаются не всеми браузерами и в принципе можно жить без них
Это один из видов управляющих фреймов, которые регламентированы в протоколе
AV
Это один из видов управляющих фреймов, которые регламентированы в протоколе
Точнее два вида )