При анализе откликов на свою статью "HTTP/1 и HTTP/2 сервера на nodejs" пришёл к выводу, что поддержка версии HTTP/2 в настоящее время в nodejs-приложениях находится в этакой суперпозиции: с одной стороны http2-библиотека nodejs позволяет без проблем использовать HTTP/2 в своих приложениях, с другой - наиболее популярный web-сервер (express) до сих пор нативно не поддерживает HTTP/2, а другие популярные web-сервера (koa, hapi) требуют от разработчика дополнительно кодирования для работы с HTTP/2:

const http2 = require('http2');
const Koa = require('koa');
const app = new Koa();
http2.createServer(options, app.callback());

То есть, поддержка HTTP/2 есть, но не похоже, что она сильно используется.

В фокусе моих интересов на данный момент находятся Progressive Web Applications. Такие приложения в принципе не работают без шифрования трафика (http), им обязательно нужен https. Современные браузеры поддерживают HTTPS на базе HTTP/2 - с этим проблем нет. Проблема в том, что современные браузеры не поддерживают HTTP/2 без HTTPS. Для production-режима, само собой, нужно получать сертификат, подписанный доверенным центром сертификации. А что делать разработчикам или тестировщикам? В данной ситуации логично использовать HTTP/1.1 (если только ваше приложение не завязано на функционал, присущий только HTTP/2 - как Server Push, и ваше приложение в принципе может работать без шифрования, например - не использует service worker). А возможен ещё вариант, когда ваше приложение находится в "безопасной среде" и ему не нужно шифрование, а вот HTTP/2 наоборот может быть полезным (приложение за прокси сервером в виде nginx или микросервис с которым общаются другие микросервисы).

Итого, я считаю, что современные web-приложения общего назначения должы иметь возможность работать и по HTTP/1.1, и по HTTP/2, в зависимости от конфигурации стартовых параметров, но мне кажется, что в реальности дело обстоит несколько иначе. Что HTTP/2 в nodejs-приложениях распространён куда меньше, чем принято считать.

Прошу коллег, которые имеют отношение к разработке web-прложений в nodejs ответить на вопрос, вынесенный в заголовок публикации.

Спасибо за участие в опросе.

Комментарии (8)


  1. FSA
    17.12.2021 21:08
    +1

    Потрачу свой комментарий к статье студента. Позвольте вас познакомпить, что для HTTP есть такая штука, как проксирование запросов. Прямо изначально так задумывалось. Можно поставить на фронтэнде какой-нибудь nginx или что-то иное, который будет поддерживать все необходимые фишки, типа HTTP 2.0, работу с сертификатами для доменов и прочее. А на бекэнде ваша задача просто предоставить для этого сервера нормальный ответ этому серверу по любому поддерживаемому протоколу.


    1. flancer Автор
      17.12.2021 22:25

      а вот HTTP/2 наоборот может быть полезным (приложение за прокси сервером в виде nginx ...)


  1. Akuma
    18.12.2021 00:01
    +8

    Оно в суперпозиции из-за того, что нафиг не нужно. Обычно перед nodejs стоит nginx который терминирует ssl и дальше все работает по обычному http.


    1. flancer Автор
      18.12.2021 10:13

      А как эта архитектура разрешает проблему Head-of-line blocking между nginx и web-приложением?


      1. Akuma
        18.12.2021 12:16

        Никак. Я и не говорил, что она что-то решает.

        Но если у вас возникают такие проблемы, то не уверен, что http2 спасет ситуацию. Скорее всего затык в медленном бекенде или малом числе одновременных запросов.


    1. flancer Автор
      18.12.2021 12:08

      и дальше все работает по обычному http

      А ещё потому, что по "необычному" (HTTP/2) nginx в upstream не умеет. HTTP/2 поддерживается только для клиентской стороны (браузеров). Разрабы nginx считают, что большого выигрыша от HTTP/2 в upstream нет.

      А вот разрабы apache'а считают, что их сервер должен "мочь в HTTP/2" с обеих сторон, и в apache такая возможность есть:

      RewriteRule    "^/(.*)$"  "h2c://localhost:3000/$1"  [P]

      Это значит, что если проксирование идёт через nginx, то про Server Push в своих node-приложениях можно забыть. Реализовывать его придётся на уровне nginx, через его конфиги. Но, в общем-то, не такая уж это и нужная вещь - Server Push.


      1. Akuma
        18.12.2021 12:15

        Он и не обязан все уметь. Я лишь привел вам самый популярный вариант построения приложения. Никто не мешает убрать nginx и взять nodejs, golang, php (даже так можно) и практически любой другой язык.

        Хотя не уверен на счет "не умеет". У меня nginx прекрасно проксирует gRPC трафик, который работает через http2 https://www.nginx.com/blog/nginx-1-13-10-grpc/


        1. flancer Автор
          18.12.2021 12:53

          Судя по конфигу из приведённой ссылки, nginx проксирует именно gRPC-траффик.

          http {
              server {
                  location / {
                      grpc_pass grpc://...;
                  }
              }
          }  

          Т.е., обычный 'h2c' за пределами его возможностей. Мне пока не удалось найти пример конфигурации, аналогичный apache'вской, чтобы заставить nginx проксировать запросы на простой HTTP/2-сервер (не gRPC). Обычный proxy_pass со второй версией HTTP не работает, судя по документации (и вообще на этой странице поиск по ключу h2c ничего не даёт).