X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=network.tex;h=dc24c665d7a4420441aa3b607b115a902f621909;hp=fd9f734f9120af57afce588b4941ab1de9aa271f;hb=4826742c87d76af810c8a30e5495135fb43b8091;hpb=efd164169524125422cf9bb80ff70a0b037886a0 diff --git a/network.tex b/network.tex index fd9f734..dc24c66 100644 --- a/network.tex +++ b/network.tex @@ -2,15 +2,15 @@ \label{cha:network} In questo capitolo sarà fatta un'introduzione ai contetti generali che servono -come prerequisiti per capire la programmazione di rete, partiremo con due -semplici esempi per poi passare ad un esame a grandi linee dei protocolli di -rete e di come questi sono organizzati e interagiscono. +come prerequisiti per capire la programmazione di rete, per evitare un +capitolo puramente teorico partiremo con due semplici esempi per poi passare +ad un esame a grandi linee dei protocolli di rete e di come questi sono +organizzati e interagiscono. In particolare, avendo assunto l'ottica di un'introduzione mirata alla -programmazione, ci concentreremo sul protocollo più diffuso, TCP/IP, che è -quello che sta alla base di internet, ed in particolare prenderemo in esame in -questa introduzione i concetti più importanti da conoscere ai fini della -programmazione. +programmazione, ci concentreremo sul protocollo più diffuso, il TCP/IP, che è +quello che sta alla base di internet, con un'ottica improntata a sottolineare +i concetti più importanti da conoscere ai fini della programmazione. \section{Il modello client-server} \label{sec:net_cliserv} @@ -35,18 +35,18 @@ generale anche per programmi che non fanno necessariamente uso della rete, come il sistema a finestre. Normalmente si dividono i server in due categorie principali, e vengono detti -\textit{concorrenti} o \textit{iterativi}, sulla base del loro comportamento. +\textsl{concorrenti} o \textsl{iterativi}, sulla base del loro comportamento. -Un server iterativo risponde alla richiesta inviando i dati e resta occupato -(non rispondendo ad ulteriori richieste) fintanto che non ha concluso la -richiesta. Una volta completata la richiesta il server diventa di nuovo +Un \textsl{server iterativo} risponde alla richiesta inviando i dati e resta +occupato (non rispondendo ad ulteriori richieste) fintanto che non ha concluso +la richiesta. Una volta completata la richiesta il server diventa di nuovo disponibile. -Un server concorrente al momento di trattare la richiesta crea un processo -figlio incaricato di fornire i servizi richiesti, per poi porsi in attesa di -ulteriori richieste. In questo modo più richieste possono essere soddisfatte -contemporaneamente; una volta che il processo figlio ha concluso il suo lavoro -viene terminato, mentre il server originale resta sempre attivo. +Un \textsl{server concorrente} al momento di trattare la richiesta crea un +processo figlio incaricato di fornire i servizi richiesti, per poi porsi in +attesa di ulteriori richieste. In questo modo più richieste possono essere +soddisfatte contemporaneamente; una volta che il processo figlio ha concluso +il suo lavoro viene terminato, mentre il server originale resta sempre attivo. \subsection{Un primo esempio di client} @@ -130,7 +130,7 @@ Il programma anzitutto include gli header necessari (\texttt{\small 1--5}); dopo la dichiarazione delle variabili (\texttt{\small 9--12}) si è omessa tutta la parte relativa al trattamento degli argomenti passati dalla linea di comando (effettuata con le apposite routines illustrate in -\ref{cha:parameter_options}). +\capref{cha:parameter_options}). Il primo passo (\texttt{\small 14--18}) è creare un \textit{socket} IPv4 (\texttt{AF\_INET}), di tipo TCP \texttt{SOCK\_STREAM} (in sostanza un canale @@ -369,7 +369,7 @@ Cos anche la corrispondenza fra i rispettivi livelli (che comunque è approssimativa) e su come essi vanno ad inserirsi all'interno del sistema operativo rispetto alla divisione fra user space e kernel space spiegata in -\ref{sec:intro_unix_struct}. +\secref{sec:intro_unix_struct}. \begin{table}[htb] \centering @@ -397,7 +397,7 @@ compongono, il TCP \textit{Trasmission Control Protocol} e l'IP \begin{description} \item \textbf{Applicazione} É relativo ai programmi di interfaccia utente, in genere questi vengono realizzati secondo il modello Client-Server (vedi - \ref{sec:net_cliserv}. + \secref{sec:net_cliserv}. \item \textbf{Trasporto} Fornisce la comunicazione tra le due stazioni terminali su cui girano gli applicativi, regola il flusso delle informazioni, e può fornire un trasporto affidabile, cioè con recupero @@ -559,7 +559,7 @@ I vari protocolli mostrati in figura sono i seguenti: da ICMPv6. \item \textsl{ICMP} \textit{Internet Group Management Protocol}. É un protocollo usato per il \textit{multicasting} (vedi - \ref{sec:xxx_multicast}), che è opzionale in IPv4. + \secref{sec:xxx_multicast}), che è opzionale in IPv4. \item \textsl{ARP} \textit{Address Resolution Protocol}. È il protocollo che mappa un indirizzo IP in un indirizzo hardware (come un indirizzo internet). È usato in reti di tipo broadcast come ethernet, token ring o @@ -636,22 +636,22 @@ grandi linee nei seguenti punti: \end{itemize} Maggiori dettagli riguardo a caratteristiche, notazioni e funzionamento del -protocollo IP sono forniti nell'appendice \ref{cha:ip_protocol}. +protocollo IP sono forniti nell'appendice \capref{cha:ip_protocol}. \subsection{UDP: User Datagram Protocol)} \label{sec:net_udp} UDP è un protocollo di trasporto molto semplice, la sua descizione 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, al pacchetto viene aggiunto un header molto semplice (per una -descrizione più accurata vedi \ref{sec:appA_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'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 \secref{sec:appA_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 @@ -746,7 +746,7 @@ controllo di flusso e della gestione della sequenzialit effettuato per entrambe le direzioni di comunicazione. Una descrizione più accurata del protocollo è fornita in appendice -\ref{cha:tcp_protocol}. +\capref{cha:tcp_protocol}. \subsection{Limiti e dimensioni riguardanti la trasmissione dei dati} \label{sec:net_lim_dim} @@ -763,28 +763,49 @@ loro origini ed alle eventuali implicazioni che possono avere: \item La dimensione massima di un pacchetti IP è di 65535 bytes, compreso l'header. Questo è dovuto al fatto che la dimensione è indicata da un campo apposito nell'header di IP che è lungo 16 bit (vedi - \ref{sec:appA_ipv4head}). + \secref{sec:appA_ipv4head}). \item La dimensione massima di un pacchetto normale di IPv6 è di 65575 bytes, 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 tranfer unit}) che è - imposta dalle modalità di funzionamento dall'hardware. Il più comune è - quello dell'ethernet che è pari a 1500 bytes. La MTU più piccola fra due - stazioni viene in genere chiamata \textit{path MTU}, e al giorno d'oggi è - normalmente data da ethernet; si tenga conto che non è affatto detto che sia - la stessa in entrambe le direzioni, anche perchè l'instradamento può essere - diverso. +\item Molte reti fisiche hanno un MTU (\textit{maximum tranfer unit}) che + dipende dal protocollo specifico usato al livello di link. Il più comune è + quello dell'ethernet che è pari a 1500 bytes, una serie di valori possibili + sono riportati in \ntab. \end{itemize} +\begin{table}[!htb] + \centering + \begin{tabular}[c]{|l|c|} + \textbf{Rete} & \textbf{MTU} \\ + \hline + Hyperlink & 65535 \\ + Token Ring IBM (16 Mbit/sec) & 17914 \\ + Token Ring IEEE 802.5 (4 Mbit/sec) & 4464 \\ + FDDI & 4532 \\ + Ethernet & 1500 \\ + X.25 & 576 \\ + \end{tabular} + \caption{Valori della MTU (\textit{maximum tranfer unit}) per una serie di + reti diverse.} + \label{tab:net_mtu_values} +\end{table} + Quando un pacchetto IP viene inviato su una interfaccia di rete e le sue dimensioni eccedono la MTU viene eseguita la cosiddetta -\textit{frammentazione} (sia da IPv4 che da IPv6, anche se i pacchetti -frammentati sono gestiti con modalità diverse\footnote{il primo usa un flag - nell'header, il secondo una opportuna opzione, si veda - \ref{cha:ip_protcol}}), i pacchetti cioè vengono spezzati in blocchi più -piccoli che possono essere trasmessi attraverso l'interfaccia. +\textit{frammentazione}, i pacchetti cioè vengono spezzati (sia da IPv4 che da +IPv6, anche se i pacchetti frammentati sono gestiti con modalità +diverse\footnote{il primo usa un flag nell'header, il secondo una opportuna + opzione, si veda \secref{cha:ip_protcol}}), in blocchi più piccoli che +possono essere trasmessi attraverso l'interfaccia. + +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 +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 +sensi, con diverse tipologie di rete coinvolte. 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 @@ -794,24 +815,28 @@ 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 uno di questi -pacchetti le cui dimensioni eccedono quelle dell'MTU della rete di -destinazione genererà un messaggio di errore ICMPv4 di tipo -\textit{destination unreachable, fragentation needed but DF bit set}. +pacchetto non deve essere frammentato; un router che riceva un pacchetto le +cui dimensioni eccedano quelle dell'MTU della rete di destinazione genererà un +messaggio di errore ICMPv4 di tipo \textit{destination unreachable, + fragentation needed but DF bit set}. Dato che i router IPv6 non possono effettuare la frammentazione la ricezione di un pacchetto di dimensione eccessiva per la ritrasmissione genererà sempre un messaggio di errore ICMPv6 di tipo \textit{paket too big}. Dato che il meccanismo di frammentazione e riassemblaggio comporta -inefficienza è opportuno che la trasmissione di grosse quantità di dati sia -gestita in maniera oculata, TCP provvede un meccanismo automatico di - -In genere il flag DF di IPv4 (e il comportamento normale di IPv6) vengono -utilizzati per il processo della \textit{path MTU discover} (vedi RFC1191 per -IPv4 e RFC1981 per IPv6) in cui inviando delle opportune serie di pacchetti si -trova il \textit{path MTU}; TCP usa questo meccanismo che è opzionale per -IPv4, ma necessario (dato che i pacchetti verrebbero bloccati) per IPv6. +inefficienza normalmente viene utilizzato il procedimento della \textit{path + MTU discover} (vedi RFC1191 per IPv4 e RFC1981 per IPv6) che permette dui +trovare 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'RFC1191 +per IPv4 e l'RFC1981 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 il \textit{path MTU}. + Infine TCP definisce una \textit{maximum segment size} MSS che annuncia all'altro capo la dimensione massima del segmento di dati