Finiti file temporanei e iniziata chroot, inserita sezione sullo scheduler
[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 Il concetto fondamentale si basa la programmazione di rete sotto Linux (e
27 sotto Unix in generale) è il modello \textit{client-server} in cui un
28 programma di servizio, il \textit{server} riceve un 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 \ntab.
74
75 \begin{table}[htb]
76   \centering
77   \begin{tabular}{|l|c|c|l|} 
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 \ntab); un confronto fra i due è riportato in \curfig\ dove viene evidenziata
118 anche la corrispondenza fra i rispettivi livelli (che comunque è
119 approssimativa) e su come essi vanno ad inserirsi all'interno del sistema
120 operativo rispetto alla divisione fra user space e kernel space spiegata in
121 \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 \nfig, dove si è riportato il flusso dei dati reali e i protocolli usati per
169 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 del
192   collegamento che si occupa di inserire le opportune informazioni per poter
193   effettuare l'instradamento nella rete ed il recapito alla destinazione
194   finale. In genere questo è il livello di IP (Internet Protocol), a cui
195   vengono inseriti 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 $n$ dalla stazione di
231 destinazione è esattamente lo stesso spedito dal livello $n$ dalla sorgente.
232 Questo rende facile il progettare il software facendo riferimento unicamente a
233 quanto necessario ad un singolo livello, con la confidenza che questo poi sarà
234 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 \pfig) che
251 nei sistemi unix (e non solo) viene inserita la divisione fra kernel space e
252 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 \pfig\ lasciando uno spazio fra UDP e TCP), ma queste vengono
257 usate solo quando si vogliono fare applicazioni di sistema per il controllo
258 della rete a basso livello, un uso quindi molto specialistico, e che non
259 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
269 Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da
270 altri membri. In \nfig\ si è riportato uno schema che mostra un panorama sui
271 vari protocolli della famiglia, e delle loro relazioni reciproche e con
272 alcune dalle principali applicazioni che li usano.
273
274 \begin{figure}[!htbp]
275   \centering
276   \includegraphics[width=10cm]{img/tcpip_overview}  
277   \caption{Panoramica sui vari protocolli che compongono la suite TCP/IP.}
278   \label{fig:net_tcpip_overview}
279 \end{figure}
280
281 I vari protocolli mostrati in figura sono i seguenti:
282
283 \begin{list}{}{}
284 \item \textsl{IPv4} \textit{Internet Protocol version 4}. È quello che
285   comunemente si chiama IP. Ha origine negli anni '80 e da allora è la base su
286   cui è costruita internet. Usa indirizzi a 32 bit e provvede la trasmissione
287   dei pacchetti TCP, UDP, ICMP e IGMP.
288 \item \textsl{IPv6} \textit{Internet Protocol version 6}. È stato progettato a
289   metà degli anni '90 per rimpiazzare IPv4. Ha indirizzi a 128 bit e effettua
290   lo stesso servizio di trasporto di IPv4 per i pacchetti TCP, UDP e ICPMv6.
291 \item \textsl{TCP} \textit{Trasmission Control Protocol}. È un protocollo
292   orientato alla connessione che provvede un trasporto affidabile e
293   bidirezionale di un flusso di dati. I socket TCP sono esempi di
294   \textit{stream socket}. Il protocollo ha cura di tutti gli aspetti del
295   trasporto, come l'acknoweledgment, i timeout, la ritrasmissione, etc. È 
296   usato dalla maggior parte delle applicazioni. Può essere usato sia con IPv4
297   che con IPv6.
298 \item \textsl{UDP} \textit{User Datagram Protocol}. È un protocollo senza
299   connessione a pacchetti. I socket UDP sono esempi di \textit{datagram
300     socket}. Contrariamente al TCP in protocollo non è affidabile e non c'è
301   garanzia che i pacchetti raggiungano la loro destinazione, né sull'eventuale
302   ordine di arrivo. Può essere usato sia con IPv4 che con IPv6.
303 \item \textsl{ICMP} \textit{Internet Control Message Protocol}. Gestisce gli
304   errori e trasporta l'informazione di controllo fra stazioni remote e
305   instradatori (\textit{host} e \textit{router}). I messaggi sono normalmente
306   generati dal software del kernel che gestisce la comunicazione TCP/IP, anche
307   se ICMP può venire usato direttamente da alcuni programmi come
308   \texttt{ping}. A volte ci si riferisce ad esso come ICPMv4 per distinguerlo
309   da ICMPv6.
310 \item \textsl{IGMP} \textit{Internet Group Management Protocol}. É un
311   protocollo usato per il \textit{multicasting} (vedi
312   \secref{sec:xxx_multicast}), che è opzionale in IPv4.
313 \item \textsl{ARP} \textit{Address Resolution Protocol}. È il protocollo che
314   mappa un indirizzo IP in un indirizzo hardware (come un indirizzo
315   internet). È usato in reti di tipo broadcast come Ethernet, Token Ring o
316   FDDI ma non serve in connessioni punto-punto.
317 \item \textsl{RARP} \textit{Reverse Address Resolution Protocol}. È il
318   protocollo che mappa un indirizzo hardware in un indirizzo IP. Viene usato a
319   volte per durante il boot per assegnare un indirizzo IP ad una macchina.
320 \item \textsl{ICMPv6} \textit{Internet Control Message Protocol, version 6}.
321   Combina per IPv6 le funzionalità di ICMPv4, IGMP e ARP.
322 \item \textsl{NETLINK} \textit{Netlink}.
323   Provvede l'interfaccia di accesso alla comunicazione a basso livello.
324 \end{list}
325
326 Gran parte delle applicazioni comunicano usando TCP o UDP, ed alcune si
327 rifanno ad IP (ed i suoi correlati ICMP e IGMP); benché sia TCP che UDP siano
328 basati su IP e sia possibile intervenire a questo livello con i \textit{raw
329   socket} questa tecnica è molto meno diffusa e a parte applicazioni
330 particolari si preferisce sempre usare i servizi messi a disposizione dai due
331 protocolli precedenti.  Per questo motivo a parte alcuni brevi accenni su IP
332 in questa sezione ci concentreremo sul livello di trasporto.
333
334 \subsection{Internet Protocol (IP)}
335 \label{sec:net_ip}
336
337 Quando si parla di IP ci si riferisce in genere alla versione attualmente in
338 uso che è la versione 4 (e viene pertanto chiamato IPv4). Questa versione
339 venne standardizzata nel 1981 dall'RFC~719.
340
341 Internet Protocol nasce per disaccoppiare le applicazioni della struttura
342 hardware delle reti di trasmissione, e creare una interfaccia di trasmissione
343 dei dati indipendente dal sottostante substrato di rete, che può essere
344 realizzato con le tecnologie più disparate (Ethernet, Token Ring, FDDI, etc.).
345 Il compito di IP è pertanto quello di trasmettere i pacchetti da un computer
346 all'altro della rete; le caratteristiche essenziali con cui questo viene
347 realizzato in IPv4 sono due:
348
349 \begin{itemize}
350 \item \textit{Universal addressing} la comunicazione avviene fra due host
351   identificati univocamente con un indirizzo a 32 bit che può appartenere ad
352   una sola interfaccia di rete.
353 \item \textit{Best effort} viene assicurato il massimo impegno nella
354   trasmissione, ma non c'è nessuna garanzia per i livelli superiori né sulla
355   percentuale di successo né sul tempo di consegna dei pacchetti di dati.
356 \end{itemize}
357
358 Negli anni '90 la crescita vertiginosa del numero di macchine connesse a
359 internet ha iniziato a far emergere i vari limiti di IPv4, per risolverne i
360 problemi si è perciò definita una nuova versione del protocollo, che (saltando
361 un numero) è diventata la versione 6. IPv6 nasce quindi come evoluzione di
362 IPv4, mantendone inalterate le funzioni che si sono dimostrate valide,
363 eliminando quelle inutili e aggiungendone poche altre per mantenere il
364 protocollo il più snello e veloce possibile.
365
366 I cambiamenti apportati sono comunque notevoli e si possono essere riassunti a
367 grandi linee nei seguenti punti:
368 \begin{itemize}
369 \item l'espansione delle capacità di indirizzamento e instradamento, per
370   supportare una gerarchia con più livelli di indirizzamento, un numero di
371   nodi indirizzabili molto maggiore e una autoconfigurazione degli indirizzi
372 \item l'introduzione un nuovo tipo di indirizzamento, l'\textit{anycast} che
373   si aggiunge agli usuali \textit{unycast} e \textit{multicast}
374 \item la semplificazione del formato della testata, eliminando o rendendo
375   opzionali alcuni dei campi di IPv4, per eliminare la necessità di
376   riprocessamento della stessa da parte dei router e contenere l'aumento di
377   dimensione dovuto all'ampliamento degli indirizzi
378 \item un supporto per le opzioni migliorato, per garantire una trasmissione
379   più efficiente del traffico normale, limiti meno stringenti sulle dimensioni
380   delle opzioni, e la flessibilità necessaria per introdurne di nuove in
381   futuro
382 \item il supporto per delle capacità di qualità di servizio (QoS) che
383   permettano di identificare gruppi di dati per i quali si può provvedere un
384   trattamento speciale (in vista dell'uso di internet per applicazioni
385   multimediali e/o ``real-time'')
386 \end{itemize}
387
388 Maggiori dettagli riguardo a caratteristiche, notazioni e funzionamento del
389 protocollo IP sono forniti nell'appendice \capref{cha:ip_protocol}.
390
391  
392 \subsection{UDP: User Datagram Protocol)}
393 \label{sec:net_udp}
394
395 UDP è un protocollo di trasporto molto semplice, la sua descrizione completa è
396 contenuta dell'RFC~768, ma in sostanza esso è una semplice interfaccia a IP
397 dal livello di trasporto. Quando un'applicazione usa UDP essa scrive un
398 pacchetto di dati (il cosiddetto \textit{datagram} che da il nome al
399 protocollo) su un socket, al pacchetto viene aggiunto un header molto semplice
400 (per una descrizione più accurata vedi \secref{sec:xxx_udp}), e poi viene
401 passato al livello superiore (IPv4 o IPv6 che sia) che lo spedisce verso la
402 destinazione.  Dato che né IPv4 né IPv6 garantiscono l'affidabilità niente
403 assicura che il pacchetto arrivi a destinazione, né che più pacchetti arrivino
404 nello stesso ordine in cui sono stati spediti.
405
406 Pertanto il problema principale che si affronta quando si usa UDP è la
407 mancanza di affidabilità, se si vuole essere sicuri che i pacchetti arrivino a
408 destinazione occorrerà provvedere con l'applicazione all'interno della quale
409 si dovrà inserire tutto quanto necessario a gestire la notifica di
410 ricevimento, la ritrasmissione, il timeout. 
411
412 Si tenga conto poi che in UDP niente garantisce che i pacchetti arrivino nello
413 stesso ordine in cui sono stati trasmessi, e può anche accadere che i
414 pacchetti vengano duplicati nella trasmissione, e non solo perduti. Di tutto
415 questo di nuovo deve tenere conto l'applicazione.
416
417 Un'altro aspetto di UDP è che se un pacchetto raggiunge correttamente la
418 destinazione esso viene passato all'applicazione ricevente in tutta la sua
419 lunghezza, la trasmissione avviene perciò per \textit{record} la cui lunghezza
420 viene anche essa trasmessa all'applicazione all'atto del ricevimento.
421
422 Infine UDP è un protocollo che opera senza connessione
423 (\textit{connectionless}) in quanto non è necessario stabilire nessun tipo di
424 relazione tra origine e destinazione dei pacchetti. Si hanno così situazioni
425 in cui un client può scrivere su uno stesso socket pacchetti destinati a
426 server diversi, o un server ricevere su un socket pacchetti provenienti da
427 client diversi.  Il modo più semplice di immaginarsi il funzionamento di UDP è
428 quello della radio, in cui si può ``trasmettere a'' e ``ricevere da'' più
429 stazioni usando la stessa frequenza.
430
431 Nonostante gli evidenti svantaggi comportati dall'inaffidabilità UDP ha il
432 grande pregio della velocità che in certi casi è essenziale; inoltre si presta
433 bene per le applicazioni in cui la connessione non è necessaria e
434 costituirebbe solo un peso di prestazioni mentre una perdita di pacchetti può
435 essere tollerata, ad esempio quelle che usano il multicasting.
436
437 \subsection{TCP: Transport Control Protocol)}
438 \label{sec:net_tcp}
439
440 Il TCP è un protocollo molto complesso, definito nell'RFC~739 e completamente
441 diverso da UDP; alla base del suo design infatti non stanno semplicità e
442 velocità, ma la ricerca della massima affidabilità possibile nella
443 trasmissione dei dati.
444
445 La prima differenza con UDP è che TCP provvede sempre una connessione diretta
446 fra un client e un server, attraverso la quale essi possono comunicare; per
447 questo il paragone più appropriato per questo protocollo è quello del
448 collegamento telefonico, in quanto prima viene stabilita una connessione fra
449 due i due capi della comunicazione su cui poi viene quest'ultima viene
450 effettuata.
451
452 Caratteristica fondamentale di TCP è l'affidabilità; quando i dati vengono
453 inviati attraverso una connessione ne viene richiesto un ``ricevuto''
454 (il cosiddetto \textit{acknowlegment}), se questo non arriva essi verranno
455 ritrasmessi per un determinato numero di tentativi, intervallati da un
456 periodo di tempo crescente, fino a che sarà considerata fallita o caduta la
457 connessione (e generato un errore di \textit{time-out}), dopo un periodo di
458 tempo che dipende dall'implementazione e che può variare far i
459 quattro e i dieci minuti.
460
461 Inoltre per tenere conto delle diverse condizioni in cui può trovarsi la linea
462 di comunicazione TCP comprende anche un algoritmo di calcolo dinamico del
463 tempo di andata e ritorno dei pacchetti (il cosiddetto RTT, 
464 \textit{round-trip time}) fra un client e un server che lo rende in grado di
465 adattarsi alle condizioni della rete per non generare inutili ritrasmissioni o
466 cadere facilmente in timeout.
467
468 Inoltre TCP è in grado di preservare l'ordine dei dati assegnando un numero di
469 sequenza ad ogni byte che trasmette. Ad esempio se un'applicazione scrive 3000
470 byte su un socket TCP, questi potranno essere spezzati dal protocollo in due
471 segmenti (le unità di dati passate da TCP a IP vengono chiamate
472 \textit{segment}) di 1500 byte, di cui il primo conterrà il numero di
473 sequenza $1-1500$ e il secondo il numero $1501-3000$. In questo modo anche se
474 i segmenti arrivano a destinazione in un ordine diverso, o se alcuni arrivano
475 più volte a causa di ritrasmissioni dovute alla perdita dei ricevuto,
476 all'arrivo sarà comunque possibile riordinare i dati e scartare i duplicati.
477
478 Il protocollo provvede anche un controllo di flusso (\textit{flow control}),
479 cioè specifica sempre all'altro capo della trasmissione quanti dati può
480 ricevere tramite una \textit{advertised window} (letteralmente finestra
481 annunciata), che indica lo spazio disponibile nel buffer di ricezione,
482 cosicché nella trasmissione non vengano inviati più dati di quelli che possono
483 essere ricevuti. 
484
485 Questa finestra cambia dinamicamente diminuendo con la ricezione dei dati dal
486 socket ed aumentando con la lettura di quest'ultimo da parte
487 dell'applicazione, se diventa nulla il buffer di ricezione è pieno e non
488 verranno accettati altri dati.  Si noti che UDP non provvede niente di tutto
489 ciò per cui nulla impedisce che vengano trasmessi pacchetti ad un rate che il
490 ricevitore non può sostenere.
491
492 Infine attraverso TCP la trasmissione è sempre bidirezionale (in inglese
493 \textit{full-duplex}), è cioè possibile sia trasmettere che ricevere allo
494 stesso tempo, il che poi comporta che quanto dicevamo a proposito del
495 controllo di flusso e della gestione della sequenzialità dei dati viene
496 effettuato per entrambe le direzioni di comunicazione.
497
498 Una descrizione più accurata del protocollo è fornita in appendice
499 \capref{cha:tcp_protocol}.
500
501 \subsection{Limiti e dimensioni riguardanti la trasmissione dei dati}
502 \label{sec:net_lim_dim}
503
504 Un aspetto di cui bisogna tenere conto, e che ritornerà in seguito, è che ci
505 sono una serie di limiti a cui la trasmissione dei dati attraverso i vari
506 livelli del protocollo deve sottostare, limiti che è opportuno tenere presente
507 perché in certi casi si possono avere delle conseguenze sul comportamento
508 delle applicazioni.
509
510 Un elenco di questi limiti è il seguente, insieme ad un breve accenno alle
511 loro origini ed alle eventuali implicazioni che possono avere:
512 \begin{itemize}
513 \item La dimensione massima di un pacchetti IP è di 65535 byte, compreso
514   l'header. Questo è dovuto al fatto che la dimensione è indicata da un campo
515   apposito nell'header di IP che è lungo 16 bit (vedi
516   \tabref{tab:IP_ipv4head}).
517 \item La dimensione massima di un pacchetto normale di IPv6 è di 65575 byte,
518   il campo apposito nell'header infatti è sempre a 16 bit, ma la dimensione
519   dell'header è fissa e di 40 byte e non è compresa nel valore indicato dal
520   suddetto campo. Inoltre IPv6 ha la possibilità di estendere la dimensione di
521   un pacchetto usando la \textit{jumbo payload option}.
522 \item Molte reti fisiche hanno un MTU (\textit{maximum transfer unit}) che
523   dipende dal protocollo specifico usato al livello di link. Il più comune è
524   quello dell'Ethernet che è pari a 1500 byte, una serie di valori possibili
525   sono riportati in \ntab.
526 \end{itemize}
527
528 Quando un pacchetto IP viene inviato su una interfaccia di rete e le sue
529 dimensioni eccedono la MTU viene eseguita la cosiddetta
530 \textit{frammentazione}, i pacchetti cioè vengono spezzati (sia da IPv4 che da
531 IPv6, anche se i pacchetti frammentati sono gestiti con modalità
532 diverse\footnote{il primo usa un flag nell'header, il secondo una opportuna
533   opzione, si veda \secref{cha:ip_protocol}}), in blocchi più piccoli che
534 possono essere trasmessi attraverso l'interfaccia.
535
536 \begin{table}[!htb]
537   \centering
538   \begin{tabular}[c]{|l|c|}
539     \hline
540     \textbf{Rete} & \textbf{MTU} \\
541     \hline
542     \hline
543     Hyperlink & 65535 \\
544     Token Ring IBM (16 Mbit/sec) & 17914 \\
545     Token Ring IEEE 802.5 (4 Mbit/sec) & 4464 \\
546     FDDI & 4532 \\
547     Ethernet & 1500 \\
548     X.25 & 576 \\
549     \hline
550   \end{tabular}
551   \caption{Valori della MTU (\textit{maximum transfer unit}) per una serie di
552     reti diverse.}
553   \label{tab:net_mtu_values}
554 \end{table}
555
556 La MTU più piccola fra due stazioni viene in genere chiamata \textit{path
557   MTU}, che dice qual'è la lunghezza massima oltre la quale un pacchetto
558 inviato da una stazione ad un'altra verrebbe senz'altro frammentato. Si tenga
559 conto che non è affatto detto che la \textit{path MTU} sia la stessa in
560 entrambe le direzioni, perché l'instradamento può essere diverso nei due
561 sensi, con diverse tipologie di rete coinvolte.
562
563 Una delle differenze fra IPv4 e IPv6 é che per IPv6 la frammentazione può
564 essere eseguita solo alla sorgente, questo vuol dire che i router IPv6 non
565 frammentano i pacchetti che trasmettono (anche se possono frammentare i
566 pacchetti che generano loro stessi), mentre i router IPv4 si. In ogni caso una
567 volta frammentati i pacchetti possono essere riassemblati solo alla
568 destinazione.
569
570 Nell'header di IPv4 è previsto il flag \texttt{DF} che specifica che il
571 pacchetto non deve essere frammentato; un router che riceva un pacchetto le
572 cui dimensioni eccedano quelle dell'MTU della rete di destinazione genererà un
573 messaggio di errore ICMPv4 di tipo \textit{destination unreachable,
574   fragmentation needed but DF bit set}.
575
576 Dato che i router IPv6 non possono effettuare la frammentazione la ricezione
577 di un pacchetto di dimensione eccessiva per la ritrasmissione genererà sempre
578 un messaggio di errore ICMPv6 di tipo \textit{packet too big}.
579
580 Dato che il meccanismo di frammentazione e riassemblaggio comporta
581 inefficienza normalmente viene utilizzato il procedimento della \textit{path
582   MTU discover} (vedi RFC~1191 per IPv4 e RFC~1981 per IPv6) che permette di
583 trovare il \textit{path MTU} fra due stazioni; per la realizzazione del
584 procedimento si usa il flag DF di IPv4 e il comportamento normale di IPv6
585 inviando delle opportune serie di pacchetti (per i dettagli vedere l'RFC~1191
586 per IPv4 e l'RFC~1981 per IPv6) fintanto che non si hanno più errori. 
587
588 Il TCP usa sempre questo meccanismo, che per le implementazioni di IPv4 è
589 opzionale, mentre diventa obbligatorio per IPv6.  Per IPv6 infatti, non
590 potendo i router frammentare i pacchetti, è necessario, per poter comunicare,
591 conoscere il \textit{path MTU}.
592
593
594 Infine TCP definisce una \textit{maximum segment size} MSS che annuncia
595 all'altro capo la dimensione massima del segmento di dati.
596
597
598 %\subsection{Il passaggio dei dati in TCP}
599 %\label{sec:net_tcp_pass}
600
601 %\subsection{Il passaggio dei dati in UDP}
602 %\label{sec:net_udp_pass}