1 \chapter{Introduzione alla programmazione di rete}
4 In questo capitolo sarà fatta un'introduzione ai concetti 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.
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.
15 \section{Il modello client-server}
16 \label{sec:net_cliserv}
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
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.
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.
37 Normalmente si dividono i server in due categorie principali, e vengono detti
38 \textsl{concorrenti} o \textsl{iterativi}, sulla base del loro comportamento.
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
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.
52 \subsection{Un primo esempio di client}
53 \label{sec:net_cli_sample}
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.
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 richiesta.
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 */
77 int main(int argc, char *argv[])
81 struct sockaddr_in serv_add;
85 if ( (sock_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
86 perror("Socket creation error");
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");
98 /* extablish connection */
99 if (connect(sock_fd, (struct sockaddr *)&serv_add, sizeof(serv_add)) < 0) {
100 perror("Connection error");
103 /* read daytime from server */
104 while ( (nread = read(sock_fd, buffer, MAXLINE)) > 0) {
106 if (fputs(buffer, stdout) == EOF) { /* write daytime */
107 perror("fputs error");
113 perror("Read error");
120 \caption{Esempio di codice di un client elementare per il servizio daytime.}
121 \label{fig:net_cli_code}
124 Il sorgente completo del programma (\texttt{ElemDaytimeTCPClient.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.
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{sec:proc_opt_handling}).
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.
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
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 passata 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.
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}.
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).
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.
183 \subsection{Un primo esempio di server}
184 \label{sec:net_serv_sample}
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{ElemDaytimeTCPServer.c}) è allegato insieme agli altri file nella
190 directory \texttt{sources}.
192 \begin{figure}[!htbp]
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 */
203 int main(int argc, char *argv[])
206 * Variables definition
208 int list_fd, conn_fd;
210 struct sockaddr_in serv_add;
211 char buffer[MAXLINE];
215 if ( (list_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
216 perror("Socket creation error");
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 */
225 if (bind(list_fd, (struct sockaddr *)&serv_add, sizeof(serv_add)) < 0) {
226 perror("bind error");
229 /* listen on socket */
230 if (listen(list_fd, BACKLOG) < 0 ) {
231 perror("listen error");
234 /* write daytime to client */
236 if ( (conn_fd = accept(list_fd, (struct sockaddr *) NULL, NULL)) <0 ) {
237 perror("accept error");
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");
252 \caption{Esempio di codice di un semplice server per il servizio daytime.}
253 \label{fig:net_serv_code}
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.
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}).
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.
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.
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.
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.
293 È importante 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.
301 \section{I protocolli di rete}
302 \label{sec:net_protocols}
304 Visto un primo esempio di programmazione, passiamo ora ad una introduzione più
305 dettagliata del funzionamento delle reti e dei relativi protocolli.
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.
314 \subsection{Il modello ISO/OSI}
315 \label{sec:net_iso_osi}
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.
328 \begin{tabular}{l c c l}
329 \textbf{Livello} & \multicolumn{2}{c}{\textbf{Nome}} & \\
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}& \\
340 \caption{I sette livelli del protocollo ISO/OSI.}
341 \label{tab:net_osilayers}
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.
353 \begin{figure}[!htbp]
355 \includegraphics[width=8cm]{img/iso_tcp_comp.eps}
356 \caption{Struttura a livelli dei protocolli OSI e TCP/IP, con la
357 relative corrispondenze e la divisione fra kernel e user space.}
358 \label{fig:net_osi_tcpip_comp}
362 \subsection{Il modello DoD (TCP/IP)}
363 \label{sec:net_tcpip_overview}
365 Così come ISO/OSI anche TCP/IP è stato strutturato in livelli (riassunti in
366 \ntab); un confronto fra i due è riportato in \curfig\ dove viene evidenziata
367 anche la corrispondenza fra i rispettivi livelli (che comunque è
368 approssimativa) e su come essi vanno ad inserirsi all'interno del sistema
369 operativo rispetto alla divisione fra user space e kernel space spiegata in
370 \secref{sec:intro_unix_struct}.
374 \begin{tabular}{l c c l}
375 \textbf{Livello} & \multicolumn{2}{c}{\textbf{Nome}} & \textbf{Esempi} \\
377 Livello 1&\textit{Application} &\textsl{Applicazione}&
379 Livello 2&\textit{Transport} &\textsl{Trasporto}& TCP, UDP \\
380 Livello 3&\textit{Network} &\textsl{Rete}& IP, (ICMP, IGMP) \\
381 Livello 4&\textit{Link} &\textsl{Connessione}&
382 device driver \& scheda di interfaccia \\
385 \caption{I quattro livelli del protocollo TCP/IP.}
386 \label{tab:net_layers}
389 Come si può notare TCP/IP è più semplice del modello ISO/OSI e strutturato in
390 soli quattro livelli. Il suo nome deriva dai due principali protocolli che lo
391 compongono, il TCP \textit{Trasmission Control Protocol} e l'IP
392 \textit{Internet Protocol}. Le funzioni dei vari livelli sono le seguenti:
395 \item \textbf{Applicazione} É relativo ai programmi di interfaccia utente, in
396 genere questi vengono realizzati secondo il modello client-server (vedi
397 \secref{sec:net_cliserv}.
398 \item \textbf{Trasporto} Fornisce la comunicazione tra le due stazioni
399 terminali su cui girano gli applicativi, regola il flusso delle
400 informazioni, e può fornire un trasporto affidabile, cioè con recupero
401 errori. Il protocollo principale di questo livello è il TCP.
402 \item \textbf{Rete} Si occupa dello smistamento dei singoli pacchetti su una
403 rete complessa e interconnessa, a questo stesso livello operano i protocolli
404 per il reperimento delle informazioni necessarie allo smistamento, per lo
405 scambio di messaggi di controllo e per il monitoraggio della rete. Il
406 protocollo su cui si basa questo livello è IP (sia nella attuale versione,
407 IPv4 che nella nuova IPv6).
408 \item \textbf{Connessione} È responsabile per l'interfacciamento al
409 dispositivo elettronico che effettua la comunicazione fisica, gestendo
410 l'invio e la ricezione dall'hardware dei pacchetti.
414 La comunicazione fra due stazioni avviene secondo le modalità illustrate in
415 \nfig, dove si è riportato il flusso dei dati reali e i protocolli usati per
416 lo scambio di informazione su ciascuno livello.
419 \includegraphics[width=6cm]{img/tcp_data_flux.eps}
420 \caption{Strutturazione del flusso dei dati nella comunicazione fra due
421 applicazioni attraverso i protocolli della suite TCP/IP.}
422 \label{fig:net_tcpip_data_flux}
425 La struttura della comuniczione pertanto si può riassumere nei seguenti passi:
427 \item Le singole applicazioni si scambieranno i dati secondo un loro formato
428 specifico, implementando un protocollo di applicazione (esempi possono
429 essere HTTP, POP, telnet, SMTP, etc).
430 \item Questi dati vengono inviati al livello di trasporto usando
431 un'interfaccia opportuna (i \textit{socket}, che esamineremo in dettaglio in
432 seguito). Qui verranno spezzati in pacchetti di dimensione opportuna e
433 incapsulati nel protocollo di trasporto, aggiungendo ad ogni pacchetto le
434 informazioni necessarie per la sua gestione. Questo processo viene
435 svolto direttamente nel kernel ad esempio dallo stack TCP nel caso il
436 protocollo di trasporto sia questo.
437 \item Una volta composto il pacchetto nel formato adatto al protocollo di
438 trasporto usato questo sarà passato al successivo livello, quello del
439 collegamento che si occupa di inserire le opportune informazioni per poter
440 effettuare l'instradamento nella rete ed il recapito alla destinazione
441 finale. In genere questo è il livello di IP (Internet Protocol), a cui
442 vengono inseriti i numeri IP che identificano i computer su internet.
443 \item L'ultimo passo è il trasferimento del pacchetto al driver della
444 interfaccia di trasmissione che si incarica di incapsularlo nel relativo
445 protocollo di trasmissione fisica usato dall'hardware usato per la
446 comunicazione (ad esempio ethernet per una scheda di rete).
450 \subsection{Criteri generali del design di TCP/IP}
451 \label{sec:net_tcpip_design}
453 La filosofia architetturale di TCP/IP è semplice: costruire una rete che
454 possa sopportare il carico in transito, ma permettere ai singoli nodi di
455 scartare pacchetti se il carico è temporaneamente eccessivo, o se risultano
456 errati o non recapitabili.
458 L'incarico di rendere il recapito pacchetti affidabile non spetta allo livello
459 di collegamento, ma ai livelli superiori. Pertanto il protocollo IP è per sua
460 natura inaffidabile, in quanto non è assicurata né una percentuale di
461 successo né un limite sui tempi di consegna dei pacchetti.
463 È il livello di trasporto che si deve occupare (qualora necessiti) del
464 controllo del flusso dei dati e del recupero degli errori; questo è realizzato
465 dal protocollo TCP. La sede principale di "intelligenza" della rete è pertanto
466 al livello di trasporto o superiore.
468 Infine le singole stazioni collegate alla rete non fungono soltanto da punti
469 terminali di comunicazione, ma possono anche assumere il ruolo di router, per
470 l'interscambio di pacchetti da una rete ad un'altra. Questo rende possibile la
471 flessibilità della rete che è in grado di adattarsi ai mutamenti delle
474 La caratteristica essenziale che rende tutto ciò possibile è la strutturazione
475 a livelli tramite l'incapsulamento. Ogni pacchetto di dati viene incapsulato
476 nel formato del livello successivo, fino al livello della connessione fisica.
477 In questo modo il pacchetto ricevuto ad un livello $n$ dalla stazione di
478 destinazione è esattamente lo stesso spedito dal livello $n$ dalla sorgente.
479 Questo rende facile il progettare il software facendo riferimento unicamente a
480 quanto necessario ad un singolo livello, con la confidenza che questo poi sarà
481 trattato uniformemente da tutti i nodi della rete.
484 \section{Il protocollo TCP/IP}
485 \label{sec:net_tpcip}
487 Come appena mostrato il protocollo TCP/IP è un insieme di protocolli diversi,
488 che operano su 4 livelli diversi. Per gli interessi della programmazione di
489 rete però sono importanti principalmente i due livelli centrali, e soprattutto
492 La principale interfaccia di programmazione di rete, quella dei socket, è
493 infatti un'interfaccia nei confronti di quest'ultimo. Questo avviene perché al
494 di sopra del livello di trasporto i programmi hanno a che fare solo con
495 dettagli specifici delle applicazioni, mentre al di sotto vengono curati tutti
496 i dettagli relativi alla comunicazione. È pertanto naturale definire una API
497 su questo confine tanto più che è proprio li (come evidenziato in \pfig) che
498 nei sistemi unix (e non solo) viene inserita la divisione fra kernel space e
501 In realtà in un sistema unix è possibile accedere anche agli altri livelli
502 inferiori (e non solo a quello di trasporto) con opportune interfacce (la cosa
503 è indicata in \pfig\ lasciando uno spazio fra UDP e TCP), ma queste vengono
504 usate solo quando si vogliono fare applicazioni di sistema per il controllo
505 della rete a basso livello, un uso quindi molto specialistico, e che non
506 rientra in quanto trattato qui.
508 In questa sezione daremo una breve descrizione dei vari protocolli di TCP/IP,
509 concentrandoci per le ragioni esposte sul livello di trasporto. All'interno di
510 questo privilegeremo poi il protocollo TCP, per il ruolo centrale che svolge
511 nella maggior parte delle applicazioni.
513 \subsection{Il quadro generale}
515 Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da
516 altri membri. In \nfig\ si è riportato uno schema che mostra un panorama sui
517 vari protocolli della famiglia, e delle loro relazioni reciproche e con
518 alcune dalle principali applicazioni che li usano.
520 \begin{figure}[!htbp]
522 \includegraphics[width=10cm]{img/tcpip_overview.eps}
523 \caption{Panoramica sui vari protocolli che compongono la suite TCP/IP.}
524 \label{fig:net_tcpip_overview}
527 I vari protocolli mostrati in figura sono i seguenti:
530 \item \textsl{IPv4} \textit{Internet Protocol version 4}. È quello che
531 comunemente si chiama IP. Ha origine negli anni '80 e da allora è la base su
532 cui è costruita internet. Usa indirizzi a 32 bit e provvede la trasmissione
533 dei pacchetti TCP, UDP, ICMP e IGMP.
534 \item \textsl{IPv6} \textit{Internet Protocol version 6}. È stato progettato a
535 metà degli anni '90 per rimpiazzare IPv4. Ha indirizzi a 128 bit e effettua
536 lo stesso servizio di trasporto di IPv4 per i pacchetti TCP, UDP e ICPMv6.
537 \item \textsl{TCP} \textit{Trasmission Control Protocol}. È un protocollo
538 orientato alla connessione che provvede un trasporto affidabile e
539 bidirezionale di un flusso di dati. I socket TCP sono esempi di
540 \textit{stream socket}. Il protocollo ha cura di tutti gli aspetti del
541 trasporto, come l'acknoweledgment, i timeout, la ritrasmissione, etc. È
542 usato dalla maggior parte delle applicazioni. Può essere usato sia con IPv4
544 \item \textsl{UDP} \textit{User Datagram Protocol}. È un protocollo senza
545 connessione a pacchetti. I socket UDP sono esempi di \textit{datagram
546 socket}. Contrariamente al TCP in protocollo non è affidabile e non c'è
547 garanzia che i pacchetti raggiungano la loro destinazione, né sull'eventuale
548 ordine di arrivo. Può essere usato sia con IPv4 che con IPv6.
549 \item \textsl{ICMP} \textit{Internet Control Message Protocol}. Gestisce gli
550 errori e trasporta l'informazione di controllo fra stazioni remote e
551 instradatori (\textit{host} e \textit{router}). I messaggi sono normalmente
552 generati dal software del kernel che gestisce la comunicazione TCP/IP, anche
553 se ICMP può venire usato direttamente da alcuni programmi come
554 \texttt{ping}. A volte ci si riferisce ad esso come ICPMv4 per distinguerlo
556 \item \textsl{ICMP} \textit{Internet Group Management Protocol}. É un
557 protocollo usato per il \textit{multicasting} (vedi
558 \secref{sec:xxx_multicast}), che è opzionale in IPv4.
559 \item \textsl{ARP} \textit{Address Resolution Protocol}. È il protocollo che
560 mappa un indirizzo IP in un indirizzo hardware (come un indirizzo
561 internet). È usato in reti di tipo broadcast come ethernet, token ring o
562 FDDI ma non serve in connessioni punto-punto.
563 \item \textsl{RARP} \textit{Reverse Address Resolution Protocol}. È il
564 protocollo che mappa un indirizzo hardware in un indirizzo IP. Viene usato a
565 volte per durante il boot per assegnare un indirizzo IP ad una macchina.
566 \item \textsl{ICMPv6} \textit{Internet Control Message Protocol, version 6}.
567 Combina per IPv6 le funzionalità di ICMPv4, IGMP e ARP.
568 \item \textsl{NETLINK} \textit{Netlink}.
569 Provvede l'interfaccia di accesso alla comunicazione a basso livello.
572 Gran parte delle applicazioni comunicano usando TCP o UDP, ed alcune si
573 rifanno ad IP (ed i suoi correlati ICMP e IGMP); benché sia TCP che UDP siano
574 basati su IP e sia possibile intervenire a questo livello con i \textit{raw
575 socket} questa tecnica è molto meno diffusa e a parte applicazioni
576 particolari si preferisce sempre usare i servizi messi a disposizione dai due
577 protocolli precedenti. Per questo motivo a parte alcuni brevi accenni su IP
578 in questa sezione ci concentreremo sul livello di trasporto.
580 \subsection{Internet Protocol (IP)}
583 Quando si parla di IP ci si riferisce in genere alla versione attualmente in
584 uso che è la versione 4 (e viene pertanto chiamato IPv4). Questa versione
585 venne standardizzata nel 1981 dall'RFC~719.
587 Internet Protocol nasce per disaccoppiare le applicazioni della struttura
588 hardware delle reti di trasmissione, e creare una interfaccia di trasmissione
589 dei dati indipendente dal sottostante substrato di rete, che può essere
590 realizzato con le tecnologie più disparate (Ethernet, Token Ring, FDDI, etc.).
591 Il compito di IP è pertanto quello di trasmettere i pacchetti da un computer
592 all'altro della rete; le caratteristiche essenziali con cui questo viene
593 realizzato in IPv4 sono due:
596 \item \textit{Universal addressing} la comunicazione avviene fra due host
597 identificati univocamente con un indirizzo a 32 bit che può appartenere ad
598 una sola interfaccia di rete.
599 \item \textit{Best effort} viene assicurato il massimo impegno nella
600 trasmissione, ma non c'è nessuna garanzia per i livelli superiori né sulla
601 percentuale di successo né sul tempo di consegna dei pacchetti di dati.
604 Negli anni '90 la crescita vertiginosa del numero di macchine connesse a
605 internet ha iniziato a far emergere i vari limiti di IPv4, per risolverne i
606 problemi si è perciò definita una nuova versione del protocollo, che (saltando
607 un numero) è diventata la versione 6. IPv6 nasce quindi come evoluzione di
608 IPv4, mantendone inalterate le funzioni che si sono dimostrate valide,
609 eliminando quelle inutili e aggiungendone poche altre per mantenere il
610 protocollo il più snello e veloce possibile.
612 I cambiamenti apportati sono comunque notevoli e si possono essere riassunti a
613 grandi linee nei seguenti punti:
615 \item l'espansione delle capacità di indirizzamento e instradamento, per
616 supportare una gerarchia con più livelli di indirizzamento, un numero di
617 nodi indirizzabili molto maggiore e una autoconfigurazione degli indirizzi
618 \item l'introduzione un nuovo tipo di indirizzamento, l'\textit{anycast} che
619 si aggiunge agli usuali \textit{unycast} e \textit{multicast}
620 \item la semplificazione del formato della testata, eliminando o rendendo
621 opzionali alcuni dei campi di IPv4, per eliminare la necessità di
622 riprocessamento della stessa da parte dei router e contenere l'aumento di
623 dimensione dovuto all'ampliamento degli indirizzi
624 \item un supporto per le opzioni migliorato, per garantire una trasmissione
625 più efficiente del traffico normale, limiti meno stringenti sulle dimensioni
626 delle opzioni, e la flessibilità necessaria per introdurne di nuove in
628 \item il supporto per delle capacità di qualità di servizio (QoS) che
629 permettano di identificare gruppi di dati per i quali si può provvedere un
630 trattamento speciale (in vista dell'uso di internet per applicazioni
631 multimediali e/o ``real-time'')
634 Maggiori dettagli riguardo a caratteristiche, notazioni e funzionamento del
635 protocollo IP sono forniti nell'appendice \capref{cha:ip_protocol}.
638 \subsection{UDP: User Datagram Protocol)}
641 UDP è un protocollo di trasporto molto semplice, la sua descrizione completa è
642 contenuta dell'RFC~768, ma in sostanza esso è una semplice interfaccia a IP
643 dal livello di trasporto. Quando un'applicazione usa UDP essa scrive un
644 pacchetto di dati (il cosiddetto \textit{datagram} che da il nome al
645 protocollo) su un socket, al pacchetto viene aggiunto un header molto semplice
646 (per una descrizione più accurata vedi \secref{sec:xxx_udp}), e poi viene
647 passato al livello superiore (IPv4 o IPv6 che sia) che lo spedisce verso la
648 destinazione. Dato che né IPv4 né IPv6 garantiscono l'affidabilità niente
649 assicura che il pacchetto arrivi a destinazione, né che più pacchetti arrivino
650 nello stesso ordine in cui sono stati spediti.
652 Pertanto il problema principale che si affronta quando si usa UDP è la
653 mancanza di affidabilità, se si vuole essere sicuri che i pacchetti arrivino a
654 destinazione occorrerà provvedere con l'applicazione all'interno della quale
655 si dovrà inserire tutto quanto necessario a gestire la notifica di
656 ricevimento, la ritrasmissione, il timeout.
658 Si tenga conto poi che in UDP niente garantisce che i pacchetti arrivino nello
659 stesso ordine in cui sono stati trasmessi, e può anche accadere che i
660 pacchetti vengano duplicati nella trasmissione, e non solo perduti. Di tutto
661 questo di nuovo deve tenere conto l'applicazione.
663 Un'altro aspetto di UDP è che se un pacchetto raggiunge correttamente la
664 destinazione esso viene passato all'applicazione ricevente in tutta la sua
665 lunghezza, la trasmissione avviene perciò per \textit{record} la cui lunghezza
666 viene anche essa trasmessa all'applicazione all'atto del ricevimento.
668 Infine UDP è un protocollo che opera senza connessione
669 (\textit{connectionless}) in quanto non è necessario stabilire nessun tipo di
670 relazione tra origine e destinazione dei pacchetti. Si hanno così situazioni
671 in cui un client può scrivere su uno stesso socket pacchetti destinati a
672 server diversi, o un server ricevere su un socket pacchetti provenienti da
673 client diversi. Il modo più semplice di immaginarsi il funzionamento di UDP è
674 quello della radio, in cui si può ``trasmettere a'' e ``ricevere da'' più
675 stazioni usando la stessa frequenza.
677 Nonostante gli evidenti svantaggi comportati dall'inaffidabilità UDP ha il
678 grande pregio della velocità che in certi casi è essenziale; inoltre si presta
679 bene per le applicazioni in cui la connessione non è necessaria e
680 costituirebbe solo un peso di prestazioni mentre una perdita di pacchetti può
681 essere tollerata, ad esempio quelle che usano il multicasting.
683 \subsection{TCP: Transport Control Protocol)}
686 Il TCP è un protocollo molto complesso, definito nell'RFC~739 e completamente
687 diverso da UDP; alla base del suo design infatti non stanno semplicità e
688 velocità, ma la ricerca della massima affidabilità possibile nella
689 trasmissione dei dati.
691 La prima differenza con UDP è che TCP provvede sempre una connessione diretta
692 fra un client e un server, attraverso la quale essi possono comunicare; per
693 questo il paragone più appropriato per questo protocollo è quello del
694 collegamento telefonico, in quanto prima viene stabilita una connessione fra
695 due i due capi della comunicazione su cui poi viene quest'ultima viene
698 Caratteristica fondamentale di TCP è l'affidabilità; quando i dati vengono
699 inviati attraverso una connessione ne viene richiesto un ``ricevuto''
700 (il cosiddetto \textit{acknowlegment}), se questo non arriva essi verranno
701 ritrasmessi per un determinato numero di tentativi, intervallati da un
702 periodo di tempo crescente, fino a che sarà considerata fallita o caduta la
703 connessione (e generato un errore di \textit{time-out}), dopo un periodo di
704 tempo che dipende dall'implementazione e che può variare far i
705 quattro e i dieci minuti.
707 Inoltre per tenere conto delle diverse condizioni in cui può trovarsi la linea
708 di comunicazione TCP comprende anche un algoritmo di calcolo dinamico del
709 tempo di andata e ritorno dei pacchetti (il cosiddetto RTT,
710 \textit{round-trip time}) fra un client e un server che lo rende in grado di
711 adattarsi alle condizioni della rete per non generare inutili ritrasmissioni o
712 cadere facilmente in timeout.
714 Inoltre TCP è in grado di preservare l'ordine dei dati assegnando un numero di
715 sequenza ad ogni byte che trasmette. Ad esempio se un'applicazione scrive 3000
716 bytes su un socket TCP, questi potranno essere spezzati dal protocollo in due
717 segmenti (le unità di dati passate da TCP a IP vengono chiamate
718 \textit{segment}) di 1500 bytes, di cui il primo conterrà il numero di
719 sequenza $1-1500$ e il secondo il numero $1501-3000$. In questo modo anche se
720 i segmenti arrivano a destinazione in un ordine diverso, o se alcuni arrivano
721 più volte a causa di ritrasmissioni dovute alla perdita dei ricevuto,
722 all'arrivo sarà comunque possibile riordinare i dati e scartare i duplicati.
724 Il protocollo provvede anche un controllo di flusso (\textit{flow control}),
725 cioè specifica sempre all'altro capo della trasmissione quanti dati può
726 ricevere tramite una \textit{advertised window} (letteralmente finestra
727 annunciata), che indica lo spazio disponibile nel buffer di ricezione,
728 cosicché nella trasmissione non vengano inviati più dati di quelli che possono
731 Questa finestra cambia dinamicamente diminuendo con la ricezione dei dati dal
732 socket ed aumentando con la lettura di quest'ultimo da parte
733 dell'applicazione, se diventa nulla il buffer di ricezione è pieno e non
734 verranno accettati altri dati. Si noti che UDP non provvede niente di tutto
735 ciò per cui nulla impedisce che vengano trasmessi pacchetti ad un rate che il
736 ricevitore non può sostenere.
738 Infine attraverso TCP la trasmissione è sempre bidirezionale (in inglese
739 \textit{full-duplex}), è cioè possibile sia trasmettere che ricevere allo
740 stesso tempo, il che poi comporta che quanto dicevamo a proposito del
741 controllo di flusso e della gestione della sequenzialità dei dati viene
742 effettuato per entrambe le direzioni di comunicazione.
744 Una descrizione più accurata del protocollo è fornita in appendice
745 \capref{cha:tcp_protocol}.
747 \subsection{Limiti e dimensioni riguardanti la trasmissione dei dati}
748 \label{sec:net_lim_dim}
750 Un aspetto di cui bisogna tenere conto, e che ritornerà in seguito, è che ci
751 sono una serie di limiti a cui la trasmissione dei dati attraverso i vari
752 livelli del protocollo deve sottostare, limiti che è opportuno tenere presente
753 perché in certi casi si possono avere delle conseguenze sul comportamento
756 Un elenco di questi limiti è il seguente, insieme ad un breve accenno alle
757 loro origini ed alle eventuali implicazioni che possono avere:
759 \item La dimensione massima di un pacchetti IP è di 65535 bytes, compreso
760 l'header. Questo è dovuto al fatto che la dimensione è indicata da un campo
761 apposito nell'header di IP che è lungo 16 bit (vedi
762 \tabref{tab:IP_ipv4head}).
763 \item La dimensione massima di un pacchetto normale di IPv6 è di 65575 bytes,
764 il campo apposito nell'header infatti è sempre a 16 bit, ma la dimensione
765 dell'header è fissa e di 40 byte e non è compresa nel valore indicato dal
766 suddetto campo. Inoltre IPv6 ha la possibilità di estendere la dimensione di
767 un pacchetto usando la \textit{jumbo payload option}.
768 \item Molte reti fisiche hanno un MTU (\textit{maximum tranfer unit}) che
769 dipende dal protocollo specifico usato al livello di link. Il più comune è
770 quello dell'ethernet che è pari a 1500 bytes, una serie di valori possibili
771 sono riportati in \ntab.
774 Quando un pacchetto IP viene inviato su una interfaccia di rete e le sue
775 dimensioni eccedono la MTU viene eseguita la cosiddetta
776 \textit{frammentazione}, i pacchetti cioè vengono spezzati (sia da IPv4 che da
777 IPv6, anche se i pacchetti frammentati sono gestiti con modalità
778 diverse\footnote{il primo usa un flag nell'header, il secondo una opportuna
779 opzione, si veda \secref{cha:ip_protocol}}), in blocchi più piccoli che
780 possono essere trasmessi attraverso l'interfaccia.
784 \begin{tabular}[c]{|l|c|}
786 \textbf{Rete} & \textbf{MTU} \\
790 Token Ring IBM (16 Mbit/sec) & 17914 \\
791 Token Ring IEEE 802.5 (4 Mbit/sec) & 4464 \\
797 \caption{Valori della MTU (\textit{maximum tranfer unit}) per una serie di
799 \label{tab:net_mtu_values}
802 La MTU più piccola fra due stazioni viene in genere chiamata \textit{path
803 MTU}, che dice qual'è la lunghezza massima oltre la quale un pacchetto
804 inviato da una stazione ad un'altra verrebbe senz'altro frammentato. Si tenga
805 conto che non è affatto detto che la \textit{path MTU} sia la stessa in
806 entrambe le direzioni, perché l'instradamento può essere diverso nei due
807 sensi, con diverse tipologie di rete coinvolte.
809 Una delle differenze fra IPv4 e IPv6 é che per IPv6 la frammentazione può
810 essere eseguita solo alla sorgente, questo vuol dire che i router IPv6 non
811 frammentano i pacchetti che trasmettono (anche se possono frammentare i
812 pacchetti che generano loro stessi), mentre i router IPv4 si. In ogni caso una
813 volta frammentati i pacchetti possono essere riassemblati solo alla
816 Nell'header di IPv4 è previsto il flag \texttt{DF} che specifica che il
817 pacchetto non deve essere frammentato; un router che riceva un pacchetto le
818 cui dimensioni eccedano quelle dell'MTU della rete di destinazione genererà un
819 messaggio di errore ICMPv4 di tipo \textit{destination unreachable,
820 fragentation needed but DF bit set}.
822 Dato che i router IPv6 non possono effettuare la frammentazione la ricezione
823 di un pacchetto di dimensione eccessiva per la ritrasmissione genererà sempre
824 un messaggio di errore ICMPv6 di tipo \textit{packet too big}.
826 Dato che il meccanismo di frammentazione e riassemblaggio comporta
827 inefficienza normalmente viene utilizzato il procedimento della \textit{path
828 MTU discover} (vedi RFC~1191 per IPv4 e RFC~1981 per IPv6) che permette di
829 trovare il \textit{path MTU} fra due stazioni; per la realizzazione del
830 procedimento si usa il flag DF di IPv4 e il comportamento normale di IPv6
831 inviando delle opportune serie di pacchetti (per i dettagli vedere l'RFC~1191
832 per IPv4 e l'RFC~1981 per IPv6) fintanto che non si hanno più errori.
834 Il TCP usa sempre questo meccanismo, che per le implementazioni di IPv4 è
835 opzionale, mentre diventa obbligatorio per IPv6. Per IPv6 infatti, non
836 potendo i router frammentare i pacchetti, è necessario, per poter comunicare,
837 conoscere il \textit{path MTU}.
840 Infine TCP definisce una \textit{maximum segment size} MSS che annuncia
841 all'altro capo la dimensione massima del segmento di dati
844 \subsection{Il passaggio dei dati in TCP}
845 \label{sec:net_tcp_pass}
847 \subsection{Il passaggio dei dati in UDP}
848 \label{sec:net_udp_pass}