X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=network.tex;h=49c6a5f5825aff98a3adfb5a4ccf3df00b957dda;hp=38861150f79d9dee8f5c632303f5b48c4560a247;hb=e20a546af590a50e7ac47f68f6c7d4648bb4f31a;hpb=0ab3f419ed7721862f3a3bc012d681fbefdf0cfa diff --git a/network.tex b/network.tex index 3886115..49c6a5f 100644 --- a/network.tex +++ b/network.tex @@ -90,7 +90,7 @@ livelli, secondo quanto riportato in \ntab. \label{tab:net_osilayers} \end{table} -Il modello ISO/OSI è stato sviluppato corrispondentemente alla definizione +Il modello ISO/OSI è stato sviluppato in corrispondenza alla definizione della serie di protocolli X.25 per la commutazione di pacchetto. Ma nonostante il lavoro dettagliato di standardizzazione il modello si è rivelato sostanzialmente troppo complesso e poco flessibile rispetto a quello, @@ -101,7 +101,7 @@ della Difesa Americano. \begin{figure}[!htbp] \centering - \includegraphics[width=8cm]{img/iso_tcp_comp} + \includegraphics[width=12cm]{img/iso_tcp_comp} \caption{Struttura a livelli dei protocolli OSI e TCP/IP, con la relative corrispondenze e la divisione fra kernel e user space.} \label{fig:net_osi_tcpip_comp} @@ -165,13 +165,13 @@ La comunicazione fra due stazioni avviene secondo le modalit lo scambio di informazione su ciascuno livello. \begin{figure}[!htb] \centering - \includegraphics[width=6cm]{img/tcp_data_flux} + \includegraphics[width=10cm]{img/tcp_data_flux} \caption{Strutturazione del flusso dei dati nella comunicazione fra due applicazioni attraverso i protocolli della suite TCP/IP.} \label{fig:net_tcpip_data_flux} \end{figure} -La struttura della comuniczione pertanto si può riassumere nei seguenti passi: +La struttura della comunicazione pertanto si può riassumere nei seguenti passi: \begin{itemize} \item Le singole applicazioni si scambieranno i dati secondo un loro formato specifico, implementando un protocollo di applicazione (esempi possono @@ -192,7 +192,7 @@ La struttura della comuniczione pertanto si pu \item L'ultimo passo è il trasferimento del pacchetto al driver della interfaccia di trasmissione che si incarica di incapsularlo nel relativo protocollo di trasmissione fisica usato dall'hardware usato per la - comunicazione (ad esempio ethernet per una scheda di rete). + comunicazione (ad esempio Ethernet per una scheda di rete). \end{itemize} @@ -259,6 +259,7 @@ concentrandoci per le ragioni esposte sul livello di trasporto. All'interno di questo privilegeremo poi il protocollo TCP, per il ruolo centrale che svolge nella maggior parte delle applicazioni. + \subsection{Il quadro generale} Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da @@ -307,7 +308,7 @@ I vari protocolli mostrati in figura sono i seguenti: \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 + internet). È usato in reti di tipo broadcast come Ethernet, Token Ring o FDDI ma non serve in connessioni punto-punto. \item \textsl{RARP} \textit{Reverse Address Resolution Protocol}. È il protocollo che mappa un indirizzo hardware in un indirizzo IP. Viene usato a @@ -462,9 +463,9 @@ 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 -bytes su un socket TCP, questi potranno essere spezzati dal protocollo in due +byte su un socket TCP, questi potranno essere spezzati dal protocollo in due segmenti (le unità di dati passate da TCP a IP vengono chiamate -\textit{segment}) di 1500 bytes, di cui il primo conterrà il numero di +\textit{segment}) di 1500 byte, di cui il primo conterrà il numero di sequenza $1-1500$ e il secondo il numero $1501-3000$. In questo modo anche se i segmenti arrivano a destinazione in un ordine diverso, o se alcuni arrivano più volte a causa di ritrasmissioni dovute alla perdita dei ricevuto, @@ -505,18 +506,18 @@ delle applicazioni. Un elenco di questi limiti è il seguente, insieme ad un breve accenno alle loro origini ed alle eventuali implicazioni che possono avere: \begin{itemize} -\item La dimensione massima di un pacchetti IP è di 65535 bytes, compreso +\item La dimensione massima di un pacchetti IP è di 65535 byte, compreso l'header. Questo è dovuto al fatto che la dimensione è indicata da un campo apposito nell'header di IP che è lungo 16 bit (vedi \tabref{tab:IP_ipv4head}). -\item La dimensione massima di un pacchetto normale di IPv6 è di 65575 bytes, +\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 un pacchetto usando la \textit{jumbo payload option}. -\item Molte reti fisiche hanno un MTU (\textit{maximum tranfer unit}) che +\item Molte reti fisiche hanno un MTU (\textit{maximum transfer 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 + quello dell'Ethernet che è pari a 1500 byte, una serie di valori possibili sono riportati in \ntab. \end{itemize} @@ -543,7 +544,7 @@ possono essere trasmessi attraverso l'interfaccia. X.25 & 576 \\ \hline \end{tabular} - \caption{Valori della MTU (\textit{maximum tranfer unit}) per una serie di + \caption{Valori della MTU (\textit{maximum transfer unit}) per una serie di reti diverse.} \label{tab:net_mtu_values} \end{table} @@ -566,7 +567,7 @@ Nell'header di IPv4 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}. + fragmentation 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