Не протокол HTTP/2 сделать веб-сокеты устарели?
Я изучаю протокол HTTP/2. Это двоичный протокол, с небольшими рамками послания. Это позволяет передавать мультиплексирование по одному TCP-соединению. Концептуально это очень похоже на WebSockets.
есть ли планы по устареванию websockets и замене их какими-то безголовыми HTTP/2 запросами и инициированными сервером push-сообщениями? Или WebSockets будут дополнять HTTP / 2?
7 ответов:
из того, что я понял HTTP/2 не является заменой для websocket, но стремится стандартизировать протокол SPDY.
в HTTP / 2 server-push используется за сценой для улучшения загрузки ресурсов клиентом из браузера. Как разработчик, вы действительно не заботитесь об этом во время разработки. Однако, с Websocket, разработчик может использовать API, который способен потреблять и толкать сообщения с уникальным полнодуплексным соединением.
Это не одно и то же вещи, и они должны дополнять друг друга.
Я говорю Нет (Websockets не устарели).
первая и наиболее часто игнорируемая проблема заключается в том, что HTTP / 2 push не подлежит принудительному исполнению и может быть проигнорирован прокси, маршрутизаторы, другие посредники или даже браузер.
т. е. (из проекта HTTP2):
посредник может получать толчки от сервера и не пересылать их клиенту. Другими словами, как использовать выталкиваемую информацию до этого промежуточный. Кроме того, посредник может выбрать дополнительные толчки к клиенту без каких-либо действий со стороны сервера.
кроме того, через некоторое время соединения HTTP/2 закрываются.
Это правда, что стандарт гласит, что:
HTTP/2 соединения являются постоянными. Для лучшей производительности ожидается, что клиенты не будут закрывать соединения до тех пор, пока не будет определено, что дальнейшая связь с сервером не требуется (для например, когда пользователь покидает веб-страницы) или пока сервер не закроет соединение.
но...
серверы рекомендуется поддерживать открытые соединения как можно дольше но разрешается прерывать бездействующие соединения при необходимости. Когда любая конечная точка решает закрыть TCP-соединение транспортного уровня, оконечная конечная точка должна сначала отправить кадр GOAWAY (раздел 6.8), чтобы обе конечные точки могли надежно определите, были ли ранее отправленные кадры обработаны и изящно завершены или завершены все необходимые оставшиеся задачи.
даже если одно и то же соединение позволяет нажимать контент, пока он открыт, и даже если HTTP/2 решает некоторые проблемы с производительностью, введенные HTTP/1.1 'keep-alive'... Соединения HTTP / 2 не остаются открытыми бесконечно.
также веб-страница не может повторно инициировать соединение HTTP / 2 после закрытия (если мы не вернемся к долго тянет, то есть).
EDIT (2017, два года спустя)
реализации HTTP / 2 показывают, что несколько вкладок браузера / окон совместно используют одно соединение HTTP / 2, что означает, что
pushникогда не будет знать, к какой вкладке / окну он принадлежит, исключая использованиеpushв качестве замены для Websockets.
ответа нет. Цели между ними очень разные. Существует даже RFC для WebSocket через HTTP/2, который позволяет создавать несколько соединений WebSocket через один канал HTTP / 2 TCP.
WS over HTTP / 2 будет ресурсосберегающей игрой, уменьшая время открытия новых соединений и позволяя больше каналов связи без дополнительных затрат на большее количество сокетов, мягких IRQ и буфера.
https://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-01
после того, как только закончите читать HTTP / 2 spec, Я думаю, что HTTP / 2 делает устаревшие websockets для большинства случаев использования, но, возможно, не все.
PUSH_PROMISE(в просторечии известный как сервер push) не является проблемой здесь. Это просто оптимизация производительности.основным вариантом использования Websockets в браузере является включение двунаправленной потоковой передачи данных. Итак, я думаю, что вопрос OP заключается в том, делает ли HTTP/2 лучшую работу по включению двунаправленного трансляция в браузере, и я думаю, что да, это делает.
прежде всего, это и Би-Ди. Просто прочитайте введение к раздел потоков:
"поток" - это независимая, двунаправленная последовательность кадров обмен между клиентом и сервером в рамках соединения HTTP/2. Потоки имеют несколько важных характеристик:
одно соединение HTTP / 2 может содержать несколько одновременно открытых потоки, с любой конечной точкой чередование кадров из нескольких потоки.
потоки могут устанавливаться и использоваться в одностороннем порядке или совместно либо клиент, либо сервер.
потоки могут быть закрыты любой конечной точкой.
статей этой (связанный в другом ответе) просто ошибаются в этом аспекте HTTP/2. Они говорят, что это не биди. Послушайте, есть одна вещь, которая не может произойти с HTTP/2: после открытия соединения сервер не может инициировать обычный поток, только push-поток. Но как только клиент открывает поток, отправляя запрос, обе стороны могут отправлять фреймы данных через него, когда им этого захочется. Если вам нужен только один поток, клиент может просто отправить запрос" Get me all the data " и прослушать его до конца сеанса. Это не сильно отличается от websockets: клиент должен инициировать запрос на обновление websocket, прежде чем сервер сможет отправлять данные. Как в HTTP / 2, так и в Websocket, один раз клиент загружает насос, запрашивая данные, обе стороны могут отправлять кадры через постоянный сокет в любое время-полный bi-di. Эта возможность" только одного потока " HTTP/2-это просто вырожденный базовый случай, который вы получите, если игнорируете или не хотите использовать некоторые дополнительные возможности реализации HTTP / 2, такие как мультиплексирование потока.
мультиплексирование имеет важное значение. В отличие от websockets, HTTP / 2 определяет свою собственную семантику мультиплексирования: как потоки получают идентификаторы и как фреймы несут идентификатор из потока, по которому они идут. HTTP / 2 также определяет семантику управления потоком для приоритизации потоков.
(О да, в этой неправильной статье также говорится, что стандарт Websocket имеет мультиплексирование. Нет, это не так уж трудно узнать, просто откройте Websocket RFC 6455 и нажмите ⌘ - F, и введите "мультиплекс". После того как вы прочитали
протокол должен быть расширяемым; в будущих версиях, вероятно, будут введены дополнительные понятия, такие как уплотнение.
вы обнаружите, что есть 2013 проект расширения для мультиплексирования Websocket. Но я не знаю, какие браузеры, если таковые имеются, поддерживаю. Я бы не стал пытаться построить свой SPA webapp на задней части этого расширения, особенно с HTTP/2, поддержка может никогда не появиться).
мультиплексирование-это именно то, что вы обычно должны делать сами, когда открываете websocket для bidi, скажем, для реактивного обновления одностраничное приложение. Я рад, что это в спецификации HTTP/2, о которой заботятся раз и навсегда.
Если вы хотите знать, что HTTP/2 может сделать, просто посмотрите на gRPC. gRPC реализован через HTTP / 2. Посмотрите конкретно на половинные и полнодуплексные параметры потоковой передачи, которые предлагает gRPC. (Обратите внимание, что gRPC в настоящее время не работает в браузерах, но это на самом деле потому, что браузеры (1) не предоставляют фрейм HTTP/2 клиенту javascript и (2) обычно не поддерживают трейлеры, которые используются в gRPC спекуляция.)
где еще может быть место для websockets? Если вам не нужно любой из дополнительных битов, которые HTTP / 2 specs out (это огромная, сложная спецификация), то, возможно, websockets лучше. Размахивая руками о сложности реализации, я уверен, что соблюдение протокола websocket всегда будет менее вычислительно дорогим, чем HTTP/2 - HTTP/2 просто требует от вас делать больше вещей.
размер кадров очень сопоставим. Вебсокетов фреймы немного меньше, 2-14 байт накладных расходов на кадр, по сравнению с фиксированными 9 HTTP/2. Поскольку websocket выбрал заголовок переменной длины, он может кодировать большие кадры (до 2^64-1 бит на кадр против HTTP/2 2^24-1 бит на кадр ). Поэтому, если вам нужен сокет, чтобы сосать что-то жирное без особых церемоний, например, я не знаю, может быть, видеокадры, тогда websockets все еще может иметь смысл. Для большинства случаев использования, особенно связанных с веб-страницами, я думаю, что HTTP / 2 выглядит так вперед.
обмен сообщениями и простая потоковая передача(не аудио, потоковое видео) могут быть выполнены как через мультиплексирование Http/2, так и через WebSockets. Таким образом, есть некоторое перекрытие, но WebSockets имеют хорошо установленный протокол, много фреймворков/API и меньше накладных расходов на заголовки. вот хорошая статья по теме.
ну, цитата из этой игры InfoQ статьи:
ну, ответ явно нет, по простой причине: как мы видели выше, HTTP/2 вводит сервер Push, который позволяет серверу активно отправлять ресурсы в кэш клиента. Однако он не позволяет передавать данные непосредственно в клиентское приложение. Серверные толчки обрабатываются только Браузером и не появляются в коде приложения, что означает, что для приложения нет API получайте уведомления об этих событиях.
и поэтому HTTP2 push-это действительно что-то между вашим браузером и сервером, в то время как Websockets действительно предоставляют API, которые могут использоваться как клиентом (javascript, если он работает в браузере), так и кодом приложения (работающим на сервере) для передачи данных в реальном времени.