X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=network.tex;h=606a3300e9e153e6ba124a6001b4db85984f8ea5;hp=9206c50451d0c0653c9907516c8cf30c602c0c20;hb=adbc2a4478d606025705a406603e6097584b9fa0;hpb=3d44c36183fe67ed64bff95a36596ad87f620683 diff --git a/network.tex b/network.tex index 9206c50..606a330 100644 --- a/network.tex +++ b/network.tex @@ -1,114 +1,196 @@ -\chapter{Introduzione alla rete} +%% network.tex +%% +%% Copyright (C) 2000-2002 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 "Prefazione", +%% with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the +%% license is included in the section entitled "GNU Free Documentation +%% License". +%% +\part{Programmazione di rete} +\label{part:progr-di-rete} + +\chapter{Introduzione alla programmazione di rete} +\label{cha:network} + +In questo capitolo sarà fatta un'introduzione ai concetti generali che servono +come prerequisiti per capire la programmazione di rete, non tratteremo quindi +aspetti specifici ma faremo una breve introduzione al modello più comune usato +nella programmazione di rete, per poi passare ad un esame a grandi linee dei +protocolli di rete e di come questi sono organizzati e interagiscono. + +In particolare, avendo assunto l'ottica di un'introduzione mirata alla +programmazione, ci concentreremo sul protocollo più diffuso, il TCP/IP, che è +quello che sta alla base di internet, avendo cura di sottolineare i concetti +più importanti da conoscere per la scrittura dei programmi. + + + +\section{Modelli di programmazione} +\label{sec:net_prog_model} + + +La differenza principale fra un'applicazione di rete e un programma normale è +che quest'ultima per definizione concerne la comunicazione fra processi +diversi, che in generale non girano neanche sulla stessa macchina. Questo già +prefigura un cambiamento completo rispetto all'ottica del programma monolitico +all'interno del quale vengono eseguite tutte le istruzioni, e chiaramente +presuppone un sistema operativo multitasking in grado di eseguire più processi +contemporaneamente. + +In questa prima sezione esamineremo brevemente i principali modelli di +programmazione in uso. Ne daremo una descrizione assolutamente generica e +superficiale, che ne illustri le caratteristiche principali, non essendo fra +gli scopi del testo approfondire questi argomenti. + +\subsection{Il modello \textit{client-server}} +\label{sec:net_cliserv} + +Il 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 richiesta e risponde a +un programma di utilizzo, il \textit{client}, fornendo a quest'ultimo un +definito insieme di servizi. + +Infatti seguono questo modello tutti i servizi fondamentali di internet, come +il le pagine web, ftp, telnet, ssh e praticamente ogni servizio che viene +fornito tramite la rete, anche se, come abbiamo visto, il modello è utilizzato +in generale anche per programmi che, come gli esempi che abbiamo usato in +\capref{cha:IPC} a proposito della comunicazione fra processi nello stesso +sistema, non fanno necessariamente uso della rete. + +Normalmente si dividono i server in due categorie principali, e vengono detti +\textsl{concorrenti} o \textsl{iterativi}, sulla base del loro comportamento. + +Un \textsl{server iterativo} risponde alla richiesta inviando i dati e resta +occupato (non rispondendo ad ulteriori richieste) fintanto che non ha concluso +la richiesta. Una volta completata la richiesta il server diventa di nuovo +disponibile. + +Un \textsl{server concorrente} al momento di trattare la richiesta crea un +processo figlio incaricato di fornire i servizi richiesti, per poi porsi in +attesa di ulteriori richieste. In questo modo più richieste possono essere +soddisfatte contemporaneamente; una volta che il processo figlio ha concluso +il suo lavoro viene terminato, mentre il server originale resta sempre attivo. + + +\subsection{Il modello \textit{peer-to-perr}} +\label{sec:net_peertopeer} + +Da fare + +\subsection{Il modello \textit{three-tier}} +\label{sec:net_three_tier} -In questo capitolo sarà fatta un'introduzione ai contetti generali che -servono come prerequisiti per capire ed -esamineremo a grandi linee i protocolli di rete e come questi sono organizzati -e interagiscono. +Da fare \section{I protocolli di rete} -\label{sec:layer} +\label{sec:net_protocols} Parlando di reti di computer si parla in genere di un insieme molto vasto ed -eterogeneo di mezzi di comunicazione che vanno dal cavo telefonico, alla -fibra ottica, alle comunicazioni via satellite; per rendere possibile la +eterogeneo di mezzi di comunicazione che vanno dal cavo telefonico, alla fibra +ottica, alle comunicazioni via satellite o via radio; per rendere possibile la comunicazione attraverso un così variegato insieme di mezzi sono stati adottati una serie di protocolli, il più famoso dei quali, quello alla base -del funzionamento di internet, é il cosiddetto TCP/IP. +del funzionamento di internet, è il protocollo TCP/IP. \subsection{Il modello ISO/OSI} -\label{sec:iso_osi} +\label{sec:net_iso_osi} Una caratteristica comune dei protocolli di rete è il loro essere strutturati -in livelli sovrapposti; in questo modo un livello superiore esegue richieste -al livello sottostante e da questo riceve responsi, mentre livelli uguali su -macchine diverse conversano tramite lo stesso protocollo. Questo modello di -funzionamento è stato stato standardizzato dalla International Standards -Organization (ISO) che ha preparato fin dal 1984 il Modello di Riferimento -Open Systems Interconnection (OSI), strutturato in a sette livelli, secondo la -tabella in \ntab. +in livelli sovrapposti; in questo modo ogni protocollo di un certo livello +realizza le sue funzionalità basandosi su un protocollo del livello +sottostante. Questo modello di funzionamento è stato stato standardizzato +dalla \textit{International Standards Organization} (ISO) che ha preparato fin +dal 1984 il Modello di Riferimento \textit{Open Systems Interconnection} +(OSI), strutturato in sette livelli, secondo quanto riportato in +\tabref{tab:net_osilayers}. \begin{table}[htb] \centering - \begin{tabular}{l c c l} - \textbf{Livello} & \multicolumn{2}{c}{\textbf{Nome}} & \\ + \begin{tabular}{|l|c|c|} \hline - Livello 7&\textit{Application} &\textsl{Applicazione}& \\ - Livello 6&\textit{Presentation} &\textsl{Presentazione}& \\ - Livello 5&\textit{Session} &\textsl{Sessione}& \\ - Livello 4&\textit{Transport} &\textsl{Trasporto}& \\ - Livello 3&\textit{Network} &\textsl{Rete}& \\ - Livello 2&\textit{DataLink} &\textsl{Collegamento Dati}& \\ - Livello 1&\textit{Connection} &\textsl{Connessione Fisica}& \\ + \textbf{Livello} & \multicolumn{2}{|c|}{\textbf{Nome}} \\ + \hline + \hline + Livello 7&\textit{Application} &\textsl{Applicazione}\\ + Livello 6&\textit{Presentation} &\textsl{Presentazione} \\ + Livello 5&\textit{Session} &\textsl{Sessione} \\ + Livello 4&\textit{Transport} &\textsl{Trasporto} \\ + Livello 3&\textit{Network} &\textsl{Rete}\\ + Livello 2&\textit{DataLink} &\textsl{Collegamento Dati} \\ + Livello 1&\textit{Connection} &\textsl{Connessione Fisica} \\ \hline \end{tabular} \caption{I sette livelli del protocollo ISO/OSI.} -\label{tab:osilayers} +\label{tab:net_osilayers} \end{table} -Il modello ISO/OSI è stato sviluppato corrispondentemente 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, -precedente, su cui si basa TCP/IP che è diventato uno standard de facto; -quest'ultimo viene comunemente chiamato modello DoD (Department of Defense), -dato che fu sviluppato dall'agenzia ARPA per il Dipartimento della Difesa -Americano. - -\subsection{Il protocollo TCP/IP} -\label{sec:tcpip_overview} - -Così come ISO/OSI anche TCP/IP è stato strutturato in livelli (riassunti in -\ntab); un confronto fra i due è riportato in \nfig dove viene evidenziata -anche la corrispondenza fra i rispettivi livelli (che comunque è -approssimativa) e come essi vanno ad inserirsi all'interno del sistema -operativo, riguardo alla divisione fra user space e kernel space spiegata in -\ref{sec:unix_struct}. - -% L'attuale Internent Protocol (IPv4) viene standardizzato nel 1981 -% dall'RFC~719; esso nasce per disaccoppiare le applicazioni della struttura -% hardware delle reti di trasmissione, e creare una interfaccia di trasmissione -% dei dati indipendente dal sottostante substrato di rete, che può essere -% realizzato con le tecnologie più disparate (Ethernet, Token Ring, FDDI, -% etc.). - -% In realtà IP realizza solo una parte di tutto questo, e fa parte di un -% sistema che va sotto il nome di TCP/IP che è, -% uno di -% questi, quello responsabile del trasporto dei pacchetti fra le varie reti che -% compongono Internet, è appunto IP. +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 +precedente, il TCP/IP, su cui si basa internet, che è diventato uno standard +de facto. Il modello di quest'ultimo viene chiamato anche modello DoD (sigla +che sta per \textit{Department of Defense}), dato che fu sviluppato +dall'agenzia ARPA per il Dipartimento della Difesa Americano. + +\begin{figure}[!htbp] + \centering + \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} +\end{figure} + + +\subsection{Il modello TCP/IP (o DoD)} +\label{sec:net_tcpip_overview} + +Così come ISO/OSI anche il modello del TCP/IP è stato strutturato in livelli +(riassunti in \tabref{tab:net_layers}); un confronto fra i due è riportato in +\figref{fig:net_osi_tcpip_comp} dove viene evidenziata anche la corrispondenza +fra i rispettivi livelli (che comunque è approssimativa) e su come essi vanno +ad inserirsi all'interno di un sistema rispetto alla divisione fra user space +e kernel space spiegata in \secref{sec:intro_unix_struct}. \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 - Livello 1&\textit{Application} &\textsl{Applicazione}& + \hline + Livello 4&\textit{Application} &\textsl{Applicazione}& Telnet, FTP, etc. \\ - Livello 2&\textit{Transport} &\textsl{Trasporto}& TCP, UDP \\ - Livello 3&\textit{Network} &\textsl{Rete}& IP, (ICMP, IGMP) \\ - Livello 4&\textit{Link} &\textsl{Connessione}& + Livello 3&\textit{Transport} &\textsl{Trasporto}& TCP, UDP \\ + Livello 2&\textit{Network} &\textsl{Rete}& IP, (ICMP, IGMP) \\ + Livello 1&\textit{Link} &\textsl{Connessione}& device driver \& scheda di interfaccia \\ \hline \end{tabular} -\caption{I quattro livelli del protocollo TPC/IP.} -\label{tab:layers} +\caption{I quattro livelli del protocollo TCP/IP.} +\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 -\textit{Internet Protocol}. Le funzioni dei vari livelli sono le seguenti: +Come si può notare come il modello TCP/IP è più semplice del modello ISO/OSI +ed è strutturato in soli quattro livelli. Il suo nome deriva dai due +principali protocolli che lo compongono, il TCP (\textit{Trasmission Control + Protocol}) che copre il livello 3 e l'IP (\textit{Internet Protocol}) che +copre il livello 2. Le funzioni dei vari livelli sono le seguenti: \begin{description} -\item \textbf{Applicazione} É relativo ai programmi di interfaccia utente, in - genere questi vengono realizzati secondo il modello Client-Server (vedi - \ref{sec:cliserv}. +\item \textbf{Applicazione} É relativo ai programmi di interfaccia con la + rete, in genere questi vengono realizzati secondo il modello client-server + (vedi \secref{sec:net_cliserv}), realizzando una comunicazione secondo un + protocollo che è specifico di ciascuna applicazione. \item \textbf{Trasporto} Fornisce la comunicazione tra le due stazioni terminali su cui girano gli applicativi, regola il flusso delle - informazioni, e può fornire un trasporto affidabile, cioè con recupero - errori. Il protocollo principale di questo livello è il TCP. + informazioni, può fornire un trasporto affidabile, cioè con recupero degli + errori o inaffidabile. I protocolli principali di questo livello sono il TCP + e l'UDP. \item \textbf{Rete} Si occupa dello smistamento dei singoli pacchetti su una rete complessa e interconnessa, a questo stesso livello operano i protocolli per il reperimento delle informazioni necessarie allo smistamento, per lo @@ -121,38 +203,49 @@ 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. - -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 dirattamente 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). - - -\subsection{Criteri generali del design di TCP/IP} - - -La filosofia architetturale di TCP/IP è semplice: costruire una rete che +La comunicazione fra due stazioni remote avviene secondo le modalità +illustrate in \figref{fig:net_tcpip_data_flux}, dove si è riportato il flusso +dei dati reali e i protocolli usati per lo scambio di informazione su ciascun +livello. Si è genericamente indicato \textit{ethernet} per il livello 1, anche +se in realtà i protocolli di trasmissione usati possono essere molti altri. + +\begin{figure}[!htb] + \centering \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 comunicazione attraverso il TCP/IP si può pertanto +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}\index{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 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 \textit{ethernet} per una scheda di rete). +\end{itemize} + + +\subsection{Criteri generali dell'architettura del TCP/IP} +\label{sec:net_tcpip_design} + +La filosofia architetturale del TCP/IP è semplice: costruire una rete che 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. @@ -176,46 +269,387 @@ interconnessioni. 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. - - - -\section{Il modello client-server} -\label{sec:cliserv}. - -La differenza principale fra un'applicazione di rete e un programma normale -è che quest'ultima per definizione concerne la comunicazione fra -``processi'' diversi (che in generale non girano neanche sulla stessa -macchina). Questo già prefigura un cambiamento completo rispetto all'ottica -del ``programma'' monolitico all'interno del quale vengono eseguite tutte le -istruzioni, e 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 programma di utilizzo, il \textit{client}, provvedendo a quest'ultimo un -definito insieme di servizi. - -Esempi di questo modello sono il WEB, ftp, telnet, ssh e praticamente ogni -servizio che viene fornito tramite la rete, ma il modello è utilizzato in -generale anche per programmi di uso locale. - -Normalmente si dividono i server in due categorie principali, -\textit{concorrenti} e \textit{iterativi}, sulla base del loro comportamento. - -Un server iterativo risponde alla richiesta inviando i dati e resta occupato -(non rispondendo ad ulteriori richieste) fintanto che non ha concluso la -richiesta. Una volta completata la richiesta il server diventa di nuovo -disponibile. - -Un server concorrente al momento di trattare la richiesta crea un processo -figlio incaricato di fornire i servizi richiesti, per poi porsi in attesa di -ulteriori richieste. In questo modo più richieste possono essere soddisfatte -contemporaneamente, una volta che il processo figlio ha concluso il suo lavoro -viene terminato, mentre il server originale resta sempre attivo. +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} +\label{sec:net_tpcip} + +Come appena mostrato il protocollo TCP/IP è un insieme di protocolli diversi, +che operano su 4 livelli diversi. Per gli interessi della programmazione di +rete però sono importanti principalmente i due livelli centrali, e soprattutto +quello di trasporto. + +La principale interfaccia di programmazione di rete, quella dei +socket\index{socket}, è infatti un'interfaccia nei confronti di quest'ultimo. +Questo avviene perché al di sopra del livello di trasporto i programmi hanno a +che fare solo con dettagli specifici delle applicazioni, mentre al di sotto +vengono curati tutti i dettagli relativi alla comunicazione. È pertanto +naturale definire una interfaccia di programmazione su questo confine tanto +più che è proprio lì (come evidenziato in \figref{fig:net_osi_tcpip_comp}) che +nei sistemi Unix (e non solo) viene inserita la divisione fra kernel space e +user space. + +In realtà in un sistema Unix è possibile accedere anche agli altri livelli +inferiori (e non solo a quello di trasporto) con opportune interfacce (la cosa +è indicata in \figref{fig:net_osi_tcpip_comp} lasciando uno spazio fra UDP e +TCP), ma queste vengono usate solo quando si vogliono fare applicazioni di +sistema per il controllo della rete a basso livello, un uso quindi molto +specialistico, e che non rientra in quanto trattato qui. + +In questa sezione daremo una breve descrizione dei vari protocolli del TCP/IP, +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} +\label{sec:net_tcpip_general} + +Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da +altri membri. In \figref{fig:net_tcpip_overview} si è riportato uno schema che +mostra un panorama sui vari protocolli della famiglia, e delle loro relazioni +reciproche e con alcune dalle principali applicazioni che li usano. + +\begin{figure}[!htbp] + \centering + \includegraphics[width=15cm]{img/tcpip_overview} + \caption{Panoramica sui vari protocolli che compongono la suite TCP/IP.} + \label{fig:net_tcpip_overview} +\end{figure} + +I vari protocolli mostrati in figura sono i seguenti: + +\begin{list}{}{} +\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 + cui è costruita internet. Usa indirizzi a 32 bit e provvede la trasmissione + dei pacchetti TCP, UDP, ICMP e IGMP. +\item \textsl{IPv6} \textit{Internet Protocol version 6}. È stato progettato a + metà degli anni '90 per rimpiazzare IPv4. Ha indirizzi a 128 bit e effettua + lo stesso servizio di trasporto di IPv4 per i pacchetti TCP, UDP e ICPMv6. +\item \textsl{TCP} \textit{Trasmission Control Protocol}. È un protocollo + orientato alla connessione che provvede un trasporto affidabile e + bidirezionale di un flusso di dati. I socket\index{socket} TCP sono esempi + di \textit{stream socket}. Il protocollo ha cura di tutti gli aspetti del + trasporto, come l'acknoweledgment, i timeout, la ritrasmissione, etc. È + usato dalla maggior parte delle applicazioni. Può essere usato sia con IPv4 + che con IPv6. +\item \textsl{UDP} \textit{User Datagram Protocol}. È un protocollo senza + connessione, a pacchetti. I socket\index{socket} UDP sono esempi di + \textit{datagram socket}. Contrariamente al TCP il protocollo non è + affidabile e non c'è garanzia che i pacchetti raggiungano la loro + destinazione, si perdano o vengano duplicati, o abbiano un particolare + ordine di arrivo. Può essere usato sia con IPv4 che con IPv6. +\item \textsl{ICMP} \textit{Internet Control Message Protocol}. Gestisce gli + errori e trasporta l'informazione di controllo fra stazioni remote e + instradatori (\textit{host} e \textit{router}). I messaggi sono normalmente + generati dal software del kernel che gestisce la comunicazione TCP/IP, anche + se ICMP può venire usato direttamente da alcuni programmi come + \texttt{ping}. A volte ci si riferisce ad esso come ICPMv4 per distinguerlo + da ICMPv6. +\item \textsl{IGMP} \textit{Internet Group Management Protocol}. É un + protocollo usato per il \textit{multicasting} (vedi + \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 + 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 + volte per durante il boot per assegnare un indirizzo IP ad una macchina. +\item \textsl{ICMPv6} \textit{Internet Control Message Protocol, version 6}. + Combina per IPv6 le funzionalità di ICMPv4, IGMP e ARP. +\item \textsl{NETLINK} \textit{Netlink}. Provvede, in Linux, l'interfaccia di + accesso alla comunicazione a basso livello. +\end{list} + +Gran parte delle applicazioni comunicano usando TCP o UDP, solo alcune, e per +scopi particolari si rifanno dirattamente ad IP (ed i suoi correlati ICMP e +IGMP); benché sia TCP che UDP siano basati su IP e sia possibile intervenire a +questo livello con i \textit{raw socket} questa tecnica è molto meno diffusa e +a parte applicazioni particolari si preferisce sempre usare i servizi messi a +disposizione dai due protocolli precedenti. Per questo motivo a parte alcuni +brevi accenni su IP in questa sezione ci concentreremo sul livello di +trasporto. + +\subsection{Internet Protocol (IP)} +\label{sec:net_ip} + +Quando si parla di IP ci si riferisce in genere alla versione attualmente in +uso che è la versione 4 (e viene pertanto chiamato IPv4). Questa versione +venne standardizzata nel 1981 dall'RFC~719. + +Internet Protocol nasce per disaccoppiare le applicazioni della struttura +hardware delle reti di trasmissione, e creare una interfaccia di trasmissione +dei dati indipendente dal sottostante substrato di rete, che può essere +realizzato con le tecnologie più disparate (Ethernet, Token Ring, FDDI, etc.). +Il compito di IP è pertanto quello di trasmettere i pacchetti da un computer +all'altro della rete; le caratteristiche essenziali con cui questo viene +realizzato in IPv4 sono due: + +\begin{itemize} +\item \textit{Universal addressing} la comunicazione avviene fra due stazioni + remote identificate univocamente con un indirizzo a 32 bit che può + appartenere ad una sola interfaccia di rete. +\item \textit{Best effort} viene assicurato il massimo impegno nella + trasmissione, ma non c'è nessuna garanzia per i livelli superiori né sulla + percentuale di successo né sul tempo di consegna dei pacchetti di dati. +\end{itemize} + +Negli anni '90 la crescita vertiginosa del numero di macchine connesse a +internet ha iniziato a far emergere i vari limiti di IPv4, per risolverne i +problemi si è perciò definita una nuova versione del protocollo, che (saltando +un numero) è diventata la versione 6. IPv6 nasce quindi come evoluzione di +IPv4, mantendone inalterate le funzioni che si sono dimostrate valide, +eliminando quelle inutili e aggiungendone poche altre per mantenere il +protocollo il più snello e veloce possibile. + +I cambiamenti apportati sono comunque notevoli e si possono essere riassunti a +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. +\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 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 + futuro. +\item il supporto per delle capacità di \textsl{qualità di servizio} (QoS) che + permettano di identificare gruppi di dati per i quali si può provvedere un + trattamento speciale (in vista dell'uso di internet per applicazioni + multimediali e/o ``real-time''). +\end{itemize} + +Maggiori dettagli riguardo a caratteristiche, notazioni e funzionamento del +protocollo IP sono forniti nell'appendice \capref{cha:ip_protocol}. + + +\subsection{User Datagram Protocol (UDP)} +\label{sec:net_udp} + +UDP è un protocollo di trasporto molto semplice, la sua descrizione completa è +contenuta dell'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\index{socket}, al pacchetto viene aggiunto un header +molto semplice (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 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 +destinazione occorrerà provvedere con l'applicazione, all'interno della quale +si dovrà inserire tutto quanto necessario a gestire la notifica di +ricevimento, la ritrasmissione, il timeout. + +Si tenga conto poi che in UDP niente garantisce che i pacchetti arrivino nello +stesso ordine in cui sono stati trasmessi, e può anche accadere che i +pacchetti vengano duplicati nella trasmissione, e non solo perduti. Di tutto +questo di nuovo deve tenere conto l'applicazione. + +Un'altro aspetto di UDP è che se un pacchetto raggiunge correttamente la +destinazione esso viene passato all'applicazione ricevente in tutta la sua +lunghezza, la trasmissione avviene perciò per \textit{record} la cui lunghezza +viene anche essa trasmessa all'applicazione all'atto del ricevimento. + +Infine UDP è un protocollo che opera senza connessione +(\textit{connectionless}) in quanto non è necessario stabilire nessun tipo di +relazione tra origine e destinazione dei pacchetti. Si hanno così situazioni +in cui un client può scrivere su uno stesso socket\index{socket} pacchetti +destinati a server diversi, o un server ricevere su un socket\index{socket} +pacchetti provenienti da client diversi. Il modo più semplice di immaginarsi +il funzionamento di UDP è quello della radio, in cui si può +``\textsl{trasmettere a}'' e ``\textsl{ricevere da}'' più stazioni usando la +stessa frequenza. + +Nonostante gli evidenti svantaggi comportati dall'inaffidabilità UDP ha il +grande pregio della velocità che in certi casi è essenziale; inoltre si 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 multicasting. + +\subsection{Transport Control Protocol (TCP)} +\label{sec:net_tcp} + +Il TCP è un protocollo molto complesso, definito nell'RFC~739 e completamente +diverso da UDP; alla base del suo design infatti non stanno semplicità e +velocità, ma la ricerca della massima affidabilità possibile nella +trasmissione dei dati. + +La prima differenza con UDP è che TCP provvede sempre una connessione diretta +fra un client e un server, attraverso la quale essi possono comunicare; per +questo il paragone più appropriato per questo protocollo è quello del +collegamento telefonico, in quanto prima viene stabilita una connessione fra +due i due capi della comunicazione su cui poi viene quest'ultima viene +effettuata. + +Caratteristica fondamentale di TCP è l'affidabilità; quando i dati vengono +inviati attraverso una connessione ne viene richiesto un ``\textsl{ricevuto}'' +(il cosiddetto \textit{acknowlegment}), se questo non arriva essi verranno +ritrasmessi per un determinato numero di tentativi, intervallati da un periodo +di tempo crescente, fino a che sarà considerata fallita o caduta la +connessione (e generato un errore di \textit{time-out}), dopo un periodo di +tempo che dipende dall'implementazione e che può variare far i quattro e i +dieci minuti. + +Inoltre per tenere conto delle diverse condizioni in cui può trovarsi la linea +di comunicazione TCP comprende anche un algoritmo di calcolo dinamico del +tempo di andata e ritorno dei pacchetti (il cosiddetto RTT, +\textit{round-trip time}) fra un client e un server che lo rende in grado di +adattarsi alle condizioni della rete per non generare inutili ritrasmissioni o +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 +byte su un socket\index{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 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, +all'arrivo sarà comunque possibile riordinare i dati e scartare i duplicati. + +Il protocollo provvede anche un controllo di flusso (\textit{flow control}), +cioè specifica sempre all'altro capo della trasmissione quanti dati può +ricevere tramite una \textit{advertised window} (letteralmente +\textsl{finestra annunciata)}, che indica lo spazio disponibile nel buffer di +ricezione, cosicché nella trasmissione non vengano inviati più dati di quelli +che possono essere ricevuti. + +Questa finestra cambia dinamicamente diminuendo con la ricezione dei dati dal +socket\index{socket} ed aumentando con la lettura di quest'ultimo da parte +dell'applicazione, se diventa nulla il buffer di ricezione è pieno e non +verranno accettati altri dati. Si noti che UDP non provvede niente di tutto +ciò per cui nulla impedisce che vengano trasmessi pacchetti ad un rate che il +ricevente non può sostenere. + +Infine attraverso TCP la trasmissione è sempre bidirezionale (in inglese +\textit{full-duplex}), è cioè possibile sia trasmettere che ricevere allo +stesso tempo, il che poi comporta che quanto dicevamo a proposito del +controllo di flusso e della gestione della sequenzialità dei dati viene +effettuato per entrambe le direzioni di comunicazione. + +Una descrizione più accurata del protocollo è fornita in appendice +\capref{cha:tcp_protocol}. + +\subsection{Limiti e dimensioni riguardanti la trasmissione dei dati} +\label{sec:net_lim_dim} + +Un aspetto di cui bisogna tenere conto nella programmazione di rete, e che +ritornerà anche più avanti, è che ci sono una serie di limiti a cui la +trasmissione dei dati attraverso i vari livelli del protocollo deve +sottostare, limiti che è opportuno tenere presente perché in certi casi si +possono avere delle conseguenze sul comportamento delle applicazioni. + +Un elenco di questi limiti, insieme ad un breve accenno alle loro origini ed +alle eventuali implicazioni che possono avere, è il seguente: +\begin{itemize} +\item La dimensione massima di un pacchetto 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 + \figref{fig:IP_ipv4_head}). +\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 transfer unit}) che + dipende dal protocollo specifico usato al livello di link. Il più comune è + quello dell'Ethernet che è pari a 1500 byte, una serie di valori possibili + sono riportati in \tabref{tab:net_mtu_values}. +\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 \\ + FDDI & 4532 \\ + Ethernet & 1500 \\ + X.25 & 576 \\ + \hline + \end{tabular} + \caption{Valori della MTU (\textit{maximum transfer unit}) per una serie di + reti diverse.} + \label{tab:net_mtu_values} +\end{table} +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 +conto che non è affatto detto che la \textit{path MTU} sia la stessa in +entrambe le direzioni, perché l'instradamento può essere diverso nei due +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 trasmettono (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. + +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 +cui dimensioni eccedano quelle dell'MTU della rete di destinazione genererà un +messaggio di errore ICMPv4 di tipo \textit{destination unreachable, + 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 +un messaggio di errore ICMPv6 di tipo \textit{packet too big}. + +Dato che il meccanismo di frammentazione e riassemblaggio comporta +inefficienza, normalmente viene utilizzato il procedimento della \textit{path + MTU discover} (vedi RFC~1191 per IPv4 e RFC~1981 per IPv6) che permette di +trovare 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 l'RFC~1191 +per IPv4 e l'RFC~1981 per IPv6) fintanto che non si hanno più errori. + +Il TCP usa sempre questo meccanismo, che per le implementazioni di IPv4 è +opzionale, mentre diventa obbligatorio per IPv6. Per IPv6 infatti, non +potendo i router frammentare i pacchetti, è necessario, per poter comunicare, +conoscere il \textit{path MTU}. + + +Infine TCP definisce una \textit{maximum segment size} MSS che annuncia +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 UDP} +%\label{sec:net_udp_pass} + +%%% Local Variables: +%%% mode: latex +%%% TeX-master: "gapil" +%%% End: