Appunti completi corso Fondamenti di Internet e Reti

NUMERI DI PORTA NOTI

Protocollo Porta Connessione

FTP per trasferimento file 20 TCP

FTP per controllo 21 TCP

SSH 22 TCP

Telnet 23 TCP

SMTP 25 TCP

DNS 53 UDP

DHCP (server) 67 UDP

DHCP (client) 68 UDP

HTTP 80 TCP

POP3 110 TCP

IMAP 143 TCP

HTTPS 443 TCP

MySQL 3306 TCP

Nella lezione precedente abbiamo visto in profondità il livello applicativo, che è quello più

astratto nel modello a strati della rete. Ora vedremo il LIVELLO DI TRASPORTO, che si

occupa della comunicazione tra processi risiedenti su host diversi. Questo livello è

realizzato nei sistemi operativi degli host ed è sopra al livello di rete, che è invece gestito

dai router. I router quindi si occupano dei livelli inferiori (rete, datalink e fisico), ma non del

trasporto e tanto meno dell’applicazione. I pacchetti che viaggiano in questi livello sono

detti SEGMENTI, mentre i pacchetti nel livello di rete saranno chiamati DATAGRAMMI.

Nella trasmissione dei pacchetti ogni livello aggiunge un suo header: il livello di trasporto

quindi aggiunge un certo header che viene poi incapsulato dallo header di rete. I router

dovranno leggere solo lo header dedicato al livello di rete, mentre l’host ricevente andrà a

leggere lo header del livello di trasporto.

Sottolineiamo il fatto che il livello di trasporto fornisce la comunicazione logica tra

PROCESSI che stanno su diversi host, mentre il livello di rete permette la comunicazione

tra HOST diversi. Non è la stessa cosa! Pensiamo a due condomini che stanno in città

diverse i cui residenti si scambiano lettere per comunicare. Il trasporto da un condominio

all'altro è analogo al livello di rete, ma il trasporto da persona a persona è una cosa

diversa. Possiamo vedere le lettere come i pacchetti, le persone come i processi, i

condomini come gli host, i postini sono il livello di trasporto e il sistema postale quello di

rete. È un'ottima analogia perché evidenzia anche che il livello di trasporto sta nei livelli

periferici (negli host), così come i postini si trovano solo nella zona in cui lavorano.

In internet i protocolli di trasporto usati sono TCP e UDP. Il primo è orientato alla

connessione e usa un trasporto affidabile, mentre il secondo è l’esatto contrario. Come

visto nella lezione scorsa, la scelta del protocollo di trasporto la facciamo al momento della

creazione delle socket. È bene anche ricordare che qui useremo sempre il termine

segmento per il trasporto e datagramma per la rete. In alcuni casi viene usato il termine

datagramma per riferirsi ai pacchetti mandati in UDP, ma per chiarezza non faremo questa

distinzione che crea confusione. Il livello di rete sottostante usa un protocollo chiamato IP

che fa del suo meglio per consegnare i pacchetti da un host all'altro, ma NON dà garanzie

di riuscirci! Per questo motivo è considerato un protocollo non affidabile, visto che i

pacchetti possono non arrivare, oppure arrivare in ordine sparso o con i dati non integri.

Ma IP lo studieremo più avanti quando tratteremo il livello di rete, ora ci basta sapere che

ogni host ha un indirizzo IP. A questo protocollo inaffidabile UDP aggiunge solo il

controllo dell'integrità, mentre la garanzia di consegna e dell'ordine sono messi a

disposizione da TCP. Quest’ultimo fornisce anche un meccanismo di controllo della

congestione, per cui cambia dinamicamente la quantità di dati inviati in modo da non

congestionare la rete. Se ne deduce che è ovviamente un protocollo molto complesso.

Il processo di mandare, nel lato mittente, un pacchetto dal socket al livello di trasporto è

detto MULTIPLEXING, mentre l’evento contrario (che avviene nel lato destinatario) è detto

DEMULTIPLEXING. Questa operazione è semplice dato che ogni socket ha un numero

identificativo che è la porta, per cui basta usare questo numero per capire a chi mandare

un pacchetto. Le porte sono numeri da 16 bit, in cui i primi valori da 0 a 1023 sono riservati

per applicazioni specifiche e sono chiamati NUMERI DI PORTA NOTI (per esempio HTTP

lavora sulla porta 80). UDP si basa solo su questo concetto per il dispatching, mentre in

seguito vedremo che le operazioni di mux e demux sono più complesse in TCP.

Nel de/mux non orientato alla connessione, i segmenti contengono una intestazione di 8

byte, nei quali i primi quattro indicano la socket di origine e di destinazione (due byte

ciascuna) e gli ultimi quattro dei valori che vedremo fra pochi paragrafi, poi il contenuto

vero e proprio fornito dal livello applicativo. Il server che riceve il pacchetto, quando

risponderà, semplicemente dovrà scambiare i valori delle socket di origine e destinazione,

e il gioco è fatto.

In UDP ogni socket è identificata da soli due valori: l’indirizzo IP dell’host e il numero di

porta. Se richieste da host diversi (quindi con diverse socket) arrivano ad un server con lo

stesso indirizzo IP e lo stesso numero di porta, esse andranno a finire nella stessa socket

di arrivo. Questa cosa sembra scontata ma non lo è, perché in TCP accade diversamente:

lì ogni socket ha quattro valori: indirizzo IP del client, porta del client, indirizzo IP del server

e porta del server. Sono quattro valori. Quindi in TCP pacchetti provenienti da host diversi

verso una macchina con lo stesso indirizzo IP e porta di destinazione in realtà finiscono su

socket diverse! L'unica eccezione sta nella prima richiesta che è quella necessaria per

instaurare la connessione. C'è questa socket "di benvenuto" che ascolta le richieste di

connessione e le instaura creando la socket appropriata.

UDP quindi è un protocollo di trasporto molto semplice, che fa il minimo essenziale:

trasporta dati da un punto all’altro. Aggiunge poco a quello che esiste già in IP: crea un

segmento con la porta di origine e di destinazione, più due valori extra e il corpo. Poi

passa tutto a IP e ha finito. Uno si chiede a cosa serve questo protocollo se fa così poche

cose. Beh abbiamo visto nella precedente lezione che ci sono situazioni in cui UDP è

preferibile a TCP, come le applicazioni multimediali e la telefonia mobile. Ma anche il DNS

usa UDP, il ché ha senso perché comunque UDP è un protocollo senza connessione,

veloce e senza fronzoli. Il lookup di un URL deve essere altrettanto rapido, altrimenti le

prestazioni di Internet calerebbero notevolmente. Va detto però che anche molte

applicazioni multimediali (in particolare lo streaming video) ora fanno uso di TCP, perché

esso fornisce il controllo della congestione. Siccome lo streaming video è uno dei

contenuti internet più presenti, un uso incontrollato dell’UDP soffocherebbe l’intera rete e i

pacchetti TCP non potrebbero nemmeno viaggiare. Come detto un segmento UDP è molto

semplice: l’intestazione ha quattro campi da due byte ciascuno. I primi due sono le socket

di origine e destinazione, poi c'è la lunghezza del segmento in byte (compresa di

intestazione) e un valore detto CHECKSUM, che serve a fare il controllo di integrità. Il

checksum è un controllo che si basa su principi matematici: in pratica si suddivide il

pacchetto in gruppi di 16 bit che vengono sommati. L’eventuale bit di riporto viene

sommato alla fine e di questo risultato si fa il complemento a 1. Questo è ciò che avviene

nel lato mittente. Nel lato destinatario si prendono i pezzi di 16 bit del pacchetto e li si

sommano tra loro insieme al checksum: se la somma è composta da soli 1 allora il

pacchetto è integro. Se compare almeno uno 0 significa che ci sono stati degli errori di

trasmissione. Arrivati al rilevamento dell’errore però UDP non fa molto altro: può scartare il

pacchetto oppure inviarlo al livello applicativo con un warning.

Ora vogliamo capire come funziona il più complicato protocollo TCP. Per prima cosa

dobbiamo vedere quali sono i principi della trasmissione dati affidabile e lo faremo

aggiungendo passo dopo passo delle difficoltà. Si inizia da una situazione idilliaca in cui

non c’è nessun tipo di errore: noi mandiamo dei pacchetti e quelli sono certi che arrivano a

destinazione, con tutti i bit integri e nello stesso ordine con cui li abbiamo inviati. Iniziamo

ad aggiungere qualche problema nel mezzo: i bit non sono integri. Per controllare la

correttezza dei bit inviati ci servono tre strumenti: un meccanismo di rilevamento

dell’errore, una notifica di ricezione e la ritrasmissione del pacchetto difettoso. Il

rilevamento dell’errore si può fare con una logica simile se non uguale a quella del

checksum, aggiungendo cioè dei dati al pacchetto che il destinatario userà per capire se i

bit ottenuti sono integri. Fatto questo il destinatario deve notificare in qualche modo il

mittente di quello che è successo: può inviare un segnale di ACKNOWLEDGEMENT

(ACK) per segnalare che il pacchetto è arrivato integro, oppure un segnale di NOT

ACKNOWLEDGEMENT (NAK). Trattandosi di un’informazione binaria questo segnale

può essere composto da un solo bit. Se il mittente riceve un NAK allora ritrasmetterà il

pacchetto, se invece riceve un ACK passa al prossimo. Ciò vuol dire che finché il mittente

non riceve una conferma lui non va avanti: deve almeno aspettare un ACK per poter

inviare il pacchetto successivo. Questo tipo di protocollo è chiamato STOP-AND-WAIT.

Ma abbiamo dato per scontato una cosa parecchio grossa: anche il segnale di ACK e NAK

può essere corrotto! E allora come facciamo? Non possiamo mandare altre informazioni,

perché qualsiasi cosa inviamo può essere corrotta. Miglioriamo il protocollo aggiungendo

ad ogni pacchetto inviato un numero di sequenza. Il numero di sequenza viene aggiunto

anche nei messaggi di ACK e NAK. Siccome i pacchetti sono inviati in modo sequenziale

questi numeri di sequenza possono essere semplicemente 0 e 1, per cui noi riceviamo

segnali come ACK0 oppure NAK1. In questo modo, facendo un po’ di ragionamenti sul bit

di sequenza, possiamo capire sia lato mittente che lato destinatario se un pacchetto è

stato inviato correttamente o meno (e si può pure abolire il NAK, tenendo solo un ACK).

Ora complichiamo le cose aggiungendo il caso dei pacchetti perduti. Per pacchetto

perduto si possono intendere molte situazioni: il pacchetto non è arrivato al destinatario,

oppure è arrivato ma il suo segnale di ACK è andato perso. O peggio ancora il pacchetto è

sano e salvo e sta arrivando, ma ci sta mettendo troppo tempo. Se noi stiamo aspettando

a lungo e non arriva nessuna risposta, non è detto per forza che il pacchetto sia andato

perduto… Ma l’unica scelta che abbiamo è considerare un intervallo di tempo oltre il quale

il pacc