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