Соединения WebSocket могут быть установлены только с URI, которые следуют этой схеме. То есть, если вы видите URI со схемой ws:// (или wss:// ), то и клиент, и сервер ДОЛЖНЫ следовать протоколу подключения WebSocket, чтобы следовать спецификации WebSocket.
После того как клиент получает ответ сервера, открывается соединение WebSocket для начала передачи данных.
Я не буду описывать здесь каждую часть протокола кадра. Подробную информацию см. в RFC 6455. Вместо этого я расскажу о наиболее важных моментах, чтобы мы могли лучше понять протокол WebSocket.
Первый бит заголовка WebSocket — это бит Fin. Этот бит устанавливается, если этот кадр является последними данными для завершения этого сообщения.
Эти биты зарезервированы для использования в будущем.
Каждый фрейм имеет код операции, который определяет, как интерпретировать полезные данные этого фрейма.
| Значение кода операции | Описание |
|---|
| 0x00 | Этот фрейм продолжает полезную нагрузку из предыдущего фрейма. |
| 0x01 | Обозначает текстовый фрейм. Текстовые фреймы декодируются сервером в кодировке UTF-8. |
| 0x02 | Обозначает двоичный фрейм. Двоичные кадры доставляются сервером без изменений. |
| 0x03-0x07 | Зарезервировано для будущего использования. |
< td>0x08 | Обозначает, что клиент желает закрыть соединение. |
| 0x09 | Кадр проверки связи. Служит механизмом сердцебиения, гарантируя, что соединение все еще живо. Получатель должен ответить pong. |
| 0x0a | Кадр pong. Служит механизмом сердцебиения, гарантируя, что соединение все еще живо. Получатель должен ответить кадром проверки связи. |
| 0x0b-0x0f | Зарезервировано для будущего использования. |
Установка этого бита в 1 включает маскирование. Веб-сокеты требуют, чтобы вся полезная нагрузка была замаскирована с использованием случайного ключа (маски), выбранного клиентом. Ключ маскирования объединяется с данными полезной нагрузки с помощью операции XOR перед отправкой данных в полезную нагрузку. Эта маскировка не позволяет кешам неправильно интерпретировать кадры WebSocket как кэшируемые данные. Почему мы должны предотвратить кеширование данных WebSocket? Безопасность.
Во время разработки протокола WebSocket было показано, что если развернут скомпрометированный сервер и клиенты подключаются к этому серверу, возможно, что промежуточные прокси-серверы или инфраструктура кэшируют ответы скомпрометированного сервера, чтобы будущие клиенты запрашивали этот сервер. данные получают неверный ответ. Эта атака называется отравление кеша и является результатом того, что мы не можем контролировать, как плохо себя ведут прокси-серверы в дикой природе. Это особенно проблематично при внедрении нового протокола, такого как WebSocket, который должен взаимодействовать с существующей инфраструктурой Интернета.
Длина полезной нагрузки
Поля «Длина полезной нагрузки» и «Расширенная длина полезной нагрузки» используются для кодирования общей длины данных полезной нагрузки для этого кадра. Если данные полезной нагрузки малы (менее 126 байт), длина кодируется в поле Payload len. По мере роста полезной нагрузки мы используем дополнительные поля для кодирования длины полезной нагрузки.
Маскирующий ключ
Как обсуждалось с битом MASK, все кадры, отправляемые клиентом на сервер, маскируются 32-битным значением, которое содержится в кадре. Это поле присутствует, если бит маски установлен в 1, и отсутствует, если бит маски установлен в 0.
Полезные данные
Данные полезной нагрузки включают произвольные данные приложения и любые данные расширения, которые были согласованы между клиентом и сервером. Расширения согласовываются во время первоначального рукопожатия и позволяют расширить протокол WebSocket для дополнительных целей.
Закрытие соединения WebSocket — рукопожатие закрытия WebSocket
Чтобы закрыть соединение WebSocket, отправляется закрывающий кадр (код операции 0x08 ). В дополнение к коду операции кадр закрытия может содержать тело, указывающее причину закрытия. Если какая-либо сторона соединения получает кадр закрытия, она должна отправить кадр закрытия в ответ, и больше данные не должны передаваться по соединению. Как только обе стороны получают кадр закрытия, TCP-соединение разрывается.Сервер всегда инициирует закрытие соединения TCP.
Дополнительные ссылки
Эта статья представляет собой введение в протокол WebSocket и охватывает много вопросов. Тем не менее, полный протокол содержит больше деталей, чем то, что я мог бы вместить в этот пост в блоге. Если вы хотите узнать больше, есть несколько отличных ресурсов на выбор:
![]()
Возьмем пример связи клиент-сервер, есть клиент, который является веб-браузером и сервером, всякий раз, когда мы инициируем соединение между клиентом и сервером, клиент-сервер устанавливает связь и решает создать новое соединение. и это соединение будет поддерживаться до тех пор, пока не будет прервано любым из них. Когда соединение установлено и активно, связь осуществляется с использованием того же канала соединения, пока оно не будет прервано.
![]()
- Веб-приложение реального времени. Веб-приложение реального времени использует веб-сокет для отображения данных на стороне клиента, которые постоянно отправляются внутренним сервером. В WebSocket данные постоянно отправляются/передаются в одно и то же соединение, которое уже открыто, поэтому WebSocket работает быстрее и повышает производительность приложения.
Например. на торговом веб-сайте или при торговле биткойнами для отображения данных о колебаниях и движении цены внутренний сервер постоянно передает клиентскому серверу с помощью канала WebSocket.
- Игровое приложение: в игровом приложении вы можете сосредоточиться на том, что данные постоянно принимаются сервером, и без обновления пользовательского интерфейса они вступят в силу на экране, пользовательский интерфейс автоматически обновляется, даже не устанавливая новое соединение, так что это очень полезно в игровом приложении.
- Приложение для чата. Приложения для чата используют веб-сокеты для установления соединения только один раз для обмена, публикации и рассылки сообщения подписчикам. Он повторно использует одно и то же соединение WebSocket для отправки и получения сообщения, а также для передачи сообщения один к одному.
Примечание: веб-служб RESTful достаточно для получения данных с сервера, если мы загружаем данные только один раз.
![Простое объяснение того, что такое WebSocket]()
Мы живем в мире, где быстрее и общительнее вы выигрываете. Когда речь идет о приложениях, достижение этих двух целей возможно с помощью WebSocket. WebSocket, который обычно называют высокопроизводительным протоколом компьютерной связи, необходим для установления канала связи между сервером и клиентом.
Что это значит и какую роль WebSocket играет в безопасности API, мы рассмотрим в этой статье. Профессионалы, активно занимающиеся разработкой мобильных и веб-приложений, могут почерпнуть подробную информацию из этой статьи.
![защита приложений на aws с помощью валарм]()
Узнайте, как защититься от распространенных проблем с безопасностью API и о стратегиях их устранения, из Руководства по безопасности API 2022 года.
Что такое WebSocket?
Согласно общепринятому определению, WebSocket — это дуплексный протокол, используемый в основном в канале связи клиент-сервер. Он двунаправленный по своей природе, что означает, что связь между клиентом и сервером происходит туда и обратно.
Соединение, установленное с использованием WebSocket, длится до тех пор, пока какая-либо из участвующих сторон не отключит его. Как только одна сторона разорвет соединение, вторая сторона не сможет общаться, так как соединение автоматически разрывается на ее фронте.
![websocket work]()
Зачем нужен веб-сокет и когда его следует избегать?
WebSocket — это важный инструмент связи клиент-сервер, и нужно полностью осознавать его полезность и избегать сценариев, чтобы максимально использовать его потенциал. Это подробно объясняется в следующем разделе.
Наиболее часто WebSocket используется при разработке приложений в реальном времени, где он помогает постоянно отображать данные на стороне клиента. Поскольку внутренний сервер постоянно отправляет эти данные обратно, WebSocket позволяет непрерывно отправлять или передавать эти данные в уже открытом соединении. Использование WebSockets делает такую передачу данных быстрой и увеличивает производительность приложения.
Реальный пример такой утилиты WebSocket — веб-сайт для торговли биткойнами. Здесь WebSocket помогает в обработке данных, которые развернутый внутренний сервер передает клиенту.
Разработчики приложений для чата обращаются к WebSocket за помощью в таких операциях, как однократный обмен сообщениями и публикация/рассылка сообщений. Поскольку для отправки и получения сообщений используется одно и то же соединение WebSocket, общение становится простым и быстрым.
Во время разработки игрового приложения крайне важно, чтобы сервер постоянно получал данные, не запрашивая обновления пользовательского интерфейса. WebSocket достигает этой цели, не нарушая пользовательский интерфейс игрового приложения.
Теперь, когда стало ясно, где следует использовать WebSocket, не забудьте узнать, в каких случаях его следует избегать, и уберечь себя от множества операционных проблем.
![Websocket vs HTTP]()
Как устанавливаются соединения WebSocket?
Вот как устанавливается это соединение:
Заголовок Connection: Upgrade обозначает рукопожатие WebSocket, в то время как Sec-WebSocket-Key содержит случайное значение в кодировке Base64. Это значение произвольно генерируется во время каждого рукопожатия WebSocket. Помимо вышеперечисленного, ключевой заголовок также является частью этого запроса.
Чтобы уточнить, Sec-WebSocket-Version, можно объяснить версию протокола WebSocket, готовую к использованию для клиента.
Заголовок ответа, Sec-WebSocket-Accept, представляет собой изюминку значения, представленного в заголовке запроса Sec-WebSocket-Key. Это связано с конкретной спецификацией протокола и широко используется для защиты от вводящей в заблуждение информации. Другими словами, это повышает безопасность API и не позволяет плохо сконфигурированным серверам создавать ошибки при разработке приложений.
В случае успешного выполнения ранее отправленного запроса будет получен ответ, аналогичный приведенной ниже текстовой последовательности:
Протокол WebSocket
Протокол WebSocket – это тип протокола с фреймами, в котором используются различные дискретные фрагменты данных. Он также развертывает тип кадра, часть данных и длину полезной нагрузки для правильного функционирования. Чтобы иметь подробное представление о протоколе WebSocket, крайне важно знать его строительный блок. Основные биты перечислены ниже.
- Fin Bit — это основной бит WebSocket. Он будет автоматически сгенерирован при установлении соединения.
- Биты RSV1, RSV2, RSV3 — это биты, зарезервированные для дополнительных возможностей.
- Код операции является частью каждого кадра и объясняет процесс интерпретации полезных данных конкретного кадра. Некоторые из распространенных значений кода операции: 0x00, 0x0, 0x02, 0x0a, 0x08 и многие другие.
- Бит маски активируется, когда один бит установлен на 1.
WebSocket требует использования случайного ключа, выбранного клиентом, для всех данных полезной нагрузки. Ключ маскировки в сочетании с данными полезной нагрузки помогает совместно использовать данные полезной нагрузки в операции XOR. Это имеет большое значение с точки зрения безопасности API приложения, поскольку маскирование предотвращает неправильную интерпретацию кэша или отравление кэша.
Давайте теперь подробно разберем его важные компоненты:
Длина полезной нагрузки
Это используется для кодирования общей длины полезных данных в WebSocket. Payload len отображается, когда длина закодированных данных меньше 126 байт. Как только длина данных полезной нагрузки превышает 126 байт, для описания длины полезной нагрузки используются дополнительные поля.
Маскирующий ключ
Каждый кадр, отправляемый клиентом на сервер, маскируется 32-битным значением. Ключ маскирования отображается, когда бит маски равен 1. В случае, если бит маски равен 0, ключ маскирования будет равен нулю.
Полезные данные
Все виды произвольных данных приложения и данных расширения называются полезными данными. Клиент и серверы используют эти данные для согласования и используются в ранних рукопожатиях WebSocket.
Заключение
Для разработчиков это скрытое благословение, поскольку оно помогает обеспечить безопасность API и открывает совершенно новый мир возможностей после подключения к различным внешним библиотекам. Попробуйте свои традиционные протоколы связи и выясните различия самостоятельно. А также не забывайте о безопасности, попробуйте надежное решение от Валарм - API Security Platform
![Malte Ubl]()
![Эйдзи Китамура]()
Проблема: соединения клиент-сервер и сервер-клиент с малой задержкой
Знакомство с WebSocket: внедрение сокетов в Интернет
Спецификация WebSocket определяет API, устанавливающий "сокетные" соединения между веб-браузером и сервером.Проще говоря: между клиентом и сервером существует постоянное соединение, и обе стороны могут начать отправку данных в любое время.
Начало работы
Вы открываете соединение WebSocket, просто вызывая конструктор WebSocket:
Немедленное присоединение некоторых обработчиков событий к соединению позволяет узнать, когда соединение открыто, получены входящие сообщения или возникла ошибка.
Второй аргумент принимает необязательные подпротоколы. Это может быть строка или массив строк. Каждая строка должна представлять имя подпротокола, и сервер принимает только один из переданных подпротоколов в массиве. Принятый подпротокол можно определить, обратившись к свойству протокола объекта WebSocket.
Имена подпротокола должны быть одним из зарегистрированных имен подпротоколов в реестре IANA. В настоящее время по состоянию на февраль 2012 года зарегистрировано только одно имя подпротокола (мыло).
Взаимодействие с сервером
Как только у нас будет соединение с сервером (когда запускается событие открытия), мы можем начать отправку данных на сервер, используя метод send('ваше сообщение') в объекте соединения. Раньше он поддерживал только строки, но в последней спецификации теперь он также может отправлять двоичные сообщения. Для отправки двоичных данных можно использовать объект Blob или ArrayBuffer.
Кроме того, сервер может отправлять нам сообщения в любое время. Всякий раз, когда это происходит, срабатывает обратный вызов onmessage. Обратный вызов получает объект события, а фактическое сообщение доступно через свойство данных.
В последней спецификации WebSocket также может получать двоичные сообщения. Двоичные кадры могут быть получены в формате Blob или ArrayBuffer. Чтобы указать формат полученного двоичного файла, установите для свойства binaryType объекта WebSocket значение «blob» или «arraybuffer». Формат по умолчанию — «блоб». (Вам не нужно выравнивать параметр binaryType при отправке.)
Еще одна недавно добавленная функция WebSocket – расширения. Используя расширения, можно будет отправлять сжатые, мультиплексированные кадры и т. д. Вы можете найти принятые сервером расширения, изучив свойство extensions объекта WebSocket после события open. По состоянию на февраль 2012 г. официально опубликованных спецификаций расширений еще нет.
Общение между источниками
Поскольку это современный протокол, связь между источниками встроена прямо в WebSocket. Хотя вам по-прежнему следует убедиться, что вы общаетесь только с клиентами и серверами, которым вы доверяете, WebSocket обеспечивает связь между сторонами в любом домене. Сервер решает, сделать ли его службу доступной для всех клиентов или только для тех, которые находятся в наборе четко определенных доменов.
Прокси-серверы
Используйте WebSockets сегодня
Сторона сервера
Реализации на стороне сервера
Версии протокола
Сетевой протокол (рукопожатие и передача данных между клиентом и сервером) для WebSocket теперь RFC6455. Последние версии Chrome и Chrome для Android полностью совместимы с RFC6455, включая обмен двоичными сообщениями. Кроме того, Firefox будет совместим с версией 11, а Internet Explorer — с версией 10. Вы по-прежнему можете использовать более старые версии протокола, но это не рекомендуется, поскольку известно, что они уязвимы. Если у вас есть серверные реализации для более старых версий протокола WebSocket, мы рекомендуем вам обновить их до последней версии.
Случаи использования
![1 Что такое WebSockets Image=]()
Введите веб-сокеты
Google Chrome стал первым браузером, включившим стандартную поддержку WebSocket в 2009 году. RFC 6455 — протокол WebSocket — был официально опубликован в Интернете в 2011 году. Протокол WebSocket и API WebSocket стандартизированы W3C и IETF, и поддержка в разных браузерах очень распространена.
Как работают соединения WebSocket
Прежде чем клиент и сервер смогут обмениваться данными, они должны использовать уровень TCP (протокол управления транспортом) для установления соединения. WebSockets эффективно работают как транспортный уровень поверх TCP.
Причины использования веб-сокетов для связи в реальном времени
Веб-сокеты обеспечивают обновления в режиме реального времени и открытые каналы связи.
Веб-сокеты совместимы с HTML5 и обеспечивают обратную совместимость со старыми HTML-документами. Поэтому они поддерживаются всеми современными веб-браузерами — Google Chrome, Mozilla Firefox, Apple Safari и другими.
WebSockets также совместимы между платформами — Android, iOS, веб-приложениями и настольными приложениями.
К одному серверу может быть открыто несколько подключений WebSocket одновременно, и даже может быть несколько подключений к одному и тому же клиенту, что открывает двери для масштабируемости.
WebSockets могут выполнять потоковую передачу через множество прокси-серверов и брандмауэров.
Существует множество ресурсов и руководств с открытым исходным кодом для включения WebSockets в приложение, например, библиотека Javascript Socket.io.
![]()
Мысли PubNub о WebSockets и длительном опросе
PubNub не зависит от протокола, но в наших текущих операциях мы обнаружили, что длительные опросы на самом деле лучше всего подходят для большинства случаев использования. Частично это связано с обслуживанием и поддержкой, необходимыми для масштабирования WebSockets, а также с потенциальными проблемами, которые могут возникнуть, когда вы не можете легко определить отключение. Веб-сокеты — отличный инструмент, но долгий опрос надежно работает в любой ситуации.
PubNub использует длительный опрос для обеспечения надежности, безопасности и масштабируемости во всех сетевых средах, а не только в большинстве. Длительный опрос может быть столь же эффективным, как и WebSockets, во многих реализациях реального времени в реальном времени. На самом деле, мы разработали метод эффективного длинного опроса, написанный на C и с несколькими оптимизациями ядра для масштабирования.
PubNub – это платформа для общения в режиме реального времени, обеспечивающая основу для аутентичного виртуального взаимодействия, например обновлений в реальном времени, чата в приложении, push-уведомлений и т. д. Структура строительных блоков нашей платформы позволяет включать дополнительные функции, такие как присутствие, рабочие панели или геолокация. PubNub также упрощает масштабирование, особенно по сравнению с платформами сокетов, такими как Socket.io или SocksJS.
Обзор
Подводя итог, можно сказать, что протокол WebSockets – очень полезный протокол для создания функций реального времени в веб-, мобильных и настольных версиях, но он не является универсальным подходом. WebSockets — это всего лишь один инструмент, который вписывается в более широкий арсенал при разработке приложений, основанных на обмене данными в реальном времени. Можно построить базовый протокол WebSocket и включить другие методы, такие как SSE или длительный опрос, и создать еще лучшее, более масштабируемое приложение реального времени.Проблема в том, что с недостатками может быть трудно справиться, если вы еще не являетесь экспертом в создании систем реального времени.
Использование PubNub значительно экономит время на разработку и расходы на обслуживание, ускоряя время выхода на рынок и упрощая то, что вашей команде инженеров потребуется для разработки, управления и роста.
Если вы заинтересованы в использовании PubNub для создания и запуска вашего приложения реального времени, свяжитесь с нашей командой здесь.
Читайте также:
. Продолжительный опрос может показаться интенсивным на стороне сервера, так как он требует непрерывных ресурсов для удержания соединения открытым, но он использует гораздо меньше, чем повторная отправка запросов на опрос.</p>
<p><img class=)
