1 \chapter{Introduzione alla programmazione di rete}
4 In questo capitolo sarà fatta un'introduzione ai contetti generali che servono
5 come prerequisiti per capire la programmazione di rete, partiremo con due
6 semplici esempi per poi passare ad un esame a grandi linee dei protocolli di
7 rete e di come questi sono organizzati e interagiscono.
9 In particolare, avendo assunto l'ottica di un'introduzione mirata alla
10 programmazione, ci concentreremo sul protocollo più diffuso, TCP/IP, che è
11 quello che sta alla base di internet, ed in particolare prenderemo in esame in
12 questa introduzione i concetti più importanti da conoscere ai fini della
16 \section{Il modello client-server}
17 \label{sec:net_cliserv}
19 La differenza principale fra un'applicazione di rete e un programma normale è
20 che quest'ultima per definizione concerne la comunicazione fra ``processi''
21 diversi (che in generale non girano neanche sulla stessa macchina). Questo già
22 prefigura un cambiamento completo rispetto all'ottica del ``programma''
23 monolitico all'interno del quale vengono eseguite tutte le istruzioni, e
24 presuppone un sistema operativo ``multitasking'' in grado di eseguire processi
27 Il concetto fondamentale si basa la programmazione di rete sotto Linux (e
28 sotto Unix in generale) è il modello \textit{client-server} in cui un
29 programma di servizio, il \textit{server} riceve un connessione e risponde a
30 un programma di utilizzo, il \textit{client}, provvedendo a quest'ultimo un
31 definito insieme di servizi.
33 Esempi di questo modello sono il WEB, ftp, telnet, ssh e praticamente ogni
34 servizio che viene fornito tramite la rete, ma il modello è utilizzato in
35 generale anche per programmi che non fanno necessariamente uso della rete,
36 come il sistema a finestre.
38 Normalmente si dividono i server in due categorie principali, e vengono detti
39 \textit{concorrenti} o \textit{iterativi}, sulla base del loro comportamento.
41 Un server iterativo risponde alla richiesta inviando i dati e resta occupato
42 (non rispondendo ad ulteriori richieste) fintanto che non ha concluso la
43 richiesta. Una volta completata la richiesta il server diventa di nuovo
46 Un server concorrente al momento di trattare la richiesta crea un processo
47 figlio incaricato di fornire i servizi richiesti, per poi porsi in attesa di
48 ulteriori richieste. In questo modo più richieste possono essere soddisfatte
49 contemporaneamente; una volta che il processo figlio ha concluso il suo lavoro
50 viene terminato, mentre il server originale resta sempre attivo.
53 \subsection{Un primo esempio di client}
54 \label{sec:net_cli_sample}
56 Per evitare di rendere l'esposizione dei concetti generali sulla rete
57 puramente teorica iniziamo con il mostrare un semplice esempio di client TCP.
58 In \nfig\ è riportata la sezione principale del codice del nostro client
59 elementare per il servizio \textit{daytime}, un servizio standard che
60 restituisce l'ora locale della macchina a cui si effettua la richesta.
65 #include <sys/types.h> /* predefined types */
66 #include <unistd.h> /* include unix standard library */
67 #include <arpa/inet.h> /* IP addresses conversion utiliites */
68 #include <sys/socket.h> /* socket library */
69 #include <stdio.h> /* include standard I/O library */
71 int main(int argc, char *argv[])
75 struct sockaddr_in serv_add;
79 if ( (sock_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
80 perror("Socket creation error");
83 /* initialize address */
84 memset((void *) &serv_add, 0, sizeof(serv_add)); /* clear server address */
85 serv_add.sin_family = AF_INET; /* address type is INET */
86 serv_add.sin_port = htons(13); /* daytime post is 13 */
87 /* build address using inet_pton */
88 if ( (inet_pton(AF_INET, argv[optind], &serv_add.sin_addr)) <= 0) {
89 perror("Address creation error");
92 /* extablish connection */
93 if (connect(sock_fd, (struct sockaddr *)&serv_add, sizeof(serv_add)) < 0) {
94 perror("Connection error");
97 /* read daytime from server */
98 while ( (nread = read(sock_fd, buffer, MAXLINE)) > 0) {
100 if (fputs(buffer, stdout) == EOF) { /* write daytime */
101 perror("fputs error");
107 perror("Read error");
114 \caption{Esempio di codice di un client elementare per il servizio daytime.}
115 \label{fig:net_cli_code}
118 Scopo di questo esempio è fornire un primo approccio alla programmazione di
119 rete, per questo motivo non ci dilungheremo nel trattare il significato dei
120 termini o il funzionamento delle varie funzioni utilizzate. Tutto questo sarà
121 esaminato in dettaglio nel seguito, per cui qui ci limiteremo a citarli senza
122 ulteriori spiegazioni.
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.
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 \ref{cha:parameter_options}).
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 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.
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{SimpleDaytimeTCPServer.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];
217 if ( (list_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
218 perror("Socket creation error");
221 /* initialize address */
222 memset((void *)&serv_add, 0, sizeof(serv_add)); /* clear server address */
223 serv_add.sin_family = AF_INET; /* address type is INET */
224 serv_add.sin_port = htons(13); /* daytime port is 13 */
225 serv_add.sin_addr.s_addr = htonl(INADDR_ANY); /* connect from anywhere */
227 if (bind(list_fd, (struct sockaddr *)&serv_add, sizeof(serv_add)) < 0) {
228 perror("bind error");
231 /* listen on socket */
232 if (listen(list_fd, BACKLOG) < 0 ) {
233 perror("listen error");
236 /* write daytime to client */
238 if ( (conn_fd = accept(list_fd, (struct sockaddr *) NULL, NULL)) <0 ) {
239 perror("accept error");
242 timeval = time(NULL);
243 snprintf(buffer, sizeof(buffer), "%.24s\r\n", ctime(&timeval));
244 if ( (write(conn_fd, buffer, strlen(buffer))) < 0 ) {
245 perror("write error");
254 \caption{Esempio di codice di un semplice server per il servizio daytime.}
255 \label{fig:net_serv_code}
258 Come per il client si includono gli header necessari a cui è aggiunto quello
259 per trattare i tempi, e si definiscono alcune costanti e le variabili
260 necessarie in seguito (\texttt{\small 1--18}), come nel caso precedente si
261 sono omesse le parti relative al trattamento delle opzioni da riga di comando.
263 La creazione del socket (\texttt{\small 22--26}) è analoga al caso precedente,
264 come pure l'inizializzazione della struttura \texttt{sockaddr\_in}, anche in
265 questo caso si usa la porta standard del servizio daytime, ma come indirizzo
266 IP si il valore predefinito \texttt{INET\_ANY} che corrisponde ad un indirizzo
267 generico (\texttt{\small 27--31}).
269 Si effettua poi (\texttt{\small 32--36}) la chiamata alla funzione
270 \texttt{bind} che permette di associare la precedente struttura al socket, in
271 modo che quest'ultimo possa essere usato per accettare connessioni su una
272 qualunque delle interfacce di rete locali.
274 Il passo successivo (\texttt{\small 37--41}) è mettere ``in ascolto'' il
275 socket, questo viene effettuato con la funzione \texttt{listen} che dice al
276 kernel di accettare connessioni per il socket specificato, la funzione indica
277 inoltre, con il secondo parametro, il numero massimo di connessioni che il
278 kernel accetterà di mettere in coda per il suddetto socket.
280 Questa ultima chiamata completa la preparazione del socket per l'ascolto (che
281 viene chiamato anche \textit{listening descriptor}) a questo punto il processo
282 è mandato in sleep (\texttt{\small 44--47}) con la successiva chiamata alla
283 funzione \texttt{accept}, fin quando non arriva e viene accettata una
284 connessione da un client.
286 Quando questo avviene \texttt{accept} ritorna un secondo descrittore di
287 socket, che viene chiamato \textit{connected descriptor} che è quello che
288 viene usato dalla successiva chiamata alla \texttt{write} per scrivere la
289 risposta al client, una volta che si è opportunamente (\texttt{\small 48--49})
290 costruita la stringa con la data da trasmettere. Completata la trasmissione il
291 nuovo socket viene chiuso (\texttt{\small 54}).
292 Il tutto è inserito in un loop infinito (\texttt{\small 42--55}) in modo da
293 poter ripetere l'invio della data ad una successiva connessione.
295 È impostante notare che questo server è estremamente elementare, infatti a
296 parte il fatto di essere dipendente da IPv4, esso è in grado di servire solo
297 un client alla volta, è cioè un \textsl{server iterativo}, inoltre esso è
298 scritto per essere lanciato da linea di comando, se lo si volesse utilizzare
299 come demone di sistema (che è in esecuzione anche quando non c'è nessuna shell
300 attiva), occorrerebbero delle opportune modifiche.
302 \section{I protocolli di rete}
303 \label{sec:net_protocols}
305 Parlando di reti di computer si parla in genere di un insieme molto vasto ed
306 eterogeneo di mezzi di comunicazione che vanno dal cavo telefonico, alla fibra
307 ottica, alle comunicazioni via satellite; per rendere possibile la
308 comunicazione attraverso un così variegato insieme di mezzi sono stati
309 adottati una serie di protocolli, il più famoso dei quali, quello alla base
310 del funzionamento di internet, è il protocollo TCP/IP.
312 \subsection{Il modello ISO/OSI}
313 \label{sec:net_iso_osi}
315 Una caratteristica comune dei protocolli di rete è il loro essere strutturati
316 in livelli sovrapposti; in questo modo un livello superiore esegue richieste
317 al livello sottostante e da questo riceve responsi, mentre livelli uguali su
318 macchine diverse conversano tramite lo stesso protocollo. Questo modello di
319 funzionamento è stato stato standardizzato dalla \textit{International
320 Standards Organization} (ISO) che ha preparato fin dal 1984 il Modello di
321 Riferimento \textit{Open Systems Interconnection} (OSI), strutturato in sette
322 livelli, secondo la tabella in \ntab.
326 \begin{tabular}{l c c l}
327 \textbf{Livello} & \multicolumn{2}{c}{\textbf{Nome}} & \\
329 Livello 7&\textit{Application} &\textsl{Applicazione}& \\
330 Livello 6&\textit{Presentation} &\textsl{Presentazione}& \\
331 Livello 5&\textit{Session} &\textsl{Sessione}& \\
332 Livello 4&\textit{Transport} &\textsl{Trasporto}& \\
333 Livello 3&\textit{Network} &\textsl{Rete}& \\
334 Livello 2&\textit{DataLink} &\textsl{Collegamento Dati}& \\
335 Livello 1&\textit{Connection} &\textsl{Connessione Fisica}& \\
338 \caption{I sette livelli del protocollo ISO/OSI.}
339 \label{tab:net_osilayers}
342 Il modello ISO/OSI è stato sviluppato corrispondentemente alla definizione
343 della serie di protocolli X.25 per la commutazione di pacchetto. Ma nonostante
344 il lavoro dettagliato di standardizzazione il modello si è rivelato
345 sostanzialmente troppo complesso e poco flessibile rispetto a quello,
346 precedente, su cui si basa TCP/IP che è diventato uno standard de facto;
347 quest'ultimo viene comunemente chiamato modello DoD (\textit{Department of
348 Defense}), dato che fu sviluppato dall'agenzia ARPA per il Dipartimento
349 della Difesa Americano.
351 \subsection{Il modello DoD (TCP/IP)}
352 \label{sec:net_tcpip_overview}
354 Così come ISO/OSI anche TCP/IP è stato strutturato in livelli (riassunti in
355 \ntab); un confronto fra i due è riportato in \nfig\ dove viene evidenziata
356 anche la corrispondenza fra i rispettivi livelli (che comunque è
357 approssimativa) e su come essi vanno ad inserirsi all'interno del sistema
358 operativo rispetto alla divisione fra user space e kernel space spiegata in
359 \ref{sec:intro_unix_struct}.
363 \begin{tabular}{l c c l}
364 \textbf{Livello} & \multicolumn{2}{c}{\textbf{Nome}} & \textbf{Esempi} \\
366 Livello 1&\textit{Application} &\textsl{Applicazione}&
368 Livello 2&\textit{Transport} &\textsl{Trasporto}& TCP, UDP \\
369 Livello 3&\textit{Network} &\textsl{Rete}& IP, (ICMP, IGMP) \\
370 Livello 4&\textit{Link} &\textsl{Connessione}&
371 device driver \& scheda di interfaccia \\
374 \caption{I quattro livelli del protocollo TPC/IP.}
375 \label{tab:net_layers}
379 Come si può notare TCP/IP è più semplice del modello ISO/OSI e strutturato in
380 soli quattro livelli. Il suo nome deriva dai due principali protocolli che lo
381 compongono, il TCP \textit{Trasmission Control Protocol} e l'IP
382 \textit{Internet Protocol}. Le funzioni dei vari livelli sono le seguenti:
385 \item \textbf{Applicazione} É relativo ai programmi di interfaccia utente, in
386 genere questi vengono realizzati secondo il modello Client-Server (vedi
387 \ref{sec:net_cliserv}.
388 \item \textbf{Trasporto} Fornisce la comunicazione tra le due stazioni
389 terminali su cui girano gli applicativi, regola il flusso delle
390 informazioni, e può fornire un trasporto affidabile, cioè con recupero
391 errori. Il protocollo principale di questo livello è il TCP.
392 \item \textbf{Rete} Si occupa dello smistamento dei singoli pacchetti su una
393 rete complessa e interconnessa, a questo stesso livello operano i protocolli
394 per il reperimento delle informazioni necessarie allo smistamento, per lo
395 scambio di messaggi di controllo e per il monitoraggio della rete. Il
396 protocollo su cui si basa questo livello è IP (sia nella attuale versione,
397 IPv4 che nella nuova IPv6).
398 \item \textbf{Connessione} È responsabile per l'interfacciamento al
399 dispositivo elettronico che effettua la comunicazione fisica, gestendo
400 l'invio e la ricezione dall'hardware dei pacchetti.
404 La comunicazione fra due stazioni avviene pertanto secondo le modalità
407 Le singole applicazioni si scambieranno i dati secondo un loro formato
408 specifico, implementando un protocollo di applicazione (esempi possono essere
409 HTTP, POP, telnet, SMTP, etc).
411 Questi dati vengono inviati al livello di trasporto usando un'interfaccia
412 opportuna (i \textit{socket}, che esamineremo in dettaglio in seguito), i
413 quali li spezzerà in pacchetti di dimensione opportuna e li incapsulerà
414 all'interno del suo protocollo di trasporto aggiungendo ad ogni pacchetto le
415 informazioni necessarie alla gestione di quest'ultimo. Questo processo viene
416 svolto dirattamente nel kernel ad esempio dallo stack TCP nel caso il
417 protocollo di trasporto sia questo.
419 Una volta composto il pacchetto nel formato adatto al protocollo di trasporto
420 usato questo sarà passato al successivo livello, quello del collegamento che
421 si occupa di inserire le opportune informazioni per poter effettuare
422 l'instradamento nella rete ed il recapito alla destinazione finale. In genere
423 questo è il livello di IP (Internet Protocol), a cui vengono inseriti i numeri
424 IP che identificano i computer su internet.
426 L'ultimo passo è il trasferimento del pacchetto al driver della interfaccia di
427 trasmissione che si incarica di incapsularlo nel relativo protocollo di
428 trasmissione fisica usato dall'hardware usato per la comunicazione (ad esempio
429 ethernet per una scheda di rete).
432 \subsection{Criteri generali del design di TCP/IP}
433 \label{sec:net_tcpip_design}
435 La filosofia architetturale di TCP/IP è semplice: costruire una rete che
436 possa sopportare il carico in transito, ma permettere ai singoli nodi di
437 scartare pacchetti se il carico è temporaneamente eccessivo, o se risultano
438 errati o non recapitabili.
440 L'incarico di rendere il recapito pacchetti affidabile non spetta allo livello
441 di collegamento, ma ai livelli superiori. Pertanto il protocollo IP è per sua
442 natura inaffidabile, in quanto non è assicurata né una percentuale di
443 successo né un limite sui tempi di consegna dei pacchetti.
445 È il livello di trasporto che si deve occupare (qualora necessiti) del
446 controllo del flusso dei dati e del recupero degli errori; questo è realizzato
447 dal protocollo TCP. La sede principale di "intelligenza" della rete è pertanto
448 al livello di trasporto o superiore.
450 Infine le singole stazioni collegate alla rete non fungono soltanto da punti
451 terminali di comunicazione, ma possono anche assumere il ruolo di router, per
452 l'interscambio di pacchetti da una rete ad un'altra. Questo rende possibile la
453 flessibilità della rete che è in grado di adattarsi ai mutamenti delle
456 La caratteristica essenziale che rende tutto ciò possibile è la strutturazione
457 a livelli tramite l'incapsulamento. Ogni pacchetto di dati viene incapsulato
458 nel formato del livello successivo, fino al livello della connessione fisica.
459 In questo modo il pacchetto ricevuto ad un livello $n$ dalla stazione di
460 destinazione è esattamente lo stesso spedito dal livello $n$ dalla sorgente.
461 Questo rende facile il progettare il software facendo riferimento unicamente a
462 quanto necessario ad un singolo livello, con la confidenza che questo poi sarà
463 trattato uniformemente da tutti i nodi della rete.
466 \section{Il protocollo TCP/IP}
467 \label{sec:net_tpcip}
469 Come già affermato il protocollo TCP/IP è un insieme di protocolli diversi,
470 che operano su 4 livelli diversi. Per gli interessi della programmazione di
471 rete però sono importanti principalmente i due livelli centrali, e soprattutto
472 quello di trasporto, su cui è innestata l'interfaccia fra kernel space e user
475 Il livello 4 infatti è normalmente gestito dal kernel, e si accede ad esso
476 solo quando si vogliono fare applicazioni di sistema per il controllo della
477 rete (locale) a basso livello, un uso quindi molto specialistico. Il livello 1
478 invece dipende dalle singole applicazioni ed è di nuovo troppo specifico per
479 essere affrontato qui.
481 In questa sezione daremo una breve descrizione dei vari protocolli di TCP/IP,
482 ma ci concentreremo principalmente sul livello di trasposto e in particolare
483 sul protocollo TCP sia per il ruolo centrale che esso svolge nella maggior
484 parte delle applciazioni, sia per la sua complessità che necessita di maggiori
487 \subsection{Il quadro generale}
489 Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da
490 altri membri. In \nfig\ si è riportato una figura di quadro che mostra un
491 panorama sull'intera famiglia, e di come i vari protocolli vengano usati dalle
494 La figura è da fare ...
496 I vari protocolli mostrati in figura sono i seguenti:
499 \item \textsl{IPv4} \textit{Internet Protocol version 4}. È quello che
500 comunemente si chiama IP. Ha origine negli anni '80 e da allora è la base su
501 cui è cotriuta internet. Usa indirizzi a 32 bit e provvede la trasmissione
502 dei pacchetti TCP, UDP, ICMP e IGMP.
503 \item \textsl{IPv6} \textit{Internet Protocol version 6}. È stato progettato a
504 metà degli anni '90 per rimpiazzare IPv4. Ha indirizzi a 128 bit e effettua
505 lo stesso servizio di trasporto di IPv4 per i pacchetti TCP, UDP e ICPMv6.
506 \item \textsl{TCP} \textit{Trasmission Control Protocol}. È un protocollo
507 orientato alla connessione che provvede un trasporto affidabile e
508 bidirezionale di un flusso di dati. I socket TCP sono esempi di
509 \textit{stream socket}. Il protocollo ha cura di tutti gli aspetti del
510 trasporto, come l'acknoweledgment, i timout, la ritrasmissione, etc. È usato
511 dalla maggior parte delle applicazioni. Può essere usato sia con IPv4 che
513 \item \textsl{UDP} \textit{User Datagram Protocol}. È un protocollo senza
514 connessione a pacchetti. I socket UDP sono esempi di \textit{datagram
515 socket}. Contrariamente al TCP in protocollo non è affidabile e non c'è
516 garanzia che i pacchetti raggiungano la loro destinazione, né sull'eventuale
517 ordine di arrivo. Può essere usato sia con IPv4 che con IPv6.
518 \item \textsl{ICMP} \textit{Internet Control Message Protocol}. Gestisce gli
519 errori e trasporta l'informazione di controllo fra stazioni remote e
520 instradatori (\textit{router} e \textit{host}). I messaggi sono normalmente
521 generati dal software del kernel che gestisce la comunicazione TCP/IP, anche
522 se può venire usato direttamente da alcuni programmi come \texttt{ping}. A
523 volte ci si riferisce ad esso come ICPMv4 per distinguerlo da ICMPv6.
524 \item \textsl{ICMP} \textit{Internet Group Management Protocol}. É un
525 protocollo usato per il \textit{multicasting} (vedi
526 \ref{sec:xxx_multicast}), che è opzionale in IPv4.
527 \item \textsl{ARP} \textit{Address Resolution Protocol}. È il protocollo che
528 mappa un indirizzo IP in un indirizzo hardware (come un indirizzo
529 internet). È usato in reti di tipo broadcast come ethernet, token ring o
530 FDDI ma non serve in connessioni punto-punto.
531 \item \textsl{RARP} \textit{Reverse Address Resolution Protocol}. È il
532 protocollo che mappa un indirizzo hardware in un indirizzo IP. Viene usato a
533 volte per durante il boot per assegnare un indirizzo IP ad una macchina.
534 \item \textsl{ICMPv6} \textit{Internet Control Message Protocol, version 6}.
535 Combina per IPv6 le funzionalità di ICMPv4, IGMP e ARP.
536 \item \textsl{NETLINK} \textit{Netlink}.
537 Provvede l'interfaccia di accesso alla comunicazione a basso livello.
540 Gran parte delle applicazioni comunicano usando TCP o UDP, ed alcune si
541 rifanno ad IP (ed i suoi correlati ICMP e IGMP); benché sia TCP che UDP siano
542 basati su IP e sia possibile intervenire a questo livello con i \textit{raw
543 socket} questa tecnica è molto meno diffusa e a parte applicazioni
544 particolari si preferisce sempre usare i servizi messi a disposizione dai due
545 protocolli precedenti. Per questo motivo a parte alcuni brevi accenni su IP
546 in questa sezione ci concentreremo sul livello di trasporto.
548 \subsection{Internet Protocol (IP)}
551 Quando si parla di IP ci si riferisce in genere alla versione attualmente in
552 uso che è la versione 4 (e viene pertanto chiamato IPv4). Questa versione
553 venne standardizzata nel 1981 dall'RFC~719.
555 Internet protocol nasce per disaccoppiare le applicazioni della struttura
556 hardware delle reti di trasmissione, e creare una interfaccia di trasmissione
557 dei dati indipendente dal sottostante substrato di rete, che può essere
558 realizzato con le tecnologie più disparate (Ethernet, Token Ring, FDDI, etc.).
559 Il compito di IP è pertanto quello di trasmettere i pacchetti da un computer
560 all'altro della rete; le caratteristiche essenziali con cui questo viene
561 realizzato in IPv4 sono due:
564 \item \textit{Universal addressing} la comunicazione avviene fra due host
565 identificati univocamente con un indirizzo a 32 bit che può appartenere ad
566 una sola interfaccia di rete.
567 \item \textit{Best effort} viene assicurato il massimo impegno nella
568 trasmissione, ma non c'è nessuna garanzia per i livelli superiori né sulla
569 percentuale di successo né sul tempo di consegna dei pacchetti di dati.
572 Negli anni '90 la crescita vertiginosa del numero di macchine connesse a
573 internet ha iniziato a far emergere i vari limiti di IPv4, per risolverne i
574 problemi si è perciò definita una nuova versione del protocollo, che (saltando
575 un numero) è diventata la versione 6. IPv6 nasce quindi come evoluzione di
576 IPv4, mantendone inalterate le funzioni che si sono dimostrate valide,
577 eliminando quelle inutili e aggiungendone poche altre per mantenere il
578 protocollo il più snello e veloce possibile.
580 I cambiamenti apportati sono comunque notevoli e si possono essere riassunti a
581 grandi linee nei seguenti punti:
583 \item l'espansione delle capacità di indirizzamento e instradamento, per
584 supportare una gerarchia con più livelli di indirizzamento, un numero di
585 nodi indirizzabili molto maggiore e una autoconfigurazione degli indirizzi
586 \item l'introduzione un nuovo tipo di indirizzamento, l'\textit{anycast} che
587 si aggiungono agli usuali \textit{unycast} e \textit{multicast}
588 \item la semplificazione del formato della testata, eliminando o rendendo
589 opzionali alcuni dei campi di IPv4, per eliminare la necessità di
590 riprocessamento della stessa da parte dei router e contenere l'aumento di
591 dimensione dovuto ai nuovi indirizzi
592 \item un supporto per le opzioni migliorato, per garantire una trasmissione
593 più efficiente del traffico normale, limiti meno stringenti sulle dimensioni
594 delle opzioni, e la flessibilità necessaria per introdurne di nuove in
596 \item il supporto per delle capacità di qualità di servizio (QoS) che permetta
597 di identificare gruppi di dati per i quali si può provvedere un trattamento
598 speciale (in vista dell'uso di internet per applicazioni multimediali e/o
602 Per maggiori dettagli riguardo al protocollo si può consultare
606 \subsection{UDP: User Datagram Protocol)}
609 UDP è un protocollo di trasporto molto semplice, la sua descizione completa è
610 contenuta dell'RFC~768, ma in sostanza esso è una semplice interfaccia a IP dal
611 livello di trasporto. Quando un'applicazione usa UDP essa scrive un pacchetto
612 di dati (il cosiddetto \textit{datagram} che da il nome al protocollo) su un
613 socket, al pacchetto viene aggiunto un header molto semplice (per una
614 descrizione più accurata vedi \ref{sec:appA_udp}), e poi viene passato al
615 livello superiore (IPv4 o IPv6 che sia) che lo spedisce verso la destinazione.
616 Dato che né IPv4 né IPv6 garantiscono l'affidabilità niente assicura che il
617 pacchetto arrivi a destinazione, né che più pacchetti arrivino nello stesso
618 ordine in cui sono stati spediti.
620 Pertanto il problema principale che si affronta quando si usa UDP è la
621 mancanza di affidabilità, se si vuole essere sicuri che i pacchetti arrivino a
622 destinazione occorrerà provvedere con l'applicazione all'interno della quale
623 si dovrà inserire tutto quanto necessario a gestire la notifica di
624 ricevimento, la ritrasmissione, il timeout.
626 Si tenga conto poi che in UDP niente garantisce che i pacchetti arrivino nello
627 stesso ordine in cui sono stati trasmessi, e può anche accadere che i
628 pacchetti vengano duplicati nella trasmissione, e non solo perduti. Di tutto
629 questo di nuovo deve tenere conto l'applicazione.
631 Un'altro aspetto di UDP è che se un pacchetto raggiunge correttamente la
632 destinazione esso viene passato all'applicazione ricevente in tutta la sua
633 lunghezza, la trasmissione avviene perciò per \textit{record} la cui lunghezza
634 viene anche essa trasmessa all'applicazione all'atto del ricevimento.
636 Infine UDP è un protocollo che opera senza connessione
637 (\textit{connectionless}) in quanto non è necessario stabilire nessun tipo di
638 relazione tra origine e destinazione dei pacchetti. Si hanno così situazioni
639 in cui un client può scrivere su uno stesso socket pacchetti destinati a
640 server diversi, o un server ricevere su un socket paccetti provenienti da
641 client diversi. Il modo più semplice di immaginarsi il funzionamento di UDP è
642 quello della radio, in cui si può ``trasmettere a'' e ``ricevere da'' più
643 stazioni usando la stessa frequenza.
645 Nonostante gli evidenti svantaggi comportati dall'inaffidabilità UDP ha il
646 grande pregio della velocità che in certi casi è essenziale; inoltre si presta
647 bene per le applicazioni in cui la connessione non è necessaria e
648 costituirebbe solo un peso di prestazioni mentre una perdita di pacchetti può
649 essere tollerata, come quelle che usano il multicasting.
651 \subsection{TCP: Transport Control Protocol)}
654 Il TCP è un protocollo molto complesso, definito nell'RFC~739 e completamente
655 diverso da UDP; alla base del suo design infatti non stanno semplicità e
656 velocità, ma la ricerca della massima affidabilità possibile nella
657 trasmissione dei dati.
659 La prima differenza con UDP è che TCP provvede sempre una conessione diretta
660 fra un client e un server, attraverso la quale essi possono comunicare; per
661 questo il paragone più appropriato per questo protocollo è quello del
662 collegamento telefonico, in quanto prima viene stabilita una connessione fra
663 due stazioni su cui poi viene effettuata una comunicazione diretta.
665 Caratteristica fondamentale di TCP è l'affidabilità; quando i dati vengono
666 inviati attraverso una connessione ne viene richiesto un ``ricevuto''
667 (il cosiddetto \textit{acknowlegment}), se questo non arriva essi verranno
668 ritrasmessi facendo un determinato numero di tentativi intervallati da un
669 periodo di tempo crescente, fintanto che la connessione sarà considerata
670 fallita o caduta la connessione (con un errore di \textit{time-out}), dopo un
671 periodo di tempo che dipende dall'implementazione e che può variare far i
672 quattro e i dieci minuti.
674 Inoltre per tenere conto delle diverse condizioni in cui può trovarsi la linea
675 di comunicazione TCP comprende anche un algoritmo di calcolo dinamico del
676 tempo di andata e ritorno dei pacchetti (il cosiddetto RTT,
677 \textit{round-trip time}) fra un client e un server che lo rende in grado di
678 adattarsi alle condizioni della rete per non generare inutili ritrasmissioni o
679 cadere facilmente in timeout.
681 Inoltre TCP è in grado di preservare l'ordine dei dati assegnando un numero di
682 sequenza ad ogni byte che trasmette. Ad esempio se un'applicazione scrive 3000
683 bytes su un socket TCP, questi potranno essere spezzati dal protocollo in due
684 segmenti (le unità di dati passate da TCP a IP vengono chiamate
685 \textit{segment}) di 1500 bytes, di cui il primo conterrà il numero di
686 sequenza $1-1500$ e il secondo il numero $1501-3000$. In questo modo anche se
687 i segmenti arrivano a destinazione in un ordine diverso, o se alcuni arrivano
688 più volte a causa di ritrasmissioni dovute alla perdita dei ricevuto,
689 all'arrivo sarà comunque possibile riordinare i dati e scartare i duplicati.
691 Il protocollo provvede anche un controllo di flusso (\textit{flow control}),
692 cioè specifica sempre all'altro capo della trasmissione quanti dati può
693 ricevere tramite una \textit{advertised window} (letteralmente finestra
694 annunciata), che indica lo spazio disponibile nel buffer di ricezione,
695 cosicchè nella trasmissione non vengano inviati più dati di quelli che possono
698 Questa finestra cambia dinamicamente diminuendo con la ricezione dei dati dal
699 socket ed aumentando con la lettura di quest'ultimo da parte
700 dell'applicazione, se diventa nulla il buffer di ricezione è pieno e non
701 verranno accettati altri dati. Si noti che UDP non provvede niente di tutto
702 ciò per cui nulla impedisce che vengano trasmessi pacchetti ad un rate che il
703 ricevitore non può sostenere.
705 Infine attraverso TCP la trasmissione è sempre bidirezionale (in inglese
706 \textit{full-duplex}), è cioè possibile sia trasmettere che ricevere allo
707 stesso tempo, il che poi comporta che quanto dicevamo a proposito del
708 controllo di flusso e della gestione della sequenzialità dei dati viene
709 effettuato per entrambe le direzioni di comunicazione.
713 \subsection{Creazione e terminazione della connessione TCP}
715 Per capire il funzionamento delle funzioni della interfaccia dei socket che
716 operano con TCP (come \texttt{connect}, \texttt{accept} e \texttt{close} che
717 vedremo più avanti) è fodamentale capire come funziona la creazione e la
718 conclusione di una connessione TCP.
723 \subsection{Le porte}