Обновился #
OpenSSL до 3.4.0 и опять без полноценной нормальной поддержки #
QUIC, т.е. непригодный для #
HTTP/3 на серверной
стороне. И, соответственно, ещё не ясно на сколько хорошо сделана клиентская часть :)
Аж вспомнились времена, когда желая получить #
curl поддерживающий нормально работу #
HTTP/3 приходилось собирать его из исходников с аналогами/форками #
OpenSSL.
#
HTTP/3 работает не через tcp-соединения, а использует в качестве транспорта протокол QUIC (Quick UDP Internet Connections), т.е. передаёт данные поверх udp без использования абстракций и сущностей tcp. Вот картинка про современный #
HTTP Сам по себе #
QUIC не умеет передавать данные в открытом виде, а может только через #
TLS v1.3, т.е. в обязательном порядке только зашифрованные. Тем самым в QUIC используется встроенный вариант TLS 1.3 крайне близкий/схожий с #
DTLS, поскольку работа протокола идёт на уровне обмена udp-пакетами, а не tcp-соединений.
#
curl может использовать разные альтернативы OpenSSL, т.к. изначально спроектирован таким образом, что не завязан именно на OpenSSL:
Что предлагают по HTTP/3 авторы curl?Вот зелёным выделена комбинация библиотек, которую полагают наиболее стабильным и полноценным вариантом
Вся загвоздка в том, что #
OpenSSL пытается содержать в себе реализацию #
QUIC, а не использует реализацию в виде какой-то библиотеки.
Что получается в целом?
Протокол #
HTTP/3 реализуется через библиотеку #
nghttp3.
Необходимая реализация #
QUIC через #
ngtcp2.
А для TLS используется #
GnuTLS или же #
wolfSSL или что-то ещё:
The OpenSSL forks #LibreSSL, #BoringSSL, #AWS-LC and #quictls support the QUIC API that #curl works with using #ngtcp2.
Вот из документация примеры и
детали по сборке этих составляющих. Если выбрана #
GnuTLS и в системе версия далёкая от свежих, то сама она довольно быстро собирается из исходников.
В целом, вообще, про варианты добавления поддержки #
HTTP/3 очень достойно расписано
здесь. И есть перевод этой публикации на
русском языке.
#
https #
http #
openssl #
softwaredevelopment #
lang_ru @
Russia
