Livello trasporto. Servizi del livello trasporto

Transcript

1 ivello trasporto Servizi Multiplexing e demultiplexing Trasporto senza connessione: UDP Principi di trasferimento affidabile Trasporto orientato alla connessione: TCP Struttura del segmento Trasferimento dati affidabile Gestione della connessione Controllo del flusso Controllo della congestione Servizi del livello trasporto fornisce comunicazione logica tra processi su host diversi i protocolli di trasporto sono solo sugli end-system: il mittente suddivide il messaggio applicativo in segmenti e li passa a livello rete il ricevente riassembla i segmenti in messaggi e li passa a livello applicazione application transport data link data link data link data link data link data link application transport data link 1

2 ivello trasporto app app TCP/UDP IP IP IP Ethernet TCP/UDP IP Ethernet Host Router Host ivello trasporto/livello rete Il livello rete: comunicazione logica tra host implementato nella sottorete di comunicazione servizio inaffidabile Il livello trasporto: comunicazione logica tra processi mette a disposizione funzioni per i programmi applicativi gestisce il multiplexing/demultiplexing del traffico di rete tra le varie applicazioni offre servizio connection-oriented (affidabile) o connectionless (non affidabile) 2

3 ivello trasporto Protocollo UDP (User Datagram Protocol): servizio inaffidabile (estensione del servizio offerto da IP) Protocollo TCP (Transmission Control Protocol): servizio affidabile, orientato alla connessione Servizi non disponibili: garanzia di banda e di ritardo Segmento: PDU di livello trasporto Segmento H H IP H TCP App, e.g., HTTP Datagramma Frame Multiplexing/demultiplexing Multiplexing nel nodo mittente: gestisce dati provenienti da più socket e aggiunge intestazione (per demultiplexing) Demultiplexing nel nodo ricevente: usa intestazione per consegnare i pacchetti ricevuti alla porta corretta 3

4 Demultiplexing I datagrammi ricevuti contengono: indirizzo IP sorgente e destinazione un segmento di livello trasporto Ogni segmento contiene numeri di porta sorgente e destinazione Indirizzi IP e numeri di porta sono usati per consegnare i segmenti al socket corretto I numeri di porta variano da 0 a (16 bit). I numeri di porta da 0 a 1023 sono riservati (well-known port numbers) Formato segmento TCP/UDP porta sorgente 32 bits porta destinazione altri campi intestazione payload (messaggio applicativo) Porte well-known 4

5 Multiplexing/demultiplexing UDP clientsocket = socket(af_inet, SOCK_DGRAM) Client Viene creato un socket UDP assegnando un numero di porta Il livello trasporto crea un segmento contenente nell intestazione i numeri di porta sorgente e destinazione Il segmento viene passato al livello rete, che incapsula il segmento in un datagramma contenente IP sorgente e destinazione. Server Il livello trasporto esamina il numero di porta destinazione e consegna il segmento al socket associato Datagrammi con stessa porta destinazione ma diversi IP e/o porta sorgente sono diretti allo stesso socket Demultiplexing UDP: esempio clientsocket.bind((, 9157)) serversocket.bind(, 6428); clientsocket.bind(,5775); application P3 transport link application P1 transport link application P4 transport link source port: 6428 dest port: 9157 source port:? dest port:? source port: 9157 dest port: 6428 source port:? dest port:? 5

6 Multiplexing/demultiplexing TCP Il client crea un socket TCP e il processo server crea un socket di connessione Un socket TCP è identificato da quattro valori: indirizzo IP sorgente numero di porta sorgente indirizzo IP destinazione porta destinazione Il ricevente usa i quattro valori per demultiplare il segmento verso il socket corretto Demultiplexing TCP: esempio application P3 transport link P4 application P5 transport link P6 server: IP address B application P2 transport link P3 host: IP address A source IP,port: B,80 dest IP,port: A,9157 source IP,port: A,9157 dest IP, port: B,80 Three segments, all destined to IP address: B, dest port: 80 are demultiplexed to different sockets source IP,port: C,5775 dest IP,port: B,80 source IP,port: C,9157 dest IP,port: B,80 host: IP address C 6

7 UDP (RFC 768) Senza connessione: non c è fase di inizializzazione ogni segmento UDP è gestito indipendentemente dagli altri Servizio best effort, i pacchetti possono: giungere a destinazione non ordinati non giungere a destinazione Servizi: multiplexing/demultiplexing controllo errore Perchè usare UDP? Non introduce ritardo per fase di inizializzazione Semplice: non ci sono informazioni di stato della connessione Basso overhead di intestazione nel segmento No controllo della congestione: le applicazioni possono inviare alla velocità desiderata (rischioso per la rete) Usato per applicazioni multimediali, tolleranti alle perdite di pacchetti e sensibili alla banda Affidabilità e controllo congestione implementabili a livello applicativo 7

8 Segmento UDP unghezza in byte del segmento UDP, compresa intestazione porta sorgente 32 bits porta destinazione lunghezza checksum Checksum (opzionale) usato da destinatario per rilevare errori nel segmento payload (messaggio applicativo) Checksum di UDP Complemento a 1 della somma di segmento UDP e pseudoheader IP: indirizzi IP sorgente e destinazione, protocollo, lunghezza UDP (RFC768) Il destinatario ricalcola il checksum In caso di errori, il segmento viene scartato oppure passato all applicazione con avviso di errore 8

9 Principi di trasferimento affidabile Il livello rete è inaffidabile: Presenza di errori Perdita e duplicazione di pacchetti Ordine dei pacchetti non garantito In caso di errori è necessario: Rilevare e/o identificare gli errori Correggere gli errori oppure notificare al mittente Chiedere la ritrasmissione Tutto questo considerando le risorse di rete e le risorse del destinatario Principi di trasferimento affidabile 9

10 Principi di trasferimento affidabile e caratteristiche del canale inaffidabile determinano la complessità del protocollo di trasferimento affidabile (rdt: reliable data transfer, udt: unreliable data transfer) Trasferimento affidabile rdt_send(): chiamata dall alto (e.g., app.). I dati vengono passati per la consegna al livello alto ricevente deliver_data(): consegna di dati al livello superiore send side receive side udt_send(): chiamata da rdt, per trasferire pacchetti su un canale inaffidabile rdt_rcv(): i pacchetti arrivano su lato ricevente del canale 10

11 Macchine a stati finiti (FSM) Stato iniziale Evento che causa la transizione di stato Azione conseguente stato 1 evento azione stato 2 o stato successivo è determinato dal prossimo evento rdt1.0: trasferimento affidabile su canale affidabile Canale sottostante affidabile no errori sui bit no perdita di pacchetti FSM per sender e receiver: sender invia dati al canale sottostante receiver legge dati dal canale sottostante call from packet = make_pkt(data) udt_send(packet) call from rdt_rcv(packet) extract (packet,data) sender receiver 11

12 rdt2.0: canale con errori sui bit Meccanismi: o riconoscimento errori (checksum) o feedback: messaggi di controllo (ACK,NAK) dal receiver al sender acknowledgements (ACK): il receiver conferma la ricezione corretta del pacchetto negative acknowledgements (NAK): il receiver conferma la ricezione del pacchetto con errori o Ritrasmissione del pacchetto al ricevimento di NAK rdt2.0: FSM sndpkt = make_pkt(data, checksum) call from isack(rcvpkt) sender ACK or NAK isnak(rcvpkt) receiver corrupt(rcvpkt) udt_send(nak) call from notcorrupt(rcvpkt) extract(rcvpkt,data) udt_send(ack) 12

13 rdt2.0: scenario senza errori sndpkt = make_pkt(data, checksum) call from isack(rcvpkt) ACK or NAK isnak(rcvpkt) corrupt(rcvpkt) udt_send(nak) call from notcorrupt(rcvpkt) extract(rcvpkt,data) udt_send(ack) rdt2.0: scenario con errori snkpkt = make_pkt(data, checksum) call from isack(rcvpkt) ACK or NAK isnak(rcvpkt) corrupt(rcvpkt) udt_send(nak) call from notcorrupt(rcvpkt) extract(rcvpkt,data) udt_send(ack) 13

14 Protocolli ARQ Protocolli di tipo ARQ (Automatic Repeat request) basati su riscontri positivi (ACK), riscontri negativi (NAK) e ritrasmissione. Protocollo stop-and wait: dopo l invio del pacchetto il sender deve ricevere ACK prima di poter inviare altri dati rdt2.0: problema Problema: ACK/NAK con errori Il sender non sa se il receiver ha inviato ACK o NACK Ritrasmette possibili duplicati Gestione dei duplicati: Il sender ritrasmette il pacchetto se ACK/NAK corrotti Il sender aggiunge un numero di sequenza ad ogni pacchetto Il receiver scarta i pacchetti duplicati 14

15 rdt2.1: sender rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt) ( corrupt(rcvpkt) isnak(rcvpkt) ) sndpkt = make_pkt(0, data, checksum) call 0 from ACK or NAK ACK or NAK call 1 from ( corrupt(rcvpkt) isnak(rcvpkt) ) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt) sndpkt = make_pkt(1, data, checksum) rdt2.1: receiver (corrupt(rcvpkt) sndpkt = make_pkt(nak, chksum) not corrupt(rcvpkt) && has_seq1(rcvpkt) sndpkt = make_pkt(ack, chksum) notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) sndpkt = make_pkt(ack, chksum) 0 from 1 from notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) sndpkt = make_pkt(ack, chksum) (corrupt(rcvpkt) sndpkt = make_pkt(nak, chksum) not corrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(ack, chksum) 15

16 Riscontri positivi e negativi Aggiungendo un campo di riscontro agli ACK, contenente il numero di sequenza del segmento cui l ACK si riferisce, il NAK può essere sostituito da un ACK duplicato, relativo all ultimo segmento ricevuto correttamente rdt2.2: sender rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,1) ( corrupt(rcvpkt) isack(rcvpkt,0) ) sndpkt = make_pkt(0, data, checksum) call 0 from ACK1 ACK0 call 1 from sndpkt = make_pkt(1, data, checksum) ( corrupt(rcvpkt) isack(rcvpkt,1) ) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,0) 16

17 rdt2.2: receiver (corrupt(rcvpkt) has_seq1(rcvpkt)) notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) sndpkt = make_pkt(ack0, chksum) 0 from 1 from notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) sndpkt = make_pkt(ack1, chksum) (corrupt(rcvpkt) has_seq0(rcvpkt)) rdt3.0: canale con errori e perdita di pacchetti Il canale sottostante può anche perdere pacchetti. È necessario meccanismo per rilevare la perdita di pacchetti (dati o ACK) Se il sender non riceve alcuna notifica dal receiver entro un tempo scelto opportunamente, il pacchetto (o l ACK) è andato perso e il sender ritrasmette Come scegliere tale tempo? Il pacchetto potrebbe arrivare con forte ritardo: problema dei duplicati, risolvibile con numeri di sequenza 17

18 Ritrasmissione basata sul tempo Meccanismo di conto alla rovescia. Il sender deve: avviare il timer dopo la trasmissione di un pacchetto (nuovo o ritrasmesso) interrompere il timer al ricevimento di un ACK rispondere alle interruzioni del timer rdt3.0 sender rdt_rcv(rcvpkt) call 0 from rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,1) stop_timer timeout start_timer ( corrupt(rcvpkt) isack(rcvpkt,0) ) Wait for ACK1 sndpkt = make_pkt(0, data, checksum) start_timer Wait for ACK0 call 1 from sndpkt = make_pkt(1, data, checksum) start_timer ( corrupt(rcvpkt) isack(rcvpkt,1) ) timeout start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,0) stop_timer rdt_rcv(rcvpkt) 18

19 rdt3.0: receiver (corrupt(rcvpkt) has_seq1(rcvpkt)) notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) sndpkt = make_pkt(ack0, chksum) 0 from 1 from notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) sndpkt = make_pkt(ack1, chksum) (corrupt(rcvpkt) has_seq0(rcvpkt)) 19