%% network.tex
%%
-%% Copyright (C) 2000-2006 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2007 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 "Un preambolo",
%% license is included in the section entitled "GNU Free Documentation
%% License".
%%
+
\chapter{Introduzione alla programmazione di rete}
\label{cha:network}
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 cap.~\ref{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.
+ un'interfaccia opportuna (i \textit{socket}, che esamineremo in dettaglio in
+ cap.~\ref{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
scartare pacchetti se il carico è temporaneamente eccessivo, o se risultano
errati o non recapitabili.
-L'incarico di rendere il recapito pacchetti affidabile non spetta allo livello
-di collegamento, ma ai livelli superiori. Pertanto il protocollo IP è per sua
-natura inaffidabile, in quanto non è assicurata né una percentuale di
-successo né un limite sui tempi di consegna dei pacchetti.
+L'incarico di rendere il recapito pacchetti affidabile non spetta al livello
+di rete, ma ai livelli superiori. Pertanto il protocollo IP è per sua natura
+inaffidabile, in quanto non è assicurata né una percentuale di successo né un
+limite sui tempi di consegna dei pacchetti.
È 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 ai livelli superiori.
+dal protocollo TCP. La sede principale di "\textit{intelligenza}" della rete è
+pertanto 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
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 fig.~\ref{fig:net_osi_tcpip_comp})
-che nei sistemi Unix (e non solo) viene inserita la divisione fra kernel space
-e user space.
+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
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
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
+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)}
\subsection{User Datagram Protocol (UDP)}
\label{sec:net_udp}
-UDP è un protocollo di trasporto molto semplice, la sua descrizione completa è
+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
+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
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.
+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 \textit{multicast}. \itindex{multicast}
+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}
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.
+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\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
+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 \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.
+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\index{socket} ed aumentando con la lettura di quest'ultimo da parte
+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
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,
+\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
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.
+pacchetti che generano loro stessi), al contrario di quanto fanno i router
+IPv4. 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
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
+fra due stazioni; per la realizzazione del procedimento si usa il flag
+\texttt{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.
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}.
-\itindend{Maximum~Transfer~Unit}
-
-
-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
+Infine TCP definisce una \itindex{Maximum~Segment~Size} \textit{Maximum
+ Segment Size} (da qui in avanti abbreviata in MSS) 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.
+\itindend{Maximum~Transfer~Unit}
+
%%% Local Variables:
%%% mode: latex
projects / gapil.git / blobdiff