Как реализованы веб-сокеты?

  • Как реализованы веб-сокеты?
  • Какой алгоритм стоит за этой новой технологией (по сравнению с длинным опросом)?
  • Как они могут быть лучше, чем Long-Polling, с точки зрения производительности?

Я задаю эти вопросы, потому что здесь мы иметь пример кода реализации веб-сокета Jetty (на стороне сервера) .

  

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

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

12 голосов | спросил David 11 Jpm1000000pmMon, 11 Jan 2016 23:19:13 +030016 2016, 23:19:13

2 ответа


0
  

Как реализованы веб-сокеты?

webSockets реализованы следующим образом:

  1. Клиент отправляет HTTP-запрос на сервер с заголовком «upgrade» для запроса
  2. Если сервер соглашается на обновление, то клиент и сервер обмениваются некоторыми учетными данными безопасности, и протокол в существующем сокете TCP переключается с HTTP на webSocket.
  3. Теперь существует постоянный открытый сокет TCP, соединяющий клиента и сервер.
  4. Любая из сторон может отправлять данные в этот открытый сокет в любое время.
  5. Все данные должны быть отправлены в очень специфическом формате пакета webSocket.

Поскольку сокет остается открытым до тех пор, пока обе стороны соглашаются, это дает серверу канал для «передачи» информации клиенту, когда есть что-то новое для отправки. Как правило, это гораздо более эффективно, чем использование Ajax-вызовов, управляемых клиентом, когда клиент должен регулярно запрашивать новую информацию. И, если клиенту необходимо отправить много сообщений на сервер (возможно, что-то вроде игры для нескольких игроков), то использование уже открытого сокета для отправки быстрого сообщения на сервер также более эффективно, чем вызов Ajax.

Из-за того, как инициируются webSockets (начиная с HTTP-запроса, а затем повторно используют этот сокет), они на 100% совместимы с существующей веб-инфраструктурой и могут даже работать на том же порту, что и ваши существующие веб-запросы (например, порт 80 или 443). Это упрощает межсайтовую защиту и лишает любого пользователя инфраструктуры на стороне клиента или сервера от необходимости изменять любую инфраструктуру для поддержки соединений webSocket.

  

Какой алгоритм стоит за этой новой технологией (по сравнению с   Long-опрос)?

В этой статье приведено очень хорошее резюме того, как работает алгоритм подключения webSocket и формат данных webSocket: Запись серверов WebSocket .

  

Как они могут быть лучше, чем Long-Polling, с точки зрения производительности?

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

  1. Клиент отправляет http-запрос новых данных от клиента.
  2. Если на сервере есть какие-то новые данные, он немедленно возвращает эти данные, а затем клиент делает еще один http-запрос с запросом дополнительных данных. Если на сервере нет новых данных, он просто на некоторое время висит на соединении, не предоставив ответа, оставив запрос в ожидании (сокет открыт, клиент ожидает ответа).
  3. Если в любое время, пока запрос все еще находится в состоянии ожидания, сервер получает некоторые данные, то он формирует эти данные в ответ и возвращает ответ для ожидающего запроса.
  4. Если данные не поступают в течение некоторого времени, то в конечном итоге запрос истекает. В этот момент клиент поймет, что новые данные не были возвращены, и начнет новый запрос.
  5. Прополощите, вспените, повторите. За каждым возвращаемым фрагментом данных или каждым тайм-аутом ожидающего запроса следует другой запрос ajax от клиента.

Итак, в то время как webSocket использует один долгоживущий сокет, через который клиент или сервер может отправлять данные другому, длительный опрос состоит из того, что клиент спрашивает сервер «у вас есть еще данные для меня?» снова и снова, каждый с новым запросом http.

Длинные опросы работают, когда все сделано правильно, они просто не так эффективны для серверной инфраструктуры, использования полосы пропускания, времени автономной работы мобильных устройств и т. д.

  

Я хочу получить объяснение по этому поводу: тот факт, что Websockets хранит   Открытое соединение между C /S не совсем то же самое, что ожидание при длительном опросе   процесс? Другими словами, почему веб-сокеты не перегружают сервер?

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

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

Вот несколько полезных ссылок по теме масштабирования:

ответил jfriend00 12 Jam1000000amTue, 12 Jan 2016 03:16:02 +030016 2016, 03:16:02
0

Очень хорошее объяснение о веб-сокетах, длинных опросах и других подходах:

В каких ситуациях будет ли предпочтительнее длинный /короткий опрос AJAX, чем HTML5 WebSockets?

Длинный опрос - запрос → ожидание → ответ . Создает соединение с сервером, как это делает AJAX, но соединение с поддержкой активности остается открытым в течение некоторого времени (хотя и ненадолго), во время открытого соединения клиент может получать данные с сервера. Клиент должен периодически переподключаться после закрытия соединения из-за таймаутов или данных eof. На стороне сервера он по-прежнему обрабатывается как HTTP-запрос так же, как AJAX, за исключением того, что ответ по запросу будет происходить сейчас или в будущем, определяемый логикой приложения. Поддерживается во всех основных браузерах.

WebSockets - клиент ↔ сервер . Создайте TCP-соединение с сервером и сохраняйте его столько, сколько нужно. Сервер или клиент могут легко закрыть его. Клиент проходит через HTTP-совместимый процесс рукопожатия, и в случае успеха сервер и клиент могут обмениваться данными в обоих направлениях в любое время. Это очень эффективно, если приложение требует частого обмена данными обоими способами. В WebSockets есть кадрирование данных, которое включает маскировку для каждого сообщения, отправляемого с клиента на сервер, поэтому данные просто шифруются. график поддержки (очень хорошо)

В целом, сокеты имеют гораздо лучшую производительность, чем длинные опросы, и вы должны использовать их вместо длинных.

ответил Mihail Petkov 11 Jpm1000000pmMon, 11 Jan 2016 23:25:43 +030016 2016, 23:25:43

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132