Strato trasporto Lo strato trasporto si colloca al livello 4 della pila ISO-OSI. Ha la funzione di stabilire un collegamento logico tra le applicazioni dei diversi host collegati tra di loro. I messaggi che si scambiano i vari host sono "segmentati" e trasformati in TPDU(Transfert Protocol Data Unit). Per capir meglio la cosa analizziamo il seguente esempio: Nota: Servizio: insieme di di operazioni che un livello mette a disposizione per comunicare con un livello superiore. Protocollo: insieme di regole che governano lo scambio di informazioni a parità di livello. Service Access Points: è un servizio che interfaccia un livello N con un livello N-1. I protocolli di trasporto del mittente di un messaggio quindi non fanno altro che: riceve i messaggi tramite SAP, li dividono in segmenti e inviano questi TPDU (multiplazione). I protocolli di trasporto del destinatario ricevono i pacchetti tramite SAP e ricompongono la sequenza di segmenti (demultiplazione). TCP: è un servizio affidabile, in quanto controlla l'integrità dell'informazione scambiata. Inoltre è di tipo connection-oriented, in quanto prima di inviare messaggi, stabilisce una connessione biunivoca tra mittente e destinatario. UDP: non è affidabile ed è di tipo connectionless (non stabilisce una connessione). È usato solo occasionalmente. Le applicazioni di due diversi Host comunicano tramite le primitive messe a disposizione dagli strati sottostanti: Listen: aspetta la richiesta di connessione Send data: trasmette Receive data: riceve T.connect: apre una connessione T.disconnect: la chiude Ogni primitiva ha i seguenti metodi: Request(): si richiede un'azione Indication(): avvertimento di un evento Response(): chiede di rispondere ad un evento Confirm(): segnala l'arrivo della conferma Es:
Quando su di una rete sono operativi più host, allora ci saranno più messaggi inviati e ricevuti contemporaneamente, quindi il livello di trasporto opera il multiplexing/demultiplexing. A causa quindi delle diverse applicazioni che possono essere coinvolte non basta aggiungere per ogni pacchetto l'ip, ma dobbiamo aggiungere l'indirizzamento di trasporto. Il protocollo di trasporto quindi utilizza il meccanismo delle porte. Ogni porta individua un canale logico utilizzabile per la comunicazione di una determinata applicazione. La coppia IP:porta viene detta socket. L'applicazione così comunicherà al sistema operativo il socket locale: Indirizzo IP:porta locale Così facendo tutti i pacchetti che devono arrivare ad una determinata applicazione sono facilmente riconoscibili. L'applicazione invierà i pacchetti ad un determinato socket di destinazione: Indirizzo IP:porta di destinazione Ogni porta è un valore numerico di due byte. Continuando con l'esempio delle poste: quando inviamo una lettera, non basta semplicemente mettere sulla busta l'indirizzo (quindi l'ip) ma sarà necessario mettere anche il nome e cognome (la porta) del destinatario per poter inviduare in modo univoco la persona che deve ricevere la lettera. Come si vede dalla figura lo strato di trasporto aggiunge al pacchetto (composto solo da dati nel livello dell'applicazione, payload), un header. Nell'header troveremo quindi: Porta mittente e porta destinatario NB: poi vedremo meglio la struttura dell'header sia per il TCP che per l'udp.
Es. abbiamo già parlato della struttura client-server, ecco come interagiscono a questo livello: A questo livello vengono introdotti i controlli sulla qualità del servizio (QoS=Quality of Service). I parametri di questo controllo sono: Ritardo massimo nell'attivazione della connessione
Numero di byte trasferiti nell'unità di tempo Velocità di consegna e ritardo massimo Probabilità di fallimento della connessione o di interruzione in caso di congestione Probabilità che la connessione non venga stabilita entro il massimo tempo di ritardo di attivazione Tasso di errore residuo o numero di messaggi persi sul numero totale di messaggi inviati Probabilità di fallimento del trasferimento Ritardo di rilascio della connessione e probabilità di fallimento nel rilascio della connessione Protezione contro le intercettazioni dati (lettura o modifica non autorizzata) Priorità della connessione Probabilità che il livello di trasporto termini la connessione per problemi interni o di congestione Quindi prima di effettuare la connessione avviene la negoziazione: L'utente mittente invia allo strato trasporto destinatario i parametri di QoS necessari: Il livello trasporto esamina i parametri: Se li può garantire effettua la connessione Altrimenti: Non inizia la connessione e comunica il fallimento all'utente Inizia la negoziazione inviando una controproposta, se l'utente accetta la connessione è attivata UDP L'UDP (User Data Protocol) è stato pensato per tutti i servizi dove non ci dobbiamo curare della connessione o dell'integrità del dato. Come detto in precedenza utilizza il meccanismo delle porte e il protocollo IP. Spesso è utilizzato nell'invio di messaggi in broadcasting o in multicasting. È adatto a trasferimenti dove si predilige la velocità della trasmissione piuttosto che la qualità: ad esempio trasmissioni tv in streaming, dove possiamo tollerare la perdita di qualche fotogramma.
Questo protocollo può dare luogo a una modalità di trasferimento tra processi di tipo: Punto-punto Bidirezionale Full-duplex Ogni Datagramma UDP, incapsulato nel datagramma IP (20 bytes), è formato da un header UDP (lungo 8 bytes) e da un UDP data (la grandezza massima è decisa dal Maximum Segment Size) Il valore massimo del segmento è comunque 64kB. Il campo header è quindi composto da: Source/Destination Port Length: lunghezza Checksum: Controllo errori Descriviamo l'invio tramite UDP di un semplice messaggio "ciao" da un host sender 137.200.70.14 (client) ad un host receiver 130.130.12.17 (server) che ha come punto di accesso la porta 3069. Il server manda in esecuzione l'applicazione e si mette in attesa sulla porta 3069. L'indirizzo del socket del server sarà <130.130.12.17:3069>. Al server arrivano segmenti con IP e/o numeri di porta differenti, quelli con lo stesso numero di porta e IP vengono consegnati allo stesso socket. Quando un server riceve un UDP: Legge il numero di porta del mittente Estrae il messaggio Invia il messaggio al socket con il numero di porta specificato: Socket mittente A: <69.12.0.54:3030> Socket mittente B: <137.200.70.14:3010>
TCP Il TCP (Transmission Control Protocol) è un protocollo affidabile come già detto in precedenza. Definiamo Rtt (round trip time) il tempo che passa tra l'invio di un messaggio e la ricezione da parte del mittente del messaggio di avvenuta consegna (tempo di andata e ritorno). Definiremo invece Rto (retransmission time out) il massimo intervallo di tempo prima che un messaggio venga considerato perso dal mittente. Se il mittente non riceve l'ack (è il simbolo che identifica un segnale di Acknowledge emesso in risposta alla ricezione di un'informazione completa) allora invia nuovamente il messaggio. Per rendere corretta una trasmissione di messaggi tra due host sono necessarie le seguenti misure: numerazione dei segmenti trasmessi e trasmissione di messaggi di riscontro con numero di sequenza; impiego di un temporizzatore (timer) in trasmissione; impiego di finestre in trasmissione e in ricezione. La numerazione dei messaggi si rende necessaria per poter dare un ordine allo scambio nella multiplicazione.
Il campo Sequence Number (SN) contiene il numero sequenziale di ciascun byte di dati a partire dall'initial Sequence Number (ISN). Il primo byte di dati spedito avrà come numero di sequenza SN=ISN+1. Es: se per esempio il primo byte nel flusso di dati ha come SN=1 (quindi il ISN aveva valore ISN=0) e sono già stati trasferiti 5000 byte, il primo byte di dati nel segmento corrente è 5001 e quindi il suo SN viene settato a 5001. Lo standard TCP non richiede che ogni sistema inizi a numerare i byte partendo da uno specifico numero; ogni sistema sceglie liberamente il numero da cui iniziare la numerazione. Inoltre si aspetta di ricevere il segmento successivo all'ultimo segmento ricevuto in ordine, ovvero quello il cui numero di sequenza è pari al numero di sequenza dell'ultimo segmento ricevuto in ordine più la dimensione del carico utile dello stesso segmento (cioè del suo campo Data). Quando viene ricevuto un segmento, si controlla se il numero di sequenza ricevuto è quello atteso e in caso affermativo il destinatario può inviare direttamente il carico utile al processo di livello applicativo e liberare i propri buffer di ricezione: se invece riceve un numero di sequenza maggiore di quello atteso, memorizza temporaneamente i dati nel buffer di ricezione nell'attesa che giungano i segmenti mancanti andati persi oppure in ritardo sulla rete. Se il numero di sequenza ricevuto è inferiore a quello atteso significa che questo segmento è già stato ricevuto e quindi si tratta di un duplicato che viene scartato. In ogni segmento inviato è presente il numero di riscontro (Acknowledgment Number). Il numero che il mittente manda al destinatario è il numero del primo Byte che il mittente si attende di ricevere. Il numero di sequenza indica al ricevente che il mittente ha ricevuto ed inoltrato al processo applicativo di livello superiore il segmento avente numero di sequenza uguale al numero di riscontro indicato e anche tutti quelli precedenti. Il mittente libererà i suoi buffer solo dopo aver ricevuto tutti gli ACKn (tecnica Go-Back-N). Quindi questo numero ci assicurerà oltre al corretto ordine della sequenza, l'avvenuta ricezione di ogni segmento. La somma dei Byte deve rispettare la sequenza, altrimenti il ricevente non li conteggia e non viene aggiornato il contatore. Es:
Se l'host A ha ricevuto dall'host B un segmento con i byte da 1 a 567 e un segmento con i byte da 900 a 2000 riconosce che "ne manca un pezzo" e come conferma all'host A invia un segmento dove scrive nel campo riscontro il valore 568 che è il numero di byte che si aspetta dall'host B per Non è richiesta la trasmissione di un messaggio di ACK a ogni segmento ricevuto: il riscontro che arriva alla sorgente è di tipo cumulativo. Per ogni segmento inviato il Tcp avvia il timer di Rto (timeout). Se nessun ACK viene ricevuto dal mittente in quell'intervallo di tempo massimo questo ritrasmette tutti i segmenti inviati dall'ultimo Nell'esempio seguente il segmento di ACK non raggiunge la destinazione nell'intervallo di tempo RTO e quindi nessuno dei due segmenti inviati dall'host A viene confermato: si procede con la ritrasmissione del primo segmento. A questo punto si viene a creare un problema di duplicati: 2 segmenti uguali raggiungono l'host B che però ha memorizzato il numero di sequenza e quindi è in grado di ignorare la seconda trasmissione e richiedere il segmento mancante, cioè quello successivo ai primi due ricevuti (nel nostro caso il 150).
Il timer Keepalive si attiva dopo la ricezione di ogni pacchetto e quando scade dichiara la connessione caduta. Per evitare che la connessione cada inopportunamente il Tcp invia pacchetti vuoti quando il mittente non ha nulla da inviare. Il Timewait è il tempo che passa per disconnettere effettivamente una connessione ed è pari al doppio della vita di ogni pacchetto, per evitare che pacchetti circolanti vengano persi. Per individuare i segmenti che dovranno essere ritrasmessi il mittente usa quella che viene definita come finestra di trasmissione. La finestra di trasmissione ha dimensione WS e in essa vengono memorizzati tutti i numeri di sequenza dei byte che la sorgente può trasmettere senza bisogno di ricevere alcun messaggio ACK da parte della destinazione. Questa usa una struttura a coda con due variabili (due puntatori). sendbase: rappresenta il numero d'ordine del byte più vecchio tra quelli trasmessi ma non ancora riscontrati positivamente dalla destinazione; nextseqnum: rappresenta il numero d'ordine del prossimo byte che cade nella finestra corrente e che deve ancora essere trasmesso per la prima volta.
Alla ricezione di un ACK il mittente aggiorna il valore di sendbase con il valore che gli viene comunicato o se tale valore risulta essere superiore al valore corrente, altrimenti lo lascia inalterato. Aggiornando il valore inferiore la finestra viene spostata collocandosi più a destra dello stesso numero di byte. La finestra di ricezione, avente dimensioni WD pari al numero di byte che il ricevente è in grado di ricevere in quel momento, è una struttura di dati che viene mantenuta aggiornata nell'host di destinazione. Nella finestra di ricezione vengono memorizzati i numeri d'ordine dei byte che la destinazione è disposta a ricevere consecutivamente, prima di dover inviare alcun messaggio ACK alla sorgente. La gestione di questa finestra viene effettuata con un'unica variabile, rcv_base, che contiene il minimo valore che il destinatario si attende sia perché quel byte non lo ha ancora ricevuto oppure perché lo ha ricevuto errato. Se il valore di questo campo è zero, il ricevente sta chiedendo di interrompere momentaneamente il flusso di dati. Se venisse perso proprio il pacchetto che richiede l'apertura della finestra, il mittente potrebbe rimanere in attesa indefinita, quindi il Tcp attiva un timer (timer di persistenza) ogni qual volta il ricevente chiude la finestra. La connessione Tcp segue le regole del protocollo punto-punto. La connessione inizia tramite un handshaking, cioè la trasmissione dei pacchetti necessari per regolare i parametri di connessione (il modem in fase di connessione produce un suono chiamato appunto handshake). La connessione in Tcp è full duplex. Come già visto in precedenza il Tcp segue il meccanismo dei socket.
Il Tcp incapsula i dati segmentati, di dimensione massima di 64kB, in datagrammi IP (come visto con l'udp). L'intestazione (Tcp header) è grande 20 bytes. Come nell'udp la dimensione massima del segmento viene determinata dall'maximum Segment Size (MSS). Definiamo anche l'mtu (Maximum Trasmission Unit), che include i 40 bytes dei due header. Solitamente nelle reti Ethernet il valore preimpostato è 1500 bytes.
Descriviamo quindi l'header Tcp: Source/destination port: porta sorgente e destinataria; Sequence number: numero di sequenza del primo byte contenuto nel segmento; ACKn: numero di sequenza che ci si aspetta di ricevere; Data offset: indica dove iniziano i dati; Reserved: posti tutti a zero (in futuro...); Flag: URG: segna 1 se si deve considerare il campo Urgent Pointer; ACK: segna 1 se si deve considerare il campo ACKn; PSH: segna 1 per la consegna immediata delle informazioni; CWR (Congestion Window Reduced): segna 1 se il sorgente ha ridotto la velocità di trasmissione per ridurre la congestione; ECE (ECN echo): posto a 1 se supporta l'explicit Congestion Notification; RST: posto a 1 per resettare una connessione; SYN: posto a 1 per stabilire la connessione e per sincronizzare i numeri di sequenza; FIN: posto a 1 per segnalare la fine della connessione. Window: dimensione della finestra in ricezione; Checksum: controllo dell'errore.
Il meccanismo di handshaking per aprire la connessione è chiamato three-way handshake (stretta di mano a tre vie): Il server manda in esecuzione l'applicazione, rimanendo in attesa passiva sulla porta dedicata (Passive Open); Un client vuole connettersi con il server, conoscendo il socket, manda una richiesta (Active Il Tcp del client genera in modo casuale un numero di sequenza iniziale e manda un messaggio di sincronizzazione (SYN=1, ACK=0): Alla ricezione di questo il server genera casualmente il suo numero di sequenza e risponde (SYN=1, ACK=1 anche detto SYN/ACK): Alla ricezione del SYN/ACK il client inizia ad inviare i primi dati in payload:
Ora i Tcp di client e server comunicano all'applicazione che la connessione è stata stabilita. La connessione Tcp non è da considerarsi una singola connessione bidirezionale, ma bensì una coppia di connessioni monodirezionali. Si potrebbe verificare il caso infatti di connessioni a metà(...). È possibile infatti la chiusura contemporanea della connessione tramite un handshake a tre vie:
Il flag utilizzato in questo caso sarebbe FIN e non SYN; L'altro risponderà con un FIN+ACK; Infine il primo host manderà l'ultimo ACK e la connessione sarà chiusa. Potrebbe verificarsi la chiusura da solo una parte della connessione tramite un handshake a quattro vie: Il client invia un segmento con il FIN=1; Il server invia un ACK per confermare la ricezione dei dati; (In questo momento la comunicazione server -> client è aperta e il server potrà continuare ad inviare pacchetti, mentre il client dovrà continuare ad inviare gli ACK corrispondenti) Quando anche il server vorrà chiudere manderà un messaggio con FIN=1; Quest'ultimo verrà confermato da un ACK finale da parte del client. Controllo dell'errore I protocolli IP, TCP e UDP utilizzano all interno di ciascuno delle loro intestazioni un semplice controllo di rilevazione di errore basato su un checksum a 16bit denominato internet checksum.
Il checksum contenuto all interno dell intestazione IP e calcolato solo sull intestazione IP (20 byte). Il calcolo del checksum non viene eseguito su nessuno dei byte che seguono l intestazione IP. Per calcolare il checksum IP di un frame in uscita per prima cosa il valore viene posto a zero, quindi la somma a 16bit con complemento a uno dell intera intestazione viene calcolata (l intestazione viene considerata sempre come sequenze di parole a 16bit). Il complemento a 1 di questa somma viene quindi memorizzata nel campo checksum dell intestazione IP. Quando il frame IP viene ricevuto la somma a 16bit con complemento a uno viene calcolata. Essendo il checksum calcolato da chi ha trasmesso il frame, gia compreso nel frame stesso, il checksum calcolato dal ricevitore dovra avere tutti i bit a 1 (ffff in notazione esadecimale, cioe uno dei due possibili valori di 0 nella rappresentazione dell aritmetica a complemento a 1) se l intestazione e stata ricevuta correttamente. Se il checksum contiene un solo bit diverso da 1 allora il frame viene scartato e non viene generato nessun errore. Sara compito di uno dei protocolli soprastanti IP (es TCP) a richiedere la ritrasmissione del frame. ICMP, IGMP, UDP e TCP tutti usano lo stesso metodo per calcolare il checksum contenuto della loro intestazione. Il checksum di TCP o di UDP, al contrario di quello calcolato e verificato in IP, contiene l intero segmento TCP o UDP cioe sia l intestazione che i dati. Mediante il calcolo del Checksum il protocollo di Trasporto riesce ad assicurare (non al 100%...) la correttezza dei segmenti inviati. Il procedimento è il seguente (uguale a quello già detto precedentemente illustrato per l'ip): I byte adiacenti sono presi a due a due per formare elementi a 16 bit; si esegue poi la loro somma in C1 (complemento a 1) sommando anche i carry; il campo checksum viene posto a 0 e viene scritto al suo interno il C1 della somma effettuata; Il ricevente esegue la somma in C1 (questa volta con il checksum all'interno); se il risultato è FFFF tutto è OK. Facciamo un esempio: Simuliamo il controllo dell'errore in un trasferimento tramite il protocollo UDP. Nel calcolo del checksum UDP dovremmo tener conto di HEADER, PSEUDO-HEADER, DATI. Il datagramma trasferito sarà composto ad esempio da: 01 00 F2 03 F4 F5 F6 F7 00 00 (00 00 campo usato per il checksum). Formiamo le word a 16-bit : 0100 F203 F4F5 F6F7. Calcoliamo la somma: 0100 + F203 + F4F5 + F6F7 = DEEF con un carry di 0002. Sommiamo i carry accumulati 0002 per ottenere la somma in C1: DEEF + 002 = DEF1. Adesso calcoliamo il C1 della somma : ~DEF1 = 210E [CHECKSUM]. Spediamo il pacchetto con incluso il checksum : 01 00 F2 03 F4 F5 F6 F7 21 0E. Il ricevente calcola il suo checksum : 0100 + F203 + F4F5 + F6F7 + 210E = 0002 FFFD FFFD + 0002 = FFFF (tutto ok!!!). Esercizio Un'applicazione client/server utilizza il protocollo UDP. In un determinato istante un client con indirizzo IP 160.80.10.11 utilizzando la porta numero 1025 invia un segmento UDP, contenente 2 byte di dati di valore 3 e 6 (in formato decimale), al server. Il server ha indirizzo 160.80.10.32 e ascolta le richieste alla porta numero 7. Scrivete il formato del segmento UDP specificando in particolare il valore dei campi contenuti nel segmento inviato dal suddetto client.
Pseudo-header Source IP: A0 50 A B Destination IP: A0 50 A 20 UDP-Header Source port: 401 Destination port: 7 Lenght: 2 Checksum: A721 Data 3 6 401(source port)+ 7(destination port)+ 2(lenght)+ A050(client IP)+ A0B(client IP)+ A050(server IP)+ A20(server IP)+ 3(data)+ 6(data)= 58DE+1 di carry->58dfh=0101 1000 1101 1111b=>complemento a 1=> 1010 0111 0010 0000b=A721h Laboratorio Wireshark Wireshark è un software che solitamente viene usato per "sniffare" una rete. In buona sostanza tramite questo programma sarà possibile catturare tutti i pacchetti che circolano sulla nostra rete. Wireshark è scaricabile gratuitamente. Dopo averlo aperto vi chiederà subito che rete e che tipo di protocollo deve filtrare.
Per metterlo in funzione cliccare sull'icona a forma di squalo in alto a sinistra. Aspettiamo un paio di secondi (magari apriamo il browser e iniziamo a navigare...). Apparirà questo: Logicamente appariranno anche tutti i protocolli di livello superiore che usano il protocollo che state usando come filtro (in questo caso l'udp). Per analizzare un pacchetto, per prima cosa stoppiamo lo sniffer (cliccando sul bottone rosso in alto). Poi andiamo a cliccare su di un pacchetto. Giù vedremo nel particolare la conformazione del pacchetto byte per byte... Esercizio 1: Fai partire il Wireshark con filtro UDP: Seleziona un pacchetto e determina quanti campi ci sono in una intestazione UDP, evidenziandoli e indicando per ciascuno di essi il nome e la dimensione e il valore corrispondente. A cosa si riferisce il campo Length? Qual è il valore più grande possibile per il numero di porta sorgente? Esegui manualmente la verifica del checksum. Esercizio 2: Ora metti come filtro TCP: Individua l'indirizzo IP e la porta TCP usata da un host sorgente. Evidenzia le tre fasi di un handshake a tre vie.