Redes de Computadores de comunicação Serviços oferecido pelo IP roteamento através de uma interconexão de redes fragmentação / remontagem serviço não conectado e de ... Desafios

Redes de Computadores

Camada de Transporte

Camada de Transporte:Objetivos

● Aspectos conceituais ● Papel da camada de transporte● Protocolo UDP● Protocolo TCP

● Modelos● TCP (fluido?)

Problema

● diferentes tecnologias possíveis para conectar um conjunto de máquinas● LAN, WAN, inter-redes, ...

● serviço de entrega de mensagens máquina a máquina

● como passar este serviço a um canal de comunicação processo a processo?

AplicaçãoAplicação

? ? ?? ? ?

rederede(internet)(internet)

acesso a redeacesso a rede(host-to-network)(host-to-network)

Fonte: Kurose e Ross, Computer Networking: A Top-Down Approach

Protocolos de transporteFornecem comunicação lógica entre processos de aplicação em diferentes hospedeiros

Os protocolos de transporte são executadosnos sistemas finais

Lado emissor: quebra as mensagens da aplicação em segmentos e envia para a camada de rede

Lado receptor: remonta os segmentos em mensagens e passa para a camada de aplicação

Sistema de comunicação

Serviços oferecido pelo IP

roteamento através de uma interconexão de redes

fragmentação / remontagem

serviço não conectado e de “melhor esforço” (best effort)

Desafios• levar em conta o

serviço fornecido pela camada de rede• perda de pacotes• desordenamento• duplicações• erros• MTU• atrasos fim-a-fim

imprevisíveis• ...

• levar em conta a necessidade das aplicações

• garantia de entrega das mensagens

• ordenamento• ausência de duplicações• ausência de mensagens erradas• mensagens de qualquer tamanho• sincronização entre emissor e

receptor• controle de fluxo do receptor

sobre emissor• suporte a diversas aplicações no

mesmo hospedeiro• ...

Papel da camada de transporte

• Transformar as propriedades nem sempre desejáveis da rede em um serviço de alto nível desejável pelas aplicações

• Há mais de um protocolo de transporte disponível para as aplicações

• Internet: TCP e UDP

Multiplexação / demultiplexação

• Problema:

• como identificar um processo (aplicação)?

• número de porta associado ao socket ligando a camada de aplicaçãoe camada de transporte(ver camada de aplicação)

Multiplexação no emissor

coleta dados de múltiplos sockets, envelopa os dados com cabeçalho (usado depois para demultiplexação)

Demultiplexação no receptor

entrega os segmentos recebidos ao socket correto

Fonte: Kurose e Ross, Computer Networking: A Top-Down Approach

Protocolos da Camada de Transporte

• User Datagram Protocol

• Transport Control Protocol

UDP

• Protocolo de transporte da Internet com baixo overhead

• Se contenta de estender

• um serviço de entrega máquina a máquina

• em um serviço de entrega processo a processo

Serviço UDP

• Serviço best effort

• como na camada de rede

• Segmentos UDP podem ser:

• perdidos

• entregues fora de ordem para a aplicação

Serviço UDP• Serviço sem conexão

• Não há apresentação entre o UDP transmissor e o receptor

• Cada segmento UDP é tratado de forma independente

• Por que existe UDP ?

• Sem estabelecimento de conexão (que possa causar em atrasos)

• Não há estado de conexão nem no transmissor, nem no receptor

• Cabeçalho de segmento reduzido

• Não há controle de congestionamento: UDP pode enviar segmentos tão rápido quanto desejado (e possível)

Datagrama UDP

• Funcionalidades além da (de)multiplexação?

• detecção de erros

Protocolos da Camada de Transporte

• User Datagram Protocol

• Transport Control Protocol

TCPOferece um serviço de entrega

• em modo conectado

• confiável

• full-duplex

• de fluxo de bytes (bytestream)

Implementa mecanismos de

•(de)multiplexação

•gerenciamento de conexões

•controle de erro

•controle de fluxo

•controle de congestionamento

Comparação com enlace de dados (0/5)

Nos próximos slides para cada um de 5 aspectos considerados...

característica para enlace de dados ponto-a-ponto real

situação encontrada pelo TCP na prática

problema imposto ao TCP

Comparação com enlace de dados (1/5)

1.Gerenciamento de conexões

um enlace ponto a ponto é construído sobre um canal físico conectando sempre os 2 mesmos sistemas finais

TCP suporta conexões entre 2 processos executando em quaisquer hospedeiros da Internet

estabelecimento de conexão mais complexo

Comparação com enlace de dados (2/5)

2.RTT (Round Trip Time)

praticamente constante sobre um enlace

varia em função do momento da conexão e da “distância” separando os 2 hospedeiros

dimensionamento do temporisador de retransmissão

Comparação com enlace de dados (3/5)

3.Unidades de dados

não se duplicam no meio de transmissão

podem ser duplicadas e ser retardadas de maneira imprevisível na rede

TCP deve lidar com atrasos imprevisíveis e duplicações

Comparação com enlace de dados (4/5)

4.buffers de recepçãosão próprios a cada enlace

recursos são compartilhados entre todas as conexões abertas

TCP deve adotar controle de fluxo

Comparação com enlace de dados (5/5)

5.Congestionamentode enlace de dados não pode ocorrer sem que o emissor perceba

de rede pode ocorrer sem queo emissor perceba

TCP deve adotar controle de congestionamento com base em indícios indiretos de congestionamento

Fluxo de Bytes

• TCP é orientado a bytes

• processo emissor “escreve” bytes sobre a conexão TCP

• processo receptor “lê” bytes da conexão TCP

Fluxo de Bytes• TCP não transmite bytes individualmente

• em emissão

• TCP armazena os bytes até ter um número razoável para transmitir

• TCP cria um segmento e o envia

• em recepção

• TCP armazena o conteúdo do segmento recebido em um buffer de recepção

• o processo destinatário lê os bytes a seu critério

Fluxo de Bytes

O segmento TCP

Gerenciamento de conexão

• Emissor e receptor TCP estabelecem uma conexão antes de trocar segmentos

• A conexão inicia variáveis TCP:

• números de seqüência

• buffers

• informação de controle de fluxo (ex. janela de recepção)

Three-way handshake

Participante ativo

(cliente)

Participante passivo

(servidor)

Transferência de dados

•TCP assegura uma transferência de dados fim-a-fim confiável

•controle de fluxo

•controle de erro

Controle de fluxo• Receptor TCP dispõe de recursos (buffers) em

quantidade limitada

• O tamanho da janela (de recepção) anunciada reflete a disponibilidade do buffer de recepção

• Receptor TCP gerencia um número de conexões variável

Janela dinâmica campo window indica o número de bytes de dados que o receptor está apto a receber

indica o número de bytes de dados que o receptor está apto a receber

Buffer de emissão

• Em emissão, um buffer armazena

• os dados enviados e a espera de confirmação (ACK)

• os dados passados pelo processo emissor, mas não ainda enviados

Buffer de recepção

• Em recepção, um buffer armazenaos dados (ordenados) que ainda não foram lidos pelo processo receptoros dados fora de seqüência

• os dados (ordenados) que ainda não foram lidos pelo processo receptoros dados fora de seqüência

Controle de erro• Controle de erro baseado

• no campo Checksum

• no campo SequenceNumber

• confirmações (ACKs) positivas(dumb receiver: sem confirmações negativas)

• um temporizador de retransmissão

• retransmissões

• RTT variável (e imprevisível)

• dimensionamento dinâmico do temporizador de retransmissão

Dimensionamento dinâmico do temporizador

transmissão

retransmissão

transmissão

retransmissão

X

subestimativa do RTT superestimativa do RTT

pacotes duplicados

ACK

Ineficiencia na retransmissao

Dimensionamento dinâmico do temporizador

• TCP calcula uma estimativa do RTT por uma média ponderada entre a estimativa previamente calculada e a última amostra medida do RTT

EstimatedRTT ⬅ α EstimatedRTT + (1 – α) SampleRTT

• SampleRTT é obtido medindo o atraso separando a emissão de um segmento e a recepção de sua confirmação

• 0,8 < α < 0,9

• TCP calcula o valor do temporizador

• TimeOut min(UBOUND, max(LBOUND, β EstimatedRTT))⬅

• UBOUND é um limite superior sobre o temporizador (ex. 60 s)

LBOUND é um limite inferior sobre o temporizador (ex. 1 s)

• 1,3 ≤ β ≤ 2

Algoritmo de Karn-Patridge

• Somente mede SampleRTT para os segmentos enviados uma única vez

• Cálculo do TimeOut

• a cada retransmissão, dobra o valor de TimeOut até que a retransmissão seja bem sucedida

• para os segmentos seguintes, conserva o valor de TimeOut até que um segmento seja confirmado na 1a. transmissão

• recalcula TimeOut a partir do EstimatedRTT

Exemplo de estimativa do RTT

Princípios de controle de congestionamento

Congestionamento

•Informalmente: “fontes demais enviando dados demais rápido demais para a rede tratar”

•Diferente de controle de fluxo!

•Sintomas

• perdas de pacotes (saturação de buffers nos roteadores)

• atrasos grandes (filas nos roteadores)

Causas/custos do congestionamento

• Dois transmissores,dois receptores

• Um roteador, buffers infinitos

• Não há retransmissão

• Grandes atrasos quando congestionado

• Máxima vazão alcançável

Causas/custos do congestionamento

• Um roteador, buffers finitos

• Transmissor reenvia pacotes perdidos

Causas/custos do congestionamento

• “Custos”do congestionamento

• mais trabalho (retransmissões) para um mesmo goodput efetivo

• retransmissões desnecessárias: cópias inúteis do mesmo pacote nos enlaces

causando mais congestionamento!

Controle de congestionamento

• TCP adapta sua taxa de transmissão usando uma janela CongestionWindow controlada pelo emissor baseado no estado atual de congestionamento

MaxWindow MIN(CongestionWindow, AdvertisedWindow)⬅

EffectiveWindow MaxWindow – (LastByteSend – LastByteAcked)⬅

MaxWindow substitui AdvertisedWindow no cálculo de EffectiveWindow

para convívio harmonioso de controle de fluxo e de congestionamento

Controle de congestionamento

• Controle fim-a-fim(sem informações diretas da rede)

• Aproximadamente,

• CongestionWindow é dinâmica em função do nível de congestionamento detectado

Controle de congestionamento

• Como o emissor percebe congestionamento?

• evento de perda de segmento

• temporizador expirado (timeout) ou 3 ACKs duplicados

• indicação implícita de congestionamento

• Emissor TCP reduz taxa (CongestionWindow) após evento de perda

TCP AIMD

Mutiplicative decreasecorta CongestionWindow pela metade após perda

Additive increaseincrementa CongestionWindow em 1 MSS a cada RTT na ausência de perdas: sondagem da taxa ideal

- Self-clocking (ajuste via recebimento de ACKs ligado ao RTT)

- aumento linear da janelacongestion avoidance

Conexão TCP de longa duração

TCP Slow Start

• Quando a conexão inicia: CongestionWindow = 1 MSS

• Exemplo: MSS = 500 bytes e RTT = 200 ms

• Taxa inicial = 20 kbps

• Capacidade disponível pode ser >> MSS/RTT

• Desejável aumentar taxa rapidamente atéuma taxa respeitável

• Quando a conexão começa, a taxa aumenta rapidamente de modo exponencial até a ocorrência do primeiro evento de perda

TCP Slow Start

• Slow start: taxa inicial é lenta, mas aumenta de modo exponencialmente rápido (até primeira perda)

• dobra CongestionWindowa cada RTT

• faz-se isso aumentandoCongestionWindowpara cada ACK recebido

Reação a perdas

• Após 3 ACKs duplicados

• rede capaz de entregar alguns segmentos

• Após timeout do temporizador

• timeout antes de 3 ACKs duplicados: mais “alarmante”

Qual indício de perda?

Reação a perdasQual indício de perda?

• Após 3 ACKs duplicados

• corta CongestionWindow pela metade

• CongestionWindow cresce linearmente

• Após timeout do temporizador

• CongestionWindow ajustado para 1 MSS

• CongestionWindow cresce exponencialmente até um limiar (Threshold), então cresce linearmente