X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=network.tex;h=0e549c9a04f83d4d8b88328ba1b9fed1e56a2c00;hp=e5d7405440926727b90784be2ad8bf6e51ea1e87;hb=b81723c64c1d63b89cd3cec12f2fcccc4a756967;hpb=d015e72d818c1632b0171cb6bea8c31018ff433e diff --git a/network.tex b/network.tex index e5d7405..0e549c9 100644 --- a/network.tex +++ b/network.tex @@ -1,6 +1,6 @@ %% 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", @@ -8,6 +8,7 @@ %% license is included in the section entitled "GNU Free Documentation %% License". %% + \chapter{Introduzione alla programmazione di rete} \label{cha:network} @@ -72,11 +73,12 @@ una risposta alla richiesta. Una volta completata la risposta il server 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}} @@ -254,12 +256,12 @@ sez.~\ref{sec:intro_unix_struct}.\footnote{in realt \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.} @@ -316,7 +318,7 @@ la procedura si pu 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 @@ -350,15 +352,15 @@ possa sopportare il carico in transito, ma permettere ai singoli nodi di 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 @@ -423,7 +425,6 @@ relazioni reciproche e con alcune dalle principali applicazioni che li usano. 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 @@ -434,7 +435,7 @@ seguenti: \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. @@ -550,7 +551,7 @@ grandi linee nei seguenti punti: \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}. @@ -575,17 +576,17 @@ protocollo IP sono forniti nell'appendice sez.~\ref{sec:ip_protocol}. \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 @@ -617,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 \textit{multicast}. \itindex{multicast} +quelle che usano il \itindex{multicast} \textit{multicast}. \subsection{Transport Control Protocol (TCP)} \label{sec:net_tcp} @@ -702,7 +703,7 @@ alle eventuali implicazioni che possono avere, 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 @@ -753,9 +754,9 @@ 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 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 @@ -769,9 +770,9 @@ di tipo \textit{packet too big}. 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. @@ -788,6 +789,7 @@ che pu 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} @@ -803,7 +805,7 @@ intestazioni di IP e TCP, in Linux il default, mantenuto nella costante % 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