3 %% Copyright (C) 2000-2002 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 "Prefazione",
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 \part{Programmazione di rete}
12 \label{part:progr-di-rete}
14 \chapter{Introduzione alla programmazione di rete}
17 In questo capitolo sarà fatta un'introduzione ai concetti generali che servono
18 come prerequisiti per capire la programmazione di rete, non tratteremo quindi
19 aspetti specifici ma faremo una breve introduzione al modello più comune usato
20 nella programmazione di rete, per poi passare ad un esame a grandi linee dei
21 protocolli di rete e di come questi sono organizzati e interagiscono.
23 In particolare, avendo assunto l'ottica di un'introduzione mirata alla
24 programmazione, ci concentreremo sul protocollo più diffuso, il TCP/IP, che è
25 quello che sta alla base di internet, avendo cura di sottolineare i concetti
26 più importanti da conoscere per la scrittura dei programmi.
30 \section{Modelli di programmazione}
31 \label{sec:net_prog_model}
34 La differenza principale fra un'applicazione di rete e un programma normale è
35 che quest'ultima per definizione concerne la comunicazione fra processi
36 diversi, che in generale non girano neanche sulla stessa macchina. Questo già
37 prefigura un cambiamento completo rispetto all'ottica del programma monolitico
38 all'interno del quale vengono eseguite tutte le istruzioni, e chiaramente
39 presuppone un sistema operativo multitasking in grado di eseguire più processi
42 In questa prima sezione esamineremo brevemente i principali modelli di
43 programmazione in uso. Ne daremo una descrizione assolutamente generica e
44 superficiale, che ne illustri le caratteristiche principali, non essendo fra
45 gli scopi del testo approfondire questi argomenti.
47 \subsection{Il modello \textit{client-server}}
48 \label{sec:net_cliserv}
50 L'architettura fondamentale su cui si basa gran parte della programmazione di
51 rete sotto Linux (e sotto Unix in generale) è il modello
52 \textit{client-server} caratterizzato dalla presenza di due categorie di
53 soggetti, i programmi di servizio, chiamati \textit{server}, che ricevono le
54 richieste e forniscono le risposte, ed i programmi di utilizzo, detti
57 In generale un server può (di norma deve) essere in grado di rispondere a più
58 di un client, per cui è possibile che molti programmi possano interagire
59 contemporaneamente, quello che contraddistingue il modello però è che
60 l'architettura dell'interazione è sempre nei termini di molti verso uno, il
61 server, che viene ad assumere un ruolo privilegiato.
63 Seguono questo modello tutti i servizi fondamentali di internet, come le
64 pagine web, la posta elettronica, ftp, telnet, ssh e praticamente ogni
65 servizio che viene fornito tramite la rete, anche se, come abbiamo visto, il
66 modello è utilizzato in generale anche per programmi che, come gli esempi che
67 abbiamo usato in \capref{cha:IPC} a proposito della comunicazione fra processi
68 nello stesso sistema, non fanno necessariamente uso della rete.
70 Normalmente si dividono i server in due categorie principali, e vengono detti
71 \textsl{concorrenti} o \textsl{iterativi}, sulla base del loro comportamento.
72 Un \textsl{server iterativo} risponde alla richiesta inviando i dati e resta
73 occupato e non rispondendo ad ulteriori richieste fintanto che non ha fornito
74 una risposta alla richiesta. Una volta completata la risposta il server
75 diventa di nuovo disponibile.
77 Un \textsl{server concorrente} al momento di trattare la richiesta crea un
78 processo figlio (o un thread) incaricato di fornire i servizi richiesti, per
79 porsi immediatamente in attesa di ulteriori richieste. In questo modo, con
80 sistemi multitasking, più richieste possono essere soddisfatte
81 contemporaneamente. Una volta che il processo figlio ha concluso il suo lavoro
82 esso di norma viene terminato, mentre il server originale resta sempre attivo.
85 \subsection{Il modello \textit{peer-to-peer}}
86 \label{sec:net_peertopeer}
88 Come abbiamo visto il tratto saliente dell'architettura \textit{client-server}
89 è quello della preminenza del server rispetto ai client, le architetture
90 \textit{peer-to-peer} si basano su un approccio completamente opposto che è
91 quello di non avere nessun programma che svolga un ruolo preminente.
93 Questo vuol dire che in generale ciascun programma viene ad agire come un nodo
94 in una rete potenzialmente paritetica; ciascun programma si trova pertanto a
95 ricevere ed inviare richieste ed a ricevere ed inviare risposte, e non c'è più
96 la separazione netta dei compiti che si ritrova nelle architetture
97 \textit{client-server}.
99 Le architetture \textit{peer-to-peer} sono salite alla ribalta con
100 l'esplosione del fenomeno Napster, ma gli stessi protocolli di routing sono un
101 buon esempio di architetture \textit{peer-to-peer}, in cui ciascun nodo,
102 tramite il demone che gestisce il routing, richiede ed invia informazioni ad
105 In realtà in molti casi di architetture classificate come \textit{peer-to-peer}
106 non è detto che la struttura sia totalmente paritetica e ci sono parecchi
107 esempi in cui alcuni servizi vengono centralizzati o distribuiti
108 gerarchicamente, come per lo stesso Napster, in cui le ricerche venivano
109 effettuate su un server centrale.
113 \subsection{Il modello \textit{three-tier}}
114 \label{sec:net_three_tier}
116 Benché qui sia trattato a parte, il modello \textit{three-tier} in realtà è
117 una estensione del modello \textit{client-server}. Con il crescere della
118 quantità dei servizi forniti in rete (in particolare su internet) ed al numero
119 di accessi richiesto. Si è così assistito anche ad una notevole crescita di
120 complessità, in cui diversi servizi venivano ad essere integrati fra di loro.
122 In particolare sempre più spesso si assiste ad una integrazione di servizi di
123 database con servizi di web, in cui le pagine vengono costruite dinamicamente
124 sulla base dei dati contenuti nel database. In tutti questi casi il problema
125 fondamentale di una architettura \textit{client-server} è che la richiesta di
126 un servizio da parte di un gran numero di client si scontra con il collo di
127 bottiglia dell'accesso diretto ad un unico server, con gravi problemi di
130 Rispondere a queste esigenze di scalabilità il modello più semplice (chiamato
131 talvolta \textit{two-tier}) da adottare è stata quello di distribuire il
132 carico delle richieste su più server identici, mantenendo quindi
133 sostanzialmente inalterata l'architettura \textit{client-server} originale.
135 Nel far questo ci si scontra però con gravi problemi di manutenibilità dei
136 servizi, in particolare per quanto riguarda la sincronizzazione dei dati, e di
137 inefficienza dell'uso delle risorse. Il problema è particolarmente grave ad
138 esempio per i database che non possono essere replicati e sincronizzati
139 facilmente, e che sono molto onerosi, la loro replicazione è costosa e
142 È a partire da queste problematiche che nasce il modello \textit{three-tier},
143 che si struttura, come dice il nome, su tre livelli. Il primo livello, quello
144 dei client che eseguono le richieste e gestiscono l'interfaccia con l'utente,
145 resta sostanzialmente lo stesso del modello \textit{client-server}, ma la
146 parte server viene suddivisa in due livelli, introducendo un
147 \textit{middle-tier}, su cui deve appoggiarsi tutta la logica di analisi delle
148 richieste dei client per ottimizzare l'accesso al terzo livello, che è quello
149 che si limita a fornire i dati dinamici che verranno usati dalla logica
150 implementata nel \textit{middle-tier} per eseguire le operazioni richieste dai
153 In questo modo si può disaccoppiare la logica dai dati, replicando la prima,
154 che è molto meno soggetta a cambiamenti ed evoluzione, e non soffre di
155 problemi di sincronizzazione, e centralizzando opportunamente i secondi. In
156 questo modo si può distribuire il carico ed accedere in maniera efficiente i
160 \section{I protocolli di rete}
161 \label{sec:net_protocols}
163 Parlando di reti di computer si parla in genere di un insieme molto vasto ed
164 eterogeneo di mezzi di comunicazione che vanno dal cavo telefonico, alla fibra
165 ottica, alle comunicazioni via satellite o via radio; per rendere possibile la
166 comunicazione attraverso un così variegato insieme di mezzi sono stati
167 adottati una serie di protocolli, il più famoso dei quali, quello alla base
168 del funzionamento di internet, è il protocollo TCP/IP.
170 \subsection{Il modello ISO/OSI}
171 \label{sec:net_iso_osi}
173 Una caratteristica comune dei protocolli di rete è il loro essere strutturati
174 in livelli sovrapposti; in questo modo ogni protocollo di un certo livello
175 realizza le sue funzionalità basandosi su un protocollo del livello
176 sottostante. Questo modello di funzionamento è stato stato standardizzato
177 dalla \textit{International Standards Organization} (ISO) che ha preparato fin
178 dal 1984 il Modello di Riferimento \textit{Open Systems Interconnection}
179 (OSI), strutturato in sette livelli, secondo quanto riportato in
180 \tabref{tab:net_osilayers}.
184 \begin{tabular}{|l|c|c|}
186 \textbf{Livello} & \multicolumn{2}{|c|}{\textbf{Nome}} \\
189 Livello 7&\textit{Application} &\textsl{Applicazione}\\
190 Livello 6&\textit{Presentation} &\textsl{Presentazione} \\
191 Livello 5&\textit{Session} &\textsl{Sessione} \\
192 Livello 4&\textit{Transport} &\textsl{Trasporto} \\
193 Livello 3&\textit{Network} &\textsl{Rete}\\
194 Livello 2&\textit{DataLink} &\textsl{Collegamento Dati} \\
195 Livello 1&\textit{Physical} &\textsl{Connessione Fisica} \\
198 \caption{I sette livelli del protocollo ISO/OSI.}
199 \label{tab:net_osilayers}
202 Il modello ISO/OSI è stato sviluppato in corrispondenza alla definizione della
203 serie di protocolli X.25 per la commutazione di pacchetto; come si vede è un
204 modello abbastanza complesso\footnote{infatti per memorizzarne i vari livelli
205 è stata creata la frase \texttt{All people seem to need data processing}, in
206 cui ciascuna parola corrisponde all'iniziale di uno dei livelli.}, tanto che
207 usualmente si tende a suddividerlo in due parti, secondo lo schema mostrato in
208 \figref{fig:net_osi_tcpip_comp}, con un \textit{upper layer} che riguarda solo
209 le applicazioni, che viene realizzato in user space, ed un \textit{lower
210 layer} in cui si mescolano la gestione fatta dal kernel e le funzionalità
211 fornite dall'hardware.
213 Il modello ISO/OSI mira ad effettuare una classificazione completamente
214 generale di ogni tipo di protocollo di rete; nel frattempo però era stato
215 sviluppato anche un altro modello, relativo al protocollo TCP/IP, che è quello
216 su cui è basata internet, che è diventato uno standard de facto. Questo
217 modello viene talvolta chiamato anche modello \textit{DoD} (sigla che sta per
218 \textit{Department of Defense}), dato che fu sviluppato dall'agenzia ARPA per
219 il Dipartimento della Difesa Americano.
223 \includegraphics[width=13cm]{img/iso_tcp_comp}
224 \caption{Struttura a livelli dei protocolli OSI e TCP/IP, con la
225 relative corrispondenze e la divisione fra kernel e user space.}
226 \label{fig:net_osi_tcpip_comp}
229 La scelta fra quale dei due modelli utilizzare dipende per lo più dai gusti
230 personali. Come caratteristiche generali il modello ISO/OSI è più teorico e
231 generico, basato separazioni funzionali, mentre il modello TCP/IP è più vicino
232 alla separazione concreta dei vari strati del sistema operativo; useremo
233 pertanto quest'ultimo, anche per la sua maggiore semplicità.\footnote{questa
234 semplicità ha un costo quando si fa riferimento agli strati più bassi, che
235 sono in effetti descritti meglio dal modello ISO/OSI, in quanto gran parte
236 dei protocolli di trasmissione hardware sono appunto strutturati sui due
237 livelli di \textit{Data Link} e \textit{Connection}.}
239 \subsection{Il modello TCP/IP (o DoD)}
240 \label{sec:net_tcpip_overview}
242 Così come ISO/OSI anche il modello del TCP/IP è stato strutturato in livelli
243 (riassunti in \tabref{tab:net_layers}); un confronto fra i due è riportato in
244 \figref{fig:net_osi_tcpip_comp} dove viene evidenziata anche la corrispondenza
245 fra i rispettivi livelli (che comunque è approssimativa) e su come essi vanno
246 ad inserirsi all'interno del sistema rispetto alla divisione fra user space e
247 kernel space spiegata in \secref{sec:intro_unix_struct}.\footnote{in realtà è
248 sempre possibile accedere dallo user space, attraverso una opportuna
249 interfaccia (come vedremo in \secref{sec:sock_sa_packet}), ai livelli
250 inferiori del protocollo.}
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 \secref{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 \figref{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 \figref{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}\index{socket}, che esamineremo
326 in dettaglio in \capref{cha:socket_intro}). Qui verranno spezzati in
327 pacchetti di dimensione opportuna e inseriti nel protocollo di trasporto,
328 aggiungendo ad ogni pacchetto le informazioni necessarie per la sua
329 gestione. Questo processo viene svolto direttamente nel kernel, ad esempio
330 dallo stack TCP, 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 allo livello
356 di collegamento, ma ai livelli superiori. Pertanto il protocollo IP è per sua
357 natura inaffidabile, in quanto non è assicurata né una percentuale di
358 successo né un 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 "intelligenza" della rete è pertanto
363 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 \secref{sec:net_protocols} il protocollo TCP/IP è un insieme
385 di protocolli diversi, che operano su 4 livelli diversi. Per gli interessi
386 della programmazione di rete però sono importanti principalmente i due livelli
387 centrali, e soprattutto quello di trasporto.
389 La principale interfaccia usata nella programmazione di rete, quella dei
390 socket\index{socket}, è infatti un'interfaccia nei confronti di quest'ultimo.
391 Questo avviene perché al di sopra del livello di trasporto i programmi hanno a
392 che fare solo con dettagli specifici delle applicazioni, mentre al di sotto
393 vengono curati tutti i dettagli relativi alla comunicazione. È pertanto
394 naturale definire una interfaccia di programmazione su questo confine, tanto
395 più che è proprio lì (come evidenziato in \figref{fig:net_osi_tcpip_comp}) che
396 nei sistemi Unix (e non solo) viene inserita la divisione fra kernel space e
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 \secref{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 \figref{fig:net_tcpip_overview} si è riportato uno schema che
416 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 \figref{fig:net_tcpip_overview} sono i
429 \begin{basedescript}{\desclabelwidth{1.7cm}\desclabelstyle{\nextlinelabel}}
430 \item[\textsl{IPv4}] \textit{Internet Protocol version 4}. È quello che
431 comunemente si chiama IP. Ha origine negli anni '80 e da allora è la base su
432 cui è costruita internet. Usa indirizzi a 32 bit, e mantiene tutte le
433 informazioni di instradamento e controllo per la trasmissione dei pacchetti
434 sulla rete; tutti gli altri protocolli della suite (eccetto ARP e RARP, e
435 quelli specifici di IPv6) vengono trasmessi attraverso di esso.
436 \item[\textsl{IPv6}] \textit{Internet Protocol version 6}. È stato progettato
437 a metà degli anni '90 per rimpiazzare IPv4. Ha uno spazio di indirizzi
438 ampliato 128 bit che consente più gerarchie di indirizzi,
439 l'autoconfigurazione, ed un nuovo tipo di indirizzi, gli \textit{anycast},
440 che consentono di inviare un pacchetto ad una stazione su un certo gruppo.
441 Effettua lo stesso servizio di trasmissione dei pacchetti di IPv4 di cui
442 vuole essere un sostituto.
443 \item[\textsl{TCP}] \textit{Trasmission Control Protocol}. È un protocollo
444 orientato alla connessione che provvede un trasporto affidabile per un
445 flusso di dati bidirezionale fra due stazioni remote. Il protocollo ha cura
446 di tutti gli aspetti del trasporto, come l'acknoweledgment, i timeout, la
447 ritrasmissione, etc. È usato dalla maggior parte delle applicazioni.
448 \item[\textsl{UDP}] \textit{User Datagram Protocol}. È un protocollo senza
449 connessione, per l'invio di dati a pacchetti. Contrariamente al TCP il
450 protocollo non è affidabile e non c'è garanzia che i pacchetti raggiungano
451 la loro destinazione, si perdano, vengano duplicati, o abbiano un
452 particolare ordine di arrivo.
453 \item[\textsl{ICMP}] \textit{Internet Control Message Protocol}. È il
454 protocollo usato a livello 2 per gestire gli errori e trasportare le
455 informazioni di controllo fra stazioni remote e instradatori (cioè fra
456 \textit{host} e \textit{router}). I messaggi sono normalmente generati dal
457 software del kernel che gestisce la comunicazione TCP/IP, anche se ICMP può
458 venire usato direttamente da alcuni programmi come \cmd{ping}. A volte ci
459 si riferisce ad esso come ICPMv4 per distinguerlo da ICMPv6.
460 \item[\textsl{IGMP}] \textit{Internet Group Management Protocol}. É un
461 protocollo di livello 2 usato per il \textit{multicasting} (vedi
462 \secref{sec:xxx_multicast}). Permette alle stazioni remote di notificare ai
463 router che supportano questa comunicazione a quale gruppo esse appartengono.
464 Come ICMP viene 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 broadcast come Ethernet, Token Ring o FDDI che hanno associato
468 un indirizzo fisico (il \textit{MAC address}) alla interfaccia, ma non serve
469 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 dall'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, etc.).
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, mantendone 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{unycast} e \textit{multicast}.
556 \item la semplificazione del formato dell'intestazione (\textit{header}) dei
557 pacchetti, eliminando o rendendo opzionali alcuni dei campi di IPv4, per
558 eliminare la necessità di riprocessamento della stessa da parte dei router e
559 contenere l'aumento di dimensione dovuto all'ampliamento degli indirizzi.
560 \item un supporto per le opzioni migliorato, per garantire una trasmissione
561 più efficiente del traffico normale, limiti meno stringenti sulle dimensioni
562 delle opzioni, e la flessibilità necessaria per introdurne di nuove in
564 \item il supporto per delle capacità di \textsl{qualità di servizio} (QoS) che
565 permettano di identificare gruppi di dati per i quali si può provvedere un
566 trattamento speciale (in vista dell'uso di internet per applicazioni
567 multimediali e/o ``real-time'').
570 Maggiori dettagli riguardo a caratteristiche, notazioni e funzionamento del
571 protocollo IP sono forniti nell'appendice \capref{cha:ip_protocol}.
574 \subsection{User Datagram Protocol (UDP)}
577 UDP è un protocollo di trasporto molto semplice, la sua descrizione completa è
578 contenuta dell'RFC~768, ma in sostanza esso è una semplice interfaccia a IP
579 dal livello di trasporto. Quando un'applicazione usa UDP essa scrive un
580 pacchetto di dati (il cosiddetto \textit{datagram} che da il nome al
581 protocollo) su un socket\index{socket}, al pacchetto viene aggiunto un header
582 molto semplice (per una descrizione più accurata vedi \secref{sec:xxx_udp}), e
583 poi viene passato al livello superiore (IPv4 o IPv6 che sia) che lo spedisce
584 verso la destinazione. Dato che né IPv4 né IPv6 garantiscono l'affidabilità
585 niente assicura che il pacchetto arrivi a destinazione, né che più pacchetti
586 arrivino nello stesso ordine in cui sono stati spediti.
588 Pertanto il problema principale che si affronta quando si usa UDP è la
589 mancanza di affidabilità, se si vuole essere sicuri che i pacchetti arrivino a
590 destinazione occorrerà provvedere con l'applicazione, all'interno della quale
591 si dovrà inserire tutto quanto necessario a gestire la notifica di
592 ricevimento, la ritrasmissione, il timeout.
594 Si tenga conto poi che in UDP niente garantisce che i pacchetti arrivino nello
595 stesso ordine in cui sono stati trasmessi, e può anche accadere che i
596 pacchetti vengano duplicati nella trasmissione, e non solo perduti. Di tutto
597 questo di nuovo deve tenere conto l'applicazione.
599 Un'altro aspetto di UDP è che se un pacchetto raggiunge correttamente la
600 destinazione esso viene passato all'applicazione ricevente in tutta la sua
601 lunghezza, la trasmissione avviene perciò per \textit{record} la cui lunghezza
602 viene anche essa trasmessa all'applicazione all'atto del ricevimento.
604 Infine UDP è un protocollo che opera senza connessione
605 (\textit{connectionless}) in quanto non è necessario stabilire nessun tipo di
606 relazione tra origine e destinazione dei pacchetti. Si hanno così situazioni
607 in cui un client può scrivere su uno stesso socket\index{socket} pacchetti
608 destinati a server diversi, o un server ricevere su un socket\index{socket}
609 pacchetti provenienti da client diversi. Il modo più semplice di immaginarsi
610 il funzionamento di UDP è quello della radio, in cui si può
611 \textsl{trasmettere} e \textsl{ricevere} da più stazioni usando la stessa
614 Nonostante gli evidenti svantaggi comportati dall'inaffidabilità UDP ha il
615 grande pregio della velocità, che in certi casi è essenziale; inoltre si
616 presta bene per le applicazioni in cui la connessione non è necessaria, e
617 costituirebbe solo un peso in termini di prestazioni, mentre una perdita di
618 pacchetti può essere tollerata, ad esempio le applicazioni di streaming e
619 quelle che usano il multicasting.
621 \subsection{Transport Control Protocol (TCP)}
624 Il TCP è un protocollo molto complesso, definito nell'RFC~739 e completamente
625 diverso da UDP; alla base della sua progettazione infatti non stanno
626 semplicità e velocità, ma la ricerca della massima affidabilità possibile
627 nella trasmissione dei dati.
629 La prima differenza con UDP è che TCP provvede sempre una connessione diretta
630 fra un client e un server, attraverso la quale essi possono comunicare; per
631 questo il paragone più appropriato per questo protocollo è quello del
632 collegamento telefonico, in quanto prima viene stabilita una connessione fra
633 due i due capi della comunicazione su cui poi effettuare quest'ultima.
635 Caratteristica fondamentale di TCP è l'affidabilità; quando i dati vengono
636 inviati attraverso una connessione ne viene richiesto un ``\textsl{ricevuto}''
637 (il cosiddetto \textit{acknowlegment}), se questo non arriva essi verranno
638 ritrasmessi per un determinato numero di tentativi, intervallati da un periodo
639 di tempo crescente, fino a che sarà considerata fallita o caduta la
640 connessione (e sarà generato un errore di \textit{timeout}); il periodo di
641 tempo dipende dall'implementazione e può variare far i quattro e i dieci
644 Inoltre, per tenere conto delle diverse condizioni in cui può trovarsi la
645 linea di comunicazione, TCP comprende anche un algoritmo di calcolo dinamico
646 del tempo di andata e ritorno dei pacchetti fra un client e un server (il
647 cosiddetto RTT, \textit{round-trip time}), che lo rende in grado di adattarsi
648 alle condizioni della rete per non generare inutili ritrasmissioni o cadere
649 facilmente in timeout.
651 Inoltre TCP è in grado di preservare l'ordine dei dati assegnando un numero di
652 sequenza ad ogni byte che trasmette. Ad esempio se un'applicazione scrive 3000
653 byte su un socket\index{socket} TCP, questi potranno essere spezzati dal
654 protocollo in due segmenti (le unità di dati passate da TCP a IP vengono
655 chiamate \textit{segment}) di 1500 byte, di cui il primo conterrà il numero di
656 sequenza $1-1500$ e il secondo il numero $1501-3000$. In questo modo anche se
657 i segmenti arrivano a destinazione in un ordine diverso, o se alcuni arrivano
658 più volte a causa di ritrasmissioni dovute alla perdita degli
659 \textit{acknowlegment}, all'arrivo sarà comunque possibile riordinare i dati e
660 scartare i duplicati.
662 Il protocollo provvede anche un controllo di flusso (\textit{flow control}),
663 cioè specifica sempre all'altro capo della trasmissione quanti dati può
664 ricevere tramite una \textit{advertised window} (letteralmente
665 \textsl{finestra annunciata)}, che indica lo spazio disponibile nel buffer di
666 ricezione, cosicché nella trasmissione non vengano inviati più dati di quelli
667 che possono essere ricevuti.
669 Questa finestra cambia dinamicamente diminuendo con la ricezione dei dati dal
670 socket\index{socket} ed aumentando con la lettura di quest'ultimo da parte
671 dell'applicazione, se diventa nulla il buffer di ricezione è pieno e non
672 verranno accettati altri dati. Si noti che UDP non provvede niente di tutto
673 ciò per cui nulla impedisce che vengano trasmessi pacchetti ad un ritmo che il
674 ricevente non può sostenere.
676 Infine attraverso TCP la trasmissione è sempre bidirezionale (in inglese si
677 dice che è \textit{full-duplex}). È cioè possibile sia trasmettere che
678 ricevere allo stesso tempo, il che comporta che quanto dicevamo a proposito
679 del controllo di flusso e della gestione della sequenzialità dei dati viene
680 effettuato per entrambe le direzioni di comunicazione.
682 %% Una descrizione più accurata del protocollo è fornita in appendice
683 %% \capref{cha:tcp_protocol}.
685 \subsection{Limiti e dimensioni riguardanti la trasmissione dei dati}
686 \label{sec:net_lim_dim}
688 Un aspetto di cui bisogna tenere conto nella programmazione di rete, e che
689 ritornerà anche più avanti, è che ci sono una serie di limiti a cui la
690 trasmissione dei dati attraverso i vari livelli del protocollo deve
691 sottostare, limiti che è opportuno tenere presente perché in certi casi si
692 possono avere delle conseguenze sul comportamento delle applicazioni.
694 Un elenco di questi limiti, insieme ad un breve accenno alle loro origini ed
695 alle eventuali implicazioni che possono avere, è il seguente:
697 \item La dimensione massima di un pacchetto IP è di 65535 byte, compresa
698 l'intestazione. Questo è dovuto al fatto che la dimensione è indicata da un
699 campo apposito nell'header di IP che è lungo 16 bit (vedi
700 \figref{fig:IP_ipv4_head}).
701 \item La dimensione massima di un pacchetto normale di IPv6 è di 65575 byte,
702 il campo apposito nell'header infatti è sempre a 16 bit, ma la dimensione
703 dell'header è fissa e di 40 byte e non è compresa nel valore indicato dal
704 suddetto campo. Inoltre IPv6 ha la possibilità di estendere la dimensione di
705 un pacchetto usando la \textit{jumbo payload option}.
706 \item Molte reti fisiche hanno un MTU (\textit{maximum transfer unit}) che
707 dipende dal protocollo specifico usato al livello di connessione fisica. Il
708 più comune è quello di ethernet che è pari a 1500 byte, una serie di altri
709 valori possibili sono riportati in \tabref{tab:net_mtu_values}.
712 Quando un pacchetto IP viene inviato su una interfaccia di rete e le sue
713 dimensioni eccedono la MTU viene eseguita la cosiddetta
714 \textit{frammentazione}, i pacchetti cioè vengono suddivisi\footnote{questo
715 accade sia per IPv4 che per IPv6, anche se i pacchetti frammentati sono
716 gestiti con modalità diverse, IPv4 usa un flag nell'header, IPv6 una
717 opportuna opzione, si veda \secref{cha:ip_protocol}.}) in blocchi più
718 piccoli che possono essere trasmessi attraverso l'interfaccia.
722 \begin{tabular}[c]{|l|c|}
724 \textbf{Rete} & \textbf{MTU} \\
728 Token Ring IBM (16 Mbit/sec) & 17914 \\
729 Token Ring IEEE 802.5 (4 Mbit/sec) & 4464 \\
735 \caption{Valori della MTU (\textit{maximum transfer unit}) per una serie di
737 \label{tab:net_mtu_values}
740 La MTU più piccola fra due stazioni viene in genere chiamata \textit{path
741 MTU}, che dice qual'è la lunghezza massima oltre la quale un pacchetto
742 inviato da una stazione ad un'altra verrebbe senz'altro frammentato. Si tenga
743 conto che non è affatto detto che la \textit{path MTU} sia la stessa in
744 entrambe le direzioni, perché l'instradamento può essere diverso nei due
745 sensi, con diverse tipologie di rete coinvolte.
747 Una delle differenze fra IPv4 e IPv6 é che per IPv6 la frammentazione può
748 essere eseguita solo alla sorgente, questo vuol dire che i router IPv6 non
749 frammentano i pacchetti che ritrasmettono (anche se possono frammentare i
750 pacchetti che generano loro stessi), mentre i router IPv4 si. In ogni caso una
751 volta frammentati i pacchetti possono essere riassemblati solo alla
754 Nell'header di IPv4 è previsto il flag \texttt{DF} che specifica che il
755 pacchetto non deve essere frammentato; un router che riceva un pacchetto le
756 cui dimensioni eccedano quelle dell'MTU della rete di destinazione genererà un
757 messaggio di errore ICMPv4 di tipo \textit{destination unreachable,
758 fragmentation needed but DF bit set}. Dato che i router IPv6 non possono
759 effettuare la frammentazione la ricezione di un pacchetto di dimensione
760 eccessiva per la ritrasmissione genererà sempre un messaggio di errore ICMPv6
761 di tipo \textit{packet too big}.
763 Dato che il meccanismo di frammentazione e riassemblaggio dei pacchetti
764 comporta inefficienza, normalmente viene utilizzato un procedimento, detto
765 \textit{path MTU discovery} che permette di determinare il \textit{path MTU}
766 fra due stazioni; per la realizzazione del procedimento si usa il flag DF di
767 IPv4 e il comportamento normale di IPv6 inviando delle opportune serie di
768 pacchetti (per i dettagli vedere l'RFC~1191 per IPv4 e l'RFC~1981 per IPv6)
769 fintanto che non si hanno più errori.
771 Il TCP usa sempre questo meccanismo, che per le implementazioni di IPv4 è
772 opzionale, mentre diventa obbligatorio per IPv6. Per IPv6 infatti, non
773 potendo i router frammentare i pacchetti, è necessario, per poter comunicare,
774 conoscere da subito il \textit{path MTU}.
776 Infine TCP definisce una MSS \textit{Maximum Segment Size} che annuncia
777 all'altro capo della connessione la dimensione massima dimensione del segmento
778 di dati che può essere ricevuto, così da evitare la frammentazione. Di norma
779 viene impostato alla dimensione della MTU dell'interfaccia meno la lunghezza
780 delle intestazioni di IP e TCP, in Linux il default, mantenuto nella costante
781 \const{TCP\_MSS} è 512.
784 %\subsection{Il passaggio dei dati in TCP}
785 %\label{sec:net_tcp_pass}
787 %\subsection{Il passaggio dei dati in UDP}
788 %\label{sec:net_udp_pass}
792 %%% TeX-master: "gapil"