X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=network.tex;h=dde8230c6171e0e27670efe095c373c0007cfb11;hp=6470c1fbef3e6cfef0dfa0d1aa42b189aa3c982e;hb=fa15a3f1ecd64efd8440e46d398fd9976abc3d25;hpb=e91584927c1db3e0b5d08facab44c76b197c101d diff --git a/network.tex b/network.tex index 6470c1f..dde8230 100644 --- a/network.tex +++ b/network.tex @@ -1,6 +1,6 @@ %% 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", @@ -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 -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 @@ -29,7 +29,6 @@ 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à @@ -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 -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 @@ -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, - 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 @@ -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 -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 @@ -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 - 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 @@ -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 - \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. @@ -568,18 +567,19 @@ 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 +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 @@ -773,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 -\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 @@ -799,6 +799,8 @@ piccoli che possono essere trasmessi attraverso l'interfaccia. \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 @@ -841,11 +843,10 @@ conoscere da subito il \textit{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 default, mantenuto nella costante \constd{TCP\_MSS} è 512.