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

WebSocket - протокол полнодуплексной двунаправленной связи поверх TCP-соединения, предназначенный для обмена сообщениями между браузером и веб-сервером в режиме реального времени. Программисты и ранее пытались решить проблему «равноправия» между сервером и клиентом. Они экспериментировали с двунаправленной связью, используя запросы XMLHttpRequest. Но это было очень медленно, так как каждый раз приходилось создавать новое TCP-соединение для каждого сообщения.
В отличие от XMLHttpRequest WebSockets устанавливает одно TCP-соединение и подтверждает, что сервер может общаться с WebSocket, делая специальные проверки, после чего сервер и клиент могут отправлять текстовые сообщения через установленное соединение при необходимости, в результате чего связь становится быстрее. Соединение постоянно держится открытым, но не передаёт лишних HTTP заголовков. При этом в веб-сокетах нет ограничений на количество соединений.

В настоящее время в World Wide Web Consortium (W3C) происходит стандартизация API Web Sockets, а в Internet Engineering Task Force (IETF) находится на утверждении стандарт протокола Web Socket.
В той или иной мере WebSocket поддерживается в следующих браузерах:

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

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

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

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

Разные версии браузеров поддерживают разные версии протоколов. Причем само развитие протокола позволяет предполагать, что со временем он может измениться несовместимым образом. Однако, маловероятно что изменится WebSocket API. Как работает протокол? Как только страница сайта решила, что она хочет открыть WebSocket на сервер, она создает специальный javascript-объект. Все начинается так же как в обычном HTTP-запросе. Браузер подключается по протоколу TCP на 80-й порт сервера, но дает немного необычный GET-запрос, и, если сервер поддерживает WebSocket, то он отвечает. Если браузер это устраивает, то он просто оставляет TCP-соединение открытым. Все - установление связи совершено, канал обмена данными готов.
Как только одна сторона хочет передать другой какую-то информацию, она отправляет дата-фрейм следующего вида:
0x00, , 0xFF
То есть просто строка текста - последовательность байт, к которой спереди приставлен нулевой байт 0x00, а в конце - 0xFF. Без заголовков и метаданных. Что именно отправлять, разработчики полностью оставили на усмотрение разработчиков сайтов: XML, JSON, простой текст.

С помощью протокола WebSockets так же можно передавать и бинарные данные, в смысле картинки. Для них используется другой дата-фрейм следующего вида:
0x80, ,
«Один или несколько байт» - очень хитрый способ указания длины тела сообщения. Чтобы не создавать ограничений на длину передаваемого сообщения и в тоже время не расходовать байты нерационально, разработчики протокола использовали следующий алгоритм. Каждый байт в указании длины рассматривается по частям: самый старший бит указывает, является ли этот байт последним (0) или же за ним есть другие (1), а младшие 7 битов содержат собственно данные.
Соответственно, как только получается признак бинарного дата-фрейма 0x80, то берется следующий байт и откладывается его в отдельную «копилку», потом на следующий байт - если у него установлен старший бит, то переносится и его в «копилку». И так далее, пока вам не встретится байт со старшим битом - 0. Это означит что этот байт - последний в указателе длины. Он также складывается в «копилку». Теперь из всех байтов в «копилке» убираются старшие биты и соединяется в единое целое остаток. Вот это и будет длина тела сообщения.
КПД такого протокола стремится к 95%. Разница будет особенно заметна, если делать частый обмен небольшими блоками данных. Скорость обработки также стремится к скорости чистого TCP-сокета - ведь все уже готово - соединение открыто - всего лишь байты переслать.

Нюансы протокола У протокола есть свои плюсы и минусы. Причем первых существенно больше.

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

Стандартность , которая устранит потребность в целом ряде технологий: Comet и все что накручено поверх него (Bayuex, LongPolling, MultiPart и так далее), работающее на хаках, а не стандартах.

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

Комплексные веб-приложения - в HTTP предусмотрено ограничение на число одновременных открытых сессий к одному серверу. Поэтому для множества различных асинхронных блоков на странице приходится делать не только серверный, но и клиентский мультиплексор. Это ограничение не распространяется на протокол WebSocket. Открывается столько, сколько необходимо.

Кросс-доменные приложения - о граничения в протоколе вводятся не по принципу «из-того-же-источника», а из «разрешенного-источника», и определяются не на клиенте, а на сервере.

Еще одна особенность: в качестве единственной разрешенной кодировки выбрана UTF-8. Теперь о минусах.

В конце ноября 2010 Адам Барт (Adam Barth) опубликовал результаты исследования надежности WebSocket. По его результатам выяснилось, что в случае использования прозрачных прокси-серверов возможна подмена кеша передаваемых данных. То есть пользователи вместо реальных данных могут получать версию данных от злоумышленника. Проблема оказалась довольно серьезной. В результате разработчики Firefox и Opera объявили, что до устранения проблем в будущих версиях их браузеров поддержка WebSocket будет закрыта, хотя они и оставили возможность их включить.
Отметим особую роль разработчиков Opera, которые создали Opera"s WebSockets testsuite. Этот тест охватывает как сам протокол, так и API, пытаясь проверить все аспекты спецификаций, включая обработку ошибок и непредвиденного поведения. Было найдено большое количество багов и несоответствий в спецификациях. Отзыв об этом был отправлен рабочей группе, работающей со спецификациями.

Возникают у Websockets проблемы и с антивирусами. Так в одном из проектов, переводимых на этот протокол, выяснилось, что все пользователи, кто использовал антивирус Avast в дефолтной конфигурации, не могли нормально работать с приложением. В Avast по умолчанию включен режим так называемого «Вэб-экрана», который решил, что Websocket протокол плохой, и молча «резал» его.

Кому нужен этот протокол? WebSocket крайне полезен для тех разработчиков, кто создает:
- веб-приложения, с интенсивным обменом данными, требовательные к скорости обмена и каналу;
- приложения, следующие стандартам;
- «долгоиграющие» веб-приложения;
- комплексные приложения с множеством различных асинхронных блоков на странице;
- кросс-доменные приложения.
На протоколе WebSocket создано уже достаточно много приложений. Самое известные – это, наверное, разработки компании Kaazing, компания, которая давно ориентируется на WebSocket. Компания внедрила технологию, которая помогает выводить меняющиеся финансовые данные, поступающих извне. Одно из таких постоянно обновляет котировки фондового рынка. Резюме Очень скоро придет эра HTML 5 приложений. Для пользователей это означает еще больше интерактива и новых возможностей, в первую очередь, благодаря технологии Websockets. Мы надеемся, что эта технология получит очень широкое распространение. И как в свое время несколько лет прошло под эгидой AJAX, так теперь, через год-другой мы будем слышать отзывы о внедрении WebSockets повсеместно.

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

Краткая история веб-приложений реального времени

Интернет был построен на представлении о том, что забота браузера– запрос данных с сервера, а забота сервера – обслуживание этих запросов. Эта парадигма не подвергалась сомнению несколько лет. Но с появлением AJAX в 2005 году многие начали работать над созданием двунаправленных соединений.

Веб-приложения значительно увеличивались в размере. Сдерживающим фактором для их роста была традиционная модель HTTP. Чтобы преодолеть это, были созданы несколько стратегий, позволяющих серверам «проталкивать» (push) данные клиенту. Одной из наиболее популярных стала стратегия «длинного опроса» . Она подразумевает поддержание HTTP- соединения открытым до тех пор,пока у сервера есть данные для отправки клиенту.

Но все эти технологии приводят к перегрузке HTTP. Каждый раз, когда вы делаете запрос HTTP, набор заголовков и cookie передаются на сервер. Они накапливаются в большие массивы информации, которые нужно передать. Это увеличивает время ожидания, что может быть критично для равномерной работы приложения.

Чтобы решить данную проблему, нужен был способ создания постоянного соединения с минимальными задержками, которое могло бы поддерживать транзакции, инициированные как клиентом, так и сервером. Это как раз то, что предоставляют веб-сокеты.

Как работают веб-сокеты

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

Браузер устанавливает соединение по веб-сокету при помощи «рукопожатия». Этот процесс начинается с отправки клиентом обычного запроса HTTP на сервер. В этот запрос включается заголовок Upgrade, который сообщает серверу, что браузер хочет установить соединение по веб-сокету.

Вот упрощённый пример первоначальных заголовков запроса.

GET ws ://websocket.example.com/ HTTP/1.1

Origin : http://example.com

Connection : Upgrade

Host : websocket.example.com

Upgrade : websocket

Замечание : URL-адреса веб-сокетов используют протокол ws . Также существует протокол wss для безопасных соединений, который является эквивалентом HTTPS.

Если сервер поддерживает протокол WebSocket, он сообщает об этом с помощью заголовка Upgrade в ответе.

HTTP /1.1 101 WebSocket Protocol Handshake

Connection : Upgrade

Upgrade : WebSocket

После того, как рукопожатие выполнено, первоначальное соединение HTTP заменяется соединением по веб-сокету, которое использует то же соединение TCP/IP . На этом этапе любая из сторон может начать отправку данных.

С помощью веб-сокетов можно передавать неограниченный объем информации без добавления данных, связанных с запросами (как в HTTP). Данные передаются через веб-сокет как сообщения, каждое из которых состоит из одного или большего количества фрагментов.

Чтобы убедиться, что сообщение будет правильно интерпретировано на стороне клиента, каждому фрагменту предшествуют от 4 до 12 байт данных о полезной нагрузке. Использование обмена сообщениями на основе фрагментов позволяет снизить объем дополнительных данных, что приводит к сокращению задержек.

Замечание : Стоит отметить, что клиент будет уведомлен о новом сообщении только, когда сервер передаст все его фрагменты.

Создаём демо-пример Создание приложения на основе веб-сокетов

Мы создадим простое приложение, которое соединяется с сервером по веб-сокету. Перед тем, как мы углубимся в детали API, нужно создать несколько файлов.

Посмотреть пример

Загрузить код

Посмотреть на CodePen

Создайте файл index.html и добавьте в него следующую разметку.

WebSockets Demo WebSockets Demo Connecting... Send Message Close Connection

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

Файл style.css , на который ссылается этот код, находится в архиве для загрузки. Далее создадим файл app.js и добавим в него следующий код.

window.onload = function() { // Получаем ссылки на элементы страницы. var form = document.getElementById("message-form"); var messageField = document.getElementById("message"); var messagesList = document.getElementById("messages"); varsocketStatus = document.getElementById("status"); varcloseBtn = document.getElementById("close"); // Остальной код из этой статьи будет добавляться ниже... };

Мы создали несколько переменных и инициализировали их ссылками на ключевые элементы страницы.

Открытие соединений

Теперь, когда готов костяк приложения, можно начать изучать WebSocket API. Для начала узнаем, как создать новое соединение WebSocket. Для этого нужно вызвать конструктор класса WebSocket и передать ему URL сервера.

Скопируйте следующий код в файл app.js , чтобы создать новое соединение.

// Создаём новый объект WebSocket. varsocket = new WebSocket("ws://echo.websocket.org");

После того, как соединение установлено, возникнет событие open объекта WebSocket. Добавим обработчик события, который обновит статус элемента сообщением о том, что соединение установлено.

// Показываем сообщение «connected» при открытии веб-сокета. socket.onopen = function(event) { socketStatus.innerHTML = "Connected to: " + event.currentTarget.url; socketStatus.className = "open"; };

Также мы добавляем класс open элементу .

Обработка ошибок

Обработка ошибок осуществляется через событие error . Добавьте следующий код, который будет записывать ошибки в консоль.

// Обработка возникающих ошибок. socket.onerror = function(error) { console.log("WebSocket Error: " + error); };

Отправка сообщений

Чтобы отправить сообщение по веб-сокет, нужно вызвать метод send() объекта WebSocket, передав ему данные для отправки.

socket.send(data);

Можно отправлять как текст, так и двоичные данные. В нашем приложении нужно передавать содержимое текстового поля на сервер при отправке формы. Чтобы сделать это, надо определить обработчик события отправки формы.

Добавьте следующий код в файл app.js .

// Отправка сообщения при отправке формы form.onsubmit = function(e) { e.preventDefault(); // Получение сообщения из текстового поля. var message = messageField.value; // Отправка сообщения по веб-сокету. socket.send(message); // Добавление сообщения в список сообщений. messagesList.innerHTML += "Sent:" + message + ""; // Очистка текстового поля. messageField.value = ""; return false; };

При отправке формы приведенный выше код получит сообщение из messageField и отправит его через веб-сокет. Затем сообщение добавляется в messagesList и отображается на экране. После этого значение messageField очищается, чтобы пользователь мог ввести новое сообщение.

Получение сообщений

При получении сообщения вызывается событие message . Оно включает в себя свойство data , которое можно использовать для доступа к содержимому сообщения.

Нам нужно создать обработчик события, который будет вызываться при получении нового сообщения. Он должен получать сообщение от события и отображать его в messagesList .

Чтобы добиться этого, скопируйте следующий код в файл app.js .

// Обработка сообщений, отправленных сервером. socket.onmessage = function(event) { var message = event.data; messagesList.innerHTML += "Received:" + message + ""; };

Закрытие соединений

Когда вы закончите работу с веб-сокетом, нужно разорвать соединение, используя метод close() .

После того, как соединение будет разорвано, браузер вызовет событие close . Добавление обработчика события close позволит выполнить любую «уборку», которая потребуется.

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

// Показываем сообщение «disconnected», когда соединение разорвано. socket.onclose = function(event) { socketStatus.innerHTML = "Disconnectedfrom WebSocket."; socketStatus.className = "closed"; };

Чтобы завершить приложение, нужно добавить обработчик события, который будет вызываться при нажатии кнопки «Close Connection». Он должен вызывать метод close() объекта WebSocket.

// Закрываем соединение при нажатии кнопки «close» closeBtn.onclick = function(e) { e.preventDefault(); // Закрываем веб-сокет. socket.close(); return false; };

Наше приложение готово!

Откройте файл index.html в браузере и попробуйте отправить несколько сообщений. Вы увидите, что сервер отправляет сообщения обратно.

Мониторинг трафика веб-сокета с помощью инструментов для разработчиков в Chrome

«Инструменты разработчика», доступные в браузере Google Chrome включают в себя средства для мониторинга трафика. Чтобы использовать этот инструмент:

• Откройте «Инструменты разработчика».
• Перейдите на вкладку Network.
• Кликните по записи, соответствующей вашему соединению по веб-сокету.
• Перейдите на вкладку Frames.

Эти инструменты предоставляют общую информацию о данных, переданных через соединение.

WebSocket на сервере

В этой статье мы сфокусировали внимание на том, как использовать веб-сокеты на стороне клиента. Если вы хотите создать собственный сервер WebSocket, существует множество библиотек, которые могут в этом помочь. Одна из наиболее популярных – socket.io , библиотека Node.JS.

Другие библиотеки:

• C++: libwebsockets ;
• Erlang: Shirasu.ws ;
• Java: Jetty ;
• Node.JS: ws ;
• Ruby: em-websocket ;
• Python: Tornado , pywebsocket ;
• PHP: Ratchet , phpws .

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

Веб-сокеты поддерживаются практически во всех современных браузерах. Единственными исключениями являются Android- браузеры и Opera Mini.

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

Я считаю, что веб сокеты придутся ко двору, если вы разрабатываете:
- веб-приложения с интенсивным обменом данными, требовательные к скорости обмена и каналу;
- приложения, следующие стандартам;
- «долгоиграющие» веб-приложения;
- комплексные приложения со множеством различных асинхронных блоков на странице;
- кросс-доменные приложения.

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

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

< script >

ws = new WebSocket("ws://site.com/demo" );

// и навешивает на новый объект три колл-бека:

// первый вызовется, когда соединение будет установлено:

ws.onopen = function () { alert("Connection opened..." ) };

// второй - когда соединено закроется

ws.onclose = function () { alert("Connection closed..." ) };

// и, наконец, третий - каждый раз, когда браузер получает какие-то данные через веб-сокет

ws.onmessage = function (evt) { $("#msg" ).append("

" +evt.data+"

" ); };

* 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, , 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-у. Если этот адрес вас не устраивает, то вы отказываете в соединение.
Все! Конец кросс-доменной зопяной боли!А руками пощупать можно? Можно!

UPDATE: Одной из открытых реализаций веб-сокетов является чат на www.mibbit.com (заметка в их блоге).
PHP-реализация сервера WebSocket также представлена модулем к асинхронному фреймворку

(Web Sockets) - это передовая технология, которая позволяет создавать интерактивное соединение между клиентом (браузером) и сервером для обмена сообщениями в режиме реального времени. Веб-сокеты, в отличие от HTTP, позволяют работать с двунаправленным потоком данных, что делает эту технологию совершенно уникальной. Давайте разберемся, как работает эта технология и чем она отличается от HTTP.

Как работает HTTP?

Схема обмена сообщениями по HTTP

Вы наверняка знаете, что такое HTTP (или HTTPS), поскольку встречаетесь с этим протоколом каждый день в своём браузере. Браузер постоянно спрашивает у сервера, есть ли для него новые сообщения, и получает их.

Вы также можете знать, что HTTP позволяет использовать разные типы запросов, такие как POST, GET или PUT, каждый из которых имеет своё назначение.

Как работают веб-сокеты?

Схема обмена сообщениями при использовании веб-сокетов

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

Веб-сокеты можно использовать, если вы разрабатываете:

• приложения реального времени;
• чат-приложения;
• IoT-приложения;
• многопользовательские игры.

Когда следует избегать использования веб-сокетов?

Практически никогда. Единственный минус - это несовместимость с некоторыми браузерами, но уже 95 % браузеров поддерживают веб-сокеты.

В некоторых случаях веб-сокеты вам всё же не понадобятся. Если вы создаёте простую CMS, вам вряд ли пригодится функциональность в режиме реального времени. Также не стоит использовать веб-сокеты в REST API, поскольку вам хватит таких HTTP-запросов, как GET, POST, DELETE и PUT.

Практические примеры

В примерах ниже для клиента используется JavaScript, а для сервера - Node.js. Примеры очень просты и вряд ли пригодятся на практике, но зато позволят разобраться в сути.

Веб-сокеты

Пример чата с веб-сокетом let ws = new WebSocket("ws://localhost:8080"); // выводим новые сообщения в консоль ws.onmessage = ({data}) => { console.log(data); } // отправляем сообщение ws.onopen = () => ws.send("Text");

Const WebSocket = require("ws"); // создаём новый websocket-сервер const wss = new WebSocket.Server({ port: 8080 }); // отправляем клиентам, когда функция clientValidator возвращает true. this - это wss. wss.broadcast = function(data, clientValidator = () => true) { this.clients.forEach(client => { if (clientValidator(client)) { client.send(data); } }); } wss.on("connection", ws => { // событие будет вызвано, когда клиент отправит сообщение ws.on("message", message => { // отправляем сообщение всем, кроме автора wss.broadcast(message, client => client !== ws); }); });

Вот иллюстрация работы веб-сокетов:

Демонстрация работы веб-сокетов

Эквивалент в HTTP

Так как HTTP должен постоянно проверять канал на наличие новых сообщений, можно использовать «грязную» проверку (dirty check) - подход, при котором клиент с заданной периодичностью (допустим, каждые 200 мс) проверяет наличие новых сообщений на сервере.

Или getting started with WebSocket PHP без phpDaemon

Здравствуйте! Простите за столь длинный заголовок, но, надеюсь, что новичкам вроде меня будет легче найти эту статью, ведь мне ничего подобного найти не удалось. Несколько недель назад я принял решение переработать игровой клиент и сервер своей игры Growing Crystals с AJAX, на WebSocket, но всё оказалось не просто непросто, а очень сложно. Поэтому я и решил написать статью, которая бы помогла самым что ни на есть начинающим разработчикам на WebSocket + PHP сэкономить несколько дней времени, максимально подробно объясняя каждый свой шаг по настройке и запуску первого WebSocket скрипта на PHP.

Код сокет-сервера на PHP я приводить не буду, т.к. он есть в архиве и снабжен комментариями. Я искусственно ограничил время работы приёмки соединений 100 секундами, чтобы скрипт он не оставался в памяти, закрывал все соединения и не приходилось при внесении в него изменений постоянно перезагружать Денвер. При чем, по прошествии 100 секунд, скрипт не прекратит свою работу, а будет ждать подключения, после которого его работа будет завершена, а все сокеты благополучно закрыты. Также, для тестирования, я использую localhost и порт 889.

Socket_bind($socket, "127.0.0.1", 889);//привязываем его к указанным ip и порту

Файлы из архива можно поместить в корневую папку localhost Денвера. Алгоритм тестирования:

Запускаем http://localhost/socket.html , он автоматически подключится к ws echo серверу ws://echo.websocket.org, можно отправить несколько сообщений, которые сервер должен отправить обратно, ведь это же эхо-сервер. Если это работает - отлично, с клиентом всё в порядке, если нет, проверьте все ли вы файлы разместили в одном каталоге, запущен ли у вас Денвер, и есть ли соединение с сетью Интернет.

Откройте в этой же вкладке где у вас открыт ws-клиент JavaScript консоль (В GoogleChrome 34.8.1847.137 m и в FireFox это делается почти одинаково меню->инструменты->консоль Java Script или Ctrl+Shift+J, но лично я использую для этого консоль FireBug). Отправьте еще несколько сообщений. Вы увидите какие сообщения приходят от сервера. Вы можете нажать disconnect и после этого отправить несколько сообщений, вы убедитесь что сообщения не уходят, т.к. связь с сервером ws://echo.websocket.org разорвана.

Запускаем в новой вкладке браузера наш сокет-сервер http://localhost/simpleworking.php . Желательно чтобы вы сразу могли видеть и вкладку клиента с консолью и вкладку сервера. Должно появиться GO() ... socket_create ...OK socket_bind ...OK Listening socket... OK

Что означает, что сервер готов к входящим соединениям.

Во вкладке клиента в поле Server address вводим ws://127.0.0.1:889 и нажимаем reconnect, мы видим что на клиенте ничего не происходит, а на сервере появляются сообщения вида Client "Resource id #3" has connected Send to client "Hello, Client!"... OK Waiting... OK

Что говорит нам о том, что технически соединение с сокетом на сервере установлено, а на клиенте ожидается соединение по протоколу веб-сокет, и оно не установлено, т.к. браузером не получены соответствующие заголовки протокола ws. При попытке отправить сообщение с клиента, в консоли должна появиться ошибка о том, что соедние с ws не установлено. К сожалению, скрипт в GoolgeChrome остановится и для новых попыток подключения придётся перезагружать страницу с веб-клиентом. В FireFox скрипт продолжает выполняться. Обязательно сделайте reconnect спустя 100 секунд, после запуска скрипта сервера, чтобы дать ему благополучно завершиться.

Client "Resource id #4" has connected Send to client "Hello, Client!"... OK time = 309.8900001049return go() ended Closing connection... OK

Чтобы окончательно убедиться в том, что сервер отвечает, что его сообщения не блокируются файрволом, запустите скрипт сервера http://localhost/simpleworking.php запустите telnet и попытайтесь подключиться к 127.0.0.1:889, только это нужно сделать не позднее 100 секунд, с момента запуска сервера, пока он не закрыл соединения и не завершил скрипт.

По telnet должен придти ответ «Hello, Client!», что свидетельствует о том, что всё работает в штатном режиме и связь с сервером двухсторонняя.

При тестировании на локальном компьютере используя Денвер, всегда убеждайтесь что выполнения скрипта PHP завершено, в противном случае перезагружайте Денвер, чтобы избежать коллизий и занятых портов.

Протокол веб-сокет

Теперь остаётся научить наш сокет-сервер общаться как веб-сокет сервер, корректно работать в фоне (демон), и, самое главное, на дешевом хостинге. Немного теории: разрешив серверу выводить на экран сообщение, которое получаем от клиента при попытке подключения, добавив перед строкой $msg = «Hello, Client!»; код

Echo "Client \"".$accept."\" says:
";
echo socket_read($accept,512);
echo "";

можно увидеть, что попытка установить соединение по протоколу веб-сокет всегда сопровождается отправлением клиентом заголовка с обязательным соблюдением формата протокола WebScoket. Тег pre для вывода заголовков выбран не случайно, т.к. в заголовках большое значение играют переносы строк. Такие заголовки я получаю от браузеров, когда пытаюсь подключиться к нашему ws://127.0.0.1:889.

GET / HTTP/1.1 Host: localhost:889 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Sec-WebSocket-Version: 13 Origin: http://localhost Sec-WebSocket-Key: ndHtpnSPk2H0qOeP6ry46A== Cookie: vc=3; __gads=ID=9eabc58c385071c7:T=1400699204:S=ALNI_Ma_g9PZBXpi_MLKDBsao3LQiGx-EA Connection: keep-alive, Upgrade Pragma:

GET / HTTP/1.1 Upgrade: websocket Connection: Upgrade Host: localhost:889 Origin: http://localhost Pragma: no-cache Cache-Control: no-cache Sec-WebSocket-Key: zNMTfmc+C9UK6Ztmv4cE5g== Sec-WebSocket-Version: 13 Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits, x-webkit-deflate-frame User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36

Еще до того, как я начал изучать веб-сокеты, мне казалось, что работа с веб-сокетами будет напоминать работу с AJAX, когда мы отправляли запросы серверу используя JavaScript XMLHttpRequest(), но в реальности задача оказалась намного сложнее, и в первую очередь потому, что WebSocket это протокол находящийся на одном уровне с протоколом HTTP (но с некоторыми нюансами) в сетевой модели OSI , что означает, нам на стороне сервера, нужно реализовывать функционал похожий на обработку HTTP (который всегда выполнял Apache). Продолжая сравнения с AJAX, в AJAX нам не нужно обеспечивать работу протокола HTTP, т.к. это всё делает браузер и веб-сервер Apache. Мы просто отправляем и получаем сообщения. Но, использование ws хоть и накладывает на нас достаточно большой объём работы связанный с реализацией сервера на PHP, оно также даёт и преимущества: сокращение объёма передаваемых данных и рост производительности серверного ПО. Для успешного общения с клиентами по протоколу WebSocket сервер должен строго выполнять требования стандарта RFC6455 , подробно описывающего форматы заголовков ответов. Все сообщения отправляемые по протоколу WebSocket можно разделить на несколько видов: handsnake (рукопожатие при установлении связи), ping-pong(проверка связи) и data-transfer(передача данных). Также есть более краткое описание протокола в общих чертах на русском . Для того, чтобы обеспечить полноценное корректное общение сервера и клиента по протоколу веб-сокет, необходима реализация функций на PHP получения и разбора заголовков от клиента, составление заголовков сервером, составление ключа и ряд других. Изучив материалы представленные на хабре и других ресурсах, удалось найти реализованные годные функции , единственным смущающим различием явлилось то, что большинство авторов используют потоковые функции работы с сокетами , они считаются более компактными, но, при этом, более ресурсоёмкими в связи с использованием буфера. Для перехода на потоковые функции работы с сокетами, не требуется установка никаких дополнительных модулей кроме уже установленных, т.к. потоки встроены в PHP 5 по умолчанию. Потоковые функции работы с сокетами всегда начинаются с stream_socket_*. При использовании потоковых функций, желательно убедиться в phpinfo() в поддержке необходимого транспорта для потоков.

Registered Stream Socket Transports: tcp, udp.

В случае если такой информации в phpinfo() нет или в случае возникновения других проблем, обратитесь к документации , но проблема решается банальным обновлением Денвера на актуальную версию.
Еще важным является тот факт, что большинство систем ограничивает возможность создания сокета на порту ниже чем 1024, поэтому во всех дальнейших программах для сокета будет использоваться порт 8889.
Взяв за основу исходные коды функций кодирования и декодирования заголовков протокола WebSocket, удалось реализовать полноценный ws echo сервер. Алгоритм его работы также прост как и в предыдущем случае: создаём ws сервер используя функцию stream_socket_server, запускаем бесконечный цикл в котором проверяем наличие новых соединений и при получении нового соединения размещаем его в массиве $connects, также запускаем второй цикл, который пробегает по всем соединениям и закрывает отвалившиеся и получает сообщения от открытых соединений. Также в скрипт PHP мною добавлено три функции, которые я оформил как обработчиков событий.

Function onOpen($connect, $info) {
echo "open OK
\n";
}

function onClose($connect) {
echo "close OK
\n";
}

function onMessage($connect, $data) {
$f = decode($data);
echo "Message:";
echo $f["payload"] . "
\n";
fwrite($connect, encode($f["payload"]));
}

Которые ничего не делают, за исключением вывода сообщений о событиях на экран. И при получении сообщения от клиента, раскодируем его и отправляем его текст, предварительно закодировав, обратно. , ws клиент не изменился. Можно протестировать ws echo server скачав архив, и разместив его в корневой папке localhost-а Денвера. Подключиться клиентом к адресу ws://127.0.0.1:8889.
Тонкости связанные с запуском ws сервера в фоне (демон), и запуск на хостинге мы разберем в . Буду рад комментариям и отзывам.

Специально для тех, кто ищет хостинг для запуска своего проекта на веб-сокетах обсуждение .

Мои статьи про PHP демонов и веб-сокеты

• Простой веб-сокет на PHP или веб сокеты с абсолютного 0