X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=network.tex;h=dada52f3a664a6d31b39cb8baa130f95931b2855;hp=79035f8b8a369b1b9664f3c3fd9bf3a63f744dbd;hb=406973e35011347c3812c671511ce738378a525b;hpb=99ef4679f4d9d22707075c7e05a4dbd3900edcd1 diff --git a/network.tex b/network.tex index 79035f8..dada52f 100644 --- a/network.tex +++ b/network.tex @@ -1,9 +1,9 @@ %% network.tex %% -%% Copyright (C) 2000-2003 Simone Piccardi. Permission is granted to +%% Copyright (C) 2000-2004 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 "Prefazione", +%% Free Software Foundation; with the Invariant Sections being "Un preambolo", %% with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the %% license is included in the section entitled "GNU Free Documentation %% License". @@ -61,8 +61,8 @@ Seguono questo modello tutti i servizi fondamentali di internet, come le pagine web, la posta elettronica, ftp, telnet, ssh e praticamente ogni servizio che viene fornito tramite la rete, anche se, come abbiamo visto, il modello è utilizzato in generale anche per programmi che, come gli esempi che -abbiamo usato in \capref{cha:IPC} a proposito della comunicazione fra processi -nello stesso sistema, non fanno necessariamente uso della rete. +abbiamo usato in cap.~\ref{cha:IPC} a proposito della comunicazione fra +processi nello stesso sistema, non fanno necessariamente uso della rete. Normalmente si dividono i server in due categorie principali, e vengono detti \textsl{concorrenti} o \textsl{iterativi}, sulla base del loro comportamento. @@ -170,11 +170,11 @@ del funzionamento di internet, Una caratteristica comune dei protocolli di rete è il loro essere strutturati in livelli sovrapposti; in questo modo ogni protocollo di un certo livello realizza le sue funzionalità basandosi su un protocollo del livello -sottostante. Questo modello di funzionamento è stato stato standardizzato -dalla \textit{International Standards Organization} (ISO) che ha preparato fin -dal 1984 il Modello di Riferimento \textit{Open Systems Interconnection} -(OSI), strutturato in sette livelli, secondo quanto riportato in -\tabref{tab:net_osilayers}. +sottostante. Questo modello di funzionamento è stato standardizzato dalla +\textit{International Standards Organization} (ISO) che ha preparato fin dal +1984 il Modello di Riferimento \textit{Open Systems Interconnection} (OSI), +strutturato in sette livelli, secondo quanto riportato in +tab.~\ref{tab:net_osilayers}. \begin{table}[htb] \centering @@ -202,8 +202,8 @@ modello abbastanza complesso\footnote{infatti per memorizzarne i vari livelli è stata creata la frase \texttt{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 -\figref{fig:net_osi_tcpip_comp}, con un \textit{upper layer} che riguarda solo -le applicazioni, che viene realizzato in user space, ed un \textit{lower +fig.~\ref{fig:net_osi_tcpip_comp}, con un \textit{upper layer} che riguarda +solo le applicazioni, che viene realizzato in user space, ed un \textit{lower layer} in cui si mescolano la gestione fatta dal kernel e le funzionalità fornite dall'hardware. @@ -237,14 +237,15 @@ pertanto quest'ultimo, anche per la sua maggiore semplicit \label{sec:net_tcpip_overview} Così come ISO/OSI anche il modello del TCP/IP è stato strutturato in livelli -(riassunti in \tabref{tab:net_layers}); un confronto fra i due è riportato in -\figref{fig:net_osi_tcpip_comp} dove viene evidenziata anche la corrispondenza -fra i rispettivi livelli (che comunque è approssimativa) e su come essi vanno -ad inserirsi all'interno del sistema rispetto alla divisione fra user space e -kernel space spiegata in \secref{sec:intro_unix_struct}.\footnote{in realtà è - sempre possibile accedere dallo user space, attraverso una opportuna - interfaccia (come vedremo in \secref{sec:sock_sa_packet}), ai livelli - inferiori del protocollo.} +(riassunti in tab.~\ref{tab:net_layers}); un confronto fra i due è riportato +in fig.~\ref{fig:net_osi_tcpip_comp} dove viene evidenziata anche la +corrispondenza fra i rispettivi livelli (che comunque è approssimativa) e su +come essi vanno ad inserirsi all'interno del sistema rispetto alla divisione +fra user space e kernel space spiegata in +sez.~\ref{sec:intro_unix_struct}.\footnote{in realtà è sempre possibile + accedere dallo user space, attraverso una opportuna interfaccia (come + vedremo in sez.~\ref{sec:sock_sa_packet}), ai livelli inferiori del + protocollo.} \begin{table}[htb] \centering @@ -274,7 +275,7 @@ copre il livello 2. Le funzioni dei vari livelli sono le seguenti: \begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}} \item[\textbf{Applicazione}] É relativo ai programmi di interfaccia con la rete, in genere questi vengono realizzati secondo il modello client-server - (vedi \secref{sec:net_cliserv}), realizzando una comunicazione secondo un + (vedi sez.~\ref{sec:net_cliserv}), realizzando una comunicazione secondo un protocollo che è specifico di ciascuna applicazione. \item[\textbf{Trasporto}] Fornisce la comunicazione tra le due stazioni terminali su cui girano gli applicativi, regola il flusso delle @@ -293,7 +294,7 @@ copre il livello 2. Le funzioni dei vari livelli sono le seguenti: \end{basedescript} La comunicazione fra due stazioni remote avviene secondo le modalità -illustrate in \figref{fig:net_tcpip_data_flux}, dove si è riportato il flusso +illustrate in fig.~\ref{fig:net_tcpip_data_flux}, dove si è riportato il flusso dei dati reali e i protocolli usati per lo scambio di informazione su ciascun livello. Si è genericamente indicato \textit{ethernet} per il livello 1, anche se in realtà i protocolli di trasmissione usati possono essere molti altri. @@ -306,7 +307,7 @@ se in realt \end{figure} Per chiarire meglio la struttura della comunicazione attraverso i vari -protocolli mostrata in \figref{fig:net_tcpip_data_flux}, conviene prendere in +protocolli mostrata in fig.~\ref{fig:net_tcpip_data_flux}, conviene prendere in esame i singoli passaggi fatti per passare da un livello al sottostante, la procedura si può riassumere nei seguenti passi: \begin{itemize} @@ -320,7 +321,7 @@ la procedura si pu 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 \capref{cha:socket_intro}). Qui verranno spezzati in + 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 @@ -378,10 +379,10 @@ questo poi sar \section{Il protocollo TCP/IP} \label{sec:net_tpcip} -Come accennato in \secref{sec:net_protocols} il protocollo TCP/IP è un insieme -di protocolli diversi, che operano su 4 livelli diversi. Per gli interessi -della programmazione di rete però sono importanti principalmente i due livelli -centrali, e soprattutto quello di trasporto. +Come accennato in sez.~\ref{sec:net_protocols} il protocollo TCP/IP è un +insieme di protocolli diversi, che operano su 4 livelli diversi. Per gli +interessi della programmazione di rete però sono importanti principalmente i +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. @@ -389,13 +390,13 @@ Questo avviene perch 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 \figref{fig:net_osi_tcpip_comp}) che -nei sistemi Unix (e non solo) viene inserita la divisione fra kernel space e -user space. +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 -programmazione (vedi \secref{sec:sock_sa_packet}), ma queste vengono usate +programmazione (vedi sez.~\ref{sec:sock_sa_packet}), ma queste vengono usate solo quando si debbano fare applicazioni di sistema per il controllo della rete a basso livello, di uso quindi molto specialistico. @@ -409,8 +410,8 @@ per il ruolo centrale che svolge nella maggior parte delle applicazioni. \label{sec:net_tcpip_general} Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da -molti membri. In \figref{fig:net_tcpip_overview} si è riportato uno schema che -mostra un panorama sui principali protocolli della famiglia, e delle loro +molti membri. In fig.~\ref{fig:net_tcpip_overview} si è riportato uno schema +che mostra un panorama sui principali protocolli della famiglia, e delle loro relazioni reciproche e con alcune dalle principali applicazioni che li usano. \begin{figure}[!htbp] @@ -420,7 +421,7 @@ relazioni reciproche e con alcune dalle principali applicazioni che li usano. \label{fig:net_tcpip_overview} \end{figure} -I vari protocolli riportati in \figref{fig:net_tcpip_overview} sono i +I vari protocolli riportati in fig.~\ref{fig:net_tcpip_overview} sono i seguenti: \begin{basedescript}{\desclabelwidth{1.7cm}\desclabelstyle{\nextlinelabel}} @@ -456,9 +457,9 @@ seguenti: 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 - \secref{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. + 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 @@ -566,7 +567,7 @@ grandi linee nei seguenti punti: \end{itemize} Maggiori dettagli riguardo a caratteristiche, notazioni e funzionamento del -protocollo IP sono forniti nell'appendice \secref{sec:ip_protocol}. +protocollo IP sono forniti nell'appendice sez.~\ref{sec:ip_protocol}. \subsection{User Datagram Protocol (UDP)} @@ -578,11 +579,11 @@ sostanza esso 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. +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 @@ -680,7 +681,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 -%% \secref{sec:tcp_protocol}. +%% sez.~\ref{sec:tcp_protocol}. \subsection{Limiti e dimensioni riguardanti la trasmissione dei dati} \label{sec:net_lim_dim} @@ -697,7 +698,7 @@ alle eventuali implicazioni che possono avere, \item La dimensione massima di un pacchetto IP è di 65535 byte, compresa l'intestazione. Questo è dovuto al fatto che la dimensione è indicata da un campo apposito nell'header di IP che è lungo 16 bit (vedi - \figref{fig:IP_ipv4_head}). + fig.~\ref{fig:IP_ipv4_head}). \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 @@ -706,7 +707,7 @@ alle eventuali implicazioni che possono avere, \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 \tabref{tab:net_mtu_values}. + valori possibili sono riportati in tab.~\ref{tab:net_mtu_values}. \end{itemize} Quando un pacchetto IP viene inviato su una interfaccia di rete e le sue @@ -714,7 +715,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{sec:ipv6_protocol}.}) in blocchi più + opportuna opzione, si veda sez.~\ref{sec:ipv6_protocol}.}) in blocchi più piccoli che possono essere trasmessi attraverso l'interfaccia. \begin{table}[!htb]