X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=network.tex;h=180d9aaf496d5fea91e4d173c81297208bb4e671;hp=9f84d7dd9b3b738ec96839cd0b5f3e50de4bfe11;hb=487b554b85cda92d10367d5af69a0355b9b2329d;hpb=90d696f5005a8ce307042cb6aabfff8335747380 diff --git a/network.tex b/network.tex index 9f84d7d..180d9aa 100644 --- a/network.tex +++ b/network.tex @@ -74,8 +74,10 @@ livelli, secondo quanto riportato in \ntab. \begin{table}[htb] \centering - \begin{tabular}{l c c l} - \textbf{Livello} & \multicolumn{2}{c}{\textbf{Nome}} & \\ + \begin{tabular}{|l|c|c|l|} + \hline + \textbf{Livello} & \multicolumn{2}{|c|}{\textbf{Nome}} & \\ + \hline \hline Livello 7&\textit{Application} &\textsl{Applicazione}& \\ Livello 6&\textit{Presentation} &\textsl{Presentazione}& \\ @@ -90,7 +92,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, @@ -120,8 +122,10 @@ operativo rispetto alla divisione fra user space e kernel space spiegata in \begin{table}[htb] \centering - \begin{tabular}{l c c l} - \textbf{Livello} & \multicolumn{2}{c}{\textbf{Nome}} & \textbf{Esempi} \\ + \begin{tabular}{|l|c|c|l|} + \hline + \textbf{Livello} & \multicolumn{2}{|c|}{\textbf{Nome}} & \textbf{Esempi} \\ + \hline \hline Livello 1&\textit{Application} &\textsl{Applicazione}& Telnet, FTP, etc. \\ @@ -171,7 +175,7 @@ lo scambio di informazione su ciascuno livello. \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 +196,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} @@ -308,7 +312,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 @@ -463,9 +467,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, @@ -506,18 +510,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} @@ -544,7 +548,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} @@ -567,7 +571,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