WikiDer > WebSocket

WebSocket

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[1] перейти с протокола HTTP на протокол WebSocket.

Протокол WebSocket обеспечивает взаимодействие между веб-браузер (или другое клиентское приложение) и веб сервер с меньшими накладными расходами, чем полудуплексные альтернативы, такие как HTTP-опрос, облегчая передачу данных в реальном времени от и к серверу. Это стало возможным за счет предоставления серверу стандартизированного способа отправки содержимого клиенту без предварительного запроса клиента и разрешения передачи сообщений туда и обратно при сохранении соединения. Таким образом, между клиентом и сервером может происходить двусторонний диалог. Связь обычно осуществляется через TCP. порт номер 443 (или 80 в случае незащищенных подключений), который полезен для тех сред, которые блокируют не-веб-подключения к Интернету с использованием брандмауэр. Аналогичная двусторонняя связь между браузером и сервером была достигнута нестандартными способами с использованием временных технологий, таких как Комета.

Большинство браузеров поддерживают протокол, в том числе Гугл Хром, Microsoft Edge, Internet Explorer, Fire Fox, Сафари и Опера.

Обзор

В отличие от HTTP, WebSocket обеспечивает полнодуплексную связь.[2][3]Кроме того, WebSocket позволяет передавать потоки сообщений поверх TCP. Только TCP имеет дело с потоками байтов, не имеющими внутренней концепции сообщения. До WebSocket полнодуплексная связь через порт 80 была доступна с использованием Комета каналы; однако реализация Comet нетривиальна и из-за накладных расходов TCP и HTTP-заголовка неэффективна для небольших сообщений. Протокол WebSocket направлен на решение этих проблем без ущерба для предположений безопасности сети.

Спецификация протокола WebSocket определяет WS (WebSocket) и wss (WebSocket Secure) как два новых единый идентификатор ресурса (URI) схемы[4] которые используются для незашифрованных и зашифрованных соединений соответственно. Помимо названия схемы и фрагмент (т.е. # не поддерживается), остальные компоненты URI определены для использования Общий синтаксис URI.[5]

Используя инструменты разработчика браузера, разработчики могут проверять квитирование WebSocket, а также фреймы WebSocket.[6]

История

WebSocket впервые упоминался как TCPConnection в HTML5 спецификация в качестве заполнителя для API сокетов на основе TCP.[7] В июне 2008 года серию дискуссий возглавил Майкл Картер в результате появилась первая версия протокола, известная как WebSocket.[8]

Название «WebSocket» было придумано Яном Хиксоном и Майклом Картером вскоре после этого в результате совместной работы в чате IRC #whatwg,[9] и впоследствии был написан для включения в спецификацию HTML5 Яном Хиксоном и объявлен в блоге cometdaily Майклом Картером.[10] В декабре 2009 года Google Chrome 4 стал первым браузером, в котором была реализована полная поддержка стандарта, с включенным по умолчанию WebSocket.[11] Впоследствии разработка протокола WebSocket была перенесена из W3C и WHATWG группа в IETF в феврале 2010 года, и автор двух редакций под руководством Яна Хиксона.[12]

После того, как протокол был отправлен и включен по умолчанию в нескольких браузерах, RFC был завершен при Яне Фетте в декабре 2011 года.[13]

Реализация браузера

Безопасная версия протокола WebSocket реализована в Firefox 6,[14] Safari 6, Google Chrome 14,[15] Опера 12.10 и Internet Explorer 10.[16] Подробный отчет о комплекте тестов протокола[17] перечисляет соответствие этих браузеров определенным аспектам протокола.

Более старая, менее безопасная версия протокола была реализована в Opera 11 и Сафари 5, а также мобильная версия Safari в iOS 4.2.[18] Браузер BlackBerry в OS7 реализует WebSockets.[19] Из-за уязвимостей он был отключен в Firefox 4 и 5,[20] и Opera 11.[21]

Статус реализации
Протокол, версияДата проектаInternet ExplorerFire Fox[22] (ПК)Firefox (Android)Chrome (ПК, мобильный)Safari (Mac, iOS)Opera (ПК, мобильный)Браузер Android
хикси-754 февраля 2010 г.45.0.0
хикси-76
hybi-00		6 мая 2010 г.
23 мая 2010 г.		4.0 (отключено)65.0.111.00 (отключено)
hybi-07, v722 апреля 2011 г.6[23][а]
hybi-10, v811 июля 2011 г.7[25][а]714[26]
RFC 6455, v13Декабрь 2011 г.10[27]111116[28]612.10[29]4.4

Реализация веб-сервера

Nginx поддерживает WebSockets с 2013 года, реализовано в версии 1.3.13 [30] в том числе действует как обратный прокси-сервер и балансировщик нагрузки приложений WebSocket.[31]

Информационные службы Интернета добавлена ​​поддержка WebSockets в версии 8, выпущенной с Windows Server 2012.[32]

Рукопожатие протокола

Чтобы установить соединение WebSocket, клиент отправляет запрос установления связи WebSocket, для которого сервер возвращает ответ подтверждения связи WebSocket, как показано в примере ниже.[33]

Запрос клиента (как в HTTP, каждая строка заканчивается на г п и в конце должна быть лишняя пустая строка):

ПОЛУЧАТЬ /чат HTTP/1.1Хозяин: server.example.comОбновление: веб-сокетСвязь: ОбновлениеSec-WebSocket-ключ: x3JJHMbDL1EzLkh9GBhXDw ==Sec-WebSocket-Протокол: чат, суперчатSec-WebSocket-Версия: 13Источник: http://example.com

Ответ сервера:

HTTP/1.1 101 Переключение протоколовОбновление: веб-сокетСвязь: ОбновлениеSec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk =Sec-WebSocket-Протокол: чат

Рукопожатие начинается с HTTP-запроса / ответа, что позволяет серверам обрабатывать HTTP-соединения, а также соединения WebSocket на одном и том же порте. Как только соединение установлено, связь переключается на двунаправленный двоичный протокол, который не соответствует протоколу HTTP.

В добавление к Обновление заголовки, клиент отправляет Sec-WebSocket-ключ заголовок, содержащий base64-кодированные случайные байты, и сервер отвечает хэш ключа в Sec-WebSocket-Accept заголовок. Это предназначено для предотвращения кеширование доверенное лицо от повторной отправки предыдущего разговора WebSocket,[34] и не обеспечивает аутентификации, конфиденциальности или целостности. Функция хеширования добавляет фиксированную строку 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 (а UUID) до значения из Sec-WebSocket-ключ заголовок (который не декодируется из base64), применяет SHA-1 функция хеширования и кодирует результат с помощью base64.[35]

После установления соединения клиент и сервер могут отправлять данные WebSocket или текстовые фреймы назад и вперед в полнодуплексный режим. Данные минимально оформлены, с небольшим заголовком, за которым следует полезная нагрузка.[36] Передачи через WebSocket описываются как «сообщения», где одно сообщение может быть разделено на несколько кадров данных. Это может позволить отправлять сообщения, в которых доступны начальные данные, но полная длина сообщения неизвестна (он отправляет один кадр данных за другим, пока не будет достигнут конец и не будет отмечен битом FIN). С расширениями протокола это также можно использовать для одновременного мультиплексирования нескольких потоков (например, чтобы избежать монополизации использования сокета для одной большой полезной нагрузки).[37]

Соображения безопасности

В отличие от обычных междоменных HTTP-запросов, запросы WebSocket не ограничиваются Политика одинакового происхождения. Поэтому серверы WebSocket должны проверять заголовок "Origin" на соответствие ожидаемым источникам во время установления соединения, чтобы избежать атак Cross-Site WebSocket Hijacking (аналогично Подделка межсайтовых запросов), что может быть возможно при аутентификации соединения с помощью файлов cookie или HTTP-аутентификации. Лучше использовать токены или аналогичные механизмы защиты для аутентификации соединения WebSocket, когда конфиденциальные (частные) данные передаются через WebSocket.[38] Живой пример уязвимости был замечен в 2020 году в виде Cable Haunt.

Обход прокси

Клиентские реализации протокола WebSocket пытаются определить, пользовательский агент настроен на использование прокси при подключении к целевому хосту и порту и, если он есть, использует HTTP ПОДКЛЮЧЕНИЕ метод настройки постоянного туннеля.

Хотя сам протокол WebSocket не знает о прокси-серверах и брандмауэрах, он поддерживает HTTP-совместимое рукопожатие, что позволяет HTTP-серверам совместно использовать свои порты HTTP и HTTPS по умолчанию (443 и 80) со шлюзом или сервером WebSocket. Протокол WebSocket определяет префиксы ws: // и wss: // для обозначения соединений WebSocket и WebSocket Secure соответственно. Обе схемы используют Механизм обновления HTTP для перехода на протокол WebSocket. Некоторые прокси-серверы прозрачны и отлично работают с WebSocket; другие будут препятствовать правильной работе WebSocket, что приведет к сбою соединения. В некоторых случаях может потребоваться дополнительная конфигурация прокси-сервера, и некоторые прокси-серверы могут потребовать обновления для поддержки WebSocket.

Если незашифрованный трафик WebSocket проходит через явный или прозрачный прокси-сервер без поддержки WebSockets, соединение, скорее всего, не удастся.[39]

Если используется зашифрованное соединение WebSocket, то использование Безопасность транспортного уровня (TLS) в соединении WebSocket Secure гарантирует выдачу команды HTTP CONNECT, когда браузер настроен на использование явного прокси-сервера. Это устанавливает туннель, который обеспечивает сквозную связь TCP на низком уровне через прокси-сервер HTTP между клиентом WebSocket Secure и сервером WebSocket. В случае прозрачных прокси-серверов браузер не знает о прокси-сервере, поэтому HTTP CONNECT не отправляется. Однако, поскольку проводной трафик зашифрован, промежуточные прозрачные прокси-серверы могут просто пропускать зашифрованный трафик, поэтому гораздо больше шансов, что соединение WebSocket будет успешным, если используется WebSocket Secure. Использование шифрования сопряжено с расходами на ресурсы, но часто обеспечивает наивысший уровень успеха, поскольку оно будет проходить через защищенный туннель.

Черновик середины 2010 года (версия hixie-76) нарушил совместимость с обратные прокси и шлюзы, включив восемь байтов ключевых данных после заголовков, но не рекламируя эти данные в Длина содержимого: 8 заголовок.[40] Эти данные не пересылались всеми промежуточными звеньями, что могло привести к сбою протокола. Более свежие проекты (например, hybi-09[41]) поместите ключевые данные в Sec-WebSocket-ключ заголовок, решающий эту проблему.

Смотрите также

Примечания

  1. ^ а б Браузеры на основе Gecko версий 6–10 реализуют объект WebSocket как «MozWebSocket»,[24] требуется дополнительный код для интеграции с существующим кодом с поддержкой WebSocket.

Рекомендации

  1. ^ Ян Фетте; Алексей Мельников (декабрь 2011 г.). «Отношение к TCP и HTTP». RFC 6455 Протокол WebSocket. IETF. сек. 1.7. Дои:10.17487 / RFC6455. RFC 6455.
  2. ^ «Глоссарий: веб-сокеты». Сеть разработчиков Mozilla. 2015 г.
  3. ^ «HTML5 WebSocket - квантовый скачок в масштабируемости для Интернета». www.websocket.org.
  4. ^ Грэм Клайн, изд. (2011-11-14). «Схемы унифицированного идентификатора ресурса (URI) IANA». Управление по присвоению номеров в Интернете. Получено 2011-12-10.
  5. ^ Ян Фетте; Алексей Мельников (декабрь 2011 г.). "URI WebSocket". RFC 6455 Протокол WebSocket. IETF. сек. 3. Дои:10.17487 / RFC6455. RFC 6455.
  6. ^ Ванга, Ванесса; Салим, Франк; Московиц, Питер (февраль 2013). «ПРИЛОЖЕНИЕ A: Проверка фреймов WebSocket с помощью инструментов разработчика Google Chrome». Полное руководство по HTML5 WebSocket. Апресс. ISBN 978-1-4302-4740-1. Получено 7 апреля 2013.
  7. ^ «HTML 5». www.w3.org. Получено 2016-04-17.
  8. ^ "[whatwg] Отзыв Майкла Картера о TCPConnection от 18 июня 2008 г. (whatwg.org от июня 2008 г.)". lists.w3.org. Получено 2016-04-17.
  9. ^ "Журналы IRC: freenode / #whatwg / 20080618". krijnhoetmer.nl. Получено 2016-04-18.
  10. ^ «Comet Daily» Архив блога »День независимости: HTML5 WebSocket освобождает Comet от взломов». Получено 2016-04-17.
  11. ^ «Веб-сокеты теперь доступны в Google Chrome». Блог Chromium. Получено 2016-04-17.
  12. ^ , Ян Хиксон. «Протокол WebSocket». tools.ietf.org. Получено 2016-04-17.
  13. ^ , Ян Хиксон. «Протокол WebSocket». tools.ietf.org. Получено 2016-04-17.
  14. ^ Диркьян Охтман (27 мая 2011 г.). "WebSocket включен в Firefox 6". Mozilla.org. Получено 2011-06-30.
  15. ^ «Статус веб-платформы Chromium». Получено 2011-08-03.
  16. ^ «WebSockets (Windows)». Microsoft. 2012-09-28. Получено 2012-11-07.
  17. ^ «Отчет о тестировании протокола WebSockets». Tavendo.de. 2011-10-27. Получено 2011-12-10.
  18. ^ Кэти Марсал (23 ноября 2010 г.). «Apple добавляет акселерометр и поддержку WebSockets в Safari в iOS 4.2». AppleInsider.com. Получено 2011-05-09.
  19. ^ «API веб-сокетов». Ежевика. Архивировано из оригинал 10 июня 2011 г.. Получено 8 июля 2011.
  20. ^ Крис Хейлманн (8 декабря 2010 г.). «WebSocket отключен в Firefox 4». Hacks.Mozilla.org. Получено 2011-05-09.
  21. ^ Александр Аас (10 декабря 2010 г.). «Относительно WebSocket». Мой блог Opera. Архивировано из оригинал на 2010-12-15. Получено 2011-05-09.
  22. ^ «WebSockets (поддержка в Firefox)». developer.mozilla.org. Mozilla Foundation. 2011-09-30. Получено 2011-12-10.
  23. ^ "Ошибка 640003 - WebSockets - обновление до ietf-06". Mozilla Foundation. 2011-03-08. Получено 2011-12-10.
  24. ^ "WebSockets - MDN". developer.mozilla.org. Mozilla Foundation. 2011-09-30. Получено 2011-12-10.
  25. ^ «Ошибка 640003 - WebSockets - обновление до ietf-07 (комментарий 91)». Mozilla Foundation. 2011-07-22.
  26. ^ "Ошибка хрома 64470". code.google.com. 2010-11-25. Получено 2011-12-10.
  27. ^ «WebSockets в Windows Consumer Preview». Команда инженеров IE. Microsoft. 2012-03-19. Получено 2012-07-23.
  28. ^ "Набор изменений WebKit 97247: WebSocket: обновить протокол WebSocket до hybi-17". trac.webkit.org. Получено 2011-12-10.
  29. ^ "Горячий летний снимок Opera 12.50". Новости разработчиков Opera. 2012-08-03. Архивировано из оригинал на 2012-08-05. Получено 2012-08-03.
  30. ^ [1]
  31. ^ «Использование NGINX в качестве прокси-сервера WebSocket». NGINX. 17 мая 2014 года.
  32. ^ «Поддержка протокола IIS 8.0 WebSocket». Документы Microsoft. 28 ноября 2012 г.. Получено 2020-02-18.
  33. ^ Ян Фетте; Алексей Мельников (декабрь 2011 г.). «Обзор протокола». RFC 6455 Протокол WebSocket. IETF. сек. 1.2. Дои:10.17487 / RFC6455. RFC 6455.
  34. ^ «Основная цель протокола WebSocket». IETF. Получено 25 июля 2015. Вычисление [...] предназначено для предотвращения предоставления кэширующим посредником WS-клиенту кэшированного ответа WS-сервера без фактического взаимодействия с WS-сервером.
  35. ^ Ян Фетте; Алексей Мельников (декабрь 2011 г.). «Вступительное рукопожатие». RFC 6455 Протокол WebSocket. IETF. п. 8. сек. 1.3. Дои:10.17487 / RFC6455. RFC 6455.
  36. ^ Ян Фетте; Алексей Мельников (декабрь 2011 г.). "Базовый протокол кадрирования". RFC 6455 Протокол WebSocket. IETF. сек. 5.2. Дои:10.17487 / RFC6455. RFC 6455.
  37. ^ Джон А. Тамплин; Такеши Ёсино (2013). Расширение мультиплексирования для веб-сокетов. IETF. I-D draft-ietf-hybi-websocket-multiplexing.
  38. ^ Кристиан Шнайдер (31 августа 2013 г.). «Межсайтовый захват веб-сокетов (CSWSH)». Блог о безопасности веб-приложений.
  39. ^ Питер Любберс (16 марта 2010 г.). «Как веб-сокеты HTML5 взаимодействуют с прокси-серверами». Infoq.com. C4Media Inc. Получено 2011-12-10.
  40. ^ Вилли Тарро (06.07.2010). «WebSocket -76 несовместим с обратными HTTP-прокси». ietf.org (электронное письмо). Инженерная группа Интернета. Получено 2011-12-10.
  41. ^ Ян Фетте (13 июня 2011 г.). "Sec-WebSocket-Key". Протокол WebSocket, проект hybi-09. сек. 11,4. Получено 15 июня, 2011.

внешняя ссылка