Я изучаю протокол HTTP / 2. Это двоичный протокол с небольшими фреймами сообщений. Это позволяет мультиплексировать поток через одно соединение TCP. Концептуально это выглядит очень похоже на WebSockets.
Планируется ли устаревание веб-сокетов и их замена какими-либо HTTP / 2-запросами без заголовков и push-сообщениями, инициируемыми сервером? Или WebSockets дополнит HTTP / 2?
Ответы:
Из того, что я понял, HTTP / 2 не является заменой веб-сокета, но стремится стандартизировать протокол SPDY.
В HTTP / 2 server-push используется за сценой для улучшения загрузки ресурсов клиентом из браузера. Как разработчик, вы не заботитесь об этом во время разработки. Тем не менее, с Websocket, разработчик может использовать API, который может использовать и отправлять сообщения с уникальным полнодуплексным соединением.
Это не одно и то же, и они должны дополнять друг друга.
источник
После того, как я закончил читать спецификацию HTTP / 2 , я думаю, что HTTP / 2 делает устаревшие веб-сокеты для большинства случаев использования, но, возможно, не для всех.
PUSH_PROMISE
(в разговорной речи известный как серверный пуш) здесь не проблема. Это просто оптимизация производительности.Основным вариантом использования веб-сокетов в браузере является включение двунаправленной потоковой передачи данных. Итак, я думаю, что вопрос OP заключается в том, выполняет ли HTTP / 2 лучшую работу по включению двунаправленной потоковой передачи в браузере, и я думаю, что да, это так.
Прежде всего, это является би-ди. Просто прочитайте введение в раздел потоков :
Статьи как это (связанные в другой ответ) не правы об этом аспекте HTTP / 2. Говорят, это не биди. Посмотрите, есть одна вещь, которая не может произойти с HTTP / 2: после открытия соединения сервер не может инициировать обычный поток, только push-поток. Но как только клиент открывает поток, отправляя запрос, обе стороны могут в любое время отправлять кадры DATA через постоянный сокет - полный биди.
Это не сильно отличается от веб-сокетов: клиент должен инициировать запрос на обновление веб-сокета, прежде чем сервер также сможет отправлять данные.
Самое большое отличие состоит в том, что, в отличие от веб-сокетов, HTTP / 2 определяет свою семантику мультиплексирования: как потоки получают идентификаторы и как кадры переносят идентификатор потока, в котором они находятся. HTTP / 2 также определяет семантику управления потоками для определения приоритетов потоков. Это важно в большинстве реальных приложений биди.
(Эта неправильная статья также говорит о том, что стандарт Websocket имеет мультиплексирование. Нет, это не так. Найти его совсем не сложно, просто откройте Websocket RFC 6455 и нажмите ⌘-F и введите «мультиплекс». После прочтения
Вы обнаружите, что существует черновое расширение 2013 года для мультиплексирования Websocket. Но я не знаю, какие браузеры, если таковые имеются, поддерживают это. Я не стал бы пытаться создать свое SPA-приложение на обратной стороне этого расширения, особенно с приходом HTTP / 2, поддержка может и не прийти).
Мультиплексирование - это именно то, что вам обычно приходится делать каждый раз, когда вы открываете веб-сокет для биди, скажем, для питания реактивно обновляемого одностраничного приложения. Я рад, что это в спецификации HTTP / 2, позаботился раз и навсегда.
Если вы хотите знать, что может сделать HTTP / 2, просто посмотрите на gRPC. gRPC реализован через HTTP / 2. Обратите особое внимание на варианты потоковой передачи в полудуплексном и полнодуплексном режиме, которые предлагает gRPC. (Обратите внимание, что gRPC в настоящее время не работает в браузерах, но это на самом деле потому, что браузеры (1) не предоставляют фрейм HTTP / 2 клиентскому javascript, и (2) обычно не поддерживают трейлеры, которые используются в спецификация gRPC)
Где еще могут быть веб-розетки? Большим из них является бинарные данные, передаваемые через сервер -> браузер. HTTP / 2 разрешает двоичные данные, передаваемые сервером-> браузером, но не отображается в браузере JS. Для таких приложений, как передача аудио и видео кадров, это причина использовать веб-сокеты.
Изменить: 17 января 2020
Со временем этот ответ постепенно поднялся до вершины (что хорошо, потому что этот ответ более или менее правильный). Тем не менее, по-прежнему время от времени появляются комментарии о том, что это неверно по разным причинам, обычно связанным с некоторой путаницей
PUSH_PROMISE
или тем, как на самом деле использовать ориентированный на сообщения сервер -> клиентский толчок в одностраничном приложении. И есть вариант использования для веб-сокетов в браузере, который представляет собой двоичные данные, передаваемые сервером. Для текстовых данных, включая JSON, не используйте веб-сокеты, используйте SSE.Напомним: протокол HTTP / 2 полон би-ди. Тем не менее, современные веб-браузеры не предоставляют JavaScript / Frame-ориентированный протокол HTTP / 2 . Тем не менее, если вы делаете несколько запросов к одному и тому же источнику через соединение HTTP / 2, весь этот трафик мультиплексируется в одном соединении (и это то, что нас волнует!).
Поэтому, если вам нужно создать приложение для чата в реальном времени, скажем, где вам нужно транслировать новые сообщения чата всем клиентам в комнате чата, которые имеют открытые соединения, вы можете (и, вероятно, должны) сделать это без веб-сокетов.
Вы должны использовать события, отправленные сервером, для отправки сообщений вниз и API Fetch для отправки запросов вверх. Server-Sent Events (SSE) - это малоизвестный, но хорошо поддерживаемый API, который предоставляет ориентированный на сообщения поток сервер-клиент. Хотя это не похоже на клиентский JavaScript, внутри вашего браузера (если он поддерживает HTTP / 2) будет повторно использоваться одно TCP-соединение для мультиплексирования всех этих сообщений. Там нет потери эффективности и на самом деле это выигрыш над веб-сокетами. Нужно несколько потоков? Откройте несколько источников событий! Они будут автоматически мультиплексированы для вас.
Помимо более эффективного использования ресурсов и меньшей начальной задержки, чем при рукопожатии через веб-сокет, Server-Sent Events обладают замечательным свойством, заключающимся в том, что они автоматически отступают и работают через HTTP / 1.1. Но когда у вас есть соединение HTTP / 2, они работают невероятно хорошо.
Вот хорошая статья с реальным примером выполнения SPA с реактивно-обновляемым обновлением.
источник
Я говорю «Нет» ( Websockets не устарели ).
Первая и наиболее часто игнорируемая проблема заключается в том, что HTTP / 2 push не применяется и может игнорироваться прокси, маршрутизаторами, другими посредниками или даже браузером.
т.е. (из черновика HTTP2):
Следовательно, HTTP / 2 Push не может заменить WebSockets.
Кроме того, HTTP / 2 соединения закрываются через некоторое время.
Это правда, что стандарт гласит, что:
Но...
Даже если одно и то же соединение позволяет передавать содержимое, пока оно открыто, и даже если HTTP / 2 решает некоторые проблемы с производительностью, вызванные «keep-alive» HTTP / 1.1 ... HTTP / 2-соединения не остаются открытыми бесконечно ,
Также веб-страница не может повторно инициировать соединение HTTP / 2 после закрытия (если только мы не вернулись к длительной работе).
РЕДАКТИРОВАТЬ (2017, два года спустя)
Реализации HTTP / 2 показывают, что несколько вкладок / окон браузера совместно используют одно соединение HTTP / 2, что означает, что
push
он никогда не узнает, к какой вкладке / окну оно принадлежит, исключая использованиеpush
в качестве замены для веб-сокетов.РЕДАКТИРОВАТЬ (2020)
Я не уверен, почему люди начали понижать голос. Во всяком случае, годы, прошедшие с момента публикации ответа, доказали, что HTTP / 2 не может заменить WebSockets и не предназначен для этого.
Конечно, HTTP / 2 может использоваться для туннелирования соединений WebSocket, но эти туннелированные соединения все равно будут нуждаться в протоколе WebSocket, и они будут влиять на поведение контейнера HTTP / 2.
источник
ssh
терминала в браузере очень проста при использовании Websockets. HTTP / 2 будет полной головной болью, особенно если открыто более одной вкладки. Кроме того, что если браузер (или один из прокси-серверов HTTP / 2) закрыл соединение? Может ли клиент просто предположить, что новые данные недоступны? мы вернулись к опросу.onclose
обратный вызов, поэтому опрос не требуется. Что касается мультиплексирования, я думаю, что это была необходимость, а не выбор.keep-alive
не удалось, и единственный способ избежать «первого в линии» снижения производительности - рискнуть мультиплексированием. Время покажет :)Ответ - нет. Цели между ними очень разные. Существует даже RFC для WebSocket через HTTP / 2, который позволяет вам создавать несколько соединений WebSocket через один канал HTTP / 2 TCP.
WS over HTTP / 2 будет играть роль сохранения ресурсов, уменьшая время открытия новых соединений и предоставляя больше каналов связи без дополнительных затрат на сокеты, программные прерывания и буферы.
https://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-01
источник
Ну, цитата из этой статьи InfoQ :
Таким образом, HTTP2 push - это нечто среднее между вашим браузером и сервером, в то время как Websockets действительно предоставляет API-интерфейсы, которые могут использоваться как клиентом (javascript, если он работает в браузере), так и кодом приложения (работает на сервере) для передачи данных в реальном времени.
источник
Обмен сообщениями и простая потоковая передача (не аудио, потоковая передача видео) могут осуществляться как через мультиплексирование Http / 2, так и через WebSockets. Таким образом, есть некоторое совпадение, но WebSockets имеет хорошо установленный протокол, много фреймворков / API и меньше заголовков. Вот хорошая статья на эту тему .
источник
На сегодняшний день нет.
HTTP / 2, по сравнению с HTTP, позволяет поддерживать соединение с сервером. Оттуда вы можете иметь несколько потоков данных одновременно. Намерение состоит в том, что вы можете нажать несколько вещей одновременно, даже если клиент не запрашивает это. Например, когда браузер запрашивает a
index.html
, сервер может также нажатьindex.css
иindex.js
. Браузер не просил об этом, но сервер может предоставить это без запроса, потому что он может предположить, что вы захотите через несколько секунд.Это быстрее , чем HTTP / 1 альтернативы получения
index.html
, анализа его, обнаружив , что нужноindex.js
иindex.css
и затем строит 2 других запросов для этих файлов. HTTP / 2 позволяет серверу передавать данные, которые клиент даже не запрашивал.В этом контексте он похож на WebSocket, но не совсем по замыслу. Предполагается, что WebSocket допускает двунаправленную связь, аналогичную TCP-соединению или последовательному соединению. Это гнездо, где оба общаются друг с другом. Кроме того, основным отличием является то, что вы можете отправлять любые произвольные пакеты данных в необработанных байтах, не инкапсулированные в протокол HTTP. Понятия заголовков, путей, строк запросов происходят только во время рукопожатия, но WebSocket открывает поток данных.
Другое отличие в том, что вы получаете гораздо более точный доступ к WebSocket в Javascript, тогда как с HTTP он обрабатывается браузером. Все, что вы получаете с HTTP, это то, что вы можете вписать в
XHR
/fetch()
. Это также означает, что браузер получит возможность перехватывать и изменять заголовки HTTP без возможности управления им (напримерOrigin
,Cookies
и т. Д.). Кроме того, то, что HTTP / 2 может выдвинуть, отправляется в браузер. Это означает, что JS не всегда (если вообще когда-либо) знает, что что-то толкает. Опять же, это имеет смыслindex.css
иindex.js
потому, что браузер будет кешировать его, но не столько для пакетов данных.Это действительно все во имя. HTTP означает протокол передачи гипертекста. Мы ориентированы на концепцию передачи активов. WebSocket - это создание сокетного соединения, в котором двоичные данные передаются в двух направлениях.
Единственное, что мы не обсуждаем, это SSE (Server-Sent Events). Передача данных в приложение (JS) не является целью HTTP / 2, но предназначена для SSE. SSE действительно усиливается с помощью HTTP / 2. Но это не настоящая замена WebSockets, когда важны сами данные, а не достигаемые конечные точки переменных. Для каждой конечной точки в WebSocket создается новый поток данных, но в SSE он используется совместно с уже существующим сеансом HTTP / 2.
Здесь кратко изложены цели для каждого:
источник
Будет реализация WebSocket в HTTP / 2. https://tools.ietf.org/html/rfc8441
источник
В настоящее время HTTP / 2 в апреле 2020 года не делает WebSockets устаревшими. Наибольшее преимущество WebSockets перед HTTP2 заключается в том, что
Означает, что HTTP / 2 не предлагает никаких JS API, таких как WebSockets, для обеспечения связи и передачи каких-либо JSON или других данных на сервер непосредственно из приложения (например, с веб-сайта). Так что, насколько я верю, HTTP / 2 сделает WebSockets только устаревшими, если начнет предлагать API, такие как WebSockets, для взаимодействия с сервером. Пока что это просто обновленная и более быстрая версия HTTP 1.1.
источник