esteso copyright al 2001
[gapil.git] / network.tex
1 \chapter{Introduzione alla programmazione di rete}
2 \label{cha:network}
3
4 In questo capitolo sarà fatta un'introduzione ai contetti generali che servono
5 come prerequisiti per capire la programmazione di rete, per evitare un
6 capitolo puramente teorico partiremo con due semplici esempi per poi passare
7 ad un esame a grandi linee dei protocolli di rete e di come questi sono
8 organizzati e interagiscono.
9
10 In particolare, avendo assunto l'ottica di un'introduzione mirata alla
11 programmazione, ci concentreremo sul protocollo più diffuso, il TCP/IP, che è
12 quello che sta alla base di internet, con un'ottica improntata a sottolineare
13 i concetti più importanti da conoscere ai fini della programmazione.
14
15 \section{Il modello client-server}
16 \label{sec:net_cliserv}
17
18 La differenza principale fra un'applicazione di rete e un programma normale è
19 che quest'ultima per definizione concerne la comunicazione fra ``processi''
20 diversi (che in generale non girano neanche sulla stessa macchina). Questo già
21 prefigura un cambiamento completo rispetto all'ottica del ``programma''
22 monolitico all'interno del quale vengono eseguite tutte le istruzioni, e
23 presuppone un sistema operativo ``multitasking'' in grado di eseguire processi
24 diversi.
25
26 Il concetto fondamentale si basa la programmazione di rete sotto Linux (e
27 sotto Unix in generale) è il modello \textit{client-server} in cui un
28 programma di servizio, il \textit{server} riceve un connessione e risponde a
29 un programma di utilizzo, il \textit{client}, provvedendo a quest'ultimo un
30 definito insieme di servizi.
31
32 Esempi di questo modello sono il WEB, ftp, telnet, ssh e praticamente ogni
33 servizio che viene fornito tramite la rete, ma il modello è utilizzato in
34 generale anche per programmi che non fanno necessariamente uso della rete,
35 come il sistema a finestre.
36
37 Normalmente si dividono i server in due categorie principali, e vengono detti
38 \textsl{concorrenti} o \textsl{iterativi}, sulla base del loro comportamento.
39
40 Un \textsl{server iterativo} risponde alla richiesta inviando i dati e resta
41 occupato (non rispondendo ad ulteriori richieste) fintanto che non ha concluso
42 la richiesta. Una volta completata la richiesta il server diventa di nuovo
43 disponibile.
44
45 Un \textsl{server concorrente} al momento di trattare la richiesta crea un
46 processo figlio incaricato di fornire i servizi richiesti, per poi porsi in
47 attesa di ulteriori richieste. In questo modo più richieste possono essere
48 soddisfatte contemporaneamente; una volta che il processo figlio ha concluso
49 il suo lavoro viene terminato, mentre il server originale resta sempre attivo.
50
51
52 \subsection{Un primo esempio di client}
53 \label{sec:net_cli_sample}
54
55 Per evitare di rendere l'esposizione dei concetti generali sulla rete
56 puramente teorica iniziamo con il mostrare un esempio di un client TCP
57 elementare.  Scopo di questo esempio è fornire un primo approccio alla
58 programmazione di rete, tutto questo sarà esaminato in dettaglio nei capitoli
59 successivo; qui ci limiteremo a introdurre la nomenclatura senza fornire
60 definizioni precise e dettagli di funzionamento che saranno trattati
61 estensivamente più avanti.
62
63 In \nfig\ è riportata la sezione principale del codice del nostro client
64 elementare per il servizio \textit{daytime}, un servizio standard che
65 restituisce l'ora locale della macchina a cui si effettua la richesta.
66
67
68 \begin{figure}[!htb]
69   \footnotesize
70   \begin{lstlisting}{}
71 #include <sys/types.h>   /* predefined types */
72 #include <unistd.h>      /* include unix standard library */
73 #include <arpa/inet.h>   /* IP addresses conversion utiliites */
74 #include <sys/socket.h>  /* socket library */
75 #include <stdio.h>       /* include standard I/O library */
76
77 int main(int argc, char *argv[])
78 {
79     int sock_fd;
80     int i, nread;
81     struct sockaddr_in serv_add;
82     char buffer[MAXLINE];
83      ...
84     /* create socket */
85     if ( (sock_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
86         perror("Socket creation error");
87         return -1;
88     }
89     /* initialize address */
90     memset((void *) &serv_add, 0, sizeof(serv_add)); /* clear server address */
91     serv_add.sin_family = AF_INET;                   /* address type is INET */
92     serv_add.sin_port = htons(13);                   /* daytime post is 13 */
93     /* build address using inet_pton */
94     if ( (inet_pton(AF_INET, argv[optind], &serv_add.sin_addr)) <= 0) {
95         perror("Address creation error");
96         return -1;
97     }
98     /* extablish connection */
99     if (connect(sock_fd, (struct sockaddr *)&serv_add, sizeof(serv_add)) < 0) {
100         perror("Connection error");
101         return -1;
102     }
103     /* read daytime from server */
104     while ( (nread = read(sock_fd, buffer, MAXLINE)) > 0) {
105         buffer[nread]=0;
106         if (fputs(buffer, stdout) == EOF) {          /* write daytime */
107             perror("fputs error");
108             return -1;
109         }
110     }
111     /* error on read */
112     if (nread < 0) {
113         perror("Read error");
114         return -1;
115     }
116     /* normal exit */
117     return 0;
118 }
119   \end{lstlisting}
120   \caption{Esempio di codice di un client elementare per il servizio daytime.}
121   \label{fig:net_cli_code}
122 \end{figure}
123
124 Il sorgente completo del programma (\texttt{SimpleDaytimeTCPClient.c}, che
125 comprende il trattamento delle opzioni e una funzione per stampare un
126 messaggio di aiuto) è allegato alla guida nella sezione dei codici sorgente e
127 può essere compilato su una qualunque macchina linux.
128
129 Il programma anzitutto include gli header necessari (\texttt{\small 1--5});
130 dopo la dichiarazione delle variabili (\texttt{\small 9--12}) si è omessa
131 tutta la parte relativa al trattamento degli argomenti passati dalla linea di
132 comando (effettuata con le apposite routines illustrate in
133 \capref{cha:parameter_options}).
134
135 Il primo passo (\texttt{\small 14--18}) è creare un \textit{socket} IPv4
136 (\texttt{AF\_INET}), di tipo TCP \texttt{SOCK\_STREAM} (in sostanza un canale
137 di comunicazione attraverso internet, questi termini verranno spiegati con
138 precisione più avanti). La funzione \texttt{socket} ritorna un descrittore,
139 analogo a quello dei file, che viene usato per identificare il socket in tutte
140 le chiamate successive. Nel caso la chiamata fallisca si stampa un errore con
141 la relativa routine e si esce.
142
143 Il passo seguente (\texttt{\small 19--27}) è quello di costruire una apposita
144 struttura \texttt{sockaddr\_in} in cui sarà inserito l'indirizzo del server ed
145 il numero della porta del servizio. Il primo passo è inizializzare tutto a
146 zero, per poi inserire il tipo di protocollo e la porta (usando per
147 quest'ultima la funzione \texttt{htons} per convertire il formato dell'intero
148 usato dal computer a quello usato nella rete), infine si utilizza la funzione
149 \texttt{inet\_pton} per convertire l'indirizzo numerico passato dalla linea di
150 comando.
151
152 Usando la funzione \texttt{connect} sul socket creato in precedenza
153 (\texttt{\small 28--32}) si provvede poi a stabilire la connessione con il
154 server specificato dall'indirizzo immesso nella struttura possata come secondo
155 argomento, il terzo argomento è la dimensione di detta struttura. Dato che
156 esistono diversi tipi di socket, si è dovuto effettuare un cast della
157 struttura inizializzata in precedenza, che è specifica per i socket IPv4.  Un
158 valore di ritorno negativo implica il fallimento della connessione.
159
160 Completata con successo la connessione il passo successivo (\texttt{\small
161   34--40}) è leggere la data dal socket; il server invierà sempre una stringa
162 di 26 caratteri della forma \verb|Wed Apr 4 00:53:00 2001\r\n|, che viene
163 letta dalla funzione \texttt{read} e scritta su \texttt{stdout}.
164
165 Dato il funzionamento di TCP la risposta potrà tornare in un unico pacchetto
166 di 26 byte (come avverrà senz'altro nel caso in questione) ma potrebbe anche
167 arrivare in 26 pacchetti di un byte.  Per questo nel caso generale non si può
168 mai assumere che tutti i dati arrivino con una singola lettura, pertanto
169 quest'ultima deve essere effettuata in un loop in cui si continui a leggere
170 fintanto che la funzione \texttt{read} non ritorni uno zero (che significa che
171 l'altro capo ha chiuso la connessione) o un numero minore di zero (che
172 significa un errore nella connessione).
173
174 Si noti come in questo caso la fine dei dati sia specificata dal server che
175 chiude la connessione; questa è una delle tecniche possibili (è quella usata
176 pure dal protocollo HTTP), ma ce ne possono essere altre, ad esempio FTP marca
177 la conclusione di un blocco di dati con la sequenza ASCII \verb|\r\n|
178 (carriage return e line feed), mentre il DNS mette la lunghezza in testa ad
179 ogni blocco che trasmette. Il punto essenziale è che TCP non provvede nessuna
180 indicazione che permetta di marcare dei blocchi di dati, per cui se questo è
181 necessario deve provvedere il programma stesso.
182
183 \subsection{Un primo esempio di server}
184 \label{sec:net_serv_sample}
185
186 Dopo aver illustrato il client daremo anche un esempio di un server
187 elementare, in grado di rispondere al precedente client. Il listato è
188 nuovamente mostrato in \nfig, il sorgente completo
189 (\texttt{SimpleDaytimeTCPServer.c}) è allegato insieme agli altri file nella
190 directory \texttt{sources}.
191
192 \begin{figure}[!htbp]
193   \footnotesize
194   \begin{lstlisting}{}
195 #include <sys/types.h>   /* predefined types */
196 #include <unistd.h>      /* include unix standard library */
197 #include <arpa/inet.h>   /* IP addresses conversion utiliites */
198 #include <sys/socket.h>  /* socket library */
199 #include <stdio.h>       /* include standard I/O library */
200 #include <time.h>
201 #define MAXLINE 80
202 #define BACKLOG 10
203 int main(int argc, char *argv[])
204 {
205 /* 
206  * Variables definition  
207  */
208     int list_fd, conn_fd;
209     int i;
210     struct sockaddr_in serv_add;
211     char buffer[MAXLINE];
212     time_t timeval;
213     ...
214     /* create socket */
215     if ( (list_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
216         perror("Socket creation error");
217         exit(-1);
218     }
219     /* initialize address */
220     memset((void *)&serv_add, 0, sizeof(serv_add)); /* clear server address */
221     serv_add.sin_family = AF_INET;                  /* address type is INET */
222     serv_add.sin_port = htons(13);                  /* daytime port is 13 */
223     serv_add.sin_addr.s_addr = htonl(INADDR_ANY);   /* connect from anywhere */
224     /* bind socket */
225     if (bind(list_fd, (struct sockaddr *)&serv_add, sizeof(serv_add)) < 0) {
226         perror("bind error");
227         exit(-1);
228     }
229     /* listen on socket */
230     if (listen(list_fd, BACKLOG) < 0 ) {
231         perror("listen error");
232         exit(-1);
233     }
234     /* write daytime to client */
235     while (1) {
236         if ( (conn_fd = accept(list_fd, (struct sockaddr *) NULL, NULL)) <0 ) {
237             perror("accept error");
238             exit(-1);
239         }
240         timeval = time(NULL);
241         snprintf(buffer, sizeof(buffer), "%.24s\r\n", ctime(&timeval));
242         if ( (write(conn_fd, buffer, strlen(buffer))) < 0 ) {
243             perror("write error");
244             exit(-1);
245         }
246         close(conn_fd);
247     }
248     /* normal exit */
249     exit(0);
250 }
251   \end{lstlisting}
252   \caption{Esempio di codice di un semplice server per il servizio daytime.}
253   \label{fig:net_serv_code}
254 \end{figure}
255
256 Come per il client si includono gli header necessari a cui è aggiunto quello
257 per trattare i tempi, e si definiscono alcune costanti e le variabili
258 necessarie in seguito (\texttt{\small 1--18}), come nel caso precedente si
259 sono omesse le parti relative al trattamento delle opzioni da riga di comando.
260
261 La creazione del socket (\texttt{\small 22--26}) è analoga al caso precedente,
262 come pure l'inizializzazione della struttura \texttt{sockaddr\_in}, anche in
263 questo caso si usa la porta standard del servizio daytime, ma come indirizzo
264 IP si il valore predefinito \texttt{INET\_ANY} che corrisponde ad un indirizzo
265 generico (\texttt{\small 27--31}).
266
267 Si effettua poi (\texttt{\small 32--36}) la chiamata alla funzione
268 \texttt{bind} che permette di associare la precedente struttura al socket, in
269 modo che quest'ultimo possa essere usato per accettare connessioni su una
270 qualunque delle interfacce di rete locali.
271
272 Il passo successivo (\texttt{\small 37--41}) è mettere ``in ascolto'' il
273 socket, questo viene effettuato con la funzione \texttt{listen} che dice al
274 kernel di accettare connessioni per il socket specificato, la funzione indica
275 inoltre, con il secondo parametro, il numero massimo di connessioni che il
276 kernel accetterà di mettere in coda per il suddetto socket.
277
278 Questa ultima chiamata completa la preparazione del socket per l'ascolto (che
279 viene chiamato anche \textit{listening descriptor}) a questo punto il processo
280 è mandato in sleep (\texttt{\small 44--47}) con la successiva chiamata alla
281 funzione \texttt{accept}, fin quando non arriva e viene accettata una
282 connessione da un client.
283
284 Quando questo avviene \texttt{accept} ritorna un secondo descrittore di
285 socket, che viene chiamato \textit{connected descriptor} che è quello che
286 viene usato dalla successiva chiamata alla \texttt{write} per scrivere la
287 risposta al client, una volta che si è opportunamente (\texttt{\small 48--49})
288 costruita la stringa con la data da trasmettere. Completata la trasmissione il
289 nuovo socket viene chiuso (\texttt{\small 54}).
290 Il tutto è inserito in un loop infinito (\texttt{\small 42--55}) in modo da
291 poter ripetere l'invio della data ad una successiva connessione.
292
293 È impostante notare che questo server è estremamente elementare, infatti a
294 parte il fatto di essere dipendente da IPv4, esso è in grado di servire solo
295 un client alla volta, è cioè un \textsl{server iterativo}, inoltre esso è
296 scritto per essere lanciato da linea di comando, se lo si volesse utilizzare
297 come demone di sistema (che è in esecuzione anche quando non c'è nessuna shell
298 attiva e il terminale da cui lo si è lanciato è stato sconnesso),
299 occorrerebbero delle opportune modifiche.
300
301 \section{I protocolli di rete}
302 \label{sec:net_protocols}
303
304 Visto un primo esempio di programmazione, passiamo ora ad una introduzione più
305 dettagliata del funzionamento delle reti e dei relativi protocolli.
306
307 Parlando di reti di computer si parla in genere di un insieme molto vasto ed
308 eterogeneo di mezzi di comunicazione che vanno dal cavo telefonico, alla fibra
309 ottica, alle comunicazioni via satellite; per rendere possibile la
310 comunicazione attraverso un così variegato insieme di mezzi sono stati
311 adottati una serie di protocolli, il più famoso dei quali, quello alla base
312 del funzionamento di internet, è il protocollo TCP/IP.
313
314 \subsection{Il modello ISO/OSI}
315 \label{sec:net_iso_osi}
316
317 Una caratteristica comune dei protocolli di rete è il loro essere strutturati
318 in livelli sovrapposti; in questo modo un livello superiore esegue richieste
319 al livello sottostante e da questo riceve responsi, mentre livelli uguali su
320 macchine diverse conversano tramite lo stesso protocollo. Questo modello di
321 funzionamento è stato stato standardizzato dalla \textit{International
322   Standards Organization} (ISO) che ha preparato fin dal 1984 il Modello di
323 Riferimento \textit{Open Systems Interconnection} (OSI), strutturato in sette
324 livelli, secondo quanto riportato in \ntab.
325
326 \begin{table}[htb]
327   \centering
328   \begin{tabular}{l c c l} 
329     \textbf{Livello} & \multicolumn{2}{c}{\textbf{Nome}} & \\
330     \hline
331     Livello 7&\textit{Application} &\textsl{Applicazione}& \\ 
332     Livello 6&\textit{Presentation} &\textsl{Presentazione}& \\ 
333     Livello 5&\textit{Session} &\textsl{Sessione}& \\ 
334     Livello 4&\textit{Transport} &\textsl{Trasporto}& \\ 
335     Livello 3&\textit{Network} &\textsl{Rete}&   \\ 
336     Livello 2&\textit{DataLink} &\textsl{Collegamento Dati}& \\
337     Livello 1&\textit{Connection} &\textsl{Connessione Fisica}& \\
338     \hline
339 \end{tabular}
340 \caption{I sette livelli del protocollo ISO/OSI.}
341 \label{tab:net_osilayers}
342 \end{table}
343
344 Il modello ISO/OSI è stato sviluppato corrispondentemente alla definizione
345 della serie di protocolli X.25 per la commutazione di pacchetto. Ma nonostante
346 il lavoro dettagliato di standardizzazione il modello si è rivelato
347 sostanzialmente troppo complesso e poco flessibile rispetto a quello,
348 precedente, su cui si basa TCP/IP che è diventato uno standard de facto;
349 quest'ultimo viene comunemente chiamato modello DoD (\textit{Department of
350   Defense}), dato che fu sviluppato dall'agenzia ARPA per il Dipartimento
351 della Difesa Americano.
352
353
354 \begin{figure}[!htbp]
355   \centering
356   
357   \caption{Struttura a livelli dei protocolli OSi e TCP/IP, con la  
358     relative corrispondeze e la divisione fra kernel e user space.}
359   \label{fig:net_osi_tcpip_comp}
360 \end{figure}
361
362
363
364 \subsection{Il modello DoD (TCP/IP)}
365 \label{sec:net_tcpip_overview}
366
367 Così come ISO/OSI anche TCP/IP è stato strutturato in livelli (riassunti in
368 \ntab); un confronto fra i due è riportato in \curfig\ dove viene evidenziata
369 anche la corrispondenza fra i rispettivi livelli (che comunque è
370 approssimativa) e su come essi vanno ad inserirsi all'interno del sistema
371 operativo rispetto alla divisione fra user space e kernel space spiegata in
372 \secref{sec:intro_unix_struct}.
373
374 \begin{table}[htb]
375   \centering
376   \begin{tabular}{l c c l} 
377     \textbf{Livello} & \multicolumn{2}{c}{\textbf{Nome}} & \textbf{Esempi} \\
378     \hline
379     Livello 1&\textit{Application} &\textsl{Applicazione}& 
380     Telnet, FTP, etc. \\ 
381     Livello 2&\textit{Transport} &\textsl{Trasporto}& TCP, UDP \\ 
382     Livello 3&\textit{Network} &\textsl{Rete}& IP, (ICMP, IGMP)  \\ 
383     Livello 4&\textit{Link} &\textsl{Connessione}& 
384     device driver \& scheda di interfaccia  \\
385     \hline
386 \end{tabular}
387 \caption{I quattro livelli del protocollo TPC/IP.}
388 \label{tab:net_layers}
389 \end{table}
390
391
392 Come si può notare TCP/IP è più semplice del modello ISO/OSI e strutturato in
393 soli quattro livelli. Il suo nome deriva dai due principali protocolli che lo
394 compongono, il TCP \textit{Trasmission Control Protocol} e l'IP
395 \textit{Internet Protocol}. Le funzioni dei vari livelli sono le seguenti:
396
397 \begin{description}
398 \item \textbf{Applicazione} É relativo ai programmi di interfaccia utente, in
399   genere questi vengono realizzati secondo il modello Client-Server (vedi
400   \secref{sec:net_cliserv}.
401 \item \textbf{Trasporto} Fornisce la comunicazione tra le due stazioni
402   terminali su cui girano gli applicativi, regola il flusso delle
403   informazioni, e può fornire un trasporto affidabile, cioè con recupero
404   errori. Il protocollo principale di questo livello è il TCP.
405 \item \textbf{Rete} Si occupa dello smistamento dei singoli pacchetti su una
406   rete complessa e interconnessa, a questo stesso livello operano i protocolli
407   per il reperimento delle informazioni necessarie allo smistamento, per lo
408   scambio di messaggi di controllo e per il monitoraggio della rete. Il
409   protocollo su cui si basa questo livello è IP (sia nella attuale versione,
410   IPv4 che nella nuova IPv6).
411 \item \textbf{Connessione} È responsabile per l'interfacciamento al
412   dispositivo elettronico che effettua la comunicazione fisica, gestendo
413   l'invio e la ricezione dall'hardware dei pacchetti.
414 \end{description}
415
416
417 La comunicazione fra due stazioni avviene pertanto secondo le modalità
418 illustrate in \nfig. 
419
420
421 \begin{figure}[!htbp]
422   \centering
423   
424   \caption{Strutturazione del flusso dei dati nella comunicazione fra due
425     applicazioni attraverso i protocolli della suite TCP/IP.}
426   \label{fig:net_tcpip_data_flux}
427 \end{figure}
428
429 Le singole applicazioni si scambieranno i dati secondo un loro formato
430 specifico, implementando un protocollo di applicazione (esempi possono essere
431 HTTP, POP, telnet, SMTP, etc). 
432
433 Questi dati vengono inviati al livello di trasporto usando un'interfaccia
434 opportuna (i \textit{socket}, che esamineremo in dettaglio in seguito), i
435 quali li spezzerà in pacchetti di dimensione opportuna e li incapsulerà
436 all'interno del suo protocollo di trasporto aggiungendo ad ogni pacchetto le
437 informazioni necessarie alla gestione di quest'ultimo. Questo processo viene
438 svolto dirattamente nel kernel ad esempio dallo stack TCP nel caso il
439 protocollo di trasporto sia questo.
440
441 Una volta composto il pacchetto nel formato adatto al protocollo di trasporto
442 usato questo sarà passato al successivo livello, quello del collegamento che
443 si occupa di inserire le opportune informazioni per poter effettuare
444 l'instradamento nella rete ed il recapito alla destinazione finale. In genere
445 questo è il livello di IP (Internet Protocol), a cui vengono inseriti i numeri
446 IP che identificano i computer su internet.
447
448 L'ultimo passo è il trasferimento del pacchetto al driver della interfaccia di
449 trasmissione che si incarica di incapsularlo nel relativo protocollo di
450 trasmissione fisica usato dall'hardware usato per la comunicazione (ad esempio
451 ethernet per una scheda di rete).
452
453
454 \subsection{Criteri generali del design di TCP/IP}
455 \label{sec:net_tcpip_design}
456
457 La filosofia architetturale di TCP/IP è semplice: costruire una rete che
458 possa sopportare il carico in transito, ma permettere ai singoli nodi di
459 scartare pacchetti se il carico è temporaneamente eccessivo, o se risultano
460 errati o non recapitabili.
461
462 L'incarico di rendere il recapito pacchetti affidabile non spetta allo livello
463 di collegamento, ma ai livelli superiori. Pertanto il protocollo IP è per sua
464 natura inaffidabile, in quanto non è assicurata né una percentuale di
465 successo né un limite sui tempi di consegna dei pacchetti.
466
467 È il livello di trasporto che si deve occupare (qualora necessiti) del
468 controllo del flusso dei dati e del recupero degli errori; questo è realizzato
469 dal protocollo TCP. La sede principale di "intelligenza" della rete è pertanto
470 al livello di trasporto o superiore.
471
472 Infine le singole stazioni collegate alla rete non fungono soltanto da punti
473 terminali di comunicazione, ma possono anche assumere il ruolo di router, per
474 l'interscambio di pacchetti da una rete ad un'altra. Questo rende possibile la
475 flessibilità della rete che è in grado di adattarsi ai mutamenti delle
476 interconnessioni.
477
478 La caratteristica essenziale che rende tutto ciò possibile è la strutturazione
479 a livelli tramite l'incapsulamento. Ogni pacchetto di dati viene incapsulato
480 nel formato del livello successivo, fino al livello della connessione fisica.
481 In questo modo il pacchetto ricevuto ad un livello $n$ dalla stazione di
482 destinazione è esattamente lo stesso spedito dal livello $n$ dalla sorgente.
483 Questo rende facile il progettare il software facendo riferimento unicamente a
484 quanto necessario ad un singolo livello, con la confidenza che questo poi sarà
485 trattato uniformemente da tutti i nodi della rete.
486
487
488 \section{Il protocollo TCP/IP}
489 \label{sec:net_tpcip}
490
491 Come appena mostrato il protocollo TCP/IP è un insieme di protocolli diversi,
492 che operano su 4 livelli diversi. Per gli interessi della programmazione di
493 rete però sono importanti principalmente i due livelli centrali, e soprattutto
494 quello di trasporto. 
495
496 La principale interfaccia di programmazione di rete, quella dei socket, è
497 infatti un'interfaccia nei confronti di quest'ultimo. Questo avviene perché al
498 di sopra del livello di trasporto i programmi hanno a che fare solo con
499 dettagli specifici delle applicazioni, mentre al di sotto vengono curati tutti
500 i dettagli relativi alla comunicazione. È pertanto naturale definire una API
501 su questo confine tanto più che è proprio li (come evidenziato in \pfig) che
502 nei sistemi unix (e non solo) viene inserita la divisione fra kernel space e
503 user space.
504
505 In realtà in un sistema unix è possibile accedere anche agli altri livelli
506 inferiori (e non solo a quello di trasporto) con opportune interfacce (la cosa
507 è indicata in \pfig\ lasciando uno spazio fra UDP e TCP), ma queste vengono
508 usate solo quando si vogliono fare applicazioni di sistema per il controllo
509 della rete a basso livello, un uso quindi molto specialistico, e che non
510 rientra in quanto trattato qui.
511
512 In questa sezione daremo una breve descrizione dei vari protocolli di TCP/IP,
513 concentrandoci per le ragioni esposte sul livello di trasposto. All'interno di
514 questo privilegeremo poi il protocollo TCP, per il ruolo centrale che svolge
515 nella maggior parte delle applicazioni.
516
517 \subsection{Il quadro generale}
518
519 Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da
520 altri membri. In \nfig\ si è riportato uno schema che mostra un panorama sui
521 vari prottocolli della famiglia, e delle loro relazioni reciproche e con
522 alcune dalle principali applicazioni che li usano.
523
524 \begin{figure}[!htbp]
525   \centering
526   
527   \caption{Panoramica sui vari protocolli che compongono la suite TCP/IP.}
528   \label{fig:net_tcpip_overview}
529 \end{figure}
530
531 I vari protocolli mostrati in figura sono i seguenti:
532
533 \begin{list}{}{}
534 \item \textsl{IPv4} \textit{Internet Protocol version 4}. È quello che
535   comunemente si chiama IP. Ha origine negli anni '80 e da allora è la base su
536   cui è cotriuta internet. Usa indirizzi a 32 bit e provvede la trasmissione
537   dei pacchetti TCP, UDP, ICMP e IGMP.
538 \item \textsl{IPv6} \textit{Internet Protocol version 6}. È stato progettato a
539   metà degli anni '90 per rimpiazzare IPv4. Ha indirizzi a 128 bit e effettua
540   lo stesso servizio di trasporto di IPv4 per i pacchetti TCP, UDP e ICPMv6.
541 \item \textsl{TCP} \textit{Trasmission Control Protocol}. È un protocollo
542   orientato alla connessione che provvede un trasporto affidabile e
543   bidirezionale di un flusso di dati. I socket TCP sono esempi di
544   \textit{stream socket}. Il protocollo ha cura di tutti gli aspetti del
545   trasporto, come l'acknoweledgment, i timeout, la ritrasmissione, etc. È 
546   usato dalla maggior parte delle applicazioni. Può essere usato sia con IPv4
547   che con IPv6.
548 \item \textsl{UDP} \textit{User Datagram Protocol}. È un protocollo senza
549   connessione a pacchetti. I socket UDP sono esempi di \textit{datagram
550     socket}. Contrariamente al TCP in protocollo non è affidabile e non c'è
551   garanzia che i pacchetti raggiungano la loro destinazione, né sull'eventuale
552   ordine di arrivo. Può essere usato sia con IPv4 che con IPv6.
553 \item \textsl{ICMP} \textit{Internet Control Message Protocol}. Gestisce gli
554   errori e trasporta l'informazione di controllo fra stazioni remote e
555   instradatori (\textit{host} e \textit{router}). I messaggi sono normalmente
556   generati dal software del kernel che gestisce la comunicazione TCP/IP, anche
557   se ICMP può venire usato direttamente da alcuni programmi come
558   \texttt{ping}. A volte ci si riferisce ad esso come ICPMv4 per distinguerlo
559   da ICMPv6.
560 \item \textsl{ICMP} \textit{Internet Group Management Protocol}. É un
561   protocollo usato per il \textit{multicasting} (vedi
562   \secref{sec:xxx_multicast}), che è opzionale in IPv4.
563 \item \textsl{ARP} \textit{Address Resolution Protocol}. È il protocollo che
564   mappa un indirizzo IP in un indirizzo hardware (come un indirizzo
565   internet). È usato in reti di tipo broadcast come ethernet, token ring o
566   FDDI ma non serve in connessioni punto-punto.
567 \item \textsl{RARP} \textit{Reverse Address Resolution Protocol}. È il
568   protocollo che mappa un indirizzo hardware in un indirizzo IP. Viene usato a
569   volte per durante il boot per assegnare un indirizzo IP ad una macchina.
570 \item \textsl{ICMPv6} \textit{Internet Control Message Protocol, version 6}.
571   Combina per IPv6 le funzionalità di ICMPv4, IGMP e ARP.
572 \item \textsl{NETLINK} \textit{Netlink}.
573   Provvede l'interfaccia di accesso alla comunicazione a basso livello.
574 \end{list}
575
576 Gran parte delle applicazioni comunicano usando TCP o UDP, ed alcune si
577 rifanno ad IP (ed i suoi correlati ICMP e IGMP); benché sia TCP che UDP siano
578 basati su IP e sia possibile intervenire a questo livello con i \textit{raw
579   socket} questa tecnica è molto meno diffusa e a parte applicazioni
580 particolari si preferisce sempre usare i servizi messi a disposizione dai due
581 protocolli precedenti.  Per questo motivo a parte alcuni brevi accenni su IP
582 in questa sezione ci concentreremo sul livello di trasporto.
583
584 \subsection{Internet Protocol (IP)}
585 \label{sec:net_ip}
586
587 Quando si parla di IP ci si riferisce in genere alla versione attualmente in
588 uso che è la versione 4 (e viene pertanto chiamato IPv4). Questa versione
589 venne standardizzata nel 1981 dall'RFC~719.
590
591 Internet Protocol nasce per disaccoppiare le applicazioni della struttura
592 hardware delle reti di trasmissione, e creare una interfaccia di trasmissione
593 dei dati indipendente dal sottostante substrato di rete, che può essere
594 realizzato con le tecnologie più disparate (Ethernet, Token Ring, FDDI, etc.).
595 Il compito di IP è pertanto quello di trasmettere i pacchetti da un computer
596 all'altro della rete; le caratteristiche essenziali con cui questo viene
597 realizzato in IPv4 sono due:
598
599 \begin{itemize}
600 \item \textit{Universal addressing} la comunicazione avviene fra due host
601   identificati univocamente con un indirizzo a 32 bit che può appartenere ad
602   una sola interfaccia di rete.
603 \item \textit{Best effort} viene assicurato il massimo impegno nella
604   trasmissione, ma non c'è nessuna garanzia per i livelli superiori né sulla
605   percentuale di successo né sul tempo di consegna dei pacchetti di dati.
606 \end{itemize}
607
608 Negli anni '90 la crescita vertiginosa del numero di macchine connesse a
609 internet ha iniziato a far emergere i vari limiti di IPv4, per risolverne i
610 problemi si è perciò definita una nuova versione del protocollo, che (saltando
611 un numero) è diventata la versione 6. IPv6 nasce quindi come evoluzione di
612 IPv4, mantendone inalterate le funzioni che si sono dimostrate valide,
613 eliminando quelle inutili e aggiungendone poche altre per mantenere il
614 protocollo il più snello e veloce possibile.
615
616 I cambiamenti apportati sono comunque notevoli e si possono essere riassunti a
617 grandi linee nei seguenti punti:
618 \begin{itemize}
619 \item l'espansione delle capacità di indirizzamento e instradamento, per
620   supportare una gerarchia con più livelli di indirizzamento, un numero di
621   nodi indirizzabili molto maggiore e una autoconfigurazione degli indirizzi
622 \item l'introduzione un nuovo tipo di indirizzamento, l'\textit{anycast} che
623   si aggiunge agli usuali \textit{unycast} e \textit{multicast}
624 \item la semplificazione del formato della testata, eliminando o rendendo
625   opzionali alcuni dei campi di IPv4, per eliminare la necessità di
626   riprocessamento della stessa da parte dei router e contenere l'aumento di
627   dimensione dovuto all'ampiamento degli indirizzi
628 \item un supporto per le opzioni migliorato, per garantire una trasmissione
629   più efficiente del traffico normale, limiti meno stringenti sulle dimensioni
630   delle opzioni, e la flessibilità necessaria per introdurne di nuove in
631   futuro
632 \item il supporto per delle capacità di qualità di servizio (QoS) che
633   permettano di identificare gruppi di dati per i quali si può provvedere un
634   trattamento speciale (in vista dell'uso di internet per applicazioni
635   multimediali e/o ``real-time'')
636 \end{itemize}
637
638 Maggiori dettagli riguardo a caratteristiche, notazioni e funzionamento del
639 protocollo IP sono forniti nell'appendice \capref{cha:ip_protocol}.
640
641  
642 \subsection{UDP: User Datagram Protocol)}
643 \label{sec:net_udp}
644
645 UDP è un protocollo di trasporto molto semplice, la sua descizione completa è
646 contenuta dell'RFC~768, ma in sostanza esso è una semplice interfaccia a IP
647 dal livello di trasporto. Quando un'applicazione usa UDP essa scrive un
648 pacchetto di dati (il cosiddetto \textit{datagram} che da il nome al
649 protocollo) su un socket, al pacchetto viene aggiunto un header molto semplice
650 (per una descrizione più accurata vedi \secref{sec:appA_udp}), e poi viene
651 passato al livello superiore (IPv4 o IPv6 che sia) che lo spedisce verso la
652 destinazione.  Dato che né IPv4 né IPv6 garantiscono l'affidabilità niente
653 assicura che il pacchetto arrivi a destinazione, né che più pacchetti arrivino
654 nello stesso ordine in cui sono stati spediti.
655
656 Pertanto il problema principale che si affronta quando si usa UDP è la
657 mancanza di affidabilità, se si vuole essere sicuri che i pacchetti arrivino a
658 destinazione occorrerà provvedere con l'applicazione all'interno della quale
659 si dovrà inserire tutto quanto necessario a gestire la notifica di
660 ricevimento, la ritrasmissione, il timeout. 
661
662 Si tenga conto poi che in UDP niente garantisce che i pacchetti arrivino nello
663 stesso ordine in cui sono stati trasmessi, e può anche accadere che i
664 pacchetti vengano duplicati nella trasmissione, e non solo perduti. Di tutto
665 questo di nuovo deve tenere conto l'applicazione.
666
667 Un'altro aspetto di UDP è che se un pacchetto raggiunge correttamente la
668 destinazione esso viene passato all'applicazione ricevente in tutta la sua
669 lunghezza, la trasmissione avviene perciò per \textit{record} la cui lunghezza
670 viene anche essa trasmessa all'applicazione all'atto del ricevimento.
671
672 Infine UDP è un protocollo che opera senza connessione
673 (\textit{connectionless}) in quanto non è necessario stabilire nessun tipo di
674 relazione tra origine e destinazione dei pacchetti. Si hanno così situazioni
675 in cui un client può scrivere su uno stesso socket pacchetti destinati a
676 server diversi, o un server ricevere su un socket paccetti provenienti da
677 client diversi.  Il modo più semplice di immaginarsi il funzionamento di UDP è
678 quello della radio, in cui si può ``trasmettere a'' e ``ricevere da'' più
679 stazioni usando la stessa frequenza.
680
681 Nonostante gli evidenti svantaggi comportati dall'inaffidabilità UDP ha il
682 grande pregio della velocità che in certi casi è essenziale; inoltre si presta
683 bene per le applicazioni in cui la connessione non è necessaria e
684 costituirebbe solo un peso di prestazioni mentre una perdita di pacchetti può
685 essere tollerata, ad esempio quelle che usano il multicasting.
686
687 \subsection{TCP: Transport Control Protocol)}
688 \label{sec:net_tcp}
689
690 Il TCP è un protocollo molto complesso, definito nell'RFC~739 e completamente
691 diverso da UDP; alla base del suo design infatti non stanno semplicità e
692 velocità, ma la ricerca della massima affidabilità possibile nella
693 trasmissione dei dati.
694
695 La prima differenza con UDP è che TCP provvede sempre una conessione diretta
696 fra un client e un server, attraverso la quale essi possono comunicare; per
697 questo il paragone più appropriato per questo protocollo è quello del
698 collegamento telefonico, in quanto prima viene stabilita una connessione fra
699 due i due capi della comunicazione su cui poi viene quest'ultima viene
700 effettuata.
701
702 Caratteristica fondamentale di TCP è l'affidabilità; quando i dati vengono
703 inviati attraverso una connessione ne viene richiesto un ``ricevuto''
704 (il cosiddetto \textit{acknowlegment}), se questo non arriva essi verranno
705 ritrasmessi per un determinato numero di tentativi, intervallati da un
706 periodo di tempo crescente, fino a che sarà considerata fallita o caduta la
707 connessione (e generato un errore di \textit{time-out}), dopo un periodo di
708 tempo che dipende dall'implementazione e che può variare far i
709 quattro e i dieci minuti.
710
711 Inoltre per tenere conto delle diverse condizioni in cui può trovarsi la linea
712 di comunicazione TCP comprende anche un algoritmo di calcolo dinamico del
713 tempo di andata e ritorno dei pacchetti (il cosiddetto RTT, 
714 \textit{round-trip time}) fra un client e un server che lo rende in grado di
715 adattarsi alle condizioni della rete per non generare inutili ritrasmissioni o
716 cadere facilmente in timeout.
717
718 Inoltre TCP è in grado di preservare l'ordine dei dati assegnando un numero di
719 sequenza ad ogni byte che trasmette. Ad esempio se un'applicazione scrive 3000
720 bytes su un socket TCP, questi potranno essere spezzati dal protocollo in due
721 segmenti (le unità di dati passate da TCP a IP vengono chiamate
722 \textit{segment}) di 1500 bytes, di cui il primo conterrà il numero di
723 sequenza $1-1500$ e il secondo il numero $1501-3000$. In questo modo anche se
724 i segmenti arrivano a destinazione in un ordine diverso, o se alcuni arrivano
725 più volte a causa di ritrasmissioni dovute alla perdita dei ricevuto,
726 all'arrivo sarà comunque possibile riordinare i dati e scartare i duplicati.
727
728 Il protocollo provvede anche un controllo di flusso (\textit{flow control}),
729 cioè specifica sempre all'altro capo della trasmissione quanti dati può
730 ricevere tramite una \textit{advertised window} (letteralmente finestra
731 annunciata), che indica lo spazio disponibile nel buffer di ricezione,
732 cosicchè nella trasmissione non vengano inviati più dati di quelli che possono
733 essere ricevuti. 
734
735 Questa finestra cambia dinamicamente diminuendo con la ricezione dei dati dal
736 socket ed aumentando con la lettura di quest'ultimo da parte
737 dell'applicazione, se diventa nulla il buffer di ricezione è pieno e non
738 verranno accettati altri dati.  Si noti che UDP non provvede niente di tutto
739 ciò per cui nulla impedisce che vengano trasmessi pacchetti ad un rate che il
740 ricevitore non può sostenere.
741
742 Infine attraverso TCP la trasmissione è sempre bidirezionale (in inglese
743 \textit{full-duplex}), è cioè possibile sia trasmettere che ricevere allo
744 stesso tempo, il che poi comporta che quanto dicevamo a proposito del
745 controllo di flusso e della gestione della sequenzialità dei dati viene
746 effettuato per entrambe le direzioni di comunicazione.
747
748 Una descrizione più accurata del protocollo è fornita in appendice
749 \capref{cha:tcp_protocol}.
750
751 \subsection{Limiti e dimensioni riguardanti la trasmissione dei dati}
752 \label{sec:net_lim_dim}
753
754 Un aspetto di cui bisogna tenere conto, e che ritornerà in seguito, è che ci
755 sono una serie di limiti a cui la trasmissione dei dati attraverso i vari
756 livelli del protocollo deve sottostare, limiti che è opportuno tenere presente
757 perché in certi casi si possono avere delle conseguenze sul comportamento
758 delle applicazioni.
759
760 Un elenco di questi limiti è il seguente, insieme ad un breve accenno alle
761 loro origini ed alle eventuali implicazioni che possono avere:
762 \begin{itemize}
763 \item La dimensione massima di un pacchetti IP è di 65535 bytes, compreso
764   l'header. Questo è dovuto al fatto che la dimensione è indicata da un campo
765   apposito nell'header di IP che è lungo 16 bit (vedi
766   \secref{sec:appA_ipv4head}).
767 \item La dimensione massima di un pacchetto normale di IPv6 è di 65575 bytes,
768   il campo apposito nell'header infatti è sempre a 16 bit, ma la dimensione
769   dell'header è fissa e di 40 byte e non è compresa nel valore indicato dal
770   suddetto campo. Inoltre IPv6 ha la possibilità di estendere la dimensione di
771   un pacchetto usando la \textit{jumbo payload option}.
772 \item Molte reti fisiche hanno un MTU (\textit{maximum tranfer unit}) che
773   dipende dal protocollo specifico usato al livello di link. Il più comune è
774   quello dell'ethernet che è pari a 1500 bytes, una serie di valori possibili
775   sono riportati in \ntab.
776 \end{itemize}
777
778 \begin{table}[!htb]
779   \centering
780   \begin{tabular}[c]{|l|c|}
781     \hline
782     \textbf{Rete} & \textbf{MTU} \\
783     \hline
784     Hyperlink & 65535 \\
785     Token Ring IBM (16 Mbit/sec) & 17914 \\
786     Token Ring IEEE 802.5 (4 Mbit/sec) & 4464 \\
787     FDDI & 4532 \\
788     Ethernet & 1500 \\
789     X.25 & 576 \\
790     \hline
791   \end{tabular}
792   \caption{Valori della MTU (\textit{maximum tranfer unit}) per una serie di
793     reti diverse.}
794   \label{tab:net_mtu_values}
795 \end{table}
796
797 Quando un pacchetto IP viene inviato su una interfaccia di rete e le sue
798 dimensioni eccedono la MTU viene eseguita la cosiddetta
799 \textit{frammentazione}, i pacchetti cioè vengono spezzati (sia da IPv4 che da
800 IPv6, anche se i pacchetti frammentati sono gestiti con modalità
801 diverse\footnote{il primo usa un flag nell'header, il secondo una opportuna
802   opzione, si veda \secref{cha:ip_protcol}}), in blocchi più piccoli che
803 possono essere trasmessi attraverso l'interfaccia.
804
805 La MTU più piccola fra due stazioni viene in genere chiamata \textit{path
806   MTU}, che dice qual'è la lunghezza massima oltre la quale un pacchetto
807 inviato da una stazione ad un'altra verrebbe senz'altro frammentato. Si tenga
808 conto che non è affatto detto che la \textit{path MTU} sia la stessa in
809 entrambe le direzioni, perchè l'instradamento può essere diverso nei due
810 sensi, con diverse tipologie di rete coinvolte.
811
812 Una delle differenze fra IPv4 e IPv6 é che per IPv6 la frammentazione può
813 essere eseguita solo alla sorgente, questo vuol dire che i router IPv6 non
814 frammentano i pacchetti che trasmettono (anche se possono frammentare i
815 pacchetti che generano loro stessi), mentre i router IPv4 si. In ogni caso una
816 volta frammentati i pacchetti possono essere riassemblati solo alla
817 destinazione.
818
819 Nell'header di IPv4 è previsto il flag \texttt{DF} che specifica che il
820 pacchetto non deve essere frammentato; un router che riceva un pacchetto le
821 cui dimensioni eccedano quelle dell'MTU della rete di destinazione genererà un
822 messaggio di errore ICMPv4 di tipo \textit{destination unreachable,
823   fragentation needed but DF bit set}.
824
825 Dato che i router IPv6 non possono effettuare la frammentazione la ricezione
826 di un pacchetto di dimensione eccessiva per la ritrasmissione genererà sempre
827 un messaggio di errore ICMPv6 di tipo \textit{paket too big}.
828
829 Dato che il meccanismo di frammentazione e riassemblaggio comporta
830 inefficienza normalmente viene utilizzato il procedimento della \textit{path
831   MTU discover} (vedi RFC1191 per IPv4 e RFC1981 per IPv6) che permette dui
832 trovare il \textit{path MTU} fra due stazioni; per la realizzazione del
833 procedimento si usa il flag DF di IPv4 e il comportamento normale di IPv6
834 inviando delle opportune serie di pacchetti (per i dettagli vedere l'RFC1191
835 per IPv4 e l'RFC1981 per IPv6) fintanto che non si hanno più errori. 
836
837 Il TCP usa sempre questo meccanismo, che per le implementazioni di IPv4 è
838 opzionale, mentre diventa obbligatorio per IPv6.  Per IPv6 infatti, non
839 potendo i router frammentare i pacchetti, è necessario, per poter comunicare,
840 conoscere il \textit{path MTU}.
841
842
843 Infine TCP definisce una \textit{maximum segment size} MSS che annuncia
844 all'altro capo la dimensione massima del segmento di dati 
845
846
847 \subsection{Il passaggio dei dati in TCP}
848 \label{sec:net_tcp_pass}
849
850 \subsection{Il passaggio dei dati in UDP}
851 \label{sec:net_udp_pass}