+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 sez.~\ref{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 (vedi sez.~\ref{cha:socket_intro}), è 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
+fig.~\ref{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 sez.~\ref{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 fig.~\ref{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 fig.~\ref{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'auto-configurazione, 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, ecc. È 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 \itindex{multicast}
+ \textit{multicast} (vedi sez.~\ref{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 \itindex{broadcast} \textit{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, ecc.).
+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, mantenendone 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 auto-configurazione degli indirizzi.
+\item l'introduzione un nuovo tipo di indirizzamento, l'\textit{anycast} che
+ si aggiunge agli usuali \textit{unicast} e \itindex{multicast}
+ \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 rielaborazione 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 sez.~\ref{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 al protocollo 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, al
+pacchetto viene aggiunto un header molto semplice (per una descrizione più
+accurata vedi sez.~\ref{sec:udp_protocol}), 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 pacchetti destinati a
+server diversi, o un server ricevere su un 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 \itindex{multicast} \textit{multicast}.
+
+\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, \itindex{Round~Trip~Time} \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 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 \itindex{advertised~window} \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 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.
+
+% TODO mettere riferimento alla appendice su TCP quando ci sarà
+%% Una descrizione più accurata del protocollo è fornita in appendice
+%% sez.~\ref{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à in seguito, quando tratteremo gli aspetti più avanzati, è 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
+ fig.~\ref{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 una MTU \itindex{Maximum~Transfer~Unit}
+ (\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
+ tab.~\ref{tab:net_mtu_values}.
+\end{itemize}
+
+\itindbeg{Maximum~Transfer~Unit}
+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 sez.~\ref{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
+ diverse tecnologie di rete.}
+ \label{tab:net_mtu_values}
+\end{table}