3 %% Copyright (C) 2000-2016 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
12 \chapter{Introduzione alla programmazione di rete}
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 al modello più comune usato
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.
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
29 \section{Modelli di programmazione}
30 \label{sec:net_prog_model}
33 La differenza principale fra un'applicazione di rete e un programma normale è
34 che quest'ultima per definizione concerne la comunicazione fra processi
35 diversi, che in generale non girano neanche sulla stessa macchina. Questo già
36 prefigura un cambiamento completo rispetto all'ottica del programma monolitico
37 all'interno del quale vengono eseguite tutte le istruzioni, e chiaramente
38 presuppone un sistema operativo multitasking in grado di eseguire più processi
41 In questa prima sezione esamineremo brevemente i principali modelli di
42 programmazione in uso. Ne daremo una descrizione assolutamente generica e
43 superficiale, che ne illustri le caratteristiche principali, non essendo fra
44 gli scopi del testo approfondire questi argomenti.
46 \subsection{Il modello \textit{client-server}}
47 \label{sec:net_cliserv}
49 L'architettura fondamentale su cui si basa gran parte della programmazione di
50 rete sotto Linux (e sotto Unix in generale) è il modello
51 \textit{client-server} caratterizzato dalla presenza di due categorie di
52 soggetti, i programmi di servizio, chiamati \textit{server}, che ricevono le
53 richieste e forniscono le risposte, ed i programmi di utilizzo, detti
56 In generale un server può (di norma deve) essere in grado di rispondere a più
57 di un client, per cui è possibile che molti programmi possano interagire
58 contemporaneamente, quello che contraddistingue il modello però è che
59 l'architettura dell'interazione è sempre nei termini di molti verso uno, il
60 server, che viene ad assumere un ruolo privilegiato.
62 Seguono questo modello tutti i servizi fondamentali di Internet, come le
63 pagine web, la posta elettronica, ftp, telnet, ssh e praticamente ogni
64 servizio che viene fornito tramite la rete, anche se, come abbiamo visto, il
65 modello è utilizzato in generale anche per programmi che non fanno
66 necessariamente uso della rete, come gli esempi che abbiamo usato in
67 cap.~\ref{cha:IPC} a proposito della comunicazione fra processi nello stesso
70 Normalmente si dividono i server in due categorie principali, e vengono detti
71 \textsl{concorrenti} o \textsl{iterativi}, sulla base del loro comportamento.
72 Un \textsl{server iterativo} risponde alla richiesta inviando i dati e resta
73 occupato e non rispondendo ad ulteriori richieste fintanto che non ha fornito
74 una risposta alla richiesta. Una volta completata la risposta il server
75 diventa di nuovo disponibile.
77 Un \textsl{server concorrente} al momento di trattare la richiesta crea un
78 processo figlio (o un \textit{thread}) incaricato di fornire i servizi
79 richiesti, per porsi immediatamente in attesa di ulteriori richieste. In
80 questo modo, con sistemi multitasking, più richieste possono essere
81 soddisfatte contemporaneamente. Una volta che il processo figlio ha concluso
82 il suo lavoro esso di norma viene terminato, mentre il server originale resta
86 \subsection{Il modello \textit{peer-to-peer}}
87 \label{sec:net_peertopeer}
89 Come abbiamo visto il tratto saliente dell'architettura \textit{client-server}
90 è quello della preminenza del server rispetto ai client, le architetture
91 \textit{peer-to-peer} si basano su un approccio completamente opposto che è
92 quello di non avere nessun programma che svolga un ruolo preminente.
94 Questo vuol dire che in generale ciascun programma viene ad agire come un nodo
95 in una rete potenzialmente paritetica; ciascun programma si trova pertanto a
96 ricevere ed inviare richieste ed a ricevere ed inviare risposte, e non c'è più
97 la separazione netta dei compiti che si ritrova nelle architetture
98 \textit{client-server}.
100 Le architetture \textit{peer-to-peer} sono salite alla ribalta con
101 l'esplosione del fenomeno Napster, ma gli stessi protocolli di routing sono un
102 buon esempio di architetture \textit{peer-to-peer}, in cui ciascun nodo,
103 tramite il demone che gestisce il routing, richiede ed invia informazioni ad
106 In realtà in molti casi di architetture classificate come
107 \textit{peer-to-peer} non è detto che la struttura sia totalmente paritetica e
108 ci sono parecchi esempi in cui alcuni servizi vengono centralizzati o
109 distribuiti gerarchicamente, come avveniva per lo stesso Napster, in cui le
110 ricerche erano effettuate su un server centrale.
114 \subsection{Il modello \textit{three-tier}}
115 \label{sec:net_three_tier}
117 Benché qui sia trattato a parte, il modello \textit{three-tier} in realtà è
118 una estensione del modello \textit{client-server}. Con il crescere della
119 quantità dei servizi forniti in rete (in particolare su Internet) ed al numero
120 di accessi richiesto. Si è così assistito anche ad una notevole crescita di
121 complessità, in cui diversi servizi venivano ad essere integrati fra di loro.
123 In particolare sempre più spesso si assiste ad una integrazione di servizi di
124 database con servizi di web, in cui le pagine vengono costruite dinamicamente
125 sulla base dei dati contenuti nel database. In tutti questi casi il problema
126 fondamentale di una architettura \textit{client-server} è che la richiesta di
127 un servizio da parte di un gran numero di client si scontra con il collo di
128 bottiglia dell'accesso diretto ad un unico server, con gravi problemi di
131 Rispondere a queste esigenze di scalabilità il modello più semplice (chiamato
132 talvolta \textit{two-tier}) da adottare è stata quello di distribuire il
133 carico delle richieste su più server identici, mantenendo quindi
134 sostanzialmente inalterata l'architettura \textit{client-server} originale.
136 Nel far questo ci si scontra però con gravi problemi di manutenibilità dei
137 servizi, in particolare per quanto riguarda la sincronizzazione dei dati, e di
138 inefficienza dell'uso delle risorse. Il problema è particolarmente grave ad
139 esempio per i database che non possono essere replicati e sincronizzati
140 facilmente, e che sono molto onerosi, la loro replicazione è costosa e
143 È a partire da queste problematiche che nasce il modello \textit{three-tier},
144 che si struttura, come dice il nome, su tre livelli. Il primo livello, quello
145 dei client che eseguono le richieste e gestiscono l'interfaccia con l'utente,
146 resta sostanzialmente lo stesso del modello \textit{client-server}, ma la
147 parte server viene suddivisa in due livelli, introducendo un
148 \textit{middle-tier}, su cui deve appoggiarsi tutta la logica di analisi delle
149 richieste dei client per ottimizzare l'accesso al terzo livello, che è quello
150 che si limita a fornire i dati dinamici che verranno usati dalla logica
151 implementata nel \textit{middle-tier} per eseguire le operazioni richieste dai
154 In questo modo si può disaccoppiare la logica dai dati, replicando la prima,
155 che è molto meno soggetta a cambiamenti ed evoluzione, e non soffre di
156 problemi di sincronizzazione, e centralizzando opportunamente i secondi. In
157 questo modo si può distribuire il carico ed accedere in maniera efficiente i
161 \subsection{Il modello \textit{broadcast}}
162 \label{sec:net_broadcast}
164 Uno specifico modello relativo alla programmazione di rete è poi quello in cui
165 è possibile, invece della classica comunicazione uno ad uno comunque usata in
166 tutti i modelli precedenti (anche nel \texttt{peer to peer} la comunicazione è
167 comunque fra singoli ``\textit{peer}''), una comunicazione da uno a molti.
171 Questo modello nasce dal fatto che molte tecnologie di rete (ed in particolare
172 la Ethernet, che è probabilmente la più diffusa) hanno il supporto per
173 effettuare una comunicazione in cui un nodo qualunque della rete più inviare
174 informazioni in contemporanea a tutti gli altri. In questo caso si parla di
175 \textit{broadcast}, utilizzando la nomenclatura usata per le trasmissioni
176 radio, anche se in realtà questo tipo di comunicazione è eseguibile da un nodo
177 qualunque per cui tutti quanti possono ricoprire sia il ruolo di trasmettitore
178 che quello di ricevitore.
182 In genere si parla di \textit{broadcast} quando la trasmissione uno a molti è
183 possibile fra qualunque nodo di una rete e gli altri, ed è supportata
184 direttamente dalla tecnologia di collegamento utilizzata. L'utilizzo di questa
185 forma di comunicazione da uno a molti però può risultare molto utile anche
186 quando questo tipo di supporto non è disponibile (come ad esempio su Internet,
187 dove non si possono contattare tutti i nodi presenti).
191 In tal caso alcuni protocolli di rete (e quelli usati per Internet sono fra
192 questi) supportano una variante del\textit{broadcast}, detta
193 \textit{multicast}, in cui resta possibile fare una comunicazione uno a molti,
194 in cui una applicazione invia i pacchetti a molte altre, in genere passando
195 attraverso un opportuno supporto degli apparati ed una qualche forma di
196 registrazione che consente la distribuzione della cominicazione ai nodi
201 Ovviamente i programmi che devono realizzare un tipo di comunicazione di
202 questo tipo (come ad esempio potrebbero essere quelli che effettuano uno
203 \textit{streaming} di informazioni) devono rispondere a delle problematiche
204 del tutto diverse da quelle classiche illustrate nei modelli precedenti, e
205 costituiscono pertanto un'altra classe completamente a parte.
208 \section{I protocolli di rete}
209 \label{sec:net_protocols}
211 Parlando di reti di computer si parla in genere di un insieme molto vasto ed
212 eterogeneo di mezzi di comunicazione che vanno dal cavo telefonico, alla fibra
213 ottica, alle comunicazioni via satellite o via radio; per rendere possibile la
214 comunicazione attraverso un così variegato insieme di mezzi sono stati
215 adottati molti protocolli, il più famoso dei quali, quello alla base del
216 funzionamento di Internet, è il gruppo di protocolli comunemente chiamato
219 \subsection{Il modello ISO/OSI}
220 \label{sec:net_iso_osi}
222 Una caratteristica comune dei protocolli di rete è il loro essere strutturati
223 in livelli sovrapposti; in questo modo ogni protocollo di un certo livello
224 realizza le sue funzionalità basandosi su un protocollo del livello
225 sottostante. Questo modello di funzionamento è stato standardizzato dalla
226 \textit{International Standards Organization} (ISO) che ha preparato fin dal
227 1984 il Modello di Riferimento \textit{Open Systems Interconnection} (OSI),
228 strutturato in sette livelli, secondo quanto riportato in
229 tab.~\ref{tab:net_osilayers}.
233 \begin{tabular}{|l|c|c|}
235 \textbf{Livello} & \multicolumn{2}{|c|}{\textbf{Nome}} \\
238 Livello 7&\textit{Application} &\textsl{Applicazione}\\
239 Livello 6&\textit{Presentation} &\textsl{Presentazione} \\
240 Livello 5&\textit{Session} &\textsl{Sessione} \\
241 Livello 4&\textit{Transport} &\textsl{Trasporto} \\
242 Livello 3&\textit{Network} &\textsl{Rete}\\
243 Livello 2&\textit{DataLink} &\textsl{Collegamento Dati} \\
244 Livello 1&\textit{Physical} &\textsl{Connessione Fisica} \\
247 \caption{I sette livelli del protocollo ISO/OSI.}
248 \label{tab:net_osilayers}
251 Il modello ISO/OSI è stato sviluppato in corrispondenza alla definizione della
252 serie di protocolli X.25 per la commutazione di pacchetto; come si vede è un
253 modello abbastanza complesso\footnote{infatti per memorizzarne i vari livelli
254 è stata creata la frase \textit{All people seem to need data processing}, in
255 cui ciascuna parola corrisponde all'iniziale di uno dei livelli.}, tanto che
256 usualmente si tende a suddividerlo in due parti, secondo lo schema mostrato in
257 fig.~\ref{fig:net_osi_tcpip_comp}, con un \textit{upper layer} che riguarda
258 solo le applicazioni, che viene realizzato in \textit{user space}, ed un
259 \textit{lower layer} in cui si mescolano la gestione fatta dal kernel e le
260 funzionalità fornite dall'hardware.
262 Il modello ISO/OSI mira ad effettuare una classificazione completamente
263 generale di ogni tipo di protocollo di rete; nel frattempo però era stato
264 sviluppato anche un altro modello, relativo al protocollo TCP/IP, che è quello
265 su cui è basata Internet, che è diventato uno standard de facto. Questo
266 modello viene talvolta chiamato anche modello \textit{DoD} (sigla che sta per
267 \textit{Department of Defense}), dato che fu sviluppato dall'agenzia ARPA per
268 il Dipartimento della Difesa Americano.
272 \includegraphics[width=12cm]{img/iso_tcp_comp}
273 \caption{Struttura a livelli dei protocolli OSI e TCP/IP, con la relative
274 corrispondenze e la divisione fra \textit{kernel space} e \textit{user
276 \label{fig:net_osi_tcpip_comp}
279 La scelta fra quale dei due modelli utilizzare dipende per lo più dai gusti
280 personali. Come caratteristiche generali il modello ISO/OSI è più teorico e
281 generico, basato separazioni funzionali, mentre il modello TCP/IP è più vicino
282 alla separazione concreta dei vari strati del sistema operativo; useremo
283 pertanto quest'ultimo, anche per la sua maggiore semplicità. Questa semplicità
284 ha un costo quando si fa riferimento agli strati più bassi, che sono in
285 effetti descritti meglio dal modello ISO/OSI, in quanto gran parte dei
286 protocolli di trasmissione hardware sono appunto strutturati sui due livelli
287 di \textit{Data Link} e \textit{Connection}.
290 \subsection{Il modello TCP/IP (o DoD)}
291 \label{sec:net_tcpip_overview}
293 Così come ISO/OSI anche il modello del TCP/IP è stato strutturato in livelli
294 (riassunti in tab.~\ref{tab:net_layers}); un confronto fra i due è riportato
295 in fig.~\ref{fig:net_osi_tcpip_comp} dove viene evidenziata anche la
296 corrispondenza fra i rispettivi livelli (che comunque è approssimativa) e su
297 come essi vanno ad inserirsi all'interno del sistema rispetto alla divisione
298 fra \textit{user space} e \textit{kernel space} spiegata in
299 sez.~\ref{sec:intro_unix_struct}.\footnote{in realtà è sempre possibile
300 accedere dallo \textit{user space}, attraverso una opportuna interfaccia
301 (come vedremo in sez.~\ref{sec:sock_sa_packet}), ai livelli inferiori del
306 \begin{tabular}{|l|c|c|l|}
308 \textbf{Livello} & \multicolumn{2}{|c|}{\textbf{Nome}} & \textbf{Esempi} \\
311 Livello 4 & \textit{Application} & \textsl{Applicazione}&
313 Livello 3 & \textit{Transport} & \textsl{Trasporto} & TCP, UDP\\
314 Livello 2 & \textit{Network} & \textsl{Rete} & IP, (ICMP, IGMP)\\
315 Livello 1 & \textit{Link} & \textsl{Collegamento}&
316 Device driver \& scheda di interfaccia\\
319 \caption{I quattro livelli del protocollo TCP/IP.}
320 \label{tab:net_layers}
323 Come si può notare come il modello TCP/IP è più semplice del modello ISO/OSI
324 ed è strutturato in soli quattro livelli. Il suo nome deriva dai due
325 principali protocolli che lo compongono, il TCP (\textit{Trasmission Control
326 Protocol}) che copre il livello 3 e l'IP (\textit{Internet Protocol}) che
327 copre il livello 2. Le funzioni dei vari livelli sono le seguenti:
329 \begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
330 \item[\textbf{Applicazione}] É relativo ai programmi di interfaccia con la
331 rete, in genere questi vengono realizzati secondo il modello client-server
332 (vedi sez.~\ref{sec:net_cliserv}), realizzando una comunicazione secondo un
333 protocollo che è specifico di ciascuna applicazione.
334 \item[\textbf{Trasporto}] Fornisce la comunicazione tra le due stazioni
335 terminali su cui girano gli applicativi, regola il flusso delle
336 informazioni, può fornire un trasporto affidabile, cioè con recupero degli
337 errori o inaffidabile. I protocolli principali di questo livello sono il TCP
339 \item[\textbf{Rete}] Si occupa dello smistamento dei singoli pacchetti su una
340 rete complessa e interconnessa, a questo stesso livello operano i protocolli
341 per il reperimento delle informazioni necessarie allo smistamento, per lo
342 scambio di messaggi di controllo e per il monitoraggio della rete. Il
343 protocollo su cui si basa questo livello è IP (sia nella attuale versione,
344 IPv4, che nella nuova versione, IPv6).
345 \item[\textbf{Collegamento}] È responsabile per l'interfacciamento al
346 dispositivo elettronico che effettua la comunicazione fisica, gestendo
347 l'invio e la ricezione dei pacchetti da e verso l'hardware.
350 La comunicazione fra due stazioni remote avviene secondo le modalità
351 illustrate in fig.~\ref{fig:net_tcpip_data_flux}, dove si è riportato il flusso
352 dei dati reali e i protocolli usati per lo scambio di informazione su ciascun
353 livello. Si è genericamente indicato \textit{ethernet} per il livello 1, anche
354 se in realtà i protocolli di trasmissione usati possono essere molti altri.
357 \centering \includegraphics[width=13cm]{img/tcp_data_flux}
358 \caption{Strutturazione del flusso dei dati nella comunicazione fra due
359 applicazioni attraverso i protocolli della suite TCP/IP.}
360 \label{fig:net_tcpip_data_flux}
363 Per chiarire meglio la struttura della comunicazione attraverso i vari
364 protocolli mostrata in fig.~\ref{fig:net_tcpip_data_flux}, conviene prendere in
365 esame i singoli passaggi fatti per passare da un livello al sottostante,
366 la procedura si può riassumere nei seguenti passi:
368 \item Le singole applicazioni comunicano scambiandosi i dati ciascuna secondo
369 un suo specifico formato. Per applicazioni generiche, come la posta o le
370 pagine web, viene di solito definito ed implementato quello che viene
371 chiamato un protocollo di applicazione (esempi possono essere HTTP, POP,
372 SMTP, ecc.), ciascuno dei quali è descritto in un opportuno standard, di
373 solito attraverso un RFC (l'acronimo RFC sta per
374 \itindex{Request~For~Comment~(RFC)} \textit{Request For Comment} ed è la
375 procedura attraverso la quale vengono proposti gli standard per Internet).
376 \item I dati delle applicazioni vengono inviati al livello di trasporto usando
377 un'interfaccia opportuna (i \textit{socket}, che esamineremo in dettaglio in
378 cap.~\ref{cha:socket_intro}). Qui verranno spezzati in pacchetti di
379 dimensione opportuna e inseriti nel protocollo di trasporto, aggiungendo ad
380 ogni pacchetto le informazioni necessarie per la sua gestione. Questo
381 processo viene svolto direttamente nel kernel, ad esempio dallo stack TCP,
382 nel caso il protocollo di trasporto usato sia questo.
383 \item Una volta composto il pacchetto nel formato adatto al protocollo di
384 trasporto usato questo sarà passato al successivo livello, quello di rete,
385 che si occupa di inserire le opportune informazioni per poter effettuare
386 l'instradamento nella rete ed il recapito alla destinazione finale. In
387 genere questo è il livello di IP (Internet Protocol), a cui vengono inseriti
388 i numeri IP che identificano i computer su Internet.
389 \item L'ultimo passo è il trasferimento del pacchetto al driver della
390 interfaccia di trasmissione, che si incarica di incapsularlo nel relativo
391 protocollo di trasmissione. Questo può avvenire sia in maniera diretta, come
392 nel caso di ethernet, in cui i pacchetti vengono inviati sulla linea
393 attraverso le schede di rete, che in maniera indiretta con protocolli come
394 PPP o SLIP, che vengono usati come interfaccia per far passare i dati su
395 altri dispositivi di comunicazione (come la seriale o la parallela).
399 \subsection{Criteri generali dell'architettura del TCP/IP}
400 \label{sec:net_tcpip_design}
402 La filosofia architetturale del TCP/IP è semplice: costruire una rete che
403 possa sopportare il carico in transito, ma permettere ai singoli nodi di
404 scartare pacchetti se il carico è temporaneamente eccessivo, o se risultano
405 errati o non recapitabili.
407 L'incarico di rendere il recapito pacchetti affidabile non spetta al livello
408 di rete, ma ai livelli superiori. Pertanto il protocollo IP è per sua natura
409 inaffidabile, in quanto non è assicurata né una percentuale di successo né un
410 limite sui tempi di consegna dei pacchetti.
412 È il livello di trasporto che si deve occupare (qualora necessiti) del
413 controllo del flusso dei dati e del recupero degli errori; questo è realizzato
414 dal protocollo TCP. La sede principale di "\textit{intelligenza}" della rete è
415 pertanto al livello di trasporto o ai livelli superiori.
417 Infine le singole stazioni collegate alla rete non fungono soltanto da punti
418 terminali di comunicazione, ma possono anche assumere il ruolo di
419 \textit{router} (\textsl{instradatori}), per l'interscambio di pacchetti da
420 una rete ad un'altra. Questo rende possibile la flessibilità della rete che è
421 in grado di adattarsi ai mutamenti delle interconnessioni.
423 La caratteristica essenziale che rende tutto ciò possibile è la strutturazione
424 a livelli tramite l'incapsulamento. Ogni pacchetto di dati viene incapsulato
425 nel formato del livello successivo, fino al livello del collegamento fisico.
426 In questo modo il pacchetto ricevuto ad un livello \textit{n} dalla stazione
427 di destinazione è esattamente lo stesso spedito dal livello \textit{n} dalla
428 sorgente. Questo rende facile il progettare il software facendo riferimento
429 unicamente a quanto necessario ad un singolo livello, con la confidenza che
430 questo poi sarà trattato uniformemente da tutti i nodi della rete.
433 \section{La struttura del TCP/IP}
434 \label{sec:net_tpcip}
436 Come accennato in sez.~\ref{sec:net_protocols} il TCP/IP è un insieme di
437 protocolli diversi, che operano su 4 livelli diversi. Per gli interessi della
438 programmazione di rete però sono importanti principalmente i due livelli
439 centrali, e soprattutto quello di trasporto.
441 La principale interfaccia usata nella programmazione di rete, quella dei
442 socket (vedi sez.~\ref{cha:socket_intro}), è infatti un'interfaccia nei
443 confronti di quest'ultimo. Questo avviene perché al di sopra del livello di
444 trasporto i programmi hanno a che fare solo con dettagli specifici delle
445 applicazioni, mentre al di sotto vengono curati tutti i dettagli relativi alla
446 comunicazione. È pertanto naturale definire una interfaccia di programmazione
447 su questo confine, tanto più che è proprio lì (come evidenziato in
448 fig.~\ref{fig:net_osi_tcpip_comp}) che nei sistemi Unix (e non solo) viene
449 inserita la divisione fra \textit{kernel space} e \textit{user space}.
451 In realtà in un sistema Unix è possibile accedere anche agli altri livelli (e
452 non solo a quello di trasporto) con opportune interfacce di programmazione
453 (vedi sez.~\ref{sec:sock_sa_packet}), ma queste vengono usate solo quando si
454 debbano fare applicazioni di sistema per il controllo della rete a basso
455 livello, di uso quindi molto specialistico.
457 In questa sezione daremo una descrizione sommaria dei vari protocolli del
458 TCP/IP, concentrandoci, per le ragioni appena esposte, sul livello di
459 trasporto. All'interno di quest'ultimo privilegeremo poi il protocollo TCP,
460 per il ruolo centrale che svolge nella maggior parte delle applicazioni.
463 \subsection{Il quadro generale}
464 \label{sec:net_tcpip_general}
466 Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da
467 molti membri. In fig.~\ref{fig:net_tcpip_overview} si è riportato uno schema
468 che mostra un panorama sui principali protocolli della famiglia, e delle loro
469 relazioni reciproche e con alcune dalle principali applicazioni che li usano.
473 \includegraphics[width=13cm]{img/tcpip_overview}
474 \caption{Panoramica sui vari protocolli che compongono la suite TCP/IP.}
475 \label{fig:net_tcpip_overview}
478 I vari protocolli riportati in fig.~\ref{fig:net_tcpip_overview} sono i
480 \begin{basedescript}{\desclabelwidth{1.7cm}\desclabelstyle{\nextlinelabel}}
481 \item[\textsl{IPv4}] \textit{Internet Protocol version 4}. È quello che
482 comunemente si chiama IP. Ha origine negli anni '80 e da allora è la base su
483 cui è costruita Internet. Usa indirizzi a 32 bit, e mantiene tutte le
484 informazioni di instradamento e controllo per la trasmissione dei pacchetti
485 sulla rete; tutti gli altri protocolli della suite (eccetto ARP e RARP, e
486 quelli specifici di IPv6) vengono trasmessi attraverso di esso.
487 \item[\textsl{IPv6}] \textit{Internet Protocol version 6}. È stato progettato
488 a metà degli anni '90 per rimpiazzare IPv4. Ha uno spazio di indirizzi
489 ampliato 128 bit che consente più gerarchie di indirizzi,
490 l'auto-configurazione, ed un nuovo tipo di indirizzi, gli \textit{anycast},
491 che consentono di inviare un pacchetto ad una stazione su un certo gruppo.
492 Effettua lo stesso servizio di trasmissione dei pacchetti di IPv4 di cui
493 vuole essere un sostituto.
494 \item[\textsl{TCP}] \textit{Trasmission Control Protocol}. È un protocollo
495 orientato alla connessione che provvede un trasporto affidabile per un
496 flusso di dati bidirezionale fra due stazioni remote. Il protocollo ha cura
497 di tutti gli aspetti del trasporto, come l'\textit{acknoweledgment} (il
498 ricevuto), i timeout, la ritrasmissione, ecc. È usato dalla maggior parte
500 \item[\textsl{UDP}] \textit{User Datagram Protocol}. È un protocollo senza
501 connessione, per l'invio di dati a pacchetti. Contrariamente al TCP il
502 protocollo non è affidabile e non c'è garanzia che i pacchetti raggiungano
503 la loro destinazione, si perdano, vengano duplicati, o abbiano un
504 particolare ordine di arrivo.
505 \item[\textsl{ICMP}] \textit{Internet Control Message Protocol}. È il
506 protocollo usato a livello 2 per gestire gli errori e trasportare le
507 informazioni di controllo fra stazioni remote e instradatori (cioè fra
508 \textit{host} e \textit{router}). I messaggi sono normalmente generati dal
509 software del kernel che gestisce la comunicazione TCP/IP, anche se ICMP può
510 venire usato direttamente da alcuni programmi come \cmd{ping}. A volte ci
511 si riferisce ad esso come ICPMv4 per distinguerlo da ICMPv6.
512 \item[\textsl{IGMP}] \textit{Internet Group Management Protocol}. É un
513 protocollo di livello 2 usato per il \textit{multicast} (vedi
514 sez.~\ref{sec:xxx_multicast}). Permette alle stazioni remote di notificare
515 ai router che supportano questa comunicazione a quale gruppo esse
516 appartengono. Come ICMP viene implementato direttamente sopra IP.
517 \item[\textsl{ARP}] \textit{Address Resolution Protocol}. È il protocollo che
518 mappa un indirizzo IP in un indirizzo hardware sulla rete locale. È usato in
519 reti di tipo \textit{broadcast} come Ethernet, Token Ring o FDDI che hanno
520 associato un indirizzo fisico (il \textit{MAC address}) alla interfaccia, ma
521 non serve in connessioni punto-punto.
522 \item[\textsl{RARP}] \textit{Reverse Address Resolution Protocol}. È il
523 protocollo che esegue l'operazione inversa rispetto ad ARP (da cui il nome)
524 mappando un indirizzo hardware in un indirizzo IP. Viene usato a volte per
525 durante l'avvio per assegnare un indirizzo IP ad una macchina.
526 \item[\textsl{ICMPv6}] \textit{Internet Control Message Protocol, version 6}.
527 Combina per IPv6 le funzionalità di ICMPv4, IGMP e ARP.
528 \item[\textsl{EGP}] \textit{Exterior Gateway Protocol}. È un protocollo di
529 routing usato per comunicare lo stato fra gateway vicini a livello di
530 \textsl{sistemi autonomi} (vengono chiamati \textit{autonomous
531 systems} i raggruppamenti al livello più alto della rete), con
532 meccanismi che permettono di identificare i vicini, controllarne la
533 raggiungibilità e scambiare informazioni sullo stato della rete. Viene
534 implementato direttamente sopra IP.
535 \item[\textsl{OSPF}] \textit{Open Shortest Path First}. È in protocollo di
536 routing per router su reti interne, che permette a questi ultimi di
537 scambiarsi informazioni sullo stato delle connessioni e dei legami che
538 ciascuno ha con gli altri. Viene implementato direttamente sopra IP.
539 \item[\textsl{GRE}] \textit{Generic Routing Encapsulation}. È un protocollo
540 generico di incapsulamento che permette di incapsulare un qualunque altro
541 protocollo all'interno di IP.
542 \item[\textsl{AH}] \textit{Authentication Header}. Provvede l'autenticazione
543 dell'integrità e dell'origine di un pacchetto. È una opzione nativa in IPv6
544 e viene implementato come protocollo a sé su IPv4. Fa parte della suite di
545 IPSEC che provvede la trasmissione cifrata ed autenticata a livello IP.
546 \item[\textsl{ESP}] \textit{Encapsulating Security Payload}. Provvede la
547 cifratura insieme all'autenticazione dell'integrità e dell'origine di un
548 pacchetto. Come per AH è opzione nativa in IPv6 e viene implementato come
549 protocollo a sé su IPv4.
550 \item[\textsl{PPP}] \textit{Point-to-Point Protocol}. È un protocollo a
551 livello 1 progettato per lo scambio di pacchetti su connessioni punto punto.
552 Viene usato per configurare i collegamenti, definire i protocolli di rete
553 usati ed incapsulare i pacchetti di dati. È un protocollo complesso con
555 \item[\textsl{SLIP}] \textit{Serial Line over IP}. È un protocollo di livello
556 1 che permette di trasmettere un pacchetto IP attraverso una linea seriale.
559 Gran parte delle applicazioni comunicano usando TCP o UDP, solo alcune, e per
560 scopi particolari si rifanno direttamente ad IP (ed i suoi correlati ICMP e
561 IGMP); benché sia TCP che UDP siano basati su IP e sia possibile intervenire a
562 questo livello con i \textit{raw socket} questa tecnica è molto meno diffusa e
563 a parte applicazioni particolari si preferisce sempre usare i servizi messi a
564 disposizione dai due protocolli precedenti. Per questo, motivo a parte alcuni
565 brevi accenni su IP in questa sezione, ci concentreremo sul livello di
568 \subsection{Internet Protocol (IP)}
571 Quando si parla di IP ci si riferisce in genere alla versione attualmente in
572 uso che è la versione 4 (e viene pertanto chiamato IPv4). Questa versione
573 venne standardizzata nel 1981
574 dall'\href{http://www.ietf.org/rfc/rfc0719.txt}{RFC~719}.
576 Internet Protocol nasce per disaccoppiare le applicazioni della struttura
577 hardware delle reti di trasmissione, e creare una interfaccia di trasmissione
578 dei dati indipendente dal sottostante substrato di rete, che può essere
579 realizzato con le tecnologie più disparate (Ethernet, Token Ring, FDDI, ecc.).
580 Il compito di IP è pertanto quello di trasmettere i pacchetti da un computer
581 all'altro della rete; le caratteristiche essenziali con cui questo viene
582 realizzato in IPv4 sono due:
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.
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.
601 I cambiamenti apportati sono comunque notevoli e si possono essere riassunti a
602 grandi linee nei seguenti punti:
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
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'').
623 Maggiori dettagli riguardo a caratteristiche, notazioni e funzionamento del
624 protocollo IP sono forniti nell'appendice sez.~\ref{sec:ip_protocol}.
627 \subsection{User Datagram Protocol (UDP)}
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
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.
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.
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.
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.
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}.
675 \subsection{Transport Control Protocol (TCP)}
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.
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.
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
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.
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.
717 \itindbeg{advertised~window}
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.
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.
733 \itindend{advertised~window}
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.
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}.
745 \subsection{Limiti e dimensioni riguardanti la trasmissione dei dati}
746 \label{sec:net_lim_dim}
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
755 Un elenco di questi limiti, insieme ad un breve accenno alle loro origini ed
756 alle eventuali implicazioni che possono avere, è il seguente:
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}.
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}.}
784 \begin{tabular}[c]{|l|c|}
786 \textbf{Rete} & \textbf{MTU} \\
790 Token Ring IBM (16 Mbit/sec) & 17914 \\
791 Token Ring IEEE 802.5 (4 Mbit/sec) & 4464 \\
797 \caption{Valori della MTU (\textit{Maximum Transfer Unit}) per una serie di
798 diverse tecnologie di rete.}
799 \label{tab:net_mtu_values}
802 %TODO aggiornare la tabella con dati più recenti
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.
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.
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}.
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.
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}.
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.
853 \itindend{Maximum~Transfer~Unit~(MTU)}
858 %%% TeX-master: "gapil"
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