Cap3 Kurose v8.0 2

Capítulo 3
Camada de Transporte
Redes de Computadores e
a Internet: Uma
abordagem Top-Down
All material copyright 1996-2020 8a edição
J.F Kurose and K.W. Ross, All Rights Reserved Jim Kurose, Keith Ross
Pearson & Bookman, 2021
Transport Layer: 3-1
Capítulo 3: Camada de Transporte
Metas do capítulo: r aprender sobre os protocolos

§ entender os princípios atrás da camada de transporte da
dos serviços da camada de Internet:
transporte: m UDP: transporte não
• multiplexação/ orientado a conexões
demultiplexação m TCP: transporte orientado a
• transferência confiável de conexões
dados
• controle de fluxo m Controle de
• controle de congestionamento congestionamento do TCP
3: Camada de Transporte
2
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

Serviços e protocolos de transporte
aplicação
transporte
§ fornecem comunicação lógica entre mobile rede
network
enlace
processos de aplicação executando em física
national or global ISP
diferentes hospedeiros
Tra
§ os protocolos de transporte são
nsp
executados nos sistemas finais:
ort
e ló
• lado transmissor: quebra as
g ic
mensagens da aplicação em local or
of
regional ISP
segmentos, repassa-os para a camada
im-
a-f
de rede home network
im
content
• lado receptor: remonta as mensagens provider
network
a partir dos segmentos, repassa-as datacenter
aplicaçãonetwork
transporte
para a camada de aplicação rede
enlace
§ dois protocolos de transporte disponíveis

física
para as aplicações Internet: enterprise

network
• TCP e UDP
3: Camada de Transporte 4
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
Camadas de Transporte x rede
§ camada de rede: comunicação Analogia doméstica:

lógica entre hospedeiros 12 crianças na casa de Ana enviando
§ camada de transporte: cartas para 12 crianças na casa de
comunicação lógica entre os Bill
processos § hospedeiros = casas
• depende de e estende serviços da § processos = crianças
camada de rede § mensagens da apl. = cartas nos
envelopes
Ações da Camada de Transporte
Transmissor:
aplicação § recebe uma mensagem da Aplicação
msg apl.
camada de aplicação
transporte § determina os valores dos TThhtransport
msg apl.
campos do cabeçalho
rede (IP) § cria o segmento rede (IP)
enlace
§ passa o segmento para o enlace
IP física
física

Ações da Camada de Transporte
Receptor:
aplicação § recebe o segmento do IP aplicação
§ verifica valores do cabeçalho
msg. apl.
transporte § extrai a mensagem da transporte
rede (IP) rede (IP)
§ demultiplexa a mensagem
enlace para a aplicação via socket enlace
física física
Th msg apl.

Protocolos da camada de transporte Internet
aplicação
transporte
§ TCP: Transmission Control Protocol mobile rede

network
enlace
física
• entrega confiável, ordenada national or global ISP
• controle de congestionamento
Tra
nsp
• controle de fluxo
ort
• estabelecimento de conexão (“setup”)
e ló
g ic
§ UDP: User Datagram Protocol local or
of
regional ISP
im-
• entrega não confiável, não ordenada: UDP
a-f
home network
im
• extensão sem “gorduras” do “melhor content
provider
esforço” do IP network datacenter
aplicaçãonetwork
transporte
§ serviços não disponíveis: rede

enlace
física
• garantias de atraso máximo
enterprise
• garantias de largura de banda mínima network
§ Transporte orientado a conexões:
TCP
congestionamento
§ Controle de congestionamento no
TCP
§ Evolução da funcionalidade da
camada de transporte Transport Layer: 3-10
servidor HTTP
cliente
aplicação aplicação
HTTP msg
transporte
transporte rede transporte

rede enlace rede
enlace física enlace
física física

servidor HTTP
cliente
HTTP msg
transport
Ht HTTP msg

rede enlace rede
física física

servidor HTTP
cliente
HTTP msg
transport
Ht HTTP msg
Hnnetwork
Ht HTTP msg transporte
transporte
rede enlace rede
física física

servidor HTTP
cliente
transporte

rede enlace rede
física física
Hn Ht HTTP msg

servidor HTTP
cliente1 cliente2
aplicação P-cliente1 P-cliente2 aplicação
transporte

rede enlace rede
física física

Multiplexação/demultiplexação
Multiplexação no transm.:
reúne dados de muitos sockets, Demultiplexação no receptor:
adiciona o cabeçalho de transporte Usa info do cabeçalho para
(usado posteriormente para a entregar os segmentos
demultiplexação) recebidos aos sockets corretos
aplicação
aplicação P1 P2 aplicação socket

P3 transporte P4
processo
rede enlace rede
física física
Como funciona a demultiplexação
32 bits
§ computador recebe os datagramas IP porta origem porta destino
• cada datagrama possui os
endereços IP da origem e do outros campos
destino do cabeçalho
• cada datagrama transporta um
segmento da camada de
transporte dados da
• cada segmento possui números aplicação
das portas origem e destino (mensagem/payload)
§ O hospedeiro usa os endereços IP e
os números das portas para
formato de segmento
direcionar o segmento ao socket
apropriado TCP/UDP
Demultiplexação não orientada a conexões
Lembrete: quando o hospedeiro recebe o
segmento UDP:
§ socket criado possui número de m verifica no. da porta de destino no
porta local ao host: segmento
DatagramSocket mySocket1 = new m encaminha o segmento UDP para o
DatagramSocket(12534);
socket com aquele no. de porta
r ao criar um datagrama para enviar

para um socket UDP, deve datagramas IP com mesmo no. de porta
especificar: destino, mas diferentes endereços IP origem
m endereço IP de destino e/ou números de porta origem podem ser
m número da porta de destino encaminhados para o mesmo socket no
destino
Demultiplexação não orientada a conexões: exemplo
DatagramSocket
serverSocket = new
DatagramSocket mySocket2 DatagramSocket DatagramSocket mySocket1 =
= new DatagramSocket new DatagramSocket (5775);
(6428);
(9157);
application
application application
P1
P3 P4
transport
transport transport
network
network link network
link physical link
physical physical
source port: 6428 source port: ?

dest port: 9157 dest port: ?
source port: 9157 source port: ?

dest port: 6428 dest port: ?
Demultiplexação Orientada a Conexões
§ Socket TCP identificado pela § Servidor pode dar suporte a
quádrupla: muitos sockets TCP
• endereço IP origem simultâneos:
• número da porta origem • cada socket é identificado pela
sua própria quádrupla
• endereço IP destino • cada socket está associado a um
• número da porta destino cliente diferente
r Demultiplexação: receptor
usa todos os quatro valores
para direcionar o segmento
para o socket apropriado
Demultiplexação Orientada a Conexões: exemplo
application
application P4 P5 P6 application
P1 P2 P3
transport
transport transport
network
network link network
link physical link
physical servidor: physical
endereço
IP B
host: source IP,port: B,80 host:

endereço dest IP,port: A,9157 source IP,port: C,5775 endereço
IP A dest IP,port: B,80 IP C
source IP,port: A,9157
dest IP, port: B,80
source IP,port: C,9157
dest IP,port: B,80
Três segmentos, todos destinados ao endereço IP: B,
porta dest: 80 são demultiplexados para diferentes sockets
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
22
TCP
congestionamento
TCP
UDP: User Datagram Protocol
§ Protocolo de transporte da Internet Por quê existe o UDP?
mínimo, “sem gorduras”, r elimina estabelecimento de
§ Serviço “melhor esforço”, segmentos conexão (que adiciona atraso RTT)
UDP podem ser: r simples: não mantém “estado” da
• perdidos conexão nem no remetente, nem
• entregues à aplicação fora de no receptor
ordem r cabeçalho de segmento reduzido
§ sem conexão: r Não há controle de
• não há saudação inicial entre o congestionamento:
remetente e o receptor UDP m UDP pode transmitir tão rápido
quanto desejado (e possível)
• tratamento independente para m funciona mesmo diante de
cada segmento UDP 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
25
UDP: User Datagram Protocol [RFC 768]
UDP: Ações da Camada de Transporte
cliente SNMP servidor SNMP
transporte transporte
(UDP) (UDP)
rede (IP) rede (IP)
enlace enlace
física física


ações do transmissor UDP:
aplicação § recebe uma mensagem da aplicação
SNMP msg
§ determina os valores dos UDP
UDPhh SNMP msg
(UDP) campos de cabeçalho UDP (UDP)
rede (IP) § cria segmento UDP rede (IP)
enlace
§ passa o segmento para o IP enlace
física física


ações do receptor UDP:
aplicação § recebe segmento do IP aplicação
§ Verifica o valor do campo
SNMP msg de checksum do cabeçalho
(UDP) (UDP)
§ extrai a mensagem da
rede
UDP (IP) msg
h SNMP
camada de aplicação rede (IP)
§ demultiplexa a mensagem
enlace enlace
para a aplicação via socket
física física

UDP: Cabeçalho do segmento
32 bits
porta origem porta dest.
comprimento checksum
Dados de
aplicação
Comprimento em bytes do (mensagem)
segmento UDP,
incluindo cabeçalho
Formato do segmento UDP
Soma de Verificação (checksum) UDP
Objetivo: detectar “erros” (ex.: bits trocados) no segmento transmitido
1o número 2o número soma
Transmitido: 5 6 11
Recebido: 4 6 11
soma de verificação
calculada no receptor
= soma de verificação calculada
no transmissor (como recebida)
Soma de Verificação (checksum) UDP
Objetivo: detectar “erros” (ex.: bits trocados) no segmento transmitido
transmissor: receptor:
§ trata conteúdo do segmentoUDP (incluindo § calcula checksum do segmento
campos do cabeçalho UDP e endereços IP) como
recebido
sequência de inteiros de 16-bits
§ checksum: soma (adição usando § verifica se o checksum calculado
complemento de 1) do conteúdo do bate com o valor recebido:
segmento • NÃO - erro detectado
§ transmissor coloca o complemento do • SIM - nenhum erro detectado.
valor da soma no campo checksum do Mas ainda pode ter erros? Veja
UDP depois ….
Checksum Internet: Exemplo

Exemplo: adição de dois inteiros de 16-bits
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
transbordo 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
soma 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
checksum 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
Note que: ao adicionar números, o transbordo (vai um) do bit mais

significativo deve ser adicionado ao resultado
33
Checksum Internet: proteção fraca!

Exemplo: adição de dois inteiros de 16-bits
0 1
1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 0
1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
transbordo 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 Apesar dos

números terem
soma 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 mudado (troca de
bits), o checksum
checksum 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 não mudou!
34
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)
35
TCP
congestionamento
TCP
Princípios de Transferência confiável de dados
processo processo
remetente destinatário
aplicação dados dados
transporte
canal confiável
abstração do serviço confiável

processo processo processo processo

remetente destinatário remetente destinatário
aplicação dados dados aplicação dados dados
canal confiável
lado remetente lado destinatário
abstração do serviço confiável do protocolo de do protocolo de
transferência transferência
confiável confiável
transporte
rede
canal não confiável
implementação do serviço confiável

processo processo
transporte
lado remetente lado destinatário

Complexidade do protocolo de do protocolo de
transferência
do protocolo de
transferência
transferência confiável de confiável confiável
dados dependerá (fortemente) transporte
rede
das características do canal não canal não confiável
confiável (perde, corrompe,
reordena os dados?) implementação do serviço confiável

processo processo
transporte
Remetente, receptor não lado remetente lado destinatário

conhecem o “estado” um do do protocolo de do protocol de
transferência transferência
outro, ex., a mensagem foi confiável confiável
recebida? transporte
§ a não ser que seja rede

informado através de uma
mensagem implementação do serviço confiável

Protocolo de transferência confiável (rdt): interfaces
rdt_send(): chamada de cima,
(ex., pela apl.). Passa dados a deliver_data(): chamada pelo
rdt para entregar dados à
serem entregues à camada
camada superior
superior do receptor
processo processo
transmissor receptor
rdt_send() dados dados
deliver_data()
dados
lado transmissor lado receptor
da implementação da implementação
do protocolo pacote do protocolo
confiável rdt confiável rdt
udt_send() Header data Header data rdt_rcv()

udt_send(): chamada pelo rdt_rcv(): chamada quando o
rdt para transferir um pacote chega no lado receptor
Comunicação bidirecional sobre um
pacote para o receptor sobre canal não confiável do canal
um canal não confiável Transport Layer: 3-41
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!
§ usar máquinas de estados finitos (FSM) para especificar transmissor,
receptor
evento causador da transição de estado
ações executadas na transição de estado
estado: estando nesse
“estado” o próximo estado estado
estado é determinado 1 evento
unicamente pelo 2
ações
próximo evento

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
§ FSMs separadas para transmissor, receptor:

• transmissor envia dados pelo canal subjacente
• receptor lê os dados do canal subjacente
Espera rdt_send(data) rdt_rcv(packet)

Espera
transmissor chamada packet = make_pkt(data) receptor chamada extract (packet,data)
de cima udt_send(packet) de baixo deliver_data(data)

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?

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
rdt2.0: especificações das FSMs
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
Espera Espera isNAK(rcvpkt)
transmissor chamada por ACK udt_send(sndpkt) rdt_rcv(rcvpkt) && corrupt(rcvpkt)
de cima ou NAK
udt_send(NAK)
rdt_rcv(rcvpkt) && isACK(rcvpkt)

Espera
L chamada receptor
de baixo
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)

especificações das FSMs
rdt_send(data)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
de cima ou NAK
udt_send(NAK)

Espera
L chamada receptor
de baixo
Nota: “estado” do receptor (o receptor recebeu

corretamente a minha mensagem?) não é rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
conhecido pelo transmissor a menos que haja deliver_data(data)
comunicação do receptor para o transmissor udt_send(ACK)
§ é para isso que precisamos de um protocolo!
rdt2.0: operação com ausência de erros
rdt_send(data)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
de cima ou NAK
udt_send(NAK)

Espera
L chamada receptor
de baixo

deliver_data(data)
udt_send(ACK)

rdt2.0: cenário com pacote corrompido
rdt_send(data)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
de cima ou NAK
udt_send(NAK)

Espera
L chamada receptor
de baixo

deliver_data(data)
udt_send(ACK)

rdt2.0 possui uma falha fatal!
o que acontece se ACK/NAK for lidando com duplicatas:
corrompido? § transmissor retransmite o último
pacote se ACK/NAK chegar com
§ transmissor não sabe o que se erro
passou no receptor! § transmissor inclui número de
§ não pode apenas retransmitir: sequência em cada pacote
possibilidade de pacotes § receptor descarta (não entrega a
duplicados aplicação) pacotes duplicados
para e espera
Transmissor envia um pacote,
e aguarda resposta do receptor
rdt2.1: transmissor, trata ACK/NAKs corrompidos
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt) rdt_rcv(rcvpkt) &&
(corrupt(rcvpkt) ||
Espera Espera por isNAK(rcvpkt) )
chamada 0 ACK ou
NAK 0 udt_send(sndpkt)
de cima
rdt_rcv(rcvpkt)
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) &&
&& notcorrupt(rcvpkt)
isACK(rcvpkt)
&& isACK(rcvpkt)
L
L
Espera por Espera
ACK ou chamada 1
rdt_rcv(rcvpkt) NAK 1 de cima
&& (corrupt(rcvpkt) ||
isNAK(rcvpkt) ) rdt_send(data)
udt_send(sndpkt) sndpkt = make_pkt(1, data, checksum)

udt_send(sndpkt)

rdt2.1: transmissor, trata ACK/NAKs corrompidos
&& 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
rdt_rcv(rcvpkt) && por 0 de por 1 de rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) && baixo baixo 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
transmissor: receptor:
§ no. de seq. adicionado ao pacote § deve verificar se o pacote
§ bastam dois nos. de seq. (0,1). recebido é uma duplicata
Por quê? • estado indica se no. de seq.
esperado é 0 ou 1
§ deve verificar se ACK/NAK
recebidos estão corrompidos § nota: receptor não tem como
saber se último ACK/NAK foi
§ duplicou o no. de estados recebido OK pelo transmissor
• estado deve “lembrar” se pacote
“esperado” deve ter no. de seq. 0
ou 1

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
rdt2.2: fragmentos do transmissor, receptor
rdt_send(data)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
Espera Espera por
ACK isACK(rcvpkt,1) )
chamada 0
de cima 0 udt_send(sndpkt)
fragmento da
FSM do transmissor rdt_rcv(rcvpkt)
rdt_rcv(rcvpkt) && && isACK(rcvpkt,0)
(corrupt(rcvpkt) || L
has_seq1(rcvpkt)) Espera fragmento da FSM
por 0 de
udt_send(sndpkt) baixo do receptor
&& has_seq1(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK1, chksum)
udt_send(sndpkt) Transport Layer: 3-55
rdt3.0: canais com erros e perdas
Nova hipóstese sobre o canal: canal subjacente também pode
perder pacotes (dados, ACKs)
• checksum, nos. de sequência, ACKs, retransmisssões poderão
ajudar… mas, não são suficientes
Q: Como as pessoas lidam com palavras

perdidas na conversa entre transmissor e
receptor?
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
§ usa temporizador para interromper após um tempo “razoável”
temporizador

Transmissor rdt3.0
rdt_send(data)
udt_send(sndpkt)
start_timer
Espera Espera
chamada 0 por
de cima ACK0
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt,1) && notcorrupt(rcvpkt)
stop_timer && isACK(rcvpkt,0)
stop_timer
Espera Espera
por chamada 1
ACK1 de cima
rdt_send(data)
udt_send(sndpkt)
start_timer

Transmissor rdt3.0
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 L
L Espera Espera
por timeout
chamada 0
ACK0 udt_send(sndpkt)
de 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 por chamada 1
udt_send(sndpkt) ACK1 de cima
start_timer rdt_rcv(rcvpkt)
rdt_send(data) L
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) || sndpkt = make_pkt(1, data, checksum)
isACK(rcvpkt,0) ) udt_send(sndpkt)
start_timer
L

rdt3.0 em ação
transmissor receptor transmissor receptor
send pkt0 pkt0 send pkt0 pkt0
rcv pkt0 rcv pkt0
ack0 send ack0 ack0 send ack0
rcv ack0 rcv ack0
send pkt1 pkt1 send pkt1 pkt1
rcv pkt1 X
perda
ack1 send ack1
rcv ack1
send pkt0 pkt0
rcv pkt0 timeout
ack0 send ack0 resend pkt1 pkt1
rcv pkt1
ack1 send ack1
rcv ack1
send pkt0 pkt0
(a) Sem perda rcv pkt0
ack0 send ack0
(b) Pacote perdido

rdt3.0 em ação
transmissor receptor send pkt0
pkt0
rcv pkt0
send pkt0 pkt0 send ack0
ack0
rcv pkt0 rcv ack0
ack0 send ack0 send pkt1 pkt1
rcv ack0 rcv pkt1
rcv pkt1 ack1
ack1 send ack1
X timeout
loss resend pkt1
pkt1 rcv pkt1
timeout
resend pkt1 pkt1
rcv pkt1 rcv ack1 (detect duplicate)
(detect duplicate)
ack1 send ack1 ack1 rcv pkt0
rcv ack1 rcv ack1 send ack0
send pkt0 pkt0 (ignore) ack0
rcv pkt0
ack0 send ack0 pkt1
(c) Perda de ACK (d) Retransmissão prematura/ ACK atrasado

Desempenho do rdt3.0 (para-e-espera)
§ U trans: utilização – fração de tempo em que transmissor
está transmitindo
§ exemplo: enlace de 1 Gbps, atraso prop. 15 ms, pacote com
8000 bits
• tempo para transmitir o pacote no canal:
L 8000 bits
Dtrans = R = = 8 microsegs
109 bits/seg

rdt3.0: operação para-e-espera
transmissão do primeiro bit do pacote, t = 0
chegada do primeiro bit do pacote

RTT chegada do último bit do
pacote, envia ACK
chegada do ACK, envia próximo

pacote, t = RTT + L / R

rdt3.0: operação para-e-espera
L/R L/R
Utransm=
RTT + L / R
0,008 RTT
=
30,008
= 0,00027
§ desempenho horrível do protocolo rdt 3.0!

§ Protocolo limita o desempenho da infraestrutura subjacente (canal)

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

Paralelismo: aumento da utilização
transmitido primeiro bit do pacote, t = 0
Transmitido ultimo bit, t = L / R
chegada do primeiro bit do pacote

RTT chegada do último bit do pacote, envia ACK
chegada do último bit do 2o pacote, envia ACK
chegada do último bit do 3o pacote, envia ACK
chegada do ACK, envia próximo
pacote, t = RTT + L / R
Paralelismo com 3-pacotes aumenta
a utilização por um fator de 3!
3L / R 0,0024
U = = = 0,00081
transm 30,008
RTT + L / R
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
já autorizado, mas
reconhecido ainda não enviado
enviado, mas não autorizado
ainda não
reconhecido
§ 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
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 armazena) ou armazena: decisão de implementação
• re-ACK pacote com o maior no. de seq. em ordem
Visão do receptor do espaço de números de
sequência: recebido e reconhecido
… … Fora de ordem: recebido, mas não reconhecido
rcv_base
não recebido
Go-Back-N em ação
janela transmissor (N=4) transmissor receptor
012345678 send pkt0
012345678 send pkt1
send pkt2 receive pkt0, send ack0
012345678
012345678 send pkt3 Xloss receive pkt1, send ack1
(wait)
receive pkt3, discard,
012345678 rcv ack0, send pkt4 (re)send ack1
012345678 rcv ack1, send pkt5 receive pkt4, discard,
(re)send ack1
ignore duplicate ACK receive pkt5, discard,
(re)send ack1
timeout
012345678 send pkt2
012345678 send pkt3
012345678 send pkt4 rcv pkt2, deliver, send ack2
012345678 send pkt5 rcv pkt3, deliver, send ack3
rcv pkt4, deliver, send ack4
rcv pkt5, deliver, send ack5

Retransmissão (repetição) seletiva
§Receptor reconhece individualmente todos os pacotes
recebidos corretamente
• armazena pacotes no buffer, conforme necessário, para posterior
entrega em-ordem à camada superior
§transmissor temporiza/retransmite individualmente pacotes
não reconhecidos
• transmissor mantém temporizador para cada pacote não reconhecido
§janela do transmissor
• N números de sequência consecutivos
• limita nos. de seq de pacotes enviados, não reconhecidos

Retransmissão seletiva: janelas do transmissor e
do receptor
já autorizado, mas
reconhecido ainda não enviado
enviado, mas não autorizado
ainda não
reconhecido
visão do transmissor dos números de sequência
Fora de ordem
(no buffer), mas Aceitável (dentro
já reconhecido da janela)
Aguardado, mas Não autorizado
ainda não
recebido
visão do receptor dos números de sequência

Retransmissão seletiva: transmissor e receptor
dados de cima: pacote n em [rcvbase, rcvbase+N-1]
§ se próx. no. seq. disponível (n) na
janela, envia pacote, liga § envia ACK(n)
temporizador (n) § fora de ordem: armazena
timeout(n): § em ordem: entrega (tb. entrega
§ reenvia pacote n, reinicia pacotes armazenados em ordem),
temporizador
avança janela p/ próximo pacote
ACK(n) em [sendbase,sendbase+N]: ainda não recebido
§ marca pacote n como recebido,
desliga temporizador(n) pacote n em [rcvbase-N,rcvbase-1]
§ se n for o menor pacote não § ACK(n)
reconhecido, avança a base da
janela para o próx. no. de seq. não senão:
reconhecido § ignora

Retransmissão seletiva em ação
Janela do transmissor (N=4) transmissor receptor
012345678 send pkt0
012345678 send pkt1
012345678 send pkt2 receive pkt0, send ack0
012345678 send pkt3 Xloss receive pkt1, send ack1
(wait)
receive pkt3, buffer,
012345678 rcv ack0, send pkt4 send ack3
012345678 rcv ack1, send pkt5
record ack3 arrived send ack4
pkt 2 timeout send ack5
012345678 send pkt2
012345678 (but not 3,4,5)
012345678 rcv pkt2; deliver pkt2,
012345678 pkt3, pkt4, pkt5; send ack2
Q: o que acontece quando chegar o ack2?

Retransmissão
janela do transmissor janela do receptor
(após recepção) (após recepção)
seletiva: dilema!
0123012 pkt0
0123012 pkt1 0123012
0123012 pkt2 0123012
exemplo:
0123012
0123012 pkt3
X
0123012
§ nos. seq: 0, 1, 2, 3 (base 4) pkt0 aceitará pacote com
no. de sequência 0
§ tam. da janela = 3 (a) Nenhum problema
0123012 pkt0
0123012 pkt1 0123012
0123012 pkt2 X 0123012
X 0123012
X
timeout
retransmit pkt0
0123012 pkt0
aceitará pacote com
no. de sequência 0
(b) oops!
Retransmissão
janela do transmissor janela do receptor
(após recepção) (após recepção)
seletiva: dilema!
0123012 pkt0
0123012 pkt1 0123012
0123012 pkt2 0123012
exemplo: 0123012 pkt3

X
0123012
§ nos. seq: 0, 1, 2, 3 (base 4) § receptor não

0123012
pkt0
vê
o lado
§ tam. da janela = 3 (a) no problem
transmissor
no. de sequência 0
§ comportamento
do receptor é
idêntico nos dois
0casos!
123012 pkt0
Q: qual o relacionamento § 0algo
1 2 3 0está
1 2 (muito)
pkt1 0123012
0errado!
necessário entre o tamanho do 123012 pkt2 X
X
0123012
número de sequência e o
0123012
X
tamanho da janela para evitar timeout
retransmit pkt0
o problema do cenário (b)? 0123012 pkt0
no. de sequência 0
(b) oops!
• estrutura do segmento
• transferência confiável de dados
• gerenciamento da conexão
congestionamento
de transporte
TCP: visão geral RFCs: 793,1122, 2018, 5681, 7323
§ ponto-a-ponto: § ACKs cumulativos
• um transmissor, um receptor § paralelismo:
§ fluxo de bytes ordenados, • controle de congestionamento e
de fluxo determinam tamanho da
confiável: janela
• sem “limites de msgs” § orientado a conexões:
§ dados full duplex: • handshaking (troca de mensagens
• fluxo bidirecional de dados na de controle) inicializa estados do
mesma conexão transmissor, receptor antes da
troca de dados
• MSS: tamanho máximo do
segmento § fluxo controlado:
• transmissor não inundará o
receptor
Estrutura do segmento TCP
32 bits
porta da fonte porta destino no. seq segmento:

ACK: no. seq. do próximo número de sequência contagem dos bytes de dados
byte esperado; no fluxo (não segmentos!)
bit A: este é um ACK número de reconhecimento
compr. (cabeçalho TCP) head not
len used C E U A P R S F janela recepção controle de fluxo: no.
checksum Internet checksum Pont. dados urg. de bytes receptor está
pronto para aceitar
opções (compr. variável)
C, E: notificação de congest.
opções TCP
dados da dados enviados
RST, SYN, FIN: aplicação pela aplicação
gerenciamento da conexão (compr. variável) no socket TCP

TCP: números de sequência, ACKs
segmento de saída do transmissor
Números de sequência: source port # dest port #
número de sequência
• “número”, dentro do fluxo acknowledgement number
de bytes, do primeiro byte checksum

rwnd
urg pointer
de dados do segmento tam. da janela

N
Reconhecimentos (ACKs):
• no. de seq. do próx. byte
espaço no. de sequência do transmissor
esperado do outro lado
• ACK cumulativo enviado e
reconhecido
enviado, autorizado não
não reconh. mas, não autorizado
(em trânsito) enviado
Q: como receptor trata
segmentos fora da ordem? segmento de saída do receptor
source port # dest port #
• R: espec. do TCP omissa – sequence number

número reconhecimento
deixado ao implementador A rwnd
checksum urg pointer
TCP: números de sequência, ACKs
Hospedeiro A Hospedeiro B
Usuário digita‘C’
Seq=42, ACK=79, data = ‘C’
hospedeiro reconhece
recebimento do‘C’,
Seq=79, ACK=43, data = ‘C’ ecoa‘C’
Hospedeiro reconhece
recebimento do
‘C’ecoado Seq=43, ACK=80
cenário telnet simples

TCP: tempo de ida e volta, temporizador
Q: como escolher o valor do Q: como estimar o RTT?
temporizador TCP? § SampleRTT: tempo medido
§ maior que o RTT, mas o RTT entre a transmissão do segmento
varia! e o recebimento do ACK
correspondente
§ muito curto: temporização • ignora retransmissões
prematura, retransmissões
desnecessárias § SampleRTT varia muito, é
desejável um “amortecedor” para
§ muito longo: reação lenta à a estimativa do RTT
perda de segmentos • usa média de medições recentes, não apenas
o último SampleRTT obtido.

EstimatedRTT = (1- a)*EstimatedRTT + a*SampleRTT
§ média móvel exponencialmente ponderada (EWMA – exponential weighted
moving average)
§ influência de cada amostra diminui exponencialmente com o tempo RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
§ valor típico: a = 0,125 350
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
300
RTT (milisegundos)
RTT (milliseconds)
250
200
150
sampleRTT
EstimatedRTT
100
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
tempo (segundos)
time (seconnds)
SampleRTT Estimated RTT
§ intervalo temporizador: EstimatedRTT mais “margem de segurança”
• grandes variações no EstimatedRTT: maior margem de segurança
TimeoutInterval = EstimatedRTT + 4*DevRTT
RTT estimado “margem de segurança”
§ DevRTT: desvio EWMA da SampleRTT do EstimatedRTT:

DevRTT = (1-b)*DevRTT + b*|SampleRTT-EstimatedRTT|
(tipicamente, b = 0,25)
* Confira os exercícios interativos on-line em: http://gaia.cs.umass.edu/kurose_ross/interactive/

Transmissor TCP (simplificado)
evento: dados recebidos da evento: estouro do temporizador
aplicação
§ cria segmento com no. de § retransmite o segmento que causou
sequência (nseq) o estouro do temporizador
§ nseq é o número de sequência § reinicia o temporizador
do primeiro byte de dados do
segmento evento: recebimento de ACK
§ liga o temporizador se já não § se o ACK reconhece segmentos
estiver ligado ainda não reconhecidos
§ temporização do segmento mais • atualizar informação sobre o que foi
antigo ainda não reconhecido reconhecido
§ valor do temporizador: • religa o temporizador se ainda
TimeOutInterval houver segmentos pendentes (não
reconhecidos),
• caso contrário, desliga o temporizador.
Receptor TCP: geração de ACKs [RFC 5681]
Evento no receptor ação no receptor TCP
chegada de segmento em ordem ACK retardado. Espera até 500ms
com todos os dados até n. seq. pelo próx. segmento. Se não chegar
esperado já reconhecidos segmento, envia ACK
chegada de segmento em ordem envia imediatamente um único ACK

com nseq esperado. Outro cumulativo, reconhecendo ambos
segmento com ACK pendente segmentos em ordem
chegada de segmento fora de envia imediatamente ACK duplicado,

ordem com nseq maior que o indicando no. seq. do próximo byte
esperado. Lacuna detetada esperado
chegada de segmento que envia imediatamente ACK, desde que

preenche a lacuna parcial ou o segmento é o primeiro da lacuna
completamente
TCP: cenários de retransmissão
Host A Host B Host A Host B
SendBase=92
Seq=92, 8 bytes de dados Seq=92, 8 bytes de dados
Seq=100, 20 bytes de dados

timeout
timeout
ACK=100
X
ACK=100
ACK=120
Seq=92, 8 bytes de dados Seq=92, 8

SendBase=100 bytes de dados envia ACK cumulativo
SendBase=120 para o 120
ACK=100
ACK=120
SendBase=120
cenário com perda estouro prematuro

do ACK do temporizador
TCP: cenários de retransmissão
Host A Host B

ACK=100
X
ACK=120
Seq=120, 15 de dados
ACK cumulativo cobre

perda anterior de ACK

Retransmissão rápida do TCP
Host A Host B
Retransmissão rápida do TCP
se o transmissor receber 3 ACKs
para os mesmos dados (“três ACKs Seq=92
, 8 byte
s de da
Seq=1
duplicados”), retransmite segmento não 00, 20
bytes
do s
de da d
timeout
reconhecido com menor no. de seq. os
X
§ provavelmente o segmento não
reconhecido se perdeu, não =100
A CK
espera pelo temporizador
C K =100
A
timeout
C K =100
A
=100
Recepção de três ACKs A C K
duplicados indica que 3 Seq=100, 20 bytes de dados
segmentos foram recebidos

depois de um não recebido,
provavelmente perdido.
Então, retransmite! Transport Layer: 3-88
• estrutura do segmento
• transferência confiável de dados
• gerenciamento da conexão
congestionamento
de transporte
Controle de fluxo do TCP
processo de
Q: O que acontece se a camada aplicação
Aplicação removendo
de rede entrega dados mais dados dos buffers do
rápido do que a camada de socket TCP
Buffers de recepção
aplicação remove os dados dos do socket TCP
buffers do socket? TCP armazenando dados
recebidos, nos buffers
código
TCP
Camada de rede
entregando o conteúdo de
datagramas IP para o TCP código
IP
do transmissor
pilha de protocolos no receptor

processo de
buffers do socket? TCP armazenando dados
recebidos, nos buffers
código
TCP
Camada de rede
entregando o conteúdo de
datagramas IP para o TCP código
IP
do transmissor

processo de
buffers do socket?
código
TCP
janela recepção
controle de fluxo: no.
bytes que o receptor está código
disposto a receber IP
do transmissor

processo de
buffers do socket?
código
controle de fluxo TCP
receptor controla o transmissor,

de modo que o transmissor não código
inunde o buffer do receptor, IP
transmitindo muita coisa, muito

rápido. do transmissor

§ O receptor TCP “anuncia” o espaço
livre do buffer no campo rwnd (janela para processo de aplicação
de recepção) no cabeçalho TCP
• RcvBuffer tamanho configurado nas
opções de socket (valor típico default é de RcvBuffer dados armazenados
4096 bytes)
rwnd espaço livre
• muitos sistemas operacionais ajustam
automaticamente o RcvBuffer
§ o transmissor limita a quantidade os carga dos segmentos TCP
dados não reconhecidos ao tamanho
do rwnd recebido armazenamento no
§ garante que o buffer do receptor não lado do receptor TCP
transbordará
Controle de fluxo do TCP controle de fluxo: no. bytes que o receptor
está disposto a receber
§ O receptor TCP “anuncia” o espaço
livre do buffer no campo rwnd (janela
recepção) no cabeçalho TCP
• RcvBuffer tamanho configurado nas janela recepção
opções de socket (valor típico default é de
4096 bytes)
• muitos sistemas operacionais ajustam
automaticamente o RcvBuffer
§ o transmissor limita a quantidade os
dados não reconhecidos ao tamanho
do rwnd recebido
§ garante que o buffer do receptor não
transbordará formato do segmento TCP

TCP: gerenciamento de conexões
antes de trocar dados, transmissor e receptor TCP dialogam:
§ concordam em estabelecer uma conexão (cada um sabendo que o outro quer
estabelecer a conexão)
§ concordam com os parâmetros da conexão (ex., nos. seq. iniciais)
estado conexão: ESTAB estado conexão: ESTAB

variáveis conexão: variáveis conexão:
No.seq cliente-p/-servidor No.seq cliente-p/-servidor
servidor-p/-cliente servidor-p/-cliente
tamanho rcvBuffer tamanho rcvBuffer
no servidor,cliente no servidor,cliente
rede rede
Socket clientSocket = Socket connectionSocket =

newSocket("hostname","port number"); welcomeSocket.accept();
Concordando em estabelecer uma conexão
Apresentação de 2 vias
(2-way handshake):
Vamos
Q: a apresentação em duas vias
conversar sempre funciona em redes?
ESTAB
OK § atrasos variáveis
ESTAB
§ mensagens retransmitidas (ex.
req_conn(x)) devido à perda de
mensagem
escolhe x § reordenação de mensagens
req_conn(x)
ESTAB § não consegue “ver” o outro lado
acc_conn(x)
ESTAB

Cenários de apresentação de 2 vias
escolhe x
req_conn(x)
ESTAB
acc_conn(x)
ESTAB
data(x+1) aceita
data(x+1)
ACK(x+1)
término da
conexão x
Sem problemas!

escolhe x
req_conn(x)
ESTAB
retransmite acc_conn(x)
req_conn(x)
ESTAB
req_conn(x)
término da
cliente conexão x servidor
encerra esquece x
ESTAB
acc_conn(x)
Problema: conexão aberta
pela metade! (sem cliente)
escolhe x
req_conn(x)
ESTAB
retransmite acc_conn(x)
req_conn(x)
ESTAB
data(x+1) aceita
data(x+1)
retransmite
data(x+1)
término da
conexão x servidor
cliente
encerra esquece x
req_conn(x)
ESTAB
data(x+1) aceita
data(x+1)
Problema: aceita
dados duplicados!
Apresentação de três vias do TCP
Estado do servidor
Estado do cliente
serverSocket = socket(AF_INET,SOCK_STREAM)
serverSocket.bind((‘’,serverPort))
serverSocket.listen(1)
clientSocket = socket(AF_INET, SOCK_STREAM) connectionSocket, addr = serverSocket.accept()
LISTEN
clientSocket.connect((serverName,serverPort)) LISTEN
escolhe no. seq inicial, x
envia msg TCP SYN
SYNSENT SYNbit=1, Seq=x
escolhe no. seq inicial, y
envia msg TCP SYNACK,
reconhecendo o SYN SYN RCVD
SYNbit=1, Seq=y
ACKbit=1; ACKnum=x+1
SYNACK(x) recebido
ESTAB indica servidor ativo;
envia ACK para SYNACK;
este segmento pode conter ACKbit=1, ACKnum=y+1
dados do cliente para servidor
ACK(y) recebido
indica cliente ativo
ESTAB

Um protocolo humano de três vias
1. On belay?
2. Belay on.
3. Climbing.

Encerrando uma conexão TCP
§ seja o cliente que o servidor fecham cada um o seu lado da
conexão
§ enviam segmento TCP com bit FIN = 1
§ respondem ao FIN recebido com um ACK
§ ao receber um FIN, ACK pode ser combinado com o próprio FIN
§ lida com trocas de FIN simultâneos

TCP
congestionamento
TCP
Princípios de Controle de Congestionamento
Congestionamento:
§ informalmente: “muitas fontes enviando dados acima da
capacidade da rede de tratá-los”
§ sintomas:
• longos atrasos (enfileiramento nos buffers dos
roteadores)
• perda de pacotes (saturação de buffers nos Controle de
roteadores) congestionamento:
§ diferente de controle de fluxo! demasiados transmissores,
enviando muito rápido
§ um dos 10 maiores problemas!
controle de fluxo: um
transmissor muito rápido
para um receptor
Causas/custos de congestionamento: cenário 1
dados originais: lin vazão: lout
Cenário mais simples:
Host A
§ um roteador, buffers infinitos
§ capacidade dos enlaces: R buffer infinito no
enlace de saída
§ dois fluxos
R R
§ sem retransmissões
Host B
R/2
Q: O que acontece
lout
atraso
quando a taxa de
chegada lin
vazão:
atinge R/2? lin R/2 lin R/2

vazão máxima por grandes atrasos qdo taxa
conexão: R/2 de chegada lin se
aproxima da capacidade Transport Layer: 3-106
§ um roteador, buffers finitos
§ transmissor retransmite pacotes perdidos, estouro do temporizador
• entrada camada de aplicação = saída da camada de aplicação: lin = lout
• entrada camada de transporte inclui retransmissões: l’in ≥ lin
Host A lin : dados originais

l'in: dados originais, mais lout
dados retransmitidos
R R
Host B buffer finito no

enlace de saída
Idealização: conhecimento perfeito R/2
lout
§ transmissor envia apenas quando houver buffer
disponível no roteador
vazão:
Host A lin : dados originais lin
copy l'in: dados originais, mais lout R/2
espaço livre no buffer!
R R

enlace de saída
Idealização: algum conhecimento
perfeito
§ pacotes podem ser perdidos (descartados no
roteador) devido a buffers cheios
§ transmissor sabe quando pacote foi descartado:
retransmite apenas se o pacote sabidamente se
perdeu
copia l'in: dados originais, mais
sem espaço no buffer!
R R

enlace de saída
Idealização: algum conhecimento R/2
perfeito capacidade
“desperdiçada” com
lout
retransmissões
§ pacotes podem ser perdidos (descartados no
roteador) devido a buffers cheios ao transmitir a R/2,
§ transmissor sabe quando pacote foi descartado: alguns pacotes
vazão:
retransmite apenas se o pacote sabidamente se necessitam
perdeu retransmissões
Host A lin : dados originais lin R/2

l'in: dados originais, mais
R R

enlace de saída
Cenário realista: duplicatas desnecessárias R/2
capacidade
§ pacotes podem ser perdidos, descartados no
lout
roteador, buffers cheios – requer retransmissões retransmissões
desnecessárias
§ mas, temporizador pode estourar prematuramente
vazão:
enviando duas cópias, ambas entregues ao transmitir a R/2,
alguns pacotes são
retransmissões,
incluindo duplicatas
Host A lin : dados originais lin
necessárias e
desnecessárias,
R/2
timeout
copy l'in: dados originais, mais que são entregues!
R R

enlace de saída
Cenário realista: duplicatas desnecessárias R/2
capacidade
§ pacotes podem ser perdidos, descartados no
lout
roteador, buffers cheios – requer retransmissões retransmissões
desnecessárias
§ mas, temporizador pode estourar prematuramente
vazão:
enviando duas cópias, ambas entregues ao transmitir a R/2,
alguns pacotes são
retransmissões,
incluindo duplicatas
nedessárias e
lin R/2 desnecessárias,
que são entregues!
“custos” do congestionamento:
vazão no receptor
§ mais trabalho (retransmissões) para uma dada
§ retransmissões desnecessárias: enlace transporta múltiplas cópias do
pacote
• diminuido a vazão máxima alcançável

§ quatro transmissores Q: o que ocorre à medida que lin e lin’ crescem?
§ caminhos multi-enlaces
R: à medida que lin’ cresce, todos pacotes azuis que
§ temporização/retransmissão chegam na fila superior são descartados,
vazão azul g 0
Host B
l'in: dados originais, mais
buffers finitos nos
enlaces de saída
Host D
lout
Host C

R/2
lout
lin’ R/2
outro “custo” do congestionamento:

§ quando pacote é descartado, qualquer capacidade de
transmissão já usada (antes do descarte) para esse pacote foi
desperdiçada!

Causas/custos do congestionamento: insights
R/2
§ vazão nunca excede a capacidade
throughput: lout
lin R/2
§ atraso cresce quando a capacidade é alcançada
delay
R/2
lin R/2
§ perda/retransmissão diminui a vazão
loutthroughput:
efetiva
lin R/2 R/2
§ duplicatas desnecessárias diminuem ainda
throughput: lout
mais a vazão efetiva
R/2
lin
§ capacidade de transmissão/buffer
R/2
lout
desperdiçados com pacotes perdidos mais
“abaixo” lin’ R/2

Abordagens para o controle de
congestionamento
controle fim-a-fim:
§ sem realimentação explícita da
rede
§ congestionamento inferido a
partir da perda, atraso ACKs
data data
observados ACKs
§ abordagem usada pelo TCP

Abordagens para o controle de
congestionamento
Controle de congestionamento
assistido pela rede:
info explícita de
§ roteadores proveem realimentação congestionamento
direta aos hospedeiros
transmissores/receptores com fluxos
data
passando pelo roteador ACKs data
ACKs
congestionado
§ pode indicar o nível do
congestionamento ou informar
explicitamente a taxa de transmissão
§ protocolos TCP ECN, ATM, DECbit

TCP
congestionamento
TCP
Controle de congestionamento do TCP: AIMD
§ abordagem: transmissores podem aumentar a taxa de transmissão até que
ocorra uma perda de pacote (congestionamento), diminui a taxa de
transmissão com o evento de perda
Additive Increase Multiplicative Decrease
aumenta a taxa de transmissão de corta a taxa de transmissão pela
1 tamanho máximo do segmento a metade a cada evento de perda
cada RTT até detetar uma perda
Taxa de transmissão TCP
Comportamento de
dente de serra do AIMD:
testando a largura de banda
tempo Transport Layer: 3-119

TCP AIMD: mais
Detalhe da diminuição multiplicativa: a taxa de transmissão
§ Cortada pela metade ao detetar perda por três ACKS duplicados
(TCP Reno)
§ Cortada para 1 MSS (maximum segment size) quando a perda é
detetada por estouro do temporizador (TCP Tahoe)
Por que usar o AIMD?
§ AIMD – algoritmo distribuído, assíncrono – mostrou que:
• otimiza as taxas dos fluxos congestionados em toda a rede!
• possui propriedades desejáveis de estabilidade

Controle de congestionamento do TCP: detalhes
espaço de nos. de sequência do transmissor
cwnd
Comportamento do transmissor
TCP:
§ aproximadamente: envia cwnd
bytes, espera RTT pelos ACKs,
depos envia mais bytes
último byte
reconhecido enviado, mas autorizado, cwnd
mas não usado taxa TCP ~
~ bytes/seg
ainda não RTT
reconhecido último byte
(“em trânsito”) enviado
§ transmissor TCP limita a taxa de tx a: LastByteSent- LastByteAcked < cwnd

§ Cwnd é ajustada dinamicamente em resposta ao congestionamento
observado da rede (implementando o controle de congestionamento do
TCP)
TCP: partida lenta (slow start)
Host A Host B
§ no início da conexão, aumenta
a taxa exponencialmente até
o primeiro evento de perda:
um segme
nto
RTT
• inicialmente cwnd = 1 MSS dois segm
entos
• duplica cwnd a cada RTT
• através do incremento de cwnd
para cada ACK recebido quatro seg
mentos
§ resumo: taxa inicial é baixa

mas cresce rapidamente de tempo
forma exponencial
TCP: da partida lenta a evitar congestionamento
Q: quando o crescimento
exponencial deve mudar para
linear?
X
R: quando cwnd atingir 1/2 do seu
Janela de congestionamento
valor antes do estouro do
(em segmentos)
temporizador
Implementação:
§ limiar variável ssthresh
§ num evento de perda, ssthresh
passa a ser 1/2 de cwnd Rodada de transmissão (RTTs)
imediatamente antes do evento de
perda
* Confira os exercício interativos online para mais exemplos: http://gaia.cs.umass.edu/kurose_ross/interactive/

Resumo: controle de congestionamento do TCP
Novo
Novo ACK!
ACK! new ACK
duplicate ACK
dupACKcount++ new ACK .
cwnd = cwnd + MSS (MSS/cwnd)
dupACKcount = 0
cwnd = cwnd+MSS transmite novos segmentos, como permitido
dupACKcount = 0
L transmite novos segmentos, como permitido
cwnd = 1 MSS
ssthresh = 64 KB cwnd > ssthresh
dupACKcount = 0 partida L prevenção
de
lenta timeout
ssthresh = cwnd/2
cwnd = 1 MSS
congest. duplicate ACK
timeout dupACKcount = 0 dupACKcount++
ssthresh = cwnd/2 retransmite o segmento que falta
cwnd = 1 MSS
dupACKcount = 0
retransmite o segmento que falta Novo
timeout
ACK!
ssthresh = cwnd/2
cwnd = 1 New ACK
dupACKcount = 0
dupACKcount == 3 retransmite o segmento que falta cwnd = ssthresh dupACKcount == 3
dupACKcount = 0
ssthresh= cwnd/2 ssthresh= cwnd/2
cwnd = ssthresh + 3 cwnd = ssthresh + 3
retransmite o segmento que falta recupera- retransmite o segmento que falta
ção
rápida
duplicate ACK
cwnd = cwnd + MSS
transmite novos segmentos, como permitido
TCP CUBIC
§ Há uma melhor forma do que AIMD para “testar” banda disponível?
§ Insight/intuição:
• Wmax: taxa de transmissão na qual a perda por congestionamento foi detetada
• estado de congestionamento do gargalo provavelmente (?) não mudou muito
• após cortar a taxa/janela pela metade com a perda, inicialmente cresce mais
rápido, mas cresce mais lentamente ao se aproximar de Wmax
Wmax TCP clássico
TCP CUBIC – maior

Wmax/2 vazão nesse exemplo

TCP CUBIC
§ K: instante em que o tamanho da janela TCP atinge Wmax
• K é ajustável
§ aumenta W em função do cubo da distância entre o instante atual e K
• maior crescimento quando mais distante de K
• menor crescimento (mais cauteloso) quando mais próximo de K
§ TCP CUBIC é o Wmax

default em Linux,
TCP Reno
TCP mais popular TCP CUBIC
para os servidores taxa TCP
de
sending
transmissão
Web populares rate
TCP
tempo
time
t0 t1 t2 t3 t4
TCP e o enlace “gargalo” congestionado
§ TCP (clássico, CUBIC) aumenta a taxa de transmissão do TCP até que
ocorra a perda de pacote na saída de algum roteador: o enlace gargalo
origem destino
TCP TCP
rede rede
enlace enlace
física física
fila de pacotes quase
nunca está vazia, algumas
vezes descarta pacotes
enlace gargalo (quase sempre ocupado)

TCP e o enlace “gargalo” congestionado
§ TCP (clássico, CUBIC) aumenta a taxa de transmissão do TCP até que
ocorra a perda de pacote na saída de algum roteador: o enlace gargalo
§ compreendendo o congestionamento: útil para focar no enlace gargalo
congestionado
insight: aumentando a taxa de
origem transmissão TCP não aumentará a
destino
vazão fim-a-fim com o gargalo
TCP
congestionado
TCP
rede rede
enlace enlace
física física
insight: aumentando a taxa

de transmissão TCP irá
aumentar o RTT medido Objetivo: “manter o tubo fim-a-fim cheio,
mas não mais cheio”
RTT
Controle de congestionamento TCP baseado em
atraso
Mantendo o tubo do transmissor ao receptor “cheio, mas não mais cheio”:
manter o gargalo ocupado transmitindo, evitando altos atrasos/buffering
no. bytes enviados
vazão no último RTT
RTTmedido medida =
RTTmedido
Abordagem baseada no atraso:
§ RTTmin - RTT mínimo observado (caminho não congestionado)
§ vazão sem congestionamento com janela de congestionamento cwnd é cwnd/RTTmin
se vazão medida estiver “muito próxima” da vazão sem congestionamento
aumenta cwnd linearmente /* caminho não congestionado*/
senão se a vazão medida estiver “muito abaixo” da vazão sem congestionamento
diminui cwnd linearmente /* caminho congestionado */
Controle de congestionamento TCP baseado em
atraso
§ controle de congestionamento sem induzir/forçar perda
§ mazimiza a vazão (“mantendo o tubo cheio…”) mantendo o atraso baixo
(“… mas não mais cheio”)
§ alguns TCPs implantados adotam uma abordagem baseada em atrasos

§ BBR implantado na rede backbone (interna) do Google

Notificação explícita de congestionamento (ECN)
redes TCP frequentemente implementam controle de congestionamento
assistido pela rede:
§ dois bits no cabeçalho IP (campo ToS) marcado pelo roteador para indicar congestionamento
• política para determinar a marcação escolhida pelo operador da rede
§ indicação de congestionamento transportada até o destino
§ destino seta o bit ECE no segmento de ACK para notificar o transmissor sobre o
congestionamento
§ envolve tanto o IP (marcação do bit ECN no cabeçalho IP) quanto o TCP (marcação dos bits C, E no
cabeçalho TCP)
origem segmento TCP ACK
destino
TCP ECE=1
TCP
rede rede
enlace enlace
física física
ECN=10 ECN=11
datagrama IP
TCP: equidade (fairness)
Objetivo da equidade: se K sessões TCP compartilham o
mesmo enlace de gargalo com largura de banda R, cada um
deve obter uma taxa média de R/K
conexão TCP 1
roteador
conexão TCP 2 gargalo com
capacidade R

Q: o TCP é justo?
Exemplo: duas sessões TCP concorrentes:
§ crescimento aditivo declividade 1, no aumento da vazão
§ redução multiplicativa diminui vazão proporcionalmente
R compartilhamento igual da banda

O TCP é justo?
R: Sim, sob condições
vazão da conexão 2
perda: reduz a janela por um fator de 2 ideais:

prevenção de congest.: aumento aditivo § mesmo RTT
perda: reduz a janela por um fator de 2
prevenção de congest.: aumento aditivo
§ número fixo de sessões
apenas na prevenção de
congestionamento
vazão da conexão 1 R
Todas as apps de rede devem ser “justas”?
Justiça e UDP Justiça, conexões TCP em
§ apps multimídia em geral não paralelo
usam TCP § aplicação pode abrir múltiplas
• não querem que a taxa seja limitada conexões em paralelo entre dois
pelo controle de congestionamento
hospedeiros
§ em geral usam UDP:
• enviam áudio/vídeo em taxas
§ navegadores web fazem isso, ex.,
constantes, toleram perda de pacotes enlace de taxa R com 9 conexões
§ não há nenhuma “polícia Internet” existentes:
policiando o uso do controle de • nova app pede 1 TCP, obtém taxa
congestionamento R/10
• nova app pede 11 TCPs, obtém R/2

TCP
congestionamento
TCP
Evoluindo a funcionalidade da camada de
transporte
§ TCP, UDP: principais protocolos de transporte por 40 anos
§ diferentes “sabores” de TCP desenvolvidos, para cenários específicos:
Cenário Desafios
Tubos longos e gordos Muitos pacotes “em trânsito”; perda
(transferência de muitos dados) “desliga” o tubo
Redes Wireless Perda devido a enlaces wireless com
ruído, mobilidade; TCP trata como perda
por congestionamento
Enlaces com longos atrasos RTTs extremamente longos
Redes de Data center Sensível à latência
Fluxos de tráfego de fundo Fluxos TCP de baixa prioridade, de fundo
§ Mover funções da camada de transporte para a camada de aplicação, em
cima do UDP
• HTTP/3 (RFC 9114 – Junho 2022): QUIC (RFC 9000 – Maio 2021)
QUIC: Quick UDP Internet Connections
§ protocolo de camada de aplicação, acima do UDP
• aumenta o desempenho do HTTP
• implantado em muitos servidores Google, apps (Chrome, app YouTube móvel)
HTTP/2 HTTP/2 (simplificado)

Aplicação HTTP/3
TLS QUIC
Transporte TCP UDP
Rede IP IP
HTTP/2 sobre TCP HTTP/2 sobre QUIC sobre UDP

QUIC: Quick UDP Internet Connections
adota abordagens que estudamos neste capítulo para
estabelecimento de conexão, controle de erro, controle de
congestionamento
• controle de erro e de congestionamento: “Leitores familiarizados com a
detecção de perda e controle de congestionamento do TCP encontrarão aqui
algoritmos semelhantes aos do TCP.” [da especificação do QUIC]
• estabelecimento de conexão: confiabilidade, controle de congestionamento,
autenticação, criptografia, estado estabelecido em um RTT
§ múltiplos “fluxos” de aplicação multiplexados sobre uma única

conexão QUIC
• separa transferência confiável de dados, segurança
• controle de congestionamento comum
QUIC: estabelecimento de conexão
saudação TCP
(camada de transporte) saudação QUIC
dados
saudação TLS
(segurança)
dados
TCP (estado da confiabilidade, QUIC: estado da confiabilidade,

controle de congestionamento) + TLS controle de congestionamento,
(estado da autenticação, criptografia) autenticação, criptografia
§ 2 saudações em série § 1 saudação
Fluxos QUIC: paralelismo, sem bloqueio HOL
HTTP HTTP
GET GET HTTP
GET
aplicação
HTTP HTTP
GET GET
HTTP
GET QUIC QUIC QUIC QUIC QUIC QUIC
encrypt encrypt encrypt encrypt encrypt encrypt
QUIC QUIC QUIC QUIC QUIC QUIC
TLS encryption TLS encryption RDT RDT RDT RDT
error!
RDT RDT
QUIC Cong. Cont. QUIC Cong. Cont.

transporte
TCP RDT TCP

error! RDT
TCP Cong. Contr. TCP Cong. Contr. UDP UDP
(a) HTTP 1.1 (b) HTTP/2 com QUIC: sem bloqueio HOL
Capítulo 3: resumo
§ Princípios por trás dos A seguir:
serviços da camada de § deixaremos a “borda” da
transporte:
• multiplexação, demultiplexação rede (camadas aplicação,
transporte)
• transferência (confiável) de
dados § Entraremos no “núcleo”
• controle de fluxo da rede
• controle de congestionamento
§ dois capítulos sobre a
§ instanciação, implementação camada de rede:
na Internet
• plano de dados
• UDP
• TCP • plano de controle

Slides adicionais do Capítulo 3

Go-Back-N: FSM estendida do transmissor
rdt_send(data)
if (nextseqnum < base+N) {
sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum)
udt_send(sndpkt[nextseqnum])
if (base == nextseqnum)
start_timer
nextseqnum++
}
L else
refuse_data(data)
base=1
nextseqnum=1
timeout
start_timer
Wait udt_send(sndpkt[base])
rdt_rcv(rcvpkt) udt_send(sndpkt[base+1])
&& corrupt(rcvpkt) …
udt_send(sndpkt[nextseqnum-1])
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
If getacknum(rcvpkt)>=base
base = getacknum(rcvpkt)+1
If (base == nextseqnum)
stop_timer
else
start_timer Transport Layer: 3-143
Go-Back-N: FSM estendida do receptor
any other event
udt_send(sndpkt) rdt_rcv(rcvpkt)
L && hasseqnum(rcvpkt,expectedseqnum)
expectedseqnum=1 Wait extract(rcvpkt,data)
sndpkt = deliver_data(data)
make_pkt(expectedseqnum,ACK,chksum) sndpkt = make_pkt(expectedseqnum,ACK,chksum)
udt_send(sndpkt)
expectedseqnum++
Usa apenas ACKs: sempre envia ACK para pacote recebido

corretamente com o maior no. de seq. em-ordem
• pode gerar ACKs duplicados
• só precisa se lembrar do expectedseqnum
§ pacotes fora de ordem:
• descarta (não armazena): receptor sem buffers de reordenamento!
• reconhece pacote com o número de sequência mais alto em-ordem
Transmissor TCP (simplificado)
data received from application above
create segment, seq. #: NextSeqNum
pass segment to IP (i.e., “send”)
NextSeqNum = NextSeqNum + length(data)
if (timer currently not running)
L start timer
NextSeqNum = InitialSeqNum wait
SendBase = InitialSeqNum for
event timeout
retransmit not-yet-acked segment
with smallest seq. #
start timer
ACK received, with ACK field value y
if (y > SendBase) {
SendBase = y
/* SendBase–1: last cumulatively ACKed byte */
if (there are currently not-yet-acked segments)
start timer
else stop timer
}
TCP: FSM da saudação em 3 vias
closed
Socket connectionSocket =
welcomeSocket.accept();
L Socket clientSocket =
newSocket("hostname","port number");
SYN(x)
SYNACK(seq=y,ACKnum=x+1) SYN(seq=x)
create new socket for communication
back to client
listen
SYN
SYN sent
rcvd
SYNACK(seq=y,ACKnum=x+1)
ESTAB
ACK(ACKnum=y+1) ACK(ACKnum=y+1)
L

Encerrando uma conexão TCP
estado do cliente estado do servidor
ESTAB ESTAB
clientSocket.close()
FIN_WAIT_1 não pode mais FINbit=1, seq=x

enviar, mas pode
receber dados CLOSE_WAIT
ACKbit=1; ACKnum=x+1
ainda pode
FIN_WAIT_2 espera o servidor enviar dados
encerrar
LAST_ACK
FINbit=1, seq=y
TIMED_WAIT não pode mais
enviar dados
ACKbit=1; ACKnum=y+1
espera temporizada
por 2*tempo máximo CLOSED
de vida do segmento
CLOSED

Vazão TCP
§ Qual é a vazão média do TCP em função do tamanho da janela e do RTT?
• Ignore a partida lenta, assuma que sempre haja dados a serem transmitidos
§ Seja W o tamanho da janela (medida em bytes) quando ocorre uma perda
• Tamanho médio da janela é ¾ W
• Vazão média é de ¾ W por RTT
3 W
vazão média TCP = bytes/seg
4 RTT
W
W/2
TCP sobre “tubos longos e largos”
§ exemplo: segmentos de 1500 bytes, RTT de 100ms, deseja vazão de 10
Gbps
§ requer janela de W = 83.333 segmentos em trânsito
§ vazão em termos da probabilidade de perda de segmentos, L [Mathis 1997]:
vazão do TCP = 1,22 . MSS
RTT L
➜ para atingir uma vazão de 10Gbps, seria necessária uma taxa de

perdas L = 2·10-10 – uma taxa demasiado baixa!
§ versões do TCP para cenários longos, alta velocidade

Cap3 Kurose v8.0 2

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Cap3 Kurose v8.0 2

Enviado por

Direitos autorais:

Formatos disponíveis

Capítulo 3

Metas do capítulo: r aprender sobre os protocolos

• controle de congestionamento congestionamento do TCP

Transport Layer: 3-3

§ dois protocolos de transporte disponíveis

para as aplicações Internet: enterprise

§ camada de rede: comunicação Analogia doméstica:

Transport Layer: 3-7

Transport Layer: 3-8

§ TCP: Transmission Control Protocol mobile rede

§ serviços não disponíveis: rede

transporte rede transporte

Transport Layer: 3-11

transporte rede transporte

Transport Layer: 3-12

Transport Layer: 3-13

transporte rede transporte

Transport Layer: 3-14

transporte rede transporte

Transport Layer: 3-15

aplicação P1 P2 aplicação socket

r ao criar um datagrama para enviar

source port: 6428 source port: ?

source port: 9157 source port: ?

host: source IP,port: B,80 host:

§Multiplexação, demultiplexação: baseada nos valores dos

UDP: User Datagram Protocol

cliente SNMP servidor SNMP

rede (IP) rede (IP)

Transport Layer: 3-27

cliente SNMP servidor SNMP

rede (IP) § cria segmento UDP rede (IP)

Transport Layer: 3-28

cliente SNMP servidor SNMP

Transport Layer: 3-29

Formato do segmento UDP

Checksum Internet: Exemplo

Note que: ao adicionar números, o transbordo (vai um) do bit mais

Checksum Internet: proteção fraca!

transbordo 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 Apesar dos

§ protocolo “sem gorduras”:

abstração do serviço confiável

Transport Layer: 3-37

processo processo processo processo

implementação do serviço confiável

Transport Layer: 3-38

lado remetente lado destinatário

Transport Layer: 3-39

Remetente, receptor não lado remetente lado destinatário

§ a não ser que seja rede

Transport Layer: 3-40

canal não confiável

Transport Layer: 3-42

§ FSMs separadas para transmissor, receptor:

Espera rdt_send(data) rdt_rcv(packet)

Transport Layer: 3-43

Como as pessoas recuperam “erros” durante uma conversa?

Transport Layer: 3-44

rdt_rcv(rcvpkt) && isACK(rcvpkt)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

Transport Layer: 3-46

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Nota: “estado” do receptor (o receptor recebeu