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).

Class	Description
CloseInfo	A record that captures error code and error reason.
ProtocolSession	Represents an established stateful connection with a remote peer for a specific QUIC connection ID.
ProtocolSession.Factory	A factory for protocol specific instances of ProtocolSession.
QuicConfiguration	A record that captures QUIC configuration parameters.
QuicConnection	A Connection implementation that receives and sends datagram packets via its associated DatagramChannelEndPoint.
QuicErrorCode
QuicSession	Represents a logical connection with a remote peer, identified by a QUIC connection ID.
QuicSession.Listener	A listener for QuicSession events.
QuicSessionContainer	A container that tracks QuicSession instances.
QuicStreamEndPoint	An EndPoint implementation on top of a QUIC stream.
StreamType	The QUIC stream type, either client or server initiated, and either unidirectional or bidirectional.