Di default, quando entrambi tcp_tw_reusee tcp_tw_recyclesono disabilitati, il kernel si assicurerà che i socket nello TIME_WAITstato rimangano in quello stato abbastanza a lungo - abbastanza a lungo per essere sicuri che i pacchetti appartenenti a connessioni future non verranno scambiati per i pacchetti in ritardo della vecchia connessione.
Quando si abilita tcp_tw_reuse, i socket in TIME_WAITstato possono essere utilizzati prima della scadenza e il kernel tenterà di assicurarsi che non vi siano collisioni tra i numeri di sequenza TCP. Se si abilita tcp_timestamps(noto anche come PAWS, per la protezione contro i numeri di sequenza spostati), si assicurerà che tali collisioni non possano verificarsi. Tuttavia, è necessario che i timestamp TCP siano abilitati su entrambe le estremità (almeno, questa è la mia comprensione). Vedi la definizione di tcp_twsk_unique per i dettagli cruenti.
Quando lo abiliti tcp_tw_recycle, il kernel diventa molto più aggressivo e farà ipotesi sui timestamp usati dagli host remoti. Seguirà l'ultimo timestamp utilizzato da ciascun host remoto con una connessione in TIME_WAITstato) e consentirà di riutilizzare un socket se il timestamp è aumentato correttamente. Tuttavia, se il timestamp utilizzato dall'host cambia (ovvero si sposta indietro nel tempo), il SYNpacchetto verrà eliminato silenziosamente e la connessione non verrà stabilita (verrà visualizzato un errore simile al "timeout di connessione"). Se vuoi immergerti nel codice del kernel, la definizione di tcp_timewait_state_process potrebbe essere un buon punto di partenza.
Ora, i timestamp non dovrebbero mai tornare indietro nel tempo; salvo che:
- l'host viene riavviato (ma poi, al momento del backup,
TIME_WAITprobabilmente il socket sarà scaduto, quindi non sarà un problema);
- l'indirizzo IP viene rapidamente riutilizzato da qualcos'altro (le
TIME_WAITconnessioni rimarranno un po ', ma altre connessioni verranno probabilmente colpite TCP RSTe questo libererà spazio);
- la traduzione dell'indirizzo di rete (o un firewall smarty-pants) è coinvolta nel mezzo della connessione.
In quest'ultimo caso, è possibile avere più host dietro lo stesso indirizzo IP e, quindi, diverse sequenze di timestamp (o, detti timestamp sono randomizzati ad ogni connessione dal firewall). In tal caso, alcuni host non saranno in grado di connettersi casualmente, poiché sono mappati su una porta per la quale il TIME_WAITbucket del server ha un timestamp più recente. Ecco perché i documenti ti dicono che "i dispositivi NAT o i bilanciatori del carico possono iniziare a eliminare i frame a causa dell'impostazione".
Alcune persone raccomandano di lasciare tcp_tw_recycleda soli, ma abilitare tcp_tw_reusee abbassaretcp_timewait_len . Concordo :-)