Camada de Transporte

Prévia do material em texto

Capítulo 3: Camada de Transporte
Nosso objetivo:
entender os princípios atrás 
dos serviços da camada de 
transporte:
• multiplexação/
demultiplexação
• transferência confiável de 
dados
• controle de fluxo
• controle de congestionamento 
13: Camada de Transporte
 aprender sobre os 
protocolos da camada de 
transporte da Internet:
 UDP: transporte não 
orientado a conexões
 TCP: transporte confiável 
orientado a conexões
 Controle de 
congestionamento do TCP
Capítulo 3: roteiro
 Serviços da camada de transporte
 Multiplexação e demultiplexação
 Transporte sem conexões: UDP
 Princípios da transferência confiável
 Transporte orientado a conexões: TCP
 Princípios de controle de 
congestionamento
 Controle de congestionamento no TCP
 Evolução da funcionalidade da camada 
de transporte
Transport Layer: 3-2
Serviços e protocolos de transporte
 fornecem comunicação lógica entre 
processos de aplicação executando em 
diferentes hospedeiros
 os protocolos de transporte são 
executados nos sistemas finais: 
• transmissor: quebra as mensagens 
da aplicação em segmentos, 
repassa-os para a camada de rede
• receptor: remonta as mensagens a 
partir dos segmentos, repassa-as 
para a camada de aplicação
 dois protocolos de transporte 
disponíveis para as aplicações 
Internet:
• TCP e UDP
3: Camada de Transporte 3
mobile network
home network
enterprise
network
national or global ISP
local or 
regional ISP
datacenter 
network
content 
provider 
network
aplicação
transporte
rede
enlace
física
aplicação
transporte
rede
enlace
física
Serviços e protocolos das camadas de Transporte x
rede
Analogia doméstica:
12 crianças na casa de Ana enviando 
cartas para 12 crianças na casa de 
Bill
 hospedeiros = casas
 processos = crianças
 mensagens da apl. = cartas nos 
envelopes
3: Camada de Transporte 4
Serviços e protocolos das camadas de Transporte x
rede
 camada de transporte:
comunicação lógica entre os 
processos
• depende de e estende serviços da 
camada de rede
 camada de rede: comunicação 
lógica entre hospedeiros
3: Camada de Transporte 5
Analogia doméstica:
12 crianças na casa de Ana enviando 
cartas para 12 crianças na casa de 
Bill
 hospedeiros = casas
 processos = crianças
 mensagens da apl. = cartas nos 
envelopes
física
enlace
rede (IP)
Aplicação
física
enlace
rede (IP)
aplicação
transport
Ações da Camada de Transporte
Transmissor:
msg apl. recebe uma mensagem da 
camada de aplicação
 determina os valores dos 
campos do cabeçalho
 cria o segmento
 passa o segmento para o 
IP
transporte
ThTh msg apl.
Transport Layer: 3-6
física
enlace
rede (IP)
aplicação
física
enlace
rede (IP)
aplicação
transporte
Ações da Camada de Transporte
transporte
Receptor:
msg. apl.  extrai a mensagem da 
camada de aplicação
 verifica valores do cabeçalho
 recebe o segmento do IP
Th msg apl.
 demultiplexa a mensagem 
para a aplicação via socket
Transport Layer: 3-7
Protocolos da camada de transporte Internet
 TCP: Transmission Control Protocol
• entrega confiável, ordenada
• controle de congestionamento
• controle de fluxo
• estabelecimento de conexão (“setup”)
UDP: User Datagram Protocol
• entrega não confiável, não ordenada: UDP
• extensão sem “gorduras” do “melhor 
esforço” do IP
 serviços não disponíveis: 
• garantias de atraso máximo
• garantias de largura de banda mínima
3: Camada de Transporte 8
mobile network
home network
enterprise
network
national or global ISP
local or
regional ISP
datacenter 
network
content
provider
network
aplicação
transporte
rede
enlace
física
aplicação
transporte
rede
enlace
física
Capítulo 3: roteiro
 Serviços da camada de transporte
 Multiplexação e demultiplexação
 Transporte sem conexões: UDP
 Princípios da transferência confiável
 Transporte orientado a conexões: 
TCP
 Princípios de controle de 
congestionamento
 Controle de congestionamento no 
TCP
 Evolução da funcionalidade da 
camada de transporte
Transport Layer: 3-9
Multiplexação/demultiplexação
Usa info do cabeçalho para 
entregar os segmentos 
recebidos aos sockets corretos
Demultiplexação no receptor:reúne dados de muitos sockets, adiciona 
o cabeçalho de transporte (usado 
posteriormente para a demultiplexação)
multiplexação no transmissor:
processo
socket
transporte
aplicação
física
enlace
rede
P2P1
transporte
aplicação
física
enlace
rede
P4
transporte
aplicação
física
enlace
rede
P3
3: Camada de Transporte 10
transport
physical
link
network transport
application
physical
link
network
transport
application
physical
link
network
HTTP server
client
HTTP msg
Transport Layer: 3-11
HTTP msgHt
HTTP msgHtHn
HTTP msgHtHn
HTTP msgHtHn
transport
physical
link
network transport
application
physical
link
network
transport
application
physical
link
network
cliente
HTTP msgHt
HTTP msg
Transport Layer: 3-12
HTTP msg
Q: como a camada de transporte sabia que deveria entregar a 
mensagem ao navegador Firefox e não ao processo Netflix ou ao 
processo Skype?
?
demultiplexação
?
demultiplexação
transporte
aplicação
Demultiplexação
multiplexação
multiplexação
transporte
aplicação
Multiplexação
 computador recebe os datagramas IP
• cada datagrama possui os 
endereços IP da origem e do 
destino 
• cada datagrama transporta um 
segmento da camada de 
transporte
• cada segmento possui números 
das portas origem e destino 
 O hospedeiro usa os endereços IP e 
os números das portas para 
direcionar o segmento ao socket 
apropriado
Como funciona a demultiplexação
porta origem porta destino
32 bits
dados da
aplicação
(mensagem/payload)
outros campos 
do cabeçalho
formato de segmento 
TCP/UDP
3: Camada de Transporte 21
Demultiplexação não orientada a conexões
Lembrete: 
 socket criado possui número de 
porta local ao host:
DatagramSocket mySocket1 = new 
DatagramSocket(12534);
datagramas IP com mesmo no. de porta 
destino, mas diferentes endereços IP origem 
e/ou números de porta origem podem ser 
encaminhados para o mesmo socket no 
destino
3: Camada de Transporte 22
quando o hospedeiro recebe o 
segmento UDP:
m verifica no. da porta de destino no 
segmento
m encaminha o segmento UDP para o 
socket com aquele no. de porta
r ao criar um datagrama para enviar 
para um socket UDP, deve 
especificar:
m endereço IP de destino
m número da porta de destino
Demultiplexação não orientada a conexões: exemplo
transport
application
physical
link
network
P3
transport
application
physical
link
network
P1
transport
application
physical
link
network
P4
source port: 9157
dest port: 6428
source port: 6428
dest port: 9157
source port: ?
dest port: ?
source port: ?
dest port: ?
3: Camada de Transporte 23
mySocket = 
socket(AF_INET,SOCK_DGRAM)
mySocket.bind(myaddr,9157);
mySocket = 
socket(AF_INET,SOCK_DGRAM)
mySocket.bind(myaddr,5775);
mySocket = 
socket(AF_INET,SOCK_DGRAM)
mySocket.bind(myaddr,6428);
Demultiplexação Orientada a Conexões
 Socket TCP identificado pela 
quádrupla: 
• endereço IP origem
• número da porta origem
• endereço IP destino
• número da porta destino
 Servidor pode dar suporte a 
muitos sockets TCP 
simultâneos: 
• cada socket é identificado pela 
sua própria quádrupla
• cada socket está associado a um 
cliente diferente
3: Camada de Transporte 24
r Demultiplexação: receptor 
usa todos os quatro valores 
para direcionar o segmento 
para o socket apropriado
Demultiplexação Orientada a Conexões: exemplo
transport
application
physical
link
network
P1
transport
application
physical
link
P4
transport
application
physical
link
network
P2
host: 
endereço 
IP A
host: 
endereço 
IP C
network
P6P5
P3
source IP,port: A,9157
dest IP, port: B,80
source IP,port: B,80
dest IP,port: A,9157 source IP,port: C,5775
dest IP,port: B,80
source IP,port: C,9157
dest IP,port: B,80
servidor: 
endereço 
IP B
Três segmentos, todos destinadosao endereço IP: B,
porta dest: 80 são demultiplexados para diferentes sockets
Transport Layer: 3-25
Resumo
Multiplexação, demultiplexação: baseada nos valores dos 
campos de cabeçalho do segmento, datagrama.
UDP: demultiplexa usando (apenas) o número da porta de 
destino
TCP: demultiplexa usando a quádrupla: endereços IP e 
números de porta da origem e do destino
Multiplexação/demultiplexação ocorre em todas as 
camadas
26
Capítulo 3: roteiro
 Serviços da camada de transporte
 Multiplexação e demultiplexação
 Transporte sem conexões: UDP
 Princípios da transferência confiável
 Transporte orientado a conexões: 
TCP
 Princípios de controle de 
congestionamento
 Controle de congestionamento no 
TCP
 Evolução da funcionalidade da 
camada de transporte
Transport Layer: 3-27
UDP: User Datagram Protocol
 Protocolo de transporte da Internet 
mínimo, “sem gorduras”, 
 Serviço “melhor esforço”, segmentos 
UDP podem ser:
• perdidos
• entregues à aplicação fora de 
ordem
 sem conexão:
• não há saudação inicial entre o 
remetente e o receptor UDP
• tratamento independente para 
cada segmento UDP
3: Camada de Transporte 28
Por quê existe o UDP?
r elimina estabelecimento de 
conexão (que adiciona atraso RTT)
r simples: não mantém “estado” da 
conexão nem no remetente, nem 
no receptor
r cabeçalho de segmento reduzido
r Não há controle de 
congestionamento: 
m UDP pode transmitir tão rápido 
quanto desejado (e possível)
m funciona mesmo diante de 
congestionamento
UDP: User Datagram Protocol
Uso do UDP:
• aplicações de fluxos (streaming) multimídia (tolerante a perdas, 
sensível à taxa de transmissão)
• DNS
• SNMP
• HTTP/3
caso seja necessária transferência confiável sobre o UDP 
(ex., HTTP/3):
• adiciona confiabilidade necessária na camada de aplicação
• adiciona controle de congestionamento na camada de aplicação
29
UDP: User Datagram Protocol [RFC 768]
3: Camada de Transporte 30
servidor SNMPcliente SNMP
transporte
(UDP)
física
enlace
rede (IP)
aplicação
UDP: Ações da Camada de Transporte
transporte
(UDP)
física
enlace
rede (IP)
aplicação
Transport Layer: 3-31
servidor SNMPcliente SNMP
transporte
(UDP)
física
enlace
rede (IP)
aplicação
transporte
(UDP)
física
enlace
rede (IP)
aplicação
UDP: Ações da Camada de Transporte
ações do transmissor UDP: 
SNMP msg recebe uma mensagem da 
camada de aplicação
 determina os valores dos 
campos de cabeçalho UDP
 cria segmento UDP
 passa o segmento para o IP
UDPhUDPh SNMP msg
Transport Layer: 3-32
servidor SNMPcliente SNMP
transporte
(UDP)
física
enlace
rede (IP)
aplicação
transporte
(UDP)
física
enlace
rede (IP)
aplicação
UDP: Ações da Camada de Transporte
ações do receptor UDP:
SNMP msg
 extrai a mensagem da 
camada de aplicação
 Verifica o valor do campo 
de checksum do cabeçalho
 recebe segmento do IP
UDPh SNMP msg
 demultiplexa a mensagem 
para a aplicação via socket
Transport Layer: 3-33
UDP: Cabeçalho do segmento
3: Camada de Transporte 34
# porta origem # porta dest
32 bits
dados da
aplicação
(carga)
formato do segmento UDP
comprimento checksum
comprimento, em 
bytes do segmento 
UDP segment, 
incluindo o cabeçalho
dados de/para a 
camada de aplicação
UDP: Cabeçalho do segmento
porta origem porta dest.
32 bits
Dados de 
aplicação 
(mensagem)
Formato do segmento UDP
comprimento checksum
Comprimento em bytes do
segmento UDP,
incluindo cabeçalho
3: Camada de Transporte 35
Soma de Verificação (checksum) UDP
Objetivo: detectar “erros” (ex.: bits trocados) no segmento transmitido
3: Camada de Transporte 36
Transmitido: 5 6 11
Recebido: 4 6 11
1o número 2o número soma
soma de verificação 
calculada no receptor
soma de verificação calculada 
no transmissor (como recebida)=
Soma de Verificação (checksum) UDP
transmissor:
 trata conteúdo do segmentoUDP
(incluindo campos do cabeçalho UDP e endereços 
IP) como sequência de inteiros de 16-
bits
 checksum: soma (adição usando 
complemento de 1) do conteúdo do 
segmento
 transmissor coloca o complemento 
do valor da soma no campo 
checksum do UDP 
receptor:
 calcula checksum do segmento 
recebido
 verifica se o checksum calculado 
bate com o valor recebido:
• NÃO - erro detectado
• SIM - nenhum erro detectado. 
Mas ainda pode ter erros? Veja 
depois ….
Objetivo: detectar “erros” (ex.: bits trocados) no segmento transmitido
3: Camada de Transporte 37
Checksum Internet: Exemplo
Exemplo: adição de dois inteiros de 16-bits
transbordo
soma
checksum
38
Note que: ao adicionar números, o transbordo (vai um) do bit mais 
significativo deve ser adicionado ao resultado
1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
Checksum Internet: proteção fraca!
transbordo
soma
checksum
39
1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
0 1 
1 0 
Apesar dos 
números terem 
mudado (troca de 
bits), o checksum
não mudou!
Exemplo: adição de dois inteiros de 16-bits
UDP: Resumo
protocolo “sem gorduras”:
• segmentos podem ser perdidos, entregues fora de ordem
• serviço melhor esforço: “envia e torce que tudo dê certo”
UDP tem pontos positivos:
• não necessita de estabelecimento de conexão 
(setup/handshaking)
• não incorrendo em um RTT adicional
• pode funcionar quando o serviço de rede estiver comprometido
• ajuda com a confiabilidade (checksum)
podem ser adicionadas funcionalidades acima do UDP na 
camada de aplicação (ex.: HTTP/3)
40
Capítulo 3: roteiro
 Serviços da camada de transporte
 Multiplexação e demultiplexação
 Transporte sem conexões: UDP
 Princípios da transferência confiável
 Transporte orientado a conexões: 
TCP
 Princípios de controle de 
congestionamento
 Controle de congestionamento no 
TCP
 Evolução da funcionalidade da 
camada de transporte
Transport Layer: 3-41
Princípios de Transferência confiável de dados
processo
remetente
dados
processo
destinatário
canal confiável
aplicação
transporte
abstração do serviço confiável
Transport Layer: 3-42
dados
Princípios de Transferência confiável de dados
processo
remetente
dados
processo
destinatário
aplicação
transporte
implementação do serviço confiável
canal não confiável
rede
transporte
lado remetente
do protocolo de
transferência
confiável 
lado destinatário
do protocolo de
transferência
confiável 
Transport Layer: 3-43
processo
remetente
dados
processo
destinatário
canal confiável
aplicação
transporte
abstração do serviço confiável
dados dados
Princípios de Transferência confiável de dados
Complexidade do protocolo de 
transferência confiável de 
dados dependerá (fortemente) 
das características do canal não 
confiável (perde, corrompe, 
reordena os dados?)
Transport Layer: 3-44
processo
remetente
dados
processo
destinatário
aplicação
transporte
implementação do serviço confiável
canal não confiável
rede
transporte
lado remetente
do protocolo de
transferência
confiável 
lado destinatário
do protocolo de
transferência
confiável 
dados
processo
remetente
dados
processo
destinatário
aplicação
transporte
implementação do serviço confiável
canal não confiável
rede
transporte
lado remetente
do protocolo de
transferência
confiável 
lado destinatário
do protocol de
transferência
confiável 
dados
Princípios de Transferência confiável de dados
Remetente, receptor não
conhecem o “estado” um do 
outro, ex., a mensagem foi 
recebida?
 a não ser que seja 
informado através de uma 
mensagem
Transport Layer: 3-45
Protocolo de transferência confiável (rdt): interfaces
processo
transmissor
dados
processo 
receptor
dados
canal não confiável
lado transmissor
da implementação
do protocolo 
confiável rdtlado receptor
da implementação
do protocolo 
confiável rdt
rdt_send()
udt_send() rdt_rcv()
deliver_data()
dataHeader dataHeader
rdt_send(): chamada de cima, 
(ex., pela apl.). Passa dados a 
serem entregues à camada 
superior do receptor
udt_send(): chamada pelo 
rdt para transferir um 
pacote para o receptor sobre 
um canal não confiável
rdt_rcv(): chamada quando o 
pacote chega no lado receptor 
do canal
deliver_data(): chamada pelo 
rdt para entregar dados à 
camada superior
Comunicação bidirecional sobre um 
canal não confiável
dados
pacote
Transport Layer: 3-46
Transferência confiável: ponto de partida
Iremos:
 incrementalmente desenvolver os lados transmissor e receptor de um 
protocolo de transferência confiável (reliable data transfer – rdt)
 considerar apenas fluxo unidirecional de dados
• mas info de controle flui em ambos os sentidos!
estado
1
estado
2
evento causador da transição de estado
ações executadas na transição de estado
estado: estando nesse 
“estado” o próximo 
estado é determinado
unicamente pelo 
próximo evento
evento
ações
 usar máquinas de estados finitos (FSM) para especificar transmissor, 
receptor
Transport Layer: 3-47
rdt1.0: transferência confiável sobre canal confiável
 canal de transmissão perfeitamente confiável
• sem erros de transmissão
• sem perda de pacotes
packet = make_pkt(data)
udt_send(packet)
rdt_send(data)
extract (packet,data)
deliver_data(data)
rdt_rcv(packet)Espera 
chamada 
de baixo
receptor
 FSMs separadas para transmissor, receptor:
• transmissor envia dados pelo canal subjacente
• receptor lê os dados do canal subjacente
transmissor
Espera 
chamada 
de cima
Transport Layer: 3-48
rdt2.0: canal com erros de bits
 canal subjacente pode trocar valores dos bits num pacote
• checksum (ex., checksum da Internet) para detetar bits com erro
 a questão: como recuperar esses erros?
Como as pessoas recuperam “erros” durante uma conversa?
Transport Layer: 3-49
rdt2.0: canal com erros de bits
canal subjacente pode trocar valores dos bits num pacote
• checksum pode detectar erros de bits
 a questão: como recuperar esses erros?
• reconhecimentos (ACKs - acknowledgements): receptor avisa 
explicitamente ao transmissor que o pacote foi recebido corretamente
• reconhecimentos negativos (NAKs): receptor avisa explicitamente ao 
transmissor que o pacote continha erros
• transmissor retransmite o pacote ao receber um NAK
para e espera
transmissor envia um pacote, aguarda resposta do receptor
Transport Layer: 3-50
rdt2.0: especificações das FSMs
Espera 
chamada 
de cima
udt_send(sndpkt)
Espera 
por ACK 
ou NAK
udt_send(NAK)
rdt_rcv(rcvpkt) && corrupt(rcvpkt)
Espera 
chamada 
de baixo
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_send(data)
rdt_rcv(rcvpkt) && isACK(rcvpkt)

transmissor
receptor
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Transport Layer: 3-51
especificações das FSMs
Espera 
chamada 
de cima
udt_send(sndpkt)
Espera 
por ACK 
ou NAK
udt_send(NAK)
rdt_rcv(rcvpkt) && corrupt(rcvpkt)
Espera 
chamada 
de baixo
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_send(data)
rdt_rcv(rcvpkt) && isACK(rcvpkt)

transmissor
receptor
Nota: “estado” do receptor (o receptor recebeu 
corretamente a minha mensagem?) não é 
conhecido pelo transmissor a menos que haja
comunicação do receptor para o transmissor
 é para isso que precisamos de um protocolo! 
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)isNAK(rcvpkt)
isACK(rcvpkt)
Transport Layer: 3-52
rdt2.0: operação com ausência de erros
Espera 
chamada 
de cima
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
udt_send(sndpkt)
udt_send(NAK)
Espera 
por ACK 
ou NAK
Espera 
chamada 
de baixo
rdt_send(data)
rdt_rcv(rcvpkt) && corrupt(rcvpkt)
rdt_rcv(rcvpkt) && isACK(rcvpkt)

extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
transmissor
receptor
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Transport Layer: 3-53
rdt2.0: cenário com pacote corrompido
Espera 
chamada 
de cima
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)Espera 
por ACK 
ou NAK
Espera 
chamada 
de baixo
rdt_send(data)
udt_send(NAK)
rdt_rcv(rcvpkt) && corrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && isACK(rcvpkt)

transmissor
receptor
Transport Layer: 3-54
rdt2.0 possui uma falha fatal!
o que acontece se ACK/NAK for 
corrompido?
 transmissor não sabe o que se 
passou no receptor!
não pode apenas retransmitir: 
possibilidade de pacotes 
duplicados
lidando com duplicatas: 
 transmissor retransmite o último 
pacote se ACK/NAK chegar com 
erro
 transmissor inclui número de 
sequência em cada pacote
 receptor descarta (não entrega a 
aplicação) pacotes duplicados
para e espera
Transmissor envia um pacote,
e aguarda resposta do receptor
Transport Layer: 3-55
rdt2.1: transmissor, trata ACK/NAKs corrompidos
Espera
chamada 0 
de cima
Espera por 
ACK ou
NAK 0
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_send(data)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && 
(corrupt(rcvpkt) || 
isNAK(rcvpkt) )
sndpkt = make_pkt(1, data, checksum)
udt_send(sndpkt)
rdt_send(data)
udt_send(sndpkt)
rdt_rcv(rcvpkt) 
&& (corrupt(rcvpkt) ||
isNAK(rcvpkt) )
Espera
chamada 1 
de cima
Espera por 
ACK ou
NAK 1
rdt_rcv(rcvpkt) 
&& notcorrupt(rcvpkt) 
&& isACK(rcvpkt) 

rdt_rcv(rcvpkt) 
&& notcorrupt(rcvpkt) && 
isACK(rcvpkt)

Transport Layer: 3-56
rdt2.1: receptor, trata ACK/NAKs corrompidos
Espera
por 0 de 
baixo
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) 
&& has_seq1(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
Espera
por 1 de 
baixo
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) 
&& has_seq0(rcvpkt) 
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
rdt_rcv(rcvpkt) && 
not corrupt(rcvpkt) &&
has_seq0(rcvpkt)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && 
not corrupt(rcvpkt) &&
has_seq1(rcvpkt)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt)
Transport Layer: 3-57
rdt2.1: discussão
transmissor:
 no. de seq. adicionado ao pacote
 bastam dois nos. de seq. (0,1). 
Por quê?
 deve verificar se ACK/NAK 
recebidos estão corrompidos
 duplicou o no. de estados
• estado deve “lembrar” se pacote 
“esperado” deve ter no. de seq. 0 
ou 1
receptor:
 deve verificar se o pacote 
recebido é uma duplicata
• estado indica se no. de seq. 
esperado é 0 ou 1
 nota: receptor não tem como 
saber se último ACK/NAK foi 
recebido OK pelo transmissor
Transport Layer: 3-58
rdt2.2: um protocolo sem NAKs
mesma funcionalidade do rdt2.1, usando apenas ACKs
ao invés de NAK, receptor envia ACK para último pacote 
recebido sem erro
• receptor deve incluir explicitamente no. de seq do pacote 
reconhecido
ACKs duplicados no transmissor resultam na mesma ação do 
NAK: retransmissão do pacote atual
Como veremos, TCP usa essa abordagem para não usar NAKs
Transport Layer: 3-59
rdt2.2: fragmentos do transmissor, receptor
Espera 
chamada 0 
de cima
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_send(data)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && 
( corrupt(rcvpkt) ||
isACK(rcvpkt,1) )
rdt_rcv(rcvpkt) 
&& notcorrupt(rcvpkt) 
&& isACK(rcvpkt,0)
Espera por 
ACK
0
fragmento da 
FSM do transmissor
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) 
&& has_seq1(rcvpkt) 
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK1, chksum)
udt_send(sndpkt)
Espera 
por 0 de 
baixo
rdt_rcv(rcvpkt)&& 
(corrupt(rcvpkt) ||
has_seq1(rcvpkt))
udt_send(sndpkt)
fragmento da FSM
do receptor

Transport Layer: 3-60
rdt3.0: canais com erros e perdas
Nova hipótese sobre o canal: canal subjacente também pode 
perder pacotes (dados, ACKs)
• checksum, nos. de sequência, ACKs, retransmissões poderão 
ajudar… mas, não são suficientes
Q: Como as pessoas lidam com palavras
perdidas na conversa entre transmissor e 
receptor?
Transport Layer: 3-61
rdt3.0: canais com erros e perdas
Abordagem: transmissor aguarda um tempo “razoável” pelo ACK 
 retransmite se nenhum ACK for recebido neste intervalo
 se pacote (ou ACK) estiver apenas atrasado (e não perdido):
• retransmissão será duplicata, mas uso de no. de seq. já cuida disto
• receptor deve especificar no. de seq do pacote sendo reconhecido
temporizador
 usa temporizador para interromper após um tempo “razoável”
Transport Layer: 3-62
Transmissor rdt3.0
Espera 
por 
ACK0
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
start_timer
rdt_send(data)
Espera 
chamada 1 
de cima
sndpkt = make_pkt(1, data, checksum)
udt_send(sndpkt)
start_timer
rdt_send(data)
rdt_rcv(rcvpkt) 
&& notcorrupt(rcvpkt) 
&& isACK(rcvpkt,0)
stop_timer
rdt_rcv(rcvpkt) 
&& notcorrupt(rcvpkt) 
&& isACK(rcvpkt,1)
stop_timer
Espera 
chamada 0 
de cima
Espera 
por 
ACK1
Transport Layer: 3-63
Transmissor rdt3.0
Espera 
por 
ACK0
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
start_timer
rdt_send(data)
Espera 
chamada 1 
de cima
sndpkt = make_pkt(1, data, checksum)
udt_send(sndpkt)
start_timer
rdt_send(data)
rdt_rcv(rcvpkt) 
&& notcorrupt(rcvpkt) 
&& isACK(rcvpkt,0)
stop_timer
rdt_rcv(rcvpkt) 
&& notcorrupt(rcvpkt) 
&& isACK(rcvpkt,1)
stop_timer
udt_send(sndpkt)
start_timer
timeoutEspera 
chamada 0 
de cima
Espera 
por 
ACK1

rdt_rcv(rcvpkt)
rdt_rcv(rcvpkt) && 
( corrupt(rcvpkt) ||
isACK(rcvpkt,1) )
rdt_rcv(rcvpkt)

udt_send(sndpkt)
start_timer
timeout
rdt_rcv(rcvpkt) && 
( corrupt(rcvpkt) ||
isACK(rcvpkt,0) )

Transport Layer: 3-64
rdt3.0 em ação
transmissor receptor
rcv pkt1
rcv pkt0
send ack0
send ack1
send ack0
rcv ack0
send pkt0
send pkt1
rcv ack1
send pkt0
rcv pkt0
pkt0
pkt0
pkt1
ack1
ack0
ack0
(a) Sem perda
transmissor receptor
rcv pkt1
rcv pkt0
send ack0
send ack1
send ack0
rcv ack0
send pkt0
send pkt1
rcv ack1
send pkt0
rcv pkt0
pkt0
pkt0
ack1
ack0
ack0
(b) Pacote perdido
pkt1
X
perda
pkt1
timeout
resend pkt1
Transport Layer: 3-65
rdt3.0 em ação
rcv pkt1
send ack1
(detect duplicate)
pkt1
transmissor receptor
rcv pkt1
rcv pkt0
send ack0
send ack1
send ack0
rcv ack0
send pkt0
send pkt1
rcv ack1
send pkt0
rcv pkt0
pkt0
pkt0
ack1
ack0
ack0
(c) Perda de ACK
ack1
X
loss
pkt1
timeout
resend pkt1
rcv pkt1
send ack1
(detect duplicate)
pkt1
transmissor receptor
rcv pkt1
send ack0
rcv ack0
send pkt1
send pkt0
rcv pkt0pkt0
ack0
(d) Retransmissão prematura/ ACK atrasado
pkt1
timeout
resend pkt1
ack1
ack1
send ack1send pkt0
rcv ack1
pkt0
rcv pkt0
send ack0ack0
pkt1
(ignore)
rcv ack1
Transport Layer: 3-66
Desempenho do rdt3.0 (para-e-espera)
 exemplo: enlace de 1 Gbps, atraso prop. 15 ms, pacote com 
8000 bits
U trans: utilização – fração de tempo em que transmissor 
está transmitindo
Dtrans =
L
R
8000 bits
109 bits/seg= = 8 microsegs
• tempo para transmitir o pacote no canal:
Transport Layer: 3-67
rdt3.0: operação para-e-espera
transmissão do primeiro bit do pacote, t = 0
transmissor receptor
RTT
chegada do primeiro bit do pacote
chegada do último bit do 
pacote, envia ACK
chegada do ACK, envia próximo
pacote, t = RTT + L / R
Transport Layer: 3-68
rdt3.0: operação para-e-espera
transmissor receptor
Utransm
=
L / R
RTT
RTT
L/R
+ L / R
= 0,00027
= 0,008
30,008
 desempenho horrível do protocolo rdt 3.0!
 Protocolo limita o desempenho da infraestrutura subjacente (canal)
Transport Layer: 3-69
Operação de protocolos com paralelismo
paralelismo (pipelining): transmissor envia vários pacotes em sequência, 
todos esperando para serem reconhecidos
• faixa de números de sequência deve ser aumentada
• armazenamento no transmissor e/ou no receptor
Transport Layer: 3-70
Paralelismo: aumento da utilização
transmitido primeiro bit do pacote, t = 0
transmissor receptor
RTT 
Transmitido ultimo bit, t = L / R
chegada do primeiro bit do pacote
chegada do último bit do pacote, envia ACK
chegada do ACK, envia próximo 
pacote, t = RTT + L / R
chegada do último bit do 2o pacote, envia ACK
chegada do último bit do 3o pacote, envia ACK
Paralelismo com 3-pacotes aumenta
a utilização por um fator de 3!
U 
transm = 
0,0024 
30,008 
= 0,00081 
3L / R 
RTT + L / R 
= 
Transport Layer: 3-71
Go-Back-N: transmissor
 transmissor: “janela” de até N, pctes consecutivos transmitidos, mas não 
reconhecidos
• no. de seq. de k-bits no cabeçalho do pacote
 ACK cumulativo: ACK(n): ACKs todos os pacotes, incluindo no. seq. n
• ao receber ACK(n): avança a janela para iniciar com n+1
 temporizador para o pacote mais antigo ainda não confirmado
 timeout(n): retransmite pacote n e todos os seguintes na janela
Transport Layer: 3-72
já
reconhecido
enviado, mas 
ainda não 
reconhecido
autorizado, mas
ainda não enviado
não autorizado
Go-Back-N: receptor
 usa apenas ACK: sempre envia ACK para pacote recebido 
corretamente com o maior no. de seq. em ordem
• pode gerar ACKs duplicados
• só precisa se lembrar do rcv_base
 ao receber pacotes fora de ordem: 
• pode descartar (não armazenar) ou armazenar: decisão de implementação
• re-ACK pacote com o maior no. de seq. em ordem
rcv_base
recebido e reconhecido
Fora de ordem: recebido, mas não reconhecido
não recebido
Visão do receptor do espaço de números de 
sequência:
… …
Transport Layer: 3-73
Go-Back-N em ação
send pkt0
send pkt1
send pkt2
send pkt3
(wait)
transmissor receptor
receive pkt0, send ack0
receive pkt1, send ack1
receive pkt3, discard, 
(re)send ack1
send pkt2
send pkt3
send pkt4
send pkt5
Xloss
timeout
receive pkt4, discard, 
(re)send ack1
receive pkt5, discard, 
(re)send ack1
rcv pkt2, deliver, send ack2
rcv pkt3, deliver, send ack3
rcv pkt4, deliver, send ack4
rcv pkt5, deliver, send ack5
ignore duplicate ACK
janela transmissor (N=4)
0 1 2 3 4 5 6 7 8 
0 1 2 3 4 5 6 7 8 
0 1 2 3 4 5 6 7 8 
0 1 2 3 4 5 6 7 8 
rcv ack0, send pkt40 1 2 3 4 5 6 7 8 
0 1 2 3 4 5 6 7 8 
0 1 2 3 4 5 6 7 8 
0 1 2 3 4 5 6 7 8 
0 1 2 3 4 5 6 7 8 
0 1 2 3 4 5 6 7 8 rcv ack1, send pkt5
Transport Layer: 3-74
Repetição Seletiva: a abordagem
paralelismo: múltiplos pacotes em trânsito
 receptor reconhece individualmente todos os pacotes recebidos 
corretamente
• buferiza pacotes, caso necessário, para entrega em ordem à camada superior
 transmissor:
• mantém (conceitualmente) um temporizador para cada pacote não 
reconhecido
• timeout: retransmite apenas o pacote associado ao timeout
• mantém (conceitualmente) “janela” incluindo N #s de seq. consecutivos
• limita os pacotes em trânsito àqueles que cabem nessa janela
Transport Layer: 3-75
Retransmissão seletiva: janelas do transmissor e 
do receptor
Transport Layer: 3-76
Fora de ordem 
(no buffer), mas 
já reconhecido
Aguardado, mas 
ainda não 
recebido
Aceitável (dentro 
da janela)
Não autorizado
já
reconhecido
enviado, mas 
ainda não 
reconhecido
autorizado, mas
ainda não enviado
não autorizado
visão do transmissor dos números de sequência
visão do receptor dos números de sequência
Retransmissão seletiva: transmissor e receptor
dados de cima:
 se próx. no. seq. disponível (n) na 
janela, envia pacote, liga 
temporizador (n)
timeout(n):
 reenvia pacote n, reinicia 
temporizador
ACK(n) em [sendbase,sendbase+N]:
 marca pacote n como recebido, 
desliga temporizador(n)
 se n for o menor pacote não 
reconhecido, avança a base da 
janela para o próx. no. de seq. não 
reconhecido
transmissor
pacote n em [rcvbase, rcvbase+N-1]
 envia ACK(n)
 forade ordem: armazena
 em ordem: entrega (tb. entrega 
pacotes armazenados em ordem), 
avança janela p/ próximo pacote 
ainda não recebido
pacote n em [rcvbase-N,rcvbase-1]
 ACK(n)
senão:
 ignora 
receptor
Transport Layer: 3-77
Retransmissão seletiva em ação
send pkt0
send pkt1
send pkt2
send pkt3
(wait)
transmissor receptor
send pkt2
(but not 3,4,5)
Xloss
pkt 2 timeout
Janela do transmissor (N=4)
0 1 2 3 4 5 6 7 8 
0 1 2 3 4 5 6 7 8 
0 1 2 3 4 5 6 7 8 
0 1 2 3 4 5 6 7 8 
rcv ack0, send pkt40 1 2 3 4 5 6 7 8 
0 1 2 3 4 5 6 7 8 
0 1 2 3 4 5 6 7 8 
0 1 2 3 4 5 6 7 8 
0 1 2 3 4 5 6 7 8 
0 1 2 3 4 5 6 7 8 rcv ack1, send pkt5
receive pkt0, send ack0
receive pkt1, send ack1
receive pkt3, buffer, 
send ack3
record ack3 arrived
receive pkt4, buffer, 
send ack4
receive pkt5, buffer, 
send ack5
rcv pkt2; deliver pkt2,
pkt3, pkt4, pkt5; send ack2
Q: o que acontece quando chegar o ack2?
Transport Layer: 3-78