3 Transporte

Capítulo 3: Camada de Transporte
Objectivos:
❒ Entender os princípios ❒ Aprender os protocolos
subjacentes ao serviço de transporte na
da camada de Internet:
transporte: ❍ UDP: transporte sem
ligação
❍ Multiplexagem/
desmultiplexagem ❍ TCP: transporte com
ligação
❍ Transferência de dados
fiável ❍ Controlo de congestão em
TCP
❍ Controlo de fluxo
❍ Controlo de congestão
Camada de Transporte 3-1
Capítulo 3: Sumário
❒ 3.1 Serviços da camada ❒ 3.5 Transporte com
de transporte ligação: TCP
❒ 3.2 Multiplexagem e ❍ estrutura dos segmentos
desmultiplexagem ❍ transferência de dados
fiável
❒ 3.3 Transporte sem
❍ controlo de fluxo
ligação: UDP
❍ gestão de ligações
❒ 3.4 Princípios de
transmissão de dados
controlo de congestão
fiável
❒ 3.7 Controlo de
congestão em TCP

Serviços de Transporte e Protocolos
❒ Fornece comunicação lógica
entre processos de aplicação a
funcionar em Sistemas

Terminais diferentes
!"!$#%
,-.$-
❒ Os Protocolos de Transporte &' () *
+
T
/)0 1 3 . 2. +(
r
a
,-.$- &' () *+
n
são executados nos Sistemas
s
/)0 1 3 . 2. +(
p
o
r
&' () *
+
t
Terminais
e
ló
,-.$-
g
/ ) 0 1 .32. +(
ic
lado que envia: parte a
o
❍ &' () *+ ,-.$-
e
x
/)0 1 . 2. +(
t
mensagem da aplicação em
r
&' () *
+
e
m
o
-
segmentos, que passa à
a
,-.-
-
e
/)0 1 3 . 2. +(
x
camada de rede
t
&' () *
+
r
e
m
o
❍ lado que recebe: junta os 435$6 7 8439:;
<
= 43>?
5; =<@
segmentos em mensagens, =@A$@
6 7 B C A 4 A ;?
passa à camada de aplicação DE ?7 8;
❒ mais que um protocolo de
transporte disponível para as
aplicações
❍ Internet: TCP e UDP
Camada de Transporte vs. Rede
❒ Camada de Rede:
comunicação lógica entre Sistemas Terminais
❒ Camada de Transporte:
comunicação lógica entre processos
❍ baseia-se, e melhora, os serviços da camada de Rede

Serviços de Transporte e Protocolos
❒ Sistemas Terminais ?
❒ Ex: cartas entre
❒ Processos ?
primos de
❒ Mensagens de aplicação ?
Lisboa e Porto !!!
❒ Protocolo de transporte ?
❒ Protocolo de rede ?
Sistemas Terminais = casas
Processos = primos
Mensagens de aplicação = cartas nos envelopes
Protocolo de transporte = primos que tratam do
correio
Protocolo de rede = serviço postal
Protocolos de Nível de Transporte na Internet
❒ entrega fiável, ordenada,
unicast (TCP)
FGH I JFK
LM
❍ controlo de congestão N
O FPQ
GM ON
R
ORSR
controlo de fluxo
❍ H I T U S F S MQ ORS$R
VW QI J
M
T
H I T U S F S MQ
r
a
estabelecimento da ligação
ORS$R VW QI JM
n
s
❍
p
H I T U S F S MQ
o
r
VW QI J
M
t
entrega não fiável (melhor

e
❒ ORS$R
ló
g
H I T U S F S MQ
ic
o
esforço, best-effort),
VW QI JM ORS$R
e
x
H I T U S F S MQ
t
r
VW QI J
M
e
não ordenada, unicast ou

m
o
-
a
ORSR
-
multicast: UDP
e
H I T U S F S MQ
x
t
VW QI J
M
r
e
m
o
❒ serviços não disponíveis: F3G$H I JF3KLM

N
O F3PQ
GM ONR
❍ tempo real ORS$R
H I T U S F S MQ
VW QI JM
❍ garantias de largura de
banda
❍ multicast fiável

fiável
ligação: UDP
fiável
❒ 3.7 Controlo de
congestão em TCP
Multiplexagem/Desmultiplexagem
Multiplexagem no envio:
Demultiplexagem na recepção:
Recolher dados de diferentes

entregar os segmentos
sockets, delimitar dados com
recebidos ao socket correcto
cabeçalho (mais tarde usado
para desmultiplexar)
= socket = processo
aplicação P3 P1
P1 aplicação P2 P4 aplicação
transporte transporte transporte
rede rede rede
lig. de dados ligação de dados lig. de dados
físico físico físico
máquina 1 máquina 2 máquina 3

Como funciona a desmultiplexagem
❒ máquina recebe datagrama IP
❍ cada datagrama tem 32 bits
endereço IP de origem,
#porto origem #porto destino
endereço IP de destino
❍ cada datagrama leva 1 outros campos
segmento da camada de do
transporte cabeçalho
❍ cada segmento tem números
de porto de origem, destino

Dados da aplicação
(relembre: números de portos
(mensagem)
bem conhecidos para
aplicações específicas)
❒ máquina usa endereços IP e
números de porto para enviar o

Formato do segmento TCP/UDP
segmento para o socket
apropriado
Desmultiplexagem sem ligação
❒ Quando uma máquina

❒ Criam-se sockets com
recebe um segmento
números de portos:
UDP:
DatagramSocket mySocket1 = new
DatagramSocket(9157); ❍ verifica o número do porto
DatagramSocket mySocket2 = new de destino no segmento
DatagramSocket(9158); ❍ envia o segmento UDP para
o socket com esse número

❒ socket UDP identificado por
de porto
dois parâmetros:
❒ datagramas IP com
(endereço IP destino, nº porto destino)
diferentes endereços IP
e/ou portos de origem
enviados para o mesmo
socket

Desmultiplexagem sem ligação (cont)
DatagramSocket serverSocket = new DatagramSocket(6428);
P2 P1
P1
P3
PO: 6428 PO: 6428
PD: 9157 PD: 5775
PO: 9157 PO: 5775
PD: 6428 PD: 6428

cliente cliente
servidor
IP: A IP: B
IP: C
PO: Porto Origem oferece endereço de retorno
Desmultiplexagem com ligação
❒ socket TCP identificado ❒ A máquina servidora
por 4 parâmetros: pode suportar muitos
❍ endereço IP de origem sockets TCP simultâneos:
❍ número de porto de ❍ cada socket identificado
origem pelos seus próprios 4
❍ endereço IP de destino parâmetros
❍ número de porto de ❒ Servidores Web têm
destino sockets diferentes para
❒ máquina que recebe usa cada cliente que se liga
todos os quatro valores ❍ HTTP não persistente terá
para enviar o segmento sockets diferentes para
cada pedido
para o socket
apropriado

Desmultiplexagem com ligação (cont)
P2 P3 P4 P1
P1
PO: 80 PO: 80
PD: 9157 PD: 5775
PO: 9157 PO: 5775
PD: 80 PD: 80
cliente cliente
servidor
IP: A IP: B
IP: C
fiável
ligação: UDP
fiável
❒ 3.7 Controlo de
congestão em TCP

UDP: User Datagram Protocol [RFC 768]
❒ Protocolo de transporte da
Internet cru, sem ornamentos

Porque existe UDP ?
❒ Serviço melhor esforço
❒ sem estabelecimento de
(best effort)
ligação (que adiciona atraso)
❒ Segmentos UDP podem ser:

❒ simples: não há estado da
❍ perdidos ligação no emissor, receptor
❍ entregues fora de ordem à ❒ cabeçalho pequeno do
aplicação segmento
❒ Sem ligação ❒ não há controlo de
❍ sem handshaking entre o congestão: UDP pode
emissor e o receptor UDP transmitir tão depressa
quanto se queira !!
❍ cada segmento UDP é
processado
independentemente dos
demais
UDP: mais
❒ Usualmente utilizado para

32 bits
aplicações com fluxos
multimédia que são:

#porto origem #porto destino
Dimensão,
❍ tolerantes a perdas
em bytes do length checksum
❍ sensíveis ao ritmo segmento
UDP,
❒ Outras utilizações do
incluindo
UDP (Porquê ?): Cabeçalho
❍ DNS Dados da aplicação
❍ SNMP (mensagem)
❒ Transferência fiável sobre
UDP: adicionar a fiabilidade
ao nível da aplicação
Formato do segmento UDP

❍ Recuperação de erros
específica da aplicação!

checksum UDP
Objectivo: detectar erros (e.g., bits trocados) no
segmento transmitido
Receptor:
Emissor:
❒ Calcula o checksum dos
❒ Trata o conteúdo do
segmentos recebidos
segmento como uma
sequência de inteiros de 16 ❒ Verifica se o checksum
bits calculado é igual ao do campo
de checksum
❒ checksum: soma do conteúdo
do segmento (complemento ❍ NÃO erro detectado
para 1 da soma) ❍ SIM não houve erro
❒ Emissor coloca o valor do detectado
checksum no campo de ❍ Mas podem haver erros?
checksum do segmento UDP Mais tarde ..
fiável
ligação: UDP
fiável
❒ 3.7 Controlo de
congestão em TCP

Princípios da transmissão de dados fiável
❒ Importante nas aplicações, transporte, ligação de dados
❒ Faz parte da lista top-10 de assuntos de redes!
serviço fornecido implementação do serviço
❒ As características do canal não fiável determinam a
complexidade do protocolo de transferência de dados fiável.
Transferência de dados fiável: início
rdt_send(): chamado do nível de deliver_data(): chamado

cima, (e.g., aplicação.). Envia dados por rdt para entregar dados
para entrega no nível superior do ao nível superior
receptor
lado do lado do
emissor receptor
udt_send(): chamado por rdt, para rdt_rcv(): chamada quando os
transferir pacotes para o receptor pacotes chegam ao canal no lado
através de um canal não fiável do receptor

Transferência de dados fiável: início
Vamos:
❒ Desenvolver incrementalmente os lados do emissor, receptor
do protocolo de transferência de dados fiável (rdt)
❒ Considerar apenas transferência de dados unidireccional
❍ Mas a informação de controlo flui nas duas direcções
❒ Usar máquinas de estado finitas (FSM) para especificar o
emissor e o receptor
Evento que causa a transição de estado

estado: quando se
Acções a tomar na transição de estado
esperam eventos.
estado
estado
1 eventos
quando neste estado, o 2
próximo estado é acções
unicamente
determinado pelo
próximo evento
Rdt1.0: transferência de dados fiável sobre um canal fiável
❒ Canal que está por baixo é perfeitamente fiável
❍ Não há erros nos bits
❍ Não há perda de pacotes
❒ Máquinas de estados separadas para o emissor e o
receptor
❍ Emissor envia dados para o canal
❍ Receptor lê dados do canal
espera rdt_send(data) espera rdt_rcv(packet)

dados de dados de extract (packet,data)
cima packet = make_pkt(data) baixo deliver_data(data)
udt_send(packet)
emissor receptor

Rdt2.0: canal introduz erros nos bits
❒ Canal que está por baixo pode trocar bits nos pacotes
❍ Relembrar: o checksum UDP detecta erros em bits
❒ Questão: como recuperar dos erros ?
❍ confirmações (acknowledgements, ACKs):
receptor diz, explicitamente, ao emissor que recebeu um pacote
sem erros
❍ confirmações negativas (negative acknowledgements, NAKs):
receptor diz, explicitamente, ao emissor que recebeu um pacote
com erros
❍ emissor retransmite o pacote quando recebe o NAK
❍ Exemplos humanos de utilização de ACKs e NAKs?
❒ Novos mecanismos em rdt2.0 (para além de rdt1.0):

❍ detecção de erros
❍ resposta (feed-back) do receptor:
mensagens de controlo (ACK,NAK) receptor → emissor

rdt2.0: Especificação da Máquina de Estados
rdt_send(data)
Receptor
sndpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
espera espera rdt_rcv(rcvpkt) &&
dados de ACK ou udt_send(sndpkt) corrupt(rcvpkt)
cima NAK
udt_send(NAK)
rdt_rcv(rcvpkt) && isACK(rcvpkt)

espera
Λ
dados de
Emissor
baixo
predicado
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)

rdt2.0: funcionamento sem erros
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
cima NAK
udt_send(NAK)

espera
Λ dados de
baixo
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
deliver_data(data)
udt_send(ACK)
rdt2.0: cenário de erros
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
cima NAK
udt_send(NAK)

espera
Λ dados de
baixo
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
deliver_data(data)
udt_send(ACK)

rdt2.0 tem uma falha fatal!
O que acontece se os ACKs
ou os NAKs se
Tratamento de duplicados:
corromperem?
❒ Emissor acrescenta número
❒ O emissor não sabe o que
de sequência a cada pacote
aconteceu no receptor!
❒ Emissor retransmite o pacote

❒ A simples retransmissão pode
ocasionar pacotes duplicados corrente se o ACK/NAK se
corromper
O que fazer?
❒ Receptor descarta pacotes
❒ Emissor envia ACKs/NAKs duplicados (não os entrega ao

referentes aos ACK/NAK do
nível superior).
receptor ?
❍ O que acontece se os
parar e esperar
ACKs/NAKs do emissor se stop and wait
perderem ? Emissor envia um pacote e
❒ Retransmite-se! espera pela resposta do
❍ Podem ser retransmitidos receptor
pacotes correctamente
Camada de Transporte
recebidos
3-27
rdt2.1: emissor, trata ACK/NAKs corrompidos
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt) rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
espera espera isNAK(rcvpkt) )
dados 0 ACK ou
de cima udt_send(sndpkt)
NAK 0
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt) && notcorrupt(rcvpkt)
&& isACK(rcvpkt)
Λ
Λ
espera espera
ACK ou dados 1
rdt_rcv(rcvpkt) && NAK 1 de cima
isNAK(rcvpkt) ) rdt_send(data)
udt_send(sndpkt) sndpkt = make_pkt(1, data, checksum)

udt_send(sndpkt)

rdt2.1: receptor, trata ACK/NAKs corrompidos
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

&& has_seq0(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && corrupt(rcvpkt) rdt_rcv(rcvpkt) && corrupt(rcvpkt)
sndpkt = make_pkt(NAK, chksum) sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
espera espera
dados 0 dados 1
rdt_rcv(rcvpkt) && de baixo rdt_rcv(rcvpkt) &&
de baixo
not corrupt(rcvpkt) && not corrupt(rcvpkt) &&
has_seq1(rcvpkt) has_seq0(rcvpkt)
sndpkt = make_pkt(ACK, chksum) sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
&& has_seq1(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt2.1: discussão
Emissor: Receptor:
❒ Nº de sequência adicionado ❒ Tem de verificar se

a cada pacote
recebeu pacotes
Dois nºs de sequência (0,1)
duplicados
❒
são suficientes
❍ o estado indica se se
❍ Porquê ?
espera um pacote com o
❒ Tem de verificar se os
nº de sequência 0 ou 1.
ACKs/NAKs recebidos
❒ nota: receptor não
estão corrompidos
pode saber se o último

❒ O dobro do nº de estados
❍ O estado tem de se ACK/NAK chegou
lembrar se o pacote correctamente ao

corrente tem o nº de
emissor
sequência 0 ou 1.

rdt2.2: um protocolo livre de NAKs
❒ a mesma funcionalidade de rdt2.1, usando apenas ACKs
❒ em vez de NAK, receptor envia ACK referente ao último
pacote correctamente recebido
❍ receptor tem de incluir, explicitamente, o nº de sequência do
pacote a ser confirmado, isto é, ACKed
❒ ACKs duplicados no emissor resultam na mesma acção
que um NAK: retransmissão do pacote corrente
rdt2.2: fragmentos do emissor, receptor
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt) rdt_rcv(rcvpkt) &&
espera espera
dados 0 de ACK isACK(rcvpkt,1) )
cima 0 udt_send(sndpkt)
fragmento
do emissor rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && && isACK(rcvpkt,0)
(corrupt(rcvpkt) || Λ
fragmento
has_seq1(rcvpkt)) espera
dados 0
udt_send(sndpkt) de baixo do receptor

&& has_seq1(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK1, chksum)
udt_send(sndpkt) Camada de Transporte 3-32
rdt3.0: canais com erros e perdas
Novos pressupostos: Aproximação: emissor espera
canal que está por baixo uma quantidade de tempo
também pode perder razoável por um ACK
pacotes (dados ou ACKs) ❒ retransmite se o ACK não for
recebido nesse tempo

❍ checksum, nºseq., ACKs,
❒ Se o pacote de dados (ou o ACK)
retransmissões ajudam,
se tiver atrasado (mas não
mas não são suficientes
perdido):
Q: como lidar com as ❍ Retransmissão será duplicada,
mas a utilização de nº de seq.

perdas?
trata disso
❍ Emissor espera até ter a
❍ Receptor tem de especificar o
certeza que os dados ou o
nº de seq. do pacote que está a
ACK se perdeu, depois
ser confirmado (ACKed)
retransmite
❒ Necessário um temporizador
❍ desvantagens? descendente (countdown timer)
rdt3.0: emissor
rdt_send(data)
rdt_rcv(rcvpkt) &&
sndpkt = make_pkt(0, data, checksum) ( corrupt(rcvpkt) ||
udt_send(sndpkt) isACK(rcvpkt,1) )
rdt_rcv(rcvpkt) start_timer Λ
Λ espera espera timeout
dados 0 de ACK0 udt_send(sndpkt)
cima
start_timer
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt,1) && notcorrupt(rcvpkt)
stop_timer && isACK(rcvpkt,0)
stop_timer
espera espera
timeout dados 1 de
udt_send(sndpkt) ACK1
cima
start_timer rdt_rcv(rcvpkt)
rdt_send(data) Λ
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) || sndpkt = make_pkt(1, data, checksum)
isACK(rcvpkt,0) ) udt_send(sndpkt)
start_timer
Λ

rdt3.0: em acção
emissor receptor
emissor receptor
funcionamento sem perdas
pacote perdido
rdt3.0: em acção
emissor receptor emissor receptor
ACK perdido temporizador expira

prematuramente

Desempenho de rdt3.0
❒ rdt3.0 funciona, mas o desempenhoL
❒ exemplo:
❍ Ligação = 1 Gbps
❍ Tempo de propagação extremo-a-extremo = 15 ms
❍ Pacote = 1KB
L (tamanho pacote em bits) 8Kb/pkt

T = = = 8 µseg
transmissão 10**9 bit/sec
R (ritmo de transmissão, bps)
L / R . 008
U = = = 0.00027
emissor
30.008
RTT + L / R microsec
onds
❍ U emissor
: utilização ou eficiência fracção do tempo que o emissor
está ocupado a enviar
❍ 1KB (pkt) cada 30 mseg -> débito de 33KB/seg numa ligação 1 Gbps
❍ o protocolo de comunicação limita o uso dos recursos físicos!

rdt3.0: funcionamento do stop-and-wait
emissor receptor
primeiro bit do pacote transmitido, t = 0
último bit do pacote transmitido, t = L / R
primeiro bit do pacote chega

RTT último bit chega, envia ACK
duração do ACK e tempo

ACK chega, enviar o próximo
de processamento
pacote, t = RTT + L / R
desprezados
L / R . 008
U = = = 0.00027
emissor
30.008
RTT + L / R microsec
onds

Protocolos em pipeline
Pipeline: o emissor permite múltiplos pacotes, ainda
não confirmados, a-caminho
❍ Intervalo dos números de sequência tem de aumentar
❍ Armazenamento no emissor e/ou receptor
um protocolo stop-and-wait em funcionamento um protocolo com pipeline em funcionamento
❒ Duas formas genéricas de protocolos em pipeline:
❍ voltar atrás N, (go-Back-N)
❍ repetição selectiva, (selective repeat)
Pipelining: utilização melhorada
emissor receptor
primeiro bit transmitido, t = 0
último bit transmitido, t = L / R
primeiro bit do pacote chega

RTT último bit do pacote chega, envia ACK
último bit do 2º pacote chega, envia ACK
último bit do 3º pacote chega, envia ACK
ACK chega, enviar o próximo
pacote, t = RTT + L / R
Aumenta utilização por
um factor de 3!
3 * L / R .024
U = = = 0.0008
emissor
30.008
RTT + L / R microsecon
ds

Voltar Atrás N (Go-Back-N)
Emissor:
❒ Cabeçalho do pacote com k bits para o nº de seq.
❒ janela de até N pacotes consecutivos, ainda não confirmados.
❒ ACK(n): confirma todos os pacotes até o nº de seq. n
❍ ACK cumulativo
❍ podem ser recebidos ACKs duplicados (ver receptor)
❒ temporizador único para o pacote mais antigo por confirmar
❒ timeout(n): retransmite pacote n e todos os pacotes de nº de seq.
superior na janela. Camada de Transporte 3-41
GBN: máquina de estados estendida do emissor

rdt_send(data)
if (nextseqnum < base+N) {
sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum)
udt_send(sndpkt[nextseqnum])
if (base == nextseqnum)
start_timer
nextseqnum++
}
Λ else
refuse_data(data)
base=1
nextseqnum=1
timeout
start_timer
Espera
udt_send(sndpkt[base])
rdt_rcv(rcvpkt) udt_send(sndpkt[base+1])
&& corrupt(rcvpkt) …
udt_send(sndpkt[nextseqnum-1])
Λ
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
base = getacknum(rcvpkt)+1
assume-se que não há ACKs
If (base == nextseqnum)
fora de ordem.
stop_timer
start_timer cancela e volta
else
a armar.
start_timer Camada de Transporte 3-42
GBN: máquina de estados estendida do receptor
default
udt_send(sndpkt) rdt_rcv(rcvpkt)
&& notcurrupt(rcvpkt)
Λ && hasseqnum(rcvpkt,expectedseqnum)
expectedseqnum=1 Wait extract(rcvpkt,data)
sndpkt = deliver_data(data)
make_pkt(0,ACK,chksum) sndpkt = make_pkt(expectedseqnum,ACK,chksum)
udt_send(sndpkt)
expectedseqnum++
Receptor simples:
❒ ACK: envia sempre ACK com o nº de sequência mais elevado
para os pacotes correcta e ordenadamente recebidos
❍ pode gerar ACKs duplicados
❍ só tem de recordar o nº de seq. esperado: expectedseqnum

❒ Pacotes fora de ordem:
❍ descartar (não armazenar) -> não há armazenamento no receptor!
❍ reconfirma o último pacote que chegou na ordem
GBN em
emissor receptor
acção

Repetição Selectiva
❒ Receptor faz o ACK individual de todos os pacotes
correctamente recebidos
❍ armazena pacotes, quando necessário, para os poder entregar
por ordem ao nível superior
❒ Emissor apenas reenvia pacotes para os quais o ACK
não tenha sido recebido.
❍ temporizador no emissor para cada pacote por confirmar
❒ Janela do emissor
❍ N números de sequência consecutivos
❍ novamente limita os números de sequência dos pacotes
enviados, por confirmar
Repetição selectiva: janela do emissor e receptor
visão dos números de sequência no emissor
visão dos números de sequência no receptor

Repetição selectiva
Emissor Receptor
Dados para enviar : Pacote n ∈ [rcvbase, rcvbase+N-1]
❒ se o próximo nº de seq. ❒ envia ACK(n)

disponível cabe na janela,
❒ fora de ordem: armazena
envia o pacote
❒ Por ordem:
Temporizador(n) expirou:
❍ entrega (também entrega os
❒ reenvia pacote n, reinicia o
pacotes armazenados que
temporizador
tenha na ordem)
ACK(n) ∈ [sendbase,sendbase+N]: ❍ avança a janela para o
❒ marca pacote n como próximo pacote ainda não
confirmado recebido
❒ se n é o pacote mais antigo Pacote n ∈ [rcvbase-N, rcvbase-1]
por confirmar, avança a

❒ ACK(n)
base da janela para o
próximo pacote por Doutro modo:

confirmar
❒ ignora
Repetição selectiva : em acção

Repetição selectiva:
dilema
Exemplo:
❒ Nºs seq : 0, 1, 2, 3
❒ Dimensão da janela =3
❒ o receptor não vê
diferenças nos dois
cenários!
❒ Dados duplicados são
passados
incorrectamente como
novos em (a)
Q: qual a relação entre o
número de nºs de seq.
disponíveis e a
dimensão da janela ?
fiável
ligação: UDP
fiável
❒ 3.7 Controlo de
congestão em TCP

TCP: Visão geral RFCs: 793, 1122, 1323, 2018, 2581
❒ Ponto-a-ponto: ❒ Transmissão full duplex:
Transmissão de dados
um emissor, um receptor
❍ ❍
bidireccional na mesma ligação
❒ Fluxo de bytes ordenado e fiável:

❍ MSS: maximum segment size
não há delimitação de
Orientado à ligação:
❍ ❒
mensagens
❍ handshaking (transferência de
❒ pipelined: mensagens de controlo) inicia o
estado do emissor e do
❍ dimensão da janela definida
receptor antes de transferir
pelo controlo de congestão e
dados
de fluxo do TCP
❒ Controlo de fluxo:
❒ Buffers no emissor e receptor
❍ Emissor não sobrecarrega o
receptor
Aplicação Aplicação
Escrita de dados Leitura de dados
interface interface
socket socket
TCP TCP
Buffer de envio Buffer de recepção
Camada de Transporte
segmento
3-51
TCP: estrutura do segmento
32 bits
# porto origem # porto destino

❒ Nº de sequência e Nº de ACKS:
❍ Contagem por bytes de dados Número sequência
Não segmentos !
Número acknowledgment
❍
❒ Head Length em palavras de 32 bits head not

UA P R S F rcvr window size
len used
❍ Dimensão sem extensões 20 Bytes
checksum ptr urgent data
❒ RCVR Window Size:
Nº de Bytes que o receptor espera

❍ Opções (dimensão variável)
receber
❒ Opções:
❍ Negociação de parâmetros dados da
MSS (usual 1500; 536; 512 Bytes) aplicação
Factor de escala p/ janela em (dimensão variável)

ligações de alto débito

TCP: estrutura do segmento
32 bits
# porto origem # porto destino

❒ Flags de sinalização de informação
urgente: Número sequência
U URG: dados que o nível superior do

Número acknowledgment
❍
emissor sinalizou como urgentes
head not
P PSH: O receptor deve passar os
UA P R S F rcvr window size
❍ len used
dados para o nível superior imediata/

checksum ptr urgent data
❒ Flags de controlo
❍ A ACK: valor válido no campo ACK Opções (dimensão variável)
❍ R- RST; S- SYN; F FIN:
estabelecimento e terminação da
ligação
dados da
❒ Ptr Urgent data
aplicação
Apontador para o último byte de dados
(dimensão variável)
❍
que contém dados urgentes
TCP: nº de sequência e ACK
Números de Sequência:
máquina A máquina B
❍ Nº do primeiro byte
de dados no segmento Utilizador Seq=4

2, AC
digita
ACKs:
K=79,
data
C
= ‘C’
❍ Nº de seq. do próximo
byte esperado do máquina

C ’
outro lado ta = ‘ recebe C e
K=43, da
e ecoa de volta
C
❍ ACK cumulativo: 79, A
Seq=
o C
confirma a recepção
correcta dos bytes máquina
anteriores confirma (ACK)

Seq=4
o eco de C
3, ACK
Q: Como é que o receptor =80
processa segmentos fora
de ordem ?
❍ R: A especificação tempo
TCP não é clara, Cenário simples de Telnet
deixando esta questão
para a implementação
TCP: Round Trip Time e Timeout
Q: como definir a Q: como estimar o RTT?
duração do ❒ SampleRTT: tempo medido desde
a transmissão de um segmento
temporizador do
até à recepção do seu ACK
TCP?
❍ não considera retransmissões
❒ maior que o RTT
❒ SampleRTT vai variar, quer-se
❍ mas o RTT varia
uma estimativa do RTT com
❒ demasiado curto: expira
variações suaves
prematuramente
❍ fazer a média de várias
❍ retransmissões
medidas recentes, não apenas
desnecessárias
o SampleRTT actual
❒ demasiado longo:
reacção lenta a perdas
de segmentos
EstimatedRTT = (1- α)*EstimatedRTT + α*SampleRTT
❒ média móvel de peso exponencial (exponential weighted
moving average)
❒ influência de uma amostra passada decresce com
rapidez exponencial
❒ valor típico: α = 0.125

Exemplo de estimativa do RTT:
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
350
300
250
RTT (milliseconds)
200
150
100
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)
SampleRTT Estimated RTT
Definir a duração do temporizador ( timeout)
❒ EstimatedRTT mais margem de segurança
❍ grande variação no EstimatedRTT -> maior margem de segurança
❒ primeiro estimar quanto é que as amostras SampleRTT se desviam
do EstimatedRTT:
β)*DevRTT +
DevRTT = (1-β
β*|SampleRTT-EstimatedRTT|
(tipicamente, β = 0.25)
Definir a duração do temporizador como:
TimeoutInterval = EstimatedRTT + 4*DevRTT

fiável
ligação: UDP
fiável
❒ 3.7 Controlo de
congestão em TCP
TCP: transferência de dados fiável
❒ O TCP cria um serviço ❒ Retransmissões
de transmissão de desencadeadas por:
dados fiável (rdt) por ❍ eventos de temporizador
cima do serviço não expirar
fiável do IP ❍ ACKs duplicados
❒ Transmissão de ❒ Considere-se inicialmente
segmentos com um emissor TCP
pipeline simplificado:
ignora ACKs duplicados

ACKs cumulativos
❍
❒
❍ ignora controlo de fluxo,
❒ O TCP usa um único
temporizador de
retransmissão

TCP: eventos do emissor
dados recebidos da aplicação: temporizador expira:
❒ Cria segmento com nº de ❒ retransmitir o segmento
sequência cujo tempo expirou
❒ Nº seq. é o nº do primeiro ❒ rearmar o temporizador
byte de dados no segmento ACK recebido:
❒ Arma o temporizador, se Se confirma segmentos

❒
não estiver já armado (o por confirmar
temporizador é para o mais
❍ actualizar o que foi
antigo segmento por confirmado
confirmar) ❍ armar temporizador se
houver segmentos por

❒ duração do temporizador:
confirmar
TimeOutInterval
NextSeqNum = InitialSeqNum
emissor
SendBase = InitialSeqNum
loop (forever) {
TCP
switch(event)
(simplificado)
event: data received from application above
create TCP segment with sequence number NextSeqNum
if (timer currently not running)
start timer
Comentário:
pass segment to IP
NextSeqNum = NextSeqNum + length(data)
SendBase-1:
último byte
event: timer timeout
confirmado
retransmit not-yet-acknowledged segment with
smallest sequence number cumulativamente
start timer Exemplo:
SendBase-1 = 71;
event: ACK received, with ACK field value of y y= 73, pelo que o
receptor quer 73+ ;

if (y > SendBase) {
SendBase = y
y > SendBase, pelo
if (there are currently not-yet-acknowledged segments)
que houve
start timer
confirmação de
}
alguns dados
} /* end of loop forever */

TCP: cenários de retransmissão
Máquina A Máquina B Máquina A Máquina B
Seq=9 Seq=9
2, 8 b 2, 8 b
ytes d ytes d
ata Seq= ata
Seq=92 timeout
100,
20 by
tes d
timeout
ata
=100
ACK
00
X K=1 120
AC ACK=
perda
Seq=9 Seq=9
2, 8 b
2, 8 b
ytes d Sendbase ytes d
ata ata
= 100
Seq=92 timeout
SendBase
= 120 20
K=1
=100 AC
ACK
SendBase
SendBase
= 100
= 120
timeout prematuro
tempo
tempo
cenário de ACK perdido
TCP: cenários de retransmissão (mais)
Máquina A Máquina B
Seq=9
2, 8 b
ytes d
ata
=100
timeout
Seq=1 ACK
00, 20
bytes
data
X
perda
SendBase =120
ACK
= 120
tempo
cenário de ACK cumulativo

TCP: geração de ACKs [RFC 1122, RFC 2581]
Evento Acção no receptor TCP

Chegada de segmento na ordem, ACK atrasado. Espera máxima de
com nº sequência esperado. 500 ms pelo próximo segmento. Se não
Tudo para trás já confirmado chega o próximo segmento, envia ACK
Chegada de segmento na ordem, Envia imediatamente um único ACK

com nº sequência esperado. cumulativo, referente a todos os
Um segmento por confirmar. segmentos que chegaram na ordem
Chegada de segmento fora de Envia ACK duplicado, indicando o nº de

ordem com nº de seq. superior ao seq. do próximo byte esperado
esperado. Buraco detectado
Chegada de segmento que Envia ACK imediato se o segmento

preenche completa ou começa no limite inferior do “buraco”
incompletamente o buraco
Retransmissão Rápida (Fast Retransmit)
❒ Duração do temporizador ❒ Se o emissor recebe 3
(timeout) normalmente ACKs para os mesmos
longa: dados, supõe que o
❍ atraso longo antes de segmento depois dos
reenviar o pacote perdido dados confirmados foi
❒ Detectar segmentos perdido:
perdidos via ACKs ❍ fast retransmit: reenvia
duplicados. o segmento antes que o
temporizador expire
❍ Emissor frequentemente
envia muitos segmentos
seguidos
❍ Se um segmento é perdido,
provavelmente haverá
muitos ACKs duplicados.

Algoritmo Fast Retransmit
event: ACK received, with ACK field value of y

if (y > SendBase) {
SendBase = y
if (there are currently not-yet-acknowledged segments)
start timer
}
else {
increment count of dup ACKs received for y
if (count of dup ACKs received for y = 3) {
resend segment with sequence number y
}
um ACK duplicado para

fast retransmit
um segmento já confirmado
fiável
ligação: UDP
fiável
❒ 3.7 Controlo de
congestão em TCP

TCP: Controlo de fluxo
Controlo de fluxo
emissor não
❒ o lado receptor da
sobrecarrega o receptor
ligação TCP tem um
por transmitir
buffer de recepção: demasiado depressa
❒ serviço de adaptação
de velocidade: adapta
o ritmo de envio à taxa
de processamento de
dados da aplicação
❒ o processo de aplicação
pode ser lento a ler
dados do buffer
Controlo de fluxo: como funciona
❒ O receptor anuncia o
espaço livre incluindo o
valor de RcvWindow
nos segmentos
❒ O emissor limita os
(Suponha que o receptor TCP dados por confirmar a
descarta segmentos fora RcvWindow
de ordem)
❍ garante que o buffer de
❒ espaço livre no buffer recepção não transborda
= RcvWindow ❒ Quando RcvWindow = 0,

o emissor envia segmentos
= RcvBuffer-[LastByteRcvd -
de 1 byte para obrigar o
LastByteRead]
receptor a responder

fiável
ligação: UDP
fiável
❒ 3.7 Controlo de
congestão em TCP
TCP: Gestão das ligações
❒ Cliente: Inicia a ligação
Recordar: O emissor TCP socket_fd=socket(Domínio, Tipo, 0)

estabelece uma ligação
connect(socket_fd,estr_ender,dim_estr_ender)
antes de iniciar a troca de

Domínio =PF_INET(comunicação entre STs IPv4)
segmentos de dados Tipo = SOCK_STREAM (TCP) ou SOCK_DGRAM (UDP)
❒ Iniciação das variáveis estr_ender = domínio; porto; end IP destino
TCP:
Nº de sequência
Servidor: contactado pelo cliente
❍ ❒
❍ Buffers socket_fd=socket(Domínio, Tipo, 0)
Informação de janela
bind(socket_fd,estr_endereços,dim_estr_ender)
❍
listen (socket_fd, num_lig_em_espera)
de controlo de fluxo
new_fd=accept(socket_fd, estr_endereços, dim)
( RcvWindow)
estr_endereços = domínio; porto; end IP origem

Gestão das ligações: Estabelecimento
Passo 1: Ligação pedida

Passo 2: Ligação concedida
❒ cliente envia segmento SYN =1

❒ servidor recebe o segmento
para o servidor
de controlo SYN, responde
Define o nº de seq. original
com o segmento de controlo
❍
client_isn
SYNACK
❍ Não tem campo de dados ❍ Não tem campo de dados
❍ Servidor reserva buffers
Passo 3: Ligação confirmada ❍ Confirma a recepção do seg.
Ack = client_isn+1
❒ cliente recebe SYNACK, ❍ Define o nº de seq. inicial do
responde com segmento ACK, servidor
que pode conter dados Server_isn
❍ Reserva buffers e variáveis
❍ Confirma a recepção do seg.
Ack = server_isn+1
Gestão das ligações: Estabelecimento
cliente servidor
pedido
Lig
(SYN= ação pedid
1, seq a
Reserva
=clien
t_ isn)
buffers e
variáveis
dida
ã o conce r_isn,
e
Reserva Ligaç seq=serv 1)
buffers e
=1, isn+
(SYN k_client_
variáveis
ac
estabelecimento
Liga
(SYN= ção confirm
0, se ada
ack=s q=client_isn
erver_ +
isn+1) 1,
tempo

Gestão das ligações: Fecho
Fechando uma ligação: cliente servidor
close
o cliente fecha o socket:
FIN
close(socket);
Passo 1: cliente envia

ACK
close
segmento de controlo TCP
FIN
FIN para o servidor
Passo 2: servidor recebe
timed wait
ACK
FIN, responde com ACK.
Fecha ligação, envia FIN.
fechado
Gestão das ligações: Fecho
Passo 3: cliente recebe FIN, cliente servidor
responde com ACK.

closing
FIN
❍ Entra em timed wait -
responderá com ACK a
FINs recebidos ACK

closing
Passo 4: servidor, recebe

FIN
ACK. Ligação fechada.

timed wait
ACK
Nota: com pequenas
fechado
modificações, pode tratar
FINs simultâneos.
fechado

TCP Gestão das ligações: ciclo de vida
Ciclo de vida do
servidor TCP
Ciclo de vida do cliente TCP
fiável
ligação: UDP
fiável
❒ 3.7 Controlo de
congestão em TCP

Princípios de Controlo de Congestão
Congestão:
❒ Informalmente: demasiadas fontes enviam
demasiada informação a um ritmo muito superior
ao que a rede é capaz de processar
❒ Diferente do controlo de fluxo!
❒ Sintomas:
❍ Perda de pacotes ( buffer overflow nos routers)
❍ Atrasos elevados (espera em fila nos buffers
dos routers)
❒ Problema da lista dos TOP 10!
Causas e custos do controlo de congestão: cenário 1
Emissor A λout
λin : dados originais
❒ dois emissores,
dois receptores
buffers partilhados na
um router, buffers
Emissor B linha de saída infinitos
❒
infinitos
❒ sem retransmissões
❒ atraso elevado
em situação de
congestão
❒ débito máximo
atingível

❒ um router, buffers finitos
❒ emissor retransmite pacotes perdidos
Emissor A λin : dados originais λout
λ'in : dados originais, mais

dados retransmitidos
Emissor B buffers partilhados na

linha de saída finitos
❒ 1 - Situação ideal : λ = λout (goodput)

in
❒ 2 - Retransmissões ocorrem quando há perdas: λ > λout
in
❒ 3 - Retransmissões de pacotes atrasados (não perdidos) faz λ
in
maior para o mesmo λout
1
1 3
2
custos da congestão:
❒ Mais trabalho (retransmissões) para um dado goodput
❒ Retransmissões desnecessárias: linha transporta múltiplas cópias
do pacote Camada de Transporte 3-82

4 emissores
Q: O que acontece
❒
❒ caminho com vários nós
quando λ e λ
timeout/retransmissões
in in
aumentam ?
❒
Emissor A λout
λin : dados originais
λ'in : dados originais, mais
dados retransmitidos
buffers partilhados na
linha de saída finitos
Emissor B
H λ
o
o
s
u
t t
A
H
o
s
t
B
Outro custo da congestão:
❒ Quando um pacote se perde, qualquer capacidade de
transmissão que já tenha sido usada para o
transmitir é perdida!

Abordagens ao controlo de congestão
Dois tipos de abordagens ao controlo de congestão:
Controlo de congestão Controlo de congestão
extremo a extremo: assistido pela rede:
❒ não há feedback explícito ❒ routers fornecem feedback
da rede aos sistemas terminais
❒ congestão inferida pelas ❍ um único bit indica a
perdas e atrasos congestão (SNA,
observadas pelos sistemas DECbit, TCP/IP ECN,
terminais ATM)
❒ aproximação do TCP ❍ envio explícito do ritmo
a que o emissor pode
enviar
Estudo de um caso: Controlo de congestão ATM ABR
ABR: available bit rate: células/pacotes RM ( resource
❒ Serviço elástico management):
❒ Se o caminho do emissor ❒ Enviadas pelo emissor,
não está sobrecarregado: intercaladas com as células de
❍ emissor deve usar a dados
largura de banda ❒ Bits nas células RM activadas
disponível pelos switches (assistido pela
❒ Se o caminho do emissor rede)
está congestionado : ❍ NI bit: No Increase - não
❍ emissor envia apenas aumentar o ritmo (congestão
ao ritmo mínimo moderada)
garantido ❍ CI bit: Congestion Indication -
indicador de congestão
❒ Células RM devolvidas ao emissor
pelo receptor com os bits intactos

Estudo de um caso: Controlo de congestão ATM ABR
❒ campo ER (explicit rate) de 2 bytes numa célula RM
❍ comutador (switch) congestionado pode diminuir o valor de ER da célula
❍ emissor envia ao ritmo mínimo suportado pelo caminho
❒ bit EFCI nas células de dados:
❍ EFCI = 1 indica congestão no switch
❍ se uma célula de dados que precede a célula RM tem o EFCI activo, o
receptor activa o bit CI na célula RM devolvida
❒ Bits CI e NI
❍ Um switch pode activar o bit NI/CI, o qual deverá ser devolvido ao
emissor na próxima célula RM Camada de Transporte 3-87
fiável
ligação: UDP
fiável
❒ 3.7 Controlo de
congestão em TCP

Controlo de Congestão no TCP
❒ Controlo extremo-a-extremo Como o emissor detecta a
(não assistido pela rede) congestão?
❒ emissor limita a transmissão: ❒ evento de perda =
LastByteSent-LastByteAcked timeout ou 3 ACKs
≤ CongWin duplicados
❒ Resumidamente, ❒ emissor TCP reduz ritmo
( CongWin) após evento

CongWin
ritmo = Bytes/seg de perda
RTT
três mecanismos:
❒ CongWin é dinâmico, função
❍ AIMD
da congestão da rede
❍ arranque lento (slow start)
detectada
❍ conservativo após eventos
de timeout
AIMD: Additive-Increase, Multiplicative Decrease
decrescimento multiplicativo: aumento aditivo: aumenta
dividir CongWin a meio após CongWin de 1 MSS cada

evento de perda RTT na ausência de
eventos de perda:
janela de sondagem
congestão
24 Kbytes
16 Kbytes
8 Kbytes
tempo
ligação TCP de longa duração

TCP: Arranque lento (Slow Start)
❒ Quando a ligação começa, ❒ Quando a ligação
CongWin = 1 MSS começa, aumenta o ritmo
❍ Exemplo: MSS = 500 bytes com rapidez exponencial
e RTT = 200 mseg até ao primeiro evento
❍ ritmo inicial = 20 kbps de perda
❒ o ritmo possível pode ser
>> MSS/RTT
❍ vantajoso aumentar
rapidamente o ritmo para
um valor respeitável
TCP: Arranque lento (mais)
❒ Quando a ligação Máquina A Máquina B
começa, aumenta o
ritmo exponencialmente
um segme
nto
RTT
até ao primeiro evento
de perda:
dois segm
entos
❍ duplica CongWin a cada

RTT
quatro seg
❍ feito incrementando mentos
CongWin por cada ACK

recebido
❒ Sumário: o ritmo inicial
é lento, cresce tempo
exponencialmente

Refinamento
Filosofia:
❒ Após 3 ACKs duplicados:
❍ CongWin é reduzida a • 3 ACKs duplicados indica
que a rede é capaz de

metade
entregar alguns segmentos
❍ a janela passa a crescer
timeout antes de 3 ACKs
linearmente
duplicados é mais
❒ Mas após timeout:
alarmante
❍ agora CongWin colocado

a 1 MSS;
❍ a janela passa a crescer
exponencialmente
❍ até um limiar (threshold),
depois cresce
linearmente Camada de Transporte 3-93
Refinamento (mais)
Q: Quando deve o
crescimento
tamanho da janela de congestão
exponencial mudar 14
TCP
para linear? 12 Reno
R: Quando
(segmentos)
10
CongWin
chegar a 1/2 do
8
seu valor antes do

6
4 limiar
timeout.
TCP
2 Tahoe
Implementação:
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
❒ Limiar variável ronda de transmissão
❒ Num evento de perda, o
limiar é colocado a 1/2 de
CongWin antes do evento

❒ TCP Tahoe (antigo): recomeça de 1
de perda após qualquer evento de perda

Sumário: Controlo de Congestão TCP
❒ QuandoCongWin está abaixo do Threshold

(limiar), o emissor está na fase slow-start, a
janela cresce exponencialmente.
❒ Quando CongWin está acima do Threshold, o

emissor está na fase congestion-avoidance, a
janela cresce linearmente.
❒ Quando ocorre um triplo ACK duplicado , o
Threshold é colocado a CongWin/2 e CongWin é

colocado a Threshold.
❒ Quando ocorre um timeout, o Threshold é

colocado a CongWin/2 e CongWin é colocado a 1
MSS.
TCP: Justiça
Objectivo de justiça: se K sessões TCP partilham um
estrangulamento por uma mesma linha de ritmo R,
cada uma deve obter um ritmo médio de R/K
ligação 1 TCP
estrangulamento
TCP
router
ligação 2
capacidade R

Porque é que o TCP é justo ?
Duas sessões em competição:
❒ aumento aditivo origina um declive de 1, quando o débito aumenta
❒ decréscimo multiplicativo decresce débito proporcionalmente
R divisão igual de largura de banda

Débito da ligação 2
perda: decresce janela por um factor de 2
evitar a congestão: aumento aditivo
perda: decresce janela por um factor de 2
evitar a congestão: aumento aditivo
Débito da ligação 1 R
TCP: Justiça (mais)
Justiça e ligações TCP

Justiça e UDP
paralelas
❒ As aplicações multimédia
nada impede as aplicações
normalmente não usam o ❒
de abrir ligações paralelas
TCP
para o mesmo destino.
❍ não querem o ritmo
estrangulado pelo controlo ❒ browsers Web fazem isto

de congestão
❒ Exemplo: linha de ritmo R
❒ Usam UDP:
suportando 9 ligações;
❍ enviam áudio/vídeo a um
❍ nova aplicação pede 1 ligação
ritmo constante, toleram
TCP, obtém ritmo R/10
perdas de pacotes
❍ nova aplicação pede 11
❒ Área de investigação: ligações TCP, obtém mais de
amigo do TCP R/2 !

Modelo da latência do TCP
Notação, pressupostos:
Q: Quanto tempo demora a
❒ Assumindo uma linha entre o
receber um objecto de um cliente e o servidor de ritmo R
servidor Web depois de [bit/seg]
enviar um pedido? ❒ S: MSS tamanho máximo do
segmento [bits]
Ignorando a congestão, a
O: tamanho do objecto [bits]
latência depende de:
❒
❒ cabeçalhos desprezáveis
❒ estabelecimento de ligação TCP
❒ sem retransmissões (sem
❒ tempo de transmissão de dados
perdas, sem corrupção)
❒ arranque lento
Dimensão da janela:
❒ 1º assumir: janela de
congestão fixa, W segmentos
❒ Depois janela dinâmica,
modelando o arranque lento

Janela de congestão fixa (1)
1º caso:
WS/R > RTT + S/R: ACK do
1º segmento da janela
recebido antes de se
esgotar a janela
latência = 2RTT + O/R
W = 4

Janela de congestão fixa (2)
2º caso:
❒ WS/R < RTT + S/R:
espera pelo ACK depois
de esgotar a janela
latência = 2RTT + O/R
+ (K-1)[S/R + RTT - WS/R]
❒ K = nº de janelas de
dados (cada com W
segmentos) que cobrem o

W = 2
objecto completo
Modelo de latência TCP: Arranque Lento (1)
❒ Supondo que a janela cresce de acordo com o Slow-Start.
❒ A latência de um objecto de dimensão O é:
O  S S
Latência = 2 RTT + + P  RTT +  − (2 P − 1)
R  R R
em que P é o nº de vezes que o TCP no servidor pára:
P = min{Q, K − 1}
-em que Q é o nº de vezes que o servidor pára se o objecto tivesse uma
dimensão infinita
-Ké o nº de janelas que cobrem o objecto

Componentes:
inicia ligação
TCP
2 RTT para ligar e
pedido pede
O/R para transmitir
objecto
primeira janela
objecto
= S/R
tempo que o servidor RTT

segunda janela
pára devido ao arranque
= 2S/R
lento
terceira janela
= 4S/R
Servidor pára:
P = min{K-1,Q} vezes
Exemplo:
quarta janela
= 8S/R
O/S = 15 segmentos
K = 4 janelas
Q = 2
P = min{K-1,Q} = 2 transmissão
objecto completa
entregue
Servidor pára P=2 vezes

tempo no
tempo no servidor
cliente
S
+ RTT = Tempo desde que o servidor inicia a transmiss ão do objecto até que recebe o ACK
R inicia ligação
TCP
S
2 k −1 = Tempo para transmitir a janela K
pede
objecto primeira janela
R = S/R
RTT segunda janela

+
S k −1 S 
= 2S/R
 R + RTT − 2 R  = Tempo de
terceira janela
espera após a transmissão da janela K = 4S/R
P quarta janela
O
Latência = + 2 RTT + ∑ TempoParagem p
= 8S/R
R p =1
P
O S S
= + 2 RTT + ∑ [ + RTT − 2 k −1 ] objecto transmissão
R k =1 R R entregue completa
O S S tempo no
= + 2 RTT + P[ RTT + ] − (2 P − 1) tempo no
cliente
servidor
R R R
Modelo de latência TCP (4)
Relembre que K = número de janelas que cobrem o objecto
Como se calcula K ?
K = min{k : 2 0 S + 21 S + L + 2 k −1 S ≥ O}
= min{k : 2 0 + 21 + L + 2 k −1 ≥ O / S }
O
= min{k : 2 k − 1 ≥ }
S
O
= min{k : k ≥ log 2 ( + 1)}
S
 O 
= log 2 ( + 1)
 S 
O cálculo de Q, número de paragens para um objecto de tamanho
infinito, é similar (veja Problemas TPC).
Modelo do HTTP
❒ Assuma que uma página Web consiste de:
❍ 1 página base HTML (de tamanho O bits)
❍ M imagens (cada de tamanho O bits)
❒ HTTP não persistente:
❍ M+1 ligações TCP em série
❍ Tempo de resposta = (M+1)O/R + (M+1)2RTT + soma das paragens
❒ HTTP persistente (com pipelining):
❍ 2 RTT para pedir e receber o ficheiro base HTML
❍ 1 RTT para pedir e receber M imagens
❍ Tempo de resposta = (M+1)O/R + 3RTT + soma das paragens
❒ HTTP não persistente com X ligações paralelas
❍ Suponha M/X inteiro.
❍ 1 ligação TCP para o ficheiro base
❍ M/X conjuntos de ligações paralelas para imagens.
❍ Tempo de resposta = (M+1)O/R + (M/X + 1)2RTT + soma das
paragens

Tempos de resposta HTTP (em segundos)
RTT = 100 mseg, O = 5 Kbytes, M=10 e X=5
20
15
non-persistent
10
persistent
parallel non-
0
28 Kbps
10 Mbps
100 Kbps
1 Mbps
persistent
Para ritmos baixos, o tempo da ligação e o tempo de resposta são
dominados pelo tempo de transmissão
Ligações persistentes dão apenas uma ligeira melhoria relativamente ao caso
de ligações paralelas.
Tempos de resposta HTTP (em segundos)
RTT =1 seg, O = 5 Kbytes, M=10 e X=5
70
60
50
non-persistent
40
30
persistent
20
10
parallel non-
0
28 Kbps
10 Mbps
100 Kbps
1 Mbps
persistent
Para RTTs elevados, o tempo de resposta é dominado pelos atrasos no
estabelecimento de ligação e arranque lento de TCP.
As ligações persistentes agora dão uma melhoria importante: especialmente em
redes com elevado atraso ritmo. •

❒ Princípios do serviço da
camada de transporte:
❍ multiplexagem,
desmultiplexagem
❍ transferência de dados
fiável A seguir:
❍ controlo de fluxo ❒ Deixar a periferia
da rede (aplicações,
❍ controlo de congestão
camada de
Instanciação e implementação
transporte)
❒
na Internet
❒ Entrar no núcleo
❍ UDP da rede
❍ TCP

3 Transporte

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

3 Transporte

Uploaded by

Copyright:

Available Formats

Capítulo 3: Camada de Transporte

❒ Entender os princípios ❒ Aprender os protocolos

subjacentes ao serviço de transporte na

transporte: ❍ UDP: transporte sem

desmultiplexagem ❍ TCP: transporte com

fiável ❍ Controlo de congestão em

Camada de Transporte 3-1

❒ 3.1 Serviços da camada ❒ 3.5 Transporte com

de transporte ligação: TCP

❒ 3.2 Multiplexagem e ❍ estrutura dos segmentos

desmultiplexagem ❍ transferência de dados

Camada de Transporte 3-2

❒ Fornece comunicação lógica

entre processos de aplicação a

funcionar em Sistemas  

❒ mais que um protocolo de

transporte disponível para as

Camada de Transporte vs. Rede

comunicação lógica entre Sistemas Terminais

comunicação lógica entre processos

❍ baseia-se, e melhora, os serviços da camada de Rede

Camada de Transporte 3-4

Sistemas Terminais = casas

Mensagens de aplicação = cartas nos envelopes

Protocolo de transporte = primos que tratam do

Protocolo de rede = serviço postal

Camada de Transporte 3-5

Protocolos de Nível de Transporte na Internet

❒ entrega fiável, ordenada,

entrega não fiável (melhor

não ordenada, unicast ou

❒ serviços não disponíveis: F3G$H I JF3KL M

Camada de Transporte 3-6

❒ 3.1 Serviços da camada ❒ 3.5 Transporte com

de transporte ligação: TCP

❒ 3.2 Multiplexagem e ❍ estrutura dos segmentos

desmultiplexagem ❍ transferência de dados

Camada de Transporte 3-7

Recolher dados de diferentes

transporte transporte transporte

rede rede rede

lig. de dados ligação de dados lig. de dados

físico físico físico

máquina 1 máquina 2 máquina 3

Camada de Transporte 3-8

❒ máquina recebe datagrama IP

❍ cada datagrama tem 32 bits

❍ cada datagrama leva 1 outros campos

❍ cada segmento tem números

de porto de origem, destino

❒ máquina usa endereços IP e

números de porto para enviar o

Camada de Transporte 3-9

Desmultiplexagem sem ligação

❒ Quando uma máquina

DatagramSocket mySocket2 = new de destino no segmento

DatagramSocket(9158); ❍ envia o segmento UDP para

o socket com esse número

e/ou portos de origem

enviados para o mesmo

Camada de Transporte 3-10

DatagramSocket serverSocket = new DatagramSocket(6428);

PO: 6428 PO: 6428

PD: 9157 PD: 5775

funcionar em Sistemas

❒ serviços não disponíveis: F3G$H I JF3KLM

PO: Porto Origem oferece endereço de retorno

Objectivo: detectar erros (e.g., bits trocados) no

do segmento (complemento ❍ NÃO erro detectado

para 1 da soma) ❍ SIM não houve erro