X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=network.tex;h=619793641b3577bec8bb118ade929e86757ddc16;hb=dd741fcfa876c0a4c26a72da0035b7cfea8202e2;hp=4cab8cf2e78d4d09d678fbd7e6d7401536438316;hpb=66e83c068629844f84fe4a0d44b382f756c9ef32;p=gapil.git diff --git a/network.tex b/network.tex index 4cab8cf..6197936 100644 --- a/network.tex +++ b/network.tex @@ -1,6 +1,6 @@ %% 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", @@ -199,7 +199,7 @@ tab.~\ref{tab:net_osilayers}. 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 @@ -255,7 +255,7 @@ sez.~\ref{sec:intro_unix_struct}.\footnote{in realt \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}& @@ -442,7 +442,7 @@ seguenti: 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 @@ -456,15 +456,16 @@ seguenti: 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 @@ -522,7 +523,7 @@ 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, 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: @@ -540,7 +541,7 @@ 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, 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. @@ -551,10 +552,11 @@ grandi linee nei seguenti punti: 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 @@ -596,7 +598,7 @@ stesso ordine in cui sono stati trasmessi, e pu 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. @@ -616,7 +618,7 @@ grande pregio della velocit 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} @@ -645,9 +647,9 @@ 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, \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 @@ -680,6 +682,7 @@ 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}. @@ -687,10 +690,11 @@ effettuato per entrambe le direzioni di comunicazione. \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: @@ -704,12 +708,14 @@ alle eventuali implicazioni che possono avere, 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 @@ -733,13 +739,13 @@ piccoli che possono essere trasmessi attraverso l'interfaccia. 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 @@ -775,6 +781,9 @@ Il TCP usa sempre questo meccanismo, che per le implementazioni di IPv4 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 @@ -784,13 +793,27 @@ 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