X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=tcpsock.tex;h=a976ecdc9b9e921b710555d94fc204056ccf9c15;hp=355593755aec47bc9f7e4c3acbcdbe0d72bee29e;hb=ff76d56c6a2c280cbe4f153173488871d7b12336;hpb=3925d42aafd1c1ac743c2f0a748981c26335915d diff --git a/tcpsock.tex b/tcpsock.tex index 3555937..a976ecd 100644 --- a/tcpsock.tex +++ b/tcpsock.tex @@ -1,6 +1,6 @@ %% tcpsock.tex %% -%% Copyright (C) 2000-2006 Simone Piccardi. Permission is granted to +%% Copyright (C) 2000-2007 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", @@ -8,6 +8,7 @@ %% license is included in the section entitled "GNU Free Documentation %% License". %% + \chapter{I socket TCP} \label{cha:TCP_socket} @@ -125,10 +126,14 @@ varr \subsection{Le opzioni TCP.} \label{sec:TCP_TCP_opt} -Ciascun segmento SYN contiene in genere delle opzioni per il protocollo TCP -(le cosiddette \textit{TCP options}, che vengono inserite fra l'header e i -dati) che servono a comunicare all'altro capo una serie di parametri utili a -regolare la connessione. Normalmente vengono usate le seguenti opzioni: +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 +connessione. Normalmente vengono usate le seguenti opzioni: \begin{itemize} \item \textit{MSS option}, dove MMS sta per \itindex{Maximum~Segment~Size} @@ -136,28 +141,37 @@ regolare la connessione. Normalmente vengono usate le seguenti opzioni: connessione annuncia all'altro il massimo ammontare di dati che vorrebbe accettare per ciascun segmento nella connessione corrente. È possibile leggere e scrivere questo valore attraverso l'opzione del socket - \const{TCP\_MAXSEG}. + \const{TCP\_MAXSEG} (vedi sez.~\ref{sec:sock_tcp_udp_options}). -\item \textit{window scale - option}, %come spiegato in sez.~\ref{sec: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'header, che così può - indicare un massimo di 65535 byte;\footnote{ Linux usa come 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 (espresso come numero di bit cui spostare a sinistra il valore - della finestra annunciata inserito nel pacchetto). +\item \textit{window scale option}, il protocollo TCP implementa il controllo + di flusso attraverso una \itindex{advertised~window} \textit{advertised + window} (la ``\textsl{finestra annunciata}'', vedi + sez.~\ref{sec:tcp_protocol_xxx}) 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{Linux usa come 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 + \itindex{advertised~window} 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 (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 negozioare 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{sysct} (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 @@ -291,10 +305,10 @@ 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 -\itindex{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). +La connessione viene iniziata dal client che annuncia una +\itindex{Maximum~Segment~Size} 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). Una volta che la connessione è stabilita il client scrive al server una richiesta (che assumiamo stare in un singolo segmento, cioè essere minore dei @@ -720,9 +734,9 @@ Si noti che si \const{INADDR\_ANY}, anche se, essendo questo nullo, il riordinamento è inutile. Si tenga presente comunque che tutte le costanti \val{INADDR\_} (riportate in tab.~\ref{tab:TCP_ipv4_addr}) sono definite secondo -l'\textit{endianess}\itindex{endianess} della macchina, ed anche se -esse possono essere invarianti rispetto all'ordinamento dei bit, è comunque -buona norma usare sempre la funzione \func{htonl}. +\itindex{endianess} l'\textit{endianess} della macchina, ed anche se esse +possono essere invarianti rispetto all'ordinamento dei bit, è comunque buona +norma usare sempre la funzione \func{htonl}. \begin{table}[htb] \centering @@ -759,7 +773,6 @@ indicare l'indirizzo di \textit{loopback}, che a sua volta viene inizializzata staticamente a \const{IN6ADRR\_LOOPBACK\_INIT}. - \subsection{La funzione \func{connect}} \label{sec:TCP_func_connect} @@ -770,7 +783,7 @@ connessione con un server TCP,\footnote{di nuovo la funzione limiterà ad impostare l'indirizzo dal quale e verso il quale saranno inviati e ricevuti i pacchetti, mentre per socket di tipo \const{SOCK\_STREAM} o \const{SOCK\_SEQPACKET}, essa attiverà la procedura di avvio (nel caso del - TCP il \itindex{three~way~handshake}\textit{three way handshake}) della + TCP il \itindex{three~way~handshake} \textit{three way handshake}) della connessione.} il prototipo della funzione è il seguente: \begin{prototype}{sys/socket.h} {int connect(int sockfd, const struct sockaddr *servaddr, socklen\_t @@ -815,22 +828,25 @@ nell'esempio sez.~\ref{sec:TCP_daytime_client}, usando le funzioni illustrate in sez.~\ref{sec:sock_addr_func}. Nel caso di socket TCP la funzione \func{connect} avvia il -\itindex{three~way~handshake}\textit{three way handshake}, e ritorna -solo quando la connessione è stabilita o si è verificato un errore. Le -possibili cause di errore sono molteplici (ed i relativi codici riportati -sopra), quelle che però dipendono dalla situazione della rete e non da errori -o problemi nella chiamata della funzione sono le seguenti: +\itindex{three~way~handshake} \textit{three way handshake}, e ritorna solo +quando la connessione è stabilita o si è verificato un errore. Le possibili +cause di errore sono molteplici (ed i relativi codici riportati sopra), quelle +che però dipendono dalla situazione della rete e non da errori o problemi +nella chiamata della funzione sono le seguenti: \begin{enumerate} \item Il client non riceve risposta al SYN: l'errore restituito è - \errcode{ETIMEDOUT}. Stevens riporta che BSD invia un primo SYN alla chiamata - di \func{connect}, un altro dopo 6 secondi, un terzo dopo 24 secondi, se - dopo 75 secondi non ha ricevuto risposta viene ritornato l'errore. Linux - invece ripete l'emissione del SYN ad intervalli di 30 secondi per un numero - di volte che può essere stabilito dall'utente sia con una opportuna - \func{sysctl} che attraverso il filesystem \file{/proc} scrivendo il valore - voluto in \file{/proc/sys/net/ipv4/tcp\_syn\_retries}. Il valore predefinito - per la ripetizione dell'invio è di 5 volte, che comporta un timeout dopo - circa 180 secondi. + \errcode{ETIMEDOUT}. Stevens riporta che BSD invia un primo SYN alla + chiamata di \func{connect}, un altro dopo 6 secondi, un terzo dopo 24 + secondi, se dopo 75 secondi non ha ricevuto risposta viene ritornato + l'errore. Linux invece ripete l'emissione del SYN ad intervalli di 30 + secondi per un numero di volte che può essere stabilito dall'utente. Questo + può essere fatto a livello globale con una opportuna + \func{sysctl},\footnote{o più semplicemente scrivendo il valore voluto in + \file{/proc/sys/net/ipv4/tcp\_syn\_retries}, vedi + sez.~\ref{sec:sock_ipv4_sysctl}.} e a livello di singolo socket con + l'opzione \const{TCP\_SYNCNT} (vedi sez.~\ref{sec:sock_tcp_udp_options}). Il + valore predefinito per la ripetizione dell'invio è di 5 volte, che comporta + un timeout dopo circa 180 secondi. \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 @@ -910,11 +926,11 @@ con cui il kernel tratta le connessioni in arrivo. Per ogni socket in ascolto infatti vengono mantenute due code: \begin{enumerate} \item La coda delle connessioni incomplete (\textit{incomplete connection - queue} che contiene un riferimento per ciascun socket per il quale è - arrivato un SYN ma il \itindex{three~way~handshake}\textit{three way + queue}) che contiene un riferimento per ciascun socket per il quale è + arrivato un SYN ma il \itindex{three~way~handshake} \textit{three way handshake} non si è ancora concluso. Questi socket sono tutti nello stato \texttt{SYN\_RECV}. -\item La coda delle connessioni complete (\textit{complete connection queue} +\item La coda delle connessioni complete (\textit{complete connection queue}) che contiene un ingresso per ciascun socket per il quale il \itindex{three~way~handshake} \textit{three way handshake} è stato completato ma ancora \func{accept} non è ritornata. Questi socket sono @@ -2026,7 +2042,7 @@ esaminato in sez.~\ref{sec:proc_termination}). In questo caso avremo l'invio del segnale \const{SIGCHLD} al padre, ma dato che non si è installato un gestore e che l'azione predefinita per questo segnale è quella di essere ignorato, non avendo predisposto la ricezione dello stato di terminazione, -otterremo che il processo figlio entrerà nello stato di zombie\index{zombie} +otterremo che il processo figlio entrerà nello stato di \index{zombie} zombie (si riveda quanto illustrato in sez.~\ref{sec:sig_sigchld}), come risulterà ripetendo il comando \cmd{ps}: \begin{verbatim} @@ -2034,7 +2050,7 @@ ripetendo il comando \cmd{ps}: 2359 pts/0 Z 0:00 [echod ] \end{verbatim} -Dato che non è il caso di lasciare processi zombie\index{zombie}, occorrerà +Dato che non è il caso di lasciare processi \index{zombie} zombie, occorrerà ricevere opportunamente lo stato di terminazione del processo (si veda sez.~\ref{sec:proc_wait}), cosa che faremo utilizzando \const{SIGCHLD} secondo quanto illustrato in sez.~\ref{sec:sig_sigchld}. Una prima modifica al nostro @@ -2387,22 +2403,22 @@ si aveva il SYN flag attivo. Si noti come a partire dal secondo pacchetto sia sempre attivo il campo \texttt{ack}, seguito dal numero di sequenza per il quale si da il ricevuto; quest'ultimo, a partire dal terzo pacchetto, viene espresso in forma relativa per maggiore compattezza. Il campo \texttt{win} in -ogni riga indica la \textit{advertising window} di cui parlavamo in -sez.~\ref{sec:TCP_TCP_opt}. Allora si può verificare dall'output del comando -come venga appunto realizzata la sequenza di pacchetti descritta in -sez.~\ref{sec:TCP_conn_cre}: prima viene inviato dal client un primo pacchetto -con il SYN che inizia la connessione, a cui il server risponde dando il -ricevuto con un secondo pacchetto, che a sua volta porta un SYN, cui il client -risponde con un il terzo pacchetto di ricevuto. +ogni riga indica la \itindex{advertised~window} \textit{advertised window} di +cui parlavamo in sez.~\ref{sec:TCP_TCP_opt}. Allora si può verificare +dall'output del comando come venga appunto realizzata la sequenza di pacchetti +descritta in sez.~\ref{sec:TCP_conn_cre}: prima viene inviato dal client un +primo pacchetto con il SYN che inizia la connessione, a cui il server risponde +dando il ricevuto con un secondo pacchetto, che a sua volta porta un SYN, cui +il client risponde con un il terzo pacchetto di ricevuto. Ritorniamo allora alla nostra sessione con il servizio echo: dopo le tre righe -del \textit{three way handshake} \itindex{three~way~handshake} non avremo nulla -fin tanto che non scriveremo una prima riga sul client; al momento in cui -facciamo questo si genera una sequenza di altri quattro pacchetti. Il primo, -dal client al server, contraddistinto da una lettera \texttt{P} che significa -che il flag PSH è impostato, contiene la nostra riga (che è appunto di 11 -caratteri), e ad esso il server risponde immediatamente con un pacchetto vuoto -di ricevuto. Poi tocca al server riscrivere indietro quanto gli è stato +del \itindex{three~way~handshake} \textit{three way handshake} non avremo +nulla fin tanto che non scriveremo una prima riga sul client; al momento in +cui facciamo questo si genera una sequenza di altri quattro pacchetti. Il +primo, dal client al server, contraddistinto da una lettera \texttt{P} che +significa che il flag PSH è impostato, contiene la nostra riga (che è appunto +di 11 caratteri), e ad esso il server risponde immediatamente con un pacchetto +vuoto di ricevuto. Poi tocca al server riscrivere indietro quanto gli è stato inviato, per cui sarà lui a mandare indietro un terzo pacchetto con lo stesso contenuto appena ricevuto, e a sua volta riceverà dal client un ACK nel quarto pacchetto. Questo causerà la ricezione dell'eco nel client che lo stamperà a @@ -2607,9 +2623,9 @@ Il risultato finale qui dipende dall'implementazione dello stack TCP, e nel caso di Linux anche dall'impostazione di alcuni dei parametri di sistema che si trovano in \file{/proc/sys/net/ipv4}, che ne controllano il comportamento: in questo caso in particolare da \file{tcp\_retries2} (vedi -sez.~\ref{sec:sock_sysctl}). Questo parametro infatti specifica il numero di -volte che deve essere ritentata la ritrasmissione di un pacchetto nel mezzo di -una connessione prima di riportare un errore di timeout. Il valore +sez.~\ref{sec:sock_ipv4_sysctl}). Questo parametro infatti specifica il numero +di volte che deve essere ritentata la ritrasmissione di un pacchetto nel mezzo +di una connessione prima di riportare un errore di timeout. Il valore preimpostato è pari a 15, il che comporterebbe 15 tentativi di ritrasmissione, ma nel nostro caso le cose sono andate diversamente, dato che le ritrasmissioni registrate da \cmd{tcpdump} sono solo 8; inoltre l'errore @@ -2844,7 +2860,7 @@ niente fintanto che non pu possono utilizzare questi valori per far si che \func{select} ritorni solo quando c'è la certezza di avere dati a sufficienza.\footnote{questo tipo di controllo è utile di norma solo per la lettura, in quanto in genere le - operazioni di scrittura sono già controllate dall'applicazione, che sà + operazioni di scrittura sono già controllate dall'applicazione, che sa sempre quanti dati invia, mentre non è detto possa conoscere la quantità di dati in ricezione; per cui, nella situazione in cui si conosce almeno un valore minimo, per evitare la penalizzazione dovuta alla ripetizione delle @@ -3200,8 +3216,8 @@ precedente versione causava l'immediato ritorno della funzione; in questo caso prima (\texttt{\small 19}) si imposta opportunamente \var{eof} ad un valore non nullo, dopo di che (\texttt{\small 20}) si effettua la chiusura del lato in scrittura del socket con \func{shutdown}. Infine (\texttt{\small 21}) si -usa la macro \macro{FD\_CLR} per togliere lo standard input dal file -descriptor set. \itindex{file~descriptor~set} +usa la macro \macro{FD\_CLR} per togliere lo standard input dal +\itindex{file~descriptor~set} \textit{file descriptor set}. In questo modo anche se la lettura del file in ingresso è conclusa, la funzione non esce dal ciclo principale (\texttt{\small 11--50}), ma continua @@ -3341,13 +3357,13 @@ vi sono dati sui socket connessi, per questo si ripete un ciclo diverso da zero; in questo modo se l'unico socket con attività era quello connesso, avendo opportunamente decrementato il contatore, il ciclo verrà saltato, e si ritornerà immediatamente (ripetuta l'inizializzazione del -\itindex{file~descriptor~set} file descriptor set con i nuovi valori nella -tabella) alla chiamata di \func{accept}. Se il socket attivo non è quello in -ascolto, o ce ne sono comunque anche altri, il valore di \var{n} non sarà -nullo ed il controllo sarà eseguito. Prima di entrare nel ciclo comunque si -inizializza (\texttt{\small 28}) il valore della variabile \var{i} che useremo -come indice nella tabella \var{fd\_open} al valore minimo, corrispondente al -file descriptor del socket in ascolto. +\itindex{file~descriptor~set} \textit{file descriptor set} con i nuovi valori +nella tabella) alla chiamata di \func{accept}. Se il socket attivo non è +quello in ascolto, o ce ne sono comunque anche altri, il valore di \var{n} non +sarà nullo ed il controllo sarà eseguito. Prima di entrare nel ciclo comunque +si inizializza (\texttt{\small 28}) il valore della variabile \var{i} che +useremo come indice nella tabella \var{fd\_open} al valore minimo, +corrispondente al file descriptor del socket in ascolto. Il primo passo (\texttt{\small 30}) nella verifica è incrementare il valore dell'indice \var{i} per posizionarsi sul primo valore possibile per un file @@ -3393,17 +3409,18 @@ successiva \func{select} ritorner disponibilità. Il nostro server comunque soffre di una vulnerabilità per un attacco di tipo -\textit{Denial of Service}. Il problema è che in caso di blocco di una -qualunque delle funzioni di I/O, non avendo usato processi separati, tutto il -server si ferma e non risponde più a nessuna richiesta. Abbiamo scongiurato -questa evenienza per l'I/O in ingresso con l'uso di \func{select}, ma non vale -altrettanto per l'I/O in uscita. Il problema pertanto può sorgere qualora una -delle chiamate a \func{write} effettuate da \func{FullWrite} si blocchi. Con -il funzionamento normale questo non accade in quanto il server si limita a -scrivere quanto riceve in ingresso, ma qualora venga utilizzato un client -malevolo che esegua solo scritture e non legga mai indietro l'\textsl{eco} del -server, si potrebbe giungere alla saturazione del buffer di scrittura, ed al -conseguente blocco del server su di una \func{write}. +\itindex{Denial~of~Service~(DoS)} \textit{Denial of Service}. Il problema è +che in caso di blocco di una qualunque delle funzioni di I/O, non avendo usato +processi separati, tutto il server si ferma e non risponde più a nessuna +richiesta. Abbiamo scongiurato questa evenienza per l'I/O in ingresso con +l'uso di \func{select}, ma non vale altrettanto per l'I/O in uscita. Il +problema pertanto può sorgere qualora una delle chiamate a \func{write} +effettuate da \func{FullWrite} si blocchi. Con il funzionamento normale questo +non accade in quanto il server si limita a scrivere quanto riceve in ingresso, +ma qualora venga utilizzato un client malevolo che esegua solo scritture e non +legga mai indietro l'\textsl{eco} del server, si potrebbe giungere alla +saturazione del buffer di scrittura, ed al conseguente blocco del server su di +una \func{write}. Le possibili soluzioni in questo caso sono quelle di ritornare ad eseguire il ciclo di risposta alle richieste all'interno di processi separati, utilizzare @@ -3559,9 +3576,10 @@ uscita e notifica in caso si errore (\texttt{\small 49--52}). Come si può notare la logica del programma è identica a quella vista in fig.~\ref{fig:TCP_SelectEchod} per l'analogo server basato su \func{select}; la sola differenza significativa è che in questo caso non c'è bisogno di -rigenerare i \itindex{file~descriptor~set} file descriptor set in quanto -l'uscita è indipendente dai dati in ingresso. Si applicano comunque anche a -questo server le considerazioni finali di sez.~\ref{sec:TCP_serv_select}. +rigenerare i \itindex{file~descriptor~set} \textit{file descriptor set} in +quanto l'uscita è indipendente dai dati in ingresso. Si applicano comunque +anche a questo server le considerazioni finali di +sez.~\ref{sec:TCP_serv_select}. % LocalWords: socket TCP client dell'I multiplexing stream three way handshake @@ -3602,7 +3620,7 @@ questo server le considerazioni finali di sez.~\ref{sec:TCP_serv_select}. % LocalWords: SNDLOWAT third fset maxfd fileno ISSET closed how SHUT RD WR eof % LocalWords: RDWR fifo Trip ping fourth CLR sull'I SETSIZE nread break Denial % LocalWords: Service poll POLLIN POLLRDNORM POLLPRI POLLRDBAND POLLOUT events -% LocalWords: POLLHUP POLLERR revents pollfd +% LocalWords: POLLHUP POLLERR revents pollfd Di %%% Local Variables: %%% mode: latex