CCNA 7: TRANSPORT LAYER

Il transport layer stabilisce una comunicazione temporanea

tra due applicazioni e trasferisce dati tra loro. Unapplicazione
genera dei dati che sono spediti dallapplicazione dellhost
sorgente allapplicazione dellhost ricevente, senza tener conto
del tipo di dispositivo ricevente, del tipo di media fisico, del
percorso intrapreso , della congestione su un link o della vastit
della rete. Il transport layer il link tra lapplication layer e i
layer sottostanti, che sono responsabili della trasmissione in
rete. Il transport layer provvede alla segmentazione del data e
fornisce i controlli necessari per riassemblare i segmenti in
flussi di comunicazione. Nel protocollo TCP/IP la funzione di
segmentazione e riassemblaggio del data sono svolti da due
tipi di protocolli molto diversi tra loro: TCP (Transmission Control
Protocol) e UDP (User Datagram Protocol. Le primarie responsabilit del network layer:

Tracking Individual Conversations: monitorare la comunicazione

individuale tra le applicazioni dellhost sorgente e quella del
destinatario: a livello di transport layer, ogni specifico set di dati che
scorre tra lapplicazione sorgente e lapplicazione destinataria detta
conversazione. Un host pu avere svariati applicazioni comunicanti in
rete simultaneamente, ognuna di queste applicazioni comunica con una
o pi applicazioni su uno o pi host remoti. Il transport layer ha quindi la
responsabilit di manutenzionare tracciare svariate comunicazioni.

Segmenting Data and Reassembling Segments: frammentare il

data per una pi semplice amministrazione e poi riassemblarne i
segmenti in flussi di dati verso il destinatario. necessario preparare i
dati per poterli spedire sul media fisico in pezzi maneggevoli. Molte reti
hanno un limite per lammontare dei dati che possono essere inclusi in
un singolo pacchetto. I protocolli di transport layer segmentano i dati
delle applicazioni in blocchi della giusta misura. Questa operazione
include lincapsulamento di ogni pezzo di data con laggiunta di un
header (che servir poi nel processo di riassemblamento). Il transport
layer dellhost destinatario deve poter ricostruire i pezzi del data in un completo flusso
di dati leggibili dall lapplication layer.

Identifying the Applications: identificare la corretta applicazione per

ogni flusso di comunicazione; possono esserci svariate applicazioni e
servizi in uso per ogni host nella rete, e per passare il flusso di dati alla
corretta applicazione necessario che il transport layer sappia
identificare lapplicazione adeguata. Per assolvere tale compito il
transport layer assegna ad ogni applicazione un identificativo,
chiamato port number. Ad ogni software che deve accedere in rete
assegnata una port number, unica per quellhost. Il transport layer usa
le porte per identificare il tipo di applicazione o di servizio.

12

Conversation Multiplexing: spedire dati molto grandi (streaming

video) in rete sotto forma di un flusso di comunicazione completo,
userebbe tutta la bandwidth e impedirebbe ad altre comunicazioni di
operare simultaneamente, oltre a rendere molto difficili le operazioni
di error recovery e ritrasmissione dei dati corrotti. Segmentare il
data in pezzi pi piccoli permette a svariate comunicazioni
provenienti da svariati utenti di essere multiplexate sullo stessa rete.
La segmentazione permette a pi applicazioni di spedire e ricevere
dati simultaneamente su un singolo computer, senza la
segmentazione solo unapplicazione potrebbe ricevere il data. Per il video streaming il media
sarebbe completamente esaurito da una sola comunicazione, invece di essere condiviso da pi
applicazioni, non si potrebbero ricevere email, chattare e vedere pagine web mentre si sta
visualizzando un video. Il transport layer aggiunge ad ogni segmento un header che contiene
un dato in binario, e che comprende diversi campi contenenti dei bit. I valori di questi campi
permettono ai diversi protocolli di transport layer di amministrare le comunicazioni.
Transport Layer Reliability : affidabilit del transport layer:
il transport layer amministra anche laffidabilit di una
comunicazione, le diverse applicazioni hanno diversi requisiti
di affidabilit. IP si basa solamente sulla struttura di tipo
addressing e routing dei pacchetti e non specifica come i
pacchetti vengono consegnati e trasportati. I protocolli di
trasporto specificano invece dettagliatamente come avviene la
trasmissione dei dati tra gli host. TCP/IP ha due protocolli di
trasporto, TCP e UDP. IP usa questi protocolli di trasporto per
abilitare la comunicazione e il trasferimento dei dati tra gli host. TCP un protocollo di
transport layer affidabile, che assicura lavvenuta consegna dei dati al destinatario. UDP un
protocollo di transport layer molto semplice che non garantisce laffidabilit.
TCP: un protocollo di trasporto affidabile, include processi che assicurano la consegna
comprovata dei dati tra le applicazioni attraverso la consegna di tipo ACK (Acknowledged).
Usare TCP come spedire un pacco che pu essere tracciabile dalla partenza sino alla
destinazione. Tre operazioni basi dellaffidabilit di TCP:

Monitorare i pacchetti trasmessi

Mandare un messaggio ACK per i dati ricevuti

Ritrasmettere i dati unacknowledged.

TCP spezza un messaggio in segmenti identificati da una sequenza numerica, e li passa al

processo IP per assemblarli in pacchetti. TCP monitora i pacchetti e se il mittente non riceve un
messaggio di ACK entro un tempo prestabilito ritrasmette i pacchetti. Solo la porzione di
messaggio andata persa verr ritrasmessa, non il messaggio per intero. Sullhost ricevente,TCP
deve riassemblare i segmenti del messaggio e passarli allapplicazione. FTP (File Transfer
Protocol) e HTTP (Hypertext Transfer Protocol) sono applicazioni che usano il protocollo TCP per
la consegna assicurata. Lintestazione di TCP contiene informazioni di controllo per lACK, la
ritrasmissione e il monitoraggio. Laffidabilit di TCP fornisce comunicazioni robuste tra le
applicazioni ma nel contempo ha svariati meccanismi di controllo che rallentano la
trasmissione. Il protocollo di trasporto UDP un compromesso tra laffidabilit e il peso
arrecato sulle risorse di rete.

12

UDP provvede alle funzioni basilari della consegna dei segmenti tra le applicazioni, con una
sorveglianza e verifica dei dati molto lievi. UDP un protocollo di tipo best-effort, ovvero
inaffidabile perch non invia responsi di avvenuta consegna (NACK). UDP non ha processi a
livello di transport layer che informano il mittente se avvenuta la consegna. UDP equivale a
spedire una lettera senza tracking, pu giungere a destinazione oppure no ed il mittente non
avr la conferma di avvenuto recapito.
Sia il TCP che lUDP sono protocolli di trasporto validi, a seconda delle
necessit dellapplicazione preferibile uno o laltro, per alcune
applicazione i segmenti devono arrivare con una sequenza specifica per
essere elaborati con successo, altre hanno bisogno di ricevere tutti i
segmenti prima di poterli utilizzare, in questi casi si usa TCP (esempio: i
database, web browsers e gli email client necessitano che al destinatario
giunga il dato completo e nella sua condizione originale, qualsiasi dato
mancante pu causare la completa rovina della comunicazione),per tale
motivo necessario avere un protocollo che supervisiona la comunicazione
per questi tipi di comunicazione. Altre volte invece, certe applicazioni sono
in grado di tollerare la perdita di dati durante la trasmissione ma non
possono ammettere un ritardo, in questi casi il protocollo UDP pi indicato perch necessita
di meno supervisione e quindi non crea ritardi (es: streaming audio, video, e VoIP). Se uno o
due segmenti di un flusso video si perdono, si crea una momentanea distorsione nel flusso che
appare come una distorsione dellimmagine, lutente pu anche non notarla. Invece se lo
streaming video avesse un sistema che ritrasmette i pacchetti non ricevuti, si verificherebbe
un degrado peggiore per limmagine, in questi casi preferibile la velocit di UDP e tralasciare
laffidabilit. Unaltra applicazione che usa UDP la radio su web, se parte del messaggio
perduto durante la trasmissione non viene ritrasmesso. Con UDP la perdita di qualche
pacchetto causa una rapidissima interruzione, con TCP i pacchetti verrebbero ritrasmessi e la
resa finale sarebbe di gran lunga peggiore.

Introducing TCP and UDP: introduzione a TCP e UDP: per capire

realmente le differenze tra i due protocolli importante capire come
ogni protocollo usa le specifiche funzioni di affidabilit e come
tracciano le comunicazioni:
TCP (Transmission Control Protocol): TCP descritto con il
documento RFC 793, supporta le funzioni di segmentazione e
riassemblamento ed inoltre:

Connection-oriented: il protocollo stabilisce una conversazione

di tipo connection-oriented tramite delle sessioni.

Reliable delivery: il protocollo assicura una consegna affidabile.

Ordered data reconstruction: il protocollo ricostruisce il pacchetto seguendo un ordine.

Flow Control: controlla il flusso dei dati.

Establishing a session: stabilendo una sessione: TCP un protocollo di tipo connectionoriented, ovvero negozia e stabilisce una connessione permanente (detta anche sessione) tra
il mittente e il destinatario prima di inoltrare il traffico. Le sessioni preparano i dispositivi per la
futura comunicazione. Attraverso le sessioni i dispositivi negoziano lammontare del traffico che
pu essere inoltrato in un dato periodo di tempo e lo amministrano. La sessione viene
terminata solo ad avvenuta e completa trasmissione.

12

Reliable Delivery: TCP ha un metodo per assicurarsi la consegna affidabile dei dati, in termini
di networking, il termine affidabilit significa assicurarsi che tutti i segmenti che partono da un
mittente giungano al destinatario. Per molte ragioni, possibile che un segmento si deteriori o
si perda del tutto, e TCP assicura la ritrasmissione dei dati corrotti.
Same Order delivery: consegna con lo stesso ordine: in una rete ci possono essere tante
rotte con diverse velocit di trasmissione e i dati possono arrivare nellordine sbagliato.
Numerando e aggiungendo una sequenza ai segmenti, il TCP assicura che i segmenti vengano
riassemblati in ordine corretto.
Flow Control: controllo del flusso: gli host di una rete hanno risorse limitate (memoria e la
bandwidth) e quando TCP si accorge che queste risorse sono utilizzate in maniera massiva, pu
richiedere allapplicazione trasmittente di ridurre il flusso dei dati. Questo processo si chiama
flow control e previene la perdita di segmenti in rete evitando la necessit di ritrasmetterli.
Role of TCP: ruolo del TCP: una volta che TCP ha
stabilito una sessione , capace di tenere traccia della
conversazione che avviene durante la sessione. Grazie
alla capacit di TCP di tracciare le attuali conversazioni
considerato un protocollo statement (STATEMENT
PROTOCOL), ovvero un protocollo che traccia lo stato
delle sessioni di comunicazione. Es: quando un data
trasmesso con TCP, il mittente attende che il destinatario
gli risponda con un ACK di avvenuta ricezione del dato, il
TCP traccia le informazioni che ha spedito e quelle per le
quali ha ricevuto ACK, se i dati sono NACK il mittente
capisce che i dati non sono arrivati e li rispedisce. Ogni
segmento di TCP ha 20 byte di overhead (controllo) nellintestazione (header), mentre un
segmento di tipo UDP ne ha solo 8. Controlli extra includono:

Sequence number (32 bit): usato per riassemblare il data.

Acknowledgement Number (32 bit): indica che il segmento stato ricevuto.

Header lenght (4 bit): detto anche data offset, indica la lunghezza dellheader di un
segmento TCP.

Reserved (6 bit): questo campo riservato per operazioni future.

Control bits (6 bit): include codici di bit e flags che indicano lo scopo e la funzione del
segmento TCP.

Window size (6 bit): indica il numero dei segmenti che possono essere accettati in un
solo istante.

Checksum (16 bit): usato per error checking dellheader e del data che compongono il
segmento.

Urgent (16 bit): indica se il data urgente.

UDP (User Datagram Protocol): un protocollo di tipo best-effort,

descritto nel documento RFC 768. UDP un protocollo di trasporto
snello che segmenta e riassembla i dati, come TCP, ma non ha
laffidabilit e il flow control. UDP un protocollo semplice,le sue
caratteristiche:

12

Connectionless: non stabilisce una connessione tra gli host prima che avvenga la
trasmissione.

Unreliable delivery: UDP non assicura laffidabilit della comunicazione, non esistono
processi per ritrasmettere i dati persi o corrotti.

No Ordered Data Reconstruction: a volte i segmenti sono ricevuti in ordine diverso da

come sono stati spediti, UDP non ripristina la sequenza originale, il data consegnato
al destinatario nellordine in cui arrivano.

No Flow Control: UDP non pu controllare e regolare lammontare dei dati che si
scambiano gli host durante la trasmissione, quindi pu accadere che il dispositivo
ricevente sia sovraccarico di dati, in questo caso, se il destinatario troppo carico,
elimina i segmenti sino a che non sar in grado di riceverli.

Role of UDP: ruolo dellUDP: anche se UDP non ha la reliability e il flow control,
la sua semplicit lo rende perfetto per quelle applicazioni che possono tollerare
una piccola percentuale di perdita dei dati trasmessi. I segmenti della
comunicazione in UDP si chiamano DATAGRAM e sono spediti in maniera beseffort dal protocollo di transport layer. DNS, lo streaming video e VoIP usano
UDP. Uno dei pi importanti requisiti del video e della voce in rete il fluire
veloce dei dati, le applicazioni per video e voce possono tollerare una piccola
perdita di dati senza che leffetto sia notabile. UDP un protocollo
STATELESS, ovvero n il client n il server tracciano lo stato delle sessioni di comunicazione.
Separating Multiple Communications: separazione delle comunicazioni
multiple: il transport layer deve poter separare e amministrare le comunicazioni
multiple per poterle gestire con i diversi requisiti necessari al trasporto. Es: un
utente sta simultaneamente chattando e ricevendo e spedendo email , guarda
pagine web ed effettua una telefonata di tipo VoIP, tutte queste applicazioni
ricevono e spediscono dati simultaneamente, nonostante ci siano diversi
requisiti di affidabilit. tollerabile un po di ritardo per il caricamento delle
email o delle pagine web, e perdere piccole porzioni di dati durante una
telefonata pu comportare la perdita di alcune parole, ed quindi possibile poter chiedere
allinterlocutore di ripetere. Questi inconvenienti sono considerati accettabili rispetto ai ritardi
che si verificherebbero se ogni volta i dati corrotti o persi venissero ritrasmessi. Nella figura si
vede come TCP e UDP amministrano diversamente le conversazioni simultanee variando i
requisiti, sia TCP che UDP tengono taccia delle varie applicazioni comunicanti ma la differenza
sta nei segmenti e datagrammi delle applicazioni, sia TCP che UDP hanno il campo PORT
NUMBER a identificarli.

TCP e UDP port addressing: assegnazione dellindirizzo delle

porte: nellheader di ogni segmento o datagramma sono inserite la
porta di sorgente e destinazione, il numero della porta sorgente
(source port number) il numero associato con lapplicazione che
ha creato la comunicazione sullhost locale. La destination port
number il numero della comunicazione associato allapplicazione
che dovr riceverla su un host remoto. Quando trasmesso un
messaggio, i servizi richiesti per linterpretazione sono identificati
dal numero di porta (port number). Ogni messaggio contiene sia il
numero di porta sorgente che il numero di porta di destinazione.

12

Destination Port: il client immette un numero di porta destinataria nel segmento per
avvisare il server di destinazione circa il tipo di applicazione richiesta per
linterpretazione del messaggio. La porta 80 per HTTP o servizi web, quando il client
specifica la porta 80, il server capisce che sono richiesti servizi web. Un server pu
offrire svariati servizi simultanei sulla porta 80 e allo stesso tempo provvedere allFTP
sulla porta 21.

Source Port: il source port number generato casualmente dal dispositivo mittente,
permettendo cos di identificare una comunicazione tra due dispositivi e quindi di
intraprenderne altre allo stesso momento. Un dispositivo pu spedire svariate
richieste HTTP ad un web server allo stesso tempo perch sono tracciate grazie alle
source ports. Le porte di sorgente e destinazione sono immesse nel segmento, i
segmenti sono poi incapsulati in pacchetti IP.

TCP and UDP port addressing: le porte di sorgente e

destinazione sono immesse nel segmento, i segmenti sono
incapsulati allinterno di un pacchetto IP. Il pacchetto IP contiene
lindirizzo IP della sorgente e della destinazione, la
combinazione tra indirizzi IP di sorgente e destinazione e il
numero delle porte di sorgente e destinazione si chiama
socket. Il socket usato per identificare il server e il service
richiesti dal client; ogni giorno migliaia di host comunicano con
milioni di server diversi e le comunicazioni sono identificate
grazie al metodo del socket. Il socket pair unico e identifica
una conversazione specifica tra due host:
es di client socket (1099 la port number del mittente): 192.168.1.7:1099
il socket in un web server potrebbe essere: 192.168.1.7:80
socket pair: la combinazione di questi due socket: 192.168.1.5:1099, 192.168.1.7:80
La source port di una richiesta client generata casualmente, il transport layer mantiene traccia della
porta e dellapplicazione che hanno generato la richiesta cos la risposta verr inoltrata allapplicazione
corretta. La requesting application port number usata come la port number di destinazione nella
risposta che proviene dal server.

IANA (Internet Assigned Numbers Authority)organizzazione che assegna il numero delle porte.
Diversi tipi di port numbers:

Well-known Ports ( Numbers 0 to 1023 ): porte ben conosciute, da 0 a 1023, riservate

per servizi e applicazioni note. Usate per HTTP, IMAP,SMTP e Telnet. Le applicazioni del
client si possono programmare per richiedere le connessioni a queste specifiche porte
e ai loro servizi associati.

Registered Ports ( Numbers 1024 to 49151 ): questi numeri di porte sono assegnate ai
processi dellutente e alle sue applicazioni. Questi processi sono i programmi che
lutente ha scelto di installare. Queste porte sono scelte dinamicamente dal client.

12

Dynamic or Private Ports ( Numbers 49152 to 65535 ): anche dette ephemeral ports
(porte passeggere), assegnate dinamicamente alle applicazioni del client quando il
client inizia a connettersi con un servizio. La dynamic port, identifica lapplicazione
del client durante la comunicazione dato che il client usa le well-known port per
identificare e connettersi al server per il servizio richiesto. Non comune che un host
usi una porta dinamica o una porta privata (solo alcuni programmi peer-to-peer le
usano).

Using both TCP and UDP: usare sia TCP che UDP: alcune applicazioni usano sia TCP che UDP,
ad es: il pi basso controllo di UDP abilita il DNS a servire svariate richieste client in maniera
molto veloce, e a volte spedire le richieste richiede laffidabilit di TCP. In casi come questo si
usa la porta well-known 53, che implementa sia TCP che UDP.
A volte necessario sapere quali sono le connessioni TCP attive, aperte e
funzionanti in un host di rete. Il comando netstat verifica queste
connessioni, mostra il protocollo in uso, lindirizzo locale e il numero di
porta, lindirizzo destinatario e la sua porta e lo stato della connessione.
Netstat si usa per capire la performance di un host quando qualcosa
sembra non andare bene.

TCP and UDP segmentation: segmentazione di TCP e UDP: ogni

header di un segmento TCP contiene una sequenza di numeri che
permettono al transport layer di destinazione di riassemblare i segmenti
nello stesso ordine in cui sono stati trasmessi. I servizi che usano UDP
tengono traccia delle conversazioni tra le applicazioni (che non significa
che tengono traccia dellordine dei segmenti o si assicurano di
mantenere la comunicazione), non c un numero di sequenza
nellheader UDP, quindi un protocollo che permette di trasferire dati in
maniera pi veloce. In questo caso alcuni segmenti arrivano in ordine sparso, lapplicazione
deve poter sopportare questi piccoli errori.

TCP and UDP 7.2: la chiave di distinzione tra TCP e UDP e laffidabilit.
TCP Server Processes: un solo server pu gestire svariate applicazioni simultaneamente,
questi processi attendono sino a che un client non inizia la comunicazione tramite una richiesta
di informazioni o altri servizi. Ogni processo del server configurato per usare una port
number, sia di default che scelta da amministratore. Un server non pu avere due tipologie di
servizi assegnati ad una sola porta. Le richieste socket che provengono da un client sono
accettate quando la porta aperta open, significa che il transport layer accetta e processa i
segmenti indirizzati a quella porta. Ci possono essere svariate porte aperte su un server, una
per ogni tipo di applicazione server. Un modo per aumentare la sicurezza su un server quello
di restringere gli accessi al server alle sole porte associate ai servizi e applicazioni di client
autorizzati.

12

12

TCP connection Establishment and Termination:

Quando due host comunicano usando TCP stabilita una connessione prima che I dati vengano
scambiati. Quando la comunicazione completata la sessione viene chiusa e la connessione
terminata. Sono i meccanismi di connessione e sessione ad abilitare laffidabilit di TCP.
Gli host tengono traccia di ogni segmento allinterno della sessione e si scambiano informazioni
circa il data che stato ricevuto usando lintestazione TCP. TCP un protocollo di tipo fullduplex, ogni comunicazione ha due flussi in una sola direzione, dette sessioni. Gli host compino
la three-way handshake stretta di mano , unoperazione in pu step che permette di
stabilire la connessione. I bit di controllo dellintestazione TCP indicano il progresso e lo stato
della connessione. Three-way handshake:

Stabilisce che il dispositivo di destinazione presente in rete.

Verifica che il dispositivo ricevente abbia un servizio attivo e che possa ricevere
richieste sulla port number necessaria al mittente.

Informa il dispositivo di destinazione che il client sorgente intende stabilire una

connessione su quella port number.

Nelle connessioni TCP lhost client stabilisce la connessione con il server, tre passaggi:

1. Il client chiede una sessione di comunicazione di tipo client-to-server al server.

2. Il server risponde con un ACK alla richiesta di clent-to-server e richiede una
sessione di comunicazione di tipo server-to-client.
3. Il client manda un ACK al server per la sessione server-to-client.

Per capire il processo three-way handshake bisogna guardare ai vari valori che si scambiano gli
host. Allinterno dellheader di un segmento TCP ci sono sei campi a 1 bit che contengono
informazioni di controllo per amministrare TCP:

URG: Urgent pointer field significant

ACK: Acknowledgement field significant

PSH: Push function

RST: Reset the connection

SYN: Synchronize sequence numbers

FIN: No more data from sender.

I campi ACK e SYN sono rilevanti per lanalisi del three-way handshake.
Step1: il client inizia una richiesta di tipo client-to-server con il
server: un client TCP inizia la sessione di three-way handshake
spedendo un segmento con controllo SYN (Synchronize sequence
number numero di sequenza sincronizzato)al server, che indica un
valore iniziale nel campo di numero di sequenza dellheader. Questo
valore iniziale per il numero di sequenza si chiama ISN (initial
sequence number), ed scelto casualmente e usato per iniziare a
tracciare il data dal client al server. LISN contenuto nellheader di
ogni segmento incrementato di uno per ogni byte spedito dal client
al server durante tutta la conversazione. Nella figura vediamo loutput
di un programma di tipo protocol analyzer per il SYN: possiamo
vedere la control flag del SYN settata e il relativo numero di sequenza
a 0. I valori veri sono quelli a 32 bit, la figura rappresenta i 4 byte in esadecimale.

Step 2: il server manda un ACK per la sessione client-to-server e

richiede una sessione server-to-client: il server TCP deve comunicare
lavvenuta ricezione del segmento SYN proveniente dal client per poter
stabilire la sessione client-to-server. Per farlo il server manda un
segmento indietro al client con la flag di ACK indicante che il numero di
acknowledgement significativo. Con questo flag settato nel segmento,
il client riconosce che il server ha ricevuto il SYN dal client TCP. Il valore
dellacknowledgement number field (il campo del numero di ACK)
uguale all ISN + 1, questo valore stabilisce una sessione dal client al
server. La flag di ACK rimane settata per il bilanciamento della sessione.
Ricordando che attualmente si ha una conversazione di tipo two-way, una dal client al server e
laltra dal server al client, in questo secondo step della three-way handshake il server deve
iniziare la risposta al client. Per inizializzare questa sessione il server usa la SYN flag alla stessa
maniera in cui lha usata il client, setta la SYN control flag nellheader per stabilire una sessione
dal server al client. La SYN flag indica che il valore iniziale del campo sequence number field si

12

trova nellheader e questo valore usato per monitorare il flusso dei dati tra server e client
della sessione.
Step 3: il client riconosce la sessione di tipo server-to-client.: infine, il
client TCP risponde con un segmento contenente un ACK che la
risposta al SYN spedito dal server. Non c user data nel segmento, il
valore presente nel campo di number acknowledgement contiene un
valore in pi nell ISN ricevuto dal server. Dopo che entrambe le sessioni
sono state stabilite tra client e server, tutti i segmenti scambiati in
questa comunicazione avranno un flag di ACK settato.
NOTA: pu essere aggiunta delle sicurezza alla rete dati negando la
possibilit di stabilire delle sessioni TCP, permettendo solamente sessioni
per specifici servizi, permettendo solamente il fluire del traffico come parte di sessioni
precedentemente stabilite.

TCP Session Termination Analysis: per chiudere una connessione

occorre settare il flag di controllo FIN (Finish) nellheader del
segmento. Per chiudere una comunicazione TCP di tipo one-way,
occore usare una two-way handshake che consiste nellutilizzo di un
segmento di FIN e di uno di ACK. Pertanto, per terminare una singola
conversazione di TCP sono necessari quattro scambi per terminare le
due sessioni.
Step1: quando il client ha finito i dati da inoltrare nel flusso, invia
un segmento che contiene il flag FIN.
Step2: il server spedisce un ACK per avvisare di aver ricevuto il FIN
e terminare la sessione da client a server.
Step3: il server manda un FIN al client, per terminare la sessione da server a client.
Step4: Il client risponde con un ACK con cui dice al server di aver ricevuto il FIN.

anche possibile terminare una connessione con una three-way handshake, quando il client ha
terminato i dati manda un FIN al server; se anche il server non ha pi dati da spedire pu
rispondere sia con un FIN che con un ACK, combinando due passaggi in uno. Il client quindi
risponde con un ACK.

Reliability e Flow Control: durante il setup della sessione viene

assegnato un numero iniziale di sequenza ISN, lISN rappresenta il

12

valore di partenza per i byte di questa sessione. Quando i dati sono trasmessi durante la
sessione, il numero della sequenza incrementato con il numero di byte che sono stati
trasmessi. Questa maniera di tracciare il segmento in base ai byte rende unico il pacchetto, i
pacchetti mancanti possono quindi essere identificati. I numeri di sequenza dei segmenti
indicano come riassemblare e riordinare i segmenti ricevuti, questo processo identificato
come reliability.

Confirming Receipt of Segments: una delle funzioni di TCP

assicurare che i pacchetti giungano a destinazione tramite ACK. Il
SEQ, numero di sequenza e lACK sono usati assieme per confermare
la ricezione dei byte nei segmenti. Il numero di SEQ indica il
numero di byte che sono stati trasmessi in questa sessione,
includendo i byte del segmento corrente. TCP usa rispedire il
numero di ACK al mittente per indicare il prossimo byte che il
ricevente si aspetta di ricevere, questo processo si chiama
expectational acknowledgement (ACK di prospettiva). Il mittente
viene informato che il destinatario ha ricevuto tutti i byte di quel
flusso dati, senza includere per il byte che contiene il numero di ACK. Lhost mittente dovr
spedire un segmento che usa un sequence number uguale allACK number. In questo esempio,
se il mittente deve attendere lACK ogni 10 byte spediti, la rete avr un gran sovraccarico. Per
ridurre il sovraccarico creato dagli ACK si pu spedire un singolo ACK per pi segmenti. Questo
ACK contiene un numero che uguale ai byte ricevuti. Esempio, per una sequenza che inizia
con il numero 2000, se sono stati ricevuti 10 segmenti da 1000 byte ciascuno, avremo un ACK
di 12001.
NOTA: window size: lammontare dei dati che un mittente pu trasmettere prima di ricevere
un ACK. La window size abilita lamministrazione della perdita dei dati e del flow control.
Handling Segment Loss: se si perdono uno o pi segmenti, solo il data nella prima contigua
sequenza di byte ha un acknoledge. Es: se sono stati ricevuti i segmenti con sequenza
numerica 1550 a 3000 e 3400 a 3500, il numero di ACK sar 3001. Questo perch ci sono
segmenti con un numero di sequenza dal 3001 al 3399 che non sono stati ricevuti. Se il
mittente non riceve un ACK in un determinato periodo di tempo, ritorna allultimo ACK ricevuto
e ritrasmette il dato. Il processo della ritrasmissione non viene descritto nel documento RFC.
Lhost ritrasmette il segmento, inserisce una copia del segmento in una coda di ritrasmissione
e fa partire un timer. Quando lACK ricevuto il segmento eliminato dalla coda, se lACK non
viene ricevuto prima che scada il tempo il segmento di nuovo ritrasmesso. Gli host oggigiorno
usano anche un particolare processo, il SACKs (selective acknowledgements). Se entrambi gli
host supportano il SACKs possibile per il destinatario mandare un ACK per segmenti
discontinui, in tale maniera solo i dati mancanti verranno ritrasmessi.

TCP Flow Control, Window Size e Acknowledgements: TCP

amministra anche il Flow Control (controllo del flusso), che aiuta a
mantenere laffidabilit della trasmissione TCP aggiustando il tasso
del flusso dei dati tra mittente e destinatario. Flow Control limita
lammontare dei segmenti inoltrati richiedendo un ACK al
destinatario prima di inviarne ulteriormente. Lheader TCP include
un campo a 16 bit chiamato window size, la window size iniziale
concordata da mittente e destinatario durante la sessione di
startup della three-way handshake, una volta concordata, il
mittente limita lammontare dei dati inviabili basandosi sulla

12

window size. Durante il ritardo che si crea nellattesa dellACK, il mittente non spedisce nessun
pacchetto, e nei momenti in cui la rete congestionata il ritardo pu aumentare, quindi il reale
tasso di trasmissione per la sessione diminuisce. Il rallentamento dei dati aiuta a mitigare i
conflitti sulla rete. TCP usa la window size per amministrare il tasso di trasmissione alla
massima velocit sostenibile dalla rete e dal ricevente mentre tenta di minimizzare la perdita di
dati e la necessit di ritrasmetterli.

TCP Flow Control Congestion Avoidance: un altro modo per

controllare il fluire dei dati usare la window size dinamica;
quando le risorse di rete sono sovraccariche, TCP reduce la window
size per fare in modo che i segmenti debbano ricevere ACK pi
frequentemente. Questo processo rallenta il tasso di trasmissione
perch il mittente deve aspettare un ACK con pi frequenza. Il
ricevente manda il valore di window size al mittente per indicare il
numero di byte che preparato a ricevere, se la destinazione deve
rallentare il flusso spedisce un valore di window size pi piccolo
inserito in un ACK. Nella figura, il ricevente congestionato e
risponde al mittente con un segmento per diminuire la window size
(per evitare la perdita di dati). Dopo un periodo in cui non si
verificano perdite di segmenti la window size di nuovo incrementata, questo processo che
aumenta e decrementa dinamicaente la window size si verifica di continuo in TCP.
UDP Low Overhead versus Reliability: UDP un protocollo semplice
e con molti meno controlli di TCP perch non connection-oriented e non
ritrasmette, non sequenzia e non controlla il flusso dei dati. Ci non
significa che le applicazioni che usano UDP siano sempre inaffidabili e
che UDP un protocollo inferiore, semplicemente le funzioni aggiuntive
non sono svolte da UDP ma possono essere implementate da altri
protocolli. Il traffico UDP relativamente basso, applicazioni che usano
UDP:

DNS

SNMP (Simple Network Management Protocol)

DHCP

RIP (Routing Information Protocol)

TFTP (Trivial File Transfer Protocol)

VoIP

Online Games

Alcune applicazioni come il gioco online e il VoIP possono tollerare una piccola perdita dei dati,
se queste applicazioni usassero TCP avrebbero enormi ritardi a causa delle tante ritrasmissioni.
Altre applicazioni, come il DNS, reinoltrano la richiesta se non ricevono risposta, quindi non
hanno necessit del TCP per avere una consegna garantita.

UDP Datagram Reassembly: siccome UDP connectionless, cio le

sessioni non sono stabilite prima dellinoltro, UDP chiamato

12

transaction-based, che significa che quando unapplicazione ha un dato da spedire

semplicemente lo spedisce. Molte applicazioni che usano UDP spediscono un piccolo
quantitativo di dati che possono essere contenuti in un solo segmento, altre invece hanno
grandi quantit di dati da spedire e devono essere creati tanti pacchetti. Il PDU dellUDP si
chiama datagram. Quando tanti datagrammi sono spediti ad un destinatario, possono
prendere svariati percorsi e giungere nellordine sbagliato. UDP non traccia il numero di
sequenza e non pu riordinare i datagrammi in ordine di trasmissione. Perci UDP riassembla il
data nellordine in cui ha ricevuto i datagrammi e lo passa allapplicazione, sar lapplicazione
a dover identificare la sequenza corretta e determinare come deve essere processato il data.

UDP Server Processes and Requests: come le applicazioni basate su

TCP, anche le applicazioni per UDP hanno delle port-numbers di tipo wellknown o porte registrate. Quando queste applicazioni girano su un server,
accettano i dati sulla porta corrispondente. Quando UDP riceve un
datagram destinato ad una di queste porte, inoltra il datagram
allapplicazione giusta basandosi sulla port number.

UDP Client Processes: processi del Client: come per TCP, anche in
UDP le comunicazioni client-server sono iniziate dallapplicazione del
client che richiede dei dati da un processo server. Il client UDP seleziona
una port number casuale dal range delle porte dinamiche disponibili e la
usa come porta sorgente della conversazione. La porta di destinazione
del processo server una porta di tipo well-known oppure una porta
registrata. Scegliere il numero di porta sorgente ina maniera casuale
incrementa la sicurezza, se esistesse uno schema presumibile si
potrebbero simulare accessi al client cercando di connettersi alle porte
presumibilmente aperte. Dopo che il client ha scelto le porte di sorgente
e destinazione, lo stesso paio di porte usato nellintestazione di tutti i
datagrammi della trasmissione. Per i dati che tornano al client dal server, il numero di porte di
sorgente e destinazione sono invertite.
TCP or UDP, that is the question: si sceglie TCP o UDP a seconda della
necessit dellapplicazione.
TCP: HTTP, FTP, SMTP, Telnet.

UDP si usa per:

Applicazioni che tollerano una piccolo perdita di dati ma non possono

sopportare ritardi.

Applicazioni con operazioni semplici di richiesta e risposta.

Comunicazioni unidirezionali dove non necessaria la reliability o che pu

essere amministrata dalle applicazioni.

12

Molte applicazioni si gestiscono autonomamente la reliability, quindi non hanno bisogno dei
servizi di TCP e si affidano al pi snello UDP: DHCP, DNS (usa sia TCP che UDP), SNMP,TFTP.

12