Войти
WebSocket - это компьютерный протокол связи, обеспечивающий полнодуплексный канал связи через одиночное TCP соединение. Протокол WebSocket был стандартизирован IETF как RFC 6455 в 2011 году, а WebSocket API в Web IDL стандартизируется W3C.
WebSocket отличается от HTTP. Оба протокола расположены на уровне 7 в модели OSI и зависят от TCP на уровне 4. Хотя они разные, в RFC 6455 указано, что WebSocket "предназначен для работы через HTTP-порты 443. и 80, а также для поддержки HTTP-прокси и посредников », что делает его совместимым с протоколом HTTP. Для достижения совместимости WebSocket рукопожатие использует заголовок HTTP Upgrade для перехода с протокола HTTP на протокол WebSocket.
Протокол WebSocket обеспечивает взаимодействие между веб-браузером (или другим клиентским приложением) и веб-сервером с меньшими затратами, чем полудуплексные альтернативы, такие как HTTP-опрос, облегчение передачи данных в реальном времени с сервера и на сервер. Это стало возможным благодаря предоставлению сервером стандартизованного способа отправки контента клиенту без предварительного запроса клиента и возможности передачи сообщений туда и обратно при сохранении соединения. Таким образом, между клиентом и сервером может происходить двусторонний диалог. Связь обычно осуществляется через TCP порт номер 443 (или 80 в случае незащищенных соединений), что является преимуществом для тех сред, которые блокируют не-веб-подключения к Интернету с помощью межсетевого экрана. Аналогичная двусторонняя связь между браузером и сервером была достигнута нестандартными способами с использованием временных технологий, таких как Comet.
. Большинство браузеров поддерживают протокол, включая Google Chrome, Microsoft Edge, Internet Explorer, Firefox, Safari и Opera.
В отличие от HTTP, WebSocket обеспечивает полнодуплексную связь. Кроме того, WebSocket позволяет передавать потоки сообщений поверх TCP. Только TCP имеет дело с потоками байтов, не имеющими внутренней концепции сообщения. До WebSocket полнодуплексная связь через порт 80 была возможна с использованием каналов Comet ; однако реализация Comet нетривиальна и из-за накладных расходов TCP и HTTP-заголовка неэффективна для небольших сообщений. Протокол WebSocket направлен на решение этих проблем без ущерба для предположений безопасности сети.
Спецификация протокола WebSocket определяет ws(WebSocket) и wss(WebSocket Secure) как две новые схемы универсального идентификатора ресурса (URI), которые используются для незашифрованных и зашифрованных соединений соответственно. Помимо имени схемы и фрагмента (т.е. #не поддерживается), остальные компоненты URI определены для использования общего синтаксиса URI.
Использование инструментов разработчика браузера, разработчики могут проверять рукопожатие WebSocket, а также фреймы WebSocket.
WebSocket впервые упоминался как TCPConnection в спецификации HTML5 как заполнитель для TCP API сокетов. В июне 2008 года Майкл Картер провел серию дискуссий, в результате которых была разработана первая версия протокола, известная как WebSocket.
Название «WebSocket» было придумано Яном Хиксоном и Майклом. Вскоре после этого Картер сотрудничал в чате IRC #whatwg, а впоследствии был автором для включения в спецификацию HTML5 Яном Хиксоном и объявлен в блоге cometdaily Майклом Картером. В декабре 2009 года Google Chrome 4 стал первым браузером, в котором была реализована полная поддержка стандарта, с включенным по умолчанию WebSocket. Впоследствии разработка протокола WebSocket была перенесена из группы W3C и WHATWG в IETF в феврале 2010 года, а авторами двух редакций был Ян Хиксон.
После того, как протокол был отправлен и активирован по умолчанию во многих браузерах RFC был завершен под руководством Яна Фетте в декабре 2011 года.
Безопасная версия протокола WebSocket реализована в Firefox 6, Safari 6, Google Chrome 14, Opera 12.10 и Internet Explorer 10. В подробном отчете о наборе тестов протоколов указано соответствие этих браузеров определенным аспектам протокола.
Более старая, менее безопасная версия протокола была реализована в Opera 11 и Safari 5, а также мобильная версия Safari в iOS 4.2. Браузер BlackBerry в OS7 реализует WebSockets. Из-за уязвимостей он был отключен в Firefox 4 и 5, а также в Opera 11.
| Протокол, версия | Дата черновика | Internet Explorer | Firefox (ПК) | Firefox (Android) | Chrome (ПК, мобильный) | Safari (Mac, iOS) | Opera (ПК, мобильный) | Браузер Android |
|---|---|---|---|---|---|---|---|---|
| hixie-75 | 4 февраля 2010 г. | 4 | 5.0.0 | |||||
| hixie-76. hybi-00 | 6 мая 2010 г.. май 23, 2010 | 4.0 (отключено) | 6 | 5.0.1 | 11.00 (отключено) | |||
| hybi-07, v7 | 22 апреля 2011 года | 6 | ||||||
| hybi-10, v8 | 11 июля 2011 г. | 7 | 7 | 14 | ||||
| RFC 6455, v13 | декабрь 2011 г. | 10 | 11 | 11 | 16 | 6 | 12.10 | 4.4 |
Nginx поддерживает WebSockets с 2013 года, реализована в версии 1.3.13, включая работу в качестве обратного прокси и балансировщика нагрузки Приложения WebSocket.
Службы IIS добавили поддержку WebSockets в версии 8, которая была выпущена с Windows Server 2012.
Чтобы установить соединение WebSocket, клиент отправляет запрос подтверждения связи WebSocket, для которого сервер возвращает ответ подтверждения связи WebSocket, как показано в примере ниже.
Запрос клиента (как и в HTTP, каждая строка заканчивается на \r\n , и в конце должна быть дополнительная пустая строка):
GET / chat HTTP / 1.1 Хост: server.example.com Обновление: websocket Подключение: Обновление Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw == Sec-WebSocket-Protocol: чат, суперчат Sec-WebSocket-Version: 13 Источник: http: // example. com
Ответ сервера:
HTTP / 1.1 101 Обновление протоколов коммутации: подключение к веб-сокету: обновление Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk = Sec-WebSocket-Protocol: chat
Рукопожатие начинается с запроса / ответа HTTP позволяя серверам обрабатывать HTTP-соединения, а также соединения WebSocket на одном и том же порте. Как только соединение установлено, связь переключается на двунаправленный двоичный протокол, который не соответствует протоколу HTTP.
В дополнение к заголовкам Upgradeклиент отправляет заголовок Sec-WebSocket-Key, содержащий случайные байты в кодировке base64, а сервер отвечает хешем ключа в заголовке Sec-WebSocket-Accept. Это предназначено для предотвращения caching прокси повторной отправки предыдущего сеанса связи WebSocket и не обеспечивает никакой аутентификации, конфиденциальности или целостности. Функция хеширования добавляет фиксированную строку 258EAFA5-E914-47DA-95CA-C5AB0DC85B11(UUID ) к значению из заголовка Sec-WebSocket-Key(который не декодируется из base64), применяет хэш-функцию SHA-1 и кодирует результат с помощью base64.
После установления соединения клиент и сервер могут отправлять данные WebSocket или текст кадры назад и вперед в полнодуплексном режиме . Данные минимально кадрированы, с небольшим заголовком, за которым следует полезная нагрузка. Передачи через WebSocket описываются как «сообщения», где одно сообщение может быть разделено на несколько кадров данных. Это может позволить отправлять сообщения, в которых доступны начальные данные, но полная длина сообщения неизвестна (он отправляет один фрейм данных за другим, пока не будет достигнут конец и помечен битом FIN). С расширениями протокола это также можно использовать для мультиплексирования нескольких потоков одновременно (например, чтобы избежать монополизации использования сокета для одной большой полезной нагрузки).
В отличие от обычного перекрестного HTTP-запросы домена, запросы WebSocket не ограничиваются политикой одинакового происхождения. Поэтому серверы WebSocket должны проверять заголовок "Origin" на соответствие ожидаемым источникам во время установления соединения, чтобы избежать атак межсайтового перехвата WebSocket (аналогично подделке межсайтовых запросов ), что может быть возможно при подключении аутентифицирован с помощью файлов cookie или HTTP-аутентификации. Лучше использовать токены или аналогичные механизмы защиты для аутентификации соединения WebSocket, когда конфиденциальные (частные) данные передаются через WebSocket. Живой пример уязвимости был замечен в 2020 году в виде Cable Haunt.
реализации протокола WebSocket, который пытается определить, настроен ли пользовательский агент для использования прокси-сервер при подключении к целевому хосту и порту и, если это так, использует метод HTTP CONNECT для настройки постоянного туннеля.
Хотя сам протокол WebSocket не знает о прокси-серверах и брандмауэрах, он поддерживает HTTP-совместимое рукопожатие, что позволяет HTTP-серверам совместно использовать свои порты HTTP и HTTPS по умолчанию (443 и 80) со шлюзом или сервером WebSocket. Протокол WebSocket определяет префиксы ws: // и wss: // для обозначения соединений WebSocket и WebSocket Secure соответственно. Обе схемы используют механизм HTTP-обновления для обновления до протокола WebSocket. Некоторые прокси-серверы прозрачны и отлично работают с WebSocket; другие будут препятствовать правильной работе WebSocket, что приведет к сбою соединения. В некоторых случаях может потребоваться дополнительная конфигурация прокси-сервера, и некоторые прокси-серверы могут потребовать обновления для поддержки WebSocket.
Если незашифрованный трафик WebSocket проходит через явный или прозрачный прокси-сервер без поддержки WebSockets, соединение, скорее всего, не удастся.
Если используется зашифрованное соединение WebSocket, то используется Transport Layer Security (TLS) в соединении WebSocket Secure гарантирует выдачу команды HTTP CONNECT, когда браузер настроен на использование явного прокси-сервера. Это устанавливает туннель, который обеспечивает низкоуровневую сквозную TCP-связь через HTTP-прокси между клиентом WebSocket Secure и сервером WebSocket. В случае прозрачных прокси-серверов браузер не знает о прокси-сервере, поэтому HTTP CONNECT не отправляется. Однако, поскольку проводной трафик зашифрован, промежуточные прозрачные прокси-серверы могут просто пропускать зашифрованный трафик, поэтому гораздо больше шансов, что соединение WebSocket будет успешным, если используется WebSocket Secure. Использование шифрования сопряжено с расходами на ресурсы, но часто обеспечивает наивысший уровень успеха, поскольку оно будет проходить через защищенный туннель.
Черновик середины 2010 г. (версия hixie-76) нарушил совместимость с обратными прокси-серверами и шлюзами, включив восемь байтов ключевых данных после заголовков, но не объявив эти данные в Content-Length: 8заголовок. Эти данные не пересылались всеми промежуточными звеньями, что могло привести к сбою протокола. Более поздние черновики (например, hybi-09) помещают ключевые данные в заголовок Sec-WebSocket-Key, решая эту проблему.
