Решил почитать, заодно тут повыкладывать какие-то материалы по HTTP/3 и QUIC, а то эти понятия всплыли в связи с тормозами ютюба. Ну и HTTP это такая вещь, с которой все IT-шники и просто люди, кто интернетом пользуются, сталкиваются. Так, для собственного образования и может кто-нибудь ещё решит почитать. Приглашаю тоже поучаствовать, насчёт каких-то материалов по теме, если кто захочет.

Наверное стоит начать с напоминания о том, что такое HTTP вообще. Сам я веб-разработкой занимался немного и это было какое-то время назад, так что наверное многие на форуме знают больше меня об этом. Но всё равно что-то напишу.

HTTP (HyperText Transfer Protocol) - это протокол, по которому веб-браузеры общаются (обмениваются данными) с сайтами (точнее - с веб-серверами). Также HTTP используют программы, которые работают c веб-сервисами, веб-службами. Вроде в этом случае может использоваться не только HTTP, но в частности используется и он. Рабочая версия HTTP (если не считать позднейшие 2 и 3) - 1.1

HTTP/1.1 - это текстовый протокол поверх TCP-IP. Клиент (браузер или другое ПО) устанавливает TCP соединение с сервером и затем отправляет серверу запрос, на который сервер отвечает. Запрос состоит из нескольких строк, разделенных символами (CR) LF - собственно строка запроса, затем строки с т.н. заголовками, потом может присутствовать "тело" запроса. После обмена информацией TCP-соединение закрывается сервером. Но может продолжаться, для того, чтобы по нему послать ещё запросы, для этого браузер должен указать соответствующий параметр в заголовках (keep-alive) и время ожидания.

Далее. HTTPS - HyperText Transfer Protocol Secure, защищенный HTTP. Запросы и ответы HTTP идут по интернету, проходя различные шлюзы и могут быть перехвачены, прочитаны третьей стороной, и также вероятно подменены. В протоколе HTTPS передаваемые данные шифруются, а также подписываются цифровой подписью, что предотвращает как возможность чтения третьей стороной, так и возможность подмены.
Сначала HTTPS использовался в некоторых случаях, но постепенно он стал широко применяться на обычных сайтах. Из Википедии: Для чего про HTTPS? В частности потому, что HTTP/2, хотя в стандарте не требуется использование защищенного протокола, по факту используется через HTTPS. https://en.wikipedia.org/wiki/HTTP/2

Теперь про HTTP/2
Сначала коротко, как бы декларативно, дальше не знаю, будет тут что-то детальней или нет.

HTTP/1.1 был принят в 1999 году. С тех пор веб развивался, страницы становились тяжелее - картинки, мультимедиа, скрипты и т.д. По некоторой статистике при загрузке типовой страницы сегодня объем данных порядка 2 Мб, кол-во запросов - порядка 70.
https://httparchive.org/reports/state-of-the-web?start=2020_06_01&end=latest&view=list

Чтобы всё это работало быстрее, в 2015 был принят HTTP/2.
Отличия такие (может не всё):
- протокол бинарный, а не текстовый
- обмен так же идет по одному TCP соединению, но по нему может идти параллельно передача нескольких данных в разных "потоках". Я так понимаю, что идут поочередно пакеты из этих разных "потоков". Это решает проблему, что пока с сервера грузится какой-то один ресурс, все остальные ждут в очереди окончания его загрузки.
- Для нормальной работы предыдущего пункта есть приоритизация запросов.
- Есть пуши (push) от сервера. Если раньше клиент запрашивает страницу, видит, что там есть ссылки и запрашивает ещё что-то, то сейчас сервер может сразу отправить нужное. Если сформулировать более в общем, то сервер может отправлять клиенту какие-то ресурсы без запроса (до запроса) клиента.
Пишут, что это может приводить к ухудшению скорости, ширины канала, т.к. сервер не знает, какие ресурсы клиент уже получил, а какие нет и может отпрваить то, что уже у клиента есть. Эта фича опционная, клиент может запросить, чтобы сервер пуши не присылал. Хром в 2022 году вышел с отключенными по-умолчанию пушами. Тут про пуши например.

Понятно, что для того, чтобы это работало, HTTP/2 должен быть реализован как на сервере, так и на клиенте (в браузере). Современные браузеры HTTP/2 поддерживают.

HTTP/3, как я понял, это тоже про скорость, также про безопасность.
Семантика в HTTP/1.1, HTTP/2 и HTTP/3 - одинаковая. У них - одни и те же методы, коды статусов и большинство заголовков.
Отличается транспортный протокол, по которому происходит обмен данными. В HTTP/1.1 и HTTP/2 - это TCP. В HTTP/3 - новый протокол поверх UDP: QUIC. Изначально это вроде был акроним: Quick UDP Internet Connections, но сейчас он вроде используется как просто название. Разработан в Гугле.

Когда речь шла о HTTP/2, то затрагивали такой тормоз. По одному соединению может идти несколько запросов, а потом ответов (pipelining). И когда какой-то ответ идет долго, остальные ждут в очереди. В HTTP/2 это решено мультиплексированием - когда несколько ответов идут по одному TCP-соединению, писал об этом выше.
Но есть ещё один тормоз, который остается и в HTTP/2 - на уровне TCP. TCP - это надежный протокол, обеспечивающий доставку данных. Я когда-то читал, не помню детали, наверное кто-то тут на форуме лучше знает, но в общем, при получении пакета данных получатель отправляет отправителю уведомление, что всё ок. Если нет - то сообщает, что не ок и тогда отправитель пытается послать пакет ещё раз, пока тот не дойдёт благополучно (наверное есть какие-то нюансы). Т.е. пакеты после него ждут, пока TCP разберется с ним. Это называется head-of-line blocking.
В UDP такого механизма нет, там просто отправляется пакет и он либо принимается адресатом, либо нет. В QUIC восстановление потерянных пакетов происходит на уровне этого протокола в отдельном потоке данных. Т.к. тут тоже есть мультиплексирование, то остальным потокам, в которых передаются другие ресурсы, в таком варианте не приходится ждать.
В QUIC интегрирован TLS1.3. Т.е. нет QUIC без TLS. Также эта интегрированность позволяет уменьшить количество запросов-ответов (roundtrip) при установлении соединения. Также, если я правильно понял, зашифрованы отдельные пакеты, поэтому для расшифровки не надо ждать, пока подойдут другие, как это в TCP - для TCP данные - это поток байтов и он не знает о границах пакетов на более высоком уровне.
QUIC может быть реализован не в ядре ОС, а на пользовательском уровне (QUIC can be implemented in the application space, as opposed to being in the operating system kernel.) и, если не ошибаюсь, в каких-то реализациях так и есть.
QUIC - это не UDP, это протокол поверх UDP и он реализует ряд функций, которые есть в TCP, но по-своему, например ту же повторную отправку недошедших пакетов данных.

Пока что всё.

s62 [игнорируется] 

Да, поскольку защищённый и UDP, то, как я понял, сервер слушает на 443 UDP порту.
И ещё в HTTP/2 и HTTP/3 заголовки (headers) идут не в текстововм виде, как в HTTP/1.1, а в бинарном и сжатом.

Да, с UDP поскольку нет понятия соединения, то UDP сервер просто принимает пакеты на своем (UDP) порту (и отправляет ответы). Не знаю, употребляется ли тут понятие "слушает". По логике по-моему это можно так назвать. Ждёт, пока что-то придет, читает пришедшее и отвечает.

В NGINX обмен по HTTP/3 идёт через 443 UDP порт.
https://www.catchpoint.com/http2-vs-http3/nginx-http3