Passa al contenuto principale

1. Introduction

1.1. Motivazione​

La creazione tradizionale di una connessione TCP richiede un three-way handshake, che introduce almeno un intero Round-Trip Time (RTT) di ritardo prima che possa iniziare il trasferimento dei dati. Per molte applicazioni moderne, in particolare servizi Web e applicazioni mobili, questa latenza rappresenta un collo di bottiglia significativo per le prestazioni.

Problema di Latenza in uno Scenario Tipico​

Nel TCP tradizionale, il client deve:

  1. Inviare un pacchetto SYN
  2. Attendere la risposta SYN-ACK del server
  3. Inviare la conferma ACK
  4. Solo a quel punto inviare i dati applicativi

Questo significa che il trasferimento dei dati applicativi richiede almeno 1.5 RTT, assumendo che il server risponda immediatamente dopo aver ricevuto l'ACK.

Sfide delle Connessioni HTTP Brevi​

Per il modello richiesta-risposta di HTTP:

  • Ogni nuova connessione richiede un three-way handshake completo
  • Nelle connessioni brevi, ad esempio una singola chiamata API, la latenza dell'handshake può rappresentare una quota elevata del tempo totale
  • Nelle reti ad alta latenza, come le reti mobili, il problema è ancora più marcato

Esempio di calcolo della latenza:

  • Rete con RTT di 50ms: latenza dell'handshake = 50ms
  • Rete con RTT di 200ms, ad esempio transoceanica: latenza dell'handshake = 200ms

Per chiamate API che restituiscono piccole quantità di dati, la latenza dell'handshake può superare il tempo effettivo di trasferimento dei dati.

1.2. Concetti Chiave​

TCP Fast Open (TFO) affronta questo problema consentendo lo scambio di dati durante l'handshake TCP.

Un TFO Cookie è un token crittografico usato per verificare l'identità del client:

  1. Fase di richiesta del cookie:

    • Il client richiede un TFO Cookie durante la prima connessione
    • Il server genera e restituisce il cookie, cifrato in base all'indirizzo IP del client
    • Il client memorizza il cookie per gli usi successivi

  2. Fase Fast Open:

    • Il client include il cookie e i dati applicativi nel pacchetto SYN
    • Il server verifica la validità del cookie
    • Se la verifica ha successo, il server accetta i dati nel SYN e può rispondere immediatamente

Miglioramento delle Prestazioni​

Con TFO, la sequenza temporale del trasferimento dati diventa:

  1. Prima connessione: il client invia SYN, richiedendo un cookie
  2. Connessioni successive: il client invia SYN + cookie + dati; il server elabora immediatamente

Riduzione della latenza: risparmio di 1 RTT completo

Progettazione di Sicurezza​

Il meccanismo dei TFO Cookie fornisce le seguenti protezioni di sicurezza:

  • Anti-Amplification: limita la dimensione dei dati nei pacchetti SYN
  • Anti-Resource Exhaustion: la verifica del cookie conferma l'identità del client
  • Backward Compatibility: i server che non supportano TFO ignorano l'opzione

Terminologia​

Secondo RFC 2119, le parole chiave in questo documento hanno il seguente significato:

  • MUST: requisito assoluto
  • SHOULD: raccomandazione forte, che può essere ignorata in circostanze specifiche
  • MAY: funzionalità completamente opzionale

Casi d'Uso​

TFO è particolarmente adatto ai seguenti scenari:

  • Navigazione Web: richieste HTTP/HTTPS
  • Chiamate API: RESTful API, RPC
  • Applicazioni mobili: richieste frequenti con connessioni brevi
  • Dispositivi IoT: invio periodico di dati

Limitazioni e Considerazioni​

Quando si usa TFO, occorre considerare che:

  • I dati nel SYN possono essere ritrasmessi, quindi sono richieste operazioni idempotenti
  • Alcuni dispositivi di rete possono interferire con le opzioni TCP
  • I cookie hanno una scadenza e devono essere aggiornati periodicamente

Sezione successiva: 2. Protocol Overview descrive in dettaglio il flusso operativo di TFO e i modelli di scambio dei messaggi.

Ultimo aggiornamento il