-bg%% tcpsock.tex
+%% tcpsock.tex
%%
-%% Copyright (C) 2000-2015 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2016 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",
descrizione delle principali caratteristiche del funzionamento di una
connessione TCP; vedremo poi le varie funzioni che servono alla creazione di
una connessione fra client e server, fornendo alcuni esempi elementari, e
-finiremo prendendo in esame l'uso dell'I/O multiplexing.
+finiremo prendendo in esame l'uso dell'\textit{I/O multiplexing}.
\section{Il funzionamento di una connessione TCP}
Si ricordi che il protocollo TCP serve a creare degli \textit{stream socket},
cioè una forma di canale di comunicazione che stabilisce una connessione
-stabile fra due stazioni, in modo che queste possano scambiarsi dei dati. In
-questa sezione ci concentreremo sulle modalità con le quali il protocollo dà
-inizio e conclude una connessione e faremo inoltre un breve accenno al
-significato di alcuni dei vari \textsl{stati} ad essa associati.
+stabile fra due macchine in rete, in modo che queste possano scambiarsi dei
+dati. In questa sezione ci concentreremo sulle modalità con le quali il
+protocollo dà inizio e conclude una connessione e faremo inoltre un breve
+accenno al significato di alcuni dei vari \textsl{stati} ad essa associati.
\subsection{La creazione della connessione: il \textit{three way handshake}}
Il processo che porta a creare una connessione TCP viene chiamato
\textit{three way handshake}; la successione tipica degli eventi (e dei
-\textsl{segmenti}\footnote{si ricordi che il segmento è l'unità elementare di
- dati trasmessa dal protocollo TCP al livello successivo; tutti i segmenti
- hanno un header che contiene le informazioni che servono allo \textit{stack
- TCP} (così viene di solito chiamata la parte del kernel che implementa il
- protocollo) per realizzare la comunicazione, fra questi dati ci sono una
- serie di flag usati per gestire la connessione, come SYN, ACK, URG, FIN,
- alcuni di essi, come SYN (che sta per \textit{syncronize}) corrispondono a
- funzioni particolari del protocollo e danno il nome al segmento, (per
- maggiori dettagli vedere sez.~\ref{sec:tcp_protocol}).} di dati che vengono
-scambiati) che porta alla creazione di una connessione è la seguente:
+\textsl{segmenti}\footnote{si ricordi che il \textsl{segmento} è l'unità
+ elementare di dati trasmessa dal protocollo TCP al livello successivo; tutti
+ i segmenti hanno un'intestazione che contiene le informazioni che servono
+ allo \textit{stack TCP} (così viene di solito chiamata la parte del kernel
+ che implementa il protocollo) per realizzare la comunicazione, fra questi
+ dati ci sono una serie di flag usati per gestire la connessione, come SYN,
+ ACK, URG, FIN, alcuni di essi, come SYN (che sta per \textit{syncronize})
+ corrispondono a funzioni particolari del protocollo e danno il nome al
+ segmento, (per maggiori dettagli vedere sez.~\ref{sec:tcp_protocol}).} di
+dati che vengono scambiati) che porta alla creazione di una connessione è la
+seguente:
\begin{enumerate}
\item Il server deve essere preparato per accettare le connessioni in arrivo;
\textsl{apertura attiva}, dall'inglese \textit{active open}. La chiamata di
\func{connect} blocca il processo e causa l'invio da parte del client di un
segmento SYN, in sostanza viene inviato al server un pacchetto IP che
- contiene solo gli header IP e TCP (con il numero di sequenza iniziale e il
- flag SYN) e le opzioni di TCP.
+ contiene solo le instestazioni di IP e TCP (con il numero di sequenza
+ iniziale e il flag SYN) e le opzioni di TCP.
-\item il server deve dare ricevuto (l'\textit{acknowledge}) del SYN del
+\item Il server deve dare ricevuto (l'\textit{acknowledge}) del SYN del
client, inoltre anche il server deve inviare il suo SYN al client (e
trasmettere il suo numero di sequenza iniziale) questo viene fatto
ritrasmettendo un singolo segmento in cui sono impostati entrambi i flag SYN
e ACK.
-\item una volta che il client ha ricevuto l'acknowledge dal server la funzione
- \func{connect} ritorna, l'ultimo passo è dare il ricevuto del SYN del
- server inviando un ACK. Alla ricezione di quest'ultimo la funzione
+\item Una volta che il client ha ricevuto l'\textit{acknowledge} dal server la
+ funzione \func{connect} ritorna, l'ultimo passo è dare il ricevuto del SYN
+ del server inviando un ACK. Alla ricezione di quest'ultimo la funzione
\func{accept} del server ritorna e la connessione è stabilita.
\end{enumerate}
Il procedimento viene chiamato \textit{three way handshake} dato che per
-realizzarlo devono essere scambiati tre segmenti. In fig.~\ref{fig:TCP_TWH}
+realizzarlo devono essere scambiati tre segmenti. In fig.~\ref{fig:TCP_TWH}
si è rappresentata graficamente la sequenza di scambio dei segmenti che
stabilisce la connessione.
\label{fig:TCP_TWH}
\end{figure}
-Si è accennato in precedenza ai \textsl{numeri di sequenza} (che sono anche
-riportati in fig.~\ref{fig:TCP_TWH}): per gestire una connessione affidabile
+\index{numeri~di~sequenza|(}
+
+Si è accennato in precedenza ai \textsl{numeri di sequenza}, che sono anche
+riportati in fig.~\ref{fig:TCP_TWH}: per gestire una connessione affidabile
infatti il protocollo TCP prevede nell'header la presenza di un numero a 32
bit (chiamato appunto \textit{sequence number}) che identifica a quale byte
nella sequenza del flusso corrisponde il primo byte della sezione dati
Il numero di sequenza di ciascun segmento viene calcolato a partire da un
\textsl{numero di sequenza iniziale} generato in maniera casuale del kernel
-all'inizio della connessione e trasmesso con il SYN; l'acknowledgement di
-ciascun segmento viene effettuato dall'altro capo della connessione impostando
-il flag ACK e restituendo nell'apposito campo dell'header un
-\textit{acknowledge number}) pari al numero di sequenza che il ricevente si
-aspetta di ricevere con il pacchetto successivo; dato che il primo pacchetto
-SYN consuma un byte, nel \textit{three way handshake} il numero di acknowledge
-è sempre pari al numero di sequenza iniziale incrementato di uno; lo stesso
-varrà anche (vedi fig.~\ref{fig:TCP_close}) per l'acknowledgement di un FIN.
-
+all'inizio della connessione e trasmesso con il SYN;
+l'\textit{acknowledgement} di ciascun segmento viene effettuato dall'altro
+capo della connessione impostando il flag ACK e restituendo nell'apposito
+campo dell'header un \textit{acknowledge number}) pari al numero di sequenza
+che il ricevente si aspetta di ricevere con il pacchetto successivo; dato che
+il primo pacchetto SYN consuma un byte, nel \textit{three way handshake} il
+numero di \textit{acknowledge} è sempre pari al numero di sequenza iniziale
+incrementato di uno; lo stesso varrà anche (vedi fig.~\ref{fig:TCP_close}) per
+l'\textit{acknowledgement} di un segmento FIN.
+
+\index{numeri~di~sequenza|)}
\itindend{three~way~handshake}
\label{sec:TCP_TCP_opt}
Ciascun segmento SYN contiene in genere delle opzioni per il protocollo TCP,
-le cosiddette \textit{TCP options},\footnote{da non confondere con le opzioni
- dei socket TCP che tratteremo in sez.~\ref{sec:sock_tcp_udp_options}, in
- questo caso si tratta delle opzioni che vengono trasmesse come parte di un
- pacchetto TCP, non delle funzioni che consentono di impostare i relativi
- valori.} che vengono inserite fra l'header e i dati, e che servono a
-comunicare all'altro capo una serie di parametri utili a regolare la
+le cosiddette \textit{TCP options}, da non confondere con le opzioni dei
+socket TCP che tratteremo in sez.~\ref{sec:sock_tcp_udp_options}; in questo
+caso infatti si tratta delle opzioni che vengono trasmesse come parte di un
+pacchetto TCP, e non delle funzioni che consentono di impostare i relativi
+valori. Queste opzioni vengono inserite fra l'intestazione ed i dati, e
+servono a comunicare all'altro capo una serie di parametri utili a regolare la
connessione. Normalmente vengono usate le seguenti opzioni:
\begin{itemize}
\item \textit{MSS option}, con questa opzione ciascun capo della connessione
annuncia all'altro il massimo ammontare di dati (MMS sta appunto per
- \textit{Maximum Segment Size}) che vorrebbe accettare per ciascun segmento
- nella connessione corrente. È possibile leggere e scrivere questo valore
- attraverso l'opzione del socket \const{TCP\_MAXSEG} (vedi
- sez.~\ref{sec:sock_tcp_udp_options}).
+ \textit{Maximum Segment Size}, vedi sez.~\ref{sec:tcp_protocol}) che
+ vorrebbe accettare per ciascun segmento nella connessione corrente. È
+ possibile leggere e scrivere questo valore attraverso l'opzione del socket
+ \const{TCP\_MAXSEG} (vedi sez.~\ref{sec:sock_tcp_udp_options}).
\item \textit{window scale option}, il protocollo TCP implementa il controllo
di flusso attraverso una \textit{advertised window} (la ``\textsl{finestra
- annunciata}'', vedi sez.~\ref{sec:tcp_protocol_xxx}) con la quale ciascun
+ annunciata}'', vedi sez.~\ref{sec:tcp_protocol}) con la quale ciascun
capo della comunicazione dichiara quanto spazio disponibile ha in memoria
- per i dati. Questo è un numero a 16 bit dell'header, che così può indicare
- un massimo di 65535 byte;\footnote{in Linux il massimo è 32767 per evitare
+ per i dati. Questo è un numero a 16 bit dell'header, che così può indicare
+ un massimo di 65535 byte\footnote{in Linux il massimo è 32767 per evitare
problemi con alcune implementazioni che usano l'aritmetica con segno per
implementare lo stack TCP.} ma alcuni tipi di connessione come quelle ad
alta velocità (sopra i 45Mbit/sec) e quelle che hanno grandi ritardi nel
cammino dei pacchetti (come i satelliti) richiedono una finestra più grande
- per poter ottenere il massimo dalla trasmissione. Per questo esiste questa
- opzione che indica un fattore di scala da applicare al valore della finestra
- annunciata\footnote{essendo una nuova opzione per garantire la compatibilità
- con delle vecchie implementazioni del protocollo la procedura che la
- attiva prevede come negoziazione che l'altro capo della connessione
- riconosca esplicitamente l'opzione inserendola anche lui nel suo SYN di
- risposta dell'apertura della connessione.} per la connessione corrente
+ per poter ottenere il massimo dalla trasmissione.
+
+ Per questo esiste un'altra opzione che indica un fattore di scala da
+ applicare al valore della finestra annunciata per la connessione corrente
(espresso come numero di bit cui spostare a sinistra il valore della
- finestra annunciata inserito nel pacchetto). Con Linux è possibile indicare
- al kernel di far negoziare il fattore di scala in fase di creazione di una
- connessione tramite la \textit{sysctl} \texttt{tcp\_window\_scaling} (vedi
- sez.~\ref{sec:sock_ipv4_sysctl}).\footnote{per poter usare questa
- funzionalità è comunque necessario ampliare le dimensioni dei buffer di
- ricezione e spedizione, cosa che può essere fatta sia a livello di sistema
- con le opportune \textit{sysctl} (vedi sez.~\ref{sec:sock_ipv4_sysctl})
- che a livello di singoli socket con le relative opzioni (vedi
- sez.~\ref{sec:sock_tcp_udp_options}).}
+ finestra annunciata inserito nel pacchetto). Essendo una nuova opzione per
+ garantire la compatibilità con delle vecchie implementazioni del protocollo
+ la procedura che la attiva prevede come negoziazione che l'altro capo della
+ connessione riconosca esplicitamente l'opzione inserendola anche lui nel suo
+ SYN di risposta dell'apertura della connessione.
+
+ Con Linux è possibile indicare al kernel di far negoziare il fattore di
+ scala in fase di creazione di una connessione tramite la \textit{sysctl}
+ \texttt{tcp\_window\_scaling} (vedi sez.~\ref{sec:sock_ipv4_sysctl}). Per
+ poter usare questa funzionalità è comunque necessario ampliare le dimensioni
+ dei buffer di ricezione e spedizione, cosa che può essere fatta sia a
+ livello di sistema con le opportune \textit{sysctl} (vedi
+ sez.~\ref{sec:sock_ipv4_sysctl}) che a livello di singoli socket con le
+ relative opzioni (vedi sez.~\ref{sec:sock_tcp_udp_options}).
\item \textit{timestamp option}, è anche questa una nuova opzione necessaria
per le connessioni ad alta velocità per evitare possibili corruzioni di dati
- dovute a pacchetti perduti che riappaiono; anche questa viene negoziata come
- la precedente.
+ dovute a pacchetti perduti che riappaiono; anche questa viene negoziata
+ all'inizio della connessione come la precedente.
\end{itemize}
-La MSS è generalmente supportata da quasi tutte le implementazioni del
-protocollo, le ultime due opzioni (trattate
+La \textit{MSS option} è generalmente supportata da quasi tutte le
+implementazioni del protocollo, le ultime due opzioni (trattate
nell'\href{http://www.ietf.org/rfc/rfc1323.txt}{RFC~1323}) sono meno comuni;
vengono anche dette \textit{long fat pipe options} dato che questo è il nome
che viene dato alle connessioni caratterizzate da alta velocità o da ritardi
-elevati. In ogni caso Linux supporta pienamente entrambe le opzioni.
+elevati. In ogni caso Linux supporta pienamente entrambe queste opzioni
+aggiuntive.
\subsection{La terminazione della connessione}
\textit{active close}). Questo comporta l'emissione di un segmento FIN, che
serve ad indicare che si è finito con l'invio dei dati sulla connessione.
-\item L'altro capo della connessione riceve il FIN e dovrà eseguire la
- \textsl{chiusura passiva} (o \textit{passive close}). Al FIN, come ad ogni
- altro pacchetto, viene risposto con un ACK, inoltre il ricevimento del FIN
- viene segnalato al processo che ha aperto il socket (dopo che ogni altro
- eventuale dato rimasto in coda è stato ricevuto) come un end-of-file sulla
- lettura: questo perché il ricevimento di un FIN significa che non si
- riceveranno altri dati sulla connessione.
+\item L'altro capo della connessione riceve il segmento FIN e dovrà eseguire
+ la \textsl{chiusura passiva} (o \textit{passive close}). Al FIN, come ad
+ ogni altro pacchetto, viene risposto con un ACK, inoltre il ricevimento del
+ FIN viene segnalato al processo che ha aperto il socket (dopo che ogni altro
+ eventuale dato rimasto in coda è stato ricevuto) come un
+ \textit{end-of-file} sulla lettura: questo perché il ricevimento di un
+ segmento FIN significa che non si riceveranno altri dati sulla connessione.
-\item Una volta rilevata l'end-of-file anche il secondo processo chiamerà la
- funzione \func{close} sul proprio socket, causando l'emissione di un altro
- segmento FIN.
+\item Una volta rilevata l'\textit{end-of-file} anche il secondo processo
+ chiamerà la funzione \func{close} sul proprio socket, causando l'emissione
+ di un altro segmento FIN.
-\item L'altro capo della connessione riceverà il FIN conclusivo e risponderà
- con un ACK.
+\item L'altro capo della connessione riceverà il segmento FIN conclusivo e
+ risponderà con un ACK.
\end{enumerate}
Dato che in questo caso sono richiesti un FIN ed un ACK per ciascuna direzione
normalmente i segmenti scambiati sono quattro. Questo non è vero sempre
-giacché in alcune situazioni il FIN del passo 1) è inviato insieme a dei dati.
+giacché in alcune situazioni il FIN del passo 1 è inviato insieme a dei dati.
Inoltre è possibile che i segmenti inviati nei passi 2 e 3 dal capo che
-effettua la chiusura passiva, siano accorpati in un singolo segmento. In
-fig.~\ref{fig:TCP_close} si è rappresentato graficamente lo sequenza di
+effettua la chiusura passiva, siano accorpati in un singolo segmento. Come per
+il SYN anche il FIN occupa un byte nel numero di sequenza, per cui l'ACK
+riporterà un \textit{acknowledge number} incrementato di uno. In
+fig.~\ref{fig:TCP_close} si è rappresentata graficamente la sequenza di
scambio dei segmenti che conclude la connessione.
\begin{figure}[!htb]
\label{fig:TCP_close}
\end{figure}
-Come per il SYN anche il FIN occupa un byte nel numero di sequenza, per cui
-l'ACK riporterà un \textit{acknowledge number} incrementato di uno.
-
Si noti che, nella sequenza di chiusura, fra i passi 2 e 3, è in teoria
possibile che si mantenga un flusso di dati dal capo della connessione che
deve ancora eseguire la chiusura passiva a quello che sta eseguendo la
come utilizzarlo in sez.~\ref{sec:TCP_shutdown}, quando parleremo della
funzione \func{shutdown}.
-La emissione del FIN avviene quando il socket viene chiuso, questo però non
-avviene solo per la chiamata esplicita della funzione \func{close}, ma anche
-alla terminazione di un processo, quando tutti i file vengono chiusi. Questo
-comporta ad esempio che se un processo viene terminato da un segnale tutte le
-connessioni aperte verranno chiuse.
+La emissione del segmento FIN avviene quando il socket viene chiuso, questo
+però non avviene solo per la chiamata esplicita della funzione \func{close},
+ma anche alla terminazione di un processo, quando tutti i file vengono chiusi.
+Questo comporta ad esempio che se un processo viene terminato da un segnale
+tutte le connessioni aperte verranno chiuse.
Infine occorre sottolineare che, benché nella figura (e nell'esempio che
vedremo più avanti in sez.~\ref{sec:TCP_echo}) sia stato il client ad eseguire
la chiusura attiva, nella realtà questa può essere eseguita da uno qualunque
dei due capi della comunicazione (come nell'esempio di
-fig.~\ref{fig:TCP_daytime_iter_server_code}), e anche se il caso più comune
-resta quello del client, ci sono alcuni servizi, il principale dei quali è
-l'HTTP, per i quali è il server ad effettuare la chiusura attiva.
+fig.~\ref{fig:TCP_daytime_iter_server_code}), e che anche se il caso più
+comune resta quello del client, ci sono alcuni servizi, il più noto dei quali
+è l'HTTP 1.0 (con le versioni successive il default è cambiato) per i quali è
+il server ad effettuare la chiusura attiva.
\subsection{Un esempio di connessione}
\label{fig:TCP_conn_example}
\end{figure}
-La connessione viene iniziata dal client che annuncia una MSS di 1460, un
-valore tipico con Linux per IPv4 su Ethernet, il server risponde con lo stesso
-valore (ma potrebbe essere anche un valore diverso).
+La connessione viene iniziata dal client che annuncia una \textit{Maximum
+ Segment Size} di 1460, un valore tipico con Linux per IPv4 su Ethernet, il
+server risponde con lo stesso valore (ma potrebbe essere anche un valore
+diverso).
Una volta che la connessione è stabilita il client scrive al server una
richiesta (che assumiamo stare in un singolo segmento, cioè essere minore dei
1460 byte annunciati dal server), quest'ultimo riceve la richiesta e
restituisce una risposta (che di nuovo supponiamo stare in un singolo
-segmento). Si noti che l'acknowledge della richiesta è mandato insieme alla
-risposta: questo viene chiamato \textit{piggybacking} ed avviene tutte le
-volte che il server è sufficientemente veloce a costruire la risposta; in
-caso contrario si avrebbe prima l'emissione di un ACK e poi l'invio della
-risposta.
+segmento). Si noti che l'\textit{acknowledge} della richiesta è mandato
+insieme alla risposta: questo viene chiamato \textit{piggybacking} ed avviene
+tutte le volte che il server è sufficientemente veloce a costruire la
+risposta; in caso contrario si avrebbe prima l'emissione di un ACK e poi
+l'invio della risposta.
Infine si ha lo scambio dei quattro segmenti che terminano la connessione
secondo quanto visto in sez.~\ref{sec:TCP_conn_term}; si noti che il capo della
in questo stato lasciando attiva una connessione ormai conclusa; la risposta è
che non deve essere fatto, ed il motivo cercheremo di spiegarlo adesso.
+\itindex{Maximum~Segment~Lifetime}
Come si è visto nell'esempio precedente (vedi fig.~\ref{fig:TCP_conn_example})
\texttt{TIME\_WAIT} è lo stato finale in cui il capo di una connessione che
esegue la chiusura attiva resta prima di passare alla chiusura definitiva
della connessione. Il tempo in cui l'applicazione resta in questo stato deve
-essere due volte la MSL (\textit{Maximum Segment Lifetime}).
-
-La MSL è la stima del massimo periodo di tempo che un pacchetto IP può vivere
-sulla rete; questo tempo è limitato perché ogni pacchetto IP può essere
-ritrasmesso dai router un numero massimo di volte (detto \textit{hop limit}).
-Il numero di ritrasmissioni consentito è indicato dal campo TTL dell'header di
-IP (per maggiori dettagli vedi sez.~\ref{sec:ip_protocol}), e viene
-decrementato ad ogni passaggio da un router; quando si annulla il pacchetto
-viene scartato. Siccome il numero è ad 8 bit il numero massimo di
-``\textsl{salti}'' è di 255, pertanto anche se il TTL (da \textit{time to
- live}) non è propriamente un limite sul tempo di vita, si stima che un
-pacchetto IP non possa restare nella rete per più di MSL secondi.
+essere due volte la \textit{Maximum Segment Lifetime} (da qui in avanti
+abbreviata in MSL).
+
+La MSL è la stima del massimo periodo di tempo in secondi che un pacchetto IP
+può vivere sulla rete. Questo tempo è limitato perché ogni pacchetto IP può
+essere ritrasmesso dai router un numero massimo di volte (detto \textit{hop
+ limit}). Il numero di ritrasmissioni consentito è indicato dal campo TTL
+dell'intestazione di IP (per maggiori dettagli vedi
+sez.~\ref{sec:ip_protocol}), e viene decrementato ad ogni passaggio da un
+router; quando si annulla il pacchetto viene scartato. Siccome il numero è ad
+8 bit il numero massimo di ``\textsl{salti}'' è di 255, pertanto anche se il
+TTL (da \textit{time to live}) non è propriamente un limite sul tempo, sulla
+sua base si stimare che un pacchetto IP non possa restare nella rete per più
+un certo numero di secondi che costituisce la \textit{Maximum Segment Lifetime}.
Ogni implementazione del TCP deve scegliere un valore per la MSL
(l'\href{http://www.ietf.org/rfc/rfc1122.txt}{RFC~1122} raccomanda 2 minuti,
projects / gapil.git / blobdiff