Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

WebSocket - это протокол компьютерной связи , обеспечивающий полнодуплексные каналы связи через одно TCP- соединение. Протокол WebSocket был стандартизирован IETF как RFC 6455 в 2011 году, а API WebSocket в Web IDL стандартизируется W3C .

WebSocket отличается от HTTP . Оба протокола расположены на уровне 7 в модели OSI и зависят от TCP на уровне 4. Хотя они разные, RFC 6455 утверждает, что WebSocket «разработан для работы через HTTP-порты 443 и 80, а также для поддержки HTTP-прокси и посредников, ", что делает его совместимым с протоколом HTTP. Для обеспечения совместимости при подтверждении связи WebSocket используется заголовок HTTP Upgrade [1] для перехода с протокола HTTP на протокол WebSocket.

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

Большинство браузеров поддерживают этот протокол, включая Google Chrome , Microsoft Edge , Internet Explorer , Firefox , Safari и Opera .

В отличие от HTTP, WebSocket обеспечивает полнодуплексную связь. [2] [3] Кроме того, WebSocket позволяет передавать потоки сообщений поверх TCP. Только TCP имеет дело с потоками байтов, не имеющими внутренней концепции сообщения. До WebSocket полнодуплексная связь через порт 80 была возможна с использованием каналов Comet ; однако реализация 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 был Ян Хиксон. В декабре 2009 года Google Chrome 4 стал первым браузером, в котором была реализована полная поддержка стандарта, с включенным по умолчанию WebSocket. [10] В феврале 2010 г. разработка протокола WebSocket была передана из группы W3C и WHATWG в IETF, а авторами двух ревизий был Ян Хиксон. [11]

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

Реализация браузера [ править ]

Защищенная версия протокола WebSocket реализована в Firefox 6, [13] Safari 6, Google Chrome 14, [14] Opera 12.10 и Internet Explorer 10. [15] В подробном отчете о тестировании протокола [16] перечислено их соответствие браузеры для определенных аспектов протокола.

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

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

Пример клиента JavaScript [ править ]

const  socket  =  new  WebSocket ( 'ws: //game.example.com: 12010 / updates' ); розетка . onopen  =  function  ()  {  setInterval ( function ()  {  if  ( socket . bufferedAmount  ==  0 )  socket . send ( getUpdateData ());  },  50 ); };

Реализация веб-сервера [ править ]

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

HTTP-сервер Apache поддерживает WebSockets с июля 2013 года, реализованный в версии 2.4.5 [31] [32]

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

lighttpd поддерживает WebSockets с 2017 года, реализованный в версии 1.4.46. [34] lighttpd mod_proxy может действовать как обратный прокси-сервер и балансировщик нагрузки приложений WebSocket. lighttpd mod_wstunnel может облегчить туннель WebSocket, позволяя клиенту использовать WebSockets для туннелирования более простого протокола, такого как JSON , в серверное приложение.

Рукопожатие протокола [ править ]

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

Клиентский запрос (как и в 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 : чат

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

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

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

Соображения безопасности [ править ]

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

Обход прокси [ править ]

Реализации клиента протокола WebSocket пытаются определить, настроен ли пользовательский агент для использования прокси-сервера при подключении к целевому узлу и порту, и, если это так, использует метод HTTP CONNECT для настройки постоянного туннеля.

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

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

Если используется зашифрованное соединение 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заголовке. [42] Эти данные не пересылались всеми промежуточными звеньями, что могло привести к сбою протокола. Более поздние проекты (например, hybi-09 [43] ) помещают ключевые данные в Sec-WebSocket-Keyзаголовок, решая эту проблему.

См. Также [ править ]

  • BOSH
  • Сравнение реализаций WebSocket
  • Сетевая розетка
  • Технология push
  • Отправленные сервером события
  • XMLHttpRequest
  • HTTP / 2
  • Набор интернет-протоколов
  • WebRTC

Заметки [ править ]

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

Ссылки [ править ]

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

Внешние ссылки [ править ]

  • Рабочая группа IETF Hypertext-Bidirectional (HyBi)
    • Протокол WebSocket - предлагаемый стандарт, опубликованный рабочей группой IETF HyBi
    • Протокол WebSocket - Internet-Draft, опубликованный рабочей группой IETF HyBi
    • Протокол WebSocket - первоначальное предложение протокола Яна Хиксона
  • API WebSocket - рабочий проект спецификации API W3C
  • WebSocket API - W3C Candidate Recommendation спецификация API
  • WebSocket.org Демонстрации WebSocket, тесты обратной связи, общая информация и сообщество