search

apache / apisix

The Cloud-Native API Gateway
https://apisix.apache.org/blog/
Apache License 2.0
14.3k stars 2.49k forks source link

feat: Integrate QUIC/HTTP3 into APISIX #9752

Open monkeyDluffy6017 opened 1 year ago

monkeyDluffy6017 commented 1 year ago

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.

  1. Switch the SSL library of QUIC branch to quictls

Synchronize with the official Nginx.

NiuBlibing commented 10 months ago

Hello, https://github.com/openresty/openresty/pull/920 is merged, is ready for apisix to support quic?