+Come riportato da Stevens (FIXME citare) lo stato \texttt{TIME\_WAIT} è
+probabilmente uno degli aspetti meno compresi del protocollo TCP, è infatti
+comune trovare nei newsgroup domande su come sia possibile evitare che
+un'applicazione resti in questo stato lasciando attiva una connessione ormai
+conclusa; la risposta è che non deve essere fatto, ed il motivo cercheremo di
+spiegarlo adesso.
+
+Come si è visto nell'esempio precedente (vedi \curfig) \texttt{TIME\_WAIT} è
+lo stato finale in cui il capo di una connessione che esegue la chiusura
+attiva resta prima di passare alla chiusura definitiva della connessione. Il
+tempo in cui l'applicazione resta in questo stato deve essere due volte la MSL
+(\textit{Maximum Segment Lifetime}).
+
+La MSL è la stima del massimo periodo di tempo che un pacchetto IP può vivere
+sulla rete; questo tempo è limitato perché ogni pacchetto IP può essere
+ritrasmesso dai router un numero massimo di volte (detto \textit{hop limit}).
+Il numero di ritrasmissioni consentito è indicato dal campo TTL dell'header di
+IP (per maggiori dettagli vedi \ref{sec:appA_xxx}), e viene decrementato ad
+ogni passaggio da un router; quando si annulla il pacchetto viene scartato.
+Siccome il numero è ad 8 bit il numero massimo di ``salti'' è di 255, pertanto
+anche se il TTL (da \textit{time to live}) non è propriamente un limite sul
+tempo di vita, si stima che un pacchetto IP non possa restare nella rete per
+più di MSL secondi.
+
+Ogni implementazione del TCP deve scegliere un valore per la MSL (l'RFC1122
+raccomanda 2 minuti, linux usa 30 secondi), questo comporta una durata dello
+stato \textsl{TIME\_WAIT} che a seconda delle implementazioni può variare fra
+1 a 4 minuti.
+
+Lo stato \texttt{TIME\_WAIT} viene utilizzato dal protocollo per due motivi
+principali:
+\begin{itemize}
+\item implementare in maniera affidabile la terminazione della connessione
+ in entrambe le direzioni.
+\item consentire l'eliminazione dei segmenti duplicati dalla rete.
+\end{itemize}
+
+Il punto è che entrambe le ragioni sono importanti, anche se spesso si fa
+riferimento solo alla prima; ma è solo se si tiene conto della seconda che si
+capisce il perché della scelta di un tempo pari al doppio della MSL come
+durata di questo stato.
+
+Il primo dei due motivi precedenti si può capire tornando a \curfig: assumendo
+che l'ultimo ACK della sequenza (quello del capo che ha eseguito la chiusura
+attiva) vanga perso, chi esegue la chiusura passiva non ricevndo risposta
+rimanderà un ulteriore FIN, per questo motivo chi esegue la chiusura attiva
+deve mantenere lo stato della connessione per essere in grado di reinviare
+l'ACK e chiuderla correttamente. Se non fosse così la risposta sarebbe un RST
+(un altro tipo si segmento) che verrebbe interpretato come un errore.
+
+Se il TCP deve poter chiudere in maniera pulita entrambe le direzioni della
+connessione allora deve essere in grado di affrontare la perdita di uno
+qualunque dei quattro segmenti che costituiscono la chiusura. Per questo
+motivo lo stato \texttt{TIME\_WAIT} deve essere mantenuto anche dopo l'invio
+dell'ultimo ACK per poter essere in grado di poterne gestire l'eventuale
+ritrasmissione in caso di perdita.
+
+
+Il secondo motivo è più complesso da capire, e necessita di spiegare meglio
+gli scenari in cui accade che i pacchetti si possono perdere nella rete o
+restare intrappolati, per poi riemergere.
+
+Il caso più comune in cui questo avviene è quello di anomalie
+nell'instradamento; può accadere cioè che un router smetta di funzionare o che
+una connessione fra due router si interrompa. In questo caso i protocolli di
+instradamento dei pacchetti possono impiegare diverso temo (anche dell'ordine
+dei minuti) prima di trovare e stabilire un percorso alternativo per i
+pacchetti. Nel frattempo possono accadere casi in cui un router manda i
+pacchetti verso un'altro e quest'ultimo li rispedisce indietro, o li manda ad
+un terzo router che li rispedisce al primo, si creano cioè dei circoli (i
+cosiddetti \textit{routing loop}) in cui restano intrappolati i pacchetti.
+
+Se uno di questi pacchetti intrappolati è un segmento di TCP chi l'ha inviato,
+non ricevendo risposta, provvederà alla ritrasmissione e se nel frattempo sarà
+stata stabilita una strada alternativa il pacchetto ritrasmesso giungerà a
+destinazione. Ma se dopo un po' di tempo (che non supera il limite dell'MSL)
+l'anomalia viene a cessare il circolo di instadamento viene spezzato i
+pacchetti intrappolati potranno essere inviati alla destinazione finale, con
+la conseguenza di avere dei pacchetti duplicati; questo è un caso che il TCP
+deve essere in grado di gestire.
+
+Allora per capire la seconda ragione per l'esistenza dello stato
+\texttt{TIME\_WAIT} si consideri il caso seguente: si supponga di avere una
+connessione fra l'IP 195.110.112.236 porta 1550 e l'IP 192.84.145.100 porta
+22, che questa venga chiusa e che poco dopo si ristabilisca la stessa
+connessione fra gli stessi IP sulle stesse porte (quella che viene detta,
+essendo gli stessi porte e numeri IP, una nuova \textsl{incarnazione} della
+connessione precedente); in questo caso ci si potrebbe trovare con dei
+pacchetti duplicati relativi alla precedente connessione che riappaiono nella
+nuova.
+
+Ma fintanto che il socket non è chiuso una nuova incarnazione non può essere
+creata, per questo un socket TCP resta sempre nello stato \texttt{TIME\_WAIT}
+per un periodo di 2MSL, in modo da attendere MSL secondi per essere sicuri che
+tutti i pacchetti duplicati in arrivo siano stati ricevuti (e scartati) o che
+nel frattempo siano stati eliminati dalla rete, e altri MSL secondi per essere
+sicuri che lo stesso avvenga le risposte nella direzione opposta.
+
+In questo modo il TCP si assicura che quando una viene creata una nuova
+connessione tutti gli eventuali segmenti residui di una precedente connessione
+che possono causare disturbi sono stati eliminati dalla rete.
+
+
+\subsection{I numeri di porta}
+\label{sec:TCPel_port_num}
+
+In un ambiente multitasking in un dato momento più processi possono dover
+usare sia UDP che TCP, e ci devono poter essere più connessioni in
+contemporanea. Per poter tenere distinte le diverse connessioni entrambi i
+protocolli usano i \textsl{numeri di porta}, che fanno parte, come si può
+vedere in \ref{sec:sock_sa_ipv4} e \ref{sec:sock_sa_ipv6} pure delle strutture
+degli indirizzi del socket.
+
+Quando un client contatta un server deve poter identificare con quale dei vari
+possibili server attivi intende parlare. Sia TCP che UDP definiscono un gruppo
+di \textsl{porte conosciute} (le cosiddette \textit{well-known port}) che
+identificano una serie di servizi noti (ad esempio la porta 22 identifica il
+servizio \texttt{ssh}) effettuati da appositi server che rispondono alle
+connessioni verso tali porte.
+
+D'altra parte un client non ha necessità di usare un numero di porta
+specifico, per cui in genere vengono usate le cosiddette \textsl{porte
+ effimere} (o \textit{ephemeral ports}) cioè porte a cui non è assegnato
+nessun servizio noto e che vengono assegnate automaticamente dal kernel alla
+creazione della connessione. Queste sono dette effimere in quanto vengono
+usate solo per la durata della connessione, e l'unico requisito che deve
+essere soddisfatto è che ognuna di esse sia assegnata in maniera univoca.
+
+La lista delle porte conosciute è definita dall'RFC1700 che contiene l'elenco
+delle porte assegnate dalla IANA (\textit{Internet Assigned Number Authority})
+ma l'elenco viene costantemente aggiornato e pubblicato all'indirizzo
+\texttt{ftp://ftp.isi.edu/in-notes/iana/assignements/port-numbers}, inoltre il
+file \texttt{/etc/services} contiene un analogo elenco, con la corrispondenza
+fra i numeri di porta ed il nome simbolico del servizio. I numeri sono divisi
+in tre intervalli: