Appendix B. Duplicates from Earlier Connection Incarnations (Duplicati da incarnazioni di connessione precedenti)

Appendix B: Duplicates from Earlier Connection Incarnations (Duplicati da incarnazioni di connessione precedenti)

Ci sono due casi da considerare: (1) un sistema che si arresta in modo anomalo (e perde lo stato della connessione) e si riavvia, e (2) la stessa connessione viene chiusa e riaperta senza perdita dello stato dell'host. Questi saranno descritti nelle due sezioni seguenti.

B.1 System Crash with Loss of State (Crash del sistema con perdita dello stato)

Il tempo di silenzio TCP di un MSL all'avvio del sistema gestisce la perdita dello stato della connessione in un crash/riavvio del sistema. Per una spiegazione, vedere ad esempio "When to Keep Quiet" nella specifica del protocollo TCP [Postel81]. Il MSL richiesto qui non dipende dalla velocità di trasferimento. L'MSL TCP attuale di 2 minuti sembra accettabile come compromesso operativo, poiché molti sistemi host impiegano questo tempo per avviarsi dopo un crash.

Tuttavia, l'opzione timestamp può essere utilizzata per allentare i requisiti MSL (o per fornire sicurezza aggiuntiva contro la corruzione dei dati). Se vengono utilizzati i timestamp e se l'orologio timestamp può essere garantito come monotono su un crash/riavvio del sistema, cioè se il primo valore dell'orologio timestamp del mittente dopo un crash/riavvio può essere garantito come maggiore dell'ultimo valore prima del riavvio, allora un tempo di silenzio sarà inutile.

Per dispensare totalmente dal tempo di silenzio richiederebbe che l'orologio host sia sincronizzato con una fonte di tempo stabile nel periodo di crash/riavvio, con una precisione di un tick dell'orologio timestamp o migliore. Possiamo allontanarci da questo requisito rigoroso per sfruttare la sincronizzazione approssimativa dell'orologio. Supponiamo che l'orologio sia sempre risincronizzato entro N tick dell'orologio timestamp e che l'avvio (esteso con un tempo di silenzio, se necessario) richieda più di N tick. Questo garantirà la monotonicità dei timestamp, che possono quindi essere utilizzati per rifiutare vecchi duplicati anche senza un MSL applicato.

B.2 Closing and Reopening a Connection (Chiusura e riapertura di una connessione)

Quando una connessione TCP viene chiusa, un ritardo di 2*MSL nello stato TIME-WAIT vincola la coppia di socket per 4 minuti (vedere Sezione 3.5 di [Postel81]). Le applicazioni costruite su TCP che chiudono una connessione e ne aprono una nuova (ad esempio, una connessione di trasferimento dati FTP che utilizza la modalità Stream) devono scegliere una nuova coppia di socket ogni volta. Il ritardo TIME-WAIT serve a due scopi diversi:

(a) Implement the full-duplex reliable close handshake of TCP. (Implementare l'handshake di chiusura affidabile full-duplex di TCP)

Il tempo appropriato per ritardare il passaggio di chiusura finale non è realmente correlato al MSL; dipende invece dal RTO per i segmenti FIN e quindi dal RTT del percorso. (Si potrebbe sostenere che il lato che invia un FIN sa quale grado di affidabilità necessita, e quindi dovrebbe essere in grado di determinare la lunghezza del ritardo TIME-WAIT per il destinatario del FIN. Questo potrebbe essere realizzato con un'opzione TCP appropriata nei segmenti FIN.)

Sebbene non esista un limite superiore formale sul RTT, la pratica comune dell'ingegneria di rete rende un RTT superiore a 1 minuto molto improbabile. Pertanto, il ritardo di 4 minuti nello stato TIME-WAIT funziona in modo soddisfacente per fornire una chiusura TCP full-duplex affidabile. Si noti ancora che questo è indipendente dall'applicazione dell'MSL e dalla velocità della rete.

Lo stato TIME-WAIT potrebbe causare un problema di prestazioni indiretto se un'applicazione dovesse chiudere ripetutamente una connessione e aprirne un'altra a una frequenza molto elevata, poiché il numero di porte TCP disponibili su un host è inferiore a 2**16. Tuttavia, le alte velocità di rete non sono il principale contributore a questo problema; il RTT è il fattore limitante nella velocità con cui le connessioni possono essere aperte e chiuse. Pertanto, questo problema non sarà peggiore a velocità di trasferimento elevate.

(b) Allow old duplicate segments to expire. (Consentire la scadenza di vecchi segmenti duplicati)

Per sostituire questa funzione dello stato TIME-WAIT, un meccanismo dovrebbe operare attraverso le connessioni. PAWS è definito rigorosamente all'interno di una singola connessione; l'ultimo timestamp TS.Recent è conservato nel blocco di controllo della connessione e scartato quando una connessione viene chiusa.

Un meccanismo aggiuntivo potrebbe essere aggiunto al TCP, una cache per host dell'ultimo timestamp ricevuto da qualsiasi connessione. Questo valore potrebbe quindi essere utilizzato nel meccanismo PAWS per rifiutare vecchi segmenti duplicati da incarnazioni precedenti della connessione, se l'orologio timestamp può essere garantito di aver fatto almeno un tick da quando la vecchia connessione era aperta. Ciò richiederebbe che il ritardo TIME-WAIT più il RTT insieme siano almeno un tick dell'orologio timestamp del mittente. Tale estensione non fa parte della proposta di questo RFC.

Si noti che questa è una variante del meccanismo proposto da Garlick, Rom e Postel [Garlick77], che richiedeva a ciascun host di mantenere record di connessione contenenti i numeri di sequenza più alti su ogni connessione. Utilizzando invece i timestamp, è necessario mantenere solo una quantità per host remoto, indipendentemente dal numero di connessioni simultanee a quell'host.