Appunti di Reti di Calcolatori
Lo scopo di questi brevi appunti è cercare di offrire – agli studenti del corso di “Reti di Calcolatori” – una sintetica visione d’insieme delle relazioni tra i diversi livelli del software di rete, prendendo come esempio la visualizzazione di una pagina Web.
Supponiamo che un utente usi un browser per visualizzare il contenuto di una URL, ad esempio della URL http://131.114.3.18/phd/corsi.htm. L’utente chiederà al browser di visualizzare il contenuto della URL utilizzando l’interfaccia offerta dal browser, digitando la URL in oggetto (oppure cliccando sul relativo hyperlink se presente nella pagina correntemente visualizzata).
1. Lo scambio di messaggi HTTP
Per soddisfare la richiesta dell’utente, il browser dovrà inviare al server 131.114.3.18 una richiesta HTTP per chiedere che gli sia inviato il file /phd/corsi.htm. Supponiamo per semplicità che il browser non abbia la possibilità di accedere a una copia “cached” di tale file (né in locale né attraverso un server proxy) e che il server possieda il file richiesto. La richiesta del browser consisterà di un unico messaggio HTTP destinato al server in oggetto, come indicato nella Figura 1.
Figura 1. Richiesta HTTP.
Quando il server 131.114.3.18 riceverà la suddetta richiesta, esso risponderà al cliente con un opportuno messaggio di risposta HTTP, come schematizzato nella Figura 2.
Figura 2. Risposta HTTP.
2. Interazione tra il livello applicazione e il servizio TCP
In realtà il browser, per poter inviare una richiesta HTTP al server 131.114.3.18, dovrà prima (cercare di) stabilire una connessione TCP con tale server. Per fare questo, il browser dovrà invocare una primitiva offerta dall’API (Application Program Interface) del servizio TCP.
Server Browser GET /phd/corsi.htm HTTP
Browser
HTTP/1.1 200 OK ... <HTML> ...
... ... </HTML>
Server HTTP
* Prima versione (dicembre 2006). Inviare segnalazioni di errori e/o commenti diettamente a brogi@di.unipi.it.
Ad esempio, se il browser è scritto in Java esso potrà utilizzare la classe Socket.java, cercando di creare un nuovo oggetto di tipo Socket per stabilire una connessione TCP col processo in ascolto sulla porta 80 del server 131.114.3.18:
... Socket c = new Socket("131.114.3.18", 80); PrintStream w = new PrintStream(c.getOutputStream()); w.println("GET /phd/corsi.htm"); ...
Una volta invocato il costruttore Socket, il processo Java si sospenderà in attesa che venga creato un oggetto (c) di tipo Socket (oppure che venga sollevata un’eccezione). Se il servizio TCP riuscirà a stabilire una connessione col server specificato, verrà creato l’oggetto di tipo Socket e il browser potrà utilizzare (l’ OutputStream di) tale oggetto per inviare il suo messaggio HTTP di richiesta. Una volta inviata la richiesta HTTP, il browser riceverà quindi la risposta dal server leggendo dall’InputStream del Socket.
3. Lo scambio di segmenti TCP
Il servizio TCP presente sull’host del browser deve ovviamente preoccuparsi di soddisfare le richieste provenienti dal livello applicazione. Ad esempio, quando il browser invoca la primitiva
new Socket("131.114.3.18", 80)
il servizio TCP dovrà cercare di stabilire una connessione con il processo in esecuzione sul server con indirizzo IP 131.114.3.18 in attesa di ricevere richieste di connessioni sulla porta 80.
Per stabilire tale connessione, il servizio TCP dell’host invierà un segmento di tipo “syn” al servizio TCP del server indicato, specificando il proprio numero di sequenza iniziale (scelto in modo casuale). Il servizio TCP del server risponderà a tale segmento inviando un segmento di tipo “syn+ack”, con cui riscontrerà il segmento ricevuto e indicherà il proprio numero di sequenza iniziale. Questa fase di “handshake” si concluderà con l’invio di un segmento di riscontro da parte del servizio TCP dell’host.
Graficamente, utilizzando la notazione proposta nella RFC 7931 e supponendo che i processi TCP scelgano rispettivamente come numero di sequenza iniziale 100 e 200, i segmenti scambiati dai processi TCP a seguito della richiesta di creazione del Socket saranno quindi quelli schematizzati nella Figura 3.
new Socket("131.114.3.18",80)
<SEQ=100> <CTL=SYN>
<SEQ=200> <ACK=101> <CTL=SYN,ACK>
<SEQ=101> <ACK=201> <CTL=ACK>
Browser
TCP
Server HTTP
TCP
Figura 3. Handshake TCP.
1 Nella notazione proposta nella RFC 793 il contenuto dei segmenti è mostrato sintetizzando numero di sequenza, campo ACK e flag di controllo.
2
Ricordiamo che i primi 32 bit di ogni segmento TCP sono utilizzati per rappresentare i numeri delle porte dei processi mittente e destinatario. Ad esempio, se al browser verrà assegnata la porta 8200, i primi bit del primo segmento TCP inviato dal server all’host saranno quelli indicati nella Figura 4.
Figura 4. Preambolo del primo segmento TCP inviato dal server.
4. Interazione tra il livello trasporto e il servizio IP
Il servizio TCP per inviare/ricevere segmenti a/da un suo pari utlizzerà il servizio IP del sottostante livello di rete. Per esempio, per inviare un segmento, TCP utilizzerà la primitiva che IP offre (nell’interfaccia prevista per il sistema operativo dell’host) per permettere l’invio di dati a un indirizzo IP. Supponiamo ad esempio che l’interfaccia di IP presente sull’host del browser offra la primitiva2
result IPsend(Inetdddress destinationIP, int protocol, byte[] data).
Quando il browser cercherà di stabilire una connessione TCP eseguendo il comando
new Socket("131.114.3.18", 80) il servizio TCP in esecuzione sull’host del browser preparerà un array d di byte contenente un segmento
TCP di tipo “syn”, lo invierà quindi al suo pari invocando la primitiva IP
IPsend ("131.114.3.18", 6, d) e quindi si metterà in attesa di ricevere (invocando opportunamente una primitiva IPreceive) un segmento
di risposta dal suo pari in esecuzione sul server HTTP.
5. Lo scambio di pacchetti IP
Il servizio IP presente sull’host del browser deve ovviamente preoccuparsi di soddisfare le richieste provenienti dai livelli superiori. Ad esempio, quando TCP invoca la primitiva
IPsend("131.114.3.18", 6, d)
il servizio IP controlla la validità dei parametri attuali, prepara il datagram IP e lo invia al suo pari in esecuzione sul server. Il contenuto del primo datagram inviato al server è schematizzato nella Figura 5, dove a titolo illustrativo sono evidenziati il valore del campo Protocol, l’indirizzo IP del destinatario contenuti nel preambolo e i primi 64 bit del segmento TCP trasportato come payload.
2 Utilizziamo per semplicità una sintassi Java-like per descrivere la primitiva send offerta da IP; per una definizione più completa si consulti la RFC 791.
numero porta sorgente
00000000010100000010000000001000
00000000000000000000000011001000 00000000000000000000000001100101 ...
...
numero porta destinazione
numero di sequenza
numero di riscontro
3
Server Browser HTTP
TCP TCP
IP
new Socket("131.114.3.18",80)
IPsend("131.114.3.18",6,d)
IP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | 6 | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 131.114.3.18 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 00100000000010000000000001010000 | | 00000000000000000000000001100100 | | ................................ | | ................................ | | ................................ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 5. Primo datagram IP inviato al server.
6. Interazione tra il livello di rete e il servizio datalink
Il servizio IP per inviare/ricevere datagram dovrà utilizzare il servizio offerto dal sottostante livello di collegamento. Quest’ultimo permetterà di inviare datagram ad un host direttamente collegato all’host su cui è in esecuzione il servizio IP in questione.
Ad esempio, per trasmettere il pacchetto IP indicato nella Figura 5, l’host su cui è in esecuzione il browser determinerà l’indirizzo IP dell’interfaccia R del router a cui deve inoltrare il pacchetto IP destinato al server 131.114.3.18, utilizzerà quindi ARP per determinare l’indirizzo MAC dell’interfaccia R del router e infine invierà il frame creato all’indirizzo MAC di R, come schematizzato nella Figura 6.
4
Browser
TCP
IP
DL
Server HTTP
TCP
IP
DL
Server S
DL
F
Host H Router
Figura 6. Trasmissione di un frame dall’host del browser al router.
Nella Figura 7 vengono evidenziati i campi relativi all’indirizzamento dei preamboli contenuti nel frame F della Figura 6.
Figura 7. Alcuni campi dei preamboli contenuti del frame F della Figura 6.
7. Conclusione
Ovviamente la precedente descrizione non fornisce (volutamente) una spiegazione completa di tutto ciò che avviene dal momento in cui un utente richiede al proprio browser di visualizzare una pagina Web al momento in cui la pagina viene effettivamente visualizzata sul monitor dell’utente.
Un utile esercizio è cercare di capire come completare la precedente descrizione, per esempio esplicitando il modo in cui i livelli di rete e datalink interagiscono (Figura 6), determinando tutti i datagram trasmessi, analizzando ciò che avviene sul server o considerando la possibile perdita di pacchetti.
SRC: INDIRIZZO MAC DI H DEST: INDIRIZZO MAC DI R ...
... SRC: INDIRIZZO IP DI H DEST: INDIRIZZO IP DI S ... ... SRC: PORTA TCP DI H DEST: PORTA TCP DI S ...
preambolo DL
preambolo IP
preambolo TCP preambolo HTTP
5
Nessun commento:
Posta un commento