monkeyDluffy6017 opened a new issue, #9752:
URL: https://github.com/apache/apisix/issues/9752
### Description
# Background
Recently Nginx released the main line version 1.25.0, which introduces
support for QUIC and HTTP/3 protocols. Nginx has officially entered the HTTP/3
era. The main improvements of HTTP/3 compared to HTTP/2 are:
1. No TCP layer head-of-line blocking. The multiple streams on a QUIC
connection have no dependencies and are independent, unrestricted by underlying
protocols. If any stream experiences packet loss, it will only affect that
stream and not others.
2. Quick connection establishment. QUIC incorporates TLS 1.3 so a connection
and a TLS key negotiation can be completed ‘simultaneously’ with just one RTT.
Even on the second connection, application data packets can be sent along with
QUIC handshake information (connection information + TLS information) achieving
a 0-RTT effect.
3. Connection migration. QUIC protocol does not “bind” connections using a
quadruple but identifies the two communication endpoints through a ‘Connection
ID’. Client and server can each choose a set of IDs to label themselves so that
even if a network changes after a mobile device changes location, causing an IP
address change, if context information (such as connection ID and TLS key) is
maintained, the original connection can be ‘seamlessly’ reused, eliminating the
cost of reconnection.
Following the support of HTTP/3 can give Apache APISIX more advantages in
terms of performance, security, and future development, thereby providing a
better user experience and meeting the changing internet needs, keeping APISIX
in the lead.
# Problem to be solved
To follow the QUIC feature, integration of the latest version of nginx is
needed. APISIX is developed based on OpenResty. The latest OpenResty supports
nginx version 1.21.4. As nginx’s QUIC feature is still experimental and not
stable enough, OpenResty officially may not upgrade to the latest nginx version
supporting QUIC in the short term. Thus, we need to upgrade nginx, package, and
test the new OpenResty ourselves.
# The benefits of solving this problem
1. Show the advancement of APISIX
2. Meet the needs of community users support for HTTP3
# Goals
1. Clarify in what form the version that supports http3 is released
2. Clarify how to integrate nginx and ssl library
# Scope of requirements
## 1. In what form to release APISIX version supporting http3
Plan to support http3 in open-source version first. There are two ways to
achieve this:
**a) Directly support http3 in the main line version of APISIX**
Advantages: Only one set of packaging process needs to be maintained, easy
to manage, and it’s also convenient for community users to participate in new
feature testing.
Disadvantages: The unofficial openresty has not been fully tested, which
might affect the stability of other features of the APISIX main-line version.
As new features can be unstable, after being integrated into the main-line
version, a lot of manpower support is needed.
**b) Creating a new branch/repository to support http3**
Advantages: Does not affect the stability of the main-line version. At the
same time, it’s convenient for interested users to upgrade and test on their
own. It can be used as a technological demonstration and only needs manpower
support when customers have a clear need.
Disadvantages: It’s necessary to maintain multiple branches/repositories,
which is not convenient to manage. Also, user participation might not be as
high.
## 2. How to integrate the nginx version that supports quic
Nginx started developing quic features based on version 1.17.8, merging main
line version modifications while developing, and finally merging to the main
line in version 1.25.0. The latest OpenResty supports nginx version 1.21.4, we
have two plans:
**a) Merging quic-related features into the nginx version (1.21.4) supported
by OpenResty**
Advantages: Only quic-related changes were merged, so there’s small conflict
with openresty, no extra development work is needed.
Disadvantages: This is not the official nginx version and lacks
corresponding tests. Although nginx officially has public test cases, it’s not
sure whether such changes to nginx will introduce new problems.
**b) Upgrade to the latest nginx version (1.25.1)**
Advantages: Since it has gone through official testing, it can guarantee
nginx’s stability to the greatest extent.
Disadvantages: The latest version of nginx has many changes, and there’s a
lot of conflicts with openresty, so more development and thorough testing is
needed.
## 3. How to integrate QUIC‑enabled SSL library.
The QUIC feature of Nginx requires the SSL/TLS library to provide the QUIC
interface. At present, there are four options:
a) openssl
NGINX usually uses OpenSSL as an external dependency, but currently, OpenSSL
does not support QUIC. We can still configure to use the OpenSSL compatibility
layer, which simulates the BoringSSL QUIC API for use with OpenSSL, but the
OpenSSL compatibility mode does not support 0-RTT.
b) BoringSSL
BoringSSL is a branch version of OpenSSL used by Google, but Google
officially stated that although the BoringSSL project is open source, it is not
recommended for widespread use in production environments because it is
adjusted according to Google’s own needs and some APIs may not be stable. Nginx
officially first used BoringSSL.
c) LibreSSL
LibreSSL is another branch of OpenSSL created and maintained by the OpenBSD
project, aimed at providing a simpler, safer, and easier to maintain
alternative. It offers a QUIC API similar to BoringSSL. The main feature is
stronger security.
d) QuicTLS
QuicTLS is a branch of OpenSSL that supports QUIC. It was developed by
Akamai and Microsoft and offers a QUIC API similar to BoringSSL. The upstream
syncs with OpenSSL, and the only changes to OpenSSL are the addition of QUIC
support. It is suitable for those who do not want to use BoringSSL but want to
experience QUIC. Microsoft’s MsQuic and Google’s Chromium QUIC are already in
use, but those QUIC changes are not intended for adoption by the official
OpenSSL. **At present, the official Nginx is built based on QuicTLS for binary
distribution.**
# My opinion
1. Create a new branch in APISIX to support QUIC features.
The stability of existing users’ usage is the most important thing
2. Build a new openresty based on nginx 1.25.1.
Developing with a stable Nginx version can reduce issues.
3. Switch the SSL library of QUIC branch to quictls
Synchronize with the official Nginx.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
