X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=network.tex;h=a75b786cf216457fce4f4915190e2b79688e556a;hp=ed310b1d41f77102e36368a4ddc64cc641d3d0a0;hb=d47f15496fa85c8ec22edcde608f2665ec5b95ae;hpb=758b135b7f04cdcebc4fe2726dc540cb24d116ba diff --git a/network.tex b/network.tex index ed310b1..a75b786 100644 --- a/network.tex +++ b/network.tex @@ -260,7 +260,7 @@ kernel space spiegata in \secref{sec:intro_unix_struct}.\footnote{in realt Telnet, FTP, etc. \\ Livello 3&\textit{Transport} &\textsl{Trasporto}& TCP, UDP \\ Livello 2&\textit{Network} &\textsl{Rete}& IP, (ICMP, IGMP) \\ - Livello 1&\textit{Link} &\textsl{Connessione}& + Livello 1&\textit{Link} &\textsl{Collegamento}& device driver \& scheda di interfaccia \\ \hline \end{tabular} @@ -290,7 +290,7 @@ copre il livello 2. Le funzioni dei vari livelli sono le seguenti: scambio di messaggi di controllo e per il monitoraggio della rete. Il protocollo su cui si basa questo livello è IP (sia nella attuale versione, IPv4, che nella nuova versione, IPv6). -\item[\textbf{Connessione}] È responsabile per l'interfacciamento al +\item[\textbf{Collegamento}] È responsabile per l'interfacciamento al dispositivo elettronico che effettua la comunicazione fisica, gestendo l'invio e la ricezione dei pacchetti da e verso l'hardware. \end{basedescript} @@ -370,7 +370,7 @@ in grado di adattarsi ai mutamenti delle interconnessioni. La caratteristica essenziale che rende tutto ciò possibile è la strutturazione a livelli tramite l'incapsulamento. Ogni pacchetto di dati viene incapsulato -nel formato del livello successivo, fino al livello della connessione fisica. +nel formato del livello successivo, fino al livello del collegamento fisico. In questo modo il pacchetto ricevuto ad un livello \textit{n} dalla stazione di destinazione è esattamente lo stesso spedito dal livello \textit{n} dalla sorgente. Questo rende facile il progettare il software facendo riferimento @@ -518,7 +518,8 @@ trasporto. Quando si parla di IP ci si riferisce in genere alla versione attualmente in uso che è la versione 4 (e viene pertanto chiamato IPv4). Questa versione -venne standardizzata nel 1981 dall'RFC~719. +venne standardizzata nel 1981 +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 @@ -568,22 +569,23 @@ grandi linee nei seguenti punti: \end{itemize} Maggiori dettagli riguardo a caratteristiche, notazioni e funzionamento del -protocollo IP sono forniti nell'appendice \capref{cha:ip_protocol}. +protocollo IP sono forniti nell'appendice \secref{sec:ip_protocol}. \subsection{User Datagram Protocol (UDP)} \label{sec:net_udp} UDP è un protocollo di trasporto molto semplice, la sua descrizione completa è -contenuta dell'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 \secref{sec:xxx_udp}), 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. +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 \secref{sec:xxx_udp}), 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 @@ -608,20 +610,21 @@ in cui un client pu 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 a}'' e ``\textsl{ricevere da}'' più stazioni usando la -stessa frequenza. +\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 +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. \subsection{Transport Control Protocol (TCP)} \label{sec:net_tcp} -Il TCP è un protocollo molto complesso, definito nell'RFC~739 e completamente +Il TCP è un protocollo molto complesso, definito +nell'\href{http://www.ietf.org/rfc/rfc0739.txt}{RFC~739} e completamente diverso da UDP; alla base della sua progettazione infatti non stanno semplicità e velocità, ma la ricerca della massima affidabilità possibile nella trasmissione dei dati. @@ -630,8 +633,7 @@ La prima differenza con UDP fra un client e un server, attraverso la quale essi possono comunicare; per questo il paragone più appropriato per questo protocollo è quello del collegamento telefonico, in quanto prima viene stabilita una connessione fra -due i due capi della comunicazione su cui poi viene quest'ultima viene -effettuata. +due i due capi della comunicazione su cui poi effettuare quest'ultima. Caratteristica fondamentale di TCP è l'affidabilità; quando i dati vengono inviati attraverso una connessione ne viene richiesto un ``\textsl{ricevuto}'' @@ -681,7 +683,7 @@ del controllo di flusso e della gestione della sequenzialit effettuato per entrambe le direzioni di comunicazione. %% Una descrizione più accurata del protocollo è fornita in appendice -%% \capref{cha:tcp_protocol}. +%% \secref{sec:tcp_protocol}. \subsection{Limiti e dimensioni riguardanti la trasmissione dei dati} \label{sec:net_lim_dim} @@ -715,7 +717,7 @@ 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{cha:ip_protocol}.}) in blocchi più + opportuna opzione, si veda \secref{sec:ipv6_protocol}.}) in blocchi più piccoli che possono essere trasmessi attraverso l'interfaccia. \begin{table}[!htb] @@ -766,15 +768,17 @@ 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 l'RFC~1191 per IPv4 e l'RFC~1981 per IPv6) -fintanto che non si hanno più errori. +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. 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}. -Infine TCP definisce una \textit{maximum segment size} MSS che annuncia +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