+Come riportato da Stevens (FIXME citare) lo stato \texttt{TIME\_WAIT} \81è
+probabilmente uno degli aspetti meno compresi del protocollo TCP, \81è 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 \81è che non deve essere fatto, ed il motivo cercheremo di
+spiegarlo adesso.
+
+Come si \81è visto nell'esempio precedente (vedi \curfig) \texttt{TIME\_WAIT} \81è
+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 \81è la stima del massimo periodo di tempo che un pacchetto IP pu\81ò vivere
+sulla rete; questo tempo \81è limitato perch\81é ogni pacchetto IP pu\81ò essere
+ritrasmesso dai router un numero massimo di volte (detto \textit{hop limit}).
+Il numero di ritrasmissioni consentito \81è 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 \81è ad 8 bit il numero massimo di ``salti'' \81è di 255, pertanto
+anche se il TTL (da \textit{time to live}) non \81è propriamente un limite sul
+tempo di vita, si stima che un pacchetto IP non possa restare nella rete per
+pi\81ù 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\81ò 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 \81è che entrambe le ragioni sono importanti, anche se spesso si fa
+riferimento solo alla prima; ma \81è solo se si tiene conto della seconda che si
+capisce il perch\81é della scelta di un tempo pari al doppio della MSL come
+durata di questo stato.
+
+Il primo dei due motivi precedenti si pu\81ò 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\81à 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\81ì 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 \81è pi\81ù 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\81ù comune in cui questo avviene \81è quello di anomalie
+nell'instradamento; pu\81ò accadere cio\81è 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\81è dei circoli (i
+cosiddetti \textit{routing loop}) in cui restano intrappolati i pacchetti.
+
+Se uno di questi pacchetti intrappolati \81è un segmento di TCP chi l'ha inviato,
+non ricevendo risposta, provveder\81à alla ritrasmissione e se nel frattempo sar\81à
+stata stabilita una strada alternativa il pacchetto ritrasmesso giunger\81à 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 \81è 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 \81è chiuso una nuova incarnazione non pu\81ò 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\81ù processi possono dover
+usare sia UDP che TCP, e ci devono poter essere pi\81ù 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\81ò
+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\81à di usare un numero di porta
+specifico, per cui in genere vengono usate le cosiddette \textsl{porte
+ effimere} (o \textit{ephemeral ports}) cio\81è porte a cui non \81è 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 \81è che ognuna di esse sia assegnata in maniera univoca.
+
+La lista delle porte conosciute \81è 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:
+
+\begin{enumerate}
+\item \textsl{le porte conosciute}. I numeri da 0 a 1023. Queste sono
+ controllate e assegnate dalla IANA. Se \81è possibile la stessa porta \81è
+ assegnata allo stesso servizio sia su UDP che su TCP (ad esempio la porta 22
+ \81è assegnata a ssh su entrambi i protocolli, anche se viene usata solo dal
+ TCP).
+
+\item \textsl{le porte registrate}. I numeri da 1024 a 49151. Queste porte non
+ sono controllate dalla IANA, che per\81ò registra ed elenca chi usa queste
+ porte come servizio agli utenti. Come per le precedenti si assegna una porta
+ ad un servizio sia per TCP che UDP anche se poi il servizio \81è implementato
+ solo su TCP. Ad esempio X Window usa le porte TCP e UDP dal 6000 al 6063
+ anche se il protocollo \81è implementato solo tramite TCP.
+
+\item \textsl{le porte private} o \textsl{dinamiche}. I numeri da 49152 a
+ 65535. La IANA non dice nulla riguardo a queste porte che pertanto
+ sono i candidati naturali ad essere usate come porte effimere.
+\end{enumerate}
+
+In realt\81à rispetto a quanto indicato nell'RFC1700 i vari sistemi hanno fatto
+scelte diverse per le porte effimere, in particolare in \nfig\ sono riportate
+quelle di BSD, Solaris e linux. Nel caso di linux poi la scelta fra i due
+intervali possibili viene fatta dinamicamente a seconda della memoria a
+disposizione del kernel per gestire le rative tabelle.
+
+\begin{figure}[!htb]
+ \centering
+
+ \caption{Allocazione dei numeri di porta}
+ \label{fig:TCPel_port_alloc}
+\end{figure}
+
+I sistemi unix hanno inoltre il concetto di \textsl{porte riservate} (che
+corrispondono alle porte con numero minore di 1024 e coincidono quindi con le
+porte conosciute). La loro caratteristica \81è che possono essere assegnate a un
+socket solo da un processo con i privilegi di root, per far si che solo
+l'amministratore possa allocare queste porte per far partire relativi servizi.
+
+Si tenga conto poi che ci sono alcuni client (in particolare \texttt{rsh} e
+\texttt{rlogin}) che richiedono una connessione su una porta riservata anche
+dal lato client come parte dell'autenticazione. Questo viene fatto tramite la
+funzione \texttt{rresvport} assegnando al socket una porta libera
+nell'intervallo fra 512 e 1023.
+
+Data una connessione TCP si suole chiamare \textit{socket pair} la
+combinazione dei quattro numeri che definiscono i due capi della connessione e
+cio\81è l'indirizzo IP locale e la porta TCP locale, e l'indirizzo IP remoto e la
+porta TCP remota; questa combinazione, che scriveremo usando una notazione del
+tipo $(195.110.112.152:22, 192.84.146.100:20100)$, identifica univocamente una
+connessione su internet. Questo concetto viene di solito esteso anche a UDP,
+bench\81é in questo caso non abbia senso parlare di connessione. L'utilizzo del
+programma \texttt{netstat} permette di visualizzare queste informazioni nei
+campi \textit{Local Address} e \textit{Foreing Address}.
+
+
+\subsection{Le porte ed il modello client/server}
+\label{sec:TCPel_port_cliserv}
+
+Per capire meglio l'uso delle porte e come vengono utilizzate quando si ha a
+che fare con un'applicazione client/server (come quella che scriveremo in
+\ref{sec:TCPel_echo_example}) esaminaremo cosa accade con le connessioni nel
+caso di un server TCP che deve gestire connessioni multiple.
+
+Se esguiamo un \texttt{netstat} su una macchina di prova (che supponiamo avere
+indirizzo 195.110.112.152) potremo avere un risultato del tipo:
+\begin{verbatim}
+Active Internet connections (servers and established)
+Proto Recv-Q Send-Q Local Address Foreign Address State
+tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
+tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN
+tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
+\end{verbatim}
+essendo presenti e attivi un server ssh, un server di posta e un DNS per il
+caching locale.
+
+Questo ci mostra ad esempio che il server ssh ha compiuto un'apertura passiva
+mettendosi in ascolto sulla porta 22 riservata a questo servizio e che si \81è
+posto in ascolto per connessioni provenienti da uno qualunque degli indirizzi
+associati alle interfaccie locali; la notazione 0.0.0.0 usata da netstat \81è
+equivalente all'asterisco utilizzato per il numero di porta ed indica il
+valore generico, e corrisponde al valore \texttt{INADDR\_ANY} definito in
+\texttt{arpa/inet.h}.
+
+Inoltre la porta e l'indirizzo di ogni eventuale connessione esterna non sono
+specificati; in questo caso la \textit{socket pair} associata al socket pu\81ò
+essere indicata come $(*:22, *.*)$, usando l'asterisco anche per gli indirizzi
+come carattere di \textit{wildchard}.
+
+In genere avendo le macchine associato un solo IP ci si pu\81ò chiedere che senso
+abbia l'utilizzo dell'indirizzo generico per l'indirizzo locale, ma esistono
+anche macchine che hanno pi\81ù di un indirizzo IP (il cosiddetto
+\textit{miltihoming}) in questo modo si possono accettare connessioni
+indirizzate verso uno qualunque di essi. Ma come si pu\81ò vedere nell'esempio
+con il DNS in ascolto sulla porta 53 \81è anche possibile restringere l'accesso
+solo alle connessioni che provengono da uno specifico indirizzo, cosa che nel
+caso \81è fatta accettando solo connessioni che arrivino sull'interfaccia di
+loopback.
+
+Una volta che ci si vorr\81à collegare a questa macchina da un'altra posta
+all'indirizzo 192.84.146.100 si potr\81à lanciare un client \texttt{ssh} per
+creare una connessione verso la precedente, e il kernel associer\81à al suddetto
+una porta effimera che per esempio potr\81à essere la 21100, la connessione
+allora sar\81à espressa dalla socket pair $(192.84.146.100:21100,
+195.110.112.152.22)$.
+
+Alla ricezione della richiesta dal client il server creer\81à un processo figlio
+per gestire la connessione, se a questo punto eseguiamo nuovamente il
+programma netstat otterremo come risultato:
+\begin{verbatim}
+Active Internet connections (servers and established)
+Proto Recv-Q Send-Q Local Address Foreign Address State
+tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
+tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN
+tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
+tcp 0 0 195.110.112.152:22 192.84.146.100:21100 ESTABLISHED
+\end{verbatim}
+
+Come si pu\81ò notare il server \81è ancora in ascolto sulla porta 22, per\81ò adesso
+c'\81è un nuovo socket (con lo stato \texttt{ESTABLISHED}) che anch'esso utilizza
+la porta 22, ed ha specificato l'indirizzo locale, questo \81è il socket con cui
+il processo figlio gestisce la connessione mentre il padre resta in ascolto
+sul socket originale.
+
+Se a questo punto lanciamo un'altra volta il client ssh per una seconda
+conessione quello che otterremo usando netstat sar\81à qualcosa del genere:
+\begin{verbatim}
+Active Internet connections (servers and established)
+Proto Recv-Q Send-Q Local Address Foreign Address State
+tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
+tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN
+tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
+tcp 0 0 195.110.112.152:22 192.84.146.100:21100 ESTABLISHED
+tcp 0 0 195.110.112.152:22 192.84.146.100:21101 ESTABLISHED
+\end{verbatim}
+cio\81è il client effettuer\81à la connessione usando un'altra porta effimera, con
+questa sar\81à aperta la connessione, ed il server creer\81à un'altro processo
+figlio sar\81à creato per gestirla.
+
+Tutto ci\81ò mostra come TCP, per poter gestire le connessioni con un server
+concorrente, non pu\81ò suddividere i pacchetti solo sulla base della porta di
+destinazione, ma deve usare tutta l'informazione contenuta nella socket pair,
+compresa la porta dell'indirizzo remoto. E se andassimo a vedere quali sono i
+processi a cui fanno riferimento i vari socket vedremmo che i pacchetti che
+arrivano dalla porta remota 21100 vanno al primo figlio e quelli che arrivano
+alla porta 21101 al secondo.