Я тут решил сделать велосипед: небольшой чат для друзей. Мне стало интересно, а как это происходит наподобие вконтакте или других проектах? Ведь сообщения/уведомления приходят мгновенно и не приходится пользователю вручную обновлять или принудительно через код рефрешить страницу.
Я искал и наткнулся на то, что раньше популярно было делать так: Ajax шлет на сервер запрос через равные короткие промежутки времени для получения ответа.... А еще есть long/short polling. В начале заприметил их, но в процессе поиска наткнулся на HTML5 websockets. Кажется он легок в реализации.
Все, в той или иной мере делают одну вещь, но мне непонятно в чем же их различие? Как они работают? Хотелось бы знать хотя бы вкратце как они работают, чтоб можно было использовать ту или иную технику в зависимости от ситуации. Или перейти на HTML5 WS и не париться?
Ответ
WebSockets, по сути, новая технология. Long polling - некий обходной и грязноватый маневр предотвратить создание нового соединения на каждый новый запрос, как это делает AJAX. Но ведь long polling был создан тогда, когда WebSockets не существовало вовсе.
А технологии развиваются, эволюционируют и вот сейчас популярность набирают уже они.
Моя небольшая отсебятинка-рекомендация: почитать и ознакомиться именно с WebSockets
Но, тем не менее.
как работают различные методы связи в Интернете:
AJAX - запрос → ответ. Создает соединение с сервером, отсылает заголовки запроса с некоторыми данными, получает ответ с сервера, закрывает соединение. Запросы отправляются часто. Поддерживается во всех основных браузерах
Как плюс: просто реализовать, данные можно сжать.
Как минус: слишком много ненужных запросов (это наверное основной минус :-)). А также большие задержки между созданием и получением данных. Сервер отсылает данные не тогда, когда они появились, а когда прилетит новый запрос.
Long poll - запрос → ожидание → ответ. Создает соедениение с сервером, как AJAX, но оставляет соединение открытым некоторое время (не сильно большое).
Сервер НЕ реагирует на запрошенную информацию и ждет, пока не появится новой информации. Пока соединение открыто - клиент ждет данные с сервера. Как только что-то новое появилось у сервера - он отсылает ее клиенту.
Клиент получив новую информацию или если истекло время ожидания НЕМЕДЛЕННО отсылает другой запрос серверу, запуская процесс ожидания на нем снова. Как правило, соединение обычно переустанавливают раз в 20-30 секунд (у вконтакте например 29 секунд), чтобы избежать возможных проблем, например с HTTP-прокси. Поддерживается во всех основных браузерах
Как плюс: малое количество запросов (по сравнению с обычным AJAX то)
WebSockets - клиент ↔ сервер. Создается TCP соединение с сервером и сохраняется открытым столько, сколько требуется. Сервер или клиент могут легко закрыть его. При подключении происходит так называемое "рукопожатие", т.е. клиентом отсылаются специальные заголовки, которые шифруется base64. Если серверу всё понравилось, то он вернет заголовок Accept. Следует помнить, что клиентское рукопожатие всегда будет иметь заголовок Origin, который будет отправлен на сервер, хотят они принимать клиентов с различных источников или нет. После установки соединения сервер и клиент могут посылать друг другу сообщения, когда новая информация доступна (либо на сервере, либо на клиенте) - в обоих направлениях в любое время. Это очень эффективно, если приложение требует частого обмена данными в обоих направлениях. Также данные, посланные с клиента на сервер в некоторой степени шифруются. Еще один плюс.
[чем поддерживается] (уже неплохо развит)
WebRTC (Web Real Time Communication - веб-коммуникация в режиме реального времени) - peer ↔ peer (P2P — равный к равному).
Транспорт для установления связи между клиентами (двумя и более), через который могут передаваться обычные данные и медиапотоки.
Используются UDP, TCP и даже более абстрактные слои. Как правило это используется для передачи данных большого объема например медиаданные (аудио и видео).
Обе стороны (пиры) могут передавать данные друг другу независимо друг от друга. [чем поддерживается] (средняя поддержка)
Server-Sent Events - клиент ← сервер. Клиент устанавливает постоянное и длительное соединение с сервером. Отсылать данные может только сервер к клиенту.
Если клиент хочет что-то послать на сервер, то для этого придется использовать другую технологию/протокол.
Этот протокол HTTP прост в реализации на большинстве серверных платформах. Это более предпочтительный протокол для использования, нежели Long Polling.
[чем поддерживается] (IE как всегда в отстающих)
Преимущества:
У каждого способа есть свои плюсы и свои минусы. Однако, сейчас хорошим и перспективным считается WebSockets. Основное преимущество WebSockets для сервера, является то, что это не запрос HTTP, а собственно протокол связи на основе сообщений.
Это позволяет достичь огромные преимущества производительности и архитектуры. Например, в node.js можно разделить одну и ту же память для различных соединений сокета, таким образом получить доступ к общим переменным.
Так что вам не нужно использовать базу данных в качестве обменного пункта в середине (как с помощью AJAX или Long Polling и, например, PHP). Вы можете хранить данные в оперативной памяти...
Решать что использовать, конечно, только вам!
Ответ переведен, слегка изменен и дополнен отсебятиной с enSO
Комментариев нет:
Отправить комментарий