Длинный опрос или полнодуплексное соединение? Где подвох?

Hotmail использует веб-сокеты. Запросы веб-сокетов отличаются от http-запросов тем, что соединение с веб-сокетами постоянно, пока пользователь находится на веб-сайте. Итак, вкратце общение происходит следующим образом: когда пользователь впервые открывает ваш сайт, он отправляет http-запрос на ваш сервер. Поскольку протокол http находится на 7-м уровне модели OSI, запрос проходит через TCP слой и устанавливает сокетное соединение (которое находится на 5-м уровне модели OSI) с сервером. Используя соответствующую технологию веб-сокетов на стороне сервера, сервер может использовать это постоянное соединение с клиентом для передачи данных, когда это необходимо.

В зависимости от того, какой язык вы используете для своей серверной части, вы можете использовать несколько различных технологий/библиотек для реализации веб-сокетов. Для веб-приложения asp.net вы можете использовать Microsoft SignalR. Если вы используете javscript (Node.js) для серверной части, вы можете использовать Socket.io. Обратите внимание, что вы также можете использовать Socket.io, даже если вы не используете node.js для своей серверной части, но реализации не будут такими тривиальными, потому что теперь у вас будет 2 разных сервера, которым потенциально потребуется обмениваться данными (например, : сеансы или база данных).

Хорошая вещь в Node.js и SignalR заключается в том, что они очень производительны и легко масштабируются для многих пользователей, особенно Node.js. Еще одна замечательная особенность обеих этих технологий заключается в том, что если браузер клиента не поддерживает веб-сокеты, у них есть соответствующие резервные методы, такие как события, отправленные сервером, опрос Ajax, длинный опрос Ajax, скрытый элемент iframe...

Для дальнейшего чтения я рекомендую это Вопрос о переполнении стека

Существует два наиболее распространенных двунаправленных механизма HTTP, см. RFC6202 "Известные проблемы и рекомендации по использованию длинных опросов". и потоковая передача в двунаправленном HTTP":

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

• HTTP Streaming: сервер держит запрос открытым неопределенно долго; то есть он никогда не завершает запрос или закрывает соединение даже после того, как передает данные клиенту.

Вы также можете найти подробный список проблем этих подходов в RFC6202. Каждый из этих методов имеет свои преимущества и недостатки.

Итак, во время стриминга HTTP соединение не разрывается:

Основной жизненный цикл приложения, использующего потоковую передачу HTTP, выглядит следующим образом:

1. Клиент делает первоначальный запрос, а затем ждет ответа.

2. Сервер откладывает ответ на запрос опроса до тех пор, пока не будет доступно обновление или пока не наступит определенный статус или тайм-аут.

3. Всякий раз, когда доступно обновление, сервер отправляет его обратно клиенту как часть ответа.

4. Данные, отправленные сервером, не завершают запрос или соединение. Сервер возвращается к шагу 3.

Я думаю, что, возможно, есть лучший подход, чем использование длительного опроса. Вы можете реализовать соединения WebSocket. Тогда у вас будет постоянное двунаправленное соединение с сервером. WebSocket — это протокол обновления, основанный на HTTP, и он был создан, чтобы избежать обходных путей, таких как длительный опрос. Если вы хотите прочитать об этом более подробно:

https://tools.ietf.org/html/rfc6455

http://www.html5rocks.com/en/tutorials/websockets/basics/

http://dojotoolkit.org/api/1.10/dojox/socket.html

https://www.sitepen.com/blog/2012/11/05/dojo-websocket-with-amd/