+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 \secref{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 \texttt{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{enumerate}
+\item implementare in maniera affidabile la terminazione della connessione
+ in entrambe le direzioni.
+\item consentire l'eliminazione dei segmenti duplicati dalla rete.
+\end{enumerate}
+
+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 ricevendo 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 tempo (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 instradamento 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 \secref{sec:sock_sa_ipv4} e \secref{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:
+
+\begin{enumerate}
+\item \textsl{le porte conosciute}. I numeri da 0 a 1023. Queste sono
+ controllate e assegnate dalla IANA. Se è possibile la stessa porta è
+ assegnata allo stesso servizio sia su UDP che su TCP (ad esempio la porta 22
+ è 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ò 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 è implementato
+ solo su TCP. Ad esempio X Window usa le porte TCP e UDP dal 6000 al 6063
+ anche se il protocollo è 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à 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
+intervalli possibili viene fatta dinamicamente a seconda della memoria a
+disposizione del kernel per gestire le relative tabelle.
+
+\begin{figure}[!htb]
+ \centering
+ \includegraphics[width=10cm]{img/tcpip_overview.eps}
+ \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 è 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 i 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è 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é 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
+\secref{sec:TCPel_cunc_serv}) esamineremo cosa accade con le connessioni nel
+caso di un server TCP che deve gestire connessioni multiple.
+
+Se eseguiamo 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 è
+posto in ascolto per connessioni provenienti da uno qualunque degli indirizzi
+associati alle interfacce locali; la notazione 0.0.0.0 usata da netstat è
+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ò
+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ò chiedere che senso
+abbia l'utilizzo dell'indirizzo generico per l'indirizzo locale, ma esistono
+anche macchine che hanno più di un indirizzo IP (il cosiddetto
+\textit{multihoming}) in questo modo si possono accettare connessioni
+indirizzate verso uno qualunque di essi. Ma come si può vedere nell'esempio
+con il DNS in ascolto sulla porta 53 è anche possibile restringere l'accesso
+solo alle connessioni che provengono da uno specifico indirizzo, cosa che nel
+caso è fatta accettando solo connessioni che arrivino sull'interfaccia di
+loopback.
+
+Una volta che ci si vorrà collegare a questa macchina da un'altra posta
+all'indirizzo 192.84.146.100 si potrà lanciare un client \texttt{ssh} per
+creare una connessione verso la precedente, e il kernel assocerà al suddetto
+una porta effimera che per esempio potrà essere la 21100, la connessione
+allora sarà espressa dalla socket pair $(192.84.146.100:21100,
+195.110.112.152.22)$.
+
+Alla ricezione della richiesta dal client il server creerà 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ò notare il server è ancora in ascolto sulla porta 22, però adesso
+c'è un nuovo socket (con lo stato \texttt{ESTABLISHED}) che anch'esso utilizza
+la porta 22, ed ha specificato l'indirizzo locale, questo è 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
+connessione quello che otterremo usando netstat sarà 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è il client effettuerà la connessione usando un'altra porta effimera, con
+questa sarà aperta la connessione, ed il server creerà un'altro processo
+figlio sarà creato per gestirla.
+
+Tutto ciò mostra come TCP, per poter gestire le connessioni con un server
+concorrente, non può 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.