Package org.eclipse.jetty.quic.common

package org.eclipse.jetty.quic.common

This module contains the main abstractions for the QUIC protocol.

A QuicConnection is a Connection that receives and sends bytes from its underlying DatagramChannelEndPoint.

A QuicConnection manages many QuicSessions, one for each QUIC connection ID.

A QuicSession manages many QUIC streams, identified by a stream ID and represented by QuicStreamEndPoint.

A QuicSession delegates I/O processing to a protocol-specific ProtocolSession, whose responsibility is to use QUIC streams to implement the protocol-specific I/O processing.

The Connection associated with each QuicStreamEndPoint parses the bytes received on the QUIC stream represented by the QuicStreamEndPoint, and generates the bytes to send on that QUIC stream.

On the client side, the layout of the components in case of HTTP/1.1 is the following:

 DatagramChannelEndPoint -- ClientQuicConnection -- ClientQuicSession -- ClientProtocolSession -- QuicStreamEndPoint -- HttpConnectionOverHTTP

The client specific ProtocolSession creates one bidirectional QUIC stream that represent the same transport as a TCP stream, over which HTTP/1.1 bytes are exchanged by the two peers.

On the client side, the layout of the components in case of HTTP/3 is the following:

 DatagramChannelEndPoint -- ClientQuicConnection -- ClientQuicSession -- ClientHTTP3Session -* QuicStreamEndPoint -- ClientHTTP3StreamConnection

In this case, the client specific, HTTP/3 specific, ProtocolSession creates and manages zero or more bidirectional QUIC streams, over which HTTP/3 bytes are exchanged by the two peers.

On the server side, the layout of the components in case of HTTP/1.1 is the following:

 CLIENT  |  SERVER
 clientA                                                   ServerQuicSessionA -- ServerProtocolSessionA -- QuicStreamEndPointA -- HttpConnection
         \                                                /
           DatagramChannelEndPoint -- ServerQuicConnection
         /                                                \
 clientB                                                   ServerQuicSessionB -- ServerProtocolSessionB -- QuicStreamEndPointB -- HttpConnection

The DatagramChannelEndPoint listens on the server port and receives UDP datagrams from all clients.

The server side QuicConnection processes the incoming datagram bytes creating a QuicSession for every QUIC connection ID sent by the clients.

The clients have created a single QUIC stream to send HTTP/1.1 requests, which results in the QuicSessions to create a correspondent QuicStreamEndPoint with its associated HttpConnection.

The path DatagramChannelEndPoint - ServerQuicConnection - ServerQuicSession - ServerProtocolSession - QuicStreamEndPoint behaves exactly like a TCP SocketChannelEndPoint for the associated HttpConnection.

On the server side, the layout of the components in case of HTTP/3 is the following:

 CLIENT  |  SERVER
 clientA                                                   ServerQuicSessionA -# ServerProtocolSessionA -- QuicStreamEndPointA1 -- ServerHTTP3StreamConnection
         \                                                /                                              \ QuicStreamEndPointA2 -- ServerHTTP3StreamConnection
           DatagramChannelEndPoint -- ServerQuicConnection
         /                                                \                                              / QuicStreamEndPointB1 -- ServerHTTP3StreamConnection
 clientB                                                   ServerQuicSessionB -# ServerProtocolSessionB -- QuicStreamEndPointB2 -- ServerHTTP3StreamConnection

In this case, the server specific, HTTP/3 specific, ProtocolSession creates and manages zero or more bidirectional QUIC streams, created by the clients, over which HTTP/3 bytes are exchanged by the two peers.

In a more compact representation, the server side layout is the following:

 DatagramChannelEndPoint -- ServerQuicConnection -* ServerQuicSession -# ServerProtocolSession -* QuicStreamEndPoint -- ServerHTTP3StreamConnection
where -- represents a 1-1 relationship, -* represents a 1-N relationship, and -# represents the place where a new thread is dispatched to process different QUIC connection IDs so that they can be processed in parallel, as it would naturally happen with TCP (which has a "thread per active connection" model).