%% network.tex
%%
-%% Copyright (C) 2000-2004 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2005 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",
+%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
%% 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".
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.
+abbiamo usato in cap.~\ref{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.
Una caratteristica comune dei protocolli di rete è il loro essere strutturati
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}.
+sottostante. Questo modello di funzionamento è 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
+tab.~\ref{tab:net_osilayers}.
\begin{table}[htb]
\centering
è 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
+fig.~\ref{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.
\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.}
+(riassunti in tab.~\ref{tab:net_layers}); un confronto fra i due è riportato
+in fig.~\ref{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
+sez.~\ref{sec:intro_unix_struct}.\footnote{in realtà è sempre possibile
+ accedere dallo user space, attraverso una opportuna interfaccia (come
+ vedremo in sez.~\ref{sec:sock_sa_packet}), ai livelli inferiori del
+ protocollo.}
\begin{table}[htb]
\centering
\hline
\hline
Livello 4&\textit{Application} &\textsl{Applicazione}&
- Telnet, FTP, etc. \\
+ Telnet, FTP, ecc. \\
Livello 3&\textit{Transport} &\textsl{Trasporto}& TCP, UDP \\
Livello 2&\textit{Network} &\textsl{Rete}& IP, (ICMP, IGMP) \\
Livello 1&\textit{Link} &\textsl{Collegamento}&
\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
+ (vedi sez.~\ref{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
\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
+illustrate in fig.~\ref{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.
\end{figure}
Per chiarire meglio la struttura della comunicazione attraverso i vari
-protocolli mostrata in \figref{fig:net_tcpip_data_flux}, conviene prendere in
+protocolli mostrata in fig.~\ref{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}
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
+ 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
\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.
+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\index{socket}, è infatti un'interfaccia nei confronti di quest'ultimo.
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.
+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 \secref{sec:sock_sa_packet}), ma queste vengono usate
+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.
\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
+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]
\label{fig:net_tcpip_overview}
\end{figure}
-I vari protocolli riportati in \figref{fig:net_tcpip_overview} sono i
+I vari protocolli riportati in fig.~\ref{fig:net_tcpip_overview} sono i
seguenti:
\begin{basedescript}{\desclabelwidth{1.7cm}\desclabelstyle{\nextlinelabel}}
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.
+ 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
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.
+ 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 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.
+ 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
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.).
+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:
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}.
+ 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 riprocessamento della stessa da parte dei router e
\end{itemize}
Maggiori dettagli riguardo a caratteristiche, notazioni e funzionamento del
-protocollo IP sono forniti nell'appendice \secref{sec:ip_protocol}.
+protocollo IP sono forniti nell'appendice sez.~\ref{sec:ip_protocol}.
\subsection{User Datagram Protocol (UDP)}
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:udp_protocol}), e poi viene passato al livello
+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
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.
+quelle che usano il \textit{multicast}. \itindex{multicast}
\subsection{Transport Control Protocol (TCP)}
\label{sec:net_tcp}
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
-%% \secref{sec:tcp_protocol}.
+%% 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à 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.
+ritornerà in seguito, quando tratteremo gli aspetti più avanzti, è 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:
\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}).
+ 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 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}.
+\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 \secref{sec:ipv6_protocol}.}) in blocchi più
+ opportuna opzione, si veda sez.~\ref{sec:ipv6_protocol}.}) in blocchi più
piccoli che possono essere trasmessi attraverso l'interfaccia.
\begin{table}[!htb]
X.25 & 576 \\
\hline
\end{tabular}
- \caption{Valori della MTU (\textit{maximum transfer unit}) per una serie di
- reti diverse.}
+ \caption{Valori della MTU (\textit{Maximum Transfer Unit}) per una serie di
+ diverse tecnologie di rete.}
\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
+ 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
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
\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"
projects / gapil.git / blobdiff