+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 nella
+programmazione di rete consideriamo cosa accade con una serie di esempi, 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 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 interfaccie 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{miltihoming}) 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 associerà 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, ma ha specificato l'indirizzo locale, e che corrisponde al socket
+con cui il processo figlio gestisce la connessione mentre il padre resta in
+ascolto.
+
+Se a questo lanciamo una seconda volta il client ssh per una seconda
+conessione quello che otterremo 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è al client sarà stata assegnata un'altra porta effimera e con questa sarà
+aperta la connessione, ed un nuovo processo figlio sarà creato per gestirla.
+
+
+Tutto ciò mostra come TCP, per poter gestire le due connessioni, 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.