RETI DI CALCOLATORI Parte Settima LIVELLO TRASPORTO: UDP/TCP Gianfranco Prini DICO - Università di Milano gfp@dico.unimi.it

NOTA DI COPYRIGHT Queste trasparenze (slide) sono protette dalle leggi sul copyright e dalle disposizioni dei trattati internazionali. Il titolo e il copyright delle slide (ivi inclusi, ma non limitatamente, ogni immagine, fotografia, animazione, video, audio, musica, testo, tabella, disegno) sono di proprietà dell'autore. Le slide possono essere riprodotte e utilizzate liberamente dagli istituti di ricerca, scolastici e universitari italiani afferenti al Ministero dell’Istruzione, dell’Università e della Ricerca per scopi istituzionali e comunque non a fini di lucro. In tal caso non è richiesta alcuna autorizzazione. Ogni altro utilizzo o riproduzione, completa o parziale (ivi incluse, ma non limitatamente, le riproduzioni su supporti ottici e magnetici, su reti di calcolatori e a stampa), sono vietati se non preventivamente autorizzati per iscritto dall'autore. L'informazione contenuta in queste slide è ritenuta essere accurata alla data riportata nel frontespizio. Essa è fornita per scopi meramente didattici e non per essere utilizzata in progetti di impianti, prodotti, reti, etc. In ogni caso essa è soggetta a cambiamenti senza preavviso. L'autore non assume alcuna responsabilità per il contenuto delle slide (ivi incluse, ma non limitatamente, la correttezza, la completezza, l'applicabilità, l'adeguatezza per uno scopo specifico e l'aggiornamento dell'informazione). In nessun caso possono essere rilasciate dichiarazioni di conformità all'informazione contenuta in queste slide. In ogni caso questa nota di copyright non deve mai essere rimossa e deve essere riportata fedelmente e integralmente anche per utilizzi parziali.

ARGOMENTI Dal routing alla richiesta di servizi Servizi, porte, porte well-known Protocollo (non affidabile) UDP Dall’inaffidabilità all’affidabilità Algoritmi di sliding window Requisiti dei canali affidabili Protocollo (affidabile) TCP

DAL ROUTING DI PACCKETTI ALLA RICHIESTA DI SERVIZI Pacchetti instradati sulla base dell’indirizzo IP di destinazione (DSAP di livello rete: L3) Indirizzi IP: sequenze di 32 bit, normalmente specificate come quaterne di numeri decimali (es. 159.149.10.5) dove ciascun numero assume valori nell’intervallo [0:255] Header L3: oltre a DSAP (indirizzo IP) per indirizzare una (interfaccia di) destinazione, anche SSAP (indirizzo IP) per consentire al destinatario di indirizzare il mittente Servizi (remoti) richiesti sulla base dei numeri di porta (DSAP di livello trasporto: L4) Numeri di porta: sequenze di 16 bit, specificate come numeri decimali (es. 21) nell’intervallo [0:65535] Header L4: oltre a DSAP (numero di porta) per richiedere un servizio remoto, anche SSAP (numero di porta) per consentire di rispondere a chi ne ha fatto richiesta

RICHIESTA/EROGAZIONE DEI SERVIZI: IMPLEMENTAZIONE Paradigma client-server (anche breve durata) Client proattivo: diritto di iniziativa (richiede un servizio) Server reattivo: dovere di obbedienza (eroga il servizio) Client e server implementati come due attività concorrenti (processi Linux, thread Java, etc.) Client e server entrambi installati sulla stessa macchina: comunicazione via interfaccia di loopback (es. 127.0.0.1), via interfaccia di rete comune (es. 159.149.154.254) o via interfacce di rete distinte (es. 16.37.215.2 e 16.41.7.196), eventualmente su reti distinte (es. 12.31.4.1 e 16.41.8.76) Invio/ricezione di pacchetti: operazioni di I/O del S.O. in nome e per conto di client o server Pacchetti recapitati ex ante: il S.O. bufferizza pro tempore Pacchetti recapitati ex post: il processo/thread attende (I/O bloccante – la norma) o prosegue (I/O non bloccante)

CLNS DI LIVELLO TASPORTO: IL PROTOCOLLO UDP UDP (User Datagram Protocol): CLNS privo di controllo di flusso suo proprio, e inaffidabile Velocità di elaborazione alla destinazione può essere insufficiente rispetto al ritmo di arrivo dei pacchetti Possibilità di pacchetti persi, duplicati o fuori sequenza Header UDP: quattro campi di 16 bit ciascuno Source port (SSAP): valore 0 se non si prevede risposta Destination port (DSAP): numero di porta del servizio Message length (min 8): comprende header e payload Checksum: valore 0 se non la si intende usare (se calcolo di checksum fornisce 0 come risultato, si usa il valore 0xFFFF, altra rappresentazione di 0 in complemento a 1) Payload UDP: può essere vuoto, ma anche saturare un pacchetto IP di lunghezza max

NUMERI DI PORTA RISERVATI: WELL-KNOWN PORT (1) I numeri di porta nell’intervallo [0:1023] sono riservati. Gli altri sono assegnabili dal S.O. ai servizi erogati dai programmi utente Alcuni numeri riservati sono assegnati a specifici servizi (well-know port number) Servizi UDP/TCP con well-know port number: Porta 007 – UDP/TCP – echo – Servizio di echo Porta 009 – UDP/TCP – discard – Ignorare il pacchetto Porta 013 – UDP/TCP – daytime – Ora del giorno Porta 067 – UDP/TCP – bootps – Server BOOTP/DHCP Porta 088 – UDP/TCP – kerberos – Servizio di sicurezza Porta 111 – UDP/TCP – rpc – Remote Procedure Call Porta 123 – UDP/TCP – ntp – Network Time Protocol

NUMERI DI PORTA RISERVATI: WELL-KNOWN PORT (2) Servizi solo UDP con well-know port number: Porta 069 – UDP – tftp –Trivial File Transfer Protocol Servizi solo TCP con well-know port number: Porta 020 – TCP – ftp-data – File Transfer Protocol (dati) Porta 021 – TCP – ftp – File Transfer Protocol (comandi) Porta 022 – TCP – ssh – Secure Shell Porta 023 – TCP – telnet – Terminale remoto (o virtuale) Porta 025 – TCP – smtp – Simple Mail Transfer Protocol Porta 080 – TCP – www – World Wide Web Porta 110 – TCP – pop3 – Post Office Protocol (ver. 3) Porta 161 – TCP – snmp – Simple Network Mgmt Prot

INAFFIDABILITA’ DEL LIVELLO NETWORK: CAUSE/SOLUZIONI Mancata ricezione di pacchetti: cause Errori di trasmissione (ricezione di pacchetti corrotti) Guasti nell’HW/SW dei sistemi intermedi o dei canali fisici Congestione lungo il percorso (rotta) dei pacchetti Ricezione di pacchetti duplicati: cause Ritrasmissione automatica indotta dal raggiungimento del tempo-limite (timeout) nel ricevere conferma (ACK) dell’avvenuta ricezione di un pacchetto (v. oltre) Ricezione di pacchetti fuori ordine: cause Instradamento dinamico di pacchetti appartenenti allo stesso flusso di dati attraverso rotte differenti Ritrasmissione posticipata di pacchetti corrotti (v. oltre) Protocolli che risolvano questi problemi una volta per tutte (es. TCP): soluzioni ad hoc per ciascuna applicazione difficili e/o inefficienti

CONFERMA DI RICEZIONE (ACK) E RITRASMISSIONE Conferma ACK sincrona, senza e con timeout Invio pacchetto A – Invio pacchetto A Arrivo ACK A – Arrivo ACK A Invio pacchetto B – Invio pacchetto B Arrivo ACK B – [Timeout] Invio pacchetto C – Invio pacchetto B Invio pacchetto C – Arrivo ACK B Timer attivato alla trasmissione di ciascun pacchetto e disattivato alla ricezione di ACK (timeout scatta se ACK non arriva per tempo) Prestazioni subottime: canali full-duplex usati in modalità half-duplex (sottocanale uscente inutilizzato tra una trasmissione e l’arrivo del relativo ACK; similmente per canale entrante)

TRASMISSIONE ANTICIPATA E POSSIBILI RITARDI DEGLI ACK Soluzione: anticipare invio di nuovi pacchetti Invio pacchetto A, avvio timer A Invio pacchetto B, avvio timer B Invio pacchetto C, avvio timer C Arrivo ACK A, arresto timer A Arrivo ACK C, arresto timer C – [Timeout B – può essere andato perduto B oppure ACK B] Invio pacchetto D, avvio timer D Arrivo ACK B, arresto timer B Problema: se il timeout B è causato da perdita di ACK B, come si capisce che il secondo B è una copia da scartare e non un nuovo originale?

TRASMISSIONE ANTICIPATA E NUMERI DI SEQUENZA (1) Soluzione: differenziare i pacchetti (numerarli sequenzialmente insieme ai relativi ACK) Invio pacchetto A, seq=1, avvio timer 1 Invio pacchetto B, seq=2, avvio timer 2 Invio pacchetto C, seq=3, avvio timer 3 Arrivo ACK A, seq=1, arresto timer 1 – [Timeout 2 – può essere andato perduto B o ACK B] Invio pacchetto D, seq=4, avvio timer 4 Arrivo ACK B, seq=2, arresto timer 2 Nota bene: è irrilevante che ACK B riguardi il secondo invio o (anche se in ritardo) il primo

TRASMISSIONE ANTICIPATA E NUMERI DI SEQUENZA (2) Alio modo: un ACK (cumulativo) con seq=n conferma i pacchetti fino a quello con seq=n Invio pacchetto A, seq=1, avvio timer 1 Invio pacchetto B, seq=2, avvio timer 2 Invio pacchetto C, seq=3, avvio timer 3 Arrivo ACK A, seq=1, arresta timer 1 Arrivo ACK C, seq=3, arresta timer 3 – Invio pacchetto D, seq=4, avvio timer 4 [Timeout 2 – non può che essere andato perduto ACK B] Arrivo ACK B, seq=2 [viene ignorato] Problema: ricevuti ACK fino a seq=n, per quali i è bene anticipare pacchetti fino a seq=n+i?

TRASMISSIONE ANTICIPATA, SLIDING WINDOW, PIGGYBACK Soluzione: sliding window (fisse o variabili) Sliding window di dimensione K (fissa o variabile): max numero di pacchetti non ancora confermati che possono essere anticipati: se n è il più alto valore per cui è stato ricevuto un ACK con seq=n, allora si può anticipare la trasmissione di tutti i pacchetti con seq=n+i, dove n+i non sia superiore a n+K Se ho già anticipato i pacchetti con seq=n+1, ..., seq=n+m (ancora non confermati), potrò ulteriormente anticipare i pacchetti i K-m pacchetti con seq=n+m+1, ..., seq=n+N Piggyback: conferma di pacchetti mediante inserimento di ACK nei pacchetti del flusso che “viaggia” in direzione opposta Se non ci sono pacchetti pronti per la trasmissione, se ne crea uno vuoto che contiene solo l’ACK in questione

CANALI AFFIDABILI: REQUISITI PREVALENTI O FREQUENTI (1) Orientamento a connessione (circuiti virtuali) Separare instaurazione di una connessione a un servizio remoto rispetto al dialogo con chi eroga quel servizio Orientamento al flusso (sequenza di ottetti) Quantità di dati di frequente non deteterminabile a priori Ordinamento degli ottetti alla trasmissione conservato in ricezione (violazione possibile solo per dati “urgenti”) Flussi non strutturati (come i file di Unix/Win) Demandare strutturazione dei flussi alle applicazioni per evitare scelte troppo rigide o non sostenibili nel tempo Flussi full-duplex (e riduzione a semi-duplex) Favorire dialogo bidirezionale client-server (anche ACK) Segnalazione (es. ACK) in linea (es. piggypack) invece che fuori linea su canali di servizio dedicati allo scopo

CANALI AFFIDABILI: REQUISITI PREVALENTI O FREQUENTI (2) Frammentazione in pacchetti opaca all’utente Applicazione produce dati con granularità “conveniente” per la sua semantica (es. un carattere alla volta per telnet) Protocollo di trasporto libero di frammentare/raggruppare dati in pacchetti di dimensione “conveniente” per routing (ma possibilità di forzare inoltro rapido – push – nel caso di applicazioni interattive intolleranti a bufferizzazione) Compensazione dinamica delle discrasie tra tempi di propagazione, di trasmissione e di elaborazione (tecnica delle sliding window) Trasmissione di nuovi pacchetti anticipata rispetto a ricezione delle conferme di corretta ricezione (ACK) Ritrasmissione di pacchetti persi/corrotti posticipata rispetto alla conservazione dell’ordine di trasmissione Adattamento dinamico della window al variare del carico della rete e della velocità di elaborazione del ricevente

CONS DI LIVELLO TRASPORTO: IL PROTOCOLLO TCP TCP (Transmission Control Protocol): CONS affidabile, dotato di controllo di flusso, che soddisfa tutti i requisiti delle slide precedenti Usa sliding window a lunghezza variabile, ma n, n+m e n+K (con K variabile) indicano ottetti e non pacchetti K viene ridefinito a ogni ACK, inviando al trasmettitore il numero di ottetti N che il ricevitore può ancora ricevere (se N=0 si blocca ogni trasmissione di dati non urgenti) Nessun meccanismo esplicito per controllo congestione Multipla/demultipla connessioni di più client allo stesso servizio (porta) del server Rappresenta le connessioni come coppie di punti terminali del tipo [(addract,portact),(addrpas,portpas)] Un punto terminale è detto attivo [risp. passivo] se può solo emettere [risp. accettare] richieste di connessione

SEGMENTI TCP: FORMATO Segmento: unità di trasferimento di TCP Scambio di segmenti consente di instaurare connessioni, trasferire dati, inviare ACK, modificare le dimensioni della sliding window, chiudere connessioni Dati utente (flussi di ottetti) frammentati in segmenti Header dei segmenti TCP: più complesso di quello UDP (v. oltre) Gestisce informazioni per implementare sliding window, ACK, numeri di sequenza, ottetti urgenti, Payload TCP: può essere vuoto, ma anche saturare un pacchetto IP di lunghezza max

HEADER TCP: FORMATO Source port (16 bit): diversamente da UDP, mai pari a 0 Destination port (16 bit): numero di porta del servizio Sequence number (32 bit): seq associato al segmento ACK number (32 bit): posizione (nel flusso di dati che “viaggia” in direzione opposta a quella del segmento) del prossimo ottetto che il ricevutore si attende di ricevere Hlen (4 bit): lunghezza dello header (multiplo di 32 bit) Reserved (6 bit): non utilizzato Code bits (6 bit): URG, ACK, PSH, RST, SYN (seq), FIN Window (16 bit): quantità di ottetti ancora anticipabili Checksum (16 bit): come per UDP (valore zero=0xFFFF) Urgent pointer (16 bit): offset dell’ultimo ottetto urgente Options (0-32 bit): varie, utile per Max Segment Size Padding (0-32 bit): allinea segmento a multiplo di 32 bit