Cap03b TCP

Prévia do material em texto

*
*Cap. 3: Camada de Transporte
*
TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581
dados full-duplex:
transmissão bi-direcional na mesma conexão
MSS: maximum segment size
orientado a conexões: 
handshaking (troca de mensagens de controle) inicializa o estado do transmissor e do receptor antes da troca de dados 
controle de fluxo:
transmissor não esgota a capacidade do receptor
ponto-a-ponto:
um transmissor, um receptor 
confiável, seqüêncial -> byte stream:
mensagens não são delimitadas
pipelined: transmissão de vários pacotes sem confirmação (ACK)
Controle de congestionamento e de fluxo definem o tamanho da janela de transmissão
buffers de transmissão e de recepção
socket
port
TCP
buffe de tx
TCP
buffer de rx
socket
port
segment
aplicação
envia dados
aplicação
lê dados 
*
*Cap. 3: Camada de Transporte
*
Estrutura do Segmento TCP
porta origem
porta destino
32 bits
dados de aplicação
(tamanho variável)
número de seqüência
número de reconhecimento
janela de recep.
dados urgentes
checksum
F
S
R
P
A
U
tam.
cabec.
não
usado
Opções (tamanho variável)
URG: dados urgentes 
(pouco usado)
ACK: campo de ACK
é válido
PSH: acelera entrega dos dados p/ app. no receptor(pouco usado)
RST, SYN, FIN:
gerenc. de conexão
(comandos de 
estabelec. e término)
número de bytes 
que o receptor
está pronto para 
aceitar
contagem por
bytes de dados
(não segmentos!)
Internet
checksum
(como no UDP)
*
*Cap. 3: Camada de Transporte
*
Números de Seqüência e ACKs do TCP 
Números de seqüência:
número do primeiro byte de dados no segmento TCP
ACKs:
número do próximo byte esperado do outro lado
ACK cumulativo Q: como o receptor trata segmentos foram de ordem?
descarta?
bufferiza para entrega posterior em ordem?
A especificação do TCP não define, fica a critério do implementador!
Host A
Host B
Seq=42, ACK=79, data = ‘C’
Seq=79, ACK=43, data = ‘C’
Seq=43, ACK=80
Usuário
digita
‘C’
host confirma
recepção
do ‘C’ ecoado
host confirma
recepção de
‘C’, e ecoa o
’C’ de volta
cenário telnet simples
*
*Cap. 3: Camada de Transporte
*
TCP: transferência de dados confiável
transmissor simplificado, assumindo que não há controle de fluxo nem de congestionamento
wait
for 
event
espera
por
evento
evento: dados recebidos 
da aplicação acima
evento: temporização esgotada 
para segmento com seq = y
evento: ACK recebido,
com número de ACK = y
cria, envia segmento
retransmite segmento
processamento do ACK
*
*Cap. 3: Camada de Transporte
*
TCP: transferência confiável
00 sendbase = initial_sequence number 
01 nextseqnum = initial_sequence number 
02
03 loop (forever) { 
04 switch(event) 
05 event: dados recebidos da aplicação acima 
06 cria segmento TCP com número de seqüência nextseqnum 
07 if (temporizador ainda não iniciado)
08 inicia temporizador
09 passa segmento ao IP 
10 nextseqnum = nextseqnum + length(data) 
11 break;
12 event: esgotamento de temporizador 
13 retransmite segmento não reconhec. com menor núm. seq. 
14 inicia temporizador
15 break;
16 event: ACK recebido, com valor y no campo de ACK 
17 if (y > sendbase) { /* ACK cumulativo de todos os dados até y */ 
18 sendbase = y 
19 if (ainda há segmentos com reconhecimento pendente)
20 inicia temporizador
21 }
21 break;
22 } /* end of loop forever */ 
Transmissor
TCP simplificado
*
*Cap. 3: Camada de Transporte
*
TCP: cenários de retransmissão
Host A
Seq=92, 8 bytes data
ACK=100
Cenário com perda
do ACK
Host B
Seq=92, 8 bytes data
ACK=100
Host A
Seq=100, 20 bytes data
ACK=100
Seq=92 temp.
Temporização prematura,
ACKs cumulativos
Host B
Seq=92, 8 bytes data
ACK=120
Seq=92, 8 bytes data
Seq=92 temp.
ACK=120
temporização
loss
X
*
*Cap. 3: Camada de Transporte
*
TCP: cenários de retransmissão
Host A
Seq=100, 20 bytes data
ACK=100
Seq=92 temp.
Efeito de
ACKs cumulativos
Host B
Seq=120, 8 bytes data
ACK=120
Seq=92, 8 bytes data
loss
X
*
*Cap. 3: Camada de Transporte
*
Geração de ACK [RFC 1122, RFC 2581]
Evento
segmento chega em ordem, 
não há lacunas,
segmentos anteriores já aceitos
segmento chega em ordem, 
não há lacunas,
um ACK atrasado pendente
segmento chega fora de ordem
número de seqüência chegou
maior: lacuna detectada
chegada de segmento que
parcial ou completamente
preenche a lacuna 
Ação do TCP Receptor
Atrasa o ACK. Espera até 500ms
pelo próximo segmento. Se não chegar,
envia segmento “vazio” com ACK
imediatamente envia um ACK
cumulativo
envia ACK duplicado, indicando número 
de seqüência do próximo byte esperado 
(menor núm. seq. na lacuna)
Reconhece (ACK) imediatamente se o
Segmento começa na borda inferior
da lacuna
TCP Fast Retransmit:
detecta perda antes do timeout
*
*Cap. 3: Camada de Transporte
*
TCP Fast Retransmit
TCP interpreta a recepção de ACKs duplicados como a perda do segmento enviado posteriormente àquele ao qual os ACKs se referem
retransmite o segmento após 3 ACKs duplicados
Permite detectar a perda de um pacote de maneira mais rápida (antes do timeout)
*
*Cap. 3: Camada de Transporte
*
TCP: transferência confiável
00 sendbase = initial_sequence number 
01 nextseqnum = initial_sequence number 
02
03 loop (forever) { 
04 switch(event) 
05 event: dados recebidos da aplicação acima 
06 cria segmento TCP com número de seqüência nextseqnum 
07 if (temporizador ainda não iniciado)
08 inicia temporizador
09 passa segmento ao IP 
10 nextseqnum = nextseqnum + length(data) 
11 break;
12 event: esgotamento de temporizador 
13 retransmite segmento não reconhec. com menor núm. seq. 
14 inicia temporizador
15 break;
16 event: ACK recebido, com valor y no campo de ACK 
17 if (y > sendbase) { /* ACK cumulativo de todos os dados até y */ 
18 sendbase = y 
19 if (ainda há segmentos com reconhecimento pendente)
20 inicia temporizador
21 }
22 else { /* recebeu ACK duplicado */
23 incrementa o contador de ACKs duplicados para segmento y
24 if (número de ACKs duplicados para segmento y for igual a 3)
25 /* TCP Fast Retransmit */
26 re-envia segmento com número de seqüência y
27 } 
21 break;
22 } /* end of loop forever */ 
Transmissor
TCP simplificado
Incluindo
“Fast Retransmit”
*
*Cap. 3: Camada de Transporte
*
TCP Round Trip Time e Temporização
Q: como escolher o valor da temporização (timeout) do TCP?
maior que o RTT
nota: RTT é variável
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
*
*Cap. 3: Camada de Transporte
*
TCP Round Trip Time e Temporização
Definindo a temporização
EstimtedRTT mais uma “margem de segurança”
grandes variações no EstimatedRTT  maior margem de segurança
EstimatedRTT = (1-x) * EstimatedRTT + x * SampleRTT
Média ponderada
valor típico de x = 0.1: história (representada pela estimativa anterior) tem mais peso que o último RTT medido
influência deuma dada amostra decresce de forma exponencial 
Temporização = EstimatedRTT + 4*Desvios
Desvio = (1-x) * Desvio +
 x * |SampleRTT - EstimatedRTT|
*
*Cap. 3: Camada de Transporte
*
TCP Estabelecimento de Conexão
 TCP transmissor estabelece conexão com o receptor antes de trocar segmentos de 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 SYN,ACK 
reconhece o SYN recebido
aloca buffers
especifica o número de seqüência inicial do servidor
Passo 3: o sistema final cliente reconhece o SYN,ACK
*
*Cap. 3: Camada de Transporte
*
TCP Estabelecimento de Conexão
cliente
SYN=1, seq=client_isn
servidor
SYN=1, seq=server_isn
ack=client_isn+1
SYN=0, seq=client_isn+1,
ack=server_isn+1
Connection
request
Connection
granted
Connection
open
*
*Cap. 3: Camada de Transporte
*
TCP Término de Conexão
Fechando uma conexão:
cliente fecha o socket: clientSocket.close(); 
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. 
cliente
FIN
servidor
ACK
ACK
FIN
close
close
closed
espera temp.
*
*Cap. 3: Camada de Transporte
*
TCP Término de Conexão
Passo 3: cliente recebe FIN, responde com ACK. 
Entra em “espera temporizada” - vai responder com ACK a eventuais FINs recebidos
se o ACK original do cliente se perder
Passo 4: servidor, recebe ACK. Conexão fechada. 
cliente
FIN
servidor
ACK
ACK
FIN
closing
closing
closed
espera temp.
closed
*
*Cap. 3: Camada de Transporte
*
TCP Controle de Conexão
Estados do Cliente
*
*Cap. 3: Camada de Transporte
*
TCP Controle de Conexão
Estados do Servidor
*
*Cap. 3: Camada de Transporte
*
TCP: Controle de Fluxo
receptor: explicitamente informa o transmissor sobre a quantidade de área livre no buffer (que varia dinamicamente) 
campo RcvWindow no cabeçalho do segmento TCP
transmissor: mantém a quantidade de dados pendentes (transmitidos mas ainda não reconhecidos) menor que a quantidade expressa no último RcvWindow recebido
transmissor não deve esgotar o buffer do receptor enviando dados rápido demais
armazenamento de recepção
RcvBuffer = tamanho do Buffer de recepção do TCP
RcvWindow = total de espaço livre no buffer
*
*Cap. 3: Camada de Transporte
*
Princípios de Controle de Congestionamento
Congestionamento:
informalmente: “muitas fontes enviando dados acima da capacidade da rede de tratá-los”
diferente de controle de fluxo!
controle de fluxo: considera transmissor e receptor apenas
controle de congestionamento: visão global da rede
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!
*
*Cap. 3: Camada de Transporte
*
Causas/custos do congestionamento: cenário 1 
dois transmissores, dois receptores
um roteador com buffers infinitos
link compartilhado
não há retransmissão
C: capacidade do link
λin: taxa de transm.
λout: taxa de recep.
grandes atrasos quando congestionado
máxima vazão obtenível
*
*Cap. 3: Camada de Transporte
*
Causas/custos do congestionamento: cenário 2 
um roteador com buffers finitos 
transmissor reenvia pacotes perdidos
*
*Cap. 3: Camada de Transporte
*
Causas/custos do congestionamento: cenário 2 
sem perdas: (tráfego bom); enquanto 
“perfeita” retransmissão, somente quando há perdas:
retransmissão de pacotes atrasados (não perdidos) torna maior (que o caso perfeito) para o mesmo
“custos” do congestionamento: 
mais trabalho (retransmissões) para uma certa quantidade de dados originais
retransmissões desnecessárias: enlace transporta várias cópias do mesmo pacote
*
*Cap. 3: Camada de Transporte
*
Causas/custos do congestionamento: cenário 3 
quatro transmissores
caminhos com múltiplos saltos
temporizações/retransmissões
Q: o que acontece quando e aumentam ?
*
*Cap. 3: Camada de Transporte
*
Causas/custos do congestionamento: cenário 3 
Outro “custo” do congestionamento: 
quando pacote é descartado, qualquer capacidade de transmissão que tenha sido anteriormente usada para aquele pacote é desperdiçada!
*
*Cap. 3: Camada de Transporte
*
Abordagens do problema de controle de congestionamento
Controle de congestionamento fim-a-fim:
não usa realimentação explícita da rede
congestionamento é inferido a partir das perdas e dos atrasos observados nos sistemas finais
abordagem usada pelo TCP
Controle de congestionamento assistido pela rede:
roteadores enviam informações para os sistemas finais
bit único indicando o congestionamento (SNA, DECbit, TCP/IP ECN, ATM)
a taxa máxima aceitável pode ser notificada explicitamente ao transmissor pela rede
Existem duas abordagens gerais para o problema de controle de congestionamento:
*
*Cap. 3: Camada de Transporte
*
TCP: Controle Congestionamento
Controle fim-a-fim (não há assistência da rede)
A taxa de transmissão é limitada pelo tamanho da janela 
Dois limites: CongWin (janela de congestionamento) e RcvWindow
Na prática: janela = min{CongWin, RcvWindow}
w segmentos, cada um com MSS bytes enviados em um RTT:
Congwin
RcvWindow
*
*Cap. 3: Camada de Transporte
*
TCP: Controle Congestionamento
“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
AIMD - congestion avoidance
 variáveis importantes:
Congwin
threshold: define o limite entre a fase slow start e a fase congestion avoidance
*
*Cap. 3: Camada de Transporte
*
AIMD (Additive-Increase, Multiplicative-Decrease)
TCP congestion avoidance:
AIMD: aumento aditivo, redução multiplicativa 
aumenta a janela de 1 a cada RTT
diminui a janela por um fator de 2 em caso de evento perda
Evento de perda: 3 ACKs duplicados
Adotado no TCP Reno (versão mais recente)
8K
16K
24K
tempo
Janela de Congestionamento
*
*Cap. 3: Camada de Transporte
*
TCP Slowstart
aumento exponencial (por RTT) no tamanho da janela (não tão lento!)
evento de perda : timeout (Tahoe TCP) e/ou 3 ACKs duplicados (Reno TCP)
inicializar: Congwin = 1
para (cada segmento reconhecido
 Congwin++
até (evento perda OU
 CongWin > threshold)
Host A
one segment
RTT
Host B
two segments
four segments
*
*Cap. 3: Camada de Transporte
*
TCP: Congestion Avoidance
/* acabou slowstart */ 
/* Congwin > threshold */
Até (evento perda) {
 cada w segmentos reconhecidos:
 Congwin++
 }
threshold = Congwin/2
Congwin = 1
realiza slowstart
Congestion avoidance
1: TCP Reno pula a fase slowstart (recuperaçaõ rápida)
após três ACKs duplicados 
*
*Cap. 3: Camada de Transporte
*
TCP Tahoe Vs. TCP Reno
TCP Tahoe (sempre)
ou
TCP Reno após
timeout
TCP Reno após 3
ACKs duplicados
(AIMD)
*
*Cap. 3: Camada de Transporte
*
TCP: Congestion Avoidance
(Tahoe TCP)
/* acabou slowstart (CongWin > threshold) */
/* Inicia congestion avoidance: crescimento 
 linear de CongWin */
Até (novo evento de perda - qualquer) {
 a cada w segmentos reconhecidos:
 CongWin++
}
/* após evento de perda */
threshold = CongWin/2
CongWin = 1
realiza slowstart até threshold
reinicia congestion avoidance
Congestion avoidance*
*Cap. 3: Camada de Transporte
*
TCP: Congestion Avoidance
(Reno TCP)
/* acabou slowstart (CongWin > threshold) */
/* Inicia congestion avoidance: crescimento 
 linear de CongWin */
Até (novo evento de perda) {
 a cada w segmentos reconhecidos:
 CongWin++
}
threshold = CongWin / 2
se timeout:
	CongWin = 1
	realiza slowstart até threshold
senão, se 3 ACKs duplicados:
	CongWin = thresholdd
reinicia congestion avoidance
Congestion avoidance
*
*Cap. 3: Camada de Transporte
*
TCP: Eqüidade (fairness)
Objetivo: se N sessões TCP devem passar pelo mesmo gargalo, cada uma deve obter 1/N da capacidade do enlace
conexão TCP 1
roteador com
gargalo de capacidade R
conexão TCP 2
*
*Cap. 3: Camada de Transporte
*
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 
R
R
divisão igual da banda
Vazão da Conexão 2
Vazão da Conexão 1
congestion avoidance: aumento aditivo
perda: reduz janela por um fator de 2
congestion avoidance: aumento aditivo
perda: reduz janela por um fato de 2
*
*Cap. 3: Camada de Transporte
*
Capítulo 3: Resumo
princípios por trás dos serviços da camada de transporte:
multiplexação/demultiplexação
transferência de dados confiável
controle de fluxo
controle de congestionamento
instanciação e implementação na 
UDP
TCP
A seguir:
saímos da “borda” da rede (camadas de aplicação e de transporte)
vamos para o “núcleo” da rede
Camada de Rede
Camada de Enlace
*
*Cap. 3: Camada de Transporte
*
Anexos:
*
*Cap. 3: Camada de Transporte
*
Estudo de caso: controle de congestionamento do serviço ATM ABR
ABR: Available Bit Rate
“serviço elástico” 
se o caminho do transmissor está pouco usado: 
transmissor pode usar a banda disponível
se o caminho do transmissor está congestionado: 
transmissor é limitado a uma taxa mínima garantida
células RM (Resource Management) :
enviadas pelo transmissor, entremeadas com as células de dados 
bits nas células RM são usados pelos comutadores (“assistida pela rede”) 
NI bit: não aumentar a taxa de transmissão (congestionamento leve)
CI bit: indicação de congestionamento: restringir a taxa de transmissão
as células RM são devolvidos ao transmissor pelo receptor, com os bits de indicaçaõ intactos
 
*
*Cap. 3: Camada de Transporte
*
Estudo de caso: controle de congestionamento do serviço ATM ABR
campo ER (explicit rate) de dois bytes nas células RM 
comutador congestionado pode reduzir o valor de ER nas células 
o transmissor envia dados de acordo com a menor vazão máxima suportada no caminho (i.e., pelo comutador mais congestionado)
bit EFCI nas células de dados: marcado como 1 pelos comutadores congestionados 
se a célula de dados que precede a célula RM tem o bit EFCI com valor 1, o receptor marca o bit CI na célula RM devolvida
*
*Cap. 3: Camada de Transporte
*
TCP: modelagem da latência
Q: Quanto tempo demora para receber um objeto de um servidor Web após enviar um pedido? 
estabelecimento de conexão TCP
atraso de transferência de dados 
Notação, hipóteses:
Assuma um enlace entre o cliente e o servidor com taxa de dados R
Assuma: janela de congestionamento fixa, W segmentos
S: MSS (bits)
O: tamanho do objeto (bits)
não há retransmissões (sem perdas e corrupção de dados)
Dois casos a considerar:
WS/R > RTT + S/R: ACK para o primeiro segmento retorna antes de se esgotar a janela de transmissão de dados
WS/R < RTT + S/R: espera pelo depois de esgotar a janela de transmissão de dados
*
*Cap. 3: Camada de Transporte
*
TCP: modelagem da latência
Caso 1: latencia = 2RTT + O/R
Caso 2: latencia = 2RTT + O/R
+ (K-1)[S/R + RTT - WS/R]
K:= O/WS
*
*Cap. 3: Camada de Transporte
*
TCP Modelagem de Latência: Slow Start
Agora suponha que a janela cresce de acordo com os procedimentos da fase slow start. 
Vamos mostrar que a latência de um objeto de tamanho O é: 
onde P é o número de vezes que o TCP fica bloqueado no servidor:
- onde Q é o número de vezes que o servidor ficaria bloqueado se 
 o objeto fosse de tamanho infinito.
- e K é o número de janelas que cobrem o objeto.
*
*Cap. 3: Camada de Transporte
*
TCP Modelagem de Latência: Slow Start (cont.)
Exemplo:
O/S = 15 segmentos
K = 4 janelas
Q = 2
P = min{K-1,Q} = 2
Servidor bloqueado P=2 times.
*
*Cap. 3: Camada de Transporte
*
TCP Modelagem de Latência: Slow Start (cont.)
R
S
R
S
RTT
P
RTT
R
O
R
S
RTT
R
S
RTT
R
O
TempoBloqueio
RTT
R
O
P
k
P
k
P
p
p
)
1
2
(
]
[
2
]
2
[
2
2
latencia
1
1
1
-
-
+
+
+
=
-
+
+
+
=
+
+
=
-
=
=
å
å
tempo de bloqueio após a
k-ésima janela
 
2
1
R
S
RTT
R
S
k
=
ú
û
ù
ê
ë
é
-
+
+
-
até quando o servidor recebe reconhecimento
 
 
tempo quando o servidor inicia o envio do segmento
=
+
RTT
R
S
tempo para enviar a k-ésima janela
2
1
=
-
R
S
k