TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581

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.


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)


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


ACK=100

Host A


ACK=100

Seq=

92

tem

p.

Temporização prematura,ACKs cumulativos

Host B


ACK=120


Seq=

92

tem

p.

ACK=120

tem

pori

zaçã

o

lossX

Cap. 3: Camada de

Transporte7

TCP: cenários de retransmissão

Host A


ACK=100

Seq=

92

tem

p.

Efeito deACKs cumulativos

Host B


ACK=120


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


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


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


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!


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


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


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

TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581

Documents