✖


Jump to content

Вебсокет

(Перенаправлено с веб-сокетов )
Вебсокет
Диаграмма, описывающая соединение с использованием WebSocket
Международный стандарт RFC   6455
Разработано IETF
Промышленность Информатика
Тип разъема TCP
Веб-сайт https://websockets.spec.whatwg.org/

WebSocket — это протокол компьютерной связи , обеспечивающий одновременный двусторонний канал связи через одно соединение протокола управления передачей (TCP). Протокол WebSocket был стандартизирован IETF как RFC   6455 в 2011 году. Текущая спецификация, позволяющая веб-приложениям использовать этот протокол, известна как WebSockets . [1] Это стандарт жизни, поддерживаемый WHATWG , и преемник API WebSocket от W3C . [2]

WebSocket отличается от HTTP, используемого для обслуживания большинства веб-страниц. Хоть они и разные, В RFC   6455 говорится, что WebSocket «предназначен для работы через HTTP-порты 443 и 80, а также для поддержки HTTP-прокси и посредников», что делает его совместимым с HTTP. WebSocket Для достижения совместимости при рукопожатии используется заголовок HTTP Upgrade. [3] для перехода с протокола HTTP на протокол WebSocket.

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

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

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

История

[ редактировать ]

WebSocket впервые упоминался как TCPConnection в спецификации HTML5 в качестве заполнителя для API сокетов на основе TCP. [8] провел серию обсуждений В июне 2008 года Майкл Картер , в результате которых появилась первая версия протокола, известная как WebSocket. [9] До WebSocket полнодуплексная связь по порту 80 была возможна с использованием Comet каналов ; однако реализация Comet нетривиальна и из-за накладных расходов на TCP-квитирование и HTTP-заголовок она неэффективна для небольших сообщений. Протокол WebSocket призван решить эти проблемы без ущерба для безопасности сети. Название «WebSocket» было придумано Яном Хиксоном и Майклом Картером вскоре после этого в результате сотрудничества в чате #whatwg IRC. [10] и впоследствии автором для включения в спецификацию HTML5 был Ян Хиксон. В декабре 2009 года Google Chrome 4 стал первым браузером, предоставившим полную поддержку стандарта с включенным по умолчанию WebSocket. [11] Разработка протокола WebSocket впоследствии была передана из группы W3C и WHATWG в IETF в феврале 2010 года, и автором двух редакций был Ян Хиксон. [12]

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

RFC   7692 представил расширение сжатия для WebSocket с использованием алгоритма DEFLATE для каждого сообщения.

Пример клиента

[ редактировать ] 
<!DOCTYPE html>
<script>
// Connect to server
ws = new WebSocket("ws://127.0.0.1/scoreboard") // Local server
// ws = new WebSocket("wss://game.example.com/scoreboard") // Remote server

ws.onopen = () => {
    console.log("Connection opened")
    ws.send("Hi server, please send me the score of yesterday's game")
}

ws.onmessage = (event) => {
    console.log("Data received", event.data)
    ws.close() // We got the score so we don't need the connection anymore
}

ws.onclose = (event) => {
    console.log("Connection closed", event.code, event.reason, event.wasClean)
}

ws.onerror = () => {
    console.log("Connection closed due to error")
}
</script>

Пример сервера

[ редактировать ] 
from socket import socket
from base64 import b64encode
from hashlib import sha1

MAGIC = b"258EAFA5-E914-47DA-95CA-C5AB0DC85B11"

# Create socket and listen at port 80
ws = socket()
ws.bind(("", 80))
ws.listen()
conn, addr = ws.accept()

# Parse request
for line in conn.recv(4096).split(b"\r\n"):
    if line.startswith(b"Sec-WebSocket-Key"):
        nonce = line.split(b":")[1].strip()

# Format response
response = f"""\
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: {b64encode(sha1(nonce + MAGIC).digest()).decode()}

"""

conn.send(response.replace("\n", "\r\n").encode())

while True: # decode messages from the client
    header = conn.recv(2)
    FIN = bool(header[0] & 0x80) # bit 0
    assert FIN == 1, "We only support unfragmented messages"
    opcode = header[0] & 0xf # bits 4-7
    assert opcode == 1 or opcode == 2, "We only support data messages"
    masked = bool(header[1] & 0x80) # bit 8
    assert masked, "The client must mask all frames"
    payload_size = header[1] & 0x7f # bits 9-15
    assert payload_size <= 125, "We only support small messages"
    masking_key = conn.recv(4)
    payload = bytearray(conn.recv(payload_size))
    for i in range(payload_size):
        payload[i] = payload[i] ^ masking_key[i % 4]
    print(payload)

Веб-API

[ редактировать ]

Веб-приложение (например, веб-браузер) может использовать WebSocket интерфейс для подключения к серверу WebSocket.

Спецификация веб-API WebSocket
Тип Имя [13] Описание
Конструктор ws = new WebSocket(url [, protocols ]) Начните открытие рукопожатия с сервером WebSocket. [14]
  • url: строка, содержащая:
    • Схема: должна быть ws, wss, http или https.
    • Имя хоста сервера.
    • Необязательный порт сервера: если не указан, 80 используется для ws/http и 443 для wss/https.
    • Необязательный путь.
    • Никакого фрагмента. Никакого фрагмента быть не должно, иначе SyntaxError брошен.
  • Необязательный protocols: строка или массив строк, используемый в качестве значения для Sec-WebSocket-Protocol заголовок.
Метод ws.send(data) Отправить данные . data должно быть string, Blob, ArrayBuffer или ArrayBufferView. Бросать InvalidStateError если ws.readyState является WebSocket.CONNECTING.
ws.close([ code ] [, reason ]) Начните завершать рукопожатие . [15]
  • Необязательный code: Если указано, должно быть 1000 (нормальное закрытие) или в диапазоне от 3000 до 4999 (определяется приложением), в противном случае InvalidAccessError брошен. Если не указано, используется 1000.
  • Необязательный reason: Если указано, должна быть строкой не длиннее 123 байтов ( UTF-8 ), в противном случае SyntaxError брошен. Если не указано, используется пустая строка.
Событие ws.onopen = (event) => {}

ws.addEventListener("open", (event) => {})

Открытое рукопожатие удалось . event тип Event.
ws.onmessage = (event) => {}

ws.addEventListener("message", (event) => {})

Данные получены. event тип MessageEvent. event.data содержит полученные данные типа: [16]
  • String для текста.
  • Blob или ArrayBuffer для двоичного кода (см. ws.binaryType).
ws.onclose = (event) => {}

ws.addEventListener("close", (event) => {})

Базовое TCP-соединение закрыто . event тип CloseEvent содержащий: [17] [18] [19] [20]
  • event.code: код состояния (целое число).
  • event.reason: причина закрытия (строка).
  • event.wasClean: true если TCP-соединение было закрыто после завершения закрывающего рукопожатия; false в противном случае.

Примечание:

  • Если полученный кадр Close содержит полезную нагрузку : данные полезной нагрузки содержат event.code и event.reason.
  • Если полученный кадр Close не содержит полезных данных : event.code равно 1005 (код не получен) и event.reason пустая строка.
  • Если кадр закрытия не был получен: event.code равно 1006 (соединение закрыто ненормально) и event.reason пустая строка.
ws.onerror = (event) => {}

ws.addEventListener("error", (event) => {})

Соединение закрыто из-за ошибки . event тип Event.
Атрибут ws.binaryType Строка, указывающая тип event.data в ws.onmessage при получении двоичных данных. Изначально установлено "blob" ( Blob объект). Может быть изменен на "arraybuffer" ( ArrayBuffer объект).
Атрибут только для чтения ws.url URL-адрес, указанный конструктору WebSocket.
ws.bufferedAmount Количество байтов, ожидающих передачи.
ws.protocol Протокол, принятый сервером, или пустая строка, если клиент не указал protocols в WebSocket конструктор.
ws.extensions Расширения, принимаемые сервером.
ws.readyState Состояние соединения. Это одна из констант ниже.
Постоянный WebSocket.CONNECTING = 0 Ожидание открытия рукопожатия . [21] [22]
WebSocket.OPEN = 1 Открытое рукопожатие удалось . Клиент и сервер могут отправлять друг другу сообщения. [23] [24]
WebSocket.CLOSING = 2 Ожидание закрытия рукопожатия . Или ws.close() был вызван или сервер отправил кадр Close. [25] [26]
WebSocket.CLOSED = 3 Базовое TCP-соединение закрыто . [27] [17] [18]

Протокол

[ редактировать ]

Шаги:

  1. Открытие рукопожатия ( HTTP-запрос + HTTP-ответ ) для установления соединения.
  2. Сообщения данных для передачи данных приложения.
  3. Закрытие рукопожатия (два кадра Close) для закрытия соединения.

Открытие рукопожатия

[ редактировать ]

Клиент отправляет HTTP-запрос ( метод GET , версия ≥ 1.1 ), а сервер возвращает HTTP-ответ с кодом состояния 101 ( Протоколы переключения ) в случае успеха. Это означает, что сервер WebSocket может использовать тот же порт, что и HTTP (80) и HTTPS (443), поскольку рукопожатие совместимо с HTTP. [28]

HTTP-заголовки
Сторона
Заголовок Ценить Обязательный
Запрос
Источник Варьируется Да (для браузерных клиентов) [29]
Хозяин Варьируется Да
Версия Sec-WebSocket 13 [30]
Sec-WebSocket-ключ base64 -encode(16-байтовый случайный одноразовый номер ) [31]
Ответ
Sec-WebSocket-Accept base64-encode( sha1 (Sec-WebSocket-Key + "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" )) [32]
Оба
Связь Обновление [33] [34]
Обновление веб-сокет [35] [36]
Sec-WebSocket-протокол Запрос может содержать разделенных запятыми список строк, (упорядоченных по предпочтениям), указывающих протоколы уровня приложения (построенные на основе сообщений данных WebSocket), которые клиент желает использовать. [37] Если клиент отправляет этот заголовок, ответ сервера должен быть одним из значений из списка. Необязательный
Sec-WebSocket-Extensions
Другие заголовки Варьируется

Пример запроса: [38] 

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com

Пример ответа: 

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat

В HTTP каждая строка заканчивается \r\n и последняя строка пуста. 

# Calculate Sec-WebSocket-Accept using Sec-WebSocket-Key
from base64 import b64encode
from hashlib import sha1
from os import urandom
# key = b64encode(urandom(16)) # Client should do this
key = b"x3JJHMbDL1EzLkh9GBhXDw==" # Value in example request above
magic = b"258EAFA5-E914-47DA-95CA-C5AB0DC85B11" # Protocol constant
print(b64encode(sha1(key + magic).digest()))
# Output: HSmrc0sMlYUkAGmm5OPpG2HaGWk=

После установления соединения связь переключается на протокол на основе двоичных кадров, который не соответствует протоколу HTTP.

Sec-WebSocket-Key и Sec-WebSocket-Accept предназначены для предотвращения кэширующим прокси-сервером предыдущего диалога WebSocket, повторной отправки [39] и не обеспечивает никакой аутентификации, конфиденциальности или целостности.

Хотя некоторые серверы принимают короткие Sec-WebSocket-Key, многие современные серверы отклонят запрос с ошибкой «неверный заголовок Sec-WebSocket-Key».

Сообщение на основе фрейма

[ редактировать ]

После открывающего рукопожатия клиент и сервер могут в любое время отправлять друг другу сообщения, например сообщения с данными (текстовые или двоичные) и управляющие сообщения (закрытие, пинг, понг). Сообщение состоит из одного или нескольких кадров.

Фрагментация позволяет разделить сообщение на два или более кадров. Это позволяет отправлять сообщения с доступными исходными данными, но с неизвестной полной длиной. Без фрагментации все сообщение должно быть отправлено в одном кадре, поэтому необходима полная длина, прежде чем можно будет отправить первый байт, для чего требуется буфер. [40] Это также позволяет мультиплексировать несколько потоков одновременно (например, чтобы избежать монополизации сокета для одной большой полезной нагрузки ). [41]

  • состоит Нефрагментированное сообщение из одного кадра с FIN = 1 и opcode ≠ 0.
  • состоит Фрагментированное сообщение из одного кадра с FIN = 0 и opcode ≠ 0, за которым следует ноль или более кадров с FIN = 0 и opcode = 0и завершается одним кадром с FIN = 1 и opcode = 0.

Каркасная конструкция

[ редактировать ]
Индекс
(в битах) 		Поле Размер
(в битах) 		Описание
0 КОНЕЦ [42] 1
  • 1 = последний кадр сообщения.
  • 0 = сообщение фрагментировано и это не последний кадр.
1 РСВ1 1 Должно быть 0, если не определено расширением. [43]
2 РСВ2 1
3 РСВ3 1
4 Код операции 4 См. коды операций ниже.
8 В маске [44] 1
  • 1 = кадр замаскирован и ключ маскировки присутствует.
  • 0 = кадр не замаскирован и ключ маскировки отсутствует.
См . маскирование между клиентом и сервером ниже.
9 Длина полезной нагрузки [45] 7, 7+16 или 7+64 Длина полезных данных (данные расширения + данные приложения) в байтах.
  • 0–125 = это длина полезной нагрузки.
  • 126 = Следующие 16 бит представляют собой длину полезной нагрузки.
  • 127 = Следующие 64 бита ( старший бит должен быть 0) представляют собой длину полезной нагрузки.
Порядок байтов — это обратный порядок байтов. Подпись беззнаковая. Для кодирования длины необходимо использовать минимальное количество битов.
Варьируется Маскирующий ключ 0 или 32 Клиент должен маскировать все кадры, отправляемые на сервер. Сервер не должен маскировать кадры, отправленные клиенту. [46] Маскирование кадра применяет XOR между ключом маскировки (четырехбайтовый случайный одноразовый номер) и данными полезной нагрузки. Для маскировки/демаскирования кадра используется следующий алгоритм: [47] 
for i = 0 to payload_length - 1
    payload[i] = payload[i] xor masking_key[i modulo 4]
Полезная нагрузка Данные расширения Длина полезной нагрузки (в байтах) Должно быть пустым, если не определено расширением.
Данные приложения Зависит от опкода.

Коды операций

[ редактировать ]
Тип рамы Код операции Связанный

Веб-API

Описание Цель
Фрагментированный
Макс. длина полезной нагрузки
Продолжение 0 Идентифицирует промежуточный кадр фрагментированного сообщения. ⁠ ⁠ байт
Кадр данных Текст 1 send(), onmessage Текст приложения в кодировке UTF-8. Данные приложения Да
Двоичный 2 Двоичные данные приложения.
3–7 Сдержанный
Рамка управления Закрывать 8 close(), onclose Кадр закрытия отправляется для запуска закрывающего рукопожатия , которое может предотвратить потерю данных, дополняя закрывающее рукопожатие TCP . [48] Ни один кадр не может быть отправлен после кадра Close. Если получен кадр Close, а предыдущий кадр Close не был отправлен, должен быть отправлен ответный кадр Close с той же полезной нагрузкой. Полезная нагрузка является необязательной, но если она присутствует, она должна начинаться с двухбайтового кода причины беззнакового целого числа с обратным порядком байтов , за которым может следовать сообщение причины в кодировке UTF-8 длиной не более 123 байтов. [49] Состояние протокола Нет 125 байт
Пинг 9 Может использоваться для задержки измерения , поддержания активности и пульса . Обе стороны могут инициировать пинг (с любой полезной нагрузкой). Тот, кто его получит, должен немедленно отправить обратно понг с той же полезной нагрузкой. Понг следует игнорировать, если предыдущий пинг не был отправлен. [50] [51]
Понг 10
11–15 Сдержанный

Коды состояния

[ редактировать ]
Диапазон [52] Разрешено в закрытом кадре Код

[53]

Описание
0–999 Нет Неиспользованный
1000–2999 (Протокол) Да 1000 Нормальное закрытие.
1001 Уходит (например, вкладка браузера закрыта).
1002 Ошибка протокола.
1003 Неподдерживаемые данные (например, конечная точка понимает только текст, но получает двоичные данные).
Нет 1004 Зарезервировано для будущего использования
1005 Код не получен.
1006 Соединение закрылось аварийно (закрытие соединения не произошло).
Да 1007 Неверные данные полезной нагрузки (например, данные, отличные от UTF-8, в текстовом сообщении).
1008 Политика нарушена.
1009 Сообщение слишком большое.
1010 Неподдерживаемое расширение. Клиент должен записать в полезные данные расширения, которые, по его ожиданиям, будет поддерживать сервер.
1011 Внутренняя ошибка сервера.
Нет 1015 Ошибка подтверждения TLS.
3000–3999 Да Используется библиотеками, фреймворками и приложениями.
4000–4999 Частное использование.

Поддержка браузера

[ редактировать ]

Безопасная версия протокола WebSocket реализована в Firefox 6. [54] Сафари 6, Гугл Хром 14, [55] Опера 12.10 и Интернет Эксплорер 10. [56] Подробный отчет о наборе тестов протокола [57] перечисляет соответствие этих браузеров конкретным аспектам протокола.

Более старая, менее безопасная версия протокола была реализована в Opera 11 и Safari 5, а также мобильная версия Safari в iOS 4.2 . [58] Браузер BlackBerry в OS7 реализует WebSockets. [59] Из-за уязвимостей он был отключен в Firefox 4 и 5, [60] и Опера 11. [61] Используя инструменты разработчика браузера, разработчики могут проверять подтверждение связи WebSocket, а также фреймы WebSocket. [62]

Протокол
Версия
Дата проекта Интернет Эксплорер Firefox [63]
(ПК) 		Firefox
(Андроид) 		Хром
(ПК, мобильный) 		Сафари
(Мак, iOS) 		Опера
(ПК, мобильный) 		Android-браузер
Хикси-75 4 февраля 2010 г. 4 5.0.0
Хикси-76
муженек-00 		6 мая 2010 г.
23 мая 2010 г. 		4.0
(неполноценный) 		6 5.0.1 11.00
(неполноценный)
гибрид-07 , v7 22 апреля 2011 г. 6 [64] [а]
гибрид-10 , v8 11 июля 2011 г. 7 [66] [а] 7 14 [67]
RFC   6455 , версия 13 декабрь 2011 г. 10 [68] 11 11 16 [69] 6 12.10 [70] 4.4

Реализации сервера

[ редактировать ]
  • HTTP-сервер Apache поддерживает WebSockets с июля 2013 года, реализовано в версии 2.4.5. [73] [74]
  • Службы Internet Information Services добавили поддержку WebSockets в версии 8, выпущенной вместе с Windows Server 2012 . [75]
  • Lighttpd поддерживает WebSockets с 2017 года, реализованный в Lighttpd 1.4.46. [76] Lighttpd mod_proxy может выступать в качестве обратного прокси-сервера и балансировщика нагрузки приложений WebSocket. Lighttpd mod_wstunnel может выступать в качестве конечной точки WebSocket для передачи произвольных данных, в том числе в формате JSON , серверному приложению. Lighttpd поддерживает WebSockets через HTTP/2 с 2022 года, реализовано в Lighttpd 1.4.65. [77]

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

[ редактировать ]

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

Обход прокси

[ редактировать ]

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

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

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

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

Проект середины 2010 года (версия hixie-76) нарушил совместимость с обратными прокси-серверами и шлюзами, включив восемь байтов ключевых данных после заголовков, но не объявив эти данные в Content-Length: 8 заголовок. [80] Эти данные не были отправлены всеми промежуточными посредниками, что могло привести к сбою протокола. Более поздние проекты (например, hybi-09 [81] ) поместите ключевые данные в Sec-WebSocket-Key заголовок, решение этой проблемы.

См. также

[ редактировать ]

Примечания

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

Ссылки

[ редактировать ]
  1. ^ «Стандарт веб-сокетов» . websockets.spec.whatwg.org . Архивировано из оригинала 12 марта 2023 г. Проверено 16 мая 2022 г.
  2. ^ «API WebSocket» . www.w3.org . Архивировано из оригинала 8 июня 2022 г. Проверено 16 мая 2022 г.
  3. ^ Ян Фетт; Алексей Мельников (декабрь 2011 г.). «Отношения с TCP и HTTP» . RFC 6455 Протокол WebSocket . IETF . сек. 1.7. дои : 10.17487/RFC6455 . РФК 6455 .
  4. ^ «Платформа Adobe Flash – Сокеты» . help.adobe.com . Архивировано из оригинала 18 апреля 2021 г. Проверено 28 июля 2021 г. Для TCP-соединений требуются «клиент» и «сервер». Flash Player может создавать клиентские сокеты.
  5. ^ «API WebSocket (WebSockets)» . Веб-документы MDN . Сеть разработчиков Mozilla. 06.04.2023. Архивировано из оригинала 28 июля 2021 г. Проверено 26 июля 2021 г.
  6. ^ Грэм Клайн, изд. (14 ноября 2011 г.). «Схемы единого идентификатора ресурса (URI) IANA» . Управление по присвоению номеров в Интернете . Архивировано из оригинала 25 апреля 2013 г. Проверено 10 декабря 2011 г.
  7. ^ Ян Фетт; Алексей Мельников (декабрь 2011 г.). «URI WebSocket» . RFC 6455 Протокол WebSocket . IETF . сек. 3. дои : 10.17487/RFC6455 . РФК 6455 .
  8. ^ «HTML 5» . www.w3.org . Архивировано из оригинала 16 сентября 2016 г. Проверено 17 апреля 2016 г.
  9. ^ «Отзыв [whatwg] TCPConnection от Майкла Картера от 18 июня 2008 г. (whatwg.org от июня 2008 г.)» . lists.w3.org . Архивировано из оригинала 27 апреля 2016 г. Проверено 17 апреля 2016 г.
  10. ^ «Журналы IRC: freenode/#whatwg/20080618» . krijnhoetmer.nl . Архивировано из оригинала 21 августа 2016 г. Проверено 18 апреля 2016 г.
  11. ^ «Веб-сокеты теперь доступны в Google Chrome» . Блог Хрома . Архивировано из оригинала 9 декабря 2021 г. Проверено 17 апреля 2016 г.
  12. ^ < [адрес электронной почты защищен] >, Ян Хиксон (6 мая 2010 г.). «Протокол WebSocket» . Ietf Datatracker . Архивировано из оригинала 17 марта 2017 г. Проверено 17 апреля 2016 г.
  13. ^ «Определение интерфейса» . ЧТОРГ . Архивировано из оригинала 12 марта 2023 г. Проверено 10 апреля 2024 г.
  14. ^ «новый WebSocket(url, протоколы)» . ЧТОРГ . Архивировано из оригинала 12 марта 2023 г. Проверено 30 апреля 2024 г.
  15. ^ "закрыть(код, причина)" . ЧТОРГ . Архивировано из оригинала 12 марта 2023 г. Проверено 10 апреля 2024 г.
  16. ^ «Когда получено сообщение WebSocket» . ЧТОРГ . Архивировано из оригинала 12 марта 2023 г. Проверено 13 апреля 2024 г.
  17. ^ Перейти обратно: а б «Когда соединение WebSocket закрывается; подэтап 3» . ЧТОРГ . Архивировано из оригинала 12 марта 2023 г. Проверено 13 апреля 2024 г.
  18. ^ Перейти обратно: а б Соединение WebSocket закрыто . сек. 7.1.4. дои : 10.17487/RFC6455 . РФК 6455 .
  19. ^ Код закрытия соединения WebSocket . сек. 7.1.5. дои : 10.17487/RFC6455 . РФК 6455 .
  20. ^ Причина закрытия соединения WebSocket . сек. 7.1.6. дои : 10.17487/RFC6455 . РФК 6455 .
  21. ^ «СОЕДИНЕНИЕ» . ЧТОРГ . Архивировано из оригинала 12 марта 2023 г. Проверено 13 апреля 2024 г.
  22. ^ Требования клиента . п. 14. сек. 4.1. дои : 10.17487/RFC6455 . РФК 6455 .
  23. ^ "ОТКРЫТЬ" . ЧТОРГ . Архивировано из оригинала 12 марта 2023 г. Проверено 10 апреля 2024 г.
  24. ^ _Соединение WebSocket установлено_ . п. 20. дои : 10.17487/RFC6455 . РФК 6455 .
  25. ^ «ЗАКРЫТИЕ» . ЧТОРГ . Архивировано из оригинала 12 марта 2023 г. Проверено 10 апреля 2024 г.
  26. ^ Завершающее рукопожатие WebSocket начато . сек. 7.1.3. дои : 10.17487/RFC6455 . РФК 6455 .
  27. ^ "ЗАКРЫТО" . ЧТОРГ . Архивировано из оригинала 12 марта 2023 г. Проверено 10 апреля 2024 г.
  28. ^ Открытие рукопожатия . сек. 1.3. дои : 10.17487/RFC6455 . РФК 6455 .
  29. ^ Требование клиента 8. п. 18. дои : 10.17487/RFC6455 . РФК 6455 .
  30. ^ Требование клиента 9. п. 18. дои : 10.17487/RFC6455 . РФК 6455 .
  31. ^ Требование клиента 7. п. 18. дои : 10.17487/RFC6455 . РФК 6455 .
  32. ^ Сервер шаг 5.4. п. 24. дои : 10.17487/RFC6455 . РФК 6455 .
  33. ^ Требование клиента 6. п. 18. дои : 10.17487/RFC6455 . РФК 6455 .
  34. ^ Шаг сервера 5.3 . п. 24. дои : 10.17487/RFC6455 . РФК 6455 .
  35. ^ Требование клиента 5. п. 17. дои : 10.17487/RFC6455 . РФК 6455 .
  36. ^ Шаг сервера 5.2 . п. 24. дои : 10.17487/RFC6455 . РФК 6455 .
  37. ^ Требование клиента 10. р. 18. дои : 10.17487/RFC6455 . РФК 6455 .
  38. ^ Обзор протокола . сек. 1.2. дои : 10.17487/RFC6455 . РФК 6455 .
  39. ^ «Основная цель протокола WebSocket» . IETF. Архивировано из оригинала 22 апреля 2016 года . Проверено 25 июля 2015 г. Вычисление [...] предназначено для предотвращения предоставления посредником кэширования WS-клиенту кэшированного ответа WS-сервера без фактического взаимодействия с WS-сервером.
  40. ^ Фрагментация . сек. 5.4. дои : 10.17487/RFC6455 . РФК 6455 .
  41. ^ Джон А. Тэмплин; Такеши Ёсино (2013). Расширение мультиплексирования для WebSockets . IETF . ID черновика-ietf-hybi-websocket-multiplexing.
  42. ^ КОНЕЦ . п. 28. дои : 10.17487/RFC6455 . РФК 6455 .
  43. ^ РСВ1, РСВ2, РСВ3 . п. 28. дои : 10.17487/RFC6455 . РФК 6455 .
  44. ^ Маска . п. 29. дои : 10.17487/RFC6455 . РФК 6455 .
  45. ^ Длина полезной нагрузки . п. 29. дои : 10.17487/RFC6455 . РФК 6455 .
  46. ^ Обзор . сек. 5.1. дои : 10.17487/RFC6455 . РФК 6455 .
  47. ^ Маскирование между клиентом и сервером . сек. 5.3. дои : 10.17487/RFC6455 . РФК 6455 .
  48. ^ Заключительное рукопожатие . сек. 1.4. дои : 10.17487/RFC6455 . РФК 6455 .
  49. ^ Закрывать . сек. 5.5.1. дои : 10.17487/RFC6455 . РФК 6455 .
  50. ^ Пинг . сек. 5.5.2. дои : 10.17487/RFC6455 . РФК 6455 .
  51. ^ Понг . сек. 5.5.3. дои : 10.17487/RFC6455 . РФК 6455 .
  52. ^ Зарезервированные диапазоны кодов состояния . сек. 7.4.2. дои : 10.17487/RFC6455 . РФК 6455 .
  53. ^ Определенные коды состояния . сек. 7.4.1. дои : 10.17487/RFC6455 . РФК 6455 .
  54. ^ Диркьян Охтман (27 мая 2011 г.). «WebSocket включен в Firefox 6» . Мозилла.орг . Архивировано из оригинала 26 мая 2012 г. Проверено 30 июня 2011 г.
  55. ^ «Состояние веб-платформы Chromium» . Архивировано из оригинала 4 марта 2017 г. Проверено 3 августа 2011 г.
  56. ^ «Вебсокеты (Windows)» . Майкрософт. 28 сентября 2012 г. Архивировано из оригинала 25 марта 2015 г. Проверено 7 ноября 2012 г.
  57. ^ «Отчет о тестировании протокола WebSockets» . Тавендо.де. 27 октября 2011 г. Архивировано из оригинала 22 сентября 2016 г. Проверено 10 декабря 2011 г.
  58. ^ Кэти Марсал (23 ноября 2010 г.). «Apple добавляет акселерометр и поддержку WebSockets в Safari в iOS 4.2» . AppleInsider.com . Архивировано из оригинала 1 марта 2011 г. Проверено 9 мая 2011 г.
  59. ^ «API веб-сокетов» . Ежевика . Архивировано из оригинала 10 июня 2011 года . Проверено 8 июля 2011 г.
  60. ^ Крис Хейлманн (8 декабря 2010 г.). «WebSocket отключен в Firefox 4» . Хакс.Mozilla.org . Архивировано из оригинала 6 марта 2017 г. Проверено 9 мая 2011 г.
  61. ^ Александр Аас (10 декабря 2010 г.). «Относительно WebSocket» . Мой оперный блог . Архивировано из оригинала 15 декабря 2010 г. Проверено 9 мая 2011 г.
  62. ^ Ван, Ванесса; Салим, Фрэнк; Московиц, Петр (февраль 2013 г.). «ПРИЛОЖЕНИЕ A: Проверка фрейма WebSocket с помощью инструментов разработчика Google Chrome» . Полное руководство по HTML5 WebSocket . Апресс. ISBN  978-1-4302-4740-1 . Архивировано из оригинала 31 декабря 2015 года . Проверено 7 апреля 2013 г.
  63. ^ «WebSockets (поддержка в Firefox)» . http://developer.mozilla.org . Фонд Мозилла. 30 сентября 2011 г. Архивировано из оригинала 26 мая 2012 г. Проверено 10 декабря 2011 г.
  64. ^ «Ошибка 640003 — WebSockets — обновление до ietf-06» . Фонд Мозилла. 08.03.2011. Архивировано из оригинала 01 апреля 2021 г. Проверено 10 декабря 2011 г.
  65. ^ «Вебсокеты — MDN» . http://developer.mozilla.org . Фонд Мозилла. 30 сентября 2011 г. Архивировано из оригинала 26 мая 2012 г. Проверено 10 декабря 2011 г.
  66. ^ «Ошибка 640003 — WebSockets — обновление до ietf-07 (комментарий 91)» . Фонд Мозилла. 22 июля 2011 г. Архивировано из оригинала 01 апреля 2021 г. Проверено 28 июля 2011 г.
  67. ^ «Ошибка Chrome 64470» . code.google.com . 25 ноября 2010 г. Архивировано из оригинала 31 декабря 2015 г. Проверено 10 декабря 2011 г.
  68. ^ «Веб-сокеты в Windows Consumer Preview» . Инженерная группа IE . Майкрософт. 19 марта 2012 г. Архивировано из оригинала 06 сентября 2015 г. Проверено 23 июля 2012 г.
  69. ^ «Набор изменений WebKit 97247: WebSocket: обновите протокол WebSocket до hybi-17» . trac.webkit.org . Архивировано из оригинала 05 января 2012 г. Проверено 10 декабря 2011 г.
  70. ^ «Жаркий летний снимок Оперы в 12.50» . Новости разработчиков Opera. 03.08.2012. Архивировано из оригинала 5 августа 2012 г. Проверено 3 августа 2012 г.
  71. ^ «Добро пожаловать в nginx!» . nginx.org . Архивировано из оригинала 17 июля 2012 года . Проверено 3 февраля 2022 г.
  72. ^ «Использование NGINX в качестве прокси-сервера WebSocket» . НГИНКС . 17 мая 2014 года. Архивировано из оригинала 6 октября 2019 года . Проверено 3 ноября 2019 г.
  73. ^ «Обзор новых функций Apache HTTP Server 2.4» . Апач . Архивировано из оригинала 11 ноября 2020 г. Проверено 26 января 2021 г.
  74. ^ «Журнал изменений Apache 2.4» . Зал Апач . Архивировано из оригинала 22 января 2021 г. Проверено 26 января 2021 г.
  75. ^ «Поддержка протокола IIS 8.0 WebSocket» . Документы Майкрософт . 28 ноября 2012 г. Архивировано из оригинала 18 февраля 2020 г. Проверено 18 февраля 2020 г.
  76. ^ «Выпуск-1 4 46 — Lighttpd — лайтти лабс» . Архивировано из оригинала 16 января 2021 г. Проверено 29 декабря 2020 г.
  77. ^ «Выпуск-1 4 65 — Lighttpd — лайтти лабс» . Архивировано из оригинала 3 мая 2024 г. Проверено 3 мая 2024 г.
  78. ^ Кристиан Шнайдер (31 августа 2013 г.). «Межсайтовый перехват веб-сокетов (CSWSH)» . Блог о безопасности веб-приложений . Архивировано из оригинала 31 декабря 2016 года . Проверено 30 декабря 2015 г.
  79. ^ Питер Любберс (16 марта 2010 г.). «Как веб-сокеты HTML5 взаимодействуют с прокси-серверами» . Infoq.com . C4Media Inc. Архивировано из оригинала 8 мая 2016 г. Проверено 10 декабря 2011 г.
  80. ^ Вилли Тарро (6 июля 2010 г.). «WebSocket -76 несовместим с обратными прокси-серверами HTTP» . ietf.org (электронная почта). Рабочая группа по интернет-инжинирингу. Архивировано из оригинала 17 сентября 2016 г. Проверено 10 декабря 2011 г.
  81. ^ Ян Фетт (13 июня 2011 г.). «Sec-WebSocket-Key» . Протокол WebSocket, проект hybi-09 . сек. 11.4 . Проверено 15 июня 2011 г. Архивировано 1 февраля 2016 г. в Wayback Machine.
[ редактировать ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=WebSocket&oldid=1228117160"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 7fe85ed54d4df80b228610c0293c05fc__1717935360
URL1:https://arc.ask3.ru/arc/aa/7f/fc/7fe85ed54d4df80b228610c0293c05fc.html
Заголовок, (Title) документа по адресу, URL1:
WebSocket - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)