prof. evandro cantú redes de computadores. 2 prof. evandro cantú, dr. eng. cantu@sj.cefetsc.edu.br...
Post on 16-Apr-2015
103 Views
Preview:
TRANSCRIPT
Prof. Evandro Cantú
REDES DE COMPUTADORES
2
Prof. Evandro Cantú, Dr. Eng.cantu@sj.cefetsc.edu.br
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
)Curso de Capacitação Intelbras Redes Computadores Maio 2007
3
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ãoTCP: transporte
orientado a conexões
Controle de congestionamento do TCP
4
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
• existem mais de um protocolo de transporte disponível para as aplicações– Internet: TCP e UDP
aplicaçãotransporte
redeenlacefísica
redeenlacefísica
aplicaçãotransporte
redeenlacefísica
redeenlacefísica
redeenlacefísica
redeenlacefísica
redeenlacefísica
transporte lógico fim a fim
5
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
6
Protocolos da camada de transporte Internet
• entrega confiável, ordenada (TCP)– 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: – garantias de atraso– garantias de largura de banda
aplicaçãotransporte
redeenlacefísica
redeenlacefísica
aplicaçãotransporte
redeenlacefísica
redeenlacefísica
redeenlacefísica
redeenlacefísica
redeenlacefísica
transporte lógico fim a fim
7
Multiplexação/demultiplexação
aplicação
transporte
rede
enlace
física
P1 aplicação
transporte
rede
enlace
física
aplicação
transporte
rede
enlace
física
P2P3 P4P1
host 1 host 2 host 3
= processo= socket
Entrega dos segmentos recebidos ao socket correto
Demultiplexação no receptor:reúne dados de muitos sockets, envelopa os dados com o cabeçalho (usado posteriormente para a demultiplexação)
Multiplexação no transmisspr:
8
• 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
Como funciona a demultiplexação
porta remetente porta receptor
32 bits
dados daaplicação
(mensagem)
outros campos do cabeçalho
formato de segmento TCP/UDP
9
Demultiplexação sem Conexões
• socket UDP identificado pela dupla:
(end IP dest, no. da porta destino)
• Quando host recebe segmento UDP:– verifica no. da porta de destino no
segmento– 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
10
Demultiplexação sem Conexões
ClienteIP:B
P2
cliente IP: A
P1P1P3
servidorIP: C
SP: 6428
DP: 9157
SP: 9157
DP: 6428
SP: 6428
DP: 5775
SP: 5775
DP: 6428
SP (source port) provê “endereço de retorno”
11
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
12
Demultiplexação Orientada a Conexões
ClienteIP:B
P1
cliente IP: A
P1P2P4
servidorIP: C
SP: 9157
DP: 80
SP: 9157
DP: 80
P5 P6 P3
D-IP:CS-IP: A
D-IP:C
S-IP: B
SP: 5775
DP: 80
D-IP:CS-IP: B
13
Demultiplexação Orientada a Conexões:
Servidor Web com Threads
ClienteIP:B
P1
cliente IP: A
P1P2
servidorIP: C
SP: 9157
DP: 80
SP: 9157
DP: 80
P4 P3
D-IP:CS-IP: A
D-IP:C
S-IP: B
SP: 5775
DP: 80
D-IP:CS-IP: B
14
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
15
Mais sobre UDP
• 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.!
porta origem porta dest.
32 bits
Dados de aplicação
(mensagem)
Formato do segmento UDP
comprimento checksum
Comprimento embytes do
segmento UDP,incluindo cabeçalho
16
Checksum UDP
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 ….
Meta: detectar “erro” (e.g., bits invertidos) no segmento transmitido
17
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 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
transbordo
somachecksum
18
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)
19
Transferência confiável de dados (rdt)
sendside
receiveside
rdt_send(): chamada de cima, (p.ex.,pela apl.). Dados recebidos p/entregar à camada sup. do receptor
udt_send(): chamada por rdt, p/ transferir pacote
pelocanal ñ confiável ao
receptor
rdt_rcv(): chamada quando pacote chega no lado receptor
do canal
deliver_data(): chamada por rdt p/
entregar dados p/ camada superior
TCP: Visão geral RFCs: 793,
1122, 1323, 2018, 2581
• transmissão full duplex:
– fluxo de dados bi-direcional na mesma conexão
– MSS: tamanho máximo de segmento
• orientado a conexão:
– handshaking (troca de msgs de controle) inicia estado de remetente, receptor antes de trocar dados
• fluxo controlado:
– receptor não será afogado
• ponto a ponto:
– 1 remetente, 1 receptor
• fluxo de bytes, ordenados, confiável:
– não estruturado em msgs
• com paralelismo (pipelined):
– tam. da janela ajustado por controle de fluxo e congestionamento do TCP
• buffers de envio e recepção
socketdoor
T C Psend buffer
T C Preceive buffer
socketdoor
segm ent
applicationwrites data
applicationreads data
TCP: estrutura do
segmento
no. porta origemno. porta dest
32 bits
dados daaplicação
(tam. variável)
número de seqüêncianúmero de
reconhecimentojanela receptor
ptr dados urg.checksum
FSRPAUtam.cab.
semuso
Opções (tam. variável)
URG: dados urgentes (pouco usados)
ACK: no. ACKválido
PSH: envia dados já(pouco usado)
RST, SYN, FIN:gestão de conexão
(comandos deestabelecimento,
liberação)
no. bytes rcpt queraceitar
contagem de dadospor bytes (não segmentos!)
checksum Internet
(como UDP)
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 Estação B
Seq=42, ACK=79, data = ‘C’
Seq=79, ACK=43, data = ‘C’
Seq=43, ACK=80
Usuáriotecla‘C’
A reconhecechegada
do ‘C’ecoado
B reconhecechegada de
‘C’, ecoa‘C’ de volta
tempocenário simples de telnet
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
100
150
200
250
300
350
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)
RTT
(mill
isec
onds
)
SampleRTT Estimated RTT
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ãoHost A
Seq=100, 20 bytes data
ACK=100
tempoestouro prematurodo temporizador
Host B
Seq=92, 8 bytes data
ACK=120
Seq=92, 8 bytes data
Seq=
92
tim
eout
ACK=120
Host A
Seq=92, 8 bytes data
ACK=100
loss
tim
eout
cenário de perda de ACK
Host B
X
Seq=92, 8 bytes data
ACK=100
tempo
Seq=
92
tim
eout
SendBase= 100
SendBase= 120
SendBase= 120
Sendbase= 100
TCP: cenários de
retransmissão
Host A
Seq=92, 8 bytes data
ACK=100
loss
tim
eout
Cenário de ACK cumulativo
Host B
X
Seq=100, 20 bytes data
ACK=120
tempo
SendBase= 120
TCP geração de ACKs [RFCs
1122, 2581]
Evento no Receptor
chegada de segmento em ordemsem lacunas,anteriores já reconhecidos
chegada de segmento em ordemsem lacunas,um ACK retardado pendente
chegada de segmento fora de ordem, com no. de seq. maiorque esperado -> lacuna
chegada de segmento que preenche a lacuna parcial oucompletamente
Ação do Receptor TCP
ACK retardado. Espera até 500msp/ próx. segmento. Se não chegarsegmento, envia ACK
envia imediatamente um únicoACK cumulativo
envia ACK duplicado, indicando no. de seq.do próximo byte esperado
ACK imediato se segmento noiní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:
• serviço de casamento de velocidades: adaptando a taxa de transmissão à taxa de leitura da aplicação receptora
• Processo da apl. pode demorar a ler do receptor
o transmissor não inundará o buffer do
receptor transmitindo muito e
rapidamente
Controle de fluxo
Controle de Fluxo do
TCP: como funciona
(Suponha que o receptor TCP receba segmentos fora de ordem)
• espaço livre no buffer
= RcvWindow
= RcvBuffer-[LastByteRcvd - LastByteRead]
• O receptor anuncia o espaço livre incluindo o valor da RcvWindow nos segmentos
• O transmissor limita os dados não reconhecidos ao tamanho da RcvWindow– Garante que o buffer do
receptor não transbordará
TCP: Gerenciamento
de Conexões
Lembrete: Remetente, receptor TCP estabelecem “conexão” antes de trocar segmentos de dados
• inicializam variáveis TCP:
– nos. de seq.
– buffers, info s/ controle de fluxo (p.ex. RcvWindow)
• cliente: iniciador de conexão • servidor: contactado por cliente
Inicialização em 3 tempos:
Passo 1: sistema cliente envia segmento de controle SYN do TCP ao servidor
– especifica no. inicial de seq
– não envia dados
Passo 2: sistema servidor recebe SYN, responde com segmento de controle SYNACK
– aloca buffers
– 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.)Encerrando uma conexão:
cliente fecha soquete:
Passo 1: sistema cliente envia segmento de controle FIN ao servidor
Passo 2: servidor recebe FIN, responde com ACK. Encerra a conexão, enviando FIN.
cliente
FIN
servidor
ACK
ACK
FIN
fechar
fechar
fechada
esp
era
te
mpori
zada
TCP: Gerenciamento de
Conexões (cont.)Passo 3: cliente recebe FIN,
responde com ACK.
– Entre em “espera temporizada” - responderá com ACK a FINs recebidos
Passo 4: servidor, recebe ACK. Conexão encerrada.
cliente
FIN
servidor
ACK
ACK
FIN
fechando
fechando
fechada
esp
era
tem
pori
zada
fechada
TCP: Gerenciamento de
Conexões (cont.)
Ciclo de vidade cliente TCP
Ciclo de vidade servidor TCP
Princípios de
Controle de
CongestionamentoCongestionamento:
• 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
Controle de congestionamento fim a fim :
• não tem realimentação explícita pela rede
• congestionamento inferido a partir das perdas, retardo observados pelo sistema terminal
• abordagem usada pelo TCP
Controle de congestionamento com apoio da rede:
• roteadores realimentam os sistemas terminais
– bit indicando congestionamento (ATM)
– taxa explícita p/ envio pelo remetente
Duas abordagens amplas para controle de congestionamento:
Controle de
Congestionamento do
TCP• controle fim-a-fim (sem assistência da
rede)• transmissor limita a transmissão: LastByteSent-LastByteAcked
CongWin
• Praticamente,
• CongWin é dinâmica, em função do congestionamento percebido da rede
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
taxa = CongWin
RTT Bytes/seg
AIMD do TCP
8 Kbytes
16 Kbytes
24 Kbytes
time
congestionwindow
decrescimento multiplicativo: corta CongWin pela metade após evento de perda
crescimento aditivo: incrementa CongWin de 1 MSS a cada RTT na ausência de eventos de perda: sondagem
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
• 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
TCP: Partida lenta
(mais)Estação A
um segmento
RTT
Estação B
tempo
dois segmentos
quqtro segmentos
Refinamento
• 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”.
Filosofia:
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 Estado Ação do Transmissor TCP Comentário
ACK recebido para dados ainda não reconhecidos
Partida lenta CongWin = CongWin + MSS, If (CongWin > Limiar) seta estado para “Evitar congestionamento”
Resulta na duplicação da CongWin a cada RTT
ACK recebido para dados ainda não reconhecidos
Evitar congestionamento
CongWin = CongWin+MSS * (MSS/CongWin)
Incremento aditivo, resultando no incremento da CongWin de 1 MSS a cada RTT
Perda detectada por ACKs triplicados
qualquer Limiar = CongWin/2, CongWin = Limiar,Seta estado para “Evitar Congestionamento”
Recuperação rápida, implementa decrescimento multiplicativo. CongWin não cai abaixo de 1 MSS.
Estouro de temporizador
qualquer Limiar = CongWin/2, CongWin = 1 MSS,Seta estado para “Partida lenta”
Entra estado de “partida lenta”
ACK duplicado qualquer Incrementa contador de ACKs duplicados para o segmento que está sendo reconhecido
CongWin e Threshold não se alteram
top related