RC-2011-2-Parte-Transporte

Prévia do material em texto

Redes de Computadores
Camada de Transporte
 
Camada de Transporte:
Objetivos
● Aspectos conceituais 
● Papel da camada de transporte
● Protocolo UDP
● Protocolo TCP
● Modelos
● TCP (fluido?)
 
Problema
● diferentes tecnologias 
possíveis para conectar um 
conjunto de máquinas
● LAN, WAN, inter-redes, ...
● serviço de entrega de 
mensagens máquina a máquina
● como passar este serviço a um 
canal de comunicação processo a 
processo?
AplicaçãoAplicação
? ? ?? ? ?
rederede
(internet)(internet)
acesso a redeacesso a rede
(host-to-network)(host-to-network)
 
Fonte: Kurose e Ross, Computer Networking: A Top-Down Approach
 
Protocolos de transporte
Fornecem comunicação lógica entre processos 
de aplicação em diferentes hospedeiros 
Os protocolos de transporte são executadosnos 
sistemas finais
Lado emissor: quebra as mensagens da 
aplicação em segmentos e envia para a camada 
de rede
Lado receptor: remonta os segmentos em 
mensagens e passa para a camada de aplicação
 
Sistema de comunicação
Serviços oferecido pelo IP
 roteamento através de uma interconexão de redes
 fragmentação / remontagem
 serviço não conectado e de “melhor esforço” (best 
effort)
Desafios
• levar em conta o 
serviço fornecido 
pela camada de rede
• perda de pacotes• desordenamento• duplicações• erros• MTU• atrasos fim-a-fim 
imprevisíveis
• ...
• levar em conta a necessidade 
das aplicações
• garantia de entrega das 
mensagens
• ordenamento• ausência de duplicações• ausência de mensagens erradas• mensagens de qualquer tamanho• sincronização entre emissor e 
receptor
• controle de fluxo do receptor 
sobre emissor
• suporte a diversas aplicações no 
mesmo hospedeiro
• ...
Papel da camada de 
transporte
• Transformar as propriedades nem 
sempre desejáveis da rede em um 
serviço de alto nível desejável pelas 
aplicações
• Há mais de um protocolo de 
transporte disponível para as 
aplicações
• Internet: TCP e UDP
Multiplexação / 
demultiplexação
• Problema:
• como identificar um processo 
(aplicação)?
• número de porta associado ao socket 
ligando a camada de aplicação
e camada de transporte
(ver camada de aplicação)
Multiplexação 
no emissor
coleta dados de 
múltiplos sockets, 
envelopa os dados com 
cabeçalho (usado depois 
para demultiplexação)
Demultiplexação 
no receptor
entrega os segmentos 
recebidos ao socket 
correto
Fonte: Kurose e Ross, Computer Networking: A Top-Down Approach
Protocolos da Camada 
de Transporte
• User Datagram Protocol
• Transport Control Protocol
UDP
• Protocolo de transporte da 
Internet com baixo overhead
• Se contenta de estender
• um serviço de entrega máquina a 
máquina
• em um serviço de entrega 
processo a processo
Serviço UDP
• Serviço best effort
• como na camada de rede
• Segmentos UDP podem ser:
• perdidos
• entregues fora de ordem para a aplicação
Serviço UDP
• Serviço sem conexão
• Não há apresentação entre o UDP transmissor e o 
receptor
• Cada segmento UDP é tratado de forma independente
• Por que existe UDP ?
• Sem estabelecimento de conexão (que possa causar em 
atrasos)
• Não há estado de conexão nem no transmissor, nem no 
receptor
• Cabeçalho de segmento reduzido
• Não há controle de congestionamento: UDP pode enviar 
segmentos tão rápido quanto desejado (e possível)
Datagrama UDP
• Funcionalidades além da (de)multiplexação?
• detecção de erros
Protocolos da Camada 
de Transporte
• User Datagram Protocol
• Transport Control Protocol
TCP
Oferece um
 serviço de entrega
• em modo 
conectado
• confiável
• full-duplex
• de fluxo de bytes 
(bytestream)
Implementa mecanismos de
•(de)multiplexação
•gerenciamento de 
conexões
•controle de erro
•controle de fluxo
•controle de 
congestionamento
Comparação com enlace de 
dados (0/5)
Nos próximos slides para cada um de 5 aspectos 
considerados...
característica para enlace de dados ponto-a-
ponto real 
situação encontrada pelo TCP na prática
problema imposto ao TCP
Comparação com enlace de 
dados (1/5)
1.Gerenciamento de conexões
um enlace ponto a ponto é construído sobre um 
canal físico conectando sempre os 2 mesmos 
sistemas finais
TCP suporta conexões entre 2 processos 
executando em quaisquer hospedeiros da 
Internet
estabelecimento de conexão mais complexo
Comparação com enlace de 
dados (2/5)
2.RTT (Round Trip Time)
praticamente constante sobre um enlace
varia em função do momento da conexão e da 
“distância” separando os 2 hospedeiros
dimensionamento do temporisador de 
retransmissão
Comparação com enlace de 
dados (3/5)
3.Unidades de dados
não se duplicam no meio de transmissão
podem ser duplicadas e ser retardadas de 
maneira imprevisível na rede
TCP deve lidar com atrasos imprevisíveis e 
duplicações
Comparação com enlace de 
dados (4/5)
4.buffers de recepção
são próprios a cada enlace
recursos são compartilhados entre todas as 
conexões abertas
TCP deve adotar controle de fluxo
Comparação com enlace de 
dados (5/5)
5.Congestionamento
de enlace de dados não pode ocorrer sem 
que o emissor perceba
de rede pode ocorrer sem que
o emissor perceba
TCP deve adotar controle de 
congestionamento com base em indícios 
indiretos de congestionamento
Fluxo de Bytes
• TCP é orientado a bytes
• processo emissor “escreve” bytes sobre a 
conexão TCP
• processo receptor “lê” bytes da conexão TCP
Fluxo de Bytes
• TCP não transmite bytes individualmente
• em emissão
• TCP armazena os bytes até ter um número 
razoável para transmitir
• TCP cria um segmento e o envia
• em recepção
• TCP armazena o conteúdo do segmento 
recebido em um buffer de recepção
• o processo destinatário lê os bytes a seu 
critério
Fluxo de Bytes
O segmento TCP
Gerenciamento de conexão
• Emissor e receptor TCP estabelecem uma 
conexão antes de trocar segmentos
• A conexão inicia variáveis TCP:
• números de seqüência
• buffers
• informação de controle de fluxo (ex. 
janela de recepção)
Three-way handshake
Participante 
ativo
(cliente)
Participante 
passivo
(servidor)
Transferência de dados
•TCP assegura uma transferência de 
dados fim-a-fim confiável
•controle de fluxo
•controle de erro
Controle de fluxo
• Receptor TCP dispõe de recursos (buffers) em 
quantidade limitada
• O tamanho da janela (de recepção) anunciada reflete a 
disponibilidade do buffer de recepção
• Receptor TCP gerencia um número de conexões 
variável
Janela dinâmica campo window 
indica o número de bytes de 
dados que o receptor está apto a 
receber
 indica o número de bytes de 
dados que o receptor está apto a 
receber
Buffer de emissão
• Em emissão, um buffer armazena
• os dados enviados e a espera de confirmação (ACK)
• os dados passados pelo processo emissor, mas não 
ainda enviados
Buffer de recepção
• Em recepção, um buffer armazenaos dados 
(ordenados) que ainda não foram lidos pelo 
processo receptoros dados fora de seqüência
• os dados (ordenados) que ainda não foram lidos 
pelo processo receptoros dados fora de 
seqüência
Controle de erro
• Controle de erro baseado
• no campo Checksum
• no campo SequenceNumber
• confirmações (ACKs) positivas
(dumb receiver: sem confirmações negativas)
• um temporizador de retransmissão
• retransmissões
• RTT variável (e imprevisível)
• dimensionamento dinâmico do temporizador 
de retransmissão
Dimensionamento dinâmico 
do temporizador
transmissão
retransmissão
transmissão
retransmissão
X
subestimativa do RTT superestimativa do RTT
pacotes duplicadosACK
Ineficiencia na retransmissao
Dimensionamento dinâmico 
do temporizador
• TCP calcula uma estimativa do RTT por uma média ponderada entre a 
estimativa previamente calculada e a última amostra medida do RTT
EstimatedRTT ⬅ α EstimatedRTT + (1 – α) SampleRTT
• SampleRTT é obtido medindo o atraso separando a emissão de um 
segmento e a recepção de sua confirmação
• 0,8 < α < 0,9 
• TCP calcula o valor do temporizador
• TimeOut min(UBOUND, max(LBOUND, β EstimatedRTT))⬅
• UBOUND é um limite superior sobre o temporizador (ex. 60 s)
LBOUND é um limite inferior sobre o temporizador (ex. 1 s)
• 1,3 ≤ β ≤ 2 
Algoritmo de Karn-Patridge
• Somente mede SampleRTT para os segmentos 
enviados uma única vez
• Cálculo do TimeOut
• a cada retransmissão, dobra o valor de 
TimeOut até que a retransmissão seja bem 
sucedida
• para os segmentos seguintes, conserva o valor 
de TimeOut até que um segmento seja 
confirmado na 1a. transmissão
• recalcula TimeOut a partir do EstimatedRTT
Exemplo de estimativa do 
RTT
Princípios de controle de 
congestionamento
Congestionamento
•Informalmente: “fontes demais enviando dados 
demais rápido demais para a rede tratar” 
•Diferente de controle de fluxo!
•Sintomas
• perdas de pacotes (saturação de buffers nos 
roteadores)
• atrasos grandes (filas nos roteadores) 
Causas/custos do 
congestionamento
• Dois transmissores,
dois receptores
• Um roteador, 
buffers infinitos
• Não há 
retransmissão
• Grandes atrasos 
quando congestionado
• Máxima vazão 
alcançável
Causas/custos do 
congestionamento
• Um roteador, buffers finitos
• Transmissor reenvia pacotes perdidos
Causas/custos do 
congestionamento
• “Custos”do congestionamento
• mais trabalho (retransmissões) para um 
mesmo goodput efetivo
• retransmissões desnecessárias: cópias 
inúteis do mesmo pacote nos enlaces
causando mais congestionamento!
Controle de 
congestionamento
• TCP adapta sua taxa de transmissão usando 
uma janela CongestionWindow controlada 
pelo emissor baseado no estado atual de 
congestionamento
MaxWindow MIN(CongestionWindow, AdvertisedWindow)⬅
EffectiveWindow MaxWindow – (LastByteSend – LastByteAcked)⬅
MaxWindow substitui AdvertisedWindow no cálculo de EffectiveWindow
para convívio harmonioso de controle de fluxo e de 
congestionamento
Controle de 
congestionamento
• Controle fim-a-fim
(sem informações diretas da rede)
• Aproximadamente,
• CongestionWindow é dinâmica em função do nível 
de congestionamento detectado 
Controle de 
congestionamento
• Como o emissor percebe congestionamento?
• evento de perda de segmento
• temporizador expirado (timeout) ou 
3 ACKs duplicados
• indicação implícita de congestionamento
• Emissor TCP reduz taxa (CongestionWindow) após 
evento de perda
TCP AIMD
Mutiplicative decrease
corta CongestionWindow 
pela metade após perda
Additive increase
incrementa CongestionWindow 
em 1 MSS a cada RTT na 
ausência de perdas: sondagem 
da taxa ideal
- Self-clocking (ajuste 
via recebimento de ACKs 
ligado ao RTT)
- aumento linear da janela
congestion avoidance
Conexão TCP de longa duração
TCP Slow Start
• Quando a conexão inicia: CongestionWindow = 1 MSS
• Exemplo: MSS = 500 bytes e RTT = 200 ms
• Taxa inicial = 20 kbps
• Capacidade disponível pode ser >> MSS/RTT
• Desejável aumentar taxa rapidamente até
uma taxa respeitável
• Quando a conexão começa, a taxa aumenta 
rapidamente de modo exponencial até a 
ocorrência do primeiro evento de perda
TCP Slow Start
• Slow start: taxa inicial é 
lenta, mas aumenta de 
modo exponencialmente 
rápido (até primeira 
perda)
• dobra 
CongestionWindow
a cada RTT
• faz-se isso aumentando
CongestionWindow
para cada ACK recebido
Reação a perdas
• Após 3 ACKs duplicados
• rede capaz de entregar alguns segmentos
• Após timeout do temporizador
• timeout antes de 3 ACKs duplicados: mais 
“alarmante”
Qual indício de perda?
Reação a perdas
Qual indício de perda?
• Após 3 ACKs duplicados
• corta CongestionWindow pela metade
• CongestionWindow cresce linearmente
• Após timeout do temporizador
• CongestionWindow ajustado para 1 MSS
• CongestionWindow cresce exponencialmente até um 
limiar (Threshold), então cresce linearmente
	Slide 1
	Slide 2
	Slide 3
	Slide 4
	Slide 5
	Slide 6
	Slide 7
	Slide 8
	Slide 9
	Slide 10
	Slide 11
	Slide 12
	Slide 13
	Slide 14
	Slide 15
	Slide 16
	Slide 17
	Slide 18
	Slide 19
	Slide 20
	Slide 21
	Slide 22
	Slide 23
	Slide 24
	Slide 25
	Slide 26
	Slide 27
	Slide 28
	Slide 29
	Slide 30
	Slide 31
	Slide 32
	Slide 33
	Slide 34
	Slide 35
	Slide 36
	Slide 37
	Slide 38
	Slide 39
	Slide 40
	Slide 41
	Slide 42
	Slide 43
	Slide 44
	Slide 45
	Slide 46
	Slide 47
	Slide 48
	Slide 49
	Slide 50
	Slide 51