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