WebSocket — протокол полнодуплексной двунаправленной связи

Размещено на http://www.allbest.ru/

Реферат

WebSocket

WebSocket -- протокол полнодуплексной двунаправленной связи поверх TCP соединения, предназначенный для обмена сообщениями между браузером и веб-сервером в режиме реального времени.

В настоящее время в W3C происходит стандартизация API Web Sockets, а в IETF находится на утверждении стандарт протокола Web Socket.

Открытие канала WebSocket

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

Протокол 75

До редакции черновика протокола номер 75 включительно соединение WebSocket устанавливалось следующим образом. Запрос клиента:

GET /demo HTTP/1.1

Upgrade: WebSocket

Connection: Upgrade

Host: example.com

Origin: http://example.com

WebSocket-Protocol: sample

Ответ сервера, подтверждающий переход на WebSocket:

HTTP/1.1 101 Web Socket Protocol Handshake

Upgrade: WebSocket

Connection: Upgrade

WebSocket-Origin: http://example.com

WebSocket-Location: ws://example.com/demo

WebSocket-Protocol: sample

Сразу после отправки ответа WebSocket соединение считается установленным, клиент и сервер могут начинать двунаправленный обмен сообщениями по этому же TCP-соединению. Для передачи текстового сообщения (в формате UTF-8) необходимо перед ним передать нулевой байт, а после -- байт со значением 255.

Протокол 76

Начиная с 2 июня 2010 года в протокол WebSocket были внесены изменения, изменившие процедуру установления соединения WebSocket без сохранения обратной совместимости. В 76-ой редакции черновика протокола WebSocket добавлена защита от поддельных запросов. Клиент, поддерживающий новую схему, присылает следующий запрос:

GET /demo HTTP/1.1

Upgrade: WebSocket

Connection: Upgrade

Sec-WebSocket-Key2: 4 @1 46546xW%0l 1 5

Host: example.com

Sec-WebSocket-Key1: 12998 5 Y3 1 .P00

Origin: http://example.com

WebSocket-Protocol: sample

^n:ds[4U

В запрос добавлены новые заголовки "Sec-WebSocket-Key1" и "Sec-WebSocket-Key2" и 8-байтовое тело запроса. Все они генерируются клиентом случайным образом.

Ответ сервера, подтверждающий переход на WebSocket:

HTTP/1.1 101 Web Socket Protocol Handshake

Upgrade: WebSocket

Connection: Upgrade

Sec-WebSocket-Origin: http://example.com

Sec-WebSocket-Location: ws://example.com/demo

Sec-WebSocket-Protocol: sample

8jKS'y:G*Co,Wxa-

Ответ содержит новые названия заголовков ("Sec-WebSocket-Origin","Sec-WebSocket-Location","Sec-WebSocket-Protocol" вместо "WebSocket-Origin", "WebSocket-Location","WebSocket-Protocol") и 16-байтное тело ответа, вычисляемое следующим образом:

из строки со значением заголовка запроса Sec-WebSocket-Key1 исключить все символы, не являющиеся цифрами (не попадающие в диапазон '0'..'9');

полученную строку превратить в 64-битное целое число (для примера выше получим 1299853100);

полученное число разделить целочисленным делением на количество пробелов в исходной строке со значением заголовка;

полученное число представить в виде 4-х байтового 32-битного числа в формате big endian: старший байт хранится по нулевому смещению;

проделать то же самое с заголовком Sec-WebSocket-Key2;

интерпретируя числа из пунктов 4) и 5) как 4-х байтовые строки, конкатенировать их (сложить в одну строку) и добавить как строку тело запроса;

вычислить от полученной 16-байтной строки значение MD5 и записать это значение в тело ответа "как есть", без преобразования в какое-либо представление;

Примечания.

Несмотря на "похожесть" новых запросов и ответов на запросы и ответы протокола HTTP, они таковыми не являются. Например, в запросе есть тело, но в заголовках поле "Content-Length" отсутствует (что нарушает соглашения HTTP).

Серверной части следует поддерживать оба вида клиентов и отличать их по наличию или отсутствию в запросе заголовков Sec-WebSocket-Key1 и Sec-WebSocket-Key2.

Протокол 07

В 07-ой версии черновика протокола от 22 апреля 2011 были внесены изменения. Клиент присылает следующий запрос:

GET /chat HTTP/1.1

Host: server.example.com

Upgrade: websocket

Connection: Upgrade

Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

Sec-WebSocket-Origin: http://example.com

Sec-WebSocket-Protocol: chat, superchat

Sec-WebSocket-Version: 7

Ответ сервера имеет следующий вид:

HTTP/1.1 101 Switching Protocols

Upgrade: websocket

Connection: Upgrade

Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Sec-WebSocket-Protocol: chat

Ответ содержит заголовок Sec-WebSocket-Protocol с единственным протоколом, выбранным сервером (chat) из всех поддерживаемых клиентом (chat, superchat). Заголовок Sec-WebSocket-Accept формируется следующим образом:

взять строковое значение из заголовка Sec-WebSocket-Key и сконкатенировать со строкой 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 (в приведённом примере получится dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA-C5AB0DC85B11)

вычислить хеш SHA-1 от полученой строки (получится 0xb3 0x7a 0x4f 0x2c 0xc0 0x62 0x4f 0x16 0x90 0xf6 0x46 0x06 0xcf 0x38 0x59 0x45 0xb2 0xbe 0xc4 0xea)

закодировать хеш в base64 (s3pPLMBiTxaQ9kYGzzhZRbK+xOo=)

Схема URL

Протокол Web Socket определяет две URI схемы, ws: (нешифрованное соединение) и wss: (шифрованное соединение).

Реализация WebSocket в браузерах

Для установки соединения скрипт создает новый объект WebSocket, которому в параметре передает WebSocket URI и определяет функции обратного вызова при установлении соединения, получении сообщения и разрыве соединения.

<html>

<head>

<script>

var webSocket = new WebSocket('ws://localhost/echo');

webSocket.onopen = function(event) {

alert('onopen');

webSocket.send("Hello Web Socket!");

};

webSocket.onmessage = function(event) {

alert('onmessage, ' + event.data);

webSocket.close();

};

webSocket.onclose = function(event) {

alert('onclose');

};

</script>

</head>

<body>

</body>

</html>

В настоящее время WebSocket поддерживается в следующих браузерах:

Google Chrome (начиная с версии 4.0.249.0);

Apple Safari (начиная с версии 5.0.7533.16);

Mozilla Firefox (начиная с версии 4);

Opera (начиная с версии 10.70 9067);

В конце ноября 2010 Adam Barth опубликовал результаты исследования надежности используемого протокола. По его результатам выяснилось, что в случае использования прозрачных прокси-серверов, возможна подмена кеша передаваемых данных с тем, что пользователи вместо реальных данных будут получать версию данных от злоумышленника. Проблема оказалась довольно серьезной для того, чтобы разработчики Firefox и Opera объявили, что до устранения проблем в будущих версиях их браузеров поддержка веб-сокетов будет закрыта, хотя осталась возможность их включить.

браузер сервер запрос

Размещено на Allbest.ru