Transporte
Referência:
 Slides extraídos do material dos professores Jim
Kurose e Keith Ross relativos ao livro “Redes de
Computadores e a Internet – Uma abordagem topdown”, segunda e terceira edições
 Alterações nos slides, incluindo sequenciamento,
textos, figuras e novos slides, foram realizadas
conforme necessidade
1
Protocolos e Serviços de Transporte
•
•
•
•
•
Fornecem comunicação lógicas entre
processos de aplicação em diferentes
hosts
Os protocolos de transporte são
executados nos sistemas finais da rede
serviço de transporte vs serviços de
rede :
camada de rede: transferência de
dados entre computadores (end
systems)
camada de transporte: transferência
de dados entre processos
– utiliza e aprimora os serviços
oferecidos pela camada de rede
aplicação
transporte
eerede
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
2
Protocolos da Camada de Transporte
Serviços de Transporte da Internet:
• confiável, seqüencial e unicast
(TCP)
– congestionamento
– controle de fluxo
– orientado à conexão
• não confiável, não seqüencial,
entrega unicast or multicast:
UDP
• serviços não disponíveis:
– tempo-real
– garantia de banda
– multicast confiável
application
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
application
transporte
rede
enlace
física
3
Multiplexação de Aplicações
Segmento - unidade de dados trocada
entre entidades da camada de
transporte
– TPDU: transport protocol data
unit (unidade de dados do
protocolo de transporte)
P3
dados da camada
de aplicação
cabeçalho do
segmento
segmento
Ht
M
Hn segmento
P1
M
aplicação
transporte
rede
Demultiplexação: entrega de
segmentos recebidos aos
processos de aplicação corretos
receptor
M
M
aplicação
transporte
rede
P4
M
P2
aplicação
transporte
rede
4
Multiplexação de Aplicações
Multiplexação:
reunir dados de múltiplos
processo de aplicação, juntar
cabeçalhos com informações
para demultiplexação
32 bits
porta origem
porta destino
outros campos de cabeçalho
multiplexação/demultiplexação:
• baseada nos número de porta do
transmissor, número de porta do
receptor e endereços IP
– números de porta origem e
destino em cada segmento
– lembre: portas com números
bem-conhecidos são usadas
para aplicações específicas
dados de aplicação
(mensagem)
formato do segmento TCP/UDP
5
Multiplexação: exemplos
host A
porta origem: x
porta dest.: 23
servidor B
porta origem:23
port dest.: x
IP Origem: C
IP Dest: B
porta origem: y
porta dest.: 80
aplicação Telnet
cliente Web
host A
cliente Web
host C
IP Origem: A
IP Dest: B
porta origem : x
porta dest.: 80
IP Origem: C
IP Dest: B
porta origem: x
porta dest.: 80
Servidor
Web B
aplicação: servidor Web
6
UDP: User Datagram Protocol [RFC 768]
• protocolo de transporte da
Internet “sem gorduras” “sem
frescuras”
•
serviço “best effort” , segmentos
UDP podem ser:
– perdidos
– entregues fora de ordem
para a aplicação
• sem conexão:
– não há apresentação entre o
UDP transmissor e o
receptor
– cada segmento UDP é
tratado de forma
independente dos outros
Porque existe um UDP?
• não há estabelecimento de
conexão (que pode redundar em
atrasos)
•
simples: 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)
7
Mais sobre UDP
• muito usado por aplicações de
mutimídia contínua (streaming)
– tolerantes à perda
Tamanho, em
bytes do segmento
– sensíveis à taxa
UDP, incluíndo
• outros usos do UDP:
– DNS
– SNMP
• transferência confiável sobre
UDP: acrescentar confiabilidade na
camada de aplicação
– recuperação de erro
específica de cada aplicação
32 bits
porta origem
porta destino
tamanho
checksum
cabeçalho
Dados de Aplicação
(mensagem)
formato do segmento UDP
8
UDP checksum
Objetivo: detectar “erros” (ex.,bits trocados) no segmento
transmitido
Transmissor:
Receptor:
• trata o conteúdo do segmento
como seqüencia de inteiros de
• computa o checksum do segmento
recebido
• verifica se o checksum calculado é
igual ao valor do campo checksum:
– NÃO - error detectado
– SIM - não há erros. Mas,
talvez haja erros apesar disto!
16 bits
•
•
checksum: soma (complemento
de 1 da soma) do conteúdo do
segmento
transmissor coloca o valor do
checksum no campo de checksum
do UDP
9
Princípios de Transferência Confiável de
Dados
• Importante nas camadas de aplicação, transporte e enlace
• Caracteristicas dos canais não confiáveis determinarão a
complexidade dos protocolos confiáveis de transferência de dados
• Necessário usar ACKs (e também NACKs, mas são desnecessários)
10
Há um problema fatal!
O que acontece se o ACK é
corrompido?
•
•
transmissor não sabe o que
aconteceu no receptor!
não pode apenas retransmitir:
possível duplicata
O que fazer?
•
•
Transmissor envia ACKs para
reconhecer os ACKs do receptor?
O que acontece se estes ACKs se
perdem?
retransmitir os ACKs, mas isto
poderia causar a retransmissão de
um pacote recebido corretamente!
Tratando duplicatas:
•
•
•
transmissor acrescenta número de
seqüência em cada pacote
Transmissor reenvia o último
pacote se ACK for perdido
receptor descarta (não passa para a
aplicação) pacotes duplicados
stop and wait
Transmissor envia um pacote
e então espera pela resposta
do receptor
11
Discussão (Stop and Wait)
Transmissor:
• adiciona número de
seqüência ao pacote
• Dois números (0 e 1) bastam.
Porque?
• deve verificar se os ACKs
recebidos estão corrompidos
• estado da transmissão deve
“lembrar” se o pacote
“corrente” tem número de
seqüência 0 ou 1
Receptor:
• deve verificar se o pacote
recebido é duplicado
– estado indica se o pacote 0
ou 1 é esperado
• nota: receptor pode não
saber se seu últino ACK
foi recebido pelo
transmissor
12
Protocolos com Paralelismo (pipelining)
Paralelismo: transmissor envia vários pacotes “ao mesmo
tempo” (em seqüência), todos esperando para serem
reconhecidos
– faixa de números de seqüência deve ser aumentada
– armazenamento no transmissor e/ou no receptor
(a) operação do protocolo stop-and-wait
(a) operação do protocolo com paralelismo
• Duas formas genéricas de protocolos com paralelismo: goBack-N, retransmissão seletiva
13
Go-Back-N
Transmissor:
• Número de seqüência com k bits no cabeçalho do pacote
• “janela” de até N, pacotes não reconhecidos, consecutivos, são permitidos
• ACK(n): reconhece todos os pacotes até o número de seqüência N
(incluindo este limite). “ACK cumulativo”
– pode receber ACKS duplicados (veja receptor)
• temporizador para cada pacote enviado e não confirmado
• timeout(n): retransmite pacote n e todos os pacotes com número de
seqüência maior que estejam dentro da janela
14
GBN em ação
15
Retransmissão Seletiva
• receptor reconhece individualmente todos os
pacotes recebidos corretamente
– armazena pacotes, quando necessário, para eventual
entrega em ordem para a camada superior
• transmissor somente reenvia os pacotes para os
quais um ACK não foi recebido
– transmissor temporiza cada pacote não reconhecido
• janela de transmissão
– N números de seqüência consecutivos
– novamente limita a quantidade de pacotes enviados,
mas não reconhecidos
16
Retransmissão seletiva: janelas do transmissor e
do receptor
(a) visão dos números de seqüência pelo transmissor
(b) visão dos números de seqüência pelo receptor
17
Retransmissão seletiva em ação
18
TCP: Overview
RFCs: 793, 1122, 1323, 2018, 2581
• ponto-a-ponto:
• dados full-duplex:
– um transmissor, um receptor
– transmissão bi-direcional na
mesma conexão
– MSS: maximum segment size
• confiável, seqüêncial byte stream:
– não há distorção nas mensagens
• pipelined: (transmissão de vários
• orientado à conexão:
– handshaking (troca de
mensagens de controle) inicia o
estado do transmissor e do
receptor antes da troca de dados
pacotes em confirmação)
– Controle de congestionamento e de
fluxo definem tamanho da janela
• buffers de transmissão e de recepção
socket
aplicação
aplicação
envia dados
lê dados
• controle de fluxo:
– transmissor não esgota a
capacidade do receptor
socket
port
port
TCP
TCP
buffe de txr
buffer de rx
segment
19
Estrutura do Segmento TCP
32 bits
URG: dados urgentes
(pouco usado)
ACK: campo de ACK
é válido
PSH: produz envio de
dados (pouco usado)
RST, SYN, FIN:
estabelec. de conexão
(comandos de
criação e término)
Internet
checksum
(como no UDP)
porta origem
porta destino
número de seqüência
número de reconhecimento
tam. não
UA P R S F
cabec.usado
checksum
contagem por
bytes de dados
(não segmentos!)
janela de recep.
dados urgentes
Opções (tamanho variável)
número de bytes
receptor está
pronto para
aceitar
dados de aplicação
(tamanho variável)
20
Números de Seqüência e ACKs do TCP
Números de seqüência:
– número do primeiro
byte no segmentos de
dados
ACKs:
– número do próximo
byte esperado do outro
lado
– ACK cumulativo:
forma como o receptor
trata segmentos fora de
ordem
– alguns pontos ficam a
critério da
implementação como
fazer
Host A
Usuário
digita
‘C’
Host B
host confirma
recepção de
‘C’, e ecoa o
’C’ de volta
host confirma
recepção
do ‘C’ ecoado
cenário telnet simples
tempo
21
TCP: Estabelecimento de Conexão
TCP transmissor estabelece
conexão com o receptor, antes
mesmo de enviar dados:
• inicializar variáveis:
– números de seqüência
– buffers, controle de fluxo (ex.
RcvWindow)
• cliente: iniciador da conexão
Socket clientSocket = new
Socket("hostname","port
number");
• servidor: chamado pelo cliente
Socket connectionSocket =
welcomeSocket.accept();
Three way handshake:
Passo 1: sistema final cliente envia
TCP SYN ao servidor
– especifica número de seqüência
inicial
Passo 2: sistema final servidor que
recebe o SYN, responde com
segmento SYNACK
– reconhece o SYN recebido
– aloca buffers
– especifica o número de
seqüência inicial do servidor
Passo 3: o sistema final cliente
reconhece o SYNACK
22
TCP: Término de Conexão
Fechando uma conexão:
cliente fecha o socket:
clientSocket.close();
Passo 3: cliente recebe FIN,
responde com ACK.
– entra “espera temporizada”
Passo 1: o cliente envia o
segmento TCP FIN ao servidor
Passo 2: servidor recebe FIN,
responde com ACK. Fecha a
conexão, envia FIN.
– vai responder com ACK a
FINs recebidos
Passo 4: servidor, recebe ACK.
Conexão fechada.
23
TCP: Controle de Fluxo
controle de fluxo
transmissor não deve
esgotar os buffers de
receção enviando
dados rápido demais
RcvBuffer = tamanho do Buffer de recepção do TCP
RcvWindow = total de espaço livre no buffer
armazenamento de recepção
receptor: explicitamente
informa o transmissor da
área livre no buffer
(dinamicamente mudando)
– campo RcvWindow
no segmento TCP
transmissor: mantém a
quantidade de dados
transmitidos mas não
reconhecidos menor que o
último RcvWindow
recebido
24
TCP Round Trip Time e Temporização
Q: como escolher o valor
da temporização do
TCP (time-out)?
• maior que o RTT
– nota: RTT varia
• muito curto: temporização
prematura
– retransmissões
desnecessárias
• muito longo: a reação à
perda de segmento fica
lenta
Q: Como estimar o RTT?
• SampleRTT: tempo medido da
transmissão de um segmento até a
respectiva confirmação
– ignora retransmissões e segmentos
reconhecidos de forma cumulativa
• SampleRTT varia de forma rápida, é
desejável um amortecedor para a
estimativa do RTT
– usar várias medidas recentes, não
apenas o último SampleRTT
obtido
25
TCP Round Trip Time e Temporização
EstimatedRTT = (1-x)*EstimatedRTT + x*SampleRTT
• Média móvel com peso exponential
• influencia de uma dada amostra decresce de forma exponencial
• valor típico de x: 0.1
Definindo a temporização
• EstimtedRTT mais “margem de segurança”
• grandes variações no EstimatedRTT -> maior margem de
segurança
Temporização = EstimatedRTT + 4*Desvios
Desvios = (1-x)*Desvio +
x*|SampleRTT-EstimatedRTT|
26
TCP Round Trip Time e Temporização
27
Princípios de Controle de Congestionamento
Congestionamento:
• informalmente: “muitas fontes enviando dados acima da
capacidade da rede tratá-los”
• diferente de controle de fluxo!
• sintomas:
– perda de pacotes (saturação de buffer nos roteadores)
– atrasos grandes (filas nos buffers dos roteadores)
• um dos 10 problemas mais importantes na Internet!
28
Causas/custos do congestionamento: cenário 3
Causas/custos do congestionamento
 Quatro transmissores
 Caminhos com múltiplos saltos
 Temporizações/retransmissões
P.: o que acontece quando
in e in
aumentam?
29
TCP: Controle Congestionamento
• controle fim-a-fim (não há assistência da rede)
• taxa de transmissão é limitada pelo tamanho da janela,
Congwin, sobre os segmentos:
Congwin
• w segmentos, cada um com MSS bytes enviados em um
RTT:
vazão =
w * MSS
Bytes/seg
RTT
30
TCP: Controle Congestionamento
• Realiza um “teste” para
reconhecer a taxa possível:
– idealmente: transmitir tão
rápido quanto possível
(Congwin tão grande
quanto possível) sem
perdas
– aumentar Congwin até
que ocorra perda
(congestionamento)
– perda: diminuir Congwin,
então ir testando
(aumentando) outra vez
• Duas “fases””
– slow start
– congestion avoidance
•
Variáveis importantes:
– Congwin
– threshold: define o
limite entre a fase slow
start e a fase congestion
avoidance
31
TCP Slowstart
Host A
initializar: Congwin = 1
para (cada segmento reconhecido
Congwin++
até (evento perda OU
CongWin > threshold)
• aumento exponencial (por RTT)
no tamanho da janela (não tão
lento!)
• evento de perda : temporização
(Tahoe TCP) e/ou 3 ACKs
duplicados (Reno TCP)
RTT
algoritmo Slowstart
Host B
tempo
32
TCP: Congestion Avoidance
Congestion avoidance
/* acabou slowstart
*/
/* Congwin > threshold */
Até (evento perda) {
cada w segmentos “acked”:
Congwin++
}
threshold = Congwin/2
Congwin = 1
(*)
realiza slowstart
(*)
(*) TCP Reno pula a fase slowstart (recuperaçaõ rápida)
após três ACKs duplicados
33
TCP AIMD
Retransmissão Rápida
• Com freqüência, o tempo de expiração é relativamente longo:
- Longo atraso antes de reenviar um pacote perdido
• Pode-se detectar segmentos perdidos por meio de ACKs duplicados:
- Transmissor freqüentemente envia muitos segmentos ao receptor
- Se um segmento é perdido, haverá desordenamento e, portanto,
muitos ACKs duplicados.
• ACK duplicado: receptor reenvia ACK do último byte de dados
recebido em ordem qdo chega um segmento fora de ordem
• Se o transmissor recebe 3 ACKs para o mesmo dado, ele supõe que o
segmento após o dado confirmado foi perdido:
• Retransmissão rápida: perda é decretada e reenvia-se o segmento
antes do temporizador expirar
34
TCP AIMD AIMD
Redução multiplicativa: diminui o CongWin pela metade após o evento de
perda
Aumento aditivo: aumenta o CongWin com 1 MSS a cada RTT na ausência
de eventos de perda: probing
conexão TCP de longa-vida
35
Eqüidade do TCP
Objetivo de eqüidade: se K sessões TCP compartilham o mesmo enlace do
gargalo com largura de banda R, cada uma deve ter taxa média de R/K
36
Porque o TCP é justo?
Duas sessões competindo pela banda:
 O aumento aditivo fornece uma inclinação de 1, quando a vazão aumenta
 Redução multiplicativa diminui a vazão proporcionalmente
perda: reduz janela por um fator
de 2
prevenção de congestionamento:
aumento aditivo
37
Eqüidade Eqüidade do TCP
Eqüidade e UDP
 Aplicações multimedia normalmente não usam TCP
 Não querem a taxa estrangulada pelo controle de congestionamento
 Em vez disso, usam UDP:
 Trafega áudio/vídeo a taxas constantes, toleram perda de pacotes
várea de pesquisa: TCP amigável
Eqüidade e conexões TCP paralelas
 Nada previne as aplicações de abrirem conexões paralelas entre 2 hosts.
 Web browsers fazem isso
 Exemplo: enlace de taxa R suportando 9 conexões;
 Novas aplicações pedem 1 TCP, obtém taxa de R/10
 Novas aplicações pedem 11 TCPs, obtém R/2!
38