1 \chapter{Introduzione alla programmazione di rete}
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.
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.
15 \section{Il modello client-server}
16 \label{sec:net_cliserv}
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
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.
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.
37 Normalmente si dividono i server in due categorie principali, e vengono detti
38 \textsl{concorrenti} o \textsl{iterativi}, sulla base del loro comportamento.
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
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.
53 \section{I protocolli di rete}
54 \label{sec:net_protocols}
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.
63 \subsection{Il modello ISO/OSI}
64 \label{sec:net_iso_osi}
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}.
77 \begin{tabular}{|l|c|c|}
79 \textbf{Livello} & \multicolumn{2}{|c|}{\textbf{Nome}} \\
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} \\
91 \caption{I sette livelli del protocollo ISO/OSI.}
92 \label{tab:net_osilayers}
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.
104 \begin{figure}[!htbp]
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}
113 \subsection{Il modello DoD (TCP/IP)}
114 \label{sec:net_tcpip_overview}
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}.
125 \begin{tabular}{|l|c|c|l|}
127 \textbf{Livello} & \multicolumn{2}{|c|}{\textbf{Nome}} & \textbf{Esempi} \\
130 Livello 1&\textit{Application} &\textsl{Applicazione}&
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 \\
138 \caption{I quattro livelli del protocollo TCP/IP.}
139 \label{tab:net_layers}
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:
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.
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.
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}
178 La struttura della comunicazione pertanto si può riassumere nei seguenti passi:
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).
203 \subsection{Criteri generali del design di TCP/IP}
204 \label{sec:net_tcpip_design}
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.
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.
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.
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
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.
237 \section{Il protocollo TCP/IP}
238 \label{sec:net_tpcip}
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
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.
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.
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.
267 \subsection{Il quadro generale}
268 \label{sec:net_tcpip_general}
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.
275 \begin{figure}[!htbp]
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}
282 I vari protocolli mostrati in figura sono i seguenti:
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
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
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.
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.
335 \subsection{Internet Protocol (IP)}
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.
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:
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.
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.
367 I cambiamenti apportati sono comunque notevoli e si possono essere riassunti a
368 grandi linee nei seguenti punti:
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
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'')
389 Maggiori dettagli riguardo a caratteristiche, notazioni e funzionamento del
390 protocollo IP sono forniti nell'appendice \capref{cha:ip_protocol}.
393 \subsection{User Datagram Protocol (UDP)}
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.
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.
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.
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.
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.
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.
438 \subsection{Transport Control Protocol (TCP)}
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.
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
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.
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.
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.
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
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.
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.
499 Una descrizione più accurata del protocollo è fornita in appendice
500 \capref{cha:tcp_protocol}.
502 \subsection{Limiti e dimensioni riguardanti la trasmissione dei dati}
503 \label{sec:net_lim_dim}
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
511 Un elenco di questi limiti è il seguente, insieme ad un breve accenno alle
512 loro origini ed alle eventuali implicazioni che possono avere:
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}.
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.
539 \begin{tabular}[c]{|l|c|}
541 \textbf{Rete} & \textbf{MTU} \\
545 Token Ring IBM (16 Mbit/sec) & 17914 \\
546 Token Ring IEEE 802.5 (4 Mbit/sec) & 4464 \\
552 \caption{Valori della MTU (\textit{maximum transfer unit}) per una serie di
554 \label{tab:net_mtu_values}
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.
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
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}.
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}.
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.
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}.
595 Infine TCP definisce una \textit{maximum segment size} MSS che annuncia
596 all'altro capo la dimensione massima del segmento di dati.
599 %\subsection{Il passaggio dei dati in TCP}
600 %\label{sec:net_tcp_pass}
602 %\subsection{Il passaggio dei dati in UDP}
603 %\label{sec:net_udp_pass}
607 %%% TeX-master: "gapil"