Re: [PATCH net-next 00/15] net: introduce QUIC infrastructure and core subcomponents

[Xin Long <lucien.xin@gmail.com>]

On Mon, Jul 7, 2025 at 4:41 AM David Howells <dhowells@redhat.com> wrote:
>
>
> Xin Long <lucien.xin@gmail.com> wrote:
>
> > Introduction
> > ============
> >
> > The QUIC protocol, as defined in RFC9000, offers a UDP-based, secure
> > transport with flow-controlled streams for efficient communication,
> > low-latency connection setup, and network path migration, ensuring
> > confidentiality, integrity, and availability across various deployments.
> >
> > This implementation introduces QUIC support in Linux Kernel, offering
> > several key advantages:
> >
> > - Seamless Integration for Kernel Subsystems: Kernel subsystems such as
> >   SMB and NFS can operate over QUIC seamlessly after the handshake,
> >   leveraging the net/handshake APIs.
> >
> > - Standardized Socket APIs for QUIC: This implementation standardizes the
> >   socket APIs for QUIC, covering essential operations like listen, accept,
> >   connect, sendmsg, recvmsg, close, get/setsockopt, and getsock/peername().
> >
> > - Efficient ALPN Routing: It incorporates ALPN routing within the kernel,
> >   efficiently directing incoming requests to the appropriate applications
> >   across different processes based on ALPN.
> >
> > - Performance Enhancements: By minimizing data duplication through
> >   zero-copy techniques such as sendfile(), and paving the way for crypto
> >   offloading in NICs, this implementation enhances performance and prepares
> >   for future optimizations.
> >
> > This implementation offers fundamental support for the following RFCs:
> >
> > - RFC9000 - QUIC: A UDP-Based Multiplexed and Secure Transport
> > - RFC9001 - Using TLS to Secure QUIC
> > - RFC9002 - QUIC Loss Detection and Congestion Control
> > - RFC9221 - An Unreliable Datagram Extension to QUIC
> > - RFC9287 - Greasing the QUIC Bit
> > - RFC9368 - Compatible Version Negotiation for QUIC
> > - RFC9369 - QUIC Version 2
> >
> > The socket APIs for QUIC follow the RFC draft [1]:
> >
> > - The Sockets API Extensions for In-kernel QUIC Implementations
> >
> > Implementation
> > ==============
> >
> > The core idea is to implement QUIC within the kernel, using a userspace
> > handshake approach.
> >
> > Only the processing and creation of raw TLS Handshake Messages are handled
> > in userspace, facilitated by a TLS library like GnuTLS. These messages are
> > exchanged between kernel and userspace via sendmsg() and recvmsg(), with
> > cryptographic details conveyed through control messages (cmsg).
> >
> > The entire QUIC protocol, aside from the TLS Handshake Messages processing
> > and creation, is managed within the kernel. Rather than using a Upper Layer
> > Protocol (ULP) layer, this implementation establishes a socket of type
> > IPPROTO_QUIC (similar to IPPROTO_MPTCP), operating over UDP tunnels.
> >
> > For kernel consumers, they can initiate a handshake request from the kernel
> > to userspace using the existing net/handshake netlink. The userspace
> > component, such as tlshd service [2], then manages the processing
> > of the QUIC handshake request.
> >
> > - Handshake Architecture:
> >
> >   ┌──────┐  ┌──────┐
> >   │ APP1 │  │ APP2 │ ...
> >   └──────┘  └──────┘
> >   ┌──────────────────────────────────────────┐
> >   │     {quic_client/server_handshake()}     │<─────────────┐
> >   └──────────────────────────────────────────┘       ┌─────────────┐
> >    {send/recvmsg()}      {set/getsockopt()}          │    tlshd    │
> >    [CMSG handshake_info] [SOCKOPT_CRYPTO_SECRET]     └─────────────┘
> >                          [SOCKOPT_TRANSPORT_PARAM_EXT]    │   ^
> >                 │ ^                  │ ^                  │   │
> >   Userspace     │ │                  │ │                  │   │
> >   ──────────────│─│──────────────────│─│──────────────────│───│───────
> >   Kernel        │ │                  │ │                  │   │
> >                 v │                  v │                  v   │
> >   ┌──────────────────┬───────────────────────┐       ┌─────────────┐
> >   │ protocol, timer, │ socket (IPPROTO_QUIC) │<──┐   │ handshake   │
> >   │                  ├───────────────────────┤   │   │netlink APIs │
> >   │ common, family,  │ outqueue  |  inqueue  │   │   └─────────────┘
> >   │                  ├───────────────────────┤   │      │       │
> >   │ stream, connid,  │         frame         │   │   ┌─────┐ ┌─────┐
> >   │                  ├───────────────────────┤   │   │     │ │     │
> >   │ path, pnspace,   │         packet        │   │───│ SMB │ │ NFS │...
> >   │                  ├───────────────────────┤   │   │     │ │     │
> >   │ cong, crypto     │       UDP tunnels     │   │   └─────┘ └─────┘
> >   └──────────────────┴───────────────────────┘   └──────┴───────┘
> >
> > - User Data Architecture:
> >
> >   ┌──────┐  ┌──────┐
> >   │ APP1 │  │ APP2 │ ...
> >   └──────┘  └──────┘
> >    {send/recvmsg()}   {set/getsockopt()}              {recvmsg()}
> >    [CMSG stream_info] [SOCKOPT_KEY_UPDATE]            [EVENT conn update]
> >                       [SOCKOPT_CONNECTION_MIGRATION]  [EVENT stream update]
> >                       [SOCKOPT_STREAM_OPEN/RESET/STOP]
> >                 │ ^               │ ^                     ^
> >   Userspace     │ │               │ │                     │
> >   ──────────────│─│───────────────│─│─────────────────────│───────────
> >   Kernel        │ │               │ │                     │
> >                 v │               v │  ┌──────────────────┘
> >   ┌──────────────────┬───────────────────────┐
> >   │ protocol, timer, │ socket (IPPROTO_QUIC) │<──┐{kernel_send/recvmsg()}
> >   │                  ├───────────────────────┤   │{kernel_set/getsockopt()}
> >   │ common, family,  │ outqueue  |  inqueue  │   │{kernel_recvmsg()}
> >   │                  ├───────────────────────┤   │
> >   │ stream, connid,  │         frame         │   │   ┌─────┐ ┌─────┐
> >   │                  ├───────────────────────┤   │   │     │ │     │
> >   │ path, pnspace,   │         packet        │   │───│ SMB │ │ NFS │...
> >   │                  ├───────────────────────┤   │   │     │ │     │
> >   │ cong, crypto     │       UDP tunnels     │   │   └─────┘ └─────┘
> >   └──────────────────┴───────────────────────┘   └──────┴───────┘
> >
> > Interface
> > =========
> >
> > This implementation supports a mapping of QUIC into sockets APIs. Similar
> > to TCP and SCTP, a typical Server and Client use the following system call
> > sequence to communicate:
> >
> >     Client                             Server
> >   ──────────────────────────────────────────────────────────────────────
> >   sockfd = socket(IPPROTO_QUIC)      listenfd = socket(IPPROTO_QUIC)
> >   bind(sockfd)                       bind(listenfd)
> >                                      listen(listenfd)
> >   connect(sockfd)
> >   quic_client_handshake(sockfd)
> >                                      sockfd = accecpt(listenfd)
> >                                      quic_server_handshake(sockfd, cert)
> >
> >   sendmsg(sockfd)                    recvmsg(sockfd)
> >   close(sockfd)                      close(sockfd)
> >                                      close(listenfd)
> >
> > Please note that quic_client_handshake() and quic_server_handshake()
> > functions are currently sourced from libquic [3]. These functions are
> > responsible for receiving and processing the raw TLS handshake messages
> > until the completion of the handshake process.
> >
> > For utilization by kernel consumers, it is essential to have tlshd
> > service [2] installed and running in userspace. This service receives
> > and manages kernel handshake requests for kernel sockets. In the kernel,
> > the APIs closely resemble those used in userspace:
> >
> >     Client                             Server
> >   ────────────────────────────────────────────────────────────────────────
> >   __sock_create(IPPROTO_QUIC, &sock)  __sock_create(IPPROTO_QUIC, &sock)
> >   kernel_bind(sock)                   kernel_bind(sock)
> >                                       kernel_listen(sock)
> >   kernel_connect(sock)
> >   tls_client_hello_x509(args:{sock})
> >                                       kernel_accept(sock, &newsock)
> >                                       tls_server_hello_x509(args:{newsock})
> >
> >   kernel_sendmsg(sock)                kernel_recvmsg(newsock)
> >   sock_release(sock)                  sock_release(newsock)
> >                                       sock_release(sock)
> >
> > Please be aware that tls_client_hello_x509() and tls_server_hello_x509()
> > are APIs from net/handshake/. They are used to dispatch the handshake
> > request to the userspace tlshd service and subsequently block until the
> > handshake process is completed.
>
> Can you please put this (or something like this) into Documentation/
> somewhere?
>
Yes, there is a patch that adds Documentation/networking/quic.rst in the
subsequent patchset, which I’ll post after this one. It addresses exactly
what you pointed out:

https://github.com/lxin/net-next/commit/9f978448531b958f859bbd48dce8a703b256b25a

Thanks.

Thanks.