From 597364c925b229bd9a8ea1a88d5e1ef885757140 Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Tue, 28 Jun 2016 17:32:55 +0000 Subject: [PATCH] Materiale vario --- listati/sockaddr_storage.h | 5 ++ network.tex | 9 ++-- tcpsock.tex | 102 +++++++++++++++++++------------------ trasplayer.tex | 3 +- 4 files changed, 62 insertions(+), 57 deletions(-) create mode 100644 listati/sockaddr_storage.h diff --git a/listati/sockaddr_storage.h b/listati/sockaddr_storage.h new file mode 100644 index 0000000..8f885d2 --- /dev/null +++ b/listati/sockaddr_storage.h @@ -0,0 +1,5 @@ +struct sockaddr_storage { + sa_family_t ss_family; /* address family: AF_xxx */ + __ss_aligntype __ss_align; + char __ss_padding[_SS_PADSIZWE]; /* address (protocol-specific) */ +}; diff --git a/network.tex b/network.tex index 575b4c5..87c5636 100644 --- a/network.tex +++ b/network.tex @@ -843,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. diff --git a/tcpsock.tex b/tcpsock.tex index d11e6a5..e26df0b 100644 --- a/tcpsock.tex +++ b/tcpsock.tex @@ -45,7 +45,7 @@ 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 \textsl{segmento} è l'unità elementare di dati trasmessa dal protocollo TCP al livello successivo; tutti - i segmenti hanno una intestazione che contiene le informazioni che servono + 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, @@ -68,8 +68,8 @@ seguente: \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 client, inoltre anche il server deve inviare il suo SYN al client (e @@ -105,8 +105,8 @@ stabilisce la connessione. \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 +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 @@ -122,7 +122,7 @@ 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 FIN. +l'\textit{acknowledgement} di un segmento FIN. \index{numeri~di~sequenza|)} \itindend{three~way~handshake} @@ -143,16 +143,16 @@ 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 + 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 @@ -207,25 +207,25 @@ caso la successione degli eventi è la seguente: \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 +\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 FIN - significa che non si riceveranno altri dati sulla connessione. + \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'\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. Come per il SYN anche il FIN occupa un byte nel numero di sequenza, per cui l'ACK @@ -239,7 +239,6 @@ scambio dei segmenti che conclude la connessione. \label{fig:TCP_close} \end{figure} - 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 @@ -250,11 +249,11 @@ procedura che è chiamata \textit{half-close}; torneremo su questo aspetto e su 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 @@ -262,9 +261,8 @@ 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 che anche se il caso più comune resta quello del client, ci sono alcuni servizi, il più noto dei quali -è l'HTTP,\footnote{la cosa si applica sempre per la versione 1.0, con le - versioni successive il default è cambiato.} per i quali è il server ad -effettuare la chiusura attiva. +è 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} @@ -312,19 +310,20 @@ che il protocollo viene ad assumere per i due lati, server e client. \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 @@ -356,22 +355,25 @@ comune trovare domande su come sia possibile evitare che un'applicazione resti 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, diff --git a/trasplayer.tex b/trasplayer.tex index 42a36f0..dce6124 100644 --- a/trasplayer.tex +++ b/trasplayer.tex @@ -26,7 +26,6 @@ In questa sezione prenderemo in esame i vari aspetti del protocollo TCP, il protocollo più comunemente usato dalle applicazioni di rete. - \subsection{Gli stati del TCP} \label{sec:TCP_states} @@ -50,13 +49,13 @@ segmento ricevuto; i nomi degli stati mostrati in fig.~\ref{fig:TCP_state_diag} sono gli stessi che vengono riportati del comando \cmd{netstat} nel campo \textit{State}. - \begin{figure}[!htb] \centering \includegraphics[width=10cm]{img/tcp_head} \caption{L'intestazione del protocollo TCP.} \label{fig:TCP_header} \end{figure} + \itindbeg{Maximum~Segment~Size~(MSS)} % TODO trattare la MSS \itindend{Maximum~Segment~Size~(MSS)} -- 2.30.2