tratteremo qui dunque il funzionamento delle varie funzioni che si sono usate
nei due esempi elementari forniti in precedenza (vedi
\secref{sec:net_cli_sample} e \secref{sec:net_serv_sample}), previa una
tratteremo qui dunque il funzionamento delle varie funzioni che si sono usate
nei due esempi elementari forniti in precedenza (vedi
\secref{sec:net_cli_sample} e \secref{sec:net_serv_sample}), previa una
di una connessione, che possono essere osservati per ciascun socket attivo con
l'uso del programma \texttt{netstat}.
di una connessione, che possono essere osservati per ciascun socket attivo con
l'uso del programma \texttt{netstat}.
\label{sec:TCPel_conn_cre}
Il processo che porta a creare una connessione TCP è chiamato \textit{three
\label{sec:TCPel_conn_cre}
Il processo che porta a creare una connessione TCP è chiamato \textit{three
verifica utilizzando il codice dei due precedenti esempi elementari
\figref{fig:net_cli_code} e \figref{fig:net_serv_code}) che porta alla
creazione di una connessione è la seguente:
verifica utilizzando il codice dei due precedenti esempi elementari
\figref{fig:net_cli_code} e \figref{fig:net_serv_code}) che porta alla
creazione di una connessione è la seguente:
che implementa il protocollo) per realizzare la comunicazione, fra questi
dati ci sono una serie di flag usati per gestire la connessione, come
\texttt{SYN}, \texttt{ACK}, \texttt{URG}, \texttt{FIN}, alcuni di essi,
che implementa il protocollo) per realizzare la comunicazione, fra questi
dati ci sono una serie di flag usati per gestire la connessione, come
\texttt{SYN}, \texttt{ACK}, \texttt{URG}, \texttt{FIN}, alcuni di essi,
funzioni particolari del protocollo e danno il nome al segmento, (per
maggiori dettagli vedere \capref{cha:tcp_protocol})}, in sostanza viene
inviato al server un pacchetto IP che contiene solo gli header IP e TCP (con
funzioni particolari del protocollo e danno il nome al segmento, (per
maggiori dettagli vedere \capref{cha:tcp_protocol})}, in sostanza viene
inviato al server un pacchetto IP che contiene solo gli header IP e TCP (con
\item \textit{MSS option} Sta per \textit{maximum segment size}, con questa
opzione ciascun capo della connessione annuncia all'altro il massimo
ammontare di dati che vorrebbe accettare per ciascun segmento nella
\item \textit{MSS option} Sta per \textit{maximum segment size}, con questa
opzione ciascun capo della connessione annuncia all'altro il massimo
ammontare di dati che vorrebbe accettare per ciascun segmento nella
l'opzione del socket \texttt{TCP\_MAXSEG}.
\item \textit{window scale option} come spiegato in \capref{cha:tcp_protocol} il
protocollo TCP implementa il controllo di flusso attraverso una
\textsl{finestra annunciata} (\textit{advertized window}) con la quale
ciascun capo della comunicazione dichiara quanto spazio disponibile ha in
l'opzione del socket \texttt{TCP\_MAXSEG}.
\item \textit{window scale option} come spiegato in \capref{cha:tcp_protocol} il
protocollo TCP implementa il controllo di flusso attraverso una
\textsl{finestra annunciata} (\textit{advertized window}) con la quale
ciascun capo della comunicazione dichiara quanto spazio disponibile ha in
- memoria per i dati. Questo è un numero a 16 bit dell'haeader, che così può
- indicare un massimo di 65535 bytes (anche se linux usa come massimo 32767
+ memoria per i dati. Questo è un numero a 16 bit dell'header, che così può
+ indicare un massimo di 65535 bytes (anche se Linux usa come massimo 32767
per evitare problemi con alcuni stack bacati che usano l'aritmetica con
segno per implementare lo stack TCP); ma alcuni tipi di connessione come
quelle ad alta velocità (sopra i 45Mbits/sec) e quelle che hanno grandi
per evitare problemi con alcuni stack bacati che usano l'aritmetica con
segno per implementare lo stack TCP); ma alcuni tipi di connessione come
quelle ad alta velocità (sopra i 45Mbits/sec) e quelle che hanno grandi
protocollo, le ultime due opzioni (trattate nell'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
protocollo, le ultime due opzioni (trattate nell'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
\subsection{La terminazione della connessione}
\label{sec:TCPel_conn_term}
Mentre per creare una connessione occorre un interscambio di tre segmenti, la
\subsection{La terminazione della connessione}
\label{sec:TCPel_conn_term}
Mentre per creare una connessione occorre un interscambio di tre segmenti, la
riferimento al codice degli esempi \figref{fig:net_cli_code} e
\figref{fig:net_serv_code}, in questo caso la successione degli eventi è la
seguente:
riferimento al codice degli esempi \figref{fig:net_cli_code} e
\figref{fig:net_serv_code}, in questo caso la successione degli eventi è la
seguente:
\item L'altro capo della connessione riceve il FIN ed esegue la
\textit{chiusura passiva} (da \textit{passive close}); al FIN, come per
tutti i pacchetti, viene risposto con un ACK. Inoltre il ricevimento del FIN
\item L'altro capo della connessione riceve il FIN ed esegue la
\textit{chiusura passiva} (da \textit{passive close}); al FIN, come per
tutti i pacchetti, viene risposto con un ACK. Inoltre il ricevimento del FIN
lettura (dopo che ogni altro eventuale dato rimasto in coda è stato
ricevuto), dato che il ricevimento di un FIN significa che non si
riceveranno altri dati sulla connessione.
lettura (dopo che ogni altro eventuale dato rimasto in coda è stato
ricevuto), dato che il ricevimento di un FIN significa che non si
riceveranno altri dati sulla connessione.
Dato che in questo caso sono richiesti un FIN ed un ACK per ciascuna direzione
normalmente i segmenti scambiati sono quattro; normalmente giacché in alcune
Dato che in questo caso sono richiesti un FIN ed un ACK per ciascuna direzione
normalmente i segmenti scambiati sono quattro; normalmente giacché in alcune
detto, anche se è possibile, che i segmenti inviati nei passi 2 e 3, siano
accorpati in un singolo segmento. In \nfig\ si è rappresentato graficamente lo
sequenza di scambio dei segmenti che stabilisce la connessione.
detto, anche se è possibile, che i segmenti inviati nei passi 2 e 3, siano
accorpati in un singolo segmento. In \nfig\ si è rappresentato graficamente lo
sequenza di scambio dei segmenti che stabilisce la connessione.
viene terminato da un segnale tutte le connessioni aperte verranno chiuse.
Infine è da sottolineare che, benché nella figura (e nell'esempio che vedremo
viene terminato da un segnale tutte le connessioni aperte verranno chiuse.
Infine è da sottolineare che, benché nella figura (e nell'esempio che vedremo
chiusura attiva, nella realtà questa può essere eseguita da uno qualunque dei
due capi della comunicazione (come in fatto in precedenza da
\figref{fig:net_serv_code}), e benché quello del client sia il caso più comune
chiusura attiva, nella realtà questa può essere eseguita da uno qualunque dei
due capi della comunicazione (come in fatto in precedenza da
\figref{fig:net_serv_code}), e benché quello del client sia il caso più comune
stesso valore (ma potrebbe essere anche un valore diverso).
Una volta che la connessione è stabilita il client scrive al server una
stesso valore (ma potrebbe essere anche un valore diverso).
Una volta che la connessione è stabilita il client scrive al server una
non ricevendo risposta, provvederà alla ritrasmissione e se nel frattempo sarà
stata stabilita una strada alternativa il pacchetto ritrasmesso giungerà a
destinazione. Ma se dopo un po' di tempo (che non supera il limite dell'MSL)
non ricevendo risposta, provvederà alla ritrasmissione e se nel frattempo sarà
stata stabilita una strada alternativa il pacchetto ritrasmesso giungerà a
destinazione. Ma se dopo un po' di tempo (che non supera il limite dell'MSL)
pacchetti intrappolati potranno essere inviati alla destinazione finale, con
la conseguenza di avere dei pacchetti duplicati; questo è un caso che il TCP
deve essere in grado di gestire.
pacchetti intrappolati potranno essere inviati alla destinazione finale, con
la conseguenza di avere dei pacchetti duplicati; questo è un caso che il TCP
deve essere in grado di gestire.
In realtà rispetto a quanto indicato nell'RFC1700 i vari sistemi hanno fatto
scelte diverse per le porte effimere, in particolare in \nfig\ sono riportate
In realtà rispetto a quanto indicato nell'RFC1700 i vari sistemi hanno fatto
scelte diverse per le porte effimere, in particolare in \nfig\ sono riportate
-quelle di BSD, Solaris e linux. Nel caso di linux poi la scelta fra i due
-intervali possibili viene fatta dinamicamente a seconda della memoria a
-disposizione del kernel per gestire le rative tabelle.
+quelle di BSD, Solaris e Linux. Nel caso di Linux poi la scelta fra i due
+intervalli possibili viene fatta dinamicamente a seconda della memoria a
+disposizione del kernel per gestire le relative tabelle.
Per capire meglio l'uso delle porte e come vengono utilizzate quando si ha a
che fare con un'applicazione client/server (come quella che scriveremo in
Per capire meglio l'uso delle porte e come vengono utilizzate quando si ha a
che fare con un'applicazione client/server (come quella che scriveremo in
indirizzo 195.110.112.152) potremo avere un risultato del tipo:
\begin{verbatim}
Active Internet connections (servers and established)
indirizzo 195.110.112.152) potremo avere un risultato del tipo:
\begin{verbatim}
Active Internet connections (servers and established)
Questo ci mostra ad esempio che il server ssh ha compiuto un'apertura passiva
mettendosi in ascolto sulla porta 22 riservata a questo servizio e che si è
posto in ascolto per connessioni provenienti da uno qualunque degli indirizzi
Questo ci mostra ad esempio che il server ssh ha compiuto un'apertura passiva
mettendosi in ascolto sulla porta 22 riservata a questo servizio e che si è
posto in ascolto per connessioni provenienti da uno qualunque degli indirizzi
equivalente all'asterisco utilizzato per il numero di porta ed indica il
valore generico, e corrisponde al valore \texttt{INADDR\_ANY} definito in
\texttt{arpa/inet.h}.
equivalente all'asterisco utilizzato per il numero di porta ed indica il
valore generico, e corrisponde al valore \texttt{INADDR\_ANY} definito in
\texttt{arpa/inet.h}.
Una volta che ci si vorrà collegare a questa macchina da un'altra posta
all'indirizzo 192.84.146.100 si potrà lanciare un client \texttt{ssh} per
Una volta che ci si vorrà collegare a questa macchina da un'altra posta
all'indirizzo 192.84.146.100 si potrà lanciare un client \texttt{ssh} per
una porta effimera che per esempio potrà essere la 21100, la connessione
allora sarà espressa dalla socket pair $(192.84.146.100:21100,
195.110.112.152.22)$.
una porta effimera che per esempio potrà essere la 21100, la connessione
allora sarà espressa dalla socket pair $(192.84.146.100:21100,
195.110.112.152.22)$.
\begin{verbatim}
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
\begin{verbatim}
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
alle connessioni che arrivano verso tale indirizzo.
Normalmente un client non specifica mai un indirizzo ad un suo socket, ed il
alle connessioni che arrivano verso tale indirizzo.
Normalmente un client non specifica mai un indirizzo ad un suo socket, ed il
sulla base dell'interfaccia usata per trasmettere i pacchetti, (che dipende
dalle regole di instradamento usate per raggiungere il server).
Se un server non specifica il suo indirizzo locale il kernel userà come
sulla base dell'interfaccia usata per trasmettere i pacchetti, (che dipende
dalle regole di instradamento usate per raggiungere il server).
Se un server non specifica il suo indirizzo locale il kernel userà come
Per specificare un indirizzo generico con IPv4 si usa il valore
\texttt{INADDR\_ANY}, il cui valore, come visto anche negli esempi precedenti
Per specificare un indirizzo generico con IPv4 si usa il valore
\texttt{INADDR\_ANY}, il cui valore, come visto anche negli esempi precedenti
un'assegnazione immediata del tipo:
\begin{verbatim}
serv_add.sin_addr.s_addr = htonl(INADDR_ANY); /* connect from anywhere */
un'assegnazione immediata del tipo:
\begin{verbatim}
serv_add.sin_addr.s_addr = htonl(INADDR_ANY); /* connect from anywhere */
Si noti che si è usato \texttt{htonl} per assegnare il valore
\texttt{INADDR\_ANY}; benché essendo questo pari a zero il riordinamento sia
Si noti che si è usato \texttt{htonl} per assegnare il valore
\texttt{INADDR\_ANY}; benché essendo questo pari a zero il riordinamento sia
\item \texttt{EAFNOSUPPORT} l'indirizzo non ha una famiglia di indirizzi
corretta nel relativo campo.
\item \texttt{EACCESS, EPERM} si è tentato di eseguire una connessione ad un
\item \texttt{EAFNOSUPPORT} l'indirizzo non ha una famiglia di indirizzi
corretta nel relativo campo.
\item \texttt{EACCESS, EPERM} si è tentato di eseguire una connessione ad un
%
\item Il client riceve come risposta al SYN un RST significa che non c'è
nessun programma in ascolto per la connessione sulla porta specificata (il
%
\item Il client riceve come risposta al SYN un RST significa che non c'è
nessun programma in ascolto per la connessione sulla porta specificata (il
non è stato avviato il server), questo è un errore fatale e la funzione
ritorna non appena il RST viene ricevuto riportando un errore
\texttt{ECONNREFUSED}.
non è stato avviato il server), questo è un errore fatale e la funzione
ritorna non appena il RST viene ricevuto riportando un errore
\texttt{ECONNREFUSED}.
Il flag RST sta per \textit{reset} ed è un segmento inviato direttamente
dal TCP quando qualcosa non va. Tre condizioni che generano un RST sono:
quando arriva un SYN per una porta che non ha nessun server in ascolto,
Il flag RST sta per \textit{reset} ed è un segmento inviato direttamente
dal TCP quando qualcosa non va. Tre condizioni che generano un RST sono:
quando arriva un SYN per una porta che non ha nessun server in ascolto,
segmento per una connessione che non esiste.
\item Il SYN del client provoca l'emissione di un messaggio ICMP di
destinazione non raggiungibile. In questo caso dato che il messaggio può
segmento per una connessione che non esiste.
\item Il SYN del client provoca l'emissione di un messaggio ICMP di
destinazione non raggiungibile. In questo caso dato che il messaggio può
come nel caso precedente, fino al timeout, e solo allora si restituisce il
codice di errore dovuto al messaggio ICMP, che da luogo ad un
\texttt{ENETUNREACH}.
come nel caso precedente, fino al timeout, e solo allora si restituisce il
codice di errore dovuto al messaggio ICMP, che da luogo ad un
\texttt{ENETUNREACH}.
Si noti infine che con la funzione \texttt{connect} si è specificato solo
indirizzo e porta del server, quindi solo una metà della socket pair; essendo
Si noti infine che con la funzione \texttt{connect} si è specificato solo
indirizzo e porta del server, quindi solo una metà della socket pair; essendo
locale viene lasciata all'assegnazione automatica del kernel, e non è
necessario effettuare una \texttt{bind}.
locale viene lasciata all'assegnazione automatica del kernel, e non è
necessario effettuare una \texttt{bind}.
\begin{enumerate}
\item Una coda delle connessioni incomplete (\textit{incomplete connection
queue} che contiene un ingresso per ciascun socket per il quale è arrivato
\begin{enumerate}
\item Una coda delle connessioni incomplete (\textit{incomplete connection
queue} che contiene un ingresso per ciascun socket per il quale è arrivato
sono tutti nello stato \texttt{SYN\_RECV}.
\item Una coda delle connessioni complete (\textit{complete connection queue}
sono tutti nello stato \texttt{SYN\_RECV}.
\item Una coda delle connessioni complete (\textit{complete connection queue}
handshake è stato completato ma ancora \texttt{accept} non è ritornata.
Questi socket sono tutti nello stato \texttt{ESTABLISHED}.
\end{enumerate}
handshake è stato completato ma ancora \texttt{accept} non è ritornata.
Questi socket sono tutti nello stato \texttt{ESTABLISHED}.
\end{enumerate}
client il server crea una nuova entrata nella coda delle connessioni
incomplete, e poi risponde con il SYN$+$ACK. La entrata resterà nella coda
delle connessioni incomplete fino al ricevimento dell'ACK dal client o fino ad
client il server crea una nuova entrata nella coda delle connessioni
incomplete, e poi risponde con il SYN$+$ACK. La entrata resterà nella coda
delle connessioni incomplete fino al ricevimento dell'ACK dal client o fino ad
sostata nella coda delle connessioni complete. Quando il processo chiama la
funzione \texttt{accept} (vedi \secref{sec:TCPel_func_accept}) la prima
entrata nella coda delle connessioni complete è passata al programma, o, se la
sostata nella coda delle connessioni complete. Quando il processo chiama la
funzione \texttt{accept} (vedi \secref{sec:TCPel_func_accept}) la prima
entrata nella coda delle connessioni complete è passata al programma, o, se la
massimo valore della somma del numero di entrate possibili per ciascuna di
dette code. Stevens riporta che BSD ha sempre applicato un fattore di 1.5 al
valore, e provvede una tabella con i risultati ottenuti con vari kernel,
massimo valore della somma del numero di entrate possibili per ciascuna di
dette code. Stevens riporta che BSD ha sempre applicato un fattore di 1.5 al
valore, e provvede una tabella con i risultati ottenuti con vari kernel,
2.2 per prevenire l'attacco chiamato \texttt{syn flood}. Questo si basa
sull'emissione da parte dell'attaccante di un grande numero di pacchetti SYN
indirizzati verso una porta forgiati con indirizzo IP fasullo\footnote{con la
2.2 per prevenire l'attacco chiamato \texttt{syn flood}. Questo si basa
sull'emissione da parte dell'attaccante di un grande numero di pacchetti SYN
indirizzati verso una porta forgiati con indirizzo IP fasullo\footnote{con la
\texttt{/proc/sys/net/ipv4/tcp\_max\_syn\_backlog}. Quando si attiva la
protezione dei syncookies però (con l'opzione da compilare nel kernel e da
attivare usando \texttt{/proc/sys/net/ipv4/tcp\_syncookies}) questo valore
\texttt{/proc/sys/net/ipv4/tcp\_max\_syn\_backlog}. Quando si attiva la
protezione dei syncookies però (con l'opzione da compilare nel kernel e da
attivare usando \texttt{/proc/sys/net/ipv4/tcp\_syncookies}) questo valore
La scelta storica per il valore di questo parametro è di 5, e alcuni vecchi
kernel non supportavano neanche valori superiori, ma la situazione corrente è
La scelta storica per il valore di questo parametro è di 5, e alcuni vecchi
kernel non supportavano neanche valori superiori, ma la situazione corrente è
occupato fra chiamate successive alla \texttt{accept} (per cui la coda più
occupata sarebbe quella delle connessioni completate), ma piuttosto quello di
gestire la presenza di un gran numero di SYN in attesa di concludere il
occupato fra chiamate successive alla \texttt{accept} (per cui la coda più
occupata sarebbe quella delle connessioni completate), ma piuttosto quello di
gestire la presenza di un gran numero di SYN in attesa di concludere il
Infine va messo in evidenza che nel caso di socket TCP quando un SYN arriva
con tutte le code piene, il pacchetto deve essere ignorato. Questo perché la
condizione in cui le code sono piene è ovviamente transitoria, per cui se il
Infine va messo in evidenza che nel caso di socket TCP quando un SYN arriva
con tutte le code piene, il pacchetto deve essere ignorato. Questo perché la
condizione in cui le code sono piene è ovviamente transitoria, per cui se il
trovare nella coda lo spazio per una nuova connessione. Se invece si
rispondesse con un RST per indicare l'impossibilità di effettuare la
connessione la chiamata a \texttt{connect} nel client ritornerebbe con una
trovare nella coda lo spazio per una nuova connessione. Se invece si
rispondesse con un RST per indicare l'impossibilità di effettuare la
connessione la chiamata a \texttt{connect} nel client ritornerebbe con una
La funzione può essere usata solo con socket che supportino la connessione
(cioè di tipo \texttt{SOCK\_STREAM}, \texttt{SOCK\_SEQPACKET} o
\texttt{SOCK\_RDM}). Per alcuni protocolli che richiedono una conferma
La funzione può essere usata solo con socket che supportino la connessione
(cioè di tipo \texttt{SOCK\_STREAM}, \texttt{SOCK\_SEQPACKET} o
\texttt{SOCK\_RDM}). Per alcuni protocolli che richiedono una conferma
comportamento), la funzione opera solo l'estrazione dalla coda delle
connessioni, la conferma della connessione viene fatta implicitamente dalla
prima chiamata ad una \texttt{read} o una \texttt{write} mentre il rifiuto
della connessione viene fatto con la funzione \texttt{close}.
comportamento), la funzione opera solo l'estrazione dalla coda delle
connessioni, la conferma della connessione viene fatta implicitamente dalla
prima chiamata ad una \texttt{read} o una \texttt{write} mentre il rifiuto
della connessione viene fatto con la funzione \texttt{close}.
errori rispetto ad altre implementazioni dei socket BSD, infatti la funzione
\texttt{accept} passa gli errori di rete pendenti sul nuovo socket come codici
di errore per \texttt{accept}. Inoltre la funzione non fa ereditare ai nuovi
errori rispetto ad altre implementazioni dei socket BSD, infatti la funzione
\texttt{accept} passa gli errori di rete pendenti sul nuovo socket come codici
di errore per \texttt{accept}. Inoltre la funzione non fa ereditare ai nuovi
socket descriptor non è più utilizzabile dal processo e non può essere usato
come argomento per una \texttt{write} o una \texttt{read} (anche se l'altro
capo della connessione non avesse chiuso la sua parte). Il kernel invierà
socket descriptor non è più utilizzabile dal processo e non può essere usato
come argomento per una \texttt{write} o una \texttt{read} (anche se l'altro
capo della connessione non avesse chiuso la sua parte). Il kernel invierà
Vedremo più avanti in \secref{sec:TCPadv_so_linger} come è possibile cambiare
questo comportamento, e cosa deve essere fatto perché il processo possa
Vedremo più avanti in \secref{sec:TCPadv_so_linger} come è possibile cambiare
questo comportamento, e cosa deve essere fatto perché il processo possa
immediatamente il socket \texttt{list\_fd}; mentre il padre continua ad
operare solo sul socket in ascolto chiudendo \texttt{sock\_fd} dopo ciascuna
\texttt{accept}. Per quanto abbiamo detto in \secref{sec:TCPel_func_close}
immediatamente il socket \texttt{list\_fd}; mentre il padre continua ad
operare solo sul socket in ascolto chiudendo \texttt{sock\_fd} dopo ciascuna
\texttt{accept}. Per quanto abbiamo detto in \secref{sec:TCPel_func_close}
numero di riferimenti non si è annullato.
Infatti subito dopo la creazione del socket \texttt{list\_fd} ha una
numero di riferimenti non si è annullato.
Infatti subito dopo la creazione del socket \texttt{list\_fd} ha una
usualmente non chiama \texttt{bind}) per ottenere numero IP e porta locale
associati al socket restituito da una \texttt{connect}, o da un server che ha
chiamato \texttt{bind} su un socket usando 0 come porta locale per ottenere il
usualmente non chiama \texttt{bind}) per ottenere numero IP e porta locale
associati al socket restituito da una \texttt{connect}, o da un server che ha
chiamato \texttt{bind} su un socket usando 0 come porta locale per ottenere il
Inoltre quando un server esegue una \texttt{bind} su un indirizzo generico, se
chiamata dopo il completamento di una connessione sul socket restituito da
Inoltre quando un server esegue una \texttt{bind} su un indirizzo generico, se
chiamata dopo il completamento di una connessione sul socket restituito da