Сетевые технологии websocket

Московский государственный университет  Приборостроения и информатики

 

 

 

 

 

 

 

 

Факультет “Информатики”

Реферат по дисциплине

“СЕТЕВЫЕ ТЕХНОЛОГИИ”

WebSocket

 

 

 

 

студента  группы ИТ-4 0906

вечернего отделения

Тихомирова Андрея

 

 

 

 

 

 

Москва, 2012

WebSocket

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

В настоящее время в W3C осуществляется стандартизация API Web Sockets. Черновой вариант стандарта этого протокола утверждён IETF.

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

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

WebSockets — полноценный асинхронный веб

Google Chromium опубликовали новость о поддержке технологии WebSocket. Моментально разработчики самых разных серверов/библиотек/фреймворков (в их числе Apache, EventMachine, Twisted, MochiWeb и т.д.) объявили о том, что поддержка ВебСокетов будет реализована в их продуктах в ближайшее время. 
Что же такого интересного сулит нам технология? WebSocket — это самое кардинальное расширение протокола HTTP с его появления. Это не финтифлюшки, это сдвиг  парадигмы HTTP. Изначально синхронный протокол, построенный по модели «запрос — ответ», становится полностью асинхронным и симметричным. Теперь уже нет клиента и сервера с фиксированными ролями, а есть два равноправных участника обмена данными. Каждый работает сам по себе, и когда надо отправляет данные другому. Отправил — и пошел дальше, ничего ждать не надо. Вторая сторона ответит, когда захочет — может не сразу, а может и вообще не ответит. Протокол дает полную свободу в обмене данными, вам решать как это использовать. 
 
— веб-приложения с интенсивным обменом данными, требовательные к скорости обмена и каналу; 
— приложения, следующие стандартам; 
— «долгоиграющие» веб-приложения; 
— комплексные приложения со множеством различных асинхронных блоков на странице; 
— кросс-доменные приложения.

И как это работает?

 
Очень просто! Как только ваша страница решила, что она хочет открыть  веб сокет на сервер, она создает  специальный javascript-объект:

1. <script>
2. ws = new WebSocket("ws://site.com/demo"); 
3. // первый колбек вызывается когда соединение будет установлено:
4. ws.onopen = function() { alert("Connection opened...") }; 
6. // второй - когда соединено закроется
7. ws.onclose = function() { alert("Connection closed...") }; 
9. // и, наконец, третий - каждый раз, когда браузер получает какие-то данные через веб-сокет
10. ws.onmessage = function(evt) { $("#msg").append("<p>"+evt.data+"</p>"); }; 
12. </script>

* This source code was highlighted with Source Code Highlighter.

А что при этом происходит в сети?

 
Все начинается так же как в обычном HTTP-запросе. Браузер подключается по протоколу TCP на 80 порт сервера и дает немного необычный GET-запрос:

GET /demo HTTP/1.1 
Upgrade: WebSocket 
Connection: Upgrade 
Host: site.com 
Origin: http://site.com

 
Если сервер поддерживает ВебСокеты, то он отвечает таким образом:

HTTP/1.1 101 Web Socket Protocol Handshake 
Upgrade: WebSocket 
Connection: Upgrade 
WebSocket-Origin: http://site.com 
WebSocket-Location: ws://site.com/demo

 
 
Если браузер это устраивает, то он просто оставляет TCP-соединение открытым. Все — «рукопожатие» совершено, канал обмена данными готов. 
Как только одна сторона хочет передать другой какую-то информацию, она отправляет дата-фрейм следующего вида:

0x00, <строка в кодировке UTF-8>, 0xFF

 
То есть просто строка текста — последовательность байт, к которой спереди приставлен нулевой байт 0x00, а в конце — 0xFF. И все — никаких заголовков, метаданных! Что именно отправлять, разработчики полностью оставили на ваше усмотрение: хотите XML, хотите JSON. 
Каждый раз, когда браузер будет получать такое сообщение, он будет «дергать» ваш колл-бек onmessage.  
 
Легко понять, что КПД такого протокола стремится к 95%. Это не классический AJAX-запрос, где на каждую фитюльку приходится пересылать несколько килобайт заголовков. Разница будет особенно заметна если делать частый обмен небольшими блоками данных. Скорость обработки так же стремится к скорости чистого TCP-сокета — ведь все уже готово — соединение открыто — всего лишь байты переслать.

Лирическое  отступление: 
И еще одна вещь, которая меня очень радует - в качестве единственной разрешенной кодировки выбрана UTF-8! Я уже робко надеюсь, что через некоторое время мы уйдем от одного из костылей веба.

А картинку можно отправить?

 
С помощью WebSockets так же можно передавать и бинарные данные. Для них используется другой дата-фрейм следующего вида:

0x80, <длина - один или несколько  байт>, <тело сообщения>

 
Что значит «один или несколько  байт»? Чтобы не создавать ограничений  на длину передаваемого сообщения  и в тоже время не расходовать  байты нерационально, разработчики использовали очень хитрый способ указания длины тела сообщения. Каждый байт в  указании длины рассматривается  по частям: самый старший бит указывает является ли этот байт последним (0) либо же за ним есть другие (1), а младшие 7 битов содержат собственно данные. Обрабатывать можно так: как только вы получили признак бинарного дата-фрейма 0x80, вы берете следующий байт и откладываете его в отдельную «копилку», смотрите на следующий байт — если у него установлен старший бит, то переносите и его в «копилку», и так далее, пока вам не встретится байт с 0 старшим битом. Значит это последний байт в указателе длины — его тоже переносите в «копилку». Теперь из всех байтов в «копилке» убираете старшие биты и слепляете остаток. Вот это и будет длина тела сообщения. Еще можно интерпретировать как 7-битные числа без старшего бита. 
 
Например, самую главную картинку веб-дизайна — прозначный однопиксельный GIF размером 43 байта можно передать так:

0x80, 0x2B, <тело сообщения>

 
Объект размером 160 байт закодируется 2 байтами длины:

0x80, 0x81, 0x20, <байты объекта>

 
Не правда ли, очень элегантно?

Что это нам  дает?

Скорость и эффективность

 
Высокую скорость и эффективность  передачи обеспечивает малый размер передаваемых данных, который иногда даже будет помещаться в один TCP-пакет  — здесь, конечно, же все зависит от вашей бизнес-логики. (В дата-фрейм можно засунуть и БСЭ, но для такой передачи потребуется чуть больше 1 TCP- пакета. :) ). 
Так же учтите, что соединение уже готово — не надо тратить время и трафик на его установление, хендшейки, переговоры.

Стандартность

 
Самим своим выходом WebSockets отправит на свалку истории Comet и все приблуды накрученные поверх него — Bayuex, LongPolling, MultiPart и так далее. Это все полезные технологии, но по большей части, они работают на хаках, а не стандартах. Отсюда периодески возникают проблемы: то прокся ответ «зажевала» и отдала его только накопив несколько ответов. Для «пробивания» проксей часто использовался двух-килобайтный «вантуз» — т.е. объем передаваемых данных увеличивался пробелами (или другими незначащими символами) до 2К, которые многие прокси передавали сразу, не задерживая. Периодически антивирусы выражали свое желание получить ответ полностью, проверить его, и только потом передать получателю. Конечно, сегодня все эти проблемы более-менее решены — иначе бы не было такого большого кол-ва веб-приложений. Однако, развитие в этом направлении сопряжено с появлением новых проблем — именно потому, что это попытка делать в обход стандарта. 
 
На мой взгляд, через некоторое время останется только 2 технологии: чистый AJAX и WebSockets. Первая хороша для одно- или несколькоразовых обновлений на странице — действительно, врядли рационально для этого раскочегаривать мощную машину веб-сокетов. А все остальное, что сейчас делается кометом и коллегами, переедет на веб-сокеты, т.к. это будет проще и эффективнее. Например, вы хотите вживую мониторить цены на рынке форекс. Пожалуйста: открывайте сокет — сервер вам будет присылать все обновления. Ваша задача только повесить правильный колл-бек на событие onmessage и менять циферки на экране. Вы решили что-то прикупить, отправьте серверу асинхронное сообщение, а параллельно продолжайте получать циферки. Элегантно? По сравнению с этим LongPolling с необходимостью периодческого рестарта даже неактивного канала (чтобы его прокся или еще кто не прихлопнул) выглядит грязным хаком.

Время жизни канала

 
В отличие от HTTP веб-сокеты не имеют  ограничений на время жизни в  неактивном состоянии. Это значит, что  больше не надо периодически рефрешить соединение, т.к. его не вправе «прихлопывать» всякие прокси. Значит, соединение может висеть в неактивном виде и не требовать ресурсов. Конечно, можно возразить, что на сервере будут забиваться TCP-сокеты. Для этого достаточно использовать хороший мультиплексор, и нормальный сервер легко потянет до миллиона открытых коннектов.

Комплексные веб-приложения

 
Как известно в HTTP предусмотрено ограничение  на число одновременных октрытых сессий к одному серверу. Из-за этого если у вас много различных асинхронных блоков на странице, то вам приходилось делать не только серверный, но и клиентский мультиплексор — именно отсюда идет Bayeux Protocol.  
К счастью, это ограничение не распространяется на веб-сокеты. Открываете столько, сколько вам нужно. А сколько использовать — одно (и через него все мультиплексировать) или же наоборот — на каждый блок свое соединение — решать вам. Исходите из удобства разработки, нагрузки на сервер и клиент.

Кросс-доменные приложения

 
И еще один «камень в ботинке» AJAX-разработчика — проблемы с кросс-доменными приложениями. Да, и для них тоже придумана масса хаков. Помашем им ручкой и смахнем скупую слезу. WebSockets не имеет таких ограничений. Ограничения вводятся не по принципу «из-того-же-источника», а из «разрешенного-источника», и определяются не на клиенте, а на сервере. Думаю, внимательные уже заметили новый заголовок Origin. Через него передается информация откуда хотят подключиться к вашему websocket-у. Если этот адрес вас не устраивает, то вы отказываете в соединение.

В настоящее время 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 объявили о том, что в будущих версиях их браузеров поддержка веб-сокетов будет по умолчанию отключена вплоть до устранения проблемы небезопасности данного протокола (хотя осталась возможность их включить).

Выводы

 
На мой взгляд, как только люди распробуют, эта технология получить очень широкое распространение. К весне-лету мы получим массу  сайтов с ней. И как в свое время  несколько лет прошло «под звездой AJAX», так и здесь год-другой мы будем слышать отзывы о внедрении  WebSockets повсеместно.

 

 

 

 

 

 

 

 

Список используемой литературы

1. Интернет портал

 http://habrahabr.ru/

2. Интернет портал

http://ru.wikipedia.org/wiki/WebSocket