Merge branch 'master' of ssh://gapil.gnulinux.it/srv/git/gapil

[gapil.git] / network.tex

diff --git a/network.tex b/network.tex
index 490112b816f839196374cfcf4a034ece60a40181..dde8230c6171e0e27670efe095c373c0007cfb11 100644 (file)
--- a/network.tex
+++ b/network.tex
@@ -1,6 +1,6 @@
 %% network.tex
 %%
 %% 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",
 %% 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",


@@ -14,9 +14,9 @@
 
 In questo capitolo sarà fatta un'introduzione ai concetti generali che servono
 come prerequisiti per capire la programmazione di rete, non tratteremo quindi
 
 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
 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
 
 In particolare, avendo assunto l'ottica di un'introduzione mirata alla
 programmazione, ci concentreremo sul gruppo di protocolli più diffuso, il


@@ -29,7 +29,6 @@ programmi.
 \section{Modelli di programmazione}
 \label{sec:net_prog_model}
 
 \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à
 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à


@@ -163,15 +162,15 @@ dati.
 
 Uno specifico modello relativo alla programmazione di rete è poi quello in cui
 è possibile, invece della classica comunicazione uno ad uno comunque usata in
 
 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
 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
 \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


@@ -369,10 +368,10 @@ la procedura si può riassumere nei seguenti passi:
   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,
   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
 \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


@@ -439,9 +438,9 @@ 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
 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
 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


@@ -494,9 +493,9 @@ seguenti:
 \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
 \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
 \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


@@ -516,9 +515,9 @@ seguenti:
   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
   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
 \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


@@ -527,8 +526,8 @@ seguenti:
   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
   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. 
   meccanismi che permettono di identificare i vicini, controllarne la
   raggiungibilità e scambiare informazioni sullo stato della rete. Viene
   implementato direttamente sopra IP. 


@@ -568,18 +567,19 @@ trasporto.
 \subsection{Internet Protocol (IP)}
 \label{sec:net_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}.
 
 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
 
 \begin{itemize}
 \item \textit{Universal addressing} la comunicazione avviene fra due stazioni


@@ -627,17 +627,18 @@ protocollo IP sono forniti nell'appendice sez.~\ref{sec:ip_protocol}.
 \subsection{User Datagram Protocol (UDP)}
 \label{sec:net_udp}
 
 \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
 
 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


@@ -698,9 +699,9 @@ 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 fra un client e un server (il
 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~(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.
+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
 
 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


@@ -772,11 +773,11 @@ alle eventuali implicazioni che possono avere, è il seguente:
 
 Quando un pacchetto IP viene inviato su una interfaccia di rete e le sue
 dimensioni eccedono la MTU viene eseguita la cosiddetta
 
 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
   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
 
 \begin{table}[!htb]
   \centering


@@ -798,6 +799,8 @@ piccoli che possono essere trasmessi attraverso l'interfaccia.
   \label{tab:net_mtu_values}
 \end{table}
 
   \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
 \itindbeg{Path~MTU}
 
 La MTU più piccola fra due stazioni viene in genere chiamata \textit{path


@@ -840,13 +843,12 @@ conoscere da subito il \textit{path MTU}.
 
 \itindend{Path~MTU}
 
 
 \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
 dell'interfaccia meno la lunghezza delle intestazioni di IP e TCP, in Linux il

-default, mantenuto nella costante \const{TCP\_MSS} è 512.
+default, mantenuto nella costante \constd{TCP\_MSS} è 512.

 
 \itindend{Maximum~Transfer~Unit~(MTU)}
 
 
 \itindend{Maximum~Transfer~Unit~(MTU)}