tcp: overview rfcs: 793, 1122, 1323, 2018, 2581
DESCRIPTION
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: - PowerPoint PPT PresentationTRANSCRIPT
Cap. 3: Camada de
Transporte1
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
socketport
TCPbuffe de tx
TCPbuffer de rx
socketport
segment
aplicaçãoenvia dados
aplicaçãolê dados
Cap. 3: Camada de
Transporte2
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 reconhecimentojanela de recep.
dados urgenteschecksum
FSRPAUtam.
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 receptorestá pronto para aceitar
contagem porbytes de dados(não segmentos!)
Internetchecksum
(como no UDP)
Cap. 3: Camada de
Transporte3
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áriodigita
‘C’
host confirmarecepção
do ‘C’ ecoado
host confirmarecepção de‘C’, e ecoa o’C’ de volta
tempocenário telnet simples
Cap. 3: Camada de
Transporte4
TCP: transferência de dados confiável
transmissor simplificado, assumindo que não há controle de fluxo nem de congestionamento
waitfor
event
esperapor
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
Transporte5
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 */
TransmissorTCP simplificado
Cap. 3: Camada de
Transporte6
TCP: cenários de retransmissão
Host A
Seq=92, 8 bytes data
ACK=100
tempoCená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
tem
p.
Temporização prematura,ACKs cumulativos
Host B
Seq=92, 8 bytes data
ACK=120
Seq=92, 8 bytes data
Seq=
92
tem
p.
ACK=120
tem
pori
zaçã
o
lossX
Cap. 3: Camada de
Transporte7
TCP: cenários de retransmissão
Host A
Seq=100, 20 bytes data
ACK=100
Seq=
92
tem
p.
Efeito deACKs cumulativos
Host B
Seq=120, 8 bytes data
ACK=120
Seq=92, 8 bytes data
tempo
lossX
Cap. 3: Camada de
Transporte8
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 ordemnúmero de seqüência chegoumaior: lacuna detectada
chegada de segmento queparcial ou completamentepreenche a lacuna
Ação do TCP Receptor
Atrasa o ACK. Espera até 500mspelo próximo segmento. Se não chegar,envia segmento “vazio” com ACK
imediatamente envia um ACKcumulativo
envia ACK duplicado, indicando número de seqüência do próximo byte esperado (menor núm. seq. na lacuna)
Reconhece (ACK) imediatamente se oSegmento começa na borda inferiorda lacuna
TC
P F
ast
Retr
an
smit
:d
ete
cta p
erd
a a
nte
s d
o t
imeou
t
Cap. 3: Camada de
Transporte9
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
Transporte10
TCP: transferência confiável
00 sendbase = initial_sequence number 01 nextseqnum = initial_sequence number 0203 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 temporizador09 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 temporizador15 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 temporizador21 }22 else { /* recebeu ACK duplicado */23 incrementa o contador de ACKs duplicados para segmento y24 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 y27 } 21 break;22 } /* end of loop forever */
TransmissorTCP simplificado
Incluindo“Fast Retransmit”
Cap. 3: Camada de
Transporte11
TCP Round Trip Time e TemporizaçãoQ: 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
Transporte12
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 de uma dada amostra decresce de forma exponencial
Definindo a temporização EstimtedRTT mais uma “margem de segurança” grandes variações no EstimatedRTT maior margem de
segurançaTemporização = EstimatedRTT + 4*Desvios
Desvio = (1-x) * Desvio + x * |SampleRTT - EstimatedRTT|
TCP Round Trip Time e Temporização
Cap. 3: Camada de
Transporte13
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
Transporte14
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
Connectionrequest
Connectiongranted
Connectionopen
Cap. 3: Camada de
Transporte15
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
esp
era
tem
p.
Cap. 3: Camada de
Transporte16
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
esp
era
tem
p.
closed
Cap. 3: Camada de
Transporte17
TCP Controle de Conexão
Estados do Cliente
Cap. 3: Camada de
Transporte18
TCP Controle de Conexão
Estados do Servidor
Cap. 3: Camada de
Transporte19
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
controle de fluxo
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
Transporte20
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
Transporte21
Causas/custos do congestionamento:
cenário 1 dois transmissores,
dois receptores um roteador com
buffers infinitos link compartilhado não há
retransmissãoC: 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
Transporte22
um roteador com buffers finitos transmissor reenvia pacotes perdidos
Causas/custos do congestionamento:
cenário 2
Cap. 3: Camada de
Transporte23
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
in
out
>
in
out
“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
Causas/custos do congestionamento:
cenário 2
inC/2<
in
in=
in
out=
Cap. 3: Camada de
Transporte24
quatro transmissores caminhos com múltiplos saltos temporizações/retransmissões
in
Q: o que acontece quando e aumentam ?
in
Causas/custos do congestionamento:
cenário 3
Cap. 3: Camada de
Transporte25
Outro “custo” do congestionamento: quando pacote é descartado, qualquer capacidade de transmissão que
tenha sido anteriormente usada para aquele pacote é desperdiçada!
Causas/custos do congestionamento:
cenário 3
Cap. 3: Camada de
Transporte26
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
Transporte27
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:
vazão = w * MSS
RTT Bytes/seg
CongwinRcvWindow
Cap. 3: Camada de
Transporte28
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
“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
TCP: Controle Congestionamento
Cap. 3: Camada de
Transporte29
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
Jane
la d
e C
onge
stio
nam
ento
Cap. 3: Camada de
Transporte30
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 = 1para (cada segmento reconhecido Congwin++até (evento perda OU CongWin > threshold)
algoritmo SlowstartHost A
one segment
RTT
Host B
tempo
two segments
four segments
Cap. 3: Camada de
Transporte31
TCP: Congestion Avoidance
/* acabou slowstart */ /* Congwin > threshold */Até (evento perda) { cada w segmentos reconhecidos: Congwin++ }threshold = Congwin/2Congwin = 1realiza slowstart
Congestion avoidance
1: TCP Reno pula a fase slowstart (recuperaçaõ rápida)após três ACKs duplicados
Cap. 3: Camada de
Transporte32
TCP Tahoe Vs. TCP Reno
TCP Tahoe (sempre)ouTCP Reno apóstimeout
TCP Reno após 3ACKs duplicados(AIMD)
Cap. 3: Camada de
Transporte33
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/2CongWin = 1realiza slowstart até thresholdreinicia congestion avoidance
Congestion avoidance
Cap. 3: Camada de
Transporte34
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 / 2se timeout:
CongWin = 1realiza slowstart até threshold
senão, se 3 ACKs duplicados:CongWin = thresholdd
reinicia congestion avoidance
Congestion avoidance
Cap. 3: Camada de
Transporte35
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 comgargalo de capacidade Rconexão TCP
2
Cap. 3: Camada de
Transporte36
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 d
a C
onexão 1
congestion avoidance: aumento aditivoperda: reduz janela por um fator de 2
congestion avoidance: aumento aditivoperda: reduz janela por um fato de 2
Cap. 3: Camada de
Transporte37
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
Transporte38
Anexos:
Cap. 3: Camada de
Transporte39
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
Transporte40
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
Estudo de caso: controle de congestionamento do serviço ATM ABR
Cap. 3: Camada de
Transporte41
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
Transporte42
Caso 1: latencia = 2RTT + O/R Caso 2: latencia = 2RTT + O/R
+ (K-1)[S/R + RTT - WS/R]
K:= O/WS
TCP: modelagem da latência
Cap. 3: Camada de
Transporte43
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 é:
R
S
R
SRTTP
R
ORTTLatency P )12(2
onde P é o número de vezes que o TCP fica bloqueado no servidor:
}1,{min KQP
- 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
Transporte44
RTT
iniciaconexão TCP
pedeobjeto
primeira janela= S/R
segunda janela= 2S/R
terceira janela= 4S/R
quarta janela= 8S/R
transmissãocompletaobjeto
entregue
tempo nocliente
tempo noservidor
Exemplo:
O/S = 15 segmentos
K = 4 janelas
Q = 2
P = min{K-1,Q} = 2
Servidor bloqueado P=2 times.
TCP Modelagem de Latência: Slow Start (cont.)
Cap. 3: Camada de
Transporte45
R
S
R
SRTTPRTT
R
O
R
SRTT
R
SRTT
R
O
TempoBloqueioRTTR
O
P
kP
k
P
pp
)12(][2
]2[2
2latencia
1
1
1
tempo de bloqueio após ak-ésima janela 2 1
R
SRTT
R
S k
até quando o servidor recebe reconhecimento
tempo quando o servidor inicia o envio do segmentoRTTR
S
tempo para enviar a k-ésima janela2 1
R
Sk
TCP Modelagem de Latência: Slow Start (cont.)
RTT
iniciaconexão TCP
pedeobjeto
primeira janela= S/R
segunda janela= 2S/R
terceira janela= 4S/R
quarta janela= 8S/R
transmissãocompletaobjeto
entregue
tempo nocliente
tempo noservidor