%% network.tex
%%
-%% Copyright (C) 2000-2005 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2006 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",
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
+ è stata creata la frase \textit{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
fig.~\ref{fig:net_osi_tcpip_comp}, con un \textit{upper layer} che riguarda
\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}&
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
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
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
- 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.
+ 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
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)}
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:
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,
+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.
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
+ 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
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 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.
+\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
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
+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.
+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 multicasting.
+pacchetti può essere tollerata: ad esempio le applicazioni di streaming e
+quelle che usano il \textit{multicast}. \itindex{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.
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
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}.
\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ù 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:
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 tab.~\ref{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
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}
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
+\itindend{Maximum~Transfer~Unit}
+
+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.
-%\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:
+
+% LocalWords: TCP multitasking client ftp telnet ssh cap thread peer to three
+% LocalWords: Napster routing tier two middle International Standards Systems
+% LocalWords: Organization Interconnection tab Application Presentation All of
+% LocalWords: Session Transport DataLink Physical people seem need processing
+% LocalWords: fig upper layer lower kernel DoD Department Defense Connection
+% LocalWords: sez UDP ICMP IGMP device Trasmission Control Protocol l'IP l'UDP
+% LocalWords: IPv ethernet SMTP RFC Request For Comment socket stack PPP ARP
+% LocalWords: router instradatori version RARP l'autoconfigurazione anycast Di
+% LocalWords: l'acknoweledgment Datagram Message host ping ICPMv ICMPv Group
+% LocalWords: multicast Address Resolution broadcast Token FDDI MAC address DF
+% LocalWords: Reverse EGP Exterior Gateway gateway autonomous systems OSPF GRE
+% LocalWords: Shortest Path First Generic Encapsulation Authentication Header
+% LocalWords: IPSEC ESP Encapsulating Security Payload Point Line over raw QoS
+% LocalWords: dall' Universal addressing Best effort unicast header dell' RTT
+% LocalWords: datagram connectionless streaming nell' acknowlegment trip flow
+% LocalWords: segment control advertised window nell'header dell'header option
+% LocalWords: payload MTU Transfer Unit Hyperlink IBM Mbit sec IEEE path but
+% LocalWords: dell'MTU destination unreachable fragmentation needed packet too
+% LocalWords: big discovery MSS Size
projects / gapil.git / blobdiff