3 %% Copyright (C) 2000-2011 Simone Piccardi. Permission is granted to
4 %% copy, distribute and/or modify this document under the terms of the GNU Free
5 %% Documentation License, Version 1.1 or any later version published by the
6 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",
7 %% with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the
8 %% license is included in the section entitled "GNU Free Documentation
12 \chapter{Introduzione alla programmazione di rete}
15 In questo capitolo sarà fatta un'introduzione ai concetti generali che servono
16 come prerequisiti per capire la programmazione di rete, non tratteremo quindi
17 aspetti specifici ma faremo una breve introduzione al modello più comune usato
18 nella programmazione di rete, per poi passare ad un esame a grandi linee dei
19 protocolli di rete e di come questi sono organizzati e interagiscono.
21 In particolare, avendo assunto l'ottica di un'introduzione mirata alla
22 programmazione, ci concentreremo sul protocollo più diffuso, il TCP/IP, che è
23 quello che sta alla base di internet, avendo cura di sottolineare i concetti
24 più importanti da conoscere per la scrittura dei programmi.
28 \section{Modelli di programmazione}
29 \label{sec:net_prog_model}
32 La differenza principale fra un'applicazione di rete e un programma normale è
33 che quest'ultima per definizione concerne la comunicazione fra processi
34 diversi, che in generale non girano neanche sulla stessa macchina. Questo già
35 prefigura un cambiamento completo rispetto all'ottica del programma monolitico
36 all'interno del quale vengono eseguite tutte le istruzioni, e chiaramente
37 presuppone un sistema operativo multitasking in grado di eseguire più processi
40 In questa prima sezione esamineremo brevemente i principali modelli di
41 programmazione in uso. Ne daremo una descrizione assolutamente generica e
42 superficiale, che ne illustri le caratteristiche principali, non essendo fra
43 gli scopi del testo approfondire questi argomenti.
45 \subsection{Il modello \textit{client-server}}
46 \label{sec:net_cliserv}
48 L'architettura fondamentale su cui si basa gran parte della programmazione di
49 rete sotto Linux (e sotto Unix in generale) è il modello
50 \textit{client-server} caratterizzato dalla presenza di due categorie di
51 soggetti, i programmi di servizio, chiamati \textit{server}, che ricevono le
52 richieste e forniscono le risposte, ed i programmi di utilizzo, detti
55 In generale un server può (di norma deve) essere in grado di rispondere a più
56 di un client, per cui è possibile che molti programmi possano interagire
57 contemporaneamente, quello che contraddistingue il modello però è che
58 l'architettura dell'interazione è sempre nei termini di molti verso uno, il
59 server, che viene ad assumere un ruolo privilegiato.
61 Seguono questo modello tutti i servizi fondamentali di internet, come le
62 pagine web, la posta elettronica, ftp, telnet, ssh e praticamente ogni
63 servizio che viene fornito tramite la rete, anche se, come abbiamo visto, il
64 modello è utilizzato in generale anche per programmi che, come gli esempi che
65 abbiamo usato in cap.~\ref{cha:IPC} a proposito della comunicazione fra
66 processi nello stesso sistema, non fanno necessariamente uso della rete.
68 Normalmente si dividono i server in due categorie principali, e vengono detti
69 \textsl{concorrenti} o \textsl{iterativi}, sulla base del loro comportamento.
70 Un \textsl{server iterativo} risponde alla richiesta inviando i dati e resta
71 occupato e non rispondendo ad ulteriori richieste fintanto che non ha fornito
72 una risposta alla richiesta. Una volta completata la risposta il server
73 diventa di nuovo disponibile.
75 Un \textsl{server concorrente} al momento di trattare la richiesta crea un
76 processo figlio (o un \itindex{thread} \textit{thread}) incaricato di fornire
77 i servizi richiesti, per porsi immediatamente in attesa di ulteriori
78 richieste. In questo modo, con sistemi multitasking, più richieste possono
79 essere soddisfatte contemporaneamente. Una volta che il processo figlio ha
80 concluso il suo lavoro esso di norma viene terminato, mentre il server
81 originale resta sempre attivo.
84 \subsection{Il modello \textit{peer-to-peer}}
85 \label{sec:net_peertopeer}
87 Come abbiamo visto il tratto saliente dell'architettura \textit{client-server}
88 è quello della preminenza del server rispetto ai client, le architetture
89 \textit{peer-to-peer} si basano su un approccio completamente opposto che è
90 quello di non avere nessun programma che svolga un ruolo preminente.
92 Questo vuol dire che in generale ciascun programma viene ad agire come un nodo
93 in una rete potenzialmente paritetica; ciascun programma si trova pertanto a
94 ricevere ed inviare richieste ed a ricevere ed inviare risposte, e non c'è più
95 la separazione netta dei compiti che si ritrova nelle architetture
96 \textit{client-server}.
98 Le architetture \textit{peer-to-peer} sono salite alla ribalta con
99 l'esplosione del fenomeno Napster, ma gli stessi protocolli di routing sono un
100 buon esempio di architetture \textit{peer-to-peer}, in cui ciascun nodo,
101 tramite il demone che gestisce il routing, richiede ed invia informazioni ad
104 In realtà in molti casi di architetture classificate come \textit{peer-to-peer}
105 non è detto che la struttura sia totalmente paritetica e ci sono parecchi
106 esempi in cui alcuni servizi vengono centralizzati o distribuiti
107 gerarchicamente, come per lo stesso Napster, in cui le ricerche venivano
108 effettuate su un server centrale.
112 \subsection{Il modello \textit{three-tier}}
113 \label{sec:net_three_tier}
115 Benché qui sia trattato a parte, il modello \textit{three-tier} in realtà è
116 una estensione del modello \textit{client-server}. Con il crescere della
117 quantità dei servizi forniti in rete (in particolare su internet) ed al numero
118 di accessi richiesto. Si è così assistito anche ad una notevole crescita di
119 complessità, in cui diversi servizi venivano ad essere integrati fra di loro.
121 In particolare sempre più spesso si assiste ad una integrazione di servizi di
122 database con servizi di web, in cui le pagine vengono costruite dinamicamente
123 sulla base dei dati contenuti nel database. In tutti questi casi il problema
124 fondamentale di una architettura \textit{client-server} è che la richiesta di
125 un servizio da parte di un gran numero di client si scontra con il collo di
126 bottiglia dell'accesso diretto ad un unico server, con gravi problemi di
129 Rispondere a queste esigenze di scalabilità il modello più semplice (chiamato
130 talvolta \textit{two-tier}) da adottare è stata quello di distribuire il
131 carico delle richieste su più server identici, mantenendo quindi
132 sostanzialmente inalterata l'architettura \textit{client-server} originale.
134 Nel far questo ci si scontra però con gravi problemi di manutenibilità dei
135 servizi, in particolare per quanto riguarda la sincronizzazione dei dati, e di
136 inefficienza dell'uso delle risorse. Il problema è particolarmente grave ad
137 esempio per i database che non possono essere replicati e sincronizzati
138 facilmente, e che sono molto onerosi, la loro replicazione è costosa e
141 È a partire da queste problematiche che nasce il modello \textit{three-tier},
142 che si struttura, come dice il nome, su tre livelli. Il primo livello, quello
143 dei client che eseguono le richieste e gestiscono l'interfaccia con l'utente,
144 resta sostanzialmente lo stesso del modello \textit{client-server}, ma la
145 parte server viene suddivisa in due livelli, introducendo un
146 \textit{middle-tier}, su cui deve appoggiarsi tutta la logica di analisi delle
147 richieste dei client per ottimizzare l'accesso al terzo livello, che è quello
148 che si limita a fornire i dati dinamici che verranno usati dalla logica
149 implementata nel \textit{middle-tier} per eseguire le operazioni richieste dai
152 In questo modo si può disaccoppiare la logica dai dati, replicando la prima,
153 che è molto meno soggetta a cambiamenti ed evoluzione, e non soffre di
154 problemi di sincronizzazione, e centralizzando opportunamente i secondi. In
155 questo modo si può distribuire il carico ed accedere in maniera efficiente i
159 \section{I protocolli di rete}
160 \label{sec:net_protocols}
162 Parlando di reti di computer si parla in genere di un insieme molto vasto ed
163 eterogeneo di mezzi di comunicazione che vanno dal cavo telefonico, alla fibra
164 ottica, alle comunicazioni via satellite o via radio; per rendere possibile la
165 comunicazione attraverso un così variegato insieme di mezzi sono stati
166 adottati una serie di protocolli, il più famoso dei quali, quello alla base
167 del funzionamento di internet, è il protocollo TCP/IP.
169 \subsection{Il modello ISO/OSI}
170 \label{sec:net_iso_osi}
172 Una caratteristica comune dei protocolli di rete è il loro essere strutturati
173 in livelli sovrapposti; in questo modo ogni protocollo di un certo livello
174 realizza le sue funzionalità basandosi su un protocollo del livello
175 sottostante. Questo modello di funzionamento è stato standardizzato dalla
176 \textit{International Standards Organization} (ISO) che ha preparato fin dal
177 1984 il Modello di Riferimento \textit{Open Systems Interconnection} (OSI),
178 strutturato in sette livelli, secondo quanto riportato in
179 tab.~\ref{tab:net_osilayers}.
183 \begin{tabular}{|l|c|c|}
185 \textbf{Livello} & \multicolumn{2}{|c|}{\textbf{Nome}} \\
188 Livello 7&\textit{Application} &\textsl{Applicazione}\\
189 Livello 6&\textit{Presentation} &\textsl{Presentazione} \\
190 Livello 5&\textit{Session} &\textsl{Sessione} \\
191 Livello 4&\textit{Transport} &\textsl{Trasporto} \\
192 Livello 3&\textit{Network} &\textsl{Rete}\\
193 Livello 2&\textit{DataLink} &\textsl{Collegamento Dati} \\
194 Livello 1&\textit{Physical} &\textsl{Connessione Fisica} \\
197 \caption{I sette livelli del protocollo ISO/OSI.}
198 \label{tab:net_osilayers}
201 Il modello ISO/OSI è stato sviluppato in corrispondenza alla definizione della
202 serie di protocolli X.25 per la commutazione di pacchetto; come si vede è un
203 modello abbastanza complesso\footnote{infatti per memorizzarne i vari livelli
204 è stata creata la frase \textit{All people seem to need data processing}, in
205 cui ciascuna parola corrisponde all'iniziale di uno dei livelli.}, tanto che
206 usualmente si tende a suddividerlo in due parti, secondo lo schema mostrato in
207 fig.~\ref{fig:net_osi_tcpip_comp}, con un \textit{upper layer} che riguarda
208 solo le applicazioni, che viene realizzato in user space, ed un \textit{lower
209 layer} in cui si mescolano la gestione fatta dal kernel e le funzionalità
210 fornite dall'hardware.
212 Il modello ISO/OSI mira ad effettuare una classificazione completamente
213 generale di ogni tipo di protocollo di rete; nel frattempo però era stato
214 sviluppato anche un altro modello, relativo al protocollo TCP/IP, che è quello
215 su cui è basata internet, che è diventato uno standard de facto. Questo
216 modello viene talvolta chiamato anche modello \textit{DoD} (sigla che sta per
217 \textit{Department of Defense}), dato che fu sviluppato dall'agenzia ARPA per
218 il Dipartimento della Difesa Americano.
222 \includegraphics[width=13cm]{img/iso_tcp_comp}
223 \caption{Struttura a livelli dei protocolli OSI e TCP/IP, con la
224 relative corrispondenze e la divisione fra kernel e user space.}
225 \label{fig:net_osi_tcpip_comp}
228 La scelta fra quale dei due modelli utilizzare dipende per lo più dai gusti
229 personali. Come caratteristiche generali il modello ISO/OSI è più teorico e
230 generico, basato separazioni funzionali, mentre il modello TCP/IP è più vicino
231 alla separazione concreta dei vari strati del sistema operativo; useremo
232 pertanto quest'ultimo, anche per la sua maggiore semplicità.\footnote{questa
233 semplicità ha un costo quando si fa riferimento agli strati più bassi, che
234 sono in effetti descritti meglio dal modello ISO/OSI, in quanto gran parte
235 dei protocolli di trasmissione hardware sono appunto strutturati sui due
236 livelli di \textit{Data Link} e \textit{Connection}.}
238 \subsection{Il modello TCP/IP (o DoD)}
239 \label{sec:net_tcpip_overview}
241 Così come ISO/OSI anche il modello del TCP/IP è stato strutturato in livelli
242 (riassunti in tab.~\ref{tab:net_layers}); un confronto fra i due è riportato
243 in fig.~\ref{fig:net_osi_tcpip_comp} dove viene evidenziata anche la
244 corrispondenza fra i rispettivi livelli (che comunque è approssimativa) e su
245 come essi vanno ad inserirsi all'interno del sistema rispetto alla divisione
246 fra user space e kernel space spiegata in
247 sez.~\ref{sec:intro_unix_struct}.\footnote{in realtà è sempre possibile
248 accedere dallo user space, attraverso una opportuna interfaccia (come
249 vedremo in sez.~\ref{sec:sock_sa_packet}), ai livelli inferiori del
254 \begin{tabular}{|l|c|c|l|}
256 \textbf{Livello} & \multicolumn{2}{|c|}{\textbf{Nome}} & \textbf{Esempi} \\
259 Livello 4 & \textit{Application} & \textsl{Applicazione}&
261 Livello 3 & \textit{Transport} & \textsl{Trasporto} & TCP, UDP\\
262 Livello 2 & \textit{Network} & \textsl{Rete} & IP, (ICMP, IGMP)\\
263 Livello 1 & \textit{Link} & \textsl{Collegamento}&
264 Device driver \& scheda di interfaccia\\
267 \caption{I quattro livelli del protocollo TCP/IP.}
268 \label{tab:net_layers}
271 Come si può notare come il modello TCP/IP è più semplice del modello ISO/OSI
272 ed è strutturato in soli quattro livelli. Il suo nome deriva dai due
273 principali protocolli che lo compongono, il TCP (\textit{Trasmission Control
274 Protocol}) che copre il livello 3 e l'IP (\textit{Internet Protocol}) che
275 copre il livello 2. Le funzioni dei vari livelli sono le seguenti:
277 \begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
278 \item[\textbf{Applicazione}] É relativo ai programmi di interfaccia con la
279 rete, in genere questi vengono realizzati secondo il modello client-server
280 (vedi sez.~\ref{sec:net_cliserv}), realizzando una comunicazione secondo un
281 protocollo che è specifico di ciascuna applicazione.
282 \item[\textbf{Trasporto}] Fornisce la comunicazione tra le due stazioni
283 terminali su cui girano gli applicativi, regola il flusso delle
284 informazioni, può fornire un trasporto affidabile, cioè con recupero degli
285 errori o inaffidabile. I protocolli principali di questo livello sono il TCP
287 \item[\textbf{Rete}] Si occupa dello smistamento dei singoli pacchetti su una
288 rete complessa e interconnessa, a questo stesso livello operano i protocolli
289 per il reperimento delle informazioni necessarie allo smistamento, per lo
290 scambio di messaggi di controllo e per il monitoraggio della rete. Il
291 protocollo su cui si basa questo livello è IP (sia nella attuale versione,
292 IPv4, che nella nuova versione, IPv6).
293 \item[\textbf{Collegamento}] È responsabile per l'interfacciamento al
294 dispositivo elettronico che effettua la comunicazione fisica, gestendo
295 l'invio e la ricezione dei pacchetti da e verso l'hardware.
298 La comunicazione fra due stazioni remote avviene secondo le modalità
299 illustrate in fig.~\ref{fig:net_tcpip_data_flux}, dove si è riportato il flusso
300 dei dati reali e i protocolli usati per lo scambio di informazione su ciascun
301 livello. Si è genericamente indicato \textit{ethernet} per il livello 1, anche
302 se in realtà i protocolli di trasmissione usati possono essere molti altri.
305 \centering \includegraphics[width=13cm]{img/tcp_data_flux}
306 \caption{Strutturazione del flusso dei dati nella comunicazione fra due
307 applicazioni attraverso i protocolli della suite TCP/IP.}
308 \label{fig:net_tcpip_data_flux}
311 Per chiarire meglio la struttura della comunicazione attraverso i vari
312 protocolli mostrata in fig.~\ref{fig:net_tcpip_data_flux}, conviene prendere in
313 esame i singoli passaggi fatti per passare da un livello al sottostante,
314 la procedura si può riassumere nei seguenti passi:
316 \item Le singole applicazioni comunicano scambiandosi i dati ciascuna secondo
317 un suo specifico formato. Per applicazioni generiche, come la posta o le
318 pagine web, viene di solito definito ed implementato quello che viene
319 chiamato un protocollo di applicazione (esempi possono essere HTTP, POP,
320 SMTP, ecc.), ciascuno dei quali è descritto in un opportuno standard (di
321 solito attraverso un RFC\footnote{l'acronimo RFC sta per \textit{Request For
322 Comment} ed è la procedura attraverso la quale vengono proposti gli
323 standard per Internet.}).
324 \item I dati delle applicazioni vengono inviati al livello di trasporto usando
325 un'interfaccia opportuna (i \textit{socket}, che esamineremo in dettaglio in
326 cap.~\ref{cha:socket_intro}). Qui verranno spezzati in pacchetti di
327 dimensione opportuna e inseriti nel protocollo di trasporto, aggiungendo ad
328 ogni pacchetto le informazioni necessarie per la sua gestione. Questo
329 processo viene svolto direttamente nel kernel, ad esempio dallo stack TCP,
330 nel caso il protocollo di trasporto usato sia questo.
331 \item Una volta composto il pacchetto nel formato adatto al protocollo di
332 trasporto usato questo sarà passato al successivo livello, quello di rete,
333 che si occupa di inserire le opportune informazioni per poter effettuare
334 l'instradamento nella rete ed il recapito alla destinazione finale. In
335 genere questo è il livello di IP (Internet Protocol), a cui vengono inseriti
336 i numeri IP che identificano i computer su internet.
337 \item L'ultimo passo è il trasferimento del pacchetto al driver della
338 interfaccia di trasmissione, che si incarica di incapsularlo nel relativo
339 protocollo di trasmissione. Questo può avvenire sia in maniera diretta, come
340 nel caso di ethernet, in cui i pacchetti vengono inviati sulla linea
341 attraverso le schede di rete, che in maniera indiretta con protocolli come
342 PPP o SLIP, che vengono usati come interfaccia per far passare i dati su
343 altri dispositivi di comunicazione (come la seriale o la parallela).
347 \subsection{Criteri generali dell'architettura del TCP/IP}
348 \label{sec:net_tcpip_design}
350 La filosofia architetturale del TCP/IP è semplice: costruire una rete che
351 possa sopportare il carico in transito, ma permettere ai singoli nodi di
352 scartare pacchetti se il carico è temporaneamente eccessivo, o se risultano
353 errati o non recapitabili.
355 L'incarico di rendere il recapito pacchetti affidabile non spetta al livello
356 di rete, ma ai livelli superiori. Pertanto il protocollo IP è per sua natura
357 inaffidabile, in quanto non è assicurata né una percentuale di successo né un
358 limite sui tempi di consegna dei pacchetti.
360 È il livello di trasporto che si deve occupare (qualora necessiti) del
361 controllo del flusso dei dati e del recupero degli errori; questo è realizzato
362 dal protocollo TCP. La sede principale di "\textit{intelligenza}" della rete è
363 pertanto al livello di trasporto o ai livelli superiori.
365 Infine le singole stazioni collegate alla rete non fungono soltanto da punti
366 terminali di comunicazione, ma possono anche assumere il ruolo di
367 \textit{router} (\textsl{instradatori}), per l'interscambio di pacchetti da
368 una rete ad un'altra. Questo rende possibile la flessibilità della rete che è
369 in grado di adattarsi ai mutamenti delle interconnessioni.
371 La caratteristica essenziale che rende tutto ciò possibile è la strutturazione
372 a livelli tramite l'incapsulamento. Ogni pacchetto di dati viene incapsulato
373 nel formato del livello successivo, fino al livello del collegamento fisico.
374 In questo modo il pacchetto ricevuto ad un livello \textit{n} dalla stazione
375 di destinazione è esattamente lo stesso spedito dal livello \textit{n} dalla
376 sorgente. Questo rende facile il progettare il software facendo riferimento
377 unicamente a quanto necessario ad un singolo livello, con la confidenza che
378 questo poi sarà trattato uniformemente da tutti i nodi della rete.
381 \section{Il protocollo TCP/IP}
382 \label{sec:net_tpcip}
384 Come accennato in sez.~\ref{sec:net_protocols} il protocollo TCP/IP è un
385 insieme di protocolli diversi, che operano su 4 livelli diversi. Per gli
386 interessi della programmazione di rete però sono importanti principalmente i
387 due livelli centrali, e soprattutto quello di trasporto.
389 La principale interfaccia usata nella programmazione di rete, quella dei
390 socket (vedi sez.~\ref{cha:socket_intro}), è infatti un'interfaccia nei
391 confronti di quest'ultimo. Questo avviene perché al di sopra del livello di
392 trasporto i programmi hanno a che fare solo con dettagli specifici delle
393 applicazioni, mentre al di sotto vengono curati tutti i dettagli relativi alla
394 comunicazione. È pertanto naturale definire una interfaccia di programmazione
395 su questo confine, tanto più che è proprio lì (come evidenziato in
396 fig.~\ref{fig:net_osi_tcpip_comp}) che nei sistemi Unix (e non solo) viene
397 inserita la divisione fra kernel space e user space.
399 In realtà in un sistema Unix è possibile accedere anche agli altri livelli
400 inferiori (e non solo a quello di trasporto) con opportune interfacce di
401 programmazione (vedi sez.~\ref{sec:sock_sa_packet}), ma queste vengono usate
402 solo quando si debbano fare applicazioni di sistema per il controllo della
403 rete a basso livello, di uso quindi molto specialistico.
405 In questa sezione daremo una descrizione sommaria dei vari protocolli del
406 TCP/IP, concentrandoci, per le ragioni appena esposte, sul livello di
407 trasporto. All'interno di quest'ultimo privilegeremo poi il protocollo TCP,
408 per il ruolo centrale che svolge nella maggior parte delle applicazioni.
411 \subsection{Il quadro generale}
412 \label{sec:net_tcpip_general}
414 Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da
415 molti membri. In fig.~\ref{fig:net_tcpip_overview} si è riportato uno schema
416 che mostra un panorama sui principali protocolli della famiglia, e delle loro
417 relazioni reciproche e con alcune dalle principali applicazioni che li usano.
419 \begin{figure}[!htbp]
421 \includegraphics[width=13cm]{img/tcpip_overview}
422 \caption{Panoramica sui vari protocolli che compongono la suite TCP/IP.}
423 \label{fig:net_tcpip_overview}
426 I vari protocolli riportati in fig.~\ref{fig:net_tcpip_overview} sono i
428 \begin{basedescript}{\desclabelwidth{1.7cm}\desclabelstyle{\nextlinelabel}}
429 \item[\textsl{IPv4}] \textit{Internet Protocol version 4}. È quello che
430 comunemente si chiama IP. Ha origine negli anni '80 e da allora è la base su
431 cui è costruita internet. Usa indirizzi a 32 bit, e mantiene tutte le
432 informazioni di instradamento e controllo per la trasmissione dei pacchetti
433 sulla rete; tutti gli altri protocolli della suite (eccetto ARP e RARP, e
434 quelli specifici di IPv6) vengono trasmessi attraverso di esso.
435 \item[\textsl{IPv6}] \textit{Internet Protocol version 6}. È stato progettato
436 a metà degli anni '90 per rimpiazzare IPv4. Ha uno spazio di indirizzi
437 ampliato 128 bit che consente più gerarchie di indirizzi,
438 l'auto-configurazione, ed un nuovo tipo di indirizzi, gli \textit{anycast},
439 che consentono di inviare un pacchetto ad una stazione su un certo gruppo.
440 Effettua lo stesso servizio di trasmissione dei pacchetti di IPv4 di cui
441 vuole essere un sostituto.
442 \item[\textsl{TCP}] \textit{Trasmission Control Protocol}. È un protocollo
443 orientato alla connessione che provvede un trasporto affidabile per un
444 flusso di dati bidirezionale fra due stazioni remote. Il protocollo ha cura
445 di tutti gli aspetti del trasporto, come l'acknoweledgment, i timeout, la
446 ritrasmissione, ecc. È usato dalla maggior parte delle applicazioni.
447 \item[\textsl{UDP}] \textit{User Datagram Protocol}. È un protocollo senza
448 connessione, per l'invio di dati a pacchetti. Contrariamente al TCP il
449 protocollo non è affidabile e non c'è garanzia che i pacchetti raggiungano
450 la loro destinazione, si perdano, vengano duplicati, o abbiano un
451 particolare ordine di arrivo.
452 \item[\textsl{ICMP}] \textit{Internet Control Message Protocol}. È il
453 protocollo usato a livello 2 per gestire gli errori e trasportare le
454 informazioni di controllo fra stazioni remote e instradatori (cioè fra
455 \textit{host} e \textit{router}). I messaggi sono normalmente generati dal
456 software del kernel che gestisce la comunicazione TCP/IP, anche se ICMP può
457 venire usato direttamente da alcuni programmi come \cmd{ping}. A volte ci
458 si riferisce ad esso come ICPMv4 per distinguerlo da ICMPv6.
459 \item[\textsl{IGMP}] \textit{Internet Group Management Protocol}. É un
460 protocollo di livello 2 usato per il \itindex{multicast}
461 \textit{multicast} (vedi sez.~\ref{sec:xxx_multicast}). Permette
462 alle stazioni remote di notificare ai router che supportano questa
463 comunicazione a quale gruppo esse appartengono. Come ICMP viene
464 implementato direttamente sopra IP.
465 \item[\textsl{ARP}] \textit{Address Resolution Protocol}. È il protocollo che
466 mappa un indirizzo IP in un indirizzo hardware sulla rete locale. È usato in
467 reti di tipo \itindex{broadcast} \textit{broadcast} come Ethernet, Token
468 Ring o FDDI che hanno associato un indirizzo fisico (il \textit{MAC
469 address}) alla interfaccia, ma non serve in connessioni punto-punto.
470 \item[\textsl{RARP}] \textit{Reverse Address Resolution Protocol}. È il
471 protocollo che esegue l'operazione inversa rispetto ad ARP (da cui il nome)
472 mappando un indirizzo hardware in un indirizzo IP. Viene usato a volte per
473 durante l'avvio per assegnare un indirizzo IP ad una macchina.
474 \item[\textsl{ICMPv6}] \textit{Internet Control Message Protocol, version 6}.
475 Combina per IPv6 le funzionalità di ICMPv4, IGMP e ARP.
476 \item[\textsl{EGP}] \textit{Exterior Gateway Protocol}. È un protocollo di
477 routing usato per comunicare lo stato fra gateway vicini a livello di
478 \textsl{sistemi autonomi}\footnote{vengono chiamati \textit{autonomous
479 systems} i raggruppamenti al livello più alto della rete.}, con
480 meccanismi che permettono di identificare i vicini, controllarne la
481 raggiungibilità e scambiare informazioni sullo stato della rete. Viene
482 implementato direttamente sopra IP.
483 \item[\textsl{OSPF}] \textit{Open Shortest Path First}. È in protocollo di
484 routing per router su reti interne, che permette a questi ultimi di
485 scambiarsi informazioni sullo stato delle connessioni e dei legami che
486 ciascuno ha con gli altri. Viene implementato direttamente sopra IP.
487 \item[\textsl{GRE}] \textit{Generic Routing Encapsulation}. È un protocollo
488 generico di incapsulamento che permette di incapsulare un qualunque altro
489 protocollo all'interno di IP.
490 \item[\textsl{AH}] \textit{Authentication Header}. Provvede l'autenticazione
491 dell'integrità e dell'origine di un pacchetto. È una opzione nativa in IPv6
492 e viene implementato come protocollo a sé su IPv4. Fa parte della suite di
493 IPSEC che provvede la trasmissione cifrata ed autenticata a livello IP.
494 \item[\textsl{ESP}] \textit{Encapsulating Security Payload}. Provvede la
495 cifratura insieme all'autenticazione dell'integrità e dell'origine di un
496 pacchetto. Come per AH è opzione nativa in IPv6 e viene implementato come
497 protocollo a sé su IPv4.
498 \item[\textsl{PPP}] \textit{Point-to-Point Protocol}. È un protocollo a
499 livello 1 progettato per lo scambio di pacchetti su connessioni punto punto.
500 Viene usato per configurare i collegamenti, definire i protocolli di rete
501 usati ed incapsulare i pacchetti di dati. È un protocollo complesso con
503 \item[\textsl{SLIP}] \textit{Serial Line over IP}. È un protocollo di livello
504 1 che permette di trasmettere un pacchetto IP attraverso una linea seriale.
507 Gran parte delle applicazioni comunicano usando TCP o UDP, solo alcune, e per
508 scopi particolari si rifanno direttamente ad IP (ed i suoi correlati ICMP e
509 IGMP); benché sia TCP che UDP siano basati su IP e sia possibile intervenire a
510 questo livello con i \textit{raw socket} questa tecnica è molto meno diffusa e
511 a parte applicazioni particolari si preferisce sempre usare i servizi messi a
512 disposizione dai due protocolli precedenti. Per questo, motivo a parte alcuni
513 brevi accenni su IP in questa sezione, ci concentreremo sul livello di
516 \subsection{Internet Protocol (IP)}
519 Quando si parla di IP ci si riferisce in genere alla versione attualmente in
520 uso che è la versione 4 (e viene pertanto chiamato IPv4). Questa versione
521 venne standardizzata nel 1981
522 dall'\href{http://www.ietf.org/rfc/rfc0719.txt}{RFC~719}.
524 Internet Protocol nasce per disaccoppiare le applicazioni della struttura
525 hardware delle reti di trasmissione, e creare una interfaccia di trasmissione
526 dei dati indipendente dal sottostante substrato di rete, che può essere
527 realizzato con le tecnologie più disparate (Ethernet, Token Ring, FDDI, ecc.).
528 Il compito di IP è pertanto quello di trasmettere i pacchetti da un computer
529 all'altro della rete; le caratteristiche essenziali con cui questo viene
530 realizzato in IPv4 sono due:
533 \item \textit{Universal addressing} la comunicazione avviene fra due stazioni
534 remote identificate univocamente con un indirizzo a 32 bit che può
535 appartenere ad una sola interfaccia di rete.
536 \item \textit{Best effort} viene assicurato il massimo impegno nella
537 trasmissione, ma non c'è nessuna garanzia per i livelli superiori né sulla
538 percentuale di successo né sul tempo di consegna dei pacchetti di dati.
541 Negli anni '90 la crescita vertiginosa del numero di macchine connesse a
542 internet ha iniziato a far emergere i vari limiti di IPv4, per risolverne i
543 problemi si è perciò definita una nuova versione del protocollo, che (saltando
544 un numero) è diventata la versione 6. IPv6 nasce quindi come evoluzione di
545 IPv4, mantenendone inalterate le funzioni che si sono dimostrate valide,
546 eliminando quelle inutili e aggiungendone poche altre per mantenere il
547 protocollo il più snello e veloce possibile.
549 I cambiamenti apportati sono comunque notevoli e si possono essere riassunti a
550 grandi linee nei seguenti punti:
552 \item l'espansione delle capacità di indirizzamento e instradamento, per
553 supportare una gerarchia con più livelli di indirizzamento, un numero di
554 nodi indirizzabili molto maggiore e una auto-configurazione degli indirizzi.
555 \item l'introduzione un nuovo tipo di indirizzamento, l'\textit{anycast} che
556 si aggiunge agli usuali \textit{unicast} e \itindex{multicast}
558 \item la semplificazione del formato dell'intestazione (\textit{header}) dei
559 pacchetti, eliminando o rendendo opzionali alcuni dei campi di IPv4, per
560 eliminare la necessità di rielaborazione della stessa da parte dei router e
561 contenere l'aumento di dimensione dovuto all'ampliamento degli indirizzi.
562 \item un supporto per le opzioni migliorato, per garantire una trasmissione
563 più efficiente del traffico normale, limiti meno stringenti sulle dimensioni
564 delle opzioni, e la flessibilità necessaria per introdurne di nuove in
566 \item il supporto per delle capacità di \textsl{qualità di servizio} (QoS) che
567 permettano di identificare gruppi di dati per i quali si può provvedere un
568 trattamento speciale (in vista dell'uso di internet per applicazioni
569 multimediali e/o ``real-time'').
572 Maggiori dettagli riguardo a caratteristiche, notazioni e funzionamento del
573 protocollo IP sono forniti nell'appendice sez.~\ref{sec:ip_protocol}.
576 \subsection{User Datagram Protocol (UDP)}
579 UDP è un protocollo di trasporto molto semplice; la sua descrizione completa è
580 contenuta dell'\href{http://www.ietf.org/rfc/rfc0768.txt}{RFC~768}, ma in
581 sostanza esso è una semplice interfaccia al protocollo IP dal livello di
582 trasporto. Quando un'applicazione usa UDP essa scrive un pacchetto di dati (il
583 cosiddetto \textit{datagram} che da il nome al protocollo) su un socket, al
584 pacchetto viene aggiunto un header molto semplice (per una descrizione più
585 accurata vedi sez.~\ref{sec:udp_protocol}), e poi viene passato al livello
586 superiore (IPv4 o IPv6 che sia) che lo spedisce verso la destinazione. Dato
587 che né IPv4 né IPv6 garantiscono l'affidabilità niente assicura che il
588 pacchetto arrivi a destinazione, né che più pacchetti arrivino nello stesso
589 ordine in cui sono stati spediti.
591 Pertanto il problema principale che si affronta quando si usa UDP è la
592 mancanza di affidabilità, se si vuole essere sicuri che i pacchetti arrivino a
593 destinazione occorrerà provvedere con l'applicazione, all'interno della quale
594 si dovrà inserire tutto quanto necessario a gestire la notifica di
595 ricevimento, la ritrasmissione, il timeout.
597 Si tenga conto poi che in UDP niente garantisce che i pacchetti arrivino nello
598 stesso ordine in cui sono stati trasmessi, e può anche accadere che i
599 pacchetti vengano duplicati nella trasmissione, e non solo perduti. Di tutto
600 questo di nuovo deve tenere conto l'applicazione.
602 Un altro aspetto di UDP è che se un pacchetto raggiunge correttamente la
603 destinazione esso viene passato all'applicazione ricevente in tutta la sua
604 lunghezza, la trasmissione avviene perciò per \textit{record} la cui lunghezza
605 viene anche essa trasmessa all'applicazione all'atto del ricevimento.
607 Infine UDP è un protocollo che opera senza connessione
608 (\textit{connectionless}) in quanto non è necessario stabilire nessun tipo di
609 relazione tra origine e destinazione dei pacchetti. Si hanno così situazioni
610 in cui un client può scrivere su uno stesso socket pacchetti destinati a
611 server diversi, o un server ricevere su un socket pacchetti provenienti da
612 client diversi. Il modo più semplice di immaginarsi il funzionamento di UDP è
613 quello della radio, in cui si può \textsl{trasmettere} e \textsl{ricevere} da
614 più stazioni usando la stessa frequenza.
616 Nonostante gli evidenti svantaggi comportati dall'inaffidabilità UDP ha il
617 grande pregio della velocità, che in certi casi è essenziale; inoltre si
618 presta bene per le applicazioni in cui la connessione non è necessaria, e
619 costituirebbe solo un peso in termini di prestazioni, mentre una perdita di
620 pacchetti può essere tollerata: ad esempio le applicazioni di streaming e
621 quelle che usano il \itindex{multicast} \textit{multicast}.
623 \subsection{Transport Control Protocol (TCP)}
626 Il TCP è un protocollo molto complesso, definito
627 nell'\href{http://www.ietf.org/rfc/rfc0739.txt}{RFC~739} e completamente
628 diverso da UDP; alla base della sua progettazione infatti non stanno
629 semplicità e velocità, ma la ricerca della massima affidabilità possibile
630 nella trasmissione dei dati.
632 La prima differenza con UDP è che TCP provvede sempre una connessione diretta
633 fra un client e un server, attraverso la quale essi possono comunicare; per
634 questo il paragone più appropriato per questo protocollo è quello del
635 collegamento telefonico, in quanto prima viene stabilita una connessione fra
636 due i due capi della comunicazione su cui poi effettuare quest'ultima.
638 Caratteristica fondamentale di TCP è l'affidabilità; quando i dati vengono
639 inviati attraverso una connessione ne viene richiesto un ``\textsl{ricevuto}''
640 (il cosiddetto \textit{acknowlegment}), se questo non arriva essi verranno
641 ritrasmessi per un determinato numero di tentativi, intervallati da un periodo
642 di tempo crescente, fino a che sarà considerata fallita o caduta la
643 connessione (e sarà generato un errore di \textit{timeout}); il periodo di
644 tempo dipende dall'implementazione e può variare far i quattro e i dieci
647 Inoltre, per tenere conto delle diverse condizioni in cui può trovarsi la
648 linea di comunicazione, TCP comprende anche un algoritmo di calcolo dinamico
649 del tempo di andata e ritorno dei pacchetti fra un client e un server (il
650 cosiddetto RTT, \itindex{Round~Trip~Time} \textit{Round Trip Time}), che lo
651 rende in grado di adattarsi alle condizioni della rete per non generare
652 inutili ritrasmissioni o cadere facilmente in timeout.
654 Inoltre TCP è in grado di preservare l'ordine dei dati assegnando un numero di
655 sequenza ad ogni byte che trasmette. Ad esempio se un'applicazione scrive 3000
656 byte su un socket TCP, questi potranno essere spezzati dal protocollo in due
657 segmenti (le unità di dati passate da TCP a IP vengono chiamate
658 \textit{segment}) di 1500 byte, di cui il primo conterrà il numero di sequenza
659 $1-1500$ e il secondo il numero $1501-3000$. In questo modo anche se i
660 segmenti arrivano a destinazione in un ordine diverso, o se alcuni arrivano
661 più volte a causa di ritrasmissioni dovute alla perdita degli
662 \textit{acknowlegment}, all'arrivo sarà comunque possibile riordinare i dati e
663 scartare i duplicati.
665 Il protocollo provvede anche un controllo di flusso (\textit{flow control}),
666 cioè specifica sempre all'altro capo della trasmissione quanti dati può
667 ricevere tramite una \itindex{advertised~window} \textit{advertised window}
668 (letteralmente ``\textsl{finestra annunciata}''), che indica lo spazio
669 disponibile nel buffer di ricezione, cosicché nella trasmissione non vengano
670 inviati più dati di quelli che possono essere ricevuti.
672 Questa finestra cambia dinamicamente diminuendo con la ricezione dei dati dal
673 socket ed aumentando con la lettura di quest'ultimo da parte
674 dell'applicazione, se diventa nulla il buffer di ricezione è pieno e non
675 verranno accettati altri dati. Si noti che UDP non provvede niente di tutto
676 ciò per cui nulla impedisce che vengano trasmessi pacchetti ad un ritmo che il
677 ricevente non può sostenere.
679 Infine attraverso TCP la trasmissione è sempre bidirezionale (in inglese si
680 dice che è \textit{full-duplex}). È cioè possibile sia trasmettere che
681 ricevere allo stesso tempo, il che comporta che quanto dicevamo a proposito
682 del controllo di flusso e della gestione della sequenzialità dei dati viene
683 effettuato per entrambe le direzioni di comunicazione.
685 % TODO mettere riferimento alla appendice su TCP quando ci sarà
686 %% Una descrizione più accurata del protocollo è fornita in appendice
687 %% sez.~\ref{sec:tcp_protocol}.
689 \subsection{Limiti e dimensioni riguardanti la trasmissione dei dati}
690 \label{sec:net_lim_dim}
692 Un aspetto di cui bisogna tenere conto nella programmazione di rete, e che
693 ritornerà in seguito, quando tratteremo gli aspetti più avanzati, è che ci sono
694 una serie di limiti a cui la trasmissione dei dati attraverso i vari livelli
695 del protocollo deve sottostare; limiti che è opportuno tenere presente perché
696 in certi casi si possono avere delle conseguenze sul comportamento delle
699 Un elenco di questi limiti, insieme ad un breve accenno alle loro origini ed
700 alle eventuali implicazioni che possono avere, è il seguente:
702 \item La dimensione massima di un pacchetto IP è di 65535 byte, compresa
703 l'intestazione. Questo è dovuto al fatto che la dimensione è indicata da un
704 campo apposito nell'header di IP che è lungo 16 bit (vedi
705 fig.~\ref{fig:IP_ipv4_head}).
706 \item La dimensione massima di un pacchetto normale di IPv6 è di 65575 byte;
707 il campo apposito nell'header infatti è sempre a 16 bit, ma la dimensione
708 dell'header è fissa e di 40 byte e non è compresa nel valore indicato dal
709 suddetto campo. Inoltre IPv6 ha la possibilità di estendere la dimensione di
710 un pacchetto usando la \textit{jumbo payload option}.
711 \item Molte reti fisiche hanno una MTU \itindex{Maximum~Transfer~Unit}
712 (\textit{Maximum Transfer Unit}) che dipende dal protocollo specifico usato
713 al livello di connessione fisica. Il più comune è quello di ethernet che è
714 pari a 1500 byte, una serie di altri valori possibili sono riportati in
715 tab.~\ref{tab:net_mtu_values}.
718 \itindbeg{Maximum~Transfer~Unit}
719 Quando un pacchetto IP viene inviato su una interfaccia di rete e le sue
720 dimensioni eccedono la MTU viene eseguita la cosiddetta
721 \textit{frammentazione}, i pacchetti cioè vengono suddivisi\footnote{questo
722 accade sia per IPv4 che per IPv6, anche se i pacchetti frammentati sono
723 gestiti con modalità diverse, IPv4 usa un flag nell'header, IPv6 una
724 opportuna opzione, si veda sez.~\ref{sec:ipv6_protocol}.}) in blocchi più
725 piccoli che possono essere trasmessi attraverso l'interfaccia.
729 \begin{tabular}[c]{|l|c|}
731 \textbf{Rete} & \textbf{MTU} \\
735 Token Ring IBM (16 Mbit/sec) & 17914 \\
736 Token Ring IEEE 802.5 (4 Mbit/sec) & 4464 \\
742 \caption{Valori della MTU (\textit{Maximum Transfer Unit}) per una serie di
743 diverse tecnologie di rete.}
744 \label{tab:net_mtu_values}
747 La MTU più piccola fra due stazioni viene in genere chiamata \textit{path
748 MTU}, che dice qual è la lunghezza massima oltre la quale un pacchetto
749 inviato da una stazione ad un'altra verrebbe senz'altro frammentato. Si tenga
750 conto che non è affatto detto che la \textit{path MTU} sia la stessa in
751 entrambe le direzioni, perché l'instradamento può essere diverso nei due
752 sensi, con diverse tipologie di rete coinvolte.
754 Una delle differenze fra IPv4 e IPv6 é che per IPv6 la frammentazione può
755 essere eseguita solo alla sorgente, questo vuol dire che i router IPv6 non
756 frammentano i pacchetti che ritrasmettono (anche se possono frammentare i
757 pacchetti che generano loro stessi), al contrario di quanto fanno i router
758 IPv4. In ogni caso una volta frammentati i pacchetti possono essere
759 riassemblati solo alla destinazione.
761 Nell'header di IPv4 è previsto il flag \texttt{DF} che specifica che il
762 pacchetto non deve essere frammentato; un router che riceva un pacchetto le
763 cui dimensioni eccedano quelle dell'MTU della rete di destinazione genererà un
764 messaggio di errore ICMPv4 di tipo \textit{destination unreachable,
765 fragmentation needed but DF bit set}. Dato che i router IPv6 non possono
766 effettuare la frammentazione la ricezione di un pacchetto di dimensione
767 eccessiva per la ritrasmissione genererà sempre un messaggio di errore ICMPv6
768 di tipo \textit{packet too big}.
770 Dato che il meccanismo di frammentazione e riassemblaggio dei pacchetti
771 comporta inefficienza, normalmente viene utilizzato un procedimento, detto
772 \textit{path MTU discovery} che permette di determinare il \textit{path MTU}
773 fra due stazioni; per la realizzazione del procedimento si usa il flag
774 \texttt{DF} di IPv4 e il comportamento normale di IPv6 inviando delle
775 opportune serie di pacchetti (per i dettagli vedere
776 l'\href{http://www.ietf.org/rfc/rfc1191.txt}{RFC~1191} per IPv4 e
777 l'\href{http://www.ietf.org/rfc/rfc1981.txt}{RFC~1981} per IPv6) fintanto che
778 non si hanno più errori.
780 Il TCP usa sempre questo meccanismo, che per le implementazioni di IPv4 è
781 opzionale, mentre diventa obbligatorio per IPv6. Per IPv6 infatti, non
782 potendo i router frammentare i pacchetti, è necessario, per poter comunicare,
783 conoscere da subito il \textit{path MTU}.
785 Infine TCP definisce una \itindex{Maximum~Segment~Size} \textit{Maximum
786 Segment Size} (da qui in avanti abbreviata in MSS) che annuncia all'altro
787 capo della connessione la dimensione massima dimensione del segmento di dati
788 che può essere ricevuto, così da evitare la frammentazione. Di norma viene
789 impostato alla dimensione della MTU dell'interfaccia meno la lunghezza delle
790 intestazioni di IP e TCP, in Linux il default, mantenuto nella costante
791 \const{TCP\_MSS} è 512.
793 \itindend{Maximum~Transfer~Unit}
798 %%% TeX-master: "gapil"
801 % LocalWords: TCP multitasking client ftp telnet ssh cap thread peer to three
802 % LocalWords: Napster routing tier two middle International Standards Systems
803 % LocalWords: Organization Interconnection tab Application Presentation All of
804 % LocalWords: Session Transport DataLink Physical people seem need processing
805 % LocalWords: fig upper layer lower kernel DoD Department Defense Connection
806 % LocalWords: sez UDP ICMP IGMP device Trasmission Control Protocol l'IP l'UDP
807 % LocalWords: IPv ethernet SMTP RFC Request For Comment socket stack PPP ARP
808 % LocalWords: router instradatori version RARP anycast Di
809 % LocalWords: l'acknoweledgment Datagram Message host ping ICPMv ICMPv Group
810 % LocalWords: multicast Address Resolution broadcast Token FDDI MAC address DF
811 % LocalWords: Reverse EGP Exterior Gateway gateway autonomous systems OSPF GRE
812 % LocalWords: Shortest Path First Generic Encapsulation Authentication Header
813 % LocalWords: IPSEC ESP Encapsulating Security Payload Point Line over raw QoS
814 % LocalWords: dall' Universal addressing Best effort unicast header dell' RTT
815 % LocalWords: datagram connectionless streaming nell' acknowlegment trip flow
816 % LocalWords: segment control advertised window nell'header dell'header option
817 % LocalWords: payload MTU Transfer Unit Hyperlink IBM Mbit sec IEEE path but
818 % LocalWords: dell'MTU destination unreachable fragmentation needed packet too
819 % LocalWords: big discovery MSS Size