Вы когда-нибудь задумывались, как работают разные типы приложений для отслеживания местоположения? Как такая программа для отображения положения данного объекта (независимо от того, курьер ли это с пиццей или контейнеровоз) или чат может отображать данные в реальном времени за несколько секунд? Благодаря веб-сокетам, которые позволяют нам создавать функции в реальном времени, устанавливая двустороннее соединение между клиентом и сервером.
В среднем один запрос веб-сокета (с использованием Socket.io) занимает примерно 83 миллисекунды по сравнению со 107 миллисекундами для HTTP-запроса. Это может показаться несущественной разницей, но как только мы осознаем, сколько таких запросов существует, и начнем подсчитывать время, необходимое для множества параллельных запросов, разница во времени становится поразительной.
Сначала давайте посмотрим, как работает традиционное HTTP-соединение, а затем посмотрим, чем соединение через веб-сокет отличается от него.
HTTP-запрос и попытка его улучшения
HTTP-соединение устанавливается, когда клиент отправляет запрос на сервер. Это создает соединение TCP/IP между сервером и клиентом. Затем сервер отправляет ответ клиенту, после чего соединение разрывается. Это означает, что новое соединение должно устанавливаться каждый раз, когда клиент делает новый запрос. На заре Интернета такая модель запроса-ответа имела смысл, но по мере роста потребности в обновлениях в реальном времени потребность в обновлениях в реальном времени становилась все более очевидной, и HTTP-запроса уже было недостаточно. Вот тогда и стали появляться разные способы манипулирования HTTP-запросами.
Эти манипуляции часто называют техникой кометы, так называемой Long polling http (длинный опрос HTTP) – лучший тому пример.
Процесс соединения здесь такой же, как и для традиционного HTTP-запроса, за исключением того, что сервер пытается сохранить соединение клиента как можно дольше. Это делается путем возврата ответа только тогда, когда у сервера есть новые данные для отправки клиенту (или когда истекает время ожидания). Это создает иллюзию, что данные обновляются в реальном времени. Например, длинный опрос используется Facebook и Google.
Как работают веб-сокеты?
Соединение WebSocket начинается с того, что клиент отправляет запрос на сервер. Однако запрос выглядит немного иначе. Вместо запроса, который начинается с http://, у нас есть запрос, который начинается с ws://. Если сервер согласен на соединение, он отправит ответ с кодом состояния 101, который подтверждает, что переключение в протоколе было принято.
На этом этапе между клиентом и сервером было инициировано рукопожатие, что означает, что соединение TCP/IP установлено и остается открытым. Это позволяет сообщениям передаваться между сервером и клиентом двунаправленно с высокой скоростью. Это соединение будет оставаться открытым до тех пор, пока клиент или сервер не решит его разорвать. Технически говоря, соединение WebSocket использует HTTP до первоначального рукопожатия. Затем он просто преобразует HTTP-соединение в соединение WebSocket.
Этот тип соединения часто называют полнодуплексным (более телекоммуникационным термином, описывающим, как работает стационарный телефон). Идея состоит в том, что во время телефонного разговора обе стороны могут разговаривать и быть услышанными одновременно. Таким образом, этот термин соответствует принципу работы соединения WebSocket.
Если вы ищете подходящее решение, то наиболее активно используемые библиотеки Websocket с открытым исходным кодом – это Socket.io, WS, Sockjs, SocketCluster.io, Feathera или Faye-web socket-node.
