HTTP спроектирован как асимметричный протокол: клиенты могут связываться с сервером в любое время (без необходимости выполнения команды пользователем, благодаря Ajax-запросам). Вместо этого сервер обычно не может отправлять обновления клиенту во время его выбора.
Соединения выполняются в виде HTTP-запросов, GET или POST практически во всех веб-браузерах, от клиента до сервера, и никогда наоборот. Этот механизм упрощает протокол во многих отношениях, но поднимает проблемы всякий раз, когда взаимодействие в реальном времени является желательным. Как реализовать чат в браузере?
Есть некоторые обходные пути, но …
Самое простое решение — непрерывный опрос сервера : каждые 5 секунд мы отправляем запрос, и сервер сообщает нам, какие сообщения поступили в чат. Однако это увеличивает нагрузку на сервер, который должен одновременно управлять огромным количеством новых подключений.
Немного лучшей моделью является длинный опрос (и другие аналогичные методы, которые все вместе называются Comet ), где каждое соединение, сделанное клиентом, остается открытым, пока не будут какие-то данные для возврата клиенту. Соединение также может иметь тайм-аут, но очень просто просто перезапустить его после истечения 60-секундного тайм-аута.
Проблема с обоими стилями заключается в том, что они не масштабируются с текущими серверами HTTP. Apache выделяет один процесс каждому соединению — если вам нужно оставить процесс открытым для каждого пользователя в чате, сервер быстро остановится. Однако существуют разные HTTP-серверы, такие как CouchDB и Node.js , которые не выделяют несколько процессов и способны обрабатывать такое большое количество одновременно открытых соединений.
WebSockets
Поскольку нам уже нужно изменить некоторую инфраструктуру на стороне сервера, чтобы она поддерживала передачу сервером клиенту определенных событий, давайте сделаем это с помощью стандартного протокола. HTML 5 WebSockets обещают двунаправленное полнодуплексное соединение, которое не закрывается после первых данных, возвращаемых сервером вместе с заголовками, но остается открытым, как любое TCP-соединение.
С технической точки зрения, фактически, WebSockets — это механизм для туннелирования TCP-соединения по HTTP : вы можете отправлять все, что вам угодно, в канале связи, но связь оборачивается в текстовый поток с заголовками HTTP, такими как Host и Origin .
Крутая вещь об использовании HTTP в наше время, кроме универсального клиента (браузера), это его дружба с прокси ; на самом деле прокси часто являются целью подключений браузеров, которые с помощью команды HTTP CONNECT указывают ему открыть TCP-соединение с каким-либо другим сервером, проходящим через NAT.
WebSockets использует ws: // и wss: // URL в качестве идентификаторов. Затраты на общение намного меньше, так как при каждом взаимодействии вы можете избежать отправки заголовков HTTP как в запросе, так и в ответе. Взаимодействие с DOM и другими компонентами браузера по-прежнему асинхронно (определяется через события и обратные вызовы), поэтому это просто хорошее обновление по Ajax-запросам.
Вы можете общаться через WebSocket через такие события, как onopen, onmessage, onclose и такие методы, как send () и close (). Этот API согласуется с WebWorkers. Это пример API, взятого с WebSocket.org:
var myWebSocket = new WebSocket("ws://www.websockets.org");
myWebSocket.onmessage = function(evt) { alert( "Received Message: " + evt.data); };
myWebSocket.send("Hello Web Sockets!");
myWebSocket.close();
Служба поддержки
Ora incomincian le dolenti note — теперь начинаются ноты горя.
Chrome является одним из немногих браузеров, поддерживающих WebSockets в стабильном выпуске, наряду с Safari 5. В Firefox 4 и Opera протокол отключен по умолчанию из-за проблем безопасности, и давайте не будем говорить об Internet Explorer.
К счастью, существует возможность эмуляции через клиентские библиотеки, используя Ajax или невидимые фреймы, где WebSockets недоступны. Здесь есть две библиотеки:
- Kaazing Web Socket Gateway (пример работы можно посмотреть на http://kaazing.me )
- Socket.IO (спасибо _odino_ )
Возможно, им потребуется также другая настройка сервера, но я думаю, что большая проблема заключается в том, чтобы заставить клиента работать, а обновление сервера всегда возможно.
Вывод
WebSockets не являются технологией, готовой к производству, но находятся на грани инноваций (и вы всегда можете отступить, пока браузеры не догонят). Посмотрим, хорошо ли работает нововведение или оно напрягает ресурсно-ориентированную модель HTTP.