REDES DE COMPUTADORES
Prof. Evandro Cantú
Prof. Evandro Cantú, Dr. Eng.
[email protected]
www.sj.cefetsc.edu.br/wiki
Slides adaptados de J. Kurose & K. Ross
(http://www.aw-bc.com/kurose-ross/),
e J. A. Suruagy
(http://www.nuperc.unifacs.br/suruagy/redes/index.html)
2
Curso de Capacitação Intelbras
Redes Computadores
Maio 2007
Camada de
Transporte
Objetivos:
• compreender os princípios
atrás dos serviços da
camada de transporte:
– multiplexação/
demultiplexação
– transferência confiável de
dados
– controle de fluxo
– controle de
congestionamento
 aprender os
protocolos da camada
de transporte da
Internet:



UDP: transporte sem
conexão
TCP: transporte
orientado a conexões
Controle de
congestionamento do
TCP
3
Serviços e protocolos
de transporte
• provê comunicação lógica entre
processos de aplicação
executando em hospedeiros
diferentes
• protocolos de transporte executam
em sistemas finais:
– lado transmissor: quebra as
mensagens das aplicações em
segmentos, repassa-os para a
camada de rede
– lado receptor: remonta as
mensagens a partir dos
segmentos, repassa-as para a
camada de aplicação
aplicação
transporte
rede
enlace
física
rede
enlace
física
rede
enlace
física
rede
enlace
física
rede
enlace
física
rede
enlace
física
aplicação
transporte
rede
enlace
física
• existem mais de um protocolo de
transporte disponível para as
aplicações
– Internet: TCP e UDP
4
Camadas de
Transporte x
Rede
• camada de rede:
comunicação lógica
entre hospedeiros
• camada de transporte:
comunicação lógica
entre processos
– depende da camada
rede e estende os
serviços por ela
oferecidos
5
Protocolos da camada
de transporte Internet
aplicação
• entrega confiável, ordenada transporte
rede
(TCP)
enlace
– controle de congestionamento
– controle de fluxo
– estabelecimento de conexão
(“setup”)
• entrega não confiável, não
ordenada: UDP
– extensão sem “frescuras” do
“melhor esforço” do IP
• serviços não disponíveis:
física
rede
enlace
física
rede
enlace
física
rede
enlace
física
rede
enlace
física
rede
enlace
física
aplicação
transporte
rede
enlace
física
– garantias de atraso
– garantias de largura de banda
6
Multiplexação/
demultiplexação
Multiplexação no transmisspr:
reúne dados de muitos
sockets, envelopa os dados
com o cabeçalho (usado
posteriormente para a
demultiplexação)
Demultiplexação no receptor:
Entrega dos segmentos
recebidos ao socket correto
= socket
aplicação
transporte
rede
= processo
P3
P1
P1
aplicação
transporte
P2
P4
aplicação
transporte
rede
rede
enlace
enlace
enlace
física
física
física
host 1
host 2
host 3
7
Como funciona a
demultiplexação
• host recebe os datagramas IP
– cada datagrama possui os
endereços IP da origem e do
destino
– cada datagrama transporta 1
segmento da camada de
transporte
– cada segmento possui
números das portas origem e
destino (lembre: números de
portas bem conhecidas para
aplicações específicas)
• host usa os endereços IP e os
números das portas para
direcionar o segmento ao socket
apropriado
32 bits
porta remetente porta receptor
outros campos
do cabeçalho
dados da
aplicação
(mensagem)
formato de segmento
TCP/UDP
8
Demultiplexação
sem Conexões
• socket UDP • Quando host recebe segmento
UDP:
identificado
– verifica no. da porta de destino no
pela dupla:
segmento
(end IP dest, no.
da porta
destino)
– encaminha o segmento UDP para
o socket com aquele no. de porta
• Datagramas IP com diferentes
endereços IP origem e/ou
números de porta origem são
encaminhados para o mesmo
socket
9
Demultiplexação
sem Conexões
P2
P1
P1
P3
SP: 6428
SP: 6428
DP: 9157
DP: 5775
SP: 9157
cliente
IP: A
DP: 6428
SP: 5775
servidor
IP: C
DP: 6428
Cliente
IP:B
SP (source port) provê “endereço de retorno”
10
Demultiplexação
Orientada a Conexões
• Socket TCP identificado
pela 4-dupla:
–
–
–
–
endereço IP origem
número da porta origem
endereço IP destino
número da porta destino
• receptor usa todos os
quatro valores para
direcionar o segmento
para o socket apropriado
• Servidor pode dar suporte
a muitos sockets TCP
simultâneos:
– cada socket é identificado
pela sua própria 4-dupla
• Servidores Web têm
sockets diferentes para
cada conexão cliente
– HTTP não persistente terá
sockets diferentes para
cada pedido
11
Demultiplexação
Orientada a
Conexões
P1
P4
P5
P2
P6
P1P3
SP: 5775
DP: 80
S-IP: B
D-IP:C
SP: 9157
cliente
IP: A
DP: 80
S-IP: A
D-IP:C
SP: 9157
servidor
IP: C
DP: 80
S-IP: B
D-IP:C
Cliente
IP:B
12
Demultiplexação
Orientada a Conexões:
Servidor Web com
Threads
P1
P2
P4
P1P3
SP: 5775
DP: 80
S-IP: B
D-IP:C
SP: 9157
cliente
IP: A
DP: 80
S-IP: A
D-IP:C
SP: 9157
servidor
IP: C
DP: 80
S-IP: B
D-IP:C
Cliente
IP:B
13
UDP: User Datagram
Protocol [RFC 768]
• Protocolo de transporte da
Internet mínimo, “sem frescura”,
• Serviço “melhor esforço”,
segmentos UDP podem ser:
– perdidos
– entregues à aplicação fora
de ordem do remesso
• sem conexão:
– não há “setup” UDP entre
remetente, receptor
– tratamento independente de
cada segmento UDP
Por quê existe um UDP?
• elimina estabelecimento de
conexão (o que pode causar
retardo)
• simples: não se mantém
“estado” da conexão no
remetente/receptor
• pequeno cabeçalho de
segmento
• sem controle de
congestionamento: UDP pode
transmitir o mais rápido
possível
14
• muito utilizado para apls. de
meios contínuos (voz, vídeo)
– tolerantes de perdas
– sensíveis à taxa de
transmissão
• outros usos de UDP:
– DNS (nomes)
– SNMP (gerenciamento)
• transferência confiável com
UDP: incluir confiabilidade na
camada de aplicação
– recuperação de erro
específica à apl.!
Comprimento em
bytes do
segmento UDP,
incluindo
cabeçalho
Mais sobre
UDP
32 bits
porta origem
porta dest.
comprimento
checksum
Dados de
aplicação
(mensagem)
Formato do segmento UDP
15
Checksum UDP
Meta: detectar “erro” (e.g., bits invertidos) no
segmento transmitido
Remetente:
• trata conteúdo do segmento
como seqüência de inteiros
de 16-bits
• campo checksum zerado
• checksum: soma (adição
usando complemento de 1)
do conteúdo do segmento
• remetente coloca
complemento do valor da
soma no campo checksum
de UDP
Receptor:
• calcula checksum do
segmento recebido
• verifica se checksum
computado é zero:
– NÃO - erro detectado
– SIM - nenhum erro
detectado. Mas ainda pode
ter erros? Veja depois ….
16
Exemplo do
Checksum Internet
• Note
– Ao adicionar números, o transbordo do bit
mais significativo deve ser adicionado o
resultado
• 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
checksum 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
17
Princípios de Transferência
confiável de dados (rdt)
• importante nas camadas de transporte, enlace
• na lista dos 10 tópicos mais importantes em redes!
• características do canal não confiável determinam a complexidade de
um protocolo de transferência confiável de dados (rdt)
18
Transferência confiável de
dados (rdt)
rdt_send(): chamada de cima,
(p.ex.,pela apl.). Dados recebidos p/
entregar à camada sup. do receptor
send
side
udt_send(): chamada por
rdt, p/ transferir pacote pelo
canal ñ confiável ao receptor
deliver_data(): chamada
por rdt p/ entregar dados
p/ camada superior
receive
side
rdt_rcv(): chamada quando
pacote chega no lado receptor do
canal
19
TCP: Visão geral RFCs: 793,
1122, 1323, 2018, 2581
socket
door
• ponto a ponto:
• transmissão full duplex:
– 1 remetente, 1 receptor
– fluxo de dados bi-direcional na
mesma conexão
• fluxo de bytes, ordenados, confiável:
– MSS: tamanho máximo de
– não estruturado em msgs
segmento
• com paralelismo (pipelined):
– tam. da janela ajustado por controle• orientado a conexão:
– handshaking (troca de msgs de
de fluxo e congestionamento do
controle) inicia estado de
TCP
remetente, receptor antes de
• buffers de envio e recepção
trocar dados
• fluxo controlado:
application
application
writes data
reads data
socket
– receptor não será afogado
door
TCP
send buffer
TCP
receive buffer
segment
TCP: estrutura do
32 bits
URG: dados urgentes
(pouco usados)
ACK: no. ACK
válido
PSH: envia dados já
(pouco usado)
RST, SYN, FIN:
gestão de conexão
(comandos de
estabelecimento,
liberação)
checksum
Internet
(como UDP)
segmento
no. porta origem no. porta dest
número de seqüência
número de reconhecimento
tam. sem
UA P R S F
cab. uso
checksum
janela receptor
ptr dados urg.
Opções (tam. variável)
dados da
aplicação
(tam. variável)
contagem
de dados
por bytes
(não segmentos!)
no. bytes
rcpt quer
aceitar
TCP: Seq e Ack
Números de sequência (Seq):
– “número”dentro do
fluxo de bytes do
primeiro byte de dados
do segmento
Números de Reconhecimento
(Ack):
– no. de seq do próx.
byte esperado do outro
lado
– ACK cumulativo
Estação A
Usuário
tecla
‘C’
Estação B
B reconhece
chegada de
‘C’, ecoa
‘C’ de volta
A reconhece
chegada
do ‘C’
ecoado
cenário simples de telnet
tempo
TCP: Tempo de Resposta e
Temporização
P: como escolher valor do
temporizador TCP?
• maior que o RTT (Round
Trip Time)
– note: RTT pode variar
• muito curto: temporização
prematura
– retransmissões são
desnecessárias
• muito longo: reação
demorada à perda de
segmentos
P: como estimar RTT?
• RTTamostra: tempo medido entre a
transmissão do segmento e o
recebimento do ACK correspondente
• Como o RTT_amostra vai varia,
usa-se várias medições recentes, não
apenas o valor corrente.
Exemplo de estimativa do
RTT:
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
350
RTT (milliseconds)
300
250
200
150
100
1
8
15
22
29
36
43
50
57
64
71
time (seconnds)
SampleRTT
Estimated RTT
78
85
92
99
106
TCP: Tempo de
Resposta (RTT) e
Temporização
Escolhendo o intervalo de temporização
• RTT_estimado mais uma “margem de segurança”
– grande variação no RTT_estimado
-> maior margem de segurança
• primeiro estima o quanto a RTTamostra desvia do
RTT_estimado, então, seta o temporizador para:
Temporização = RTT_estimado + 4*Desvio_RTT
Transferência de dados
confiável do TCP
• O TCP cria um serviço
confiável sobre o
serviço não confiável do
IP
• Segmentos em série
(pipelined)
• Acks cumulativos
• O TCP usa um único
temporizador para
retransmissões
• As retransmissões são
disparadas por:
– estouros de temporização
– acks duplicados
• Considere inicialmente um
transmissor TCP
simplificado:
– ignora acks duplicados
– ignora controles de fluxo
e de congestionamento
Eventos do
transmissor TCP:
Dados recebidos da aplicação:
• Cria segmento com no. de
seqüência (nseq)
• nseq é o número de seqüência
do primeiro byte do segmento
• Liga o temporizador se já não
estiver ligado (temporização
do segmento mais antigo
ainda não reconhecido)
• Valor do temporizador:
calculado anteriormente
estouro do temporizador:
• Retransmite o segmento que
causou o estouro do temporizador
• Reinicia o temporizador
Recepção de Ack:
• Se reconhecer segmentos ainda
não reconhecidos
– atualizar informação sobre o
que foi reconhecido
– religa o temporizador se ainda
houver segmentos pendentes
(não reconhecidos)
TCP: cenários de
retransmissão
Host A
X
loss
Sendbase
= 100
SendBase
= 120
SendBase
= 100
tempo
cenário de perda de ACK
Host B
Seq=92 timeout
Host B
SendBase
= 120
Seq=92 timeout
timeout
Host A
tempo
estouro prematuro
do temporizador
TCP: cenários de
retransmissão
timeout
Host A
Host B
X
loss
SendBase
= 120
tempo
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
sem lacunas,
anteriores já reconhecidos
ACK retardado. Espera até 500ms
p/ próx. segmento. Se não chegar
segmento, envia ACK
chegada de segmento em ordem
sem lacunas,
um ACK retardado pendente
envia imediatamente um único
ACK cumulativo
chegada de segmento fora de
ordem, com no. de seq. maior
que esperado -> lacuna
envia ACK duplicado, indicando no.
de seq.do próximo byte esperado
chegada de segmento que
preenche a lacuna parcial ou
completamente
ACK imediato se segmento no
início da lacuna
Retransmissão
rápida
• O intervalo do temporizador •
é freqüentemente bastante
longo:
– longo atraso antes de
retransmitir um pacote
perdido
• Detecta segmentos perdidos
através de ACKs duplicados.
– O transmissor
normalmente envia
diversos segmentos
– Se um segmento se perder,
provavelmente haverá
muitos ACKs duplicados.
Se o transmissor receber 3
ACKs para os mesmos
dados, ele supõe que o
segmento após os dados
reconhecidos se perdeu:
– Retransmissão rápida:
retransmite o segmento
antes que estoure o
temporizador
Controle de Fluxo do TCP
• Lado receptor da
conexão TCP possui um
buffer de recepção:
• Processo da apl. pode
demorar a ler do
receptor
Controle de fluxo
o transmissor não
inundará o buffer do
receptor transmitindo
muito e rapidamente
• serviço de casamento
de velocidades:
adaptando a taxa de
transmissão à taxa de
leitura da aplicação
receptora
Controle de Fluxo do
TCP: como funciona
• O receptor anuncia o
espaço livre incluindo o
valor da RcvWindow nos
segmentos
• O transmissor limita os
(Suponha que o receptor TCP
dados não reconhecidos ao
receba segmentos fora de ordem)
tamanho da RcvWindow
• espaço livre no buffer
– Garante que o buffer do
= RcvWindow
receptor não
transbordará
= RcvBuffer[LastByteRcvd LastByteRead]
TCP: Gerenciamento
de Conexões
Inicialização em 3 tempos:
Passo 1: sistema cliente envia segmento de
Lembrete: Remetente, receptor TCP
controle SYN do TCP ao servidor
estabelecem “conexão” antes de
trocar segmentos de dados
– especifica no. inicial de seq
• inicializam variáveis TCP:
– não envia dados
– nos. de seq.
Passo 2: sistema servidor recebe SYN,
– buffers, info s/ controle de fluxo
responde com segmento de controle
(p.ex. RcvWindow)
SYNACK
• cliente: iniciador de conexão
– aloca buffers
• servidor: contactado por cliente
– especifica no. inicial de seq.
servidor-> receptor
Passo 3: receptor recebe SYNACK,
responde com segmento ACK que pode
conter dados.
TCP: Gerenciamento de
Conexões (cont.)
cliente
Encerrando uma conexão:
servidor
fechar
cliente fecha soquete:
Passo 1: sistema cliente envia segmento
de controle FIN ao servidor
fechar
espera
temporizada
Passo 2: servidor recebe FIN, responde
com ACK. Encerra a conexão,
enviando FIN.
fechada
TCP: Gerenciamento de
Conexões (cont.)
Passo 3: cliente recebe FIN,
responde com ACK.
– Entre em “espera
temporizada” - responderá
com ACK a FINs recebidos
cliente
servidor
fechando
fechando
espera
temporizada
Passo 4: servidor, recebe ACK.
Conexão encerrada.
fechada
fechada
TCP: Gerenciamento de
Conexões (cont.)
Ciclo de vida
de servidor TCP
Ciclo de vida
de cliente TCP
Princípios de
Controle de
Congestionamento
Congestionamento:
• informalmente: “muitas fontes enviando muitos dados muito
rapidamente para a rede poder tratar”
• diferente de controle de fluxo!
• manifestações:
– perda de pacotes (esgotamento de buffers em roteadores)
– longos atrasos (enfileiramento nos buffers dos roteadores)
• um dos 10 problemas mais importantes em redes!
Abordagens de controle de
congestionamento
Duas abordagens amplas para controle de
congestionamento:
Controle de congestionamento Controle de
congestionamento
fim a fim :
com apoio da rede:
• não tem realimentação
• roteadores realimentam os
explícita pela rede
sistemas terminais
• congestionamento inferido
– bit indicando
a partir das perdas, retardo
congestionamento
observados pelo sistema
(ATM)
terminal
– taxa explícita p/ envio
• abordagem usada pelo TCP
pelo remetente
Controle de
Congestionamento do
• controle fim-a-fim (sem assistência
da rede)
• transmissor limita a transmissão:
LastByteSent-LastByteAcked
 CongWin
• Praticamente,
taxa =
CongWin
Bytes/seg
RTT
• CongWin é dinâmica, em função do
congestionamento percebido da rede
TCP
Como o transmissor percebe
o congestionamento?
• evento de perda = estouro do
temporizador ou 3 acks
duplicados
• transmissor TCP reduz a taxa
(CongWin) após evento de
perda
três mecanismos:
– AIMD
– partida lenta
– conservador após eventos de
estouro de temporização
AIMD do TCP
decrescimento multiplicativo: corta
CongWin pela metade após
evento de perda
congestion
window
crescimento aditivo: incrementa
CongWin de 1 MSS a cada
RTT na ausência de eventos de
perda: sondagem
24 Kbytes
16 Kbytes
8 Kbytes
time
Conexão TCP de longa duração
Partida Lenta do TCP
• No início da conexão,
CongWin = 1 MSS
– Exemplo: MSS = 500
bytes & RTT = 200 mseg
– taxa inicial = 20 kbps
• largura de banda disponível
pode ser >> MSS/RTT
– é desejável um
crescimento rápido até
uma taxa considerável
• No início da conexão,
aumenta a taxa
exponencialmente até o
primeiro evento de perda
TCP: Partida lenta
(mais)
Estação A Estação B
RTT
• No início da conexão,
aumenta a taxa
exponencialmente até o
primeiro evento de perda:
– duplica CongWin a cada
RTT
– através do incremento da
CongWin para cada
ACK recebido
• Resumo: taxa inicial é baixa
mas cresce rapidamente de
forma exponencial
tempo
Refinamento
Filosofia:
• Após 3 ACKs duplicados:
– corta CongWin pela metade
– a janela depois cresce
linearmente
• Mas após estouro de temporizador:
– CongWin é reduzida a 1 MSS;
– janela cresce exponencialmente
– até um limiar, depois cresce
linearmente
• 3 ACKs duplicados
indica que a rede é capaz
de entregar alguns
segmentos
• estouro de
temporizador antes de 3
ACKs duplicados é mais
“alarmante”.
Refinamento (mais)
P: Quando o
crescimento
exponencial deve
mudar para linear?
R: Quando CongWin
atinge 1/2 do seu
valor antes do
estouro do
temporizador.
Implementação:
• Limiar (Threshold) variável
• Com uma perda o limiar passa a
ser 1/2 da CongWin
imediatamente anterior à perda.
Resumo: Controle de
Congestionamento do
TCP
• Quando a CongWin está abaixo do limiar,
transmissor está na fase de início lento, janela
cresce exponencialmente.
• Quando a CongWin está acima do limiar,
transmissor está na fase de evitar congestionamento,
janela cresce linearmente.
• Quando chegam ACKs triplicados, Limiar passa a
ser CongWin/2 e CongWin passa ao valor do
Limiar.
• Quando estoura o temporizador, Limiar passa a ser
CongWin/2 e CongWin passa a ser 1 MSS.
Controle de congestionamento do
transmissor TCP
Evento
ACK recebido
Estado
Partida lenta
para dados
Ação do Transmissor TCP
Comentário
CongWin = CongWin + MSS,
Resulta na duplicação da
If (CongWin > Limiar)
CongWin a cada RTT
seta estado para “Evitar
ainda não
reconhecidos
congestionamento”
ACK recebido
Evitar
CongWin = CongWin+MSS *
Incremento aditivo, resultando
para dados
congestiona
(MSS/CongWin)
no incremento da CongWin de
ainda não
mento
1 MSS a cada RTT
reconhecidos
Perda
Limiar = CongWin/2,
Recuperação rápida,
detectada por
CongWin = Limiar,
implementa decrescimento
ACKs
Seta estado para “Evitar
multiplicativo. CongWin não cai
triplicados
Congestionamento”
abaixo de 1 MSS.
Limiar = CongWin/2,
Entra estado de “partida lenta”
Estouro de
qualquer
qualquer
temporizador
CongWin = 1 MSS,
Seta estado para “Partida lenta”
ACK duplicado
qualquer
Incrementa contador de ACKs
CongWin e Threshold não se
duplicados para o segmento que
alteram
está sendo reconhecido