Экспериментальная поддержка HTTP/3 уже встроена в основные браузеры и начинает потихоньку пробираться на сервера. А это значит, что уже можно полностью отказаться от использования в своих nodejs-приложениях от http-библиотеки и переключиться на http2. Насколько же отличается реализация http2-сервера от обычного http-сервера?

Под катом пример простого web-приложения, выполняющего типовые задачи (получение статики GET'ом, upload файлов, POST-запросы, server sent events) на серверах HTTP/1 и HTTP/2. HTTP/2 Server Push в данном примере не затрагивался. Приложение не использует внешних зависимостей (npm-пакетов), всё сделано при помощи собственного функционала nodejs.

Описание web-приложения

Клиентская часть - это ./index.html и ./favicon.ico (куда ж без него!). Раздача статики серверами - обычный GET-запрос. Функционал клиента позволяет загрузить файл на сервер (upload), получить список файлов (SSE - сервер передаёт клиенту имя одного файла раз в 200 мсек.), удалить выбранные файлы с сервера (типовой POST-запрос).

Запросы клиента обслуживают HTTP/1 и HTTP/2 серверы на портах 4010 и 4020. Каждый сервер реализован в собственном файле (./http1.mjs и ./http2.mjs), общий код вынесен в библиотеку ./lib.mjs. Оба сервера используют один и тот же каталог для хранения загруженных файлов.

Чтобы попробовать приложение, нужно склонировать на свой компьютер github-репозиторий flancer64/habr_node_http_servers и запустить сервера:

$ node http1.mjs & 
$ node http2.mjs &

Точки входа в приложение:

Так как для доступа к HTTP/2-серверу через браузер нужно использовать шифрование (https), а сертификат в тестовом приложении самоподписной, то при первом входе на HTTP/2-сервер высвечивается предупреждение браузера, которое можно игнорить.

Резюме

Внезапно оказалось, что в nodejs для этих 4-функций (GET, POST, upload, SSE) различий на уровне кода между HTTP/1 и HTTP/2 нет. Вернее, единственное различие - это способ создания сервера. Вот код для HTTP/1:

import {createServer} from 'http';
import {onRequest} from './lib.mjs';
const server = createServer();
server.listen(4010);
server.on('error', (err) => console.dir(err));
server.on('request', onRequest);

А это код для HTTP/2:

import {createSecureServer} from 'http2';
import {readFileSync} from 'fs';
import {onRequest} from './lib.mjs';
const server = createSecureServer({
    key: readFileSync('key.pem'),
    cert: readFileSync('cert.pem')
});
server.listen(4020);
server.on('error', (err) => console.dir(err));
server.on('request', onRequest);

Всё, далее оба сервера используют один и тот же библиотечный код (функция onRequest), реализующий backend-логику web-приложения.

Как бы, это довольно очевидно: HTTP/2 является развитием HTTP/1 и базируется на принципе "запрос - ответ":

В случае с SSE получается, что ответ состоит из фрагментов и растянут во времени:

Этот базовый принцип отличает протокол HTTP (полудуплекс - сначала передача, потом приём) от WebSocket, который является полнодуплексным (приём и передача информации осуществляется независимо):

Двунаправленная передача информации для WebSocket.

Но для меня стало неожиданным, что между http и http2 библиотеками в nodejs есть такая качественная обратная совместимость - просто выноси бизнес-логику отдельно и используй её на http или http2-сервере по своему желанию.

"That's all I have to say about that" (c)

Послесловие

Эта публикация довольно быстро, за два-три дня, нахватала 8 минусов, после чего ушла из фокуса аудитории. Всё эту неделю я возился с web-серверами собственной платформы - @teqfw/web и @teqfw/http2. Ведь какой основной вывод из этой публикации? А вывод такой:

между http и http2 библиотеками в nodejs есть ... качественная обратная совместимость - просто выноси бизнес-логику отдельно и используй её на http или http2-сервере по своему желанию

В nodejs, какой бы npm-пакет не использовало ваше приложение (express, koa, @hapi/hapi, @teqfw/web, @teqfw/http2 или любой другой), в основе всегда будет одна или несколько node-библиотек http, https, http2. А в силу архитектуры HTTP-протокола, вне зависимости от версии протокола и наличия шифрования, обработка HTTP-запросов в приложении сводится к вот этому:

/** @type {module:http.Server|module:https.Server|module:http2.Http2Server|module:http2.Http2SecureServer} */
let server;

/**
 * @param {module:http.IncomingMessage|module:http2.Http2ServerRequest}req
 * @param {module:http.ServerResponse|module:http2.Http2ServerResponse} res
 */
function onRequest(req, res) {}

server.on('request', onRequest);

Да, для любого ООП'шника указание типа объекта в виде:

/** @type {TypeA|TypeB|...} */
let obj;

выглядит бредово, но... это JavaScript, здесь так можно.

Как следствие, можно ожидать, что выбор типа запускаемого сервера (http, https, http2) для любого из npm-пакетов (express, koa, ...) должен задаваться через конфигурационные опции. Что-то типа:

const Server = require('excellent-server');
const app = new Server({useHttp1: true, port: 3000});

или при запуске из командной строки:

$ ./bin/tequila.mjs help web-server-start
Usage: tequila web-server-start [options]

Start web server (HTTP/1 or HTTP/2).

Options:
  -1, --http1        use HTTP/1 server (default: HTTP/2)
  -p, --port <port>  port to use (default: 3000)
  -k, --key <path>   private key in PEM format to secure HTTP/2 server.
  -c, --cert <path>  certificates chain in PEM format to secure HTTP/2 server.

Но... express вообще не работает с HTTP/2, а Koa и Hapi встраиваются в node'овские сервера, а не инкапсулируют их:

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

Т.е., разработчику нужно обернуть своим кодом эти сервера, чтобы их можно было запускать в HTTP/1 и HTTP/2 режимах по выбору.

В общем, по итогам этой публикации я пришёл к выводу, что на моей платформе нет необходимости в двух пакетах (@teqfw/web, @teqfw/http2). Весь функционал можно уложить в один пакет. Вся разница - это в том, какая из node-библиотек применяется для создания http-сервера. А вот дальнейшая обработка запросов в большинстве случаев от способа создания сервера не зависит (ну, разве что Server Push не будет работать для HTTP/1).

А за что эта публикация получила минуса? В основном, за "Низкий технический уровень материала":

У меня нет претензий к человеку, который заминусил публикацию из-за личной неприязни. Это мировоззренческие расхождения, это нормально. Но "низкий технический уровень"?!

Express.js у которого в NPM под 20 млн. закачек за неделю не работает с HTTP/2, а в этой статье ссылка на код, который обрабатывает по HTPP/1, HTTP/2 (HTTPS) 4 вида запросов:

GET: раздача статики
POST: отправка данных на сервер для их обработки и получение результата;
upload: загрузка файлов на сервер (через потоки, а не через буферизацию в памяти!);
Server Sent Events;

Причём без применения каких-либо дополнительных npm-пакетов. Только лишь средствами nodejs. Этих 4 видов запросов вполне достаточно для того, чтобы на этом базисе строить собственные web-приложения. Всё это уместилось в 240 строках backend-кода (JS) и 209 строках frontend-кода (HTML/CSS/JS). Сейчас в моде микросервисы, так вот, для них не нужны express/koa/hapi, которые тянут за собой 50/42/30 пакетов соответственно. Вполне хватает библиотек nodejs.

У меня вопрос к тем семерым, что заминусили публикацию за низкий технический уровень: в ваших nodejs-приложениях какие web-сервера используются и какие версии HTTP поддерживаются?

HTTP/1 и HTTP/2 сервера на nodejs