Gregory's Server
Обновился #OpenSSL до 3.4.0 и опять без полноценной нормальной поддержки #QUIC, т.е. непригодный для #HTTP/3 на серверной стороне. И, соответственно, ещё не ясно на сколько хорошо сделана клиентская часть :)
Аж вспомнились времена, когда желая получить #curl поддерживающий нормально работу #HTTP/3 приходилось собирать его из исходников с #GnuTLS, вместо #OpenSSL.
#HTTP/3 работает не через #tcp/ip, а использует в качестве транспорта протокол #QUIC (Quick UDP Internet Connections), т.е. передаёт данные поверх #udp, без использования #tcp/ip, не устанавливая tcp-соединений. Вот картинка про современный #HTTP https://daniel.haxx.se/blog/wp-content/uploads/2023/01/HTTP_3-October-2022.jpg
Сам по себе #QUIC не умеет передавать данные в открытом виде, а может только через #TLS v1.3, т.е. в обязательном порядке только зашифрованные (используется вариант #TLS близкий к #DTLS, а не тот вариант #TLS что применяется повсеместно для tcp-соединений).
#curl может использовать разные альтернативы #OpenSSL, т.к. изначально спроектирован таким образом, что не привязан именно к #OpenSSL, вот официальная документация что и как с криптографическими бэкендами. Примерно там же есть сравнение разных бэкендов.
Что предлагаю по реализации HTTP/3 сами авторы?
Вот зелёным выделена комбинация библиотек, которую полагают наиболее стабильным и полноценным вариантом https://everything.curl.dev/internals/slide-http3-backends.jpg
Вся загвоздка в том, что #OpenSSL пытается содержать в себе реализацию #QUIC, а не использует реализацию в виде какой-то библиотеки.
Что получается с предлагаемой комбинацией?
Протокол #HTTP/3 реализуется через библиотеку #nghttp3, необходимая реализация #QUIC через #ngtcp2, а для TLS используется #GnuTLS или же #wolfSSL
Вот официальная документация с деталями по сборке отдельных составляющих. Если доступный в системе #GnuTLS далёк от свежих версий, то легко собирается из исходников.
В целом, про варианты #curl с поддержкой #HTTP/3 очень хорошо и достойно расписано здесь. Есть и перевод этой публикации на русском языке.
#https #http #openssl #lang_ru @Russia
Аж вспомнились времена, когда желая получить #curl поддерживающий нормально работу #HTTP/3 приходилось собирать его из исходников с #GnuTLS, вместо #OpenSSL.
#HTTP/3 работает не через #tcp/ip, а использует в качестве транспорта протокол #QUIC (Quick UDP Internet Connections), т.е. передаёт данные поверх #udp, без использования #tcp/ip, не устанавливая tcp-соединений. Вот картинка про современный #HTTP https://daniel.haxx.se/blog/wp-content/uploads/2023/01/HTTP_3-October-2022.jpg
Сам по себе #QUIC не умеет передавать данные в открытом виде, а может только через #TLS v1.3, т.е. в обязательном порядке только зашифрованные (используется вариант #TLS близкий к #DTLS, а не тот вариант #TLS что применяется повсеместно для tcp-соединений).
#curl может использовать разные альтернативы #OpenSSL, т.к. изначально спроектирован таким образом, что не привязан именно к #OpenSSL, вот официальная документация что и как с криптографическими бэкендами. Примерно там же есть сравнение разных бэкендов.
Что предлагаю по реализации HTTP/3 сами авторы?
Вот зелёным выделена комбинация библиотек, которую полагают наиболее стабильным и полноценным вариантом https://everything.curl.dev/internals/slide-http3-backends.jpg
Вся загвоздка в том, что #OpenSSL пытается содержать в себе реализацию #QUIC, а не использует реализацию в виде какой-то библиотеки.
Что получается с предлагаемой комбинацией?
Протокол #HTTP/3 реализуется через библиотеку #nghttp3, необходимая реализация #QUIC через #ngtcp2, а для TLS используется #GnuTLS или же #wolfSSL
Вот официальная документация с деталями по сборке отдельных составляющих. Если доступный в системе #GnuTLS далёк от свежих версий, то легко собирается из исходников.
В целом, про варианты #curl с поддержкой #HTTP/3 очень хорошо и достойно расписано здесь. Есть и перевод этой публикации на русском языке.
#https #http #openssl #lang_ru @Russia