TCP: Visão geral RFCs: 793, 1122, 1323, 2018, 2581

3: Nível de Transporte 3b-1

TCP: Visão geral RFCs: 793, 1122, 1323, 2018, 2581

Transmissão de dados bi-direccional: Transmissão de dados bi-

direccional na mesma ligação

MSS: maximum segment size

Orientado-à-ligação: handshaking

(transferência de mensagens de controlo)

• Inicia o estado do emissor e do receptor antes de transferir os dados

Fluxo controlado: Emissor não sobrecarrega

o receptor

Ponto-a-ponto: Um emissor, um receptor

Cadeia de bytes ordenada e fiável: Não há “fronteiras nas

mensagens” pipelined:

TCP dimensão das janelas de controlo de congestão e de fluxo ajustável

Buffers no emissor e receptor

socketdoor

TCPBuffer de envio

TCPBuffer de recepção

socketdoor

AplicaçãoEscrita de dados

AplicaçãoLeitura de dados

segmento


TCP: estrutura do segmento

# porto origem# porto destino

32 bits

applicationdata

(variable length)

Número sequênciaNúmero

acknowledgmentrcvr window size

ptr urgent datachecksum

FSRPAUheadlen

notused

Opções (dimensão variável)



# porto destino

32 bits

applicationdata

(variable length)




FSRPAUheadlen

notused


# porto origem Nº de sequência e Nº de ACKS: Contagem por bytes de dados Não segmentos !

Head Length em palavras de 32 b Dimensão sem extensões 20 B

RCVR Window Size: Nº de Bytes que o receptor espera

receber

Opções: Negociação de parâmetros

• MSS (usual 1500; 536; 512 B)• Factor de escala p/ janela em

ligações de alto débito



# porto destino

32 bits

applicationdata

(variable length)




FSRPAUheadlen

notused


# porto origem Flags de sinalização de informação urgente:

U – URG: dados que o nível superior do emissor sinalizou como urgentes

P – PSH: O receptor deve passar os dados para o nível superior imediata/

Flags de controlo A – ACK: valor válido no campo ACK R- RST; S- SYN; F – FIN:

estabelecimento e terminação da ligação

Ptr Urgent data Apontador para o último byte de

dados que contém dados urgentes


TCP nº de sequência e ACKSeq. #’s:

Nº da cadeia de bytes do primeiro byte do segmento de dados

ACKs: Nº de seq. do

próximo byte esperado do outro lado

ACK acumulativoQ: Como é que o receptor

processa segmentos for a de ordem ? A: A especificação

TCP não é clara, deixando esta questão para a implementação

Host A Host B

Seq=42, ACK=79, data = ‘C’

Seq=79, ACK=43, data = ‘C’

Seq=43, ACK=80

Utilizadordigita

‘C’

Sistema Terminal confirma (ACK)

e ecoa o ‘C’

Sistema Terminal recebe ‘C’ e

e ecoa de volta o ‘C’

tempoCenário simples de Telnet


TCP: cenários de retransmissão

Host A

Seq=92, 8 bytes data

ACK=100

loss

tim

eout

tempo Perda de ACK

Host B

X


ACK=100

Host A


ACK=100

Seq=

92

tim

eout

tempo Timeout antecipado,ACKs acumulativo

Host B


ACK=120


Seq=

10

0 t

imeou

t

ACK=120


TCP: transferência de dados fiável

Emissor simplificado, assume:

waitfor

event

waitfor

event

evento: dados recebidosdas aplicações dos

níveis superiores

evento: temporizador expira para o segmento com o nº de seq. y

evento: ACK recebido com ACK y

criação, envio do segmento

Retransmisssão do segmento y

ACK processado

•Transferência de dados uni-direcccional•Sem controlo de fluxo•Sem controlo de congestão


TCP: transferência de dados fiável

00 sendbase = initial_sequence number 01 nextseqnum = initial_sequence number 0203 loop (forever) { 04 switch(event) 05 event: data received from application above 06 create TCP segment with sequence number nextseqnum 07 start timer for segment nextseqnum 08 pass segment to IP 09 nextseqnum = nextseqnum + length(data) 10 event: timer timeout for segment with sequence number y 11 retransmit segment with sequence number y 12 compute new timeout interval for segment y 13 restart timer for sequence number y 14 event: ACK received, with ACK field value of y 15 if (y > sendbase) { /* cumulative ACK of all data up to y */ 16 cancel all timers for segments with sequence numbers < y 17 sendbase = y 18 } 19 else { /* a duplicate ACK for already ACKed segment */ 20 increment number of duplicate ACKs received for y 21 if (number of duplicate ACKS received for y == 3) { 22 /* TCP fast retransmit */ 23 resend segment with sequence number y 24 restart timer for segment y 25 } 26 } /* end of loop forever */

Emissor TCP simplificado


TCP Controlo de fluxoreceptor:

Informa explicitamente o emissor da quantidade de buffer livre, de forma dinâmica

RcvWindow: • campo usado do cabeçalho TCP

emissor: Mantém a quantidade

de dados transmitidos e não confirmados (unACKed) inferior ao valor mais recente que recebeu da janela RcvWindow

Emisor não sobrecarrega o

receptor por transmitir demasiadamente

rápido

Controlo de fluxo

Não controla

o que sepassa na rede


TCP Controlo de fluxo - receptor

LastByteRead = nº do último byte lido do buffer pela aplicação do lado BLastByteRcv = nº do último byte recebido da rede e colocado no buffer do lado B

LastByteRcv – LastByteRead <= RcvBuffer

RcvWindow = RcvBuffer – [LastByteRcv – LastByteRead]

RcvBuffer = dimensão do buffer de recepção do TCP

RcvWindow = quantidade de espaço disponível no buffer

LastByteReadLastByteRcv


TCP Controlo de fluxo - emissor

LastByteSend= nº do último byte enviado para a rede LastByteAck = nº do último byte que foi confirmada a recepção

LastByteSend – LastByteAcK <= RcvWindow

RcvBuffer = dimensão do buffer de recepção do TCP

RcvWindow = quantidade de espaço disponível no buffer

receptor: Sinaliza o emissor RcvWindow = 0 Não tem mais informação para enviar para o emissor

emissor: Não pode enviar mais informação !

Solução: TCP “obriga” o emissor a enviar um segmento de 1 B

para obrigar o receptor a responder


TCP Round Trip Time eTimeout

Q: como estabelecer o valor de timeout do TCP?

Superior a RTT nota: RTT vai

variar Muito pequeno:

timeout antecipado Retransmissões

desnecessárias Muito longo: reacção

lenta à perda de segmentos

Q: Como estimar RTT? SampleRTT: tempo medido

desde a transmissão do segmento para o nível de rede até à recepção do ACK Ignora retransmissões, Faz o ACK acumulativo dos

segmentos SampleRTT vai variar,

Estimar RTT de forma “suave” Usar várias medidas

recentes e não apena o valor corrente de SampleRTT


TCP Round Trip Time e Timeout

EstimatedRTT = (1-x)*EstimatedRTT + x*SampleRTT Exponential weighted moving average Influência de uma amostra decresce com uma rapidez

exponencial Valor típico de x: 0.125

Parametrizando o timeout EstimatedRTT mais “margem de segurança” Grande variação em EstimatedRTT -> margem de

segurança superior

Timeout = EstimatedRTT + 4*Deviation

Deviation = (1-x)*Deviation + x*|SampleRTT-EstimatedRTT|

Mede a variação de SampleRTT em relação ao EstimatedRTT


TCP Gestão das ligações

Recordar: O emissor TCP estabelece uma ligação antes de iniciar a transmissão dos segmentos

Inicialização das variáveis TCP: Nº de sequência Buffers Informação de janela de

controlo de fluxo (RcvWindow)

Cliente: Inicia a ligaçãosocket_fd=socket(Domínio, Tipo, 0)

connect(socket_fd,estr_ender,dim_estr_ender)

Domínio =PF_INET(comunicação entre STs IPVv4)

Tipo = SOCK_STREAM (TCP) ou SOCK_DGRAM (UDP)

estr_end = domínio; porto; end IP destino)

Servidor: contactado pelo clientesocket_fd=socket(Domínio, Tipo, 0)

bind(socket_fd1,estr_endereços,dim_estr_ender)

listen (socket_fd1, num_lig_em_espera)

new_fd=accept(socket_fd1, estr_endereços, dim)

estr_end = domínio; porto; end IP origem)


TCP Gestão das ligações: Estabelecimento

Passo 1: Ligação pedidda

Sistema Terminal do cliente envia segmento SYN =1 para o servidor Não tem campo de dados Define o nº de seq. original

• client_isn

Passo 2: Ligação concedida Sistema Terminal do

Servidor recebe o segmento de controlo SYN =1 Não tem campo de dados

Confirma a recepção do seg.• Ack = client_isn+1

Define o nº de seq. inicial do servidor

• Server_isn Responde com o segmento

de controlo SYNACK

Passo 3: Ligação confirmada

Sistema Terminal do cliente envia segmento SYN = 0 para o servidor

Reserva buffers e variáveis Confirma a recepção do seg.

• Ack = server_isn+1


cliente

Connection-request(SYN=1, seq=client_isn)

servidor

Connection-granted

(SYN=1, seq=server_isn,

ack_client_isn+1)

Acknowldege(SYN=0, seq=client_isn+1, ack=server_isn+1)

pedido

Reserva buffers e variáveis

tempo

TCP Gestão das ligações: Estabelecimento

Reserva buffers e variáveis

estabelecimento


TCP Gestão das ligações: Fecho

Passo 1/2: Pedido de fim de ligação do cliente

Sistema Terminal do cliente envia o segmento de controlo FYN = 1 para terminar a ligação TCP Cancela a reserva de

recursos

Sistema Terminal do servidor confirma a recepção do FYN do cliente Envia ACK

Cliente: fecha a ligação

close(sock_fd)

Servidor: fecha a ligação com o cliente

close(sock_fd1)

Passo 3/4: Pedido de fim de ligação do servidor

Sistema Terminal do servidor envia o segmento de controlo FYN = 1 para terminar a ligação TCP Cancela a reserva de recursos

Sistema Terminal do cliente confirma a recepção do FYN do cliente Envia ACK Espera um tempo até dar a

ligação por terminada


cliente

FIN

servidor

ACK

ACK

FIN

Fechando

Fechando

FechouTem

po d

e e

spera

Fechou

TCP Gestão das ligações: Fecho


Ciclo de vida do cliente TCP

Ciclo de vida do servidor TCP

TCP Gestão das ligações: ciclo de vida


Princípios de controlo de congestão

Congestão: Informalmente: “demasiadas fontes enviam

informação a um ritmo muito superior ao que a rede é capaz de processar”

Diferente do controlo de fluxo! Sintomas:

Perda de pacote (buffer overflow nos routers)

Atrasos elevados (queueing nos buffers dos router)

Problema da lista dos TOP 10!


Causas e custos do controlo de congestão: cenário 1

Dois emissores Dois receptores Um router Buffer infinito Sem

retransmissões

Atraso elevado em situação de congestão

Débito máximo atingível


um router buffers finitos Emissor retransmite pacotes perdidos



1 - Situação ideal : (goodput)

2 - Retransmissões ocorrem quando há perdas:

3 - Retransmissões de pacotes atrasados (não perdidos) faz

maior para o mesmo

in

out

=

in

out

>

in

out

“custos” da congestão: Mais trabalho (retrans) para um dado “goodput” Retransmissões desnecessárias: ligação transporte múltiplas cópias do pacote


1

1 2 3


4 emissores Caminho com vários nós timeout/retransmissões

in

Q: o que acontece quando e aumenta ?

in


A C: R1 R2 B D: R2 R3 C A: R3 R4 D B: R4 R1



A C: R1 R2 B D: R2 R3 C A: R3 R4 D B: R4 R1

in pequeno Mais dados são transmitidos na

rede e entregues ao destino Overflow de buffers é raro out também aumenta

in e ’in muito elevado (B->D) Tráfego de A que chega a R2 pode ser aproximadamente R Tráfego de B->D que chega a R2 é muito superior ao tráfego proveniente de A->C). Quando maior for o tráfego de B->D maior é a probabilidade do tráfego de A->C

encontrar o buffer de R2 cheio com um pacote de B


Outro “custo” da congestão: Quando um pacote se perde, qualquer capacidade de

transmisssão que já tenha sido usada para o transmitir é perdida!



Aproximações ao controlo de congestão

Controlo de congestão extremo-a-extremo:

Não há feedback da rede Congestão inferida pelos

Sistemas Terminais, quando detectam perdas na rede

Aproximação do TCP

Controlo de congestão assistido pela rede:

Routers fornecem feedback aos Sistemas Terminas Um único bit indica a

congestão Envio explicíto do

ritmo a que o emissor pode enviar

Duas aproximações ao controlo de congestão:


Caso de estudo: Controlo de congestão ATM ABR

ABR: available bit rate: “Serviço elástico” Se o caminho do emissor

não está carregado: Emissor deve usar a

largura de banda disponível

Se o caminho do emissor não está congestionado : Emissor envia apenas

ao ritmo mínimo garantido

RM (resource management) cells:

Enviadas pelo emissor, intercaladas com as células de dados

Bits nas células RM activadas pelos switches (“network-assisted”) NI bit: não aumentar o ritmo

(congestão média) CI bit: indicador de

congestão Células RM cells retornadas pelo

receptor com os bits intactos


ER (explicit rate) campo de 2 bytes numa célula RM switch congestionado pode diminuir o valor de ER da célula Emissor envia ao ritmo mínimo suportado pelo caminho

EFCI bit na célula de dados: EFCI = 1 indica congestão no switch Se as células de dados que precedem a célula RM têm EFCI ctivo,

receptor activa CI na célula RM de retorno Bits CI e NI

Um switch pode activar o bit NI/CI, o qual deverá ser retornado ao emissor na próxima célula RM

Caso de estudo: Controlo de congestão ATM ABR


Controlo de congestão no TCP Controlo extremo-a-extremo (não assistido pela rede) Ritmo de transmissão limitado pela dimensão da janela

de congestão, Congwin:

W segmentos, cada um com MSS bytes enviados em cada RTT:

Débito = w * MSS

RTT Bytes/sec

Congwin


Duas fases slow start congestion avoidance

Variáveis importantes: Congwin threshold

• Define o valor de limiar (threshold) entre duas fases slow start e controlo de congestao

“probing” para a largura de banda utilizável: Idealmente: transmite

táo rápido quanto possível sem perdas (Congwin tão grande quando possível)

aumenta Congwin até perdas (congestão)

perdas: diminui Congwin, então aumenta o probing

Controlo de congestão no TCP


TCP Slowstart

Aumenta exponencialmente (por RTT) o tamanho da janela

Evento de perda: TCP Tahoe : Timeout TCP Reno: Timeout e/ou três ACKs

duplicados (recebidos antes do timeout)

initialize: Congwin = 1for (each segment ACKed) Congwin++until (loss event OR Congwin > threshold)

Algoritmo de SlowstartHost A

one segment

RTT

Host B

Tempo

two segments

four segments


TCP Congestion Avoidance

/* slowstart is over */ /* Congwin > threshold */Until (loss event) { every w segments ACKed: Congwin++ }threshold = Congwin/2Congwin = 1perform slowstart

Congestion avoidance

1

1: TCP Reno ultrapassa o slowstart (recuperação rápida ) após 3 ACKs duplicados


TCP FairnessObjectivo de justiça:

se uma ligação estrangulada é partilhada por N sessões TCP, cada uma delas deve obter 1/N da capacidade da ligação

Método de evitar congestão: Incrementa a

janela 1 unidade por RTT

Decrementa a janela 2 unidades por evento de perda

AIMD –Additive Increase Multiplicative Decrease

Ligação TCP 1

bottleneckrouter

Capacidade = R

Ligação TCP 2


Porque é que o TCP é justo ?Duas sessões em competição: Aumento aditivo:

Aumento origina um declive de 1, quando o débito aumenta

Decréscimo multiplicativo: Débito decresce proporcionalmente

R

R

Largura de Banda partilhada

igualmente

Débito da ligação 1

Débit

o d

a lig

açã

o 2

Evitar a congestão: aumento aditivo

Perdas: janela decresce por um factor 2

A

B

C

D


Modelo de latência do TCPQ: Quanto tempo demora a receber um objecto um dum Web

servidor depois de enviar um pedido ? Estabelecimento duma ligação TCP Fase de transferência de dados

Pressupostos: Ligação Cliente e o Servidor não é partilhada com outro tipo de

tráfego TCP ou UDP.

Sem retransmissões Sem perdas Sem corrupção

Headers desprezáveis Tempo de transmissão

Só é significativo para os segmentos de dimensão máxima Controlo de fluxo:

Não afecta os resultados Controlo de congestão

Threshold tão elevado que não é atingido


Modelo de latência do TCPNotações: R = Ritmo de transferência [b/s] W= Dimensão da janela de congestão

[segmentos] S = MSS Dimensão do maior segmento [bits] O = Dimensão do objecto [bits]Dois casos a considerar:

Servidor recebe o ACK do 1º segmento antes de transmitir todos os dados da janela WS/R > RTT + S/R

O Servidor transmite os dados da janela antes de receber o ACK do 1º segmento; espera ACK antes de prosseguir a transmissão WS/R < RTT + S/R


Modelo de latência TCP

Caso 1: latencia = 2RTT + O/R Caso 2: latencia = 2RTT + O/R

+ (K-1)[S/R + RTT - WS/R]

Nº de janelas que é preciso para txd o objecto• K:= O/WS

W = 4W = 2


Modelo de latência TCP: Slow Start

Supondo que a janela cresce de acordo com o SlowStart.

A latência de um objecto de dimensão O é:

R

S

R

SRTTP

R

ORTTLatency P )12(2

Em que P é o nº de vezes que o TCP no servidor bloqueia (stall)

}1,{min KQP

-em que Q é o nº de vezes que o servidor pára se o objecto tiver uma dimensão infinita

- K é o nº da janela que cobre o objecto


RTT

initia te TCPconnection

requestobject

first w indow= S /R

second w indow= 2S /R

third w indow= 4S /R

fourth w indow= 8S /R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Exemplo:

O/S = 15 segmentos

K = 4 janelas

Q = 2

P = min{K-1,Q} = 2

Servidor pára P=2 vezes.



R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

emTempoParagRTTR

Oatência

P

kP

k

P

pp

)12(][2

]2[2

2L

1

1

1

K janela da ão transmissa após espera

de Tempo 2 1

R

SRTT

R

S k

K janela ar transmitipara Tempo 2 1

R

Sk

RTT

initia te TCPconnection

requestobject

first w indow= S /R

second w indow= 2S /R

third w indow= 4S /R

fourth w indow= 8S /R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver


ACK o recebe que até objecto do ão transmissa iniciaservidor o que desde Tempo RTTR

S


Chapter 3: Summary

Princípios do serviço do nível de transporte: multiplexagem/

demultiplexagem Transferência de dados fiável Controlo de fluxo Controlo de congestão

Instanciação e implementação na Internet UDP TCP

Próximo: Deixar a periferia

da rede Entrar no ”core”

da rede

TCP: Visão geral RFCs: 793, 1122, 1323, 2018, 2581

Documents

Transcript of TCP: Visão geral RFCs: 793, 1122, 1323, 2018, 2581