Completata la descrizione dell'esempio dei mutex realizzati con i semafori.
[gapil.git] / network.tex
1 \chapter{Introduzione alla programmazione di rete}
2 \label{cha:network}
3
4 In questo capitolo sarà fatta un'introduzione ai concetti generali che servono
5 come prerequisiti per capire la programmazione di rete, non tratteremo quindi
6 aspetti specifici ma faremo una breve introduzione al modello più comune usato
7 nella programmazione di rete, per poi passare ad un esame a grandi linee dei
8 protocolli di rete e di come questi sono organizzati e interagiscono. 
9
10 In particolare, avendo assunto l'ottica di un'introduzione mirata alla
11 programmazione, ci concentreremo sul protocollo più diffuso, il TCP/IP, che è
12 quello che sta alla base di internet, avendo cura di sottolineare i concetti
13 più importanti da conoscere per la scrittura dei programmi.
14
15 \section{Il modello client-server}
16 \label{sec:net_cliserv}
17
18 La differenza principale fra un'applicazione di rete e un programma normale è
19 che quest'ultima per definizione concerne la comunicazione fra ``processi''
20 diversi (che in generale non girano neanche sulla stessa macchina). Questo già
21 prefigura un cambiamento completo rispetto all'ottica del ``programma''
22 monolitico all'interno del quale vengono eseguite tutte le istruzioni, e
23 presuppone un sistema operativo ``multitasking'' in grado di eseguire processi
24 diversi.
25
26 Un concetto fondamentale su cui si basa la programmazione di rete sotto Linux
27 (e sotto Unix in generale) è il modello \textit{client-server} in cui un
28 programma di servizio, il \textit{server}, riceve una connessione e risponde a
29 un programma di utilizzo, il \textit{client}, provvedendo a quest'ultimo un
30 definito insieme di servizi.
31
32 Esempi di questo modello sono il WEB, ftp, telnet, ssh e praticamente ogni
33 servizio che viene fornito tramite la rete, ma il modello è utilizzato in
34 generale anche per programmi che non fanno necessariamente uso della rete,
35 come il sistema a finestre.
36
37 Normalmente si dividono i server in due categorie principali, e vengono detti
38 \textsl{concorrenti} o \textsl{iterativi}, sulla base del loro comportamento.
39
40 Un \textsl{server iterativo} risponde alla richiesta inviando i dati e resta
41 occupato (non rispondendo ad ulteriori richieste) fintanto che non ha concluso
42 la richiesta. Una volta completata la richiesta il server diventa di nuovo
43 disponibile.
44
45 Un \textsl{server concorrente} al momento di trattare la richiesta crea un
46 processo figlio incaricato di fornire i servizi richiesti, per poi porsi in
47 attesa di ulteriori richieste. In questo modo più richieste possono essere
48 soddisfatte contemporaneamente; una volta che il processo figlio ha concluso
49 il suo lavoro viene terminato, mentre il server originale resta sempre attivo.
50
51
52
53 \section{I protocolli di rete}
54 \label{sec:net_protocols}
55
56 Parlando di reti di computer si parla in genere di un insieme molto vasto ed
57 eterogeneo di mezzi di comunicazione che vanno dal cavo telefonico, alla fibra
58 ottica, alle comunicazioni via satellite; per rendere possibile la
59 comunicazione attraverso un così variegato insieme di mezzi sono stati
60 adottati una serie di protocolli, il più famoso dei quali, quello alla base
61 del funzionamento di internet, è il protocollo TCP/IP.
62
63 \subsection{Il modello ISO/OSI}
64 \label{sec:net_iso_osi}
65
66 Una caratteristica comune dei protocolli di rete è il loro essere strutturati
67 in livelli sovrapposti; in questo modo un livello superiore esegue richieste
68 al livello sottostante e da questo riceve responsi, mentre livelli uguali su
69 macchine diverse conversano tramite lo stesso protocollo. Questo modello di
70 funzionamento è stato stato standardizzato dalla \textit{International
71   Standards Organization} (ISO) che ha preparato fin dal 1984 il Modello di
72 Riferimento \textit{Open Systems Interconnection} (OSI), strutturato in sette
73 livelli, secondo quanto riportato in \tabref{tab:net_osilayers}.
74
75 \begin{table}[htb]
76   \centering
77   \begin{tabular}{|l|c|c|} 
78     \hline
79     \textbf{Livello} & \multicolumn{2}{|c|}{\textbf{Nome}} \\
80     \hline
81     \hline
82     Livello 7&\textit{Application}  &\textsl{Applicazione}\\ 
83     Livello 6&\textit{Presentation} &\textsl{Presentazione} \\ 
84     Livello 5&\textit{Session}      &\textsl{Sessione} \\ 
85     Livello 4&\textit{Transport}    &\textsl{Trasporto} \\ 
86     Livello 3&\textit{Network}      &\textsl{Rete}\\ 
87     Livello 2&\textit{DataLink}     &\textsl{Collegamento Dati} \\
88     Livello 1&\textit{Connection}   &\textsl{Connessione Fisica} \\
89     \hline
90 \end{tabular}
91 \caption{I sette livelli del protocollo ISO/OSI.}
92 \label{tab:net_osilayers}
93 \end{table}
94
95 Il modello ISO/OSI è stato sviluppato in corrispondenza alla definizione
96 della serie di protocolli X.25 per la commutazione di pacchetto. Ma nonostante
97 il lavoro dettagliato di standardizzazione il modello si è rivelato
98 sostanzialmente troppo complesso e poco flessibile rispetto a quello,
99 precedente, su cui si basa TCP/IP che è diventato uno standard de facto;
100 quest'ultimo viene comunemente chiamato modello DoD (\textit{Department of
101   Defense}), dato che fu sviluppato dall'agenzia ARPA per il Dipartimento
102 della Difesa Americano.
103
104 \begin{figure}[!htbp]
105   \centering
106   \includegraphics[width=12cm]{img/iso_tcp_comp}
107   \caption{Struttura a livelli dei protocolli OSI e TCP/IP, con la  
108     relative corrispondenze e la divisione fra kernel e user space.}
109   \label{fig:net_osi_tcpip_comp}
110 \end{figure}
111
112
113 \subsection{Il modello DoD (TCP/IP)}
114 \label{sec:net_tcpip_overview}
115
116 Così come ISO/OSI anche TCP/IP è stato strutturato in livelli (riassunti in
117 \tabref{tab:net_layers}); un confronto fra i due è riportato in
118 \figref{fig:net_osi_tcpip_comp} dove viene evidenziata anche la corrispondenza
119 fra i rispettivi livelli (che comunque è approssimativa) e su come essi vanno
120 ad inserirsi all'interno del sistema operativo rispetto alla divisione fra
121 user space e kernel space spiegata in \secref{sec:intro_unix_struct}.
122
123 \begin{table}[htb]
124   \centering
125   \begin{tabular}{|l|c|c|l|} 
126     \hline
127     \textbf{Livello} & \multicolumn{2}{|c|}{\textbf{Nome}} & \textbf{Esempi} \\
128     \hline
129     \hline
130     Livello 1&\textit{Application} &\textsl{Applicazione}& 
131     Telnet, FTP, etc. \\ 
132     Livello 2&\textit{Transport} &\textsl{Trasporto}& TCP, UDP \\ 
133     Livello 3&\textit{Network} &\textsl{Rete}& IP, (ICMP, IGMP)  \\ 
134     Livello 4&\textit{Link} &\textsl{Connessione}& 
135     device driver \& scheda di interfaccia  \\
136     \hline
137 \end{tabular}
138 \caption{I quattro livelli del protocollo TCP/IP.}
139 \label{tab:net_layers}
140 \end{table}
141
142 Come si può notare TCP/IP è più semplice del modello ISO/OSI e strutturato in
143 soli quattro livelli. Il suo nome deriva dai due principali protocolli che lo
144 compongono, il TCP \textit{Trasmission Control Protocol} e l'IP
145 \textit{Internet Protocol}. Le funzioni dei vari livelli sono le seguenti:
146
147 \begin{description}
148 \item \textbf{Applicazione} É relativo ai programmi di interfaccia utente, in
149   genere questi vengono realizzati secondo il modello client-server (vedi
150   \secref{sec:net_cliserv}.
151 \item \textbf{Trasporto} Fornisce la comunicazione tra le due stazioni
152   terminali su cui girano gli applicativi, regola il flusso delle
153   informazioni, e può fornire un trasporto affidabile, cioè con recupero
154   errori. Il protocollo principale di questo livello è il TCP.
155 \item \textbf{Rete} Si occupa dello smistamento dei singoli pacchetti su una
156   rete complessa e interconnessa, a questo stesso livello operano i protocolli
157   per il reperimento delle informazioni necessarie allo smistamento, per lo
158   scambio di messaggi di controllo e per il monitoraggio della rete. Il
159   protocollo su cui si basa questo livello è IP (sia nella attuale versione,
160   IPv4 che nella nuova IPv6).
161 \item \textbf{Connessione} È responsabile per l'interfacciamento al
162   dispositivo elettronico che effettua la comunicazione fisica, gestendo
163   l'invio e la ricezione dall'hardware dei pacchetti.
164 \end{description}
165
166
167 La comunicazione fra due stazioni avviene secondo le modalità illustrate in
168 \figref{fig:net_tcpip_data_flux}, dove si è riportato il flusso dei dati reali
169 e i protocolli usati per lo scambio di informazione su ciascuno livello.
170 \begin{figure}[!htb]
171   \centering
172   \includegraphics[width=10cm]{img/tcp_data_flux}  
173   \caption{Strutturazione del flusso dei dati nella comunicazione fra due
174     applicazioni attraverso i protocolli della suite TCP/IP.}
175   \label{fig:net_tcpip_data_flux}
176 \end{figure}
177
178 La struttura della comunicazione pertanto si può riassumere nei seguenti passi:
179 \begin{itemize}
180 \item Le singole applicazioni si scambieranno i dati secondo un loro formato
181   specifico, implementando un protocollo di applicazione (esempi possono
182   essere HTTP, POP, telnet, SMTP, etc).
183 \item Questi dati vengono inviati al livello di trasporto usando
184   un'interfaccia opportuna (i \textit{socket}, che esamineremo in dettaglio in
185   seguito). Qui verranno spezzati in pacchetti di dimensione opportuna e
186   incapsulati nel protocollo di trasporto, aggiungendo ad ogni pacchetto le
187   informazioni necessarie per la sua gestione. Questo processo viene
188   svolto direttamente nel kernel ad esempio dallo stack TCP nel caso il
189   protocollo di trasporto sia questo.
190 \item Una volta composto il pacchetto nel formato adatto al protocollo di
191   trasporto usato questo sarà passato al successivo livello, quello di rete,
192   che si occupa di inserire le opportune informazioni per poter effettuare
193   l'instradamento nella rete ed il recapito alla destinazione finale. In
194   genere questo è il livello di IP (Internet Protocol), a cui vengono inseriti
195   i numeri IP che identificano i computer su internet.
196 \item L'ultimo passo è il trasferimento del pacchetto al driver della
197   interfaccia di trasmissione che si incarica di incapsularlo nel relativo
198   protocollo di trasmissione fisica usato dall'hardware usato per la
199   comunicazione (ad esempio Ethernet per una scheda di rete).
200 \end{itemize}
201
202
203 \subsection{Criteri generali del design di TCP/IP}
204 \label{sec:net_tcpip_design}
205
206 La filosofia architetturale di TCP/IP è semplice: costruire una rete che
207 possa sopportare il carico in transito, ma permettere ai singoli nodi di
208 scartare pacchetti se il carico è temporaneamente eccessivo, o se risultano
209 errati o non recapitabili.
210
211 L'incarico di rendere il recapito pacchetti affidabile non spetta allo livello
212 di collegamento, ma ai livelli superiori. Pertanto il protocollo IP è per sua
213 natura inaffidabile, in quanto non è assicurata né una percentuale di
214 successo né un limite sui tempi di consegna dei pacchetti.
215
216 È il livello di trasporto che si deve occupare (qualora necessiti) del
217 controllo del flusso dei dati e del recupero degli errori; questo è realizzato
218 dal protocollo TCP. La sede principale di "intelligenza" della rete è pertanto
219 al livello di trasporto o superiore.
220
221 Infine le singole stazioni collegate alla rete non fungono soltanto da punti
222 terminali di comunicazione, ma possono anche assumere il ruolo di router, per
223 l'interscambio di pacchetti da una rete ad un'altra. Questo rende possibile la
224 flessibilità della rete che è in grado di adattarsi ai mutamenti delle
225 interconnessioni.
226
227 La caratteristica essenziale che rende tutto ciò possibile è la strutturazione
228 a livelli tramite l'incapsulamento. Ogni pacchetto di dati viene incapsulato
229 nel formato del livello successivo, fino al livello della connessione fisica.
230 In questo modo il pacchetto ricevuto ad un livello \textit{n} dalla stazione
231 di destinazione è esattamente lo stesso spedito dal livello \textit{n} dalla
232 sorgente.  Questo rende facile il progettare il software facendo riferimento
233 unicamente a quanto necessario ad un singolo livello, con la confidenza che
234 questo poi sarà trattato uniformemente da tutti i nodi della rete.
235
236
237 \section{Il protocollo TCP/IP}
238 \label{sec:net_tpcip}
239
240 Come appena mostrato il protocollo TCP/IP è un insieme di protocolli diversi,
241 che operano su 4 livelli diversi. Per gli interessi della programmazione di
242 rete però sono importanti principalmente i due livelli centrali, e soprattutto
243 quello di trasporto. 
244
245 La principale interfaccia di programmazione di rete, quella dei socket, è
246 infatti un'interfaccia nei confronti di quest'ultimo. Questo avviene perché al
247 di sopra del livello di trasporto i programmi hanno a che fare solo con
248 dettagli specifici delle applicazioni, mentre al di sotto vengono curati tutti
249 i dettagli relativi alla comunicazione. È pertanto naturale definire una API
250 su questo confine tanto più che è proprio li (come evidenziato in
251 \figref{fig:net_osi_tcpip_comp}) che nei sistemi Unix (e non solo) viene
252 inserita la divisione fra kernel space e user space.
253
254 In realtà in un sistema Unix è possibile accedere anche agli altri livelli
255 inferiori (e non solo a quello di trasporto) con opportune interfacce (la cosa
256 è indicata in \figref{fig:net_osi_tcpip_comp} lasciando uno spazio fra UDP e
257 TCP), ma queste vengono usate solo quando si vogliono fare applicazioni di
258 sistema per il controllo della rete a basso livello, un uso quindi molto
259 specialistico, e che non rientra in quanto trattato qui.
260
261 In questa sezione daremo una breve descrizione dei vari protocolli di TCP/IP,
262 concentrandoci per le ragioni esposte sul livello di trasporto. All'interno di
263 questo privilegeremo poi il protocollo TCP, per il ruolo centrale che svolge
264 nella maggior parte delle applicazioni.
265
266
267 \subsection{Il quadro generale}
268 \label{sec:net_tcpip_general}
269
270 Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da
271 altri membri. In \figref{fig:net_tcpip_overview} si è riportato uno schema che
272 mostra un panorama sui vari protocolli della famiglia, e delle loro relazioni
273 reciproche e con alcune dalle principali applicazioni che li usano.
274
275 \begin{figure}[!htbp]
276   \centering
277   \includegraphics[width=15cm]{img/tcpip_overview}  
278   \caption{Panoramica sui vari protocolli che compongono la suite TCP/IP.}
279   \label{fig:net_tcpip_overview}
280 \end{figure}
281
282 I vari protocolli mostrati in figura sono i seguenti:
283
284 \begin{list}{}{}
285 \item \textsl{IPv4} \textit{Internet Protocol version 4}. È quello che
286   comunemente si chiama IP. Ha origine negli anni '80 e da allora è la base su
287   cui è costruita internet. Usa indirizzi a 32 bit e provvede la trasmissione
288   dei pacchetti TCP, UDP, ICMP e IGMP.
289 \item \textsl{IPv6} \textit{Internet Protocol version 6}. È stato progettato a
290   metà degli anni '90 per rimpiazzare IPv4. Ha indirizzi a 128 bit e effettua
291   lo stesso servizio di trasporto di IPv4 per i pacchetti TCP, UDP e ICPMv6.
292 \item \textsl{TCP} \textit{Trasmission Control Protocol}. È un protocollo
293   orientato alla connessione che provvede un trasporto affidabile e
294   bidirezionale di un flusso di dati. I socket TCP sono esempi di
295   \textit{stream socket}. Il protocollo ha cura di tutti gli aspetti del
296   trasporto, come l'acknoweledgment, i timeout, la ritrasmissione, etc. È 
297   usato dalla maggior parte delle applicazioni. Può essere usato sia con IPv4
298   che con IPv6.
299 \item \textsl{UDP} \textit{User Datagram Protocol}. È un protocollo senza
300   connessione a pacchetti. I socket UDP sono esempi di \textit{datagram
301     socket}. Contrariamente al TCP in protocollo non è affidabile e non c'è
302   garanzia che i pacchetti raggiungano la loro destinazione, né sull'eventuale
303   ordine di arrivo. Può essere usato sia con IPv4 che con IPv6.
304 \item \textsl{ICMP} \textit{Internet Control Message Protocol}. Gestisce gli
305   errori e trasporta l'informazione di controllo fra stazioni remote e
306   instradatori (\textit{host} e \textit{router}). I messaggi sono normalmente
307   generati dal software del kernel che gestisce la comunicazione TCP/IP, anche
308   se ICMP può venire usato direttamente da alcuni programmi come
309   \texttt{ping}. A volte ci si riferisce ad esso come ICPMv4 per distinguerlo
310   da ICMPv6.
311 \item \textsl{IGMP} \textit{Internet Group Management Protocol}. É un
312   protocollo usato per il \textit{multicasting} (vedi
313   \secref{sec:xxx_multicast}), che è opzionale in IPv4.
314 \item \textsl{ARP} \textit{Address Resolution Protocol}. È il protocollo che
315   mappa un indirizzo IP in un indirizzo hardware (come un indirizzo
316   internet). È usato in reti di tipo broadcast come Ethernet, Token Ring o
317   FDDI ma non serve in connessioni punto-punto.
318 \item \textsl{RARP} \textit{Reverse Address Resolution Protocol}. È il
319   protocollo che mappa un indirizzo hardware in un indirizzo IP. Viene usato a
320   volte per durante il boot per assegnare un indirizzo IP ad una macchina.
321 \item \textsl{ICMPv6} \textit{Internet Control Message Protocol, version 6}.
322   Combina per IPv6 le funzionalità di ICMPv4, IGMP e ARP.
323 \item \textsl{NETLINK} \textit{Netlink}.
324   Provvede l'interfaccia di accesso alla comunicazione a basso livello.
325 \end{list}
326
327 Gran parte delle applicazioni comunicano usando TCP o UDP, ed alcune si
328 rifanno ad IP (ed i suoi correlati ICMP e IGMP); benché sia TCP che UDP siano
329 basati su IP e sia possibile intervenire a questo livello con i \textit{raw
330   socket} questa tecnica è molto meno diffusa e a parte applicazioni
331 particolari si preferisce sempre usare i servizi messi a disposizione dai due
332 protocolli precedenti.  Per questo motivo a parte alcuni brevi accenni su IP
333 in questa sezione ci concentreremo sul livello di trasporto.
334
335 \subsection{Internet Protocol (IP)}
336 \label{sec:net_ip}
337
338 Quando si parla di IP ci si riferisce in genere alla versione attualmente in
339 uso che è la versione 4 (e viene pertanto chiamato IPv4). Questa versione
340 venne standardizzata nel 1981 dall'RFC~719.
341
342 Internet Protocol nasce per disaccoppiare le applicazioni della struttura
343 hardware delle reti di trasmissione, e creare una interfaccia di trasmissione
344 dei dati indipendente dal sottostante substrato di rete, che può essere
345 realizzato con le tecnologie più disparate (Ethernet, Token Ring, FDDI, etc.).
346 Il compito di IP è pertanto quello di trasmettere i pacchetti da un computer
347 all'altro della rete; le caratteristiche essenziali con cui questo viene
348 realizzato in IPv4 sono due:
349
350 \begin{itemize}
351 \item \textit{Universal addressing} la comunicazione avviene fra due host
352   identificati univocamente con un indirizzo a 32 bit che può appartenere ad
353   una sola interfaccia di rete.
354 \item \textit{Best effort} viene assicurato il massimo impegno nella
355   trasmissione, ma non c'è nessuna garanzia per i livelli superiori né sulla
356   percentuale di successo né sul tempo di consegna dei pacchetti di dati.
357 \end{itemize}
358
359 Negli anni '90 la crescita vertiginosa del numero di macchine connesse a
360 internet ha iniziato a far emergere i vari limiti di IPv4, per risolverne i
361 problemi si è perciò definita una nuova versione del protocollo, che (saltando
362 un numero) è diventata la versione 6. IPv6 nasce quindi come evoluzione di
363 IPv4, mantendone inalterate le funzioni che si sono dimostrate valide,
364 eliminando quelle inutili e aggiungendone poche altre per mantenere il
365 protocollo il più snello e veloce possibile.
366
367 I cambiamenti apportati sono comunque notevoli e si possono essere riassunti a
368 grandi linee nei seguenti punti:
369 \begin{itemize}
370 \item l'espansione delle capacità di indirizzamento e instradamento, per
371   supportare una gerarchia con più livelli di indirizzamento, un numero di
372   nodi indirizzabili molto maggiore e una autoconfigurazione degli indirizzi
373 \item l'introduzione un nuovo tipo di indirizzamento, l'\textit{anycast} che
374   si aggiunge agli usuali \textit{unycast} e \textit{multicast}
375 \item la semplificazione del formato dell'intestazione (\textit{header}) dei
376   pacchetti, eliminando o rendendo opzionali alcuni dei campi di IPv4, per
377   eliminare la necessità di riprocessamento della stessa da parte dei router e
378   contenere l'aumento di dimensione dovuto all'ampliamento degli indirizzi
379 \item un supporto per le opzioni migliorato, per garantire una trasmissione
380   più efficiente del traffico normale, limiti meno stringenti sulle dimensioni
381   delle opzioni, e la flessibilità necessaria per introdurne di nuove in
382   futuro
383 \item il supporto per delle capacità di qualità di servizio (QoS) che
384   permettano di identificare gruppi di dati per i quali si può provvedere un
385   trattamento speciale (in vista dell'uso di internet per applicazioni
386   multimediali e/o ``real-time'')
387 \end{itemize}
388
389 Maggiori dettagli riguardo a caratteristiche, notazioni e funzionamento del
390 protocollo IP sono forniti nell'appendice \capref{cha:ip_protocol}.
391
392  
393 \subsection{User Datagram Protocol (UDP)}
394 \label{sec:net_udp}
395
396 UDP è un protocollo di trasporto molto semplice, la sua descrizione completa è
397 contenuta dell'RFC~768, ma in sostanza esso è una semplice interfaccia a IP
398 dal livello di trasporto. Quando un'applicazione usa UDP essa scrive un
399 pacchetto di dati (il cosiddetto \textit{datagram} che da il nome al
400 protocollo) su un socket, al pacchetto viene aggiunto un header molto semplice
401 (per una descrizione più accurata vedi \secref{sec:xxx_udp}), e poi viene
402 passato al livello superiore (IPv4 o IPv6 che sia) che lo spedisce verso la
403 destinazione.  Dato che né IPv4 né IPv6 garantiscono l'affidabilità niente
404 assicura che il pacchetto arrivi a destinazione, né che più pacchetti arrivino
405 nello stesso ordine in cui sono stati spediti.
406
407 Pertanto il problema principale che si affronta quando si usa UDP è la
408 mancanza di affidabilità, se si vuole essere sicuri che i pacchetti arrivino a
409 destinazione occorrerà provvedere con l'applicazione all'interno della quale
410 si dovrà inserire tutto quanto necessario a gestire la notifica di
411 ricevimento, la ritrasmissione, il timeout. 
412
413 Si tenga conto poi che in UDP niente garantisce che i pacchetti arrivino nello
414 stesso ordine in cui sono stati trasmessi, e può anche accadere che i
415 pacchetti vengano duplicati nella trasmissione, e non solo perduti. Di tutto
416 questo di nuovo deve tenere conto l'applicazione.
417
418 Un'altro aspetto di UDP è che se un pacchetto raggiunge correttamente la
419 destinazione esso viene passato all'applicazione ricevente in tutta la sua
420 lunghezza, la trasmissione avviene perciò per \textit{record} la cui lunghezza
421 viene anche essa trasmessa all'applicazione all'atto del ricevimento.
422
423 Infine UDP è un protocollo che opera senza connessione
424 (\textit{connectionless}) in quanto non è necessario stabilire nessun tipo di
425 relazione tra origine e destinazione dei pacchetti. Si hanno così situazioni
426 in cui un client può scrivere su uno stesso socket pacchetti destinati a
427 server diversi, o un server ricevere su un socket pacchetti provenienti da
428 client diversi.  Il modo più semplice di immaginarsi il funzionamento di UDP è
429 quello della radio, in cui si può ``trasmettere a'' e ``ricevere da'' più
430 stazioni usando la stessa frequenza.
431
432 Nonostante gli evidenti svantaggi comportati dall'inaffidabilità UDP ha il
433 grande pregio della velocità che in certi casi è essenziale; inoltre si presta
434 bene per le applicazioni in cui la connessione non è necessaria e
435 costituirebbe solo un peso di prestazioni mentre una perdita di pacchetti può
436 essere tollerata, ad esempio quelle che usano il multicasting.
437
438 \subsection{Transport Control Protocol (TCP)}
439 \label{sec:net_tcp}
440
441 Il TCP è un protocollo molto complesso, definito nell'RFC~739 e completamente
442 diverso da UDP; alla base del suo design infatti non stanno semplicità e
443 velocità, ma la ricerca della massima affidabilità possibile nella
444 trasmissione dei dati.
445
446 La prima differenza con UDP è che TCP provvede sempre una connessione diretta
447 fra un client e un server, attraverso la quale essi possono comunicare; per
448 questo il paragone più appropriato per questo protocollo è quello del
449 collegamento telefonico, in quanto prima viene stabilita una connessione fra
450 due i due capi della comunicazione su cui poi viene quest'ultima viene
451 effettuata.
452
453 Caratteristica fondamentale di TCP è l'affidabilità; quando i dati vengono
454 inviati attraverso una connessione ne viene richiesto un ``ricevuto''
455 (il cosiddetto \textit{acknowlegment}), se questo non arriva essi verranno
456 ritrasmessi per un determinato numero di tentativi, intervallati da un
457 periodo di tempo crescente, fino a che sarà considerata fallita o caduta la
458 connessione (e generato un errore di \textit{time-out}), dopo un periodo di
459 tempo che dipende dall'implementazione e che può variare far i
460 quattro e i dieci minuti.
461
462 Inoltre per tenere conto delle diverse condizioni in cui può trovarsi la linea
463 di comunicazione TCP comprende anche un algoritmo di calcolo dinamico del
464 tempo di andata e ritorno dei pacchetti (il cosiddetto RTT, 
465 \textit{round-trip time}) fra un client e un server che lo rende in grado di
466 adattarsi alle condizioni della rete per non generare inutili ritrasmissioni o
467 cadere facilmente in timeout.
468
469 Inoltre TCP è in grado di preservare l'ordine dei dati assegnando un numero di
470 sequenza ad ogni byte che trasmette. Ad esempio se un'applicazione scrive 3000
471 byte su un socket TCP, questi potranno essere spezzati dal protocollo in due
472 segmenti (le unità di dati passate da TCP a IP vengono chiamate
473 \textit{segment}) di 1500 byte, di cui il primo conterrà il numero di
474 sequenza $1-1500$ e il secondo il numero $1501-3000$. In questo modo anche se
475 i segmenti arrivano a destinazione in un ordine diverso, o se alcuni arrivano
476 più volte a causa di ritrasmissioni dovute alla perdita dei ricevuto,
477 all'arrivo sarà comunque possibile riordinare i dati e scartare i duplicati.
478
479 Il protocollo provvede anche un controllo di flusso (\textit{flow control}),
480 cioè specifica sempre all'altro capo della trasmissione quanti dati può
481 ricevere tramite una \textit{advertised window} (letteralmente finestra
482 annunciata), che indica lo spazio disponibile nel buffer di ricezione,
483 cosicché nella trasmissione non vengano inviati più dati di quelli che possono
484 essere ricevuti. 
485
486 Questa finestra cambia dinamicamente diminuendo con la ricezione dei dati dal
487 socket ed aumentando con la lettura di quest'ultimo da parte
488 dell'applicazione, se diventa nulla il buffer di ricezione è pieno e non
489 verranno accettati altri dati.  Si noti che UDP non provvede niente di tutto
490 ciò per cui nulla impedisce che vengano trasmessi pacchetti ad un rate che il
491 ricevitore non può sostenere.
492
493 Infine attraverso TCP la trasmissione è sempre bidirezionale (in inglese
494 \textit{full-duplex}), è cioè possibile sia trasmettere che ricevere allo
495 stesso tempo, il che poi comporta che quanto dicevamo a proposito del
496 controllo di flusso e della gestione della sequenzialità dei dati viene
497 effettuato per entrambe le direzioni di comunicazione.
498
499 Una descrizione più accurata del protocollo è fornita in appendice
500 \capref{cha:tcp_protocol}.
501
502 \subsection{Limiti e dimensioni riguardanti la trasmissione dei dati}
503 \label{sec:net_lim_dim}
504
505 Un aspetto di cui bisogna tenere conto, e che ritornerà in seguito, è che ci
506 sono una serie di limiti a cui la trasmissione dei dati attraverso i vari
507 livelli del protocollo deve sottostare, limiti che è opportuno tenere presente
508 perché in certi casi si possono avere delle conseguenze sul comportamento
509 delle applicazioni.
510
511 Un elenco di questi limiti è il seguente, insieme ad un breve accenno alle
512 loro origini ed alle eventuali implicazioni che possono avere:
513 \begin{itemize}
514 \item La dimensione massima di un pacchetti IP è di 65535 byte, compreso
515   l'header. Questo è dovuto al fatto che la dimensione è indicata da un campo
516   apposito nell'header di IP che è lungo 16 bit (vedi
517   \figref{fig:IP_ipv4_head}).
518 \item La dimensione massima di un pacchetto normale di IPv6 è di 65575 byte,
519   il campo apposito nell'header infatti è sempre a 16 bit, ma la dimensione
520   dell'header è fissa e di 40 byte e non è compresa nel valore indicato dal
521   suddetto campo. Inoltre IPv6 ha la possibilità di estendere la dimensione di
522   un pacchetto usando la \textit{jumbo payload option}.
523 \item Molte reti fisiche hanno un MTU (\textit{maximum transfer unit}) che
524   dipende dal protocollo specifico usato al livello di link. Il più comune è
525   quello dell'Ethernet che è pari a 1500 byte, una serie di valori possibili
526   sono riportati in \tabref{tab:net_mtu_values}.
527 \end{itemize}
528
529 Quando un pacchetto IP viene inviato su una interfaccia di rete e le sue
530 dimensioni eccedono la MTU viene eseguita la cosiddetta
531 \textit{frammentazione}, i pacchetti cioè vengono spezzati (sia da IPv4 che da
532 IPv6, anche se i pacchetti frammentati sono gestiti con modalità
533 diverse,\footnote{il primo usa un flag nell'header, il secondo una opportuna
534   opzione, si veda \secref{cha:ip_protocol}.}) in blocchi più piccoli che
535 possono essere trasmessi attraverso l'interfaccia.
536
537 \begin{table}[!htb]
538   \centering
539   \begin{tabular}[c]{|l|c|}
540     \hline
541     \textbf{Rete} & \textbf{MTU} \\
542     \hline
543     \hline
544     Hyperlink & 65535 \\
545     Token Ring IBM (16 Mbit/sec) & 17914 \\
546     Token Ring IEEE 802.5 (4 Mbit/sec) & 4464 \\
547     FDDI & 4532 \\
548     Ethernet & 1500 \\
549     X.25 & 576 \\
550     \hline
551   \end{tabular}
552   \caption{Valori della MTU (\textit{maximum transfer unit}) per una serie di
553     reti diverse.}
554   \label{tab:net_mtu_values}
555 \end{table}
556
557 La MTU più piccola fra due stazioni viene in genere chiamata \textit{path
558   MTU}, che dice qual'è la lunghezza massima oltre la quale un pacchetto
559 inviato da una stazione ad un'altra verrebbe senz'altro frammentato. Si tenga
560 conto che non è affatto detto che la \textit{path MTU} sia la stessa in
561 entrambe le direzioni, perché l'instradamento può essere diverso nei due
562 sensi, con diverse tipologie di rete coinvolte.
563
564 Una delle differenze fra IPv4 e IPv6 é che per IPv6 la frammentazione può
565 essere eseguita solo alla sorgente, questo vuol dire che i router IPv6 non
566 frammentano i pacchetti che trasmettono (anche se possono frammentare i
567 pacchetti che generano loro stessi), mentre i router IPv4 si. In ogni caso una
568 volta frammentati i pacchetti possono essere riassemblati solo alla
569 destinazione.
570
571 Nell'header di IPv4 è previsto il flag \texttt{DF} che specifica che il
572 pacchetto non deve essere frammentato; un router che riceva un pacchetto le
573 cui dimensioni eccedano quelle dell'MTU della rete di destinazione genererà un
574 messaggio di errore ICMPv4 di tipo \textit{destination unreachable,
575   fragmentation needed but DF bit set}.
576
577 Dato che i router IPv6 non possono effettuare la frammentazione la ricezione
578 di un pacchetto di dimensione eccessiva per la ritrasmissione genererà sempre
579 un messaggio di errore ICMPv6 di tipo \textit{packet too big}.
580
581 Dato che il meccanismo di frammentazione e riassemblaggio comporta
582 inefficienza normalmente viene utilizzato il procedimento della \textit{path
583   MTU discover} (vedi RFC~1191 per IPv4 e RFC~1981 per IPv6) che permette di
584 trovare il \textit{path MTU} fra due stazioni; per la realizzazione del
585 procedimento si usa il flag DF di IPv4 e il comportamento normale di IPv6
586 inviando delle opportune serie di pacchetti (per i dettagli vedere l'RFC~1191
587 per IPv4 e l'RFC~1981 per IPv6) fintanto che non si hanno più errori. 
588
589 Il TCP usa sempre questo meccanismo, che per le implementazioni di IPv4 è
590 opzionale, mentre diventa obbligatorio per IPv6.  Per IPv6 infatti, non
591 potendo i router frammentare i pacchetti, è necessario, per poter comunicare,
592 conoscere il \textit{path MTU}.
593
594
595 Infine TCP definisce una \textit{maximum segment size} MSS che annuncia
596 all'altro capo la dimensione massima del segmento di dati.
597
598
599 %\subsection{Il passaggio dei dati in TCP}
600 %\label{sec:net_tcp_pass}
601
602 %\subsection{Il passaggio dei dati in UDP}
603 %\label{sec:net_udp_pass}
604
605 %%% Local Variables: 
606 %%% mode: latex
607 %%% TeX-master: "gapil"
608 %%% End: