Camada de Transporte

Capítulo 3: Camada de Transporte
Metas do capítulo:
r entender os r aprender sobre os
princípios atrás dos protocolos da camada
serviços da camada de transporte da
de transporte: Internet:
m multiplexação/
m UDP: transporte não
demultiplexação
orientado a conexões
m transferência
m TCP: transporte
confiável de dados
orientado a conexões
m controle de fluxo
m Controle de
m controle de congestionamento do
congestionamento TCP
3: Camada de Transporte 1
Conteúdo do Capítulo 3
r 3.1 Introdução e r 3.5 Transporte
serviços de camada de orientado para
transporte conexão: TCP
r 3.2 Multiplexação e r 3.6 Princípios de
demultiplexação controle de
r 3.3 Transporte não congestionamento
orientado para r 3.7 Controle de
conexão: UDP congestionamento no
r 3.4 Princípios da TCP
transferência
confiável de dados
Serviços e protocolos de transporte
r fornecem comunicação lógica aplicação
entre processos de aplicação transporte
rede
executando em diferentes enlace rede
hospedeiros física rede enlace
tr
enlace física
os protocolos de transporte são
a
r física
ns
executados nos sistemas finais:
po
rede
rt
enlace
m lado transmissor: quebra as
e
física
rede
ló
mensagens da aplicação em
gi
enlace
co
física
segmentos, repassa-os para a rede
fi
m
camada de rede enlace
a
física
fi
m lado receptor: remonta as
m
mensagens a partir dos aplicação
segmentos, repassa-as para a transporte
rede
camada de aplicação enlace
física
r existe mais de um protocolo de
transporte disponível para as
aplicações
m Internet: TCP e UDP
Camadas de Transporte x rede
Analogia doméstica:
r camada de rede:
12 crianças na casa de Ana
comunicação lógica enviando cartas para 12
entre hospedeiros crianças na casa de Bill
r camada de transporte: r hospedeiros = casas
processos = crianças
comunicação lógica r
r mensagens da apl. = cartas nos
entre os processos envelopes
m depende de e estende r protocolo de transporte = Ana
serviços da camada de e Bill que demultiplexam para
rede suas crianças
r protocolo da camada de rede =
serviço postal
Protocolos da camada de transporte Internet
r entrega confiável, ordenada aplicação

transporte
(TCP) rede
enlace rede
m controle de física rede enlace
tr
física
congestionamento enlace
a
física
ns
controle de fluxo
po
rede
m
rt
enlace
estabelecimento de conexão
e
física
m rede
ló
gi
(“setup”) enlace
co
física
rede
fi
r entrega não confiável, não
m
enlace
a
física
ordenada: UDP
fi
m
m extensão sem “gorduras” do aplicação
transporte
“melhor esforço” do IP rede
enlace
r serviços não disponíveis: física
m garantias de atraso máximo

m garantias de largura de
banda mínima
transferência
confiável de dados
Multiplexação/demultiplexação
Multiplexação no transm.:
reúne dados de muitos sockets,
adiciona o cabeçalho de transporte Demultiplexação no receptor:
(usado posteriormente para a Usa info do cabeçalho para
demultiplexação) entregar os segmentos
recebidos aos sockets corretos
aplicação
aplicação P1 P2 aplicação socket

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

o segmento UDP: de porta destino, mas
m verifica no. da porta de diferentes endereços IP
destino no segmento origem e/ou números de porta
m encaminha o segmento UDP origem podem ser
para o socket com aquele no. encaminhados para o mesmo
de porta socket no destino
Demultiplexação não orientada a
conexões: exemplo
DatagramSocket
serverSocket = new
DatagramSocket DatagramSocket
mySocket2 = new DatagramSocket
mySocket1 = new
DatagramSocket (6428); DatagramSocket
(9157); application (5775);
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
r Socket TCP identificado r Servidor pode dar suporte a
pela quádrupla: muitos sockets TCP
m endereço IP origem simultâneos:
m número da porta origem m cada socket é identificado
m endereço IP destino pela sua própria quádrupla
m número da porta destino r Servidores Web têm sockets
r Demultiplexação: diferentes para cada conexão
receptor usa todos os de cliente
quatro valores para m HTTP não persistente terá
direcionar o segmento sockets diferentes para cada
pedido
para o socket apropriado
Demultiplexação Orientada a
Conexões: exemplo
application
application
application
P4 P5 P6
P3 P2 P3
transport
transport transport
network
link physical link
physical server: IP physical
address B
host: IP source IP,port: B,80 host: IP

address A dest IP,port: A,9157 source IP,port: C,5775 address C
dest IP,port: B,80
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,
dest port: 80 são demultiplexados para sockets distintos 3: Camada de Transporte 12
Demultiplexação Orientada a Conexões:
Servidor Web com Threads
Servidor com threads
application
application application
P3 P4 P2 P3
transport
transport transport
network
link physical link
physical server: IP physical
address B
host: IP source IP,port: B,80 host: IP

address A dest IP,port: A,9157 source IP,port: C,5775 address C
dest IP,port: B,80
source IP,port: A,9157
dest IP, port: B,80
source IP,port: C,9157
dest IP,port: B,80
transferência
confiável de dados
UDP: User Datagram Protocol [RFC 768]
r Protocolo de transporte da r Uso do UDP:

Internet mínimo, “sem m aplicações de streaming
gorduras”, multimídia (tolerante a
r Serviço “melhor esforço”, perdas, sensível a taxas)
segmentos UDP podem ser: m DNS
m perdidos m SNMP
m entregues à aplicação fora
r transferência confiável
de ordem sobre UDP:
r sem conexão: m adiciona confiabilidade na
camada de aplicação
m não há saudação inicial m recuperação de erros
entre o remetente e o específica da aplicação
receptor UDP
m tratamento independente
para cada segmento UDP
UDP: Cabeçalho do segmento
Comprimento em bytes do
segmento UDP,
incluindo cabeçalho Por quê existe um UDP?
r elimina estabelecimento de
32 bits conexão (que pode causar
porta origem porta dest. retardo)
comprimento checksum r simples: não mantém
“estado” da conexão nem no
remetente, nem no
receptor
r cabeçalho de segmento
reduzido
Dados de
r Não há controle de
aplicação
congestionamento: UDP
(mensagem) pode transmitir tão rápido
quanto desejado (e
possível)
Formato do segmento UDP
Soma de Verificação (checksum)
UDP
Objetivo: detectar “erros” (ex.: bits trocados) no
segmento transmitido
Transmissor: Receptor:
r trata conteúdo do
r calcula checksum do
segmento como sequência
segmento recebido
de inteiros de 16-bits
r verifica se o checksum
r checksum: soma (adição
calculado bate com o valor
usando complemento de 1)
recebido:
do conteúdo do segmento
m NÃO - erro detectado
r transmissor coloca
complemento do valor da m SIM - nenhum erro
soma no campo checksum detectado. Mas ainda
do UDP pode ter erros? Veja
depois ….
Exemplo do Checksum Internet
r Exemplo: adição de dois inteiros de 16-bits
1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 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 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
soma de 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
verificação
Note que: ao adicionar números, o transbordo (vai um) do bit

mais significativo deve ser adicionado ao resultado
transferência
confiável de dados
Princípios de Transferência confiável de
dados (rdt)
r importante nas
camadas de
transporte e de
enlace
r na lista dos 10
tópicos mais
importantes em
redes!
r características
do canal não
confiável
determinam a
complexidade de
um protocolo de
transferência
confiável de
dados (rdt)
Transferência confiável: o ponto de
partida
rdt_send(): chamada de cima, (ex.: deliver_data(): chamada pelo
pela apl.). Passa dados p/ serem rdt para entregar dados p/ camada
entregues à camada sup. do receptor superior
lado lado
transmissor receptor
udt_send(): chamada pelo rdt para rdt_rcv(): chamada quando

transferir um pacotes para o pacote chega no lado receptor do
receptor sobre um canal não canal
confiável
Transferência confiável: o ponto de
partida
Iremos:
r desenvolver incrementalmente os lados transmissor e receptor
de um protocolo confiável de transferência de dados (rdt)
r considerar apenas fluxo unidirecional de dados
m mas info de controle flui em ambos os sentidos!
r Usar máquinas de estados finitos (FSM) p/ especificar os
protocolos transmissor e receptor
evento causador da transição de estado

ações executadas na transição de estado
estado: neste “estado”
o próximo estado é estado estado
1 evento
determinado 2
unicamente pelo ações
próximo evento
rdt1.0: transferência confiável sobre canais
confiáveis
r canal de transmissão
perfeitamente
confiável
m não há erros de bits
m não há perda de pacotes
r FSMs separadas para
transmissor e
receptor:
m transmissor envia dados
pelo canal subjacente
m receptor lê os dados do
canal subjacente
rdt2.0: canal com erros de bits
r canal subjacente pode trocar valores dos bits num pacote
m lembrete: checksum UDP pode detectar erros de bits
r a questão: como recuperar esses erros?
Como as pessoas recuperam “erros”

durante uma conversa?
rdt2.0: canal com erros de bits
r canal subjacente pode trocar valores dos bits num pacote
m lembre-se: checksum UDP pode detectar erros de bits
r a questão: como recuperar esses erros?
m reconhecimentos (ACKs): receptor avisa explicitamente ao
transmissor que o pacote foi recebido corretamente
m reconhecimentos negativos (NAKs): receptor avisa
explicitamente ao transmissor que o pacote tinha erros
m transmissor reenvia o pacote ao receber um NAK
r novos mecanismos no rdt2.0 (em relação ao rdt1.0):
m detecção de erros
m Realimentação (feedback): mensagens de controle (ACK,NAK) do
receptor para o transmissor
rdt2.0: especificação da FSM
Animação
no slide
seguinte!
rdt2.0: operação com ausência de
erros
rdt_send(data)
sndpkt = make_pkt(data, checksum)
udt_send(sndpkt) receptor
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for Wait for rdt_rcv(rcvpkt) &&
call from ACK or udt_send(sndpkt) corrupt(rcvpkt)
above NAK
udt_send(NAK)
rdt_rcv(rcvpkt) && isACK(rcvpkt)

Wait for
L call from
below
transmissor
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
rdt2.0: cenário de erro
rdt_send(data)
sndpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for Wait for rdt_rcv(rcvpkt) &&
call from ACK or udt_send(sndpkt) corrupt(rcvpkt)
above NAK
udt_send(NAK)
rdt_rcv(rcvpkt) && isACK(rcvpkt)

Wait for
L call from
below
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
deliver_data(data)
udt_send(ACK)
rdt2.0 tem uma falha fatal!
O que acontece se o Lidando c/ duplicatas:
ACK/NAK for r transmissor retransmite o
corrompido? último pacote se ACK/NAK
chegar com erro
r Transmissor não sabe o que
se passou no receptor! r transmissor inclui número
de sequência em cada
r não pode apenas pacote
retransmitir: possibilidade r receptor descarta (não
de pacotes duplicados entrega a aplicação)
pacotes duplicados
pare e espera
Transmissor envia um pacote,
e então aguarda resposta
do receptor
rdt2.1: transmissor, trata ACK/NAKs
corrompidos
rdt2.1: receptor, trata ACK/NAKs
corrompidos
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq0(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(NAK, chksum) sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
Esperar Esperar
rdt_rcv(rcvpkt) && 0 de 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:
r no. de seq no pacote r deve verificar se o
r bastam dois nos. de pacote recebido é uma
seq. (0,1). Por quê? duplicata
estado indica se no. de
r deve verificar se
m
seq. esperado é 0 ou 1
ACK/NAK recebidos
estão corrompidos r nota: receptor não tem
como saber se último
r duplicou o no. de
ACK/NAK foi recebido
estados
bem pelo transmissor
m estado deve “lembrar”
se pacote “esperado”
deve ter no. de seq. 0
ou 1
rdt2.2: um protocolo sem NAKs
r mesma funcionalidade do rdt2.1, usando

apenas ACKs
r ao invés de NAK, receptor envia ACK para
último pacote recebido sem erro
m receptor deve incluir explicitamente no. de seq
do pacote reconhecido
r ACKs duplicados no transmissor resultam
na mesma ação do NAK: retransmissão do
pacote atual
rdt2.2: fragmentos do transmissor e
receptor rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
aguarda aguarda
ACK isACK(rcvpkt,1) )
chamada 0
de cima 0 udt_send(sndpkt)
fragmento FSM
do transmissor rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && && isACK(rcvpkt,0)
(corrupt(rcvpkt) || L
has_seq1(rcvpkt)) aguarda fragmento FSM
0 de
udt_send(sndpkt) baixo do receptor
&& has_seq1(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK1, chksum)
udt_send(sndpkt)
rdt3.0: canais com erros e perdas
Nova hipótese: canal de Abordagem: transmissor

transmissão também aguarda um tempo
pode perder pacotes “razoável” pelo ACK
(dados ou ACKs) r retransmite se nenhum ACK
m checksum, no. de seq., for recebido neste intervalo
ACKs, retransmissões r se pacote (ou ACK) estiver
podem ajudar, mas não apenas atrasado (e não
são suficientes perdido):
m retransmissão será
duplicata, mas uso de no.
de seq. já cuida disto
m receptor deve especificar
no. de seq do pacote sendo
reconhecido
r requer temporizador
Transmissor rdt3.0
rdt3.0 em ação
rdt3.0 em ação
Remetente Destinatário
send pkt0 pkt0
rcv pkt0
ack0 send ack0
rcv ack0
send pkt1 pkt1
rcv pkt1
send ack1
ack1
timeout
resend pkt1 pkt1
rcv pkt1
rcv ack1 pkt0 (detect duplicate)
send pkt0 send ack1
ack1
rcv ack1 rcv pkt0
ack0 send ack0
ignora
(d) retransmissão prematura
Desempenho do rdt3.0
r rdt3.0 funciona, porém seu desempenho é sofrível

r Exemplo: enlace de 1 Gbps, retardo fim a fim de 15
ms, pacote de 8000 bits:
L 8000bits
dtrans = = 9
= 8 microsegundos
R 10 bps
U L/R 0,008
= = 8 = 0,00027
sender 30,008
RTT + L / R microsec
onds
r pac. de 1KB a cada 30 mseg -> vazão de 33kB/seg num
enlace de 1 Gbps
r protocolo limita uso dos recursos físicos!
rdt3.0: operação pare e espere
L/ R 0,008
U tx = = = 0,00027
RTT + L / R 30,008
Protocolos com paralelismo (pipelining)
Paralelismo (pipelining): transmissor envia vários
pacotes em sequência, todos esperando para
serem reconhecidos
m faixa de números de sequência deve ser aumentada
m Armazenamento no transmissor e/ou no receptor
(a) operação do protocolo pare e espere (a) operação do protocolo com paralelismo
r Duas formas genéricas de protocolos com paralelismo:

Go-back-N, retransmissão seletiva 3: Camada de Transporte 41
Paralelismo: aumento da utilização
Aumenta a utilização
por um fator de 3!
3´ L / R 0,024
U tx = = = 0,00081
RTT + L / R 30,008
Protocolos com Paralelismo
Go-back-N: Retransmissão seletiva:
r O transmissor pode ter até N r O transmissor pode ter até N
pacotes não reconhecidos no pacotes não reconhecidos no
“tubo” “tubo”
r Receptor envia apenas acks r Receptor envia acks
cumulativos individuais para cada pacote
m Não reconhece pacote se
houver falha de seq.
r Transmissor possui um
r Transmissor possui um
temporizador para o pacote
temporizador para cada
mais antigo ainda não
pacote ainda não reconhecido
reconhecido
m Se o temporizador
m Se o temporizador
estourar, retransmite
estourar, retransmite
apenas o pacote
todos os pacotes ainda não
correspondente.
reconhecidos.
Go-back-N (GBN)
Transmissor:
r no. de seq. de k-bits no cabeçalho do pacote
r admite “janela” de até N pacotes consecutivos não
reconhecidos
r ACK(n): reconhece todos pacotes, até e inclusive no. de seq n -

“ACK/reconhecimento cumulativo”
m pode receber ACKs duplicados (veja receptor)
r temporizador para o pacote mais antigo ainda não confirmado
r Estouro do temporizador: retransmite todos os pacotes
pendentes.
GBN: FSM estendida para o
transmissor
If getacknum(rcvpkt)>=base
GBN: FSM estendida para o
receptor
receptor simples:
r usa apenas ACK: sempre envia
ACK para pacote recebido
corretamente com o maior no.
de seq. em-ordem
m pode gerar ACKs duplicados
m só precisa se lembrar do
expectedseqnum
r pacotes fora de ordem:
m descarta (não armazena) ->
receptor não usa buffers!
m reconhece pacote com o
número de sequência mais alto
em-ordem
sender window (N=4) sender receiver
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 seletiva
r receptor reconhece individualmente todos os
pacotes recebidos corretamente
m armazena pacotes no buffer, conforme necessário, para
posterior entrega em-ordem à camada superior
r transmissor apenas reenvia pacotes para os quais
um ACK não foi recebido
m temporizador de remetente para cada pacote sem ACK
r janela do transmissão
m N números de sequência consecutivos
m outra vez limita números de sequência de pacotes
enviados, mas ainda não reconhecidos
Retransmissão seletiva: janelas do
transmissor e do receptor
reconhecido
Retransmissão seletiva
transmissor receptor
dados de cima: pacote n em
r se próx. no. de seq (n) [rcvbase, rcvbase+N-1]
disponível estiver na janela,
envia o pacote e liga r envia ACK(n)
temporizador(n)
r fora de ordem: armazena
estouro do temporizador(n):
r reenvia pacote n, reinicia r em ordem: entrega (tb.
temporizador(n) entrega pacotes
ACK(n) em [sendbase,sendbase+N]: armazenados em ordem),
r marca pacote n como avança janela p/ próxima
“recebido”
pacote ainda não recebido
r se n for menor pacote não
reconhecido, avança base da pacote n em
janela ao próx. no. de seq não [rcvbase-N,rcvbase-1]
reconhecido
r ACK(n)
senão:
r ignora
Retransmissão seletiva em ação
Retransmissão
seletiva: dilema
Exemplo:
r nos. de seq : 0, 1, 2, 3
r tam. de janela =3
r receptor não vê diferença

entre os dois cenários!
r incorretamente passa
dados duplicados como
novos em (a)
P: qual a relação entre

tamanho de no. de seq e
tamanho de janela?
r 3.2 Multiplexação e m estrutura do segmento
transferência confiável de
demultiplexação
m
dados
r 3.3 Transporte não m controle de fluxo
gerenciamento da conexão
orientado para m
conexão: UDP r 3.6 Princípios de

controle de
r 3.4 Princípios da
congestionamento
transferência
confiável de dados r 3.7 Controle de
congestionamento no
TCP
TCP: Visão geral RFCs: 793, 1122, 1323, 2018, 2581
r ponto a ponto: r transmissão full duplex:

m um transmissor, um receptor m fluxo de dados bi-direcional
r fluxo de bytes, ordenados, na mesma conexão
confiável: m MSS: tamanho máximo de
m não estruturado em msgs segmento
r com paralelismo (pipelined): r orientado a conexão:
tam. da janela ajustado por
m handshaking (troca de msgs
m
controle de fluxo e
congestionamento do TCP
de controle) inicia estado do
transmissor e do receptor
antes da troca de dados
r fluxo controlado:
m receptor não será afogado
pelo transmissor
Estrutura do segmento TCP
URG: dados urgentes contagem por

(pouco usado) bytes de dados
(não
ACK: campo de ACK
é válido segmentos!)
PSH: produz envio de

dados (pouco usado) número de bytes
receptor está
RST, SYN, FIN: pronto para
estabelec. de conexão aceitar
(comandos de
criação e término)
Internet
checksum
(como no UDP)
TCP: nos. de seq. e ACKs
segmento de saída do “transmissor”
source port # dest port #
Nos. de seq.: sequence number

acknowledgement number
m “número”dentro do rwnd
fluxo de bytes do checksum urg pointer
primeiro byte de dados window size

N
do segmento
ACKs:
m no. de seq do próx. byte sender sequence number space
esperado do outro lado

sent sent, not- usable not
m ACK cumulativo ACKed yet ACKed but not usable
(“in- yet sent
P: como receptor trata flight”)
segmentos fora da ordem? segmento que chega ao “transmissor”
source port # dest port #
m R: espec do TCP omissa sequence number
- deixado ao acknowledgement number
A rwnd
implementador checksum urg pointer
TCP: nos. de seq. e ACKs
cenário telnet simples
TCP: tempo de viagem de ida e volta (RTT –
Round Trip Time) e Temporização
P: como escolher o P: como estimar RTT?
valor do r SampleRTT: tempo medido entre
temporizador TCP? a transmissão do segmento e o
recebimento do ACK
r maior que o RTT
correspondente
m mas o RTT varia
m ignora retransmissões
r muito curto:
r SampleRTT varia de forma
temporização prematura
rápida, é desejável um
m retransmissões “amortecedor” para a estimativa
desnecessárias do RTT
r muito longo: reação m usa várias medições recentes,
demorada à perda de não apenas o último
segmentos SampleRTT obtido
TCP: Tempo de Resposta (RTT) e
Temporização
EstimatedRTT = (1-a)* EstimatedRTT + a*SampleRTT
r média móvel exponencialmente ponderada
r influência de cada amostra diminui exponencialmente com o
tempo
r valor típico de a = 0,125
TCP: Tempo de Resposta (RTT) e
Temporização
Escolhendo o intervalo de temporização
r EstimatedRTT mais uma “margem de segurança”
m grandes variações no EstimatedRTT
-> maior margem de segurança
r primeiro estimar o quanto a SampleRTT se desvia do
EstimatedRTT:
DevRTT = (1-b)* DevRTT +

b*|SampleRTT - EstimatedRTT|
(valor típico de b = 0,25)

r Então, ajusta o temporizador para:
TimeoutInterval = EstimatedRTT + 4*DevRTT
RTT estimado “margem de segurança”

demultiplexação
m
dados
orientado para m

controle de
congestionamento
transferência
congestionamento no
TCP
Transferência de dados confiável
do TCP
r O TCP cria um serviço r As retransmissões são
rdt sobre o serviço não disparadas por:
confiável do IP m estouros de
m Segmentos transmitidos temporização
em “paralelo” (pipelined) m acks duplicados
m Acks cumulativos r Considere inicialmente
m O TCP usa um único um transmissor TCP
temporizador para simplificado:
retransmissões
m ignore acks duplicados
m ignore controles de
fluxo e de
congestionamento
Eventos do transmissor TCP
Dados recebidos da aplicação: Estouro do temporizador:
r Cria segmento com no. de r Retransmite o segmento
sequência (nseq) que causou o estouro do
r nseq é o número de temporizador
sequência do primeiro byte r Reinicia o temporizador
de dados do segmento Recepção de Ack:
r Liga o temporizador se já r Se reconhecer segmentos
não estiver ligado ainda não reconhecidos
(temporização do segmento m atualizar informação sobre
mais antigo ainda não o que foi reconhecido
reconhecido) m religa o temporizador se
r Valor do temporizador: ainda houver segmentos
calculado anteriormente pendentes (não
reconhecidos)
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
} 3: Camada de Transporte 64
TCP: cenários de retransmissão
Religa
Religa temporização
temporização
Religa
temporização
Desliga
temporização
Desliga
temporização
Cenário com perda Temporização prematura,

do ACK ACKs cumulativos
TCP: cenários de retransmissão
(mais)
Desliga
temporização
Seq=120, 15 bytes of data
Cenário de ACK cumulativo
TCP geração de ACKs [RFCs 1122, 2581]
Evento no Receptor Ação do Receptor TCP

chegada de segmento em ordem ACK retardado. Espera até 500ms
sem lacunas, pelo próx. segmento. Se não chegar
anteriores já reconhecidos segmento, envia ACK
chegada de segmento em ordem envia imediatamente um único

sem lacunas, ACK cumulativo
um ACK retardado pendente
chegada de segmento fora de envia ACK duplicado, indicando no.

ordem, com no. de seq. maior de seq.do próximo byte esperado
que esperado -> lacuna
chegada de segmento que ACK imediato se segmento começa

preenche a lacuna parcial ou no início da lacuna
completamente
Retransmissão rápida do TCP
r O intervalo do
temporizador é retx rápida do TCP
frequentemente bastante se o transmissor receber 3
longo: ACKs para os mesmos dados
m longo atraso antes de
retransmitir um pacote (“três ACKs duplicados”),
perdido retransmite segmentos não
r Detecta segmentos reconhecidos com menores
perdidos através de ACKs nos. de seq.
duplicados. § provavelmente o
m O transmissor segmento não
normalmente envia reconhecido se perdeu,
diversos segmentos
não é preciso esperar o
m Se um segmento se temporizador.
perder, provavelmente
haverá muitos ACKs
duplicados.
Host A Host B

X
ACK=100
ACK=100
ACK=100
timeout
ACK=100
Retransmissão de um segmento após três ACKs duplicados

demultiplexação
m
dados
orientado para m

controle de
congestionamento
transferência
congestionamento no
TCP
Controle de Fluxo
do TCP processo
de aplicação
a aplicação pode remover dados
dos buffers do socket TCP …. aplicação
Buffers de recepção SO
do socket TCP
… mais devagar do
que o receptor TCP
está entregando TCP
(transmissor está code
enviando)
IP
Controle de fluxo code
o receptor controla o
transmissor, de modo que
este não inunde o buffer do do transmissor
receptor transmitindo muito pilha de protocolos no receptor

e rapidamente
Controle de Fluxo do TCP:
como funciona
r O receptor “anuncia” o espaço livre
do buffer incluindo o valor da rwnd
nos cabeçalhos TCP dos segmentos para processo de aplicação
que saem do receptor para o
transmissor
RcvBuffer dados armazenados
m Tamanho do RcvBuffer é
configurado através das opções do
socket (o valor default é de 4096 rwnd espaço livre
bytes)
m muitos sistemas operacionais ajustam
RcvBuffer automaticamente.
carga dos segmentos TCP
r O transmissor limita a quantidade
os dados não reconhecidos ao
tamanho do rwnd recebido. armazenamento no
lado do receptor
r Garante que o buffer do receptor
não transbordará
demultiplexação
m
dados
orientado para m

controle de
congestionamento
transferência
congestionamento no
TCP
TCP: Gerenciamento de Conexões
antes de trocar dados, transmissor e receptor TCP dialogam:
r concordam em estabelecer uma conexão (cada um sabendo
que o outro quer estabelecer a conexão)
r concordam com os parâmetros da conexão.
aplicação aplicação
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
network network
Socket clientSocket = Socket connectionSocket =

newSocket("hostname","port welcomeSocket.accept();
number");
Concordando em estabelecer uma conexão
Apresentação de duas vias

(2-way handshake):
P: a apresentação em duas
vias sempre funciona em
redes?
Let’s talk
ESTAB r atrasos variáveis
OK
ESTAB r mensagens retransmitidas
(ex: req_conn(x)) devido à
perda de mensagem
r reordenação de mensagens
choose x r não consegue ver o outro lado
req_conn(x)
ESTAB
acc_conn(x)
ESTAB
Concordando em estabelecer uma conexão
cenários de falha da apresentação de duas vias:
escolhe x escolhe x
req_conn(x) req_conn(x)
ESTAB ESTAB
retransmite acc_conn(x) retransmite acc_conn(x)
req_conn(x) req_conn(x)
ESTAB ESTAB
data(x+1) aceita
req_conn(x)
retransmite dados(x+1)
dados(x+1)
término da término da
cliente conexão x servidor conexão x servidor
cliente
termina esquece x termina esquece x
req_conn(x)
ESTAB ESTAB
data(x+1) aceita
conexão aberta pela metade! dados(x+1)
(sem cliente!)
Apresentação de três vias do TCP
estado do cliente estado do servidor

LISTEN LISTEN
escolhe no seq inicial, x
envia msg TCP SYN
SYNSENT SYNbit=1, Seq=x
escolhe no seq inicial, y
envia msg SYNACK,
reconhecendo o SYN SYN RCVD
SYNbit=1, Seq=y
ACKbit=1; ACKnum=x+1
SYNACK(x) recebido
ESTAB Indica que o servidor está
ativo;
envia ACK para SYNACK; ACKbit=1, ACKnum=y+1
este segmento pode conter
dados do cliente para ACK(y) recebido
servidor indica que o cliente está
ativo ESTAB
Apresentação de três vias do TCP
closed
Socket connectionSocket =
welcomeSocket.accept();
L Socket clientSocket =
SYN(x) newSocket("hostname","port
number");
SYNACK(seq=y,ACKnum=x+1)
cria novo socket para SYN(seq=x)
comunicação com o cliente listen
SYN SYN
rcvd sent
SYNACK(seq=y,ACKnum=x+1)
ESTAB ACK(ACKnum=y+1)
ACK(ACKnum=y+1)
L
TCP: Encerrando uma conexão
r seja o cliente que o servidor fecham cada um o seu
lado da conexão
m enviam segmento TCP com bit FIN = 1
r respondem ao FIN recebido com um ACK
m ao receber um FIN, ACK pode ser combinado com o
próprio FIN
r lida com trocas de FIN simultâneos
TCP: Encerrando uma conexão
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 término enviar dados
pelo servidor
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
transferência
confiável de dados
Princípios de Controle de
Congestionamento
Congestionamento:
r informalmente: “muitas fontes enviando dados
acima da capacidade da rede de tratá-los”
r diferente de controle de fluxo!
r Sintomas:
m perda de pacotes (saturação de buffers nos
roteadores)
m longos atrasos (enfileiramento nos buffers dos
roteadores)
r um dos 10 problemas mais importantes em redes!
Causas/custos de congestionamento:
cenário 1
r dois remetentes,
dois receptores
r um roteador,
buffers infinitos
r sem retransmissão
r capacidade do link
de saída: R
Vazão máxima por Grandes atrasos qdo. taxa

conexão: R/2 de chegada se aproxima da
capacidade 3: Camada de Transporte 83
Causas/custos de congest.: cenário 2
r Um roteador, buffers finitos
r retransmissão pelo remetente de pacote perdido
m entrada camada apl. = saída camada apl.: lin = lout
m entrada camada transp. inclui retransmissões.: l’in ≥ lout
Hospedeiro A l : dados originais lout

in Hospedeiro C
l'in : dados originais mais
dados retransmitidos
Hospedeiro B Buffers de enlace de saída

finitos compartilhados
Hospedeiro D
Idealização: conhecimento R/2
perfeito
lout
r transmissor envia apenas
quando houver buffer
disponível no roteador lin R/2
Hospedeiro A l : dados originais lout

in Hospedeiro C
cópia l'in : dados originais mais

Hospedeiro B
espaço livre em buffer!
Buffers de enlace de Hospedeiro D

saída finitos
compartilhados
Idealização: perda conhecida.
pacotes podem ser perdidos,
descartados no roteador devido a
buffers cheios
r transmissor apenas retransmite
se o pacote sabidamente se
perdeu.
lin : dados originais
cópia l'in : dados originais mais lout

Hospedeiro B
sem espaço em buffer!

A
Hospedeiro D
Idealização: perda conhecida. R/2
pacotes podem ser perdidos,
descartados no roteador devido a ao transmitir a R/2,
alguns pacotes são
buffers cheios
lout
retransmissões, mas
r transmissor apenas retransmite assintoticamente a
goodput ainda seria
se o pacote sabidamente se R/2 (por que?)
lin R/2
perdeu.
l'in : dados originais mais lout

Hospedeiro B

A
Hospedeiro D
Realidade: duplicatas R/2
r pacotes podem ser perdidos,
descartados no roteador devido ao transmitir a R/2,
alguns pacotes são
lout
a buffers cheios retransmissões
incluindo duplicatas
r retransmissão prematura, envio que são entregues!
de duas cópias, ambas entregues. R/2
lin
timeout l'in : dados originais mais lout

Hospedeiro B

A
Hospedeiro D
Realidade: duplicatas R/2
r pacotes podem ser perdidos,
descartados no roteador devido ao transmitir a R/2,
alguns pacotes são
lout
a buffers cheios retransmissões
incluindo duplicatas
r retransmissão prematura, envio que são entregues!
de duas cópias, ambas entregues. R/2
lin
“custos” do congestionamento:
• mais trabalho (retransmissões) para uma dada “goodput”
• Retransmissões desnecessárias: link transporta múltiplas cópias
do pacote
• diminuindo a “goodput”
cenário 3 P: o que acontece à medida que lin e
r quatro remetentes l’in crescem ?
r caminhos com múltiplos R: à medida que l’in vermelho
enlaces cresce, todos os pacotes azuis
r temporização/ que chegam à fila superior são
retransmissão descartados, vazão azul -> 0
lout
l'in : dados originais mais
Buffers de enlace de saída
finitos compartilhados
cenário 3
R/2
Outro “custo” de congestionamento:

r quando pacote é descartado, qq. capacidade de transmissão
já usada (antes do descarte) para esse pacote foi
desperdiçada!
transferência
confiável de dados
Controle de Congestionamento do
TCP: aumento aditivo, diminuição multiplicativa
r Abordagem: aumentar a taxa de transmissão
(tamanho da janela), testando a largura de banda
utilizável, até que ocorra uma perda
m aumento aditivo: incrementa cwnd de 1 MSS a cada RTT
até detectar uma perda
m diminuição multiplicativa: corta cwnd pela metade após
evento de perda
Comportamento de
dente de serra:
testando a largura
de banda
93
Controle de Congestionamento do
TCP: detalhes
sender sequence number space Taxa de transmissão do TCP:
cwnd
r aproximadamente: envia uma
janela (cwnd), espera RTT
para os ACKs, depois envia
mais bytes
last byte last byte
ACKed sent, not- sent
yet ACKed
taxa = cwnd
(“in-
flight”)
bytes/seg
RTT
r transmissor limita a transmissão:
LastByteSent-LastByteAcked
£ cwnd
r cwnd é dinâmica, em função do
congestionamento detectado na rede
TCP: Partida lenta
r no início da conexão, aumenta A B
a taxa exponencialmente até
o primeiro evento de perda: um segme
nto
RTT
m inicialmente cwnd = 1
MSS dois segm
entos
m duplica cwnd a cada RTT
m através do incremento da
cwnd para cada ACK quatro seg
recebido mentos
r resumo: taxa inicial é baixa

mas cresce rapidamente de
forma exponencial
tempo
TCP: detectando, reagindo a perdas
r perda indicada pelo estouro de temporizador:

m cwnd é reduzida a 1 MSS;
m janela cresce exponencialmente (como na partida

lenta) até um limiar, depois cresce linearmente
r perda indicada por ACKs duplicados: TCP RENO
m ACKs duplicados indicam que a rede é capaz de
entregar alguns segmentos
m corta cwnd pela metade depois cresce
linearmente
r O TCP Tahoe sempre reduz a cwnd para 1 (seja por
estouro de temporizador que três ACKS duplicados)
TCP: mudando da partida lenta para a CA
P: Quando o crescimento
exponencial deve
mudar para linear?
R: Quando cwnd atingir
1/2 do seu valor antes
da detecção de perda.
Implementação:
r Limiar (Threshold) variável
(ssthresh)
r Com uma perda o limiar
(ssthresh) é ajustado para
1/2 da cwnd imediatamente
antes do evento de perda.
Controle de congestionamento do
transmissor TCP
Novo
Novo ACK!
ACK!
ACK duplicado
dupACKcount++ novo ACK
.
novo 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
lenta de
timeout
ssthresh = cwnd/2 congest.
cwnd = 1 MSS ACK duplicado
timeout dupACKcount = 0 dupACKcount++
ssthresh = cwnd/2 retransmite os segmentos que faltam
cwnd = 1 MSS
dupACKcount = 0
retransmite os segmentos que faltam
timeout
Novo
ACK!
ssthresh = cwnd/2
cwnd = 1 Novo ACK
dupACKcount = 0
cwnd = ssthresh dupACKcount == 3
dupACKcount == 3 retransmite os segmentos que faltam dupACKcount = 0
ssthresh= cwnd/2 ssthresh= cwnd/2
cwnd = ssthresh + 3 cwnd = ssthresh + 3
retransmite os segmentos que faltam retransmite os segmentos que faltam
recuperação
rápida
ACK duplicado
cwnd = cwnd + MSS
transmite novos segmentos, como permitido
Vazão (throughput) do TCP
r Qual é a vazão média do TCP em função do tamanho da janela
e do RTT?
m Ignore a partida lenta, assuma que sempre haja dados a serem
transmitidos
r Seja W o tamanho da janela (medida em bytes) quando ocorre uma
perda
m Tamanho médio da janela é ¾ W
m Vazão média é de ¾ W por RTT
W
W/2
Futuro do TCP: TCP em “tubos
longos e largos”
r exemplo: segmentos de 1500 bytes, RTT de 100ms,
deseja vazão de 10 Gbps
r Requer janela de W = 83.333 segmentos em
trânsito
r Vazão em termos de taxa de perdas (L) [Mathis 1997]:
1,22 × MSS
vazão do TCP =
RTT L
➜ para atingir uma vazão de 10Gbps, seria necessária uma taxa de
perdas L = 2·10-10 demasiado baixa!!!
r São necessárias novas versões do TCP para altas
velocidades!
Equidade (Fairness) do TCP
objetivo de equidade: se K sessões TCP compartilham

o mesmo enlace de gargalo com largura de banda R,
cada uma deve obter uma taxa média de R/K
Conexão TCP 1
Roteador
com gargalo, de
Conexão capacidade R
TCP 2

Por que o TCP é justo?
Duas sessões competindo pela banda:
r Aumento aditivo dá gradiente de 1, enquanto vazão aumenta
r Redução multiplicativa diminui vazão proporcionalmente
R compartilhamento igual da banda

Vazão da conexão 2
perda: diminui janela por fator de 2

prevenção de congest.: aumento aditivo
perda: diminui janela por fator de 2
prevenção de congest.: aumento aditivo
Vazão da conexão 1 R
Equidade (mais)
Equidade e UDP Equidade e conexões TCP em
paralelo
r aplicações multimídia
frequentemente não usam r nada impede que as apls. abram
TCP conexões paralelas entre 2
m não querem a taxa hosts
estrangulada pelo controle r os browsers Web fazem isto
de congestionamento r exemplo: canal com taxa R
r preferem usar o UDP: compartilhado por 9 conexões;
m injetam áudio/vídeo a m novas aplicações pedem 1 TCP,
taxas constantes, toleram obtém taxa de R/10
perdas de pacotes m novas aplicações pedem 11 TCPs,
obtém taxa R/2 !

Notificação Explícita de Congestionamento
(ECN)
controle de congestionamento assistido pela rede:

§ dois bits no cabeçalho IP (campo ToS) são marcados pelo
roteador de rede para indicar o congestionamento
§ indicação de congestionamento é levada até o receptor
§ o receptor (vendo a indicação de congestionamento) seta o
bit ECE no segmento de reconhecimento para notificar o
transmissor sobre o congestionamento.
segmento TCP de ACK

origem (nova flag) destino
aplicação aplicação
ECE=1
transporte transporte
rede rede
enlace enlace
física física
ECN=00 ECN=11
datagrama IP Transport Layer 3-104

Capítulo 3: Resumo
r Princípios por trás dos

serviços da camada de
transporte: Próximo capítulo:
m multiplexação/ r saímos da “borda” da
demultiplexação rede (camadas de
m transferência confiável de
aplicação e transporte)
dados r entramos no “núcleo”
m controle de fluxo
da rede
m controle de congestionamento
r dois capítulos sobre a
camada de rede:
r instanciação e implementação na
m plano de dados
Internet m plano de controle
m UDP
m TCP

Camada de Transporte

Enviado por

Dados do documento

Descrição 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

Camada de Transporte

Enviado por

Direitos autorais:

Formatos disponíveis

Capítulo 3: Camada de Transporte

r entrega confiável, ordenada aplicação

m garantias de atraso máximo

aplicação P1 P2 aplicação socket

r Quando o hospedeiro recebe r Datagramas IP com mesmo no.

source port: 6428 source port: ?

source port: 9157 source port: ?

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

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

r Protocolo de transporte da r Uso do UDP:

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

udt_send(): chamada pelo rdt para rdt_rcv(): chamada quando

evento causador da transição de estado

r a questão: como recuperar esses erros?

Como as pessoas recuperam “erros”

rdt_rcv(rcvpkt) && isACK(rcvpkt)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

r mesma funcionalidade do rdt2.1, usando

Nova hipótese: canal de Abordagem: transmissor

(d) retransmissão prematura

r rdt3.0 funciona, porém seu desempenho é sofrível

r Duas formas genéricas de protocolos com paralelismo:

r ACK(n): reconhece todos pacotes, até e inclusive no. de seq n -

r receptor não vê diferença

P: qual a relação entre

conexão: UDP r 3.6 Princípios de

r ponto a ponto: r transmissão full duplex:

URG: dados urgentes contagem por

PSH: produz envio de

Nos. de seq.: sequence number

fluxo de bytes do checksum urg pointer

primeiro byte de dados window size

esperado do outro lado

cenário telnet simples

DevRTT = (1-b)* DevRTT +

(valor típico de b = 0,25)

RTT estimado “margem de segurança”

conexão: UDP r 3.6 Princípios de

Cenário com perda Temporização prematura,

Cenário de ACK cumulativo

Evento no Receptor Ação do Receptor TCP

chegada de segmento em ordem envia imediatamente um único

chegada de segmento fora de envia ACK duplicado, indicando no.

chegada de segmento que ACK imediato se segmento começa

Seq=92, 8 bytes of data

Retransmissão de um segmento após três ACKs duplicados

conexão: UDP r 3.6 Princípios de

receptor transmitindo muito pilha de protocolos no receptor

conexão: UDP r 3.6 Princípios de

estado conexão: ESTAB estado conexão: ESTAB

Socket clientSocket = Socket connectionSocket =

Apresentação de duas vias

cenários de falha da apresentação de duas vias:

estado do cliente estado do servidor

FIN_WAIT_1 não pode mais FINbit=1, seq=x

Vazão máxima por Grandes atrasos qdo. taxa

Hospedeiro A l : dados originais lout

Hospedeiro B Buffers de enlace de saída

Hospedeiro A l : dados originais lout

cópia l'in : dados originais mais

espaço livre em buffer!

Buffers de enlace de Hospedeiro D

cópia l'in : dados originais mais lout