%% network.tex
%%
-%% Copyright (C) 2000-2012 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2019 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 "Un preambolo",
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
+aspetti specifici ma faremo una breve introduzione ai modelli più comuni usati
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.
+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.
+programmazione, ci concentreremo sul gruppo di protocolli 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à
l'architettura dell'interazione è sempre nei termini di molti verso uno, il
server, che viene ad assumere un ruolo privilegiato.
-Seguono questo modello tutti i servizi fondamentali di internet, come le
+Seguono questo modello tutti i servizi fondamentali di Internet, come le
pagine web, la posta elettronica, 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 cap.~\ref{cha:IPC} a proposito della comunicazione fra
-processi nello stesso sistema, non fanno necessariamente uso della rete.
+modello è utilizzato in generale anche per programmi che non fanno
+necessariamente uso della rete, come gli esempi che abbiamo usato in
+cap.~\ref{cha:IPC} a proposito della comunicazione fra processi nello stesso
+sistema.
Normalmente si dividono i server in due categorie principali, e vengono detti
\textsl{concorrenti} o \textsl{iterativi}, sulla base del loro comportamento.
diventa di nuovo disponibile.
Un \textsl{server concorrente} al momento di trattare la richiesta crea un
-processo figlio (o un \itindex{thread} \textit{thread}) incaricato di fornire
-i servizi richiesti, per porsi immediatamente in attesa di ulteriori
-richieste. In questo modo, con sistemi multitasking, più richieste possono
-essere soddisfatte contemporaneamente. Una volta che il processo figlio ha
-concluso il suo lavoro esso di norma viene terminato, mentre il server
-originale resta sempre attivo.
+processo figlio (o un \textit{thread}) incaricato di fornire i servizi
+richiesti, per porsi immediatamente in attesa di ulteriori richieste. In
+questo modo, con sistemi multitasking, più richieste possono essere
+soddisfatte contemporaneamente. Una volta che il processo figlio ha concluso
+il suo lavoro esso di norma viene terminato, mentre il server originale resta
+sempre attivo.
\subsection{Il modello \textit{peer-to-peer}}
tramite il demone che gestisce il routing, richiede ed invia informazioni ad
altri nodi.
-In realtà in molti casi di architetture classificate come \textit{peer-to-peer}
-non è detto che la struttura sia totalmente paritetica e ci sono parecchi
-esempi in cui alcuni servizi vengono centralizzati o distribuiti
-gerarchicamente, come per lo stesso Napster, in cui le ricerche venivano
-effettuate su un server centrale.
+In realtà in molti casi di architetture classificate come
+\textit{peer-to-peer} non è detto che la struttura sia totalmente paritetica e
+ci sono parecchi esempi in cui alcuni servizi vengono centralizzati o
+distribuiti gerarchicamente, come avveniva per lo stesso Napster, in cui le
+ricerche erano effettuate su un server centrale.
Benché qui sia trattato a parte, il modello \textit{three-tier} in realtà è
una estensione del modello \textit{client-server}. Con il crescere della
-quantità dei servizi forniti in rete (in particolare su internet) ed al numero
+quantità dei servizi forniti in rete (in particolare su Internet) ed al numero
di accessi richiesto. Si è così assistito anche ad una notevole crescita di
complessità, in cui diversi servizi venivano ad essere integrati fra di loro.
dati.
+\subsection{Il modello \textit{broadcast}}
+\label{sec:net_broadcast}
+
+Uno specifico modello relativo alla programmazione di rete è poi quello in cui
+è possibile, invece della classica comunicazione uno ad uno comunque usata in
+tutti i modelli precedenti (anche nel \textit{peer-to-peer} la comunicazione è
+comunque fra singoli ``\textit{peer}''), una comunicazione da uno a molti.
+
+\itindbeg{broadcast}
+
+Questo modello nasce dal fatto che molte tecnologie di rete (ed in particolare
+Ethernet, che è probabilmente la più diffusa) hanno il supporto per effettuare
+una comunicazione in cui un nodo qualunque della rete più inviare informazioni
+in contemporanea a tutti gli altri. In questo caso si parla di
+\textit{broadcast}, utilizzando la nomenclatura usata per le trasmissioni
+radio, anche se in realtà questo tipo di comunicazione è eseguibile da un nodo
+qualunque per cui tutti quanti possono ricoprire sia il ruolo di trasmettitore
+che quello di ricevitore.
+
+\itindbeg{multicast}
+
+In genere si parla di \textit{broadcast} quando la trasmissione uno a molti è
+possibile fra qualunque nodo di una rete e gli altri, ed è supportata
+direttamente dalla tecnologia di collegamento utilizzata. L'utilizzo di questa
+forma di comunicazione da uno a molti però può risultare molto utile anche
+quando questo tipo di supporto non è disponibile (come ad esempio su Internet,
+dove non si possono contattare tutti i nodi presenti).
+
+\itindend{broadcast}
+
+In tal caso alcuni protocolli di rete (e quelli usati per Internet sono fra
+questi) supportano una variante del\textit{broadcast}, detta
+\textit{multicast}, in cui resta possibile fare una comunicazione uno a molti,
+in cui una applicazione invia i pacchetti a molte altre, in genere passando
+attraverso un opportuno supporto degli apparati ed una qualche forma di
+registrazione che consente la distribuzione della cominicazione ai nodi
+interessati.
+
+\itindend{multicast}
+
+Ovviamente i programmi che devono realizzare un tipo di comunicazione di
+questo tipo (come ad esempio potrebbero essere quelli che effettuano uno
+\textit{streaming} di informazioni) devono rispondere a delle problematiche
+del tutto diverse da quelle classiche illustrate nei modelli precedenti, e
+costituiscono pertanto un'altra classe completamente a parte.
+
+
\section{I protocolli di rete}
\label{sec:net_protocols}
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 protocollo TCP/IP.
+adottati molti protocolli, il più famoso dei quali, quello alla base del
+funzionamento di Internet, è il gruppo di protocolli comunemente chiamato
+TCP/IP.
\subsection{Il modello ISO/OSI}
\label{sec:net_iso_osi}
cui ciascuna parola corrisponde all'iniziale di uno dei livelli.}, tanto che
usualmente si tende a suddividerlo in due parti, secondo lo schema mostrato in
fig.~\ref{fig:net_osi_tcpip_comp}, con un \textit{upper layer} che riguarda
-solo le applicazioni, che viene realizzato in user space, ed un \textit{lower
- layer} in cui si mescolano la gestione fatta dal kernel e le funzionalità
-fornite dall'hardware.
+solo le applicazioni, che viene realizzato in \textit{user space}, ed un
+\textit{lower layer} in cui si mescolano la gestione fatta dal kernel e le
+funzionalità fornite dall'hardware.
Il modello ISO/OSI mira ad effettuare una classificazione completamente
generale di ogni tipo di protocollo di rete; nel frattempo però era stato
sviluppato anche un altro modello, relativo al protocollo TCP/IP, che è quello
-su cui è basata internet, che è diventato uno standard de facto. Questo
+su cui è basata Internet, che è diventato uno standard de facto. Questo
modello viene talvolta chiamato anche modello \textit{DoD} (sigla che sta per
\textit{Department of Defense}), dato che fu sviluppato dall'agenzia ARPA per
il Dipartimento della Difesa Americano.
\begin{figure}[!htb]
\centering
- \includegraphics[width=13cm]{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.}
+ \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 \textit{kernel space} e \textit{user
+ space}.}
\label{fig:net_osi_tcpip_comp}
\end{figure}
personali. Come caratteristiche generali il modello ISO/OSI è più teorico e
generico, basato separazioni funzionali, mentre il modello TCP/IP è più vicino
alla separazione concreta dei vari strati del sistema operativo; useremo
-pertanto quest'ultimo, anche per la sua maggiore semplicità.\footnote{questa
- semplicità ha un costo quando si fa riferimento agli strati più bassi, che
- sono in effetti descritti meglio dal modello ISO/OSI, in quanto gran parte
- dei protocolli di trasmissione hardware sono appunto strutturati sui due
- livelli di \textit{Data Link} e \textit{Connection}.}
+pertanto quest'ultimo, anche per la sua maggiore semplicità. Questa semplicità
+ha un costo quando si fa riferimento agli strati più bassi, che sono in
+effetti descritti meglio dal modello ISO/OSI, in quanto gran parte dei
+protocolli di trasmissione hardware sono appunto strutturati sui due livelli
+di \textit{Data Link} e \textit{Connection}.
+
\subsection{Il modello TCP/IP (o DoD)}
\label{sec:net_tcpip_overview}
in fig.~\ref{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 del sistema rispetto alla divisione
-fra user space e kernel space spiegata in
+fra \textit{user space} e \textit{kernel space} spiegata in
sez.~\ref{sec:intro_unix_struct}.\footnote{in realtà è sempre possibile
- accedere dallo user space, attraverso una opportuna interfaccia (come
- vedremo in sez.~\ref{sec:sock_sa_packet}), ai livelli inferiori del
+ accedere dallo \textit{user space}, attraverso una opportuna interfaccia
+ (come vedremo in sez.~\ref{sec:sock_sa_packet}), ai livelli inferiori del
protocollo.}
\begin{table}[htb]
un suo specifico formato. Per applicazioni generiche, come la posta o le
pagine web, viene di solito definito ed implementato quello che viene
chiamato un protocollo di applicazione (esempi possono essere HTTP, POP,
- SMTP, ecc.), ciascuno dei quali è descritto in un opportuno standard (di
- solito attraverso un RFC\footnote{l'acronimo RFC sta per \textit{Request For
- Comment} ed è la procedura attraverso la quale vengono proposti gli
- standard per Internet.}).
+ SMTP, ecc.), ciascuno dei quali è descritto in un opportuno standard, di
+ solito attraverso un RFC (l'acronimo RFC sta per
+ \itindex{Request~For~Comment~(RFC)} \textit{Request For Comment} ed è la
+ procedura attraverso la quale vengono proposti gli standard per Internet).
\item I dati delle applicazioni vengono inviati al livello di trasporto usando
un'interfaccia opportuna (i \textit{socket}, che esamineremo in dettaglio in
cap.~\ref{cha:socket_intro}). Qui verranno spezzati in pacchetti di
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.
+ 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. Questo può avvenire sia in maniera diretta, come
questo poi sarà trattato uniformemente da tutti i nodi della rete.
-\section{Il protocollo TCP/IP}
+\section{La struttura del TCP/IP}
\label{sec:net_tpcip}
-Come accennato in sez.~\ref{sec:net_protocols} 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.
+Come accennato in sez.~\ref{sec:net_protocols} il 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 usata nella programmazione di rete, quella dei
-socket (vedi sez.~\ref{cha:socket_intro}), è 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
+socket (che vedremo in sez.~\ref{cha:socket_intro}), è 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
fig.~\ref{fig:net_osi_tcpip_comp}) che nei sistemi Unix (e non solo) viene
-inserita la divisione fra kernel space e user space.
+inserita la divisione fra \textit{kernel space} e \textit{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 di
-programmazione (vedi sez.~\ref{sec:sock_sa_packet}), ma queste vengono usate
-solo quando si debbano fare applicazioni di sistema per il controllo della
-rete a basso livello, di uso quindi molto specialistico.
+In realtà in un sistema Unix è possibile accedere anche agli altri livelli (e
+non solo a quello di trasporto) con opportune interfacce di programmazione
+(vedi sez.~\ref{sec:sock_sa_packet}), ma queste vengono usate solo quando si
+debbano fare applicazioni di sistema per il controllo della rete a basso
+livello, di uso quindi molto specialistico.
In questa sezione daremo una descrizione sommaria dei vari protocolli del
TCP/IP, concentrandoci, per le ragioni appena esposte, sul livello di
che mostra un panorama sui principali protocolli della famiglia, e delle loro
relazioni reciproche e con alcune dalle principali applicazioni che li usano.
-\begin{figure}[!htbp]
+\begin{figure}[!htb]
\centering
\includegraphics[width=13cm]{img/tcpip_overview}
\caption{Panoramica sui vari protocolli che compongono la suite TCP/IP.}
\begin{basedescript}{\desclabelwidth{1.7cm}\desclabelstyle{\nextlinelabel}}
\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 mantiene tutte le
+ cui è costruita Internet. Usa indirizzi a 32 bit, e mantiene tutte le
informazioni di instradamento e controllo per la trasmissione dei pacchetti
sulla rete; tutti gli altri protocolli della suite (eccetto ARP e RARP, e
quelli specifici di IPv6) vengono trasmessi attraverso di esso.
\item[\textsl{TCP}] \textit{Trasmission Control Protocol}. È un protocollo
orientato alla connessione che provvede un trasporto affidabile per un
flusso di dati bidirezionale fra due stazioni remote. Il protocollo ha cura
- di tutti gli aspetti del trasporto, come l'acknoweledgment, i timeout, la
- ritrasmissione, ecc. È usato dalla maggior parte delle applicazioni.
+ di tutti gli aspetti del trasporto dei dati, come l'\textit{acknowledgment}
+ (il ricevuto), i timeout, la ritrasmissione, ecc. È usato dalla maggior
+ parte delle applicazioni.
\item[\textsl{UDP}] \textit{User Datagram Protocol}. È un protocollo senza
connessione, per l'invio di dati a pacchetti. Contrariamente al TCP il
protocollo non è affidabile e non c'è garanzia che i pacchetti raggiungano
venire usato direttamente da alcuni programmi come \cmd{ping}. A volte ci
si riferisce ad esso come ICPMv4 per distinguerlo da ICMPv6.
\item[\textsl{IGMP}] \textit{Internet Group Management Protocol}. É un
- protocollo di livello 2 usato per il \itindex{multicast}
- \textit{multicast} (vedi sez.~\ref{sec:xxx_multicast}). Permette
- alle stazioni remote di notificare ai router che supportano questa
- comunicazione a quale gruppo esse appartengono. Come ICMP viene
- implementato direttamente sopra IP.
+ protocollo di livello 2 usato per il \textit{multicast} (vedi
+ sez.~\ref{sec:xxx_multicast}). Permette alle stazioni remote di notificare
+ ai router che supportano questa comunicazione a quale gruppo esse
+ appartengono. Come ICMP viene implementato direttamente sopra IP.
\item[\textsl{ARP}] \textit{Address Resolution Protocol}. È il protocollo che
mappa un indirizzo IP in un indirizzo hardware sulla rete locale. È usato in
- reti di tipo \itindex{broadcast} \textit{broadcast} come Ethernet, Token
- Ring o FDDI che hanno associato un indirizzo fisico (il \textit{MAC
- address}) alla interfaccia, ma non serve in connessioni punto-punto.
+ reti di tipo \textit{broadcast} come Ethernet, Token Ring o FDDI che hanno
+ associato un indirizzo fisico (il \textit{MAC address}) alla interfaccia, ma
+ non serve in connessioni punto-punto.
\item[\textsl{RARP}] \textit{Reverse Address Resolution Protocol}. È il
protocollo che esegue l'operazione inversa rispetto ad ARP (da cui il nome)
mappando un indirizzo hardware in un indirizzo IP. Viene usato a volte per
Combina per IPv6 le funzionalità di ICMPv4, IGMP e ARP.
\item[\textsl{EGP}] \textit{Exterior Gateway Protocol}. È un protocollo di
routing usato per comunicare lo stato fra gateway vicini a livello di
- \textsl{sistemi autonomi}\footnote{vengono chiamati \textit{autonomous
- systems} i raggruppamenti al livello più alto della rete.}, con
+ \textsl{sistemi autonomi} (vengono chiamati \textit{autonomous
+ systems} i raggruppamenti al livello più alto della rete), con
meccanismi che permettono di identificare i vicini, controllarne la
raggiungibilità e scambiare informazioni sullo stato della rete. Viene
implementato direttamente sopra IP.
\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
+Quando si parla di \textit{Internet Protocol} (IP) si fa in genere riferimento
+ad una versione (la quarta, da cui il nome IPv4) che è quella più usata
+comunemente, anche se ormai si sta diffondendo sempre di più la nuova versione
+IPv6. Il protocollo IPv4 venne standardizzato nel 1981
dall'\href{http://www.ietf.org/rfc/rfc0719.txt}{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, ecc.).
-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:
+Il protocollo IP (indipendentemente dalla versione) 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
+interconnessione fisica, che può essere realizzato con le tecnologie più
+disparate (Ethernet, Token Ring, FDDI, ecc.). 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 sono due:
\begin{itemize}
\item \textit{Universal addressing} la comunicazione avviene fra due stazioni
\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
+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, mantenendone inalterate le funzioni che si sono dimostrate valide,
supportare una gerarchia con più livelli di indirizzamento, un numero di
nodi indirizzabili molto maggiore e una auto-configurazione degli indirizzi.
\item l'introduzione un nuovo tipo di indirizzamento, l'\textit{anycast} che
- si aggiunge agli usuali \textit{unicast} e \itindex{multicast}
- \textit{multicast}.
+ si aggiunge agli usuali \textit{unicast} 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 rielaborazione della stessa da parte dei router e
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
+ trattamento speciale (in vista dell'uso di Internet per applicazioni
multimediali e/o ``real-time'').
\end{itemize}
\subsection{User Datagram Protocol (UDP)}
\label{sec:net_udp}
-UDP è un protocollo di trasporto molto semplice; la sua descrizione completa è
-contenuta dell'\href{http://www.ietf.org/rfc/rfc0768.txt}{RFC~768}, ma in
-sostanza esso è una semplice interfaccia al protocollo 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, al
-pacchetto viene aggiunto un header molto semplice (per una descrizione più
-accurata vedi sez.~\ref{sec:udp_protocol}), 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.
+Il protocollo UDP è un protocollo di trasporto molto semplice; la sua
+descrizione completa è contenuta
+dell'\href{http://www.ietf.org/rfc/rfc0768.txt}{RFC~768}, ma in sostanza esso
+è una semplice interfaccia al protocollo 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, al pacchetto
+viene aggiunto un header molto semplice (per una descrizione più accurata vedi
+sez.~\ref{sec:udp_protocol}), 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
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 \itindex{multicast} \textit{multicast}.
+quelle che usano il \textit{multicast}.
\subsection{Transport Control Protocol (TCP)}
\label{sec:net_tcp}
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 fra un client e un server (il
-cosiddetto RTT, \itindex{Round~Trip~Time} \textit{Round Trip Time}), che lo
-rende in grado di adattarsi alle condizioni della rete per non generare
-inutili ritrasmissioni o cadere facilmente in timeout.
+cosiddetto RTT, \textit{Round Trip Time}), 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
\textit{acknowlegment}, all'arrivo sarà comunque possibile riordinare i dati e
scartare i duplicati.
+\itindbeg{advertised~window}
+
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 \itindex{advertised~window} \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.
+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 ed aumentando con la lettura di quest'ultimo da parte
ciò per cui nulla impedisce che vengano trasmessi pacchetti ad un ritmo che il
ricevente non può sostenere.
+\itindend{advertised~window}
+
Infine attraverso TCP la trasmissione è sempre bidirezionale (in inglese si
dice che è \textit{full-duplex}). È cioè possibile sia trasmettere che
ricevere allo stesso tempo, il che comporta che quanto dicevamo a proposito
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 una MTU \itindex{Maximum~Transfer~Unit}
- (\textit{Maximum Transfer Unit}) che dipende dal protocollo specifico usato
- al livello di connessione fisica. Il più comune è quello di ethernet che è
- pari a 1500 byte, una serie di altri valori possibili sono riportati in
- tab.~\ref{tab:net_mtu_values}.
+\itindbeg{Maximum~Transfer~Unit~(MTU)}
+\item Molte reti fisiche hanno una MTU (\textit{Maximum Transfer Unit}) che
+ dipende dal protocollo specifico usato al livello di connessione fisica. Il
+ più comune è quello di ethernet che è pari a 1500 byte, una serie di altri
+ valori possibili sono riportati in tab.~\ref{tab:net_mtu_values}.
\end{itemize}
-\itindbeg{Maximum~Transfer~Unit}
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 suddivisi\footnote{questo
+\textit{frammentazione}, i pacchetti cioè vengono suddivisi in blocchi più
+piccoli che possono essere trasmessi attraverso l'interfaccia.\footnote{questo
accade sia per IPv4 che per IPv6, anche se i pacchetti frammentati sono
gestiti con modalità diverse, IPv4 usa un flag nell'header, IPv6 una
- opportuna opzione, si veda sez.~\ref{sec:ipv6_protocol}.}) in blocchi più
-piccoli che possono essere trasmessi attraverso l'interfaccia.
+ opportuna opzione, si veda sez.~\ref{sec:ipv6_protocol}.}
\begin{table}[!htb]
\centering
\label{tab:net_mtu_values}
\end{table}
+%TODO aggiornare la tabella con dati più recenti
+
+\itindbeg{Path~MTU}
+
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
potendo i router frammentare i pacchetti, è necessario, per poter comunicare,
conoscere da subito il \textit{path MTU}.
-Infine TCP definisce una \itindex{Maximum~Segment~Size} \textit{Maximum
- Segment Size} (da qui in avanti abbreviata in MSS) che annuncia all'altro
-capo della connessione la dimensione massima dimensione del segmento di dati
-che può essere ricevuto, così da evitare la frammentazione. Di norma viene
-impostato alla dimensione della MTU dell'interfaccia meno la lunghezza delle
-intestazioni di IP e TCP, in Linux il default, mantenuto nella costante
-\const{TCP\_MSS} è 512.
+\itindend{Path~MTU}
+
+Infine il TCP definisce una \textit{Maximum Segment Size} o MSS (vedi
+sez.~\ref{sec:tcp_protocol}) che annuncia all'altro capo della connessione la
+dimensione massima del segmento di dati che può essere ricevuto, così da
+evitare la frammentazione. Di norma viene impostato alla dimensione della MTU
+dell'interfaccia meno la lunghezza delle intestazioni di IP e TCP, in Linux il
+default, mantenuto nella costante \constd{TCP\_MSS} è 512.
-\itindend{Maximum~Transfer~Unit}
+\itindend{Maximum~Transfer~Unit~(MTU)}
%%% Local Variables:
projects / gapil.git / blobdiff