19. Tipi e formati di frame

Come descritto nella Sezione 12.4, i pacchetti contengono uno o più frame. Questa sezione descrive il formato e la semantica dei tipi di frame QUIC di base.

19.1 Frame PADDING

Un frame PADDING (type=0x00) non ha valore semantico. I frame PADDING possono essere utilizzati per aumentare la dimensione di un pacchetto. Il padding può essere utilizzato per aumentare un pacchetto Initial alla dimensione minima richiesta o per fornire protezione contro l'analisi del traffico per i pacchetti protetti.

19.2 Frame PING

Gli endpoint possono utilizzare frame PING (type=0x01) per verificare che i loro peer siano ancora vivi o per verificare la raggiungibilità al peer. Il frame PING non contiene campi aggiuntivi.

19.3 Frame ACK

I ricevitori inviano frame ACK (tipi 0x02 e 0x03) per informare i mittenti dei pacchetti che hanno ricevuto ed elaborato. Il frame ACK contiene uno o più intervalli ACK. Gli intervalli ACK identificano i pacchetti riconosciuti.

19.3.1 Intervalli ACK

Ogni intervallo ACK consiste in valori alternati di Gap e ACK Range Length in ordine decrescente del numero di pacchetto.

19.3.2 Conteggi ECN

Il frame ACK utilizza il bit meno significativo (cioè, tipo 0x03) per indicare feedback ECN e segnalare la ricezione di pacchetti QUIC con codepoint ECN associati di ECT(0), ECT(1), o CE nell'intestazione IP del pacchetto.

19.4 Frame RESET_STREAM

Un endpoint utilizza un frame RESET_STREAM (type=0x04) per terminare bruscamente la parte di invio di uno stream.

19.5 Frame STOP_SENDING

Un endpoint utilizza un frame STOP_SENDING (type=0x05) per comunicare che i dati in arrivo vengono scartati alla ricezione secondo la richiesta dell'applicazione.

19.6 Frame CRYPTO

Un frame CRYPTO (type=0x06) è utilizzato per trasmettere messaggi di handshake crittografico. Può essere inviato in tutti i tipi di pacchetto tranne 0-RTT.

19.7 Frame NEW_TOKEN

Un server invia un frame NEW_TOKEN (type=0x07) per fornire al client un token da inviare nell'intestazione di un pacchetto Initial per una connessione futura.

19.8 Frame STREAM

I frame STREAM creano implicitamente uno stream e trasportano dati dello stream. Il frame STREAM assume la forma 0b00001XXX (o l'insieme di valori da 0x08 a 0x0f).

19.9 Frame MAX_DATA

Un frame MAX_DATA (type=0x10) è utilizzato nel controllo di flusso per informare il peer della quantità massima di dati che possono essere inviati sulla connessione nel suo insieme.

19.10 Frame MAX_STREAM_DATA

Un frame MAX_STREAM_DATA (type=0x11) è utilizzato nel controllo di flusso per informare un peer della quantità massima di dati che possono essere inviati su uno stream.

19.11 Frame MAX_STREAMS

Un frame MAX_STREAMS (type=0x12 o 0x13) informa il peer del numero cumulativo di stream di un dato tipo che è autorizzato ad aprire.

19.12 Frame DATA_BLOCKED

Un mittente DOVREBBE inviare un frame DATA_BLOCKED (type=0x14) quando desidera inviare dati ma è incapace di farlo a causa del controllo di flusso a livello di connessione.

19.13 Frame STREAM_DATA_BLOCKED

Un mittente DOVREBBE inviare un frame STREAM_DATA_BLOCKED (type=0x15) quando desidera inviare dati ma è incapace di farlo a causa del controllo di flusso a livello di stream.

19.14 Frame STREAMS_BLOCKED

Un mittente DOVREBBE inviare un frame STREAMS_BLOCKED (type=0x16 o 0x17) quando desidera aprire uno stream ma è incapace di farlo a causa del limite massimo di stream impostato dal suo peer.

19.15 Frame NEW_CONNECTION_ID

Un endpoint invia un frame NEW_CONNECTION_ID (type=0x18) per fornire al suo peer ID di connessione alternativi che possono essere utilizzati per interrompere la correlazione durante la migrazione di connessioni.

19.16 Frame RETIRE_CONNECTION_ID

Un endpoint invia un frame RETIRE_CONNECTION_ID (type=0x19) per indicare che non utilizzerà più un ID di connessione emesso dal suo peer.

19.17 Frame PATH_CHALLENGE

Gli endpoint possono utilizzare frame PATH_CHALLENGE (type=0x1a) per verificare la raggiungibilità al peer e per la validazione del percorso durante la migrazione della connessione.

19.18 Frame PATH_RESPONSE

Un frame PATH_RESPONSE (type=0x1b) è inviato in risposta a un frame PATH_CHALLENGE.

19.19 Frame CONNECTION_CLOSE

Un endpoint invia un frame CONNECTION_CLOSE (type=0x1c o 0x1d) per notificare al suo peer che la connessione è in fase di chiusura. Il frame CONNECTION_CLOSE con un tipo di 0x1c è utilizzato per segnalare errori a livello QUIC, o l'assenza di errori. Il frame CONNECTION_CLOSE con un tipo di 0x1d è utilizzato per segnalare un errore con l'applicazione che utilizza QUIC.

19.20 Frame HANDSHAKE_DONE

Il server utilizza un frame HANDSHAKE_DONE (type=0x1e) per segnalare la conferma dell'handshake al client.

19.21 Frame di estensione

I frame QUIC non utilizzano una codifica auto-descrittiva. Un endpoint deve quindi comprendere la sintassi di tutti i frame prima di poter elaborare con successo un pacchetto. Ciò consente una codifica efficiente dei frame, ma significa che un endpoint non può inviare un frame di un tipo sconosciuto al suo peer.

Un'estensione a QUIC che desidera utilizzare un nuovo tipo di frame DEVE prima assicurarsi che un peer sia in grado di comprendere il frame. Un endpoint può utilizzare un parametro di trasporto per segnalare la sua disponibilità a ricevere tipi di frame di estensione.