elemtcp.tex

   1 \chapter{Socket TCP elementari}
   2 \label{cha:elem_TCP_sock}
   3
   4 In questo capitolo inizieremo ad approndire la conoscenza dei socket TCP,
   5 tratteremo qui dunque il funzionamento delle varie funzioni che si sono usate
   6 nei due esempi elementari forniti in precedenza (vedi \ref{sec:net_cli_sample}
   7 e \ref{sec:net_serv_sample}), previa una descrizione delle principali
   8 caratteristiche del funzionamento di una connessione TCP.
   9
  10 La seconda parte del capitolo sarà poi dedicata ad una riscrittura
  11 dell'esempio precedente per trasformarlo in una prima applicazione
  12 client/server semplice, ma completa, che implementi il servizio standard
  13 \texttt{time} su TCP (vedremo in seguito un esempio anche con UDP).
  14
  15
  16 \section{Il funzionamento di una connessione TCP}
  17 \label{sec:TCPel_connession}
  18
  19 Prima di entrare nei dettagli di come si usano le varie funzioni dei socket
  20 che operano con TCP, è fondamentale capire alcune basi del funzionamento del
  21 protocollo, ed in particolare su come si stabilisce una connessione, come la
  22 si conclude e qual'è il significato dei vari stati del protocollo ad essa
  23 connessi.
  24
  25 La conoscenza del funzionamento del protocollo è infatti essenziale per capire
  26 il modello di programmazione ed il funzionamento delle API. In tutto questo è
  27 di grande aiuto il programma \texttt{netstat}, che useremo per mostrare lo
  28 stato in cui si trova ciascuna connessione attiva.
  29
  30 \subsection{La creazione della connessione: il \textit{three way handushake}}
  31 \label{sec:TCPel_conn_cre}
  32
  33 Lo scenario tipico che si verifica quando si deve stabilire una connessione
  34 TCP (lo stesso usato negli esempi elementari \ref{fig:net_cli_code} e
  35 \ref{fig:net_serv_code}) la successione degli eventi è la
  36 seguente:
  37
  38 \begin{itemize}
  39 \item Il server deve essere preparato per accettare le connessioni in arrivo;
  40   il procedimento si chiama \textsl{apertura passiva} del socket (da
  41   \textit{passive open}); questo viene fatto chiamando la sequenza di funzioni
  42   \texttt{socket}, \texttt{bind} e \texttt{listen}. Infine il server chiama la
  43   funzione \texttt{accept} e il processo si blocca in attesa di connessioni.
  44
  45 \item Il client richiede l'inizio della connessione usando la funzione
  46   \texttt{connect}, attraverso un procedimento che viene chiamato
  47   \textsl{apertura attiva}, dall'inglese \textit{active open}. La chiamata di
  48   \texttt{connect} blocca il processo e causa l'invio da parte del client di
  49   un segmento \texttt{SYN}\footnote{Si ricordi che il segmento è l'unità
  50     elementare di dati trasmessa dal protocollo TCP al livello superiore;
  51     tutti i segmenti hanno un header che contiene le informazioni che servono
  52     allo \textit{stack TCP} (così viene di solito chiamata la parte del kernel
  53     che implementa il protocollo) per realizzare la comunicazione, fra questi
  54     dati ci sono una serie di flag usati per gestire la connessione, come
  55     \texttt{SYN}, \texttt{ACK}, \texttt{URG}, \texttt{FIN}, alcuni di essi,
  56     come \texttt{SYN} (che sta per \textit{sincronize}) corrispondono a
  57     funzioni particolari del protocollo e danno il nome al segmento, (per
  58     maggiori dettagli vedere \ref{cha:tcp_protocol})}, in sostanza viene
  59   inviato al server un pacchetto IP che contiene solo gli header IP e TCP (con
  60   un numero di sequenza) e le opzioni di TCP.
  61
  62 \item il server deve dare ricevuto (l'\textit{acknowledge}) del \texttt{SYN}
  63   del client, inoltre anche il server deve inviare il suo \texttt{SYN} al
  64   client (e trasmettere il numero di sequenza iniziale) questo viene fatto
  65   ritrasmettendo un singolo segmento in cui entrambi i flag \texttt{SYN}
  66   \texttt{ACK} e sono settati.
  67
  68 \item una volta che il client ha ricevuto l'acknowledge dal server la funzione
  69   \texttt{connect} ritorna, l'ultimo passo è dare dare il ricevuto del
  70   \texttt{SYN} del server inviando un \texttt{ACK}. Alla ricezione di
  71   quest'ultimo la funzione \texttt{accept} del server ritorna e la connessione
  72   è stabilita.
  73 \end{itemize}
  74
  75 Dato che per compiere tutto questo procedimento devono essere scambiati tre
  76 pacchetti esso viene generalmente chiamato \textit{three way handshake}. In
  77 \nfig\ si è rappresentato graficamente lo sequenza di scambio dei segmenti che
  78 stabilisce la connessione.
  79
  80 % Una analogia citata da R. Stevens per la connessione TCP è quella con il
  81 % sistema del telefono. La funzione \texttt{socket} può essere considerata
  82 % l'equivalente di avere un telefono. La funzione \texttt{bind} è analoga al
  83 % dire alle altre persone qual'è il proprio numero di telefono perché possano
  84 % chiamare. La funzione \texttt{listen} è accendere il campanello del telefono
  85 % per sentire le chiamate in arrivo.  La funzione \texttt{connect} richiede di
  86 % conoscere il numero di chi si vuole chiamare. La funzione \texttt{accept} è
  87 % quando si risponde al telefono.
  88
  89 \begin{figure}[htb]
  90   \centering
  91
  92   \caption{Il \textit{three way handshake} del TCP}
  93   \label{fig:TCPel_TWH}
  94 \end{figure}
  95
  96 Si noti che figura si sono riportati anche i \textsl{numeri di sequenza}
  97 associati ai vari pacchetti; per gestire una connessione affidabile infatti il
  98 protocollo TCP prevede nell'header la presenza di un \textit{sequence number}
  99 a 32 bit che identifica a quale byte nella sequenza dello stream corrisponde
 100 il primo byte dei dati contenuti nel segmento.
 101
 102 Il numero di sequenza di ciascun segmento viene calcolato a partire da un
 103 numero di sequenza iniziale generato in maniera casuale del kernel all'inizio
 104 della connessione e trasmesso con il SYN; l'acknowledgement di ciascun
 105 segmento viene effettuato dall'altro capo della connessione settando il flag
 106 \texttt{ACK} e restituendo nell'apposito campo dell'header un
 107 \textit{acknowledge number}) pari al numero di sequenza che il ricevente si
 108 aspetta di ricevere con il pacchetto successivo; dato che il primo pacchetto
 109 SYN consuma un byte, nel \textit{three way handshake} il numero di acknowledge
 110 è sempre pari al numero di sequenza iniziale incrementato di uno; lo stesso
 111 varrà anche (vedi \nfig) per l'acknowledgement di un FIN.
 112
 113 \subsection{Le opzioni TCP.}
 114 \label{sec:TCPel_TCP_opt}
 115
 116 Ciascun SYN può contenere delle opzioni per il TCP (le cosiddette \textit{TCP
 117   options}, che vengono inserite fra l'header e i dati) che servono a regolare
 118 la connessione. Normalmente vengono usate le seguenti opzioni:
 119
 120 \begin{itemize}
 121 \item \textit{MSS option} Sta per \textit{maximum segment size}, con questa
 122   opzione ciascun capo della connessione annuncia all'altro il massimo
 123   ammontare di dati che vorrebbe accettare per ciascun segmento nella
 124   connesione corrente. È possibile leggere e scrivere questo valore attraverso
 125   l'opzione del socket \texttt{TCP\_MAXSEG}.
 126
 127 \item \textit{window scale option} come spiegato in \ref{cha:tcp_protocol} il
 128   protocollo TCP implementa il controllo di flusso attraverso una
 129   \textsl{finestra annunciata} (\textit{advertized window}) con la quale
 130   ciascun capo della comunicazione dichiara quanto spazio disponibile ha in
 131   memoria per i dati. Questo è un numero a 16 bit dell'haeader, che così può
 132   indicare un massimo di 65535 bytes; ma alcuni tipi di connessione come
 133   quelle ad alta velocità (sopra i 45Mbits/sec) e quelle che hanno grandi
 134   ritardi nel cammino dei pacchetti (come i satelliti) richiedono una finestra
 135   più grande per poter ottenere il massimo dalla trasmissione, per questo
 136   esiste questa opzione che indica un fattore di scala da applicare al valore
 137   della finestra annunciata\footnote{essendo una nuova opzione per garantire
 138     la compatibilità con delle vecchie implementazioni del protocollo la
 139     procedura che la attiva prevede come negoziazione che l'altro capo della
 140     connessione riconosca esplicitamente l'opzione inserendola anche lui nel
 141     suo SYN di risposta dell'apertura della connessione} per la connessione
 142   corrente (espresso come numero di bit cui shiftare a sinistra il valore
 143   della finestra annunciata).
 144
 145 \item \textit{timestamp option} è anche questa una nuova opzione necessaria
 146   per le connessioni ad alta velocità per evitare possibili corruzioni di dati
 147   dovute a pacchetti perduti che riappaiono; anche questa viene negoziata come
 148   la precedente.
 149
 150 \end{itemize}
 151
 152 La MSS è generalmente supportata da quasi tutte le implementazioni del
 153 protocollo, le ultime due opzioni (trattate nell'RFC 1323) sono meno comuni;
 154 vengono anche dette \textit{long fat pipe options} dato che questo è il nome
 155 che viene dato alle connessioni caratterizzate da alta velocità o da ritardi
 156 elevati.
 157
 158
 159 \subsection{La terminazione della connessione}
 160 \label{sec:TCPel_conn_term}
 161
 162 Mentre per creare una connessione occorre un interscambio di tre segmenti, la
 163 procedura di chiusura ne richede ben quattro; in questo caso la successione
 164 degli eventi è la seguente:
 165
 166 \begin{enumerate}
 167 \item Un processo ad uno dei due capi chiama la funzione \texttt{close}, dando
 168   l'avvio a quella che viene chiamata \textsl{chiusura attiva} (da
 169   \textit{active close}). Questo comporta l'emissione di un segmento FIN, che
 170   significa che si è finito con l'invio dei dati sulla connessione.
 171
 172 \item L'altro capo della connessione riceve il FIN ed esegue la
 173   \textit{chiusura passiva} (da \textit{passive close}); al FIN, come per
 174   tutti i pacchetti, viene risposto con un ACK. Inoltre il ricevimento del FIN
 175   viene passato al processo che ha aperto il socket come un end of file sulla
 176   lettura (dopo che ogni altro eventuale dato rimasto in coda è stato
 177   ricevuto), dato che il ricevimento di un FIN significa che non si
 178   riceveranno altri dati sulla connessione.
 179
 180 \item Dopo un certo tempo anche il secondo processo chiamerà la funzione
 181   \texttt{close} sul proprio socket, causando l'emissione di un altro segmento
 182   FIN.
 183
 184 \item L'altro capo della connessione riceverà il FIN conclusivo e risponderà
 185   con un ACK.
 186 \end{enumerate}
 187
 188
 189 Dato che in questo caso sono richiesti un FIN ed un ACK per ciascuna direzione
 190 normalmente i segmenti scambiati sono quattro; normalmente giacché in alcune
 191 sitazioni il FIN del passo 1) è inviato insieme a dei dati. Comunque non è
 192 detto, anche se è possibile, che i segmenti inviati nei passi 2 e 3, siano
 193 accorpati in un singolo segmento. In \nfig\ si è rappresentato graficamente lo
 194 sequenza di scambio dei segmenti che stabilisce la connessione.
 195
 196 \begin{figure}[htb]
 197   \centering
 198
 199   \caption{Il \textit{three way handshake} del TCP}
 200   \label{fig:TCPel_TWH}
 201 \end{figure}
 202
 203 Come per il SYN anche il FIN occupa un byte nel numero di sequenza, per cui
 204 l'ACK riporterà un \textit{acknowledge number} incrementato di uno.
 205
 206 Si noti che nella sequenza di chiusura fra i passi 2 e 3 è in teoria possibile
 207 che si mantenga un flusso di dati dal capo della connessione che sta eseguendo
 208 la chiusura passiva a quello che sta eseguendo la chiusura attiva. Nella
 209 sequenza indicata i dati verrebbero persi, dato che si è chiuso il socket, ma
 210 esistono situazione in cui si vuole che avvenga proprio questo, che è chiamato
 211 \texit{half-close}, per cui torneremo su questo aspetto e su come utilizzarlo
 212 più avanti, quando parleremo della funzione \texttt{shutdown}.
 213
 214 La emissione del FIN avviene quando il socket viene chiuso, questo però non
 215 avviene solo per la chiamata della funzione \texttt{close}, ma anche alla
 216 terminazione di un processo, il che vuol dire che se un processo viene
 217 terminato da un segnale tutte le connessioni aperte verranno chiuse.
 218
 219
 220 \subsection{Un esempio di connessione}
 221 \label{sec:TCPel_conn_dia}
 222
 223 Le operazioni del TCP nella creazione e conclusione di una connessione sono
 224 specificate attraverso il diagramma di transizione degli stati riportato in
 225 \nfig. TCP prevede l'esistenza di 11 diversi stati per una connessione ed un
 226 insieme di regole per le transizioni da uno stato all'altro basate sullo stato
 227 corrente e sul tipo di segmetno ricevuto.
 228
 229
 230
 231 \subsection{Lo stato \texttt{TIME\_WAIT}}
 232 \label{sec:TCPel_time_wait}
 233
 234
 235
 236 \section{I numeri di porta}
 237 \label{sec:TCPel_ports}
 238
 239 \section{Le funzioni dei socket TCP}
 240 \label{sec:TCPel_functions}
 241
 242 \subsection{La funzione \texttt{connect}}
 243 \label{sec:TCPel_func_connect}
 244
 245 \subsection{La funzione \texttt{bind}}
 246 \label{sec:TCPel_func_bind}
 247
 248 \subsection{La funzione \texttt{listen}}
 249 \label{sec:TCPel_func_listen}
 250
 251 \subsection{La funzione \texttt{accept}}
 252 \label{sec:TCPel_func_accept}
 253
 254
 255 \subsection{Le porte}
 256
 257
 258