%% network.tex
%%
-%% Copyright (C) 2000-2006 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2010 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}
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.
+processo figlio (o un \itindex{thread} \textit{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}}
\textbf{Livello} & \multicolumn{2}{|c|}{\textbf{Nome}} & \textbf{Esempi} \\
\hline
\hline
- Livello 4&\textit{Application} &\textsl{Applicazione}&
- 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}&
- device driver \& scheda di interfaccia \\
+ Livello 4 & \textit{Application} & \textsl{Applicazione}&
+ 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}&
+ Device driver \& scheda di interfaccia\\
\hline
\end{tabular}
\caption{I quattro livelli del protocollo TCP/IP.}
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
+ 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
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
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
\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},
+ 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.
\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.
+ 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}.
\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, 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.
+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
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}
+quelle che usano il \itindex{multicast} \textit{multicast}.
\subsection{Transport Control Protocol (TCP)}
\label{sec:net_tcp}
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 ed aumentando con la lettura di quest'ultimo da parte
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
% 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: router instradatori version RARP 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
projects / gapil.git / blobdiff