%% network.tex
%%
-%% Copyright (C) 2000-2015 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 gruppo di protocolli più diffuso, il
\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à
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 \texttt{peer to peer} la comunicazione è
+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
-la 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
+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
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
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
\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'\textit{acknoweledgment} (il
- ricevuto), 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
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
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
\itindend{Path~MTU}
-Infine il TCP definisce una \itindex{Maximum~Segment~Size~(MSS)}
-\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
+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.