X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=network.tex;h=879f9708bda4d2ccc59f534e7806865604d9aaab;hp=f6b571ba196abee09037536fcb40247c489c758f;hb=09473ed326013ece27d53cd5ff9f96064cbce9f3;hpb=056bbc90c8a0710b57fa7b13f5f0dfdad1b3ff3f diff --git a/network.tex b/network.tex index f6b571b..879f970 100644 --- a/network.tex +++ b/network.tex @@ -350,17 +350,15 @@ quest'ultimo viene comunemente chiamato modello DoD (\textit{Department of Defense}), dato che fu sviluppato dall'agenzia ARPA per il Dipartimento della Difesa Americano. - \begin{figure}[!htbp] \centering - + \includegraphics[width=8cm]{img/iso_tcp_comp.eps} \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} \end{figure} - \subsection{Il modello DoD (TCP/IP)} \label{sec:net_tcpip_overview} @@ -388,7 +386,6 @@ operativo rispetto alla divisione fra user space e kernel space spiegata in \label{tab:net_layers} \end{table} - Come si può notare TCP/IP è più semplice del modello ISO/OSI e strutturato in soli quattro livelli. Il suo nome deriva dai due principali protocolli che lo compongono, il TCP \textit{Trasmission Control Protocol} e l'IP @@ -414,41 +411,40 @@ compongono, il TCP \textit{Trasmission Control Protocol} e l'IP \end{description} -La comunicazione fra due stazioni avviene pertanto secondo le modalità -illustrate in \nfig. - - -\begin{figure}[!htbp] +La comunicazione fra due stazioni avviene secondo le modalità illustrate in +\nfig, dove si è riportato il flusso dei dati reali e i protocolli usati per +lo scambio di informazione su ciascuno livello. +\begin{figure}[!htb] \centering - + \includegraphics[width=6cm]{img/tcp_data_flux.eps} \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} -Le singole applicazioni si scambieranno i dati secondo un loro formato -specifico, implementando un protocollo di applicazione (esempi possono essere -HTTP, POP, telnet, SMTP, etc). - -Questi dati vengono inviati al livello di trasporto usando un'interfaccia -opportuna (i \textit{socket}, che esamineremo in dettaglio in seguito), i -quali li spezzerà in pacchetti di dimensione opportuna e li incapsulerà -all'interno del suo protocollo di trasporto aggiungendo ad ogni pacchetto le -informazioni necessarie alla gestione di quest'ultimo. Questo processo viene -svolto direttamente nel kernel ad esempio dallo stack TCP nel caso il -protocollo di trasporto sia questo. - -Una volta composto il pacchetto nel formato adatto al protocollo di trasporto -usato questo sarà passato al successivo livello, quello del collegamento che -si occupa di inserire le opportune informazioni per poter effettuare -l'instradamento nella rete ed il recapito alla destinazione finale. In genere -questo è il livello di IP (Internet Protocol), a cui vengono inseriti i numeri -IP che identificano i computer su internet. - -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). +La struttura della comuniczione 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 + essere HTTP, POP, telnet, SMTP, etc). +\item Questi dati vengono inviati al livello di trasporto usando + un'interfaccia opportuna (i \textit{socket}, che esamineremo in dettaglio in + seguito). Qui verranno spezzati in pacchetti di dimensione opportuna e + incapsulati nel protocollo di trasporto, aggiungendo ad ogni pacchetto le + informazioni necessarie per la sua gestione. Questo processo viene + svolto direttamente nel kernel ad esempio dallo stack TCP nel caso il + protocollo di trasporto sia questo. +\item Una volta composto il pacchetto nel formato adatto al protocollo di + trasporto usato questo sarà passato al successivo livello, quello del + collegamento che si occupa di inserire le opportune informazioni per poter + effettuare l'instradamento nella rete ed il recapito alla destinazione + finale. In genere questo è il livello di IP (Internet Protocol), a cui + vengono inseriti i numeri IP che identificano i computer su internet. +\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). +\end{itemize} \subsection{Criteri generali del design di TCP/IP} @@ -523,7 +519,7 @@ alcune dalle principali applicazioni che li usano. \begin{figure}[!htbp] \centering - + \includegraphics[width=10cm]{img/tcpip_overview.eps} \caption{Panoramica sui vari protocolli che compongono la suite TCP/IP.} \label{fig:net_tcpip_overview} \end{figure} @@ -647,7 +643,7 @@ contenuta dell'RFC~768, ma in sostanza esso 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 +(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 @@ -763,7 +759,7 @@ 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 - \secref{sec:appA_ipv4head}). + \tabref{tab:IP_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 @@ -775,12 +771,21 @@ loro origini ed alle eventuali implicazioni che possono avere: sono riportati in \ntab. \end{itemize} +Quando un pacchetto IP viene inviato su una interfaccia di rete e le sue +dimensioni eccedono la MTU viene eseguita la cosiddetta +\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_protocol}}), in blocchi più piccoli che +possono essere trasmessi attraverso l'interfaccia. + \begin{table}[!htb] \centering \begin{tabular}[c]{|l|c|} \hline \textbf{Rete} & \textbf{MTU} \\ \hline + \hline Hyperlink & 65535 \\ Token Ring IBM (16 Mbit/sec) & 17914 \\ Token Ring IEEE 802.5 (4 Mbit/sec) & 4464 \\ @@ -794,14 +799,6 @@ loro origini ed alle eventuali implicazioni che possono avere: \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}, 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