#AndersenUseful
HTTP обозначает передачу гипертекста и это протокол без состояния. Т.е после выполненного или завершённого запроса, связь между клиентом и сервером полностью потеряна🤓
При каждом новом запросе устанавливается новое TCP соединение, после выполнения запроса - получения ответа - соединение закрывается.
Можно думать об этом, как о подбрасывании монеты:
Вы подбрасываете монету один раз и получаете результат — либо орёл либо решка.
И если мы подбрасываем её снова, то этот результат не имеет ничего общего с предыдущим результатом соединение полностью потеряно после успешного запроса .
В модели HTTP, клиенты, которые запрашивают данные, должны указать действие (метод запроса), чтобы получить сообщение, либо удалить, либо добавить что-то. Это просто сообщает серверу то, что они хотят сделать.
Все эти методы и характеристики запросов помещены в так называемый заголовок, который отправляется через Интернет, чтобы сообщить серверу, что он хочет делать, и сервер также отвечает этим заголовком.
В 2005 году поняли, что эта модель не совсем то, что хотелось.
Ведь важно, чтобы Интернет мог делать больше, чем просто отвечать некоторыми данными и поэтому была изобретена технология, известная как AJAX, что означает асинхронный JavaScript и XML.
Это позволило нам асинхронно отправлять данные на сервер, после первоначального запроса.
С помощью модели, клиент отправляет первоначальный запрос HTML- страницы, на который сервер отвечает, и затем клиент может продолжать делать запросы после этого, и это позволило нам сделать очень много крутых вещей.
Если нам что-то нужно, мы просто можем спросить сервер — нам не нужно обновлять страницу.
НО что произойдёт, если мы захотим сделать что-то, что работает в режиме реального времени? 🤔
Что-то вроде чата или приложения, где я хочу, чтобы пользователи могли мгновенно в режиме реального времени разговаривать друг с другом
Представьте, если бы чат требовал, чтобы вы нажимали, чтобы получить все сообщения, чтобы посмотреть сообщения друзей
Вы бы не хотели сидеть и постоянно нажимать на кнопку чтобы получить все сообщения за весь день.
И в идеале, что мы хотим? Мы хотим модель, в которой мы можем сделать запрос и получить ответ для начальной страницы а затем, если у сервера появились какие-то новые данные, то он может отправить эти данные к нам.
В случае чата приложения, если я отправляю сообщение в групповой чат со всеми своими друзьями, сервер получит это сообщение, а затем
Он такой: "ладно, у меня есть это сообщение, позвольте мне отправить его всем людям, которые хотят знать об этом сообщении". И если они подключены к этому серверу, то тогда он может отправить это сообщение всем кто подключен.
Так это как раз то, что WebSockets и делают.
Веб-сокеты созданы для решения этой наследственной проблемы с HTTP и они определяют этот полнодуплексный двунаправленный канал связи между клиентом и сервером.
Простыми словами, это означает, что клиент и сервер могут разговаривать в реальном времени без необходимости постоянно делать запросы
Если вы хотите сделать ВЕБ-СОКЕТ через Интернет вы отправляете на сервер заголовок, говорящий, хорошо, я хочу перейти с HTTP на WebSockets и он использует то же TCP соединение, которое изначально установил, загружая страницу.
И сервер такой, окей, хорошо, давай обновим — и как только это обновление будет выполнено — клиент и сервер могут непрерывно отправлять данные туда и обратно друг другу без накладных расходов, которые может принести с собой HTTP.
Говоря о производительности, важно помнить, что заголовки отправляются только один раз, во время первоначального рукопожатия, где сервер и клиент соглашаются перейти на WebSokets, то единственное место где заголовки отправляются, остальное — это просто отправка данных туда и обратно, поэтому при отправке данных нет накладных расходов (на установку соединения).
В случае же HTTP у нас постоянно устанавливается новое соединение при каждом запросе.
Плюсы очевидны😉