presuppone un sistema operativo ``multitasking'' in grado di eseguire processi
diversi.
-Il concetto fondamentale si basa la programmazione di rete sotto Linux (e
-sotto Unix in generale) è il modello \textit{client-server} in cui un
-programma di servizio, il \textit{server} riceve un connessione e risponde a
+Un concetto fondamentale su cui si basa la programmazione di rete sotto Linux
+(e sotto Unix in generale) è il modello \textit{client-server} in cui un
+programma di servizio, il \textit{server}, riceve una connessione e risponde a
un programma di utilizzo, il \textit{client}, provvedendo a quest'ultimo un
definito insieme di servizi.
\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}& \\
\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,
\begin{figure}[!htbp]
\centering
- \includegraphics[width=8cm]{img/iso_tcp_comp.eps}
+ \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}
\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. \\
lo scambio di informazione su ciascuno livello.
\begin{figure}[!htb]
\centering
- \includegraphics[width=6cm]{img/tcp_data_flux.eps}
+ \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
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.
+ trasporto usato questo sarà passato al successivo livello, quello di rete,
+ 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).
+ comunicazione (ad esempio Ethernet per una scheda di rete).
\end{itemize}
La caratteristica essenziale che rende tutto ciò possibile è la strutturazione
a livelli tramite l'incapsulamento. Ogni pacchetto di dati viene incapsulato
nel formato del livello successivo, fino al livello della connessione fisica.
-In questo modo il pacchetto ricevuto ad un livello $n$ dalla stazione di
-destinazione è esattamente lo stesso spedito dal livello $n$ dalla sorgente.
-Questo rende facile il progettare il software facendo riferimento unicamente a
-quanto necessario ad un singolo livello, con la confidenza che questo poi sarà
-trattato uniformemente da tutti i nodi della rete.
+In questo modo il pacchetto ricevuto ad un livello \textit{n} dalla stazione
+di destinazione è esattamente lo stesso spedito dal livello \textit{n} dalla
+sorgente. Questo rende facile il progettare il software facendo riferimento
+unicamente a quanto necessario ad un singolo livello, con la confidenza che
+questo poi sarà trattato uniformemente da tutti i nodi della rete.
\section{Il protocollo TCP/IP}
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
\begin{figure}[!htbp]
\centering
- \includegraphics[width=10cm]{img/tcpip_overview.eps}
+ \includegraphics[width=15cm]{img/tcpip_overview}
\caption{Panoramica sui vari protocolli che compongono la suite TCP/IP.}
\label{fig:net_tcpip_overview}
\end{figure}
\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
nodi indirizzabili molto maggiore e una autoconfigurazione degli indirizzi
\item l'introduzione un nuovo tipo di indirizzamento, l'\textit{anycast} che
si aggiunge agli usuali \textit{unycast} e \textit{multicast}
-\item la semplificazione del formato della testata, eliminando o rendendo
- opzionali alcuni dei campi di IPv4, per eliminare la necessità di
- riprocessamento della stessa da parte dei router e contenere l'aumento di
- dimensione dovuto all'ampliamento degli indirizzi
+\item la semplificazione del formato dell'intestazione (\textit{header}) dei
+ pacchetti, eliminando o rendendo opzionali alcuni dei campi di IPv4, per
+ eliminare la necessità di riprocessamento della stessa da parte dei router e
+ contenere l'aumento di dimensione dovuto all'ampliamento degli indirizzi
\item un supporto per le opzioni migliorato, per garantire una trasmissione
più efficiente del traffico normale, limiti meno stringenti sulle dimensioni
delle opzioni, e la flessibilità necessaria per introdurne di nuove in
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,
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}
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
+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]
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}
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
all'altro capo la dimensione massima del segmento di dati.
-\subsection{Il passaggio dei dati in TCP}
-\label{sec:net_tcp_pass}
+%\subsection{Il passaggio dei dati in TCP}
+%\label{sec:net_tcp_pass}
+
+%\subsection{Il passaggio dei dati in UDP}
+%\label{sec:net_udp_pass}
-\subsection{Il passaggio dei dati in UDP}
-\label{sec:net_udp_pass}
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End:
projects / gapil.git / blobdiff