Newsgroup: it.comp.os.linux.sys
Titolo: Troppi TIME_WAIT

Server web, parecchio frequentato, costantemente tra le 500 e le 1000 
connessioni sulla porta 80 in TIME_WAIT.
In /etc/sysctl.conf ho settato
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 1800
ma non ho notato nessuna diminuzione del numero di connessioni in 
TIME_WAIT (ovviamente ho fatto il necessario perche' le nuove 
impostazioni venissero prese) neanche a distanza di ore. La mia modifica 
e' corretta per ottenere la diminuzione del numero di time_wait o che 
cosa bisogna fare in questi casi?

prima di modificare i parametri del kernel io sarei passato dalle 
impostazioni di rete di apache!!!!! prova a guardare alcune impostazioni 
permettono decisamente di migliorare le cose
-- 
Davide Corrado
System Engineer
WEB CONSULT

 permettono decisamente di migliorare le cose
Sbagliero', ma che cosa c'entra apache? Per apache la connessione e' 
chiusa correttamente, non la vede e non ne sa piu' nulla. E' il kernel 
che nella gestione del protocollo tcp/ip mantiene in stato di time_wait 
le connessioni chiuse.

mi sa che hai ragione ho letto troppo frettolosamente la tua richiesta


Sgranocchiando il cranio di G.G.G, vi trovai inciso:

Se trovi tanti time_wait, vuol dire che hai tante connessioni che si
chiudono. Punto. Abbassare la durata dello stato di TIME_WAIT può essere
una soluzione foriera di problemi. Il suo valore è stimato sulla base di
osservazioni non spannometriche sulle possibilità di un pacchetto di
giungere in ritardo, ed è di 2 minuti. Ancora hard-coded, per quanto ne
so.
C'è questo piccolo (anche se datato) thread qui:
http://www.ussg.iu.edu/hypermail/linux/kernel/0006.2/0474.html
Cambiare quel valore significa mettere mano al codice.
Nulla ti impedisce di farlo (ringraziando i cielo), purchè tu sappia
esattamente quali possono essere le implicazioni:
Non sarebbe molto bello iniziare ad avere connessioni crashate per
corruzione della comunicazione tcp, che è esattamente quello che accade
se il riciclo dei socket avviene troppo rapidamente.
E, per esperienza [1], mettersi a debuggare i problemi di 'sto genere non
è divertente...
[1] Ho passato un certo tempo a debuggare i problemi dovuti a
comportamenti anomali dello stack di alcuni apparati embedded proprietari.
Alla fine si son stufati prima loro e hanno cambiato stack...
-- 
cat: .signature: No such file or directory

 corruzione della comunicazione tcp, che è esattamente quello che accade
E' possibile che venga corrotta una connessione tcp/ip aperta 
successivamente alla cancellazione prematura di uno stato di time_wait?
Le connessioni sono identificate da un numero immagino, da 0 a 65000 ma 
magari anche di piu'. La scelta dell'identificativo immagino non sia 
quella di prendere il precedente e sommarci 1 per evitare i problemi di 
sicurezza (es. ip spoofing) legati alla predicibilita' 
dell'identificativo della connessione tcp/ip. Quale regola usa linux 
distribuzione rh/fedora per scegliere un nuovo identificativo?



Non è quello il problema, almeno non principalmente.
Le connessioni sono identificate in funzione della combinazione
SRC_IP:SRC_PORT:DST_IP:DST_PORT
Scopo dello stato TIME_WAIT è star lì ad occupare tale combinazione per
un certo tempo dopo il termine delle counicazioni, in modo da evitare che
tale combinazione possa essere riutilizzata, fino a che non vi è la
ragionevole certezza che qualsiasi pacchetto appartenente alla connesione
non sia arrivato o morto per strada. Nel corso di tale tempo, tutto i
datagrammi in arrivo e appartenenti a tale combinazione (socket) vengono
scartati.
Se la combinazione (che viene utilizzata per associare il contenuto del
singolo datagramma IP al socket cui appartiene) viene riutilizzata troppo
presto, può accadere che un pacchetto appartenente alla "incarnazione
precedente" di tale combinazione arrivi *dopo* il ciclo di vita della
connessione cui apparteneva (per via di un route loop, piutosto che
persistenza in queue a causa di una congestione su un router, whatever..),
venendo erroneamente riconosciuta come parte della comunicazione attuale.
Se accadesse una cosa del genere, e se la finestra di trasmissione cui si
infila tale pacchetto fosse parte della finestra della connessione
attuale, tale pacchetto può andare a corrompere il flusso di dati della
nuova incarnazione della connessione.
A ovvia "protezione" da tale prospettiva si *dovrebbe* a sua volta porre
la presenza di uno stato TIME_WAIT anche dal lato del client che stia
collegandosi (d'altra parte deve esserci una collimanza anche -anzi, solo-
dei SUOI valori), ma
- essendo una macchina a stati finiti ci si attende che entrambe le parti
siano in grado di gestire da sole anche i casi critici, pertanto affidarsi
a tale considerazione è un errore
- in un mondo di ip dinamici e di macchine che si rebootano (e di stack
fatti coi piedi come posso testimoniare in prima persona) non puoi avere
la garanzia che chi sta dall'altra parte sia sempre lui (dynamic), o che
abbia memoria del suo stato precedente (reboot) o che anche solo gliene
freghi qualcosa (fuffaware).
Ovvio che ciò non ti salva dal datagramma forgiato ad-hoc (tcp
injection), ma serve a dare la ragionevole garanzia che un evento del
genere non possa avvenire "per sbaglio"...
Aloha...