-\chapter{Introduzione alla rete}
-
-In questo capitolo sarà fatta un'introduzione ai contetti generali che
-servono come prerequisiti per capire ed
-esamineremo a grandi linee i protocolli di rete e come questi sono organizzati
-e interagiscono.
+%% network.tex
+%%
+%% Copyright (C) 2000-2003 Simone Piccardi. Permission is granted to
+%% copy, distribute and/or modify this document under the terms of the GNU Free
+%% Documentation License, Version 1.1 or any later version published by the
+%% Free Software Foundation; with the Invariant Sections being "Prefazione",
+%% with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the
+%% license is included in the section entitled "GNU Free Documentation
+%% License".
+%%
+\part{Programmazione di rete}
+\label{part:progr-di-rete}
+
+\chapter{Introduzione alla programmazione di rete}
+\label{cha:network}
+
+In questo capitolo sarà fatta un'introduzione ai concetti generali che servono
+come prerequisiti per capire la programmazione di rete, non tratteremo quindi
+aspetti specifici ma faremo una breve introduzione al modello più comune usato
+nella programmazione di rete, per poi passare ad un esame a grandi linee dei
+protocolli di rete e di come questi sono organizzati e interagiscono.
+
+In particolare, avendo assunto l'ottica di un'introduzione mirata alla
+programmazione, ci concentreremo sul protocollo più diffuso, il TCP/IP, che è
+quello che sta alla base di internet, avendo cura di sottolineare i concetti
+più importanti da conoscere per la scrittura dei programmi.
+
+
+
+\section{Modelli di programmazione}
+\label{sec:net_prog_model}
+
+
+La differenza principale fra un'applicazione di rete e un programma normale è
+che quest'ultima per definizione concerne la comunicazione fra processi
+diversi, che in generale non girano neanche sulla stessa macchina. Questo già
+prefigura un cambiamento completo rispetto all'ottica del programma monolitico
+all'interno del quale vengono eseguite tutte le istruzioni, e chiaramente
+presuppone un sistema operativo multitasking in grado di eseguire più processi
+contemporaneamente.
+
+In questa prima sezione esamineremo brevemente i principali modelli di
+programmazione in uso. Ne daremo una descrizione assolutamente generica e
+superficiale, che ne illustri le caratteristiche principali, non essendo fra
+gli scopi del testo approfondire questi argomenti.
+
+\subsection{Il modello \textit{client-server}}
+\label{sec:net_cliserv}
+
+L'architettura fondamentale su cui si basa gran parte della programmazione di
+rete sotto Linux (e sotto Unix in generale) è il modello
+\textit{client-server} caratterizzato dalla presenza di due categorie di
+soggetti, i programmi di servizio, chiamati \textit{server}, che ricevono le
+richieste e forniscono le risposte, ed i programmi di utilizzo, detti
+\textit{client}.
+
+In generale un server può (di norma deve) essere in grado di rispondere a più
+di un client, per cui è possibile che molti programmi possano interagire
+contemporaneamente, quello che contraddistingue il modello però è che
+l'architettura dell'interazione è sempre nei termini di molti verso uno, il
+server, che viene ad assumere un ruolo privilegiato.
+
+Seguono questo modello tutti i servizi fondamentali di internet, come le
+pagine web, la posta elettronica, ftp, telnet, ssh e praticamente ogni
+servizio che viene fornito tramite la rete, anche se, come abbiamo visto, il
+modello è utilizzato in generale anche per programmi che, come gli esempi che
+abbiamo usato in \capref{cha:IPC} a proposito della comunicazione fra processi
+nello stesso sistema, non fanno necessariamente uso della rete.
+
+Normalmente si dividono i server in due categorie principali, e vengono detti
+\textsl{concorrenti} o \textsl{iterativi}, sulla base del loro comportamento.
+Un \textsl{server iterativo} risponde alla richiesta inviando i dati e resta
+occupato e non rispondendo ad ulteriori richieste fintanto che non ha fornito
+una risposta alla richiesta. Una volta completata la risposta il server
+diventa di nuovo disponibile.
+
+Un \textsl{server concorrente} al momento di trattare la richiesta crea un
+processo figlio (o un thread) incaricato di fornire i servizi richiesti, per
+porsi immediatamente in attesa di ulteriori richieste. In questo modo, con
+sistemi multitasking, più richieste possono essere soddisfatte
+contemporaneamente. Una volta che il processo figlio ha concluso il suo lavoro
+esso di norma viene terminato, mentre il server originale resta sempre attivo.
+
+
+\subsection{Il modello \textit{peer-to-peer}}
+\label{sec:net_peertopeer}
+
+Come abbiamo visto il tratto saliente dell'architettura \textit{client-server}
+è quello della preminenza del server rispetto ai client, le architetture
+\textit{peer-to-peer} si basano su un approccio completamente opposto che è
+quello di non avere nessun programma che svolga un ruolo preminente.
+
+Questo vuol dire che in generale ciascun programma viene ad agire come un nodo
+in una rete potenzialmente paritetica; ciascun programma si trova pertanto a
+ricevere ed inviare richieste ed a ricevere ed inviare risposte, e non c'è più
+la separazione netta dei compiti che si ritrova nelle architetture
+\textit{client-server}.
+
+Le architetture \textit{peer-to-peer} sono salite alla ribalta con
+l'esplosione del fenomeno Napster, ma gli stessi protocolli di routing sono un
+buon esempio di architetture \textit{peer-to-peer}, in cui ciascun nodo,
+tramite il demone che gestisce il routing, richiede ed invia informazioni ad
+altri nodi.
+
+In realtà in molti casi di architetture classificate come \textit{peer-to-peer}
+non è detto che la struttura sia totalmente paritetica e ci sono parecchi
+esempi in cui alcuni servizi vengono centralizzati o distribuiti
+gerarchicamente, come per lo stesso Napster, in cui le ricerche venivano
+effettuate su un server centrale.
+
+
+
+\subsection{Il modello \textit{three-tier}}
+\label{sec:net_three_tier}
+
+Benché qui sia trattato a parte, il modello \textit{three-tier} in realtà è
+una estensione del modello \textit{client-server}. Con il crescere della
+quantità dei servizi forniti in rete (in particolare su internet) ed al numero
+di accessi richiesto. Si è così assistito anche ad una notevole crescita di
+complessità, in cui diversi servizi venivano ad essere integrati fra di loro.
+
+In particolare sempre più spesso si assiste ad una integrazione di servizi di
+database con servizi di web, in cui le pagine vengono costruite dinamicamente
+sulla base dei dati contenuti nel database. In tutti questi casi il problema
+fondamentale di una architettura \textit{client-server} è che la richiesta di
+un servizio da parte di un gran numero di client si scontra con il collo di
+bottiglia dell'accesso diretto ad un unico server, con gravi problemi di
+scalabilità.
+
+Rispondere a queste esigenze di scalabilità il modello più semplice (chiamato
+talvolta \textit{two-tier}) da adottare è stata quello di distribuire il
+carico delle richieste su più server identici, mantenendo quindi
+sostanzialmente inalterata l'architettura \textit{client-server} originale.
+
+Nel far questo ci si scontra però con gravi problemi di manutenibilità dei
+servizi, in particolare per quanto riguarda la sincronizzazione dei dati, e di
+inefficienza dell'uso delle risorse. Il problema è particolarmente grave ad
+esempio per i database che non possono essere replicati e sincronizzati
+facilmente, e che sono molto onerosi, la loro replicazione è costosa e
+complessa.
+
+È a partire da queste problematiche che nasce il modello \textit{three-tier},
+che si struttura, come dice il nome, su tre livelli. Il primo livello, quello
+dei client che eseguono le richieste e gestiscono l'interfaccia con l'utente,
+resta sostanzialmente lo stesso del modello \textit{client-server}, ma la
+parte server viene suddivisa in due livelli, introducendo un
+\textit{middle-tier}, su cui deve appoggiarsi tutta la logica di analisi delle
+richieste dei client per ottimizzare l'accesso al terzo livello, che è quello
+che si limita a fornire i dati dinamici che verranno usati dalla logica
+implementata nel \textit{middle-tier} per eseguire le operazioni richieste dai
+client.
+
+In questo modo si può disaccoppiare la logica dai dati, replicando la prima,
+che è molto meno soggetta a cambiamenti ed evoluzione, e non soffre di
+problemi di sincronizzazione, e centralizzando opportunamente i secondi. In
+questo modo si può distribuire il carico ed accedere in maniera efficiente i
+dati.
\section{I protocolli di rete}
-\label{sec:layer}
+\label{sec:net_protocols}
Parlando di reti di computer si parla in genere di un insieme molto vasto ed
-eterogeneo di mezzi di comunicazione che vanno dal cavo telefonico, alla
-fibra ottica, alle comunicazioni via satellite; per rendere possibile la
+eterogeneo di mezzi di comunicazione che vanno dal cavo telefonico, alla fibra
+ottica, alle comunicazioni via satellite o via radio; per rendere possibile la
comunicazione attraverso un così variegato insieme di mezzi sono stati
adottati una serie di protocolli, il più famoso dei quali, quello alla base
-del funzionamento di internet, é il cosiddetto TCP/IP.
+del funzionamento di internet, è il protocollo TCP/IP.
\subsection{Il modello ISO/OSI}
-\label{sec:iso_osi}
+\label{sec:net_iso_osi}
Una caratteristica comune dei protocolli di rete è il loro essere strutturati
-in livelli sovrapposti; in questo modo un livello superiore esegue richieste
-al livello sottostante e da questo riceve responsi, mentre livelli uguali su
-macchine diverse conversano tramite lo stesso protocollo. Questo modello di
-funzionamento è stato stato standardizzato dalla International Standards
-Organization (ISO) che ha preparato fin dal 1984 il Modello di Riferimento
-Open Systems Interconnection (OSI), strutturato in a sette livelli, secondo la
-tabella in \ntab.
+in livelli sovrapposti; in questo modo ogni protocollo di un certo livello
+realizza le sue funzionalità basandosi su un protocollo del livello
+sottostante. Questo modello di funzionamento è stato stato standardizzato
+dalla \textit{International Standards Organization} (ISO) che ha preparato fin
+dal 1984 il Modello di Riferimento \textit{Open Systems Interconnection}
+(OSI), strutturato in sette livelli, secondo quanto riportato in
+\tabref{tab:net_osilayers}.
\begin{table}[htb]
\centering
- \begin{tabular}{l c c l}
- \textbf{Livello} & \multicolumn{2}{c}{\textbf{Nome}} & \\
+ \begin{tabular}{|l|c|c|}
+ \hline
+ \textbf{Livello} & \multicolumn{2}{|c|}{\textbf{Nome}} \\
\hline
- Livello 7&\textit{Application} &\textsl{Applicazione}& \\
- Livello 6&\textit{Presentation} &\textsl{Presentazione}& \\
- Livello 5&\textit{Session} &\textsl{Sessione}& \\
- Livello 4&\textit{Transport} &\textsl{Trasporto}& \\
- Livello 3&\textit{Network} &\textsl{Rete}& \\
- Livello 2&\textit{DataLink} &\textsl{Collegamento Dati}& \\
- Livello 1&\textit{Connection} &\textsl{Connessione Fisica}& \\
+ \hline
+ Livello 7&\textit{Application} &\textsl{Applicazione}\\
+ Livello 6&\textit{Presentation} &\textsl{Presentazione} \\
+ Livello 5&\textit{Session} &\textsl{Sessione} \\
+ Livello 4&\textit{Transport} &\textsl{Trasporto} \\
+ Livello 3&\textit{Network} &\textsl{Rete}\\
+ Livello 2&\textit{DataLink} &\textsl{Collegamento Dati} \\
+ Livello 1&\textit{Physical} &\textsl{Connessione Fisica} \\
\hline
\end{tabular}
\caption{I sette livelli del protocollo ISO/OSI.}
-\label{tab:osilayers}
+\label{tab:net_osilayers}
\end{table}
-Il modello ISO/OSI è stato sviluppato corrispondentemente alla definizione
-della serie di protocolli X.25 per la commutazione di pacchetto. Ma nonostante
-il lavoro dettagliato di standardizzazione il modello si è rivelato
-sostanzialmente troppo complesso e poco flessibile rispetto a quello,
-precedente, su cui si basa TCP/IP che è diventato uno standard de facto;
-quest'ultimo viene comunemente chiamato modello DoD (Department of Defense),
-dato che fu sviluppato dall'agenzia ARPA per il Dipartimento della Difesa
-Americano.
-
-\subsection{Il protocollo TCP/IP}
-\label{sec:tcpip_overview}
-
-Così come ISO/OSI anche TCP/IP è stato strutturato in livelli (riassunti in
-\ntab); un confronto fra i due è riportato in \nfig dove viene evidenziata
-anche la corrispondenza fra i rispettivi livelli (che comunque è
-approssimativa) e come essi vanno ad inserirsi all'interno del sistema
-operativo, riguardo alla divisione fra user space e kernel space spiegata in
-\ref{sec:unix_struct}.
-
-% L'attuale Internent Protocol (IPv4) viene standardizzato nel 1981
-% dall'RFC~719; esso nasce per disaccoppiare le applicazioni della struttura
-% hardware delle reti di trasmissione, e creare una interfaccia di trasmissione
-% dei dati indipendente dal sottostante substrato di rete, che può essere
-% realizzato con le tecnologie più disparate (Ethernet, Token Ring, FDDI,
-% etc.).
-
-% In realtà IP realizza solo una parte di tutto questo, e fa parte di un
-% sistema che va sotto il nome di TCP/IP che è,
-% uno di
-% questi, quello responsabile del trasporto dei pacchetti fra le varie reti che
-% compongono Internet, è appunto IP.
+Il modello ISO/OSI è stato sviluppato in corrispondenza alla definizione della
+serie di protocolli X.25 per la commutazione di pacchetto; come si vede è un
+modello abbastanza complesso\footnote{infatti per memorizzarne i vari livelli
+ è stata creata la frase \texttt{All people seem to need data processing}, in
+ cui ciascuna parola corrisponde all'iniziale di uno dei livelli.}, tanto che
+usualmente si tende a suddividerlo in due parti, secondo lo schema mostrato in
+\figref{fig:net_osi_tcpip_comp}, con un \textit{upper layer} che riguarda solo
+le applicazioni, che viene realizzato in user space, ed un \textit{lower
+ layer} in cui si mescolano la gestione fatta dal kernel e le funzionalità
+fornite dall'hardware.
+
+Il modello ISO/OSI mira ad effettuare una classificazione completamente
+generale di ogni tipo di protocollo di rete; nel frattempo però era stato
+sviluppato anche un altro modello, relativo al protocollo TCP/IP, che è quello
+su cui è basata internet, che è diventato uno standard de facto. Questo
+modello viene talvolta chiamato anche modello \textit{DoD} (sigla che sta per
+\textit{Department of Defense}), dato che fu sviluppato dall'agenzia ARPA per
+il Dipartimento della Difesa Americano.
+
+\begin{figure}[!htb]
+ \centering
+ \includegraphics[width=13cm]{img/iso_tcp_comp}
+ \caption{Struttura a livelli dei protocolli OSI e TCP/IP, con la
+ relative corrispondenze e la divisione fra kernel e user space.}
+ \label{fig:net_osi_tcpip_comp}
+\end{figure}
+
+La scelta fra quale dei due modelli utilizzare dipende per lo più dai gusti
+personali. Come caratteristiche generali il modello ISO/OSI è più teorico e
+generico, basato separazioni funzionali, mentre il modello TCP/IP è più vicino
+alla separazione concreta dei vari strati del sistema operativo; useremo
+pertanto quest'ultimo, anche per la sua maggiore semplicità.\footnote{questa
+ semplicità ha un costo quando si fa riferimento agli strati più bassi, che
+ sono in effetti descritti meglio dal modello ISO/OSI, in quanto gran parte
+ dei protocolli di trasmissione hardware sono appunto strutturati sui due
+ livelli di \textit{Data Link} e \textit{Connection}.}
+
+\subsection{Il modello TCP/IP (o DoD)}
+\label{sec:net_tcpip_overview}
+
+Così come ISO/OSI anche il modello del TCP/IP è stato strutturato in livelli
+(riassunti in \tabref{tab:net_layers}); un confronto fra i due è riportato in
+\figref{fig:net_osi_tcpip_comp} dove viene evidenziata anche la corrispondenza
+fra i rispettivi livelli (che comunque è approssimativa) e su come essi vanno
+ad inserirsi all'interno del sistema rispetto alla divisione fra user space e
+kernel space spiegata in \secref{sec:intro_unix_struct}.\footnote{in realtà è
+ sempre possibile accedere dallo user space, attraverso una opportuna
+ interfaccia (come vedremo in \secref{sec:sock_sa_packet}), ai livelli
+ inferiori del protocollo.}
\begin{table}[htb]
\centering
- \begin{tabular}{l c c l}
- \textbf{Livello} & \multicolumn{2}{c}{\textbf{Nome}} & \textbf{Esempi} \\
+ \begin{tabular}{|l|c|c|l|}
\hline
- Livello 1&\textit{Application} &\textsl{Applicazione}&
+ \textbf{Livello} & \multicolumn{2}{|c|}{\textbf{Nome}} & \textbf{Esempi} \\
+ \hline
+ \hline
+ Livello 4&\textit{Application} &\textsl{Applicazione}&
Telnet, FTP, etc. \\
- Livello 2&\textit{Transport} &\textsl{Trasporto}& TCP, UDP \\
- Livello 3&\textit{Network} &\textsl{Rete}& IP, (ICMP, IGMP) \\
- Livello 4&\textit{Link} &\textsl{Connessione}&
+ Livello 3&\textit{Transport} &\textsl{Trasporto}& TCP, UDP \\
+ Livello 2&\textit{Network} &\textsl{Rete}& IP, (ICMP, IGMP) \\
+ Livello 1&\textit{Link} &\textsl{Collegamento}&
device driver \& scheda di interfaccia \\
\hline
\end{tabular}
-\caption{I quattro livelli del protocollo TPC/IP.}
-\label{tab:layers}
+\caption{I quattro livelli del protocollo TCP/IP.}
+\label{tab:net_layers}
\end{table}
-
-Come si può notare TCP/IP è più semplice del modello ISO/OSI e strutturato in
-soli quattro livelli. Il suo nome deriva dai due principali protocolli che lo
-compongono, il TCP \textit{Trasmission Control Protocol} e l'IP
-\textit{Internet Protocol}. Le funzioni dei vari livelli sono le seguenti:
-
-\begin{description}
-\item \textbf{Applicazione} É relativo ai programmi di interfaccia utente, in
- genere questi vengono realizzati secondo il modello Client-Server (vedi
- \ref{sec:cliserv}.
-\item \textbf{Trasporto} Fornisce la comunicazione tra le due stazioni
+Come si può notare come il modello TCP/IP è più semplice del modello ISO/OSI
+ed è strutturato in soli quattro livelli. Il suo nome deriva dai due
+principali protocolli che lo compongono, il TCP (\textit{Trasmission Control
+ Protocol}) che copre il livello 3 e l'IP (\textit{Internet Protocol}) che
+copre il livello 2. Le funzioni dei vari livelli sono le seguenti:
+
+\begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
+\item[\textbf{Applicazione}] É relativo ai programmi di interfaccia con la
+ rete, in genere questi vengono realizzati secondo il modello client-server
+ (vedi \secref{sec:net_cliserv}), realizzando una comunicazione secondo un
+ protocollo che è specifico di ciascuna applicazione.
+\item[\textbf{Trasporto}] Fornisce la comunicazione tra le due stazioni
terminali su cui girano gli applicativi, regola il flusso delle
- informazioni, e può fornire un trasporto affidabile, cioè con recupero
- errori. Il protocollo principale di questo livello è il TCP.
-\item \textbf{Rete} Si occupa dello smistamento dei singoli pacchetti su una
+ informazioni, può fornire un trasporto affidabile, cioè con recupero degli
+ errori o inaffidabile. I protocolli principali di questo livello sono il TCP
+ e l'UDP.
+\item[\textbf{Rete}] Si occupa dello smistamento dei singoli pacchetti su una
rete complessa e interconnessa, a questo stesso livello operano i protocolli
per il reperimento delle informazioni necessarie allo smistamento, per lo
scambio di messaggi di controllo e per il monitoraggio della rete. Il
protocollo su cui si basa questo livello è IP (sia nella attuale versione,
- IPv4 che nella nuova IPv6).
-\item \textbf{Connessione} È responsabile per l'interfacciamento al
+ IPv4, che nella nuova versione, IPv6).
+\item[\textbf{Collegamento}] È responsabile per l'interfacciamento al
dispositivo elettronico che effettua la comunicazione fisica, gestendo
- l'invio e la ricezione dall'hardware dei pacchetti.
-\end{description}
-
-
-La comunicazione fra due stazioni avviene pertanto secondo le modalità
-illustrate in \nfig.
-
-Le singole applicazioni si scambieranno i dati secondo un loro formato
-specifico, implementando un protocollo di applicazione (esempi possono essere
-HTTP, POP, telnet, SMTP, etc).
-
-Questi dati vengono inviati al livello di trasporto usando un'interfaccia
-opportuna (i \textit{socket}, che esamineremo in dettaglio in seguito), i
-quali li spezzerà in pacchetti di dimensione opportuna e li incapsulerà
-all'interno del suo protocollo di trasporto aggiungendo ad ogni pacchetto le
-informazioni necessarie alla gestione di quest'ultimo. Questo processo viene
-svolto dirattamente nel kernel ad esempio dallo stack TCP nel caso il
-protocollo di trasporto sia questo.
-
-Una volta composto il pacchetto nel formato adatto al protocollo di trasporto
-usato questo sarà passato al successivo livello, quello del collegamento che
-si occupa di inserire le opportune informazioni per poter effettuare
-l'instradamento nella rete ed il recapito alla destinazione finale. In genere
-questo è il livello di IP (Internet Protocol), a cui vengono inseriti i numeri
-IP che identificano i computer su internet.
-
-L'ultimo passo è il trasferimento del pacchetto al driver della interfaccia di
-trasmissione che si incarica di incapsularlo nel relativo protocollo di
-trasmissione fisica usato dall'hardware usato per la comunicazione (ad esempio
-ethernet per una scheda di rete).
-
-
-\subsection{Criteri generali del design di TCP/IP}
-
-
-La filosofia architetturale di TCP/IP è semplice: costruire una rete che
+ l'invio e la ricezione dei pacchetti da e verso l'hardware.
+\end{basedescript}
+
+La comunicazione fra due stazioni remote avviene secondo le modalità
+illustrate in \figref{fig:net_tcpip_data_flux}, dove si è riportato il flusso
+dei dati reali e i protocolli usati per lo scambio di informazione su ciascun
+livello. Si è genericamente indicato \textit{ethernet} per il livello 1, anche
+se in realtà i protocolli di trasmissione usati possono essere molti altri.
+
+\begin{figure}[!htb]
+ \centering \includegraphics[width=13cm]{img/tcp_data_flux}
+ \caption{Strutturazione del flusso dei dati nella comunicazione fra due
+ applicazioni attraverso i protocolli della suite TCP/IP.}
+ \label{fig:net_tcpip_data_flux}
+\end{figure}
+
+Per chiarire meglio la struttura della comunicazione attraverso i vari
+protocolli mostrata in \figref{fig:net_tcpip_data_flux}, conviene prendere in
+esame i singoli passaggi fatti per passare da un livello al sottostante,
+la procedura si può riassumere nei seguenti passi:
+\begin{itemize}
+\item Le singole applicazioni comunicano scambiandosi i dati ciascuna secondo
+ un suo specifico formato. Per applicazioni generiche, come la posta o le
+ pagine web, viene di solito definito ed implementato quello che viene
+ chiamato un protocollo di applicazione (esempi possono essere HTTP, POP,
+ SMTP, ecc.), ciascuno dei quali è descritto in un opportuno standard (di
+ solito attraverso un RFC\footnote{L'acronimo RFC sta per \textit{Request For
+ Comment} ed è la procedura attraverso la quale vengono proposti gli
+ standard per Internet.}).
+\item I dati delle applicazioni vengono inviati al livello di trasporto usando
+ un'interfaccia opportuna (i \textit{socket}\index{socket}, che esamineremo
+ in dettaglio in \capref{cha:socket_intro}). Qui verranno spezzati in
+ pacchetti di dimensione opportuna e inseriti nel protocollo di trasporto,
+ aggiungendo ad ogni pacchetto le informazioni necessarie per la sua
+ gestione. Questo processo viene svolto direttamente nel kernel, ad esempio
+ dallo stack TCP, nel caso il protocollo di trasporto usato sia questo.
+\item Una volta composto il pacchetto nel formato adatto al protocollo di
+ trasporto usato questo sarà passato al successivo livello, quello di rete,
+ che si occupa di inserire le opportune informazioni per poter effettuare
+ l'instradamento nella rete ed il recapito alla destinazione finale. In
+ genere questo è il livello di IP (Internet Protocol), a cui vengono inseriti
+ i numeri IP che identificano i computer su internet.
+\item L'ultimo passo è il trasferimento del pacchetto al driver della
+ interfaccia di trasmissione, che si incarica di incapsularlo nel relativo
+ protocollo di trasmissione. Questo può avvenire sia in maniera diretta, come
+ nel caso di ethernet, in cui i pacchetti vengono inviati sulla linea
+ attraverso le schede di rete, che in maniera indiretta con protocolli come
+ PPP o SLIP, che vengono usati come interfaccia per far passare i dati su
+ altri dispositivi di comunicazione (come la seriale o la parallela).
+\end{itemize}
+
+
+\subsection{Criteri generali dell'architettura del TCP/IP}
+\label{sec:net_tcpip_design}
+
+La filosofia architetturale del TCP/IP è semplice: costruire una rete che
possa sopportare il carico in transito, ma permettere ai singoli nodi di
scartare pacchetti se il carico è temporaneamente eccessivo, o se risultano
errati o non recapitabili.
È il livello di trasporto che si deve occupare (qualora necessiti) del
controllo del flusso dei dati e del recupero degli errori; questo è realizzato
dal protocollo TCP. La sede principale di "intelligenza" della rete è pertanto
-al livello di trasporto o superiore.
+al livello di trasporto o ai livelli superiori.
Infine le singole stazioni collegate alla rete non fungono soltanto da punti
-terminali di comunicazione, ma possono anche assumere il ruolo di router, per
-l'interscambio di pacchetti da una rete ad un'altra. Questo rende possibile la
-flessibilità della rete che è in grado di adattarsi ai mutamenti delle
-interconnessioni.
+terminali di comunicazione, ma possono anche assumere il ruolo di
+\textit{router} (\textsl{instradatori}), per l'interscambio di pacchetti da
+una rete ad un'altra. Questo rende possibile la flessibilità della rete che è
+in grado di adattarsi ai mutamenti delle interconnessioni.
La caratteristica essenziale che rende tutto ciò possibile è la strutturazione
a livelli tramite l'incapsulamento. Ogni pacchetto di dati viene incapsulato
-nel formato del livello successivo, fino al livello della connessione fisica.
-In questo modo il pacchetto ricevuto ad un livello $n$ dalla stazione di
-destinazione è esattamente lo stesso spedito dal livello $n$ dalla sorgente.
-Questo rende facile il progettare il software facendo riferimento unicamente a
-quanto necessario ad un singolo livello, con la confidenza che questo poi sarà
-trattato uniformemente da tutti i nodi della rete.
-
-
-
-\section{Il modello client-server}
-\label{sec:cliserv}.
-
-La differenza principale fra un'applicazione di rete e un programma normale
-è che quest'ultima per definizione concerne la comunicazione fra
-``processi'' diversi (che in generale non girano neanche sulla stessa
-macchina). Questo già prefigura un cambiamento completo rispetto all'ottica
-del ``programma'' monolitico all'interno del quale vengono eseguite tutte le
-istruzioni, e presuppone un sistema operativo ``multitasking'' in grado di
-eseguire processi diversi.
-
-Il concetto fondamentale si basa la programmazione di rete sotto Linux (e
-sotto Unix in generale) è il modello \textit{client-server} in cui un
-programma di servizio, il \textit{server} riceve un connessione e risponde a
-un programma di utilizzo, il \textit{client}, provvedendo a quest'ultimo un
-definito insieme di servizi.
-
-Esempi di questo modello sono il WEB, ftp, telnet, ssh e praticamente ogni
-servizio che viene fornito tramite la rete, ma il modello è utilizzato in
-generale anche per programmi di uso locale.
-
-Normalmente si dividono i server in due categorie principali,
-\textit{concorrenti} e \textit{iterativi}, sulla base del loro comportamento.
-
-Un server iterativo risponde alla richiesta inviando i dati e resta occupato
-(non rispondendo ad ulteriori richieste) fintanto che non ha concluso la
-richiesta. Una volta completata la richiesta il server diventa di nuovo
-disponibile.
-
-Un server concorrente al momento di trattare la richiesta crea un processo
-figlio incaricato di fornire i servizi richiesti, per poi porsi in attesa di
-ulteriori richieste. In questo modo più richieste possono essere soddisfatte
-contemporaneamente, una volta che il processo figlio ha concluso il suo lavoro
-viene terminato, mentre il server originale resta sempre attivo.
+nel formato del livello successivo, fino al livello del collegamento fisico.
+In questo modo il pacchetto ricevuto ad un livello \textit{n} dalla stazione
+di destinazione è esattamente lo stesso spedito dal livello \textit{n} dalla
+sorgente. Questo rende facile il progettare il software facendo riferimento
+unicamente a quanto necessario ad un singolo livello, con la confidenza che
+questo poi sarà trattato uniformemente da tutti i nodi della rete.
+
+
+\section{Il protocollo TCP/IP}
+\label{sec:net_tpcip}
+
+Come accennato in \secref{sec:net_protocols} il protocollo TCP/IP è un insieme
+di protocolli diversi, che operano su 4 livelli diversi. Per gli interessi
+della programmazione di rete però sono importanti principalmente i due livelli
+centrali, e soprattutto quello di trasporto.
+
+La principale interfaccia usata nella programmazione di rete, quella dei
+socket\index{socket}, è infatti un'interfaccia nei confronti di quest'ultimo.
+Questo avviene perché al di sopra del livello di trasporto i programmi hanno a
+che fare solo con dettagli specifici delle applicazioni, mentre al di sotto
+vengono curati tutti i dettagli relativi alla comunicazione. È pertanto
+naturale definire una interfaccia di programmazione su questo confine, tanto
+più che è proprio lì (come evidenziato in \figref{fig:net_osi_tcpip_comp}) che
+nei sistemi Unix (e non solo) viene inserita la divisione fra kernel space e
+user space.
+
+In realtà in un sistema Unix è possibile accedere anche agli altri livelli
+inferiori (e non solo a quello di trasporto) con opportune interfacce di
+programmazione (vedi \secref{sec:sock_sa_packet}), ma queste vengono usate
+solo quando si debbano fare applicazioni di sistema per il controllo della
+rete a basso livello, di uso quindi molto specialistico.
+
+In questa sezione daremo una descrizione sommaria dei vari protocolli del
+TCP/IP, concentrandoci, per le ragioni appena esposte, sul livello di
+trasporto. All'interno di quest'ultimo privilegeremo poi il protocollo TCP,
+per il ruolo centrale che svolge nella maggior parte delle applicazioni.
+
+
+\subsection{Il quadro generale}
+\label{sec:net_tcpip_general}
+
+Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da
+molti membri. In \figref{fig:net_tcpip_overview} si è riportato uno schema che
+mostra un panorama sui principali protocolli della famiglia, e delle loro
+relazioni reciproche e con alcune dalle principali applicazioni che li usano.
+
+\begin{figure}[!htbp]
+ \centering
+ \includegraphics[width=13cm]{img/tcpip_overview}
+ \caption{Panoramica sui vari protocolli che compongono la suite TCP/IP.}
+ \label{fig:net_tcpip_overview}
+\end{figure}
+
+I vari protocolli riportati in \figref{fig:net_tcpip_overview} sono i
+seguenti:
+
+\begin{basedescript}{\desclabelwidth{1.7cm}\desclabelstyle{\nextlinelabel}}
+\item[\textsl{IPv4}] \textit{Internet Protocol version 4}. È quello che
+ comunemente si chiama IP. Ha origine negli anni '80 e da allora è la base su
+ cui è costruita internet. Usa indirizzi a 32 bit, e mantiene tutte le
+ informazioni di instradamento e controllo per la trasmissione dei pacchetti
+ sulla rete; tutti gli altri protocolli della suite (eccetto ARP e RARP, e
+ quelli specifici di IPv6) vengono trasmessi attraverso di esso.
+\item[\textsl{IPv6}] \textit{Internet Protocol version 6}. È stato progettato
+ a metà degli anni '90 per rimpiazzare IPv4. Ha uno spazio di indirizzi
+ ampliato 128 bit che consente più gerarchie di indirizzi,
+ l'autoconfigurazione, ed un nuovo tipo di indirizzi, gli \textit{anycast},
+ che consentono di inviare un pacchetto ad una stazione su un certo gruppo.
+ Effettua lo stesso servizio di trasmissione dei pacchetti di IPv4 di cui
+ vuole essere un sostituto.
+\item[\textsl{TCP}] \textit{Trasmission Control Protocol}. È un protocollo
+ orientato alla connessione che provvede un trasporto affidabile per un
+ flusso di dati bidirezionale fra due stazioni remote. Il protocollo ha cura
+ di tutti gli aspetti del trasporto, come l'acknoweledgment, i timeout, la
+ ritrasmissione, etc. È usato dalla maggior parte delle applicazioni.
+\item[\textsl{UDP}] \textit{User Datagram Protocol}. È un protocollo senza
+ connessione, per l'invio di dati a pacchetti. Contrariamente al TCP il
+ protocollo non è affidabile e non c'è garanzia che i pacchetti raggiungano
+ la loro destinazione, si perdano, vengano duplicati, o abbiano un
+ particolare ordine di arrivo.
+\item[\textsl{ICMP}] \textit{Internet Control Message Protocol}. È il
+ protocollo usato a livello 2 per gestire gli errori e trasportare le
+ informazioni di controllo fra stazioni remote e instradatori (cioè fra
+ \textit{host} e \textit{router}). I messaggi sono normalmente generati dal
+ software del kernel che gestisce la comunicazione TCP/IP, anche se ICMP può
+ venire usato direttamente da alcuni programmi come \cmd{ping}. A volte ci
+ si riferisce ad esso come ICPMv4 per distinguerlo da ICMPv6.
+\item[\textsl{IGMP}] \textit{Internet Group Management Protocol}. É un
+ protocollo di livello 2 usato per il \textit{multicasting} (vedi
+ \secref{sec:xxx_multicast}). Permette alle stazioni remote di notificare ai
+ router che supportano questa comunicazione a quale gruppo esse appartengono.
+ Come ICMP viene implementato direttamente sopra IP.
+\item[\textsl{ARP}] \textit{Address Resolution Protocol}. È il protocollo che
+ mappa un indirizzo IP in un indirizzo hardware sulla rete locale. È usato in
+ reti di tipo broadcast come Ethernet, Token Ring o FDDI che hanno associato
+ un indirizzo fisico (il \textit{MAC address}) alla interfaccia, ma non serve
+ in connessioni punto-punto.
+\item[\textsl{RARP}] \textit{Reverse Address Resolution Protocol}. È il
+ protocollo che esegue l'operazione inversa rispetto ad ARP (da cui il nome)
+ mappando un indirizzo hardware in un indirizzo IP. Viene usato a volte per
+ durante l'avvio per assegnare un indirizzo IP ad una macchina.
+\item[\textsl{ICMPv6}] \textit{Internet Control Message Protocol, version 6}.
+ Combina per IPv6 le funzionalità di ICMPv4, IGMP e ARP.
+\item[\textsl{EGP}] \textit{Exterior Gateway Protocol}. È un protocollo di
+ routing usato per comunicare lo stato fra gateway vicini a livello di
+ \textsl{sistemi autonomi}\footnote{vengono chiamati \textit{autonomous
+ systems} i raggruppamenti al livello più alto della rete.}, con
+ meccanismi che permettono di identificare i vicini, controllarne la
+ raggiungibilità e scambiare informazioni sullo stato della rete. Viene
+ implementato direttamente sopra IP.
+\item[\textsl{OSPF}] \textit{Open Shortest Path First}. È in protocollo di
+ routing per router su reti interne, che permette a questi ultimi di
+ scambiarsi informazioni sullo stato delle connessioni e dei legami che
+ ciascuno ha con gli altri. Viene implementato direttamente sopra IP.
+\item[\textsl{GRE}] \textit{Generic Routing Encapsulation}. È un protocollo
+ generico di incapsulamento che permette di incapsulare un qualunque altro
+ protocollo all'interno di IP.
+\item[\textsl{AH}] \textit{Authentication Header}. Provvede l'autenticazione
+ dell'integrità e dell'origine di un pacchetto. È una opzione nativa in IPv6
+ e viene implementato come protocollo a sé su IPv4. Fa parte della suite di
+ IPSEC che provvede la trasmissione cifrata ed autenticata a livello IP.
+\item[\textsl{ESP}] \textit{Encapsulating Security Payload}. Provvede la
+ cifratura insieme all'autenticazione dell'integrità e dell'origine di un
+ pacchetto. Come per AH è opzione nativa in IPv6 e viene implementato come
+ protocollo a sé su IPv4.
+\item[\textsl{PPP}] \textit{Point-to-Point Protocol}. È un protocollo a
+ livello 1 progettato per lo scambio di pacchetti su connessioni punto punto.
+ Viene usato per configurare i collegamenti, definire i protocolli di rete
+ usati ed incapsulare i pacchetti di dati. È un protocollo complesso con
+ varie componenti.
+\item[\textsl{SLIP}] \textit{Serial Line over IP}. È un protocollo di livello
+ 1 che permette di trasmettere un pacchetto IP attraverso una linea seriale.
+\end{basedescript}
+
+Gran parte delle applicazioni comunicano usando TCP o UDP, solo alcune, e per
+scopi particolari si rifanno direttamente ad IP (ed i suoi correlati ICMP e
+IGMP); benché sia TCP che UDP siano basati su IP e sia possibile intervenire a
+questo livello con i \textit{raw socket} questa tecnica è molto meno diffusa e
+a parte applicazioni particolari si preferisce sempre usare i servizi messi a
+disposizione dai due protocolli precedenti. Per questo motivo a parte alcuni
+brevi accenni su IP in questa sezione ci concentreremo sul livello di
+trasporto.
+
+\subsection{Internet Protocol (IP)}
+\label{sec:net_ip}
+
+Quando si parla di IP ci si riferisce in genere alla versione attualmente in
+uso che è la versione 4 (e viene pertanto chiamato IPv4). Questa versione
+venne standardizzata nel 1981
+dall'\href{http://www.ietf.org/rfc/rfc0719.txt}{RFC~719}.
+
+Internet Protocol nasce per disaccoppiare le applicazioni della struttura
+hardware delle reti di trasmissione, e creare una interfaccia di trasmissione
+dei dati indipendente dal sottostante substrato di rete, che può essere
+realizzato con le tecnologie più disparate (Ethernet, Token Ring, FDDI, etc.).
+Il compito di IP è pertanto quello di trasmettere i pacchetti da un computer
+all'altro della rete; le caratteristiche essenziali con cui questo viene
+realizzato in IPv4 sono due:
+
+\begin{itemize}
+\item \textit{Universal addressing} la comunicazione avviene fra due stazioni
+ remote identificate univocamente con un indirizzo a 32 bit che può
+ appartenere ad una sola interfaccia di rete.
+\item \textit{Best effort} viene assicurato il massimo impegno nella
+ trasmissione, ma non c'è nessuna garanzia per i livelli superiori né sulla
+ percentuale di successo né sul tempo di consegna dei pacchetti di dati.
+\end{itemize}
+
+Negli anni '90 la crescita vertiginosa del numero di macchine connesse a
+internet ha iniziato a far emergere i vari limiti di IPv4, per risolverne i
+problemi si è perciò definita una nuova versione del protocollo, che (saltando
+un numero) è diventata la versione 6. IPv6 nasce quindi come evoluzione di
+IPv4, mantendone inalterate le funzioni che si sono dimostrate valide,
+eliminando quelle inutili e aggiungendone poche altre per mantenere il
+protocollo il più snello e veloce possibile.
+
+I cambiamenti apportati sono comunque notevoli e si possono essere riassunti a
+grandi linee nei seguenti punti:
+\begin{itemize}
+\item l'espansione delle capacità di indirizzamento e instradamento, per
+ supportare una gerarchia con più livelli di indirizzamento, un numero di
+ nodi indirizzabili molto maggiore e una autoconfigurazione degli indirizzi.
+\item l'introduzione un nuovo tipo di indirizzamento, l'\textit{anycast} che
+ si aggiunge agli usuali \textit{unycast} e \textit{multicast}.
+\item la semplificazione del formato dell'intestazione (\textit{header}) dei
+ pacchetti, eliminando o rendendo opzionali alcuni dei campi di IPv4, per
+ eliminare la necessità di riprocessamento della stessa da parte dei router e
+ contenere l'aumento di dimensione dovuto all'ampliamento degli indirizzi.
+\item un supporto per le opzioni migliorato, per garantire una trasmissione
+ più efficiente del traffico normale, limiti meno stringenti sulle dimensioni
+ delle opzioni, e la flessibilità necessaria per introdurne di nuove in
+ futuro.
+\item il supporto per delle capacità di \textsl{qualità di servizio} (QoS) che
+ permettano di identificare gruppi di dati per i quali si può provvedere un
+ trattamento speciale (in vista dell'uso di internet per applicazioni
+ multimediali e/o ``real-time'').
+\end{itemize}
+
+Maggiori dettagli riguardo a caratteristiche, notazioni e funzionamento del
+protocollo IP sono forniti nell'appendice \secref{sec:ip_protocol}.
+
+
+\subsection{User Datagram Protocol (UDP)}
+\label{sec:net_udp}
+
+UDP è un protocollo di trasporto molto semplice, la sua descrizione completa è
+contenuta dell'\href{http://www.ietf.org/rfc/rfc0768.txt}{RFC~768}, ma in
+sostanza esso è una semplice interfaccia a IP dal livello di trasporto. Quando
+un'applicazione usa UDP essa scrive un pacchetto di dati (il cosiddetto
+\textit{datagram} che da il nome al protocollo) su un socket\index{socket}, al
+pacchetto viene aggiunto un header molto semplice (per una descrizione più
+accurata vedi \secref{sec:xxx_udp}), e poi viene passato al livello superiore
+(IPv4 o IPv6 che sia) che lo spedisce verso la destinazione. Dato che né IPv4
+né IPv6 garantiscono l'affidabilità niente assicura che il pacchetto arrivi a
+destinazione, né che più pacchetti arrivino nello stesso ordine in cui sono
+stati spediti.
+
+Pertanto il problema principale che si affronta quando si usa UDP è la
+mancanza di affidabilità, se si vuole essere sicuri che i pacchetti arrivino a
+destinazione occorrerà provvedere con l'applicazione, all'interno della quale
+si dovrà inserire tutto quanto necessario a gestire la notifica di
+ricevimento, la ritrasmissione, il timeout.
+
+Si tenga conto poi che in UDP niente garantisce che i pacchetti arrivino nello
+stesso ordine in cui sono stati trasmessi, e può anche accadere che i
+pacchetti vengano duplicati nella trasmissione, e non solo perduti. Di tutto
+questo di nuovo deve tenere conto l'applicazione.
+
+Un'altro aspetto di UDP è che se un pacchetto raggiunge correttamente la
+destinazione esso viene passato all'applicazione ricevente in tutta la sua
+lunghezza, la trasmissione avviene perciò per \textit{record} la cui lunghezza
+viene anche essa trasmessa all'applicazione all'atto del ricevimento.
+
+Infine UDP è un protocollo che opera senza connessione
+(\textit{connectionless}) in quanto non è necessario stabilire nessun tipo di
+relazione tra origine e destinazione dei pacchetti. Si hanno così situazioni
+in cui un client può scrivere su uno stesso socket\index{socket} pacchetti
+destinati a server diversi, o un server ricevere su un socket\index{socket}
+pacchetti provenienti da client diversi. Il modo più semplice di immaginarsi
+il funzionamento di UDP è quello della radio, in cui si può
+\textsl{trasmettere} e \textsl{ricevere} da più stazioni usando la stessa
+frequenza.
+
+Nonostante gli evidenti svantaggi comportati dall'inaffidabilità UDP ha il
+grande pregio della velocità, che in certi casi è essenziale; inoltre si
+presta bene per le applicazioni in cui la connessione non è necessaria, e
+costituirebbe solo un peso in termini di prestazioni, mentre una perdita di
+pacchetti può essere tollerata, ad esempio le applicazioni di streaming e
+quelle che usano il multicasting.
+
+\subsection{Transport Control Protocol (TCP)}
+\label{sec:net_tcp}
+
+Il TCP è un protocollo molto complesso, definito
+nell'\href{http://www.ietf.org/rfc/rfc0739.txt}{RFC~739} e completamente
+diverso da UDP; alla base della sua progettazione infatti non stanno
+semplicità e velocità, ma la ricerca della massima affidabilità possibile
+nella trasmissione dei dati.
+
+La prima differenza con UDP è che TCP provvede sempre una connessione diretta
+fra un client e un server, attraverso la quale essi possono comunicare; per
+questo il paragone più appropriato per questo protocollo è quello del
+collegamento telefonico, in quanto prima viene stabilita una connessione fra
+due i due capi della comunicazione su cui poi effettuare quest'ultima.
+
+Caratteristica fondamentale di TCP è l'affidabilità; quando i dati vengono
+inviati attraverso una connessione ne viene richiesto un ``\textsl{ricevuto}''
+(il cosiddetto \textit{acknowlegment}), se questo non arriva essi verranno
+ritrasmessi per un determinato numero di tentativi, intervallati da un periodo
+di tempo crescente, fino a che sarà considerata fallita o caduta la
+connessione (e sarà generato un errore di \textit{timeout}); il periodo di
+tempo dipende dall'implementazione e può variare far i quattro e i dieci
+minuti.
+
+Inoltre, per tenere conto delle diverse condizioni in cui può trovarsi la
+linea di comunicazione, TCP comprende anche un algoritmo di calcolo dinamico
+del tempo di andata e ritorno dei pacchetti fra un client e un server (il
+cosiddetto RTT, \textit{round-trip time}), che lo rende in grado di adattarsi
+alle condizioni della rete per non generare inutili ritrasmissioni o cadere
+facilmente in timeout.
+
+Inoltre TCP è in grado di preservare l'ordine dei dati assegnando un numero di
+sequenza ad ogni byte che trasmette. Ad esempio se un'applicazione scrive 3000
+byte su un socket\index{socket} TCP, questi potranno essere spezzati dal
+protocollo in due segmenti (le unità di dati passate da TCP a IP vengono
+chiamate \textit{segment}) di 1500 byte, di cui il primo conterrà il numero di
+sequenza $1-1500$ e il secondo il numero $1501-3000$. In questo modo anche se
+i segmenti arrivano a destinazione in un ordine diverso, o se alcuni arrivano
+più volte a causa di ritrasmissioni dovute alla perdita degli
+\textit{acknowlegment}, all'arrivo sarà comunque possibile riordinare i dati e
+scartare i duplicati.
+
+Il protocollo provvede anche un controllo di flusso (\textit{flow control}),
+cioè specifica sempre all'altro capo della trasmissione quanti dati può
+ricevere tramite una \textit{advertised window} (letteralmente
+\textsl{finestra annunciata)}, che indica lo spazio disponibile nel buffer di
+ricezione, cosicché nella trasmissione non vengano inviati più dati di quelli
+che possono essere ricevuti.
+
+Questa finestra cambia dinamicamente diminuendo con la ricezione dei dati dal
+socket\index{socket} ed aumentando con la lettura di quest'ultimo da parte
+dell'applicazione, se diventa nulla il buffer di ricezione è pieno e non
+verranno accettati altri dati. Si noti che UDP non provvede niente di tutto
+ciò per cui nulla impedisce che vengano trasmessi pacchetti ad un ritmo che il
+ricevente non può sostenere.
+
+Infine attraverso TCP la trasmissione è sempre bidirezionale (in inglese si
+dice che è \textit{full-duplex}). È cioè possibile sia trasmettere che
+ricevere allo stesso tempo, il che comporta che quanto dicevamo a proposito
+del controllo di flusso e della gestione della sequenzialità dei dati viene
+effettuato per entrambe le direzioni di comunicazione.
+
+%% Una descrizione più accurata del protocollo è fornita in appendice
+%% \secref{sec:tcp_protocol}.
+
+\subsection{Limiti e dimensioni riguardanti la trasmissione dei dati}
+\label{sec:net_lim_dim}
+
+Un aspetto di cui bisogna tenere conto nella programmazione di rete, e che
+ritornerà anche più avanti, è che ci sono una serie di limiti a cui la
+trasmissione dei dati attraverso i vari livelli del protocollo deve
+sottostare, limiti che è opportuno tenere presente perché in certi casi si
+possono avere delle conseguenze sul comportamento delle applicazioni.
+
+Un elenco di questi limiti, insieme ad un breve accenno alle loro origini ed
+alle eventuali implicazioni che possono avere, è il seguente:
+\begin{itemize}
+\item La dimensione massima di un pacchetto IP è di 65535 byte, compresa
+ l'intestazione. Questo è dovuto al fatto che la dimensione è indicata da un
+ campo apposito nell'header di IP che è lungo 16 bit (vedi
+ \figref{fig:IP_ipv4_head}).
+\item La dimensione massima di un pacchetto normale di IPv6 è di 65575 byte,
+ il campo apposito nell'header infatti è sempre a 16 bit, ma la dimensione
+ dell'header è fissa e di 40 byte e non è compresa nel valore indicato dal
+ suddetto campo. Inoltre IPv6 ha la possibilità di estendere la dimensione di
+ un pacchetto usando la \textit{jumbo payload option}.
+\item Molte reti fisiche hanno un MTU (\textit{maximum transfer unit}) che
+ dipende dal protocollo specifico usato al livello di connessione fisica. Il
+ più comune è quello di ethernet che è pari a 1500 byte, una serie di altri
+ valori possibili sono riportati in \tabref{tab:net_mtu_values}.
+\end{itemize}
+
+Quando un pacchetto IP viene inviato su una interfaccia di rete e le sue
+dimensioni eccedono la MTU viene eseguita la cosiddetta
+\textit{frammentazione}, i pacchetti cioè vengono suddivisi\footnote{questo
+ accade sia per IPv4 che per IPv6, anche se i pacchetti frammentati sono
+ gestiti con modalità diverse, IPv4 usa un flag nell'header, IPv6 una
+ opportuna opzione, si veda \secref{sec:ipv6_protocol}.}) in blocchi più
+piccoli che possono essere trasmessi attraverso l'interfaccia.
+
+\begin{table}[!htb]
+ \centering
+ \begin{tabular}[c]{|l|c|}
+ \hline
+ \textbf{Rete} & \textbf{MTU} \\
+ \hline
+ \hline
+ Hyperlink & 65535 \\
+ Token Ring IBM (16 Mbit/sec) & 17914 \\
+ Token Ring IEEE 802.5 (4 Mbit/sec) & 4464 \\
+ FDDI & 4532 \\
+ Ethernet & 1500 \\
+ X.25 & 576 \\
+ \hline
+ \end{tabular}
+ \caption{Valori della MTU (\textit{maximum transfer unit}) per una serie di
+ reti diverse.}
+ \label{tab:net_mtu_values}
+\end{table}
+La MTU più piccola fra due stazioni viene in genere chiamata \textit{path
+ MTU}, che dice qual'è la lunghezza massima oltre la quale un pacchetto
+inviato da una stazione ad un'altra verrebbe senz'altro frammentato. Si tenga
+conto che non è affatto detto che la \textit{path MTU} sia la stessa in
+entrambe le direzioni, perché l'instradamento può essere diverso nei due
+sensi, con diverse tipologie di rete coinvolte.
+
+Una delle differenze fra IPv4 e IPv6 é che per IPv6 la frammentazione può
+essere eseguita solo alla sorgente, questo vuol dire che i router IPv6 non
+frammentano i pacchetti che ritrasmettono (anche se possono frammentare i
+pacchetti che generano loro stessi), mentre i router IPv4 si. In ogni caso una
+volta frammentati i pacchetti possono essere riassemblati solo alla
+destinazione.
+
+Nell'header di IPv4 è previsto il flag \texttt{DF} che specifica che il
+pacchetto non deve essere frammentato; un router che riceva un pacchetto le
+cui dimensioni eccedano quelle dell'MTU della rete di destinazione genererà un
+messaggio di errore ICMPv4 di tipo \textit{destination unreachable,
+ fragmentation needed but DF bit set}. Dato che i router IPv6 non possono
+effettuare la frammentazione la ricezione di un pacchetto di dimensione
+eccessiva per la ritrasmissione genererà sempre un messaggio di errore ICMPv6
+di tipo \textit{packet too big}.
+
+Dato che il meccanismo di frammentazione e riassemblaggio dei pacchetti
+comporta inefficienza, normalmente viene utilizzato un procedimento, detto
+\textit{path MTU discovery} che permette di determinare il \textit{path MTU}
+fra due stazioni; per la realizzazione del procedimento si usa il flag DF di
+IPv4 e il comportamento normale di IPv6 inviando delle opportune serie di
+pacchetti (per i dettagli vedere
+l'\href{http://www.ietf.org/rfc/rfc1191.txt}{RFC~1191} per IPv4 e
+l'\href{http://www.ietf.org/rfc/rfc1981.txt}{RFC~1981} per IPv6) fintanto che
+non si hanno più errori.
+
+Il TCP usa sempre questo meccanismo, che per le implementazioni di IPv4 è
+opzionale, mentre diventa obbligatorio per IPv6. Per IPv6 infatti, non
+potendo i router frammentare i pacchetti, è necessario, per poter comunicare,
+conoscere da subito il \textit{path MTU}.
+
+Infine TCP definisce una MSS \textit{Maximum Segment Size} che annuncia
+all'altro capo della connessione la dimensione massima dimensione del segmento
+di dati che può essere ricevuto, così da evitare la frammentazione. Di norma
+viene impostato alla dimensione della MTU dell'interfaccia meno la lunghezza
+delle intestazioni di IP e TCP, in Linux il default, mantenuto nella costante
+\const{TCP\_MSS} è 512.
+
+
+%\subsection{Il passaggio dei dati in TCP}
+%\label{sec:net_tcp_pass}
+
+%\subsection{Il passaggio dei dati in UDP}
+%\label{sec:net_udp_pass}
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End:
projects / gapil.git / blobdiff