RETI DI CALCOLATORI
Parte Settima
LIVELLO
TRASPORTO:
UDP/TCP
Gianfranco Prini
DICO - Università di Milano
[email protected]
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
Arrivo ACK A
Invio pacchetto B
Arrivo ACK B
Invio pacchetto C
Invio pacchetto C
– Invio pacchetto A
– Arrivo ACK A
– Invio pacchetto B
– [Timeout]
– Invio pacchetto B
– 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 B, avvio timer 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 B, seq=2, avvio timer 2
– 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