Arquitetura TCP/IP. Parte XI Transporte orientado a conexão (TCP) Fabrízzio Alphonsus A. M. N. Soares

Transcrição

1 Arquitetura TCP/IP Parte XI Transporte orientado a conexão (TCP) Fabrízzio Alphonsus A. M. N. Soares

2 Tópicos Características do TCP Como o TCP fornece confiabilidade Janela deslizante Estabelecimento e encerramento de conexão TCP Portas TCP, conexões e extremidades Formato do segmento TCP Retransmissão adaptativa Cálculo do RTT Controle de fluxo e congestionamento Slow start Congestion avoidance Fast recovery, Fast retransmit

3 Características do TCP Orientação a fluxo Fluxo sem estrutura (seqüência de bytes) Transferência bufferizada Conexão full-duplex Confiabilidade Controle de fluxo e de congestionamento

4 Como o TCP fornece confiabilidade Reconhecimento positivo com retransmissão Transmissor inicia um temporizador ao transmitir um segmento Receptor envia um reconhecimento quando o segmento chega Transmissor reenvia segmento se temporizador expira antes da chegada do reconhecimento

5 Reconhecimentos

6 Recuperação após uma perda

7 Janela deslizante Um protocolo simples de reconhecimento positivo e retransmissão pacote-a-pacote é ineficiente, sobretudo à medida que aumenta a latência Solução: Transmitir múltiplos pacotes antes de receber um reconhecimento Continuar controlando reconhecimentos e temporizadores para cada pacote Ou seja, usar janela deslizante

8 Janela deslizante (cont.) Um janela deslizante de tamanho adequado consegue manter a rede saturada de pacotes Qual o tamanho adequado da janela?!

9 Janela deslizante (cont.)

10 Janela deslizante do TCP Medição da janela em bytes e tamanho variável para controlar fluxo Exemplo: Até byte 2, segmentos já foram enviados e reconhecidos Entre bytes 3 e 6, segmentos já foram enviados, mas não reconhecidos Entre bytes 7 e 9, segmentos já podem ser enviados A partir do byte 10, segmentos ainda não podem ser enviados

11 Estabelecimento de conexão TCP Aperto de mão de via tripla (3-Way handshake)

12 Encerramento de conexão TCP

13 Abertura ativa e passiva Cada conexão possui duas extremidades Uma extremidade espera por contato Parte servidora da aplicação Usa abertura passiva (passive open) do TCP Uma extremidade inicia o contato Parte cliente da aplicação Usa abertura ativa (active open) do TCP

14 Máquina de estados do TCP

15 Transferência bufferizada Aplicação escreve bytes Aplicação lê bytes TCP buffer de transmissão TCP buffer de recepção segmento segmento segmento Três mecanismos determinam o envio de um segmento Limiar (threshold) do buffer (MSS Maximum Segment Size) Forçado pela aplicação (push) Temporizador

16 Portas TCP, conexões e extremidades Em cada extremidade de uma comunicação se encontra uma aplicação Antes de estabelecer uma conexão, o TCP identifica uma aplicação pela número da porta de protocolo Após estabelecer uma conexão, esta passa a identificar as aplicações nas duas extremidades É possível compartilhar uma porta TCP entre múltiplas conexões no mesmo equipamento Uma conexão é identificada por quatro itens: Endereço IP de origem Porta TCP de origem Endereço IP de destino Porta TCP de destino

17 Formato do segmento TCP

18 Cabeçalho TCP SOURCE PORT e DESTINATION PORT identificam as aplicações nas extremidades da conexão TCP SEQUENCE NUMBER é a posição no fluxo de bytes do transmissor que está sendo transportada no segmento ACKNOWLEDGEMENT NUMBER é o número do próximo byte que a origem espera receber HLEN especifica o tamanho do cabeçalho do segmento TCP, medido em DWORD (32 bits)

19 Cabeçalho TCP (cont.) Alguns segmentos transportam apenas um reconhecimento, enquanto outros carregam dados. Há segmentos que levam requisições para estabelecer ou encerrar conexões. TCP usa o campo CODE BITS para determinar o propósito e conteúdo de um segmento

20 Cabeçalho TCP (cont.) Principal função do campo WINDOW é permitir o controle de fluxo: Receptor controla o fluxo descrevendo ao transmissor o tamanho atual do buffer em bytes Também chamado anúncio de janela (window advertisement) Cada segmento, incluindo os segmentos de dados, especificam o tamanho da janela além do byte reconhecido (ou seja, atualizam o tamanho do buffer) Tamanho da janela pode ser zero (buffer cheio)

21 Cabeçalho TCP (cont.) CHECKSUM inclui todo o segmento (cabeçalho e dados) e é obrigatório (diferente do UDP) Como o UDP, TCP também inclui pseudocabeçalho no CHECKSUM

22 Cabeçalho TCP (cont.) URGENT POINTER marca o fim de dados urgentes (depende do bit URG estar ativado) Dados urgentes fazem parte do fluxo TCP normal O receptor (TCP) deveria entregar os dados urgentes à aplicação assim que eles são recebidos, independente de haver outros dados há mais tempo no buffer Para receber os dados urgentes, a aplicação é colocada em modo urgente e somente deve deixar esse modo após ler todos os dados (urgentes)

23 Cabeçalho TCP (cont.) OPTIONS segue o formato TLV (type-length-value) Exemplos (type-length e significado): 0 - End of Option List 1 - No-Operation 2 4 Maximum Segment Size 3 3 WSOPT - Window Scale 4 2 SACK Permitted 5 N SACK 6 6 Echo (obsoleted by option 8) 7 6 Echo Reply (obsoleted by option 8) 8 10 TSOPT - Time Stamp Option *** Lista completa do campo OPTIONS:

24 Exemplos de portas TCP reservadas

25 Reconhecimentos e retransmissões Reconhecimento do TCP informa o número de sequência do próximo byte (octeto) Reconhecimento é acumulativo Vantagens: Fácil de gerar e sem ambiguidade Reconhecimentos perdidos não implicam necessariamente em retransmissões, devido a reconhecimentos posteriores Desvantagem: Especifica apenas uma posição no fluxo de dados Solução: SACK (Selective ACK)

26 Retransmissão adaptativa Durante quanto tempo o transmissor deve esperar pelo reconhecimento de um pacote? Se valor fixo muito pequeno desperdício com restransmissões desnecessárias Se valor fixo muito grande desperdício de banda passante ociosa Além disso: Atrasos em uma conexão variam ao longo do tempo, ou seja, valor fixo não é apropriado Atrasos variam entre conexões, ou seja, valor fixo não é apropriado Solução: retransmissão deve ser adaptativa

27 Retransmissão adaptativa (cont.) TCP mantém uma estimativa do tempo de ida-e-volta (RTT Round-Trip Time) de cada conexão Estimativa é realizada com base no atraso medido entre o envio do segmento e a recepção do respectivo reconhecimento Temporizador para retransmissão se baseia na estimativa do RTT

28 Retransmissão adaptativa Dificuldades (cont.) Segmentos ou reconhecimento podem ser perdidos ou atrasados, tornando imprecisa a estimativa do RTT RTT varia em várias ordens de magnitude entre diferentes conexões Tráfego é em rajadas, logo os valores do RTT de uma conexão variam de forma significativa Abordagem Esquemas de retransmissão adaptativa usam uma estimativa do RTT estatisticamente suavizada A suavização evita que o valor médio do RTT varie muito e evita reações exacerbadas do TCP

29 Cálculo do RTT esquema original RTT = alfa * RTT anterior + (1 - alfa) * RTT amostra Temporizador = beta * RTT Quanto maior o valor de alfa, menos a estimativa de RTT é suscetível a amostras recentes Quanto menor o valor de alfa, mais rapidamente a estimativa de RTT reage a amostras recentes Especificação original recomenda beta = 2

30 Cálculo do RTT problema com o esquema original Como associar reconhecimentos com transmissões: TCP reconhece o recebimento dos dados, não das transmissões (ambiguidade de reconhecimento) Assumir que um reconhecimento corresponde à transmissão mais recente pode causar instabilidade na estimativa do RTT, pois pode haver amostras muito pequenas e grande número de retransmissões Assumir que um reconhecimento corresponde à primeira transmissão pode levar a uma estimativa excessivamente longa Simplesmente não utilizar reconhecimentos ambíguos, é uma solução satisfatória?

31 Cálculo do RTT esquema Partridge/Karn Inicia (como no método original) com o temporizador em função da estimativa do RTT Quando há retransmissão não atualiza estimativa, mas aumenta o temporizador (normalmente, por um fator de 2) temporizador = gama * temporizador anterior Quando chega um reconhecimento de um segmento não retransmitido, volta a recalcular a estimativa do RTT e temporizador volta a ser função da mesma

32 Cálculo do RTT mais mudanças De acordo com teoria de filas: sigma (variação do RTT) muda proporcionalmente a 1/(1 L), onde L é a carga atual na rede e, 0 L 1 Com carga de 50% (L=0,5), RTT varia por um fator de ±2 * sigma, ou 4 Com carga de 80% (L=0,8), RTT varia por um fator de ±2 * sigma, ou 20 O esquema original não é capaz de lidar com alta carga, ou seja, grande variação do RTT Exemplo: se beta = 2, o esquema original consegue estimar o RTT adequadamente com carga até 30%

33 Cálculo do RTT mais mudanças (cont.) Resumindo: O fator de variação do RTT é uma constante beta, fazendo com esse esquema não consiga se adaptar a grandes variações do RTT (por não ser variável) Usando beta = 2 (de acordo com o recomendado), à medida que a variação do RTT aumenta (ou seja, a carga na rede sobe), aumenta o número de retransmissões e, portanto a carga na rede (e a variação do RTT) Portanto, é necessário tornar o fator variável, e foi mostrado que é adequado usar a média e a variância (de fato, o desvio) para descrevê-lo É usado o desvio médio, por ser uma aproximação do desvio padrão que é mais fácil de calcular

34 Cálculo do RTT mais mudanças (cont.) Nova implementação: DIFF = RTT amostra - RTT antigo RTT = RTT antigo + delta * DIFF DEV = DEV antigo + rô * ( DIFF - DEV antigo ) Temporizador = RTT + etá * DEV DEV estima o desvio médio 0 delta 1, ajusta o peso da nova amostra no RTT 0 rô 1, ajusta o peso da nova amostra no DEV etá controla o peso de DEV no Temporizador Valores típicos: delta = 0,125; rô = 0,25; etá = 4

35 Estimativa do RTT

36 Estimativa do temporizador RTO = Retransmission TimeOut

37 Controle de fluxo Evita que o transmissor esgote os buffers do receptor por transmitir muito, ou muito rapidamente Receptor avisa explicitamente ao transmissor da quantidade de espaço livre disponível, a qual pode mudar dinamicamente campo WINDOW do cabeçalho TCP Transmissor mantém a quantidade de dados transmitidos, porém ainda não reconhecidos

38 Controle de congestionamento Congestionamento Rede tem dificuldade (ou se torna incapaz) de transmitir todo o tráfego que recebe Os roteadores tem suas filas (buffers) sobrecarregadas Sintomas de congestionamento: Aumento significativo do atraso dos pacotes (por entrarem em filas mais longas) Perda de pacotes (por transbordo dos buffers) Principal métrica usada atualmente na detecção e controle de congestionamento

39 Controle de congestionamento (cont.) Para (tentar) evitar congestionamento, TCP: Realiza uma sondagem da capacidade efetiva da rede, começando com um segmento Aumenta gradativamente sua taxa de transmissão à medida que chegam novos reconhecimentos (self-clocking) Estabelece como limite superior a janela de transmissão anunciada (WINDOW)

40 Controle de congestionamento (cont.) Quando o congestionamento ocorre, TCP: Diminui abruptamente a taxa de transmissão E volta a aumentá-la gradativamente

41 Controle de congestionamento (cont.) Principais algoritmos de controle de congestionamento do TCP Slow start Congestion Avoidance Fast recovery, Fast retransmit Variáveis importantes: AdvWin maior janela que o transmissor pode usar, descrita pelo receptor no campo WINDOW CongWin janela que o transmissor usa para monitorar o nível de congestionamento TxWin = mínimo (AdvWin, CongWin) Threshold limiar a partir do qual a CongWin deixa de ser tratada pelo algoritmo Slow start e passa a ser definida pelo algoritmo Congestion avoidance

42 Controle de congestionamento Slow start (cont.) 1) inicializa: CongWin = 1 2) para (cada_segmento_com_ack) 3) CongWin++ 4) até (evento_de_perda OU CongWin > Threshold) 5) se (evento_de_perda) volta_ao_passo_1 6) senão congestion avoidance

43 Controle de congestionamento (cont.) Congestion avoidance 1) Até (evento_de_perda) { 2) para_cada_w_segmentos_reconhecidos: 3) CongWin++ } 4) Threshold = CongWin/2 5) Slow Start

44 Controle de congestionamento (cont.) TCP obedece o princípio AIMD (Additive Increase Multiplicative Decrease) Incremento aditivo (enquanto não há perda de pacote): CongWin++ Decremento multiplicativo (ao ocorrer uma perda): CongWin = 1 e Threshold = CongWin/2 No entanto, os dois algoritmos básicos são muito conservadores Fast recovery e Fast retransmit melhoram o desempenho do TCP, mas mantém o AIMD

45 Controle de congestionamento (cont.) Fast retransmit Ao receber um segmento fora de ordem, o TCP envia um reconhecimento para o byte esperado A chegada de um sequência de reconhecimentos duplicados é um indício que não há congestionamento, mas que um segmento foi perdido O algoritmo fast retransmit permite a retransmissão prematura de um segmento perdido antes da expiração do temporizador Quando o transmissor recebe três reconhecimentos duplicados, TCP conclui que o pacote foi perdido e retransmite o mesmo

46 Controle de congestionamento (cont.) Fast Recovery Remove a fase slow start do TCP quando o algoritmo fast retransmit sinaliza um congestionamento Faz CongWin = CongWin/2 E então inicia o congestion avoidance

47 Comparação entre UDP e TCP UDP TCP Datagrama Serviço não-confiável Checksum opcional Sem conexão Mensagens delimitadas Sem controle fluxo Sem controle de congestionamento Suporta unicast, multicast e broadcast Segmento Serviço confiável Checksum obrigatório Orientado a conexão Fluxo (stream) de dados Com controle de fluxo Com controle de congestionamento Suporta apenas unicast