Я изучаю протокол HTTP/2. Это двоичный протокол с небольшими кадрами сообщений. Он позволяет осуществлять мультиплексирование потоков по одному TCP-соединению. Понятно, что это похоже на WebSockets.
Планируются ли устаревшие веб-порты и заменяются их каким-либо запросами HTTP/2 без заголовка и инициированными сервером push-сообщениями? Или WebSockets дополняет HTTP/2?
Из того, что я понял, HTTP/2 не является заменой для websocket, но нацелен на стандартизацию протокола SPDY.
В HTTP/2 сервер-push используется за сценой для улучшения загрузки ресурсов клиентом из браузера. Как разработчик, вы не заботитесь об этом во время своего развития. Однако с помощью Websocket разработчику разрешено использовать API, который способен потреблять и нажимать сообщение с уникальным полнодуплексным соединением.
Это не одни и те же вещи, и они должны дополнять друг друга.
После того, как я закончил читать спецификацию HTTP/2, я думаю, что HTTP/2 делает устаревшие веб-сокеты для большинства случаев использования, но, возможно, не для всех.
PUSH_PROMISE (в просторечии известный как серверный push) здесь не проблема. Это просто оптимизация производительности.
Основным вариантом использования веб-сокетов в браузере является включение двунаправленной потоковой передачи данных. Итак, я думаю, что OP-вопрос заключается в том, выполняет ли HTTP/2 лучшую работу по включению двунаправленной потоковой передачи в браузере, и я думаю, что да, это так.
Прежде всего, это би-ди. Просто прочитайте введение в раздел потоков:
"Поток" - это независимая двунаправленная последовательность кадров, которыми обмениваются клиент и сервер в рамках соединения HTTP/2. Потоки имеют несколько важных характеристик:
Одно соединение 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 (это огромная, сложная спецификация), тогда, возможно, веб-сокеты лучше. Размахивая руками о сложности реализации, я уверен, что соблюдение протокола websocket всегда будет менее затратным в вычислительном отношении, чем HTTP/2 - HTTP/2 просто требует от вас больше работы.
Размер кадров очень сопоставим. Кадры веб-сокета немного меньше, 2-14 байт на кадр, по сравнению с фиксированным HTTP/2. 9. Поскольку веб-сокет выбрал заголовок переменной длины, он может кодировать большие кадры (до 2 ^ 64-1 бит на кадр против HTTP/2 2 ^ 24-1 бит на кадр). Так что если вам нужен сокет, чтобы отсосать что-то толстое без особой церемонии, например, я не знаю, может быть, видеокадры, тогда веб-сокеты все еще могут иметь смысл. Я думаю, что для большинства случаев использования, особенно для веб-страниц, HTTP/2 выглядит как путь вперед.
Я говорю "Нет" (Websockets не устарели).
Первая и наиболее часто игнорируемая проблема заключается в том, что HTTP/2 push не применяется и может игнорироваться прокси, маршрутизаторами, другими посредниками или даже браузером.
т.е. (из черновика HTTP2):
Посредник может получать запросы от сервера и не перенаправлять их клиенту. Другими словами, как использовать переданную информацию, зависит от этого посредника. Точно так же посредник может решить сделать дополнительные действия для клиента без каких-либо действий со стороны сервера.
Кроме того, HTTP/2 соединения закрываются через некоторое время.
Это правда, что стандарт гласит, что:
HTTP/2 соединения постоянны. Для достижения максимальной производительности ожидается, что клиенты не будут закрывать соединения, пока не будет определено, что дальнейшая связь с сервером не требуется (например, когда пользователь уходит с определенной веб-страницы) или пока сервер не закроет соединение.
Но...
Серверам рекомендуется поддерживать открытые соединения как можно дольше, но при необходимости им разрешается прерывать неактивные соединения. Когда одна из конечных точек решает закрыть TCP-соединение транспортного уровня, конечная точка ДОЛЖНА сначала отправить кадр GOAWAY (раздел 6.8), чтобы обе конечные точки могли надежно определить, были ли обработаны ранее отправленные кадры, изящно завершить или завершить любые необходимые оставшиеся задачи.
Даже если одно и то же соединение позволяет передавать содержимое, пока оно открыто, и даже если HTTP/2 решает некоторые проблемы с производительностью, возникающие в HTTP/1.1 "keep-alive"... HTTP/2-соединения не остаются открытыми бесконечно.
Также веб-страница не может повторно инициировать соединение HTTP/2 после закрытия (если только мы не вернулись к длительной работе).
РЕДАКТИРОВАТЬ (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
Ну, цитата из этой статьи InfoQ:
Что ж, ответ однозначно отрицательный по простой причине: как мы видели выше, в HTTP/2 представлен Server Push, который позволяет серверу активно отправлять ресурсы в кеш клиента. Однако он не позволяет передавать данные в само клиентское приложение. Серверные запросы обрабатываются только браузером и не отображаются в коде приложения, что означает, что у приложения нет API для получения уведомлений об этих событиях.
Таким образом, HTTP2 push - это нечто среднее между вашим браузером и сервером, в то время как Websockets действительно предоставляет API-интерфейсы, которые могут использоваться как клиентом (javascript, если он работает в браузере), так и кодом приложения (работает на сервере) для передачи данных в реальном времени.
Обмен сообщениями и простая потоковая передача (не аудио, потоковая передача видео) могут выполняться как с помощью мультиплексирования Http/2, так и с WebSockets. Таким образом, существует некоторое перекрытие, но у WebSockets есть хорошо установленный протокол, много фреймворков /API и меньше накладных расходов на заголовки. Вот хорошая статья о теме.
Я так не думаю, что если push/pull и full duplex доступны как часть http/2, то почему я должен рекомендовать использовать WebSocket и, очевидно, дополнительные накладные расходы. Должен сказать, да, это определенно устаревший WebSocket