A CAMADA DE TRANSPORTE

(1)

A CAMADA DE TRANSPORTE

Prof.: Mauro Henrique Mulati

UNIVERSIDADE ESTADUAL DE MARINGÁ Centro de Tecnologia

Departamento de Informática

(2)

Roteiro



TCP

A CAMADA DE TRANSPORTE

(3)

Introdução ao TCP



TCP (Transmission Control Protocol)

 Fornece um fluxo de bytes fim a fim confiável em um inter-rede

não confiável

 Orientado a conexão (fornece um circuito virtual entre aplicações

do usuário final)

 TCP deve retransmitir os segmentos sempre que necessário  TCP deve reorganizar as mensagens na seqüência correta



Entidade de transporte TCP

 Procedimento de biblioteca  Processo do usuário

 Parte do núcleo do SO

 Gerencia fluxos e interfaces TCP para a camada IP

 Aceita fluxos de dados do usuário, divide-os em partes e envia

(4)

O modelo de serviço do TCP

Portas, conexões e extremidades



O TCP usa a conexão, e não a porta do protocolo, como sua

abstração fundamental; as conexões são identificadas por

um par de extremidades



Extremidade: (host, porta)

 Host: Endereço IP

 Porta: Porta TCP nesse host

 (128.10.2.3, 25): porta TCP 25 na máquina com endereço IP

128.10.2.3



Conexão: definida por suas duas extremidades

 (128.26.0.36, 1069) e (128.10.2.3, 25)  (128.9.0.32, 1184) e (128.10.2.3, 53)

 (128.2.254.139, 1184) e (128.10.2.3, 53)



N.º de porta TCP pode ser compartilhado por várias conexões

(5)

O modelo de serviço do TCP

Portas, conexões e extremidades



Soquete

 mecanismo que oferece uma extremidade para comunicação  API para programação de aplicações sobre Internet

 Conjunto de primitivas de transporte

 Primitivas de soquetes usadas no UNIX de Berkeley para o TCP

(6)

O modelo de serviço do TCP

Portas, conexões e extremidades



Abaixo de 1024: portas bem conhecidas, serviços padrão



Inetd (Internet daemon)

OS PROTOCOLOS DA INTERNET: TCP

Port Protocol _Use

21 _FTP _{File transfer} 23 _Telnet Remote login 25 SMTP E-mail

69 TFTP Trivial File Transfer Protocol 79 Finger Lookup info about a user

80 _HTTP _{World Wide Web} 110 POP-3 Remote e-mail access 119 NNTP USENET news

(7)

O modelo de serviço do TCP



TCP não admite os processos de multidifusão e difusão



Conexão TCP é um fluxo de bytes e não um fluxo de

mensagens (fronteiras não são preservadas)



No UNIX, os arquivos também têm essa propriedade



Aplicação repassa dados para entidade TCP

 Pode enviá-los imediatamente ou armazená-los em um buffer

 PUSH

 Dados urgentes (Ctrl-C p/ interromper processo remoto)

(a) Quatro segmentos de 512 bytes enviados como datagramas IP separados

(8)

O protocolo TCP



Cada byte em uma conexão TCP tem seu próprio n.º de

seqüência de 32 bits



Segmento TCP:

 Cabeçalho fixo de 20 bytes (além da parte opcional)  Carga útil IP: 65515 bytes

 MTU: Maximum transfer unit (taxa máxima de transferência)

 1500 bytes (carga útil Ethernet)



TCP usa protocolo de janela deslizante

 Envia segmento, dispara um timer

 Chega ao destino, entidade TCP receptora retorna um segmento

(com ou sem dados) com um n.º de confirmação igual ao próximo n.º de seqüência que espera receber

 Se o timer expirar antes, o segmento será restransmitido

(9)

O protocolo TCP



Segmentos podem chegar fora de ordem

 3072 a 4095 podem chegar, mas não serão confirmados porque

os bytes 2048 a 3071 ainda não chegaram

(10)

O cabeçalho do segmento TCP

(11)

O cabeçalho do segmento TCP



Source port e destination port (16 bits cada)



Sequence number (32 bits)



Acknowledgement number (32 bits): próximo byte esperado e

não o último byte recebido corretamente



TCP header length (4 bits): Quantas palavras de 32 bits

existem no cabeçalho



URG: Campo de ponteiro de urgente é valido



ACK: Campo de confirmação é válido



PSH: Este segmento requer um PSH



RST: Reinicia a conexão



SYN: Sincroniza n.º

s

de seqüência



FIN: Emissor alcançou final do seu fluxo de bytes

(12)

O cabeçalho do segmento TCP



Window size (16 bits): indica quantos bytes podem ser

enviados a partir do byte confirmado



No TCP, as confirmações e a permissão para enviar dados

adicionais são isoladas



“Recebi os bytes até k, mas não quero mais agora.”



Esse desacoplamento (na verdade, uma janela de tamanho

variável) proporciona flexibilidade adicional

(13)

O cabeçalho do segmento TCP



Checksum: para aumentar confiabilidade

 Total de verificação do cabeçalho, dos dados e do

pseudocabeçalho



O pseudocabeçalho incluído no total de verificação do TCP 

Ajuda a detectar pacotes extraviados



Viola a hierarquia do protocolo



UDP também utiliza

(14)

O cabeçalho do segmento TCP



Options: Recursos extras



Opção que permite a cada host estipular o máximo de carga

útil do TCP que está disposto a receber



Durante a configuração da conexão

 Pode anunciar sua capacidade máxima e avaliar a capacidade

de seu parceiro

 Padrão: 536 bytes

 Nos dois sentidos não precisa ser o mesmo



Window scale: fator de escala para a janela

 Permite deslocar o campo window size até 14 bits para a

esquerda, janelas de até 230_bytes



Retransmissão seletiva em vez do go back n

 NACK para permitir que o receptor solicite segmento(s) espe.(s)

(15)

O estabelecimento de conexões TCP

 CONNECT: endereço IP, porta, tamanho máximo, e opcionalmente alguns dados do usuário. SYN ativado e ACK desativado (...)

(a) Estabelecimento de uma conexão TCP em condições normais. (b) Colisão entre chamadas

 N.º de seq. inicial é baseado no uso do clock

 Quando um host sofrer uma pane, ele não poderá reinicializar por um período equivalente a duração máxima de pacotes

(16)

Encerramento de conexões TCP



São full-duplex



Vamos considerar como sendo um par de conexões simplex

 Cada conexão simplex é encerrada de modo independente de

sua parceira

 Bit FIN ativado: não há mais dados a serem transmitidos  FIN é confirmado, esse sentido é destivado

 Dados podem fluir indefinidamente no outro sentido  Dois sentidos desativados, conexão encerrada

 Quatro segmentos: um FIN e um ACK em cada sentido

 Primeiro ACK e segundo FIN podem ocupar o mesmo segmento

 Evitar problemas dos dois exércitos: timers

 Se uma resposta FIN não chegar em 2T, transmissor encerra OS PROTOCOLOS DA INTERNET: TCP

(17)

Modelagem do gerenciamento de conexões do TCP

Os estados usados na máquina de estados finitos para o gerenciamento de uma conexão TCP

- Em cada estado, determinados eventos são válidos

- Quando ocorre um evento válido, é possível executar uma ação - Outro evento, será reportado um erro

(18)

Modelagem do gerenciamento de conexões do TCP

Máquinas de estados finitos usada no

gerenciamento de uma conexão TCP.

A linha contínua mais escura representa o

caminho normal de um cliente. A linha

tracejada mais escura representa o caminho

normal de um servidor.

As linhas mais finas representam eventos incomuns.

Cada transição é identificada pelo

evento que a provoca

e pela ação resultante dela, separados por uma barra

(19)

Política de transmissão do TCP

 Gerenciamento de janelas no TCP não está diretamente relacionado às confirmações  Transmissores não são obrigados a enviar os dados assim que os receberem da aplicação. Nem os receptores tem a obrigação de enviar as confirmações imediatamente Gerenciamento de janelas no TCP OS PROTOCOLOS DA INTERNET: TCP OS PROTOCOLOS DA INTERNET: TCP

(20)

Política de transmissão do TCP



Exceções

 Dados urgentes: por ex., para eliminar o processo na máquina

remota

 Transmissor pode enviar um segmento de 1 byte para fazer com

que o receptor anuncie novamente o próximo byte esperado e o tamanho da janela

 Para evitar impasse



Exemplo Telnet, ssh



Abordagem: retardar as confirmações e atualizações de janela

durante 500 ms



Algoritmo de Nagle

 Quando os dados chegarem ao transmissor um byte por vez,

basta enviar o primeiro byte e armazenar no buffer todos os outros até que o byte pendente tenha sido confirmado, depois

(21)

Política de transmissão do TCP

Síndrome da janela boba

 Dados são repassados p/ a entidade TCP

transmissora em grandes blocos, mas uma aplicação

interativa no lado receptor lê os dados um byte por vez

 Forçar aguardar até que haja espaço

considerável na janela para então anunciar o fato

 Tamanho máximo

anunciado ou

 Metade de sua

capacidade livre (o que for menor)

 Emissor pode ajudar não enviando

(22)

Controle de congestionamento do TCP



Quando a carga oferecida a qualquer rede é maior que sua

capacidade, acontece um congestionamento

 A Internet não é exceção a essa regra



O controle é feito pelo TCP (trabalho mais pesado)

 Verdadeira solução é diminuir a taxa de transmissão de dados



Idéia é não injetar um novo pacote na rede até que um pacote

antigo saia da rede



O TCP tenta alcançar esse objetivo manipulando

dinamicamente o tamanho da janela



Primeiro passo: Detectar congestionamento.

timeout pode ser causado por:

 Ruído

 Pacote descartado em um roteador por congestionamento

(23)

Controle de congestionamento do TCP



A maioria dos timeouts de transmissão se deve a

congestionamentos



Estabelecimento: Tamanho de janela adequado



Para evitar congestionamento:

 Receptor pode especificar uma janela a partir do tamanho de

seu buffer

 Se transmissor se mantiver dentro do tamanho da janela, não

haverá problemas causados pela sobrecarga dos buffers na

extremidade receptora, mas eles ainda poderão ocorrer devido a congestionamentos internos na rede

(24)

Controle de congestionamento do TCP

(a) Uma rede rápida alimentando um receptor de pequena capacidade. (b) Uma rede lenta alimentando um receptor de grande capacidade

(25)

Controle de congestionamento do TCP



Problemas em potencial:

 Capacidade da rede

 Capacidade do receptor



Lidar com cada um em separado

 Cada transmissor mantém duas janelas

 Janela fornecida pelo receptor  Janela de congestionamento

 O n.º de bytes que pode ser transmitido é o valor mínimo entre

as duas janelas

(26)

Controle de congestionamento do TCP



Ex.:

 Se o receptor pedir:

 Envie 8 KB

 Mas o transmissor souber que qualquer rajada com mais de

4 KB irá congestionar a rede, ele enviará apenas 4 KB

 Se o receptor pedir:

 Envie 8 KB

 Transmissor souber que rajadas de até 32 KB passam pela rede

sem problemas

 Enviará os 8 KB solicitados OS PROTOCOLOS DA INTERNET: TCP

(27)

Controle de congestionamento do TCP

_ _{Conexão estabelecida:}

 Transmissor ajusta a janela de congestionamento ao tamanho

do segmento máximo em uso na conexão

 Envia um segmento máximo  Se confirmado antes do timeout

 Transmissor dobra o tamanho do segmento

 A medida que cada um desses segmentos for confirmado, a

janela de congestionamento será aumentada em um tamanho de segmento máximo da janela de congestionamento (dobrada)

 Janela de congestionamento mantém crescimento exponencial

até que ocorra um timeout (ou que a janela do receptor seja

alcançada)

 Se janelas de 1024, 2048 e 4096 bytes funcinarem bem, mas

uma rajada de 8192 bytes causar um timeout

 Janela de congestionamento deverá ser mantida em 4096 bytes  Não importando quanto espaço de janela o receptor ofereça

(28)

Controle de congestionamento do TCP



Na Internet:

 Terceiro parâmetro: limiar (inicialmente 64 KB)

 Além das janelas:  Do receptor

 De congestionamento  Quando há timeout:

 O limiar é definido como a metade da janela de congestionamento atual

 E a janela de congestionamento é redefinida como um segmento máximo

 Em seguida, a inicialização lenta é usada para determinar o que

a rede é capaz de gerenciar, exceto pelo fato de o

crescimento exponencial ser interrompido quando o limiar é alcançado

 A partir daí, as transmissões bem-sucedidas proporcionam um OS PROTOCOLOS DA INTERNET: TCP

(29)

Controle de congestionamento do TCP

Um exemplo de algoritmo de congestionamento da Internet

Tamanho máximo do segmento: 1024 bytes ou 1 KB Em principio, a janela de congestionamento tinha 64 KB, mas houve timeout limiar foi definido com 32 KB e janela de congestionamento 1 KB p/ transmissão 0 Exponencialmente até chegar a 32 KB a partir daí, crescimento linear

T aman ho d a jan ela d e con ge sti ona men to (kilo by te s)

(30)

Controle de congestionamento do TCP



Se não ocorrerem outros timeouts

 A janela de congestionamento continuará a crescer até atingir o

tamanho da janela do receptor

 Nesse ponto ele pára de crescer e permanece constante desde

que:

 Não ocorra outro timeout

 A janela do receptor não mude de tamanho

 Se chegar um pacote SOURCE QUENCH do ICMP e for repassado ao TCP, esse evento será tratado como se tivesse ocorrido um

timeout (existe abordagem mais recente: RFC 3168) OS PROTOCOLOS DA INTERNET: TCP

(31)

Gerenciamento de timers do TCP



TCP utiliza vários timers

 Timer de retransmissão

 Quando um segmento é enviado, um timer de retransmissão é ativado

 Se o segmento for confirmado antes de o timer expirar, ele será interrompido

 Se o timer expirar antes de a confirmação chegar, o segmento será retransmitido (e o timer será disparado novamente)



Qual deve ser o intervalo de timeout?

 Camada de enlace: retardo esperado é bastante previsível

(pequena variância) -> timer pode ser programada para expirar logo após o momento em que a confirmação é esperada

 Camada de transporte: ambiente radicalmente distinto

(32)

Gerenciamento de timers do TCP

(a) Densidade de probabilidades de tempos de chegada de confirmações na camada de enlace de dados

(b) Densidade de probabilidades de tempos de chegada de confirmações para o TCP

(33)

Gerenciamento de timers do TCP



Determinar tempo de ida e volta para o destino não é uma

tarefa fácil



Mesmo quando o tempo é conhecido, também é difícil decidir

sobre o intervalo de timeout



Se o timeout for curto demais, T1, ocorrerão retransmissões

desnecessárias, sobrecarregando a Internet com pacotes

inúteis



Por outro lado, se for longo demais, T2, o desempenho será

prejudicado devido ao longo retardo de retransmissão

sempre que um pacote se perder



Média e variância na distribuição da chegada das

confirmações podem mudar com muita rapidez em um

intervalo de poucos segundos, devido à ocorrência ou à

resolução de um congestionamento

(34)

Gerenciamento de timers do TCP



Solução: utilizar algoritmo altamente dinâmico que ajuste

constantemente os intervalos de timeout

 Com base na contínua avaliação do desempenho da rede



No TCP (criado por Jacobson (1988) )

 Para cada conexão, RTT

 Melhor estimativa no momento para o tempo de percurso de ida e volta até o destino em questão

 Segmento enviado, timer disparado

 Não só para verificar quanto tempo a confirmação leva para chegar

 Também para acionar uma retransmissão, caso a confirmação demore demais para chegar

 Se confirmação votar antes de o timer expirar, TCP medirá o tempo necessário, que será M

(35)

Gerenciamento de timers do TCP



Em seguida, TCP atualiza RTT:

RTT =⋅RTT 1− M

=

7

8 =

0,875

RTT =0,875⋅RTT 0,125 M

OS PROTOCOLOS DA INTERNET: TCP OS PROTOCOLOS DA INTERNET: TCP

(36)

Gerenciamento de timers do TCP



Mesmo que RTT seja adequado, não é trivial escolher timeout

para retransmissão



Em geral, TCP utiliza:



Valor para



Implementações iniciais:

 Experiência mostrou que um valor constante era inflexível, não

atendia casos com variância maior

 Em 1988 Jacobson propôs: tornar aproximadamente

proporcional ao desvio-padrão da função de densidade de probabilidades de tempos de chegada de confirmações

 Grande variância, alto valor de  Pequena variância, baixo valor de

⋅

RTT



=

2 



OS PROTOCOLOS DA INTERNET: TCP OS PROTOCOLOS DA INTERNET: TCP

(37)

Gerenciamento de timers do TCP



Foi sugerido o desvio-médio, uma forma econômica do desvio

padrão



Algoritmo de Jacobson exige o controle de outra variável de

suavização, D, o desvio

 Sempre que uma confirmação chega, é calculada a diferença

entre os valores esperados e os valores observados |RTT-M|

 Valor suavizado dessa expressão é mantido em D pela fórmula:

 Onde pode ou não ter o mesmo valor para usado para

suavizar RTT

 Mesmo que D não seja exatamente igual ao desvio-padrão, ela

atende às necessidade da rede

 Pode ser realizada usando-se apenas somas, subtrações e

D=⋅D1−

∣

_{RTT −M}

∣



(38)

Gerenciamento de timers do TCP



Por fim, intervalo de timeout:



Fator 4: escolha é arbitrária

 Multiplicação realizada com um único deslocamento

 Minimiza o n.º de timeouts e retransmissões desnecessárias

 Menos de 1% de todos os pacotes chegam com um atraso de mais de 4 vezes o desvio padrão

 Problema: quando um segmento é retransmitido e a confirmação

chega: se refere à primeira ou a uma transmissão posterior?

 Não atualizar RTT em qualquer segmento que tenha sido retransmitido

 Em vez disso, intervalo de timeout seria duplicado a cada falha, até os segmentos chegarem ao destino da primeira vez

Timeout=RTT 4×D

(39)

Gerenciamento de timers do TCP



Timer de retransmissão não é o único que o TCP utiliza

 Timer de persistência, para evitar impasse a seguir

 Receptor envia confirmação com um tamanho de janela 0

 Mais tarde, receptor atualiza a janela, mas pacote com atualização se perde

 Agora, tanto o transmissor quanto o receptor estão esperando que o outro faça algo

 Quando o timer de persistência expirar, o transmissor enviará um teste ao receptor

 A resposta ao teste fornece o tamanho da janela

 Se ela ainda for zero, o timer de persistência será ativado novamente

 Se for diferente de zero, os dados poderão ser transmitidos

(40)

Gerenciamento de timers do TCP

 Timer keepalive (mater vivo)

 Quando conexão permanece inativa por muito tempo

 O timer keepalive pode expirar, fazendo um lado verificar se o outro

lado ainda está ativo

 Se o outro lado não responder, a conexão será encerrada  Recurso polêmico:

 Além de aumentar o overhead

 Pode encerrar uma boa conexão devido a uma partição transitória da

rede

 Timer empregado no estado TIMED WAIT durante o

encerramento

 É executado por um tempo igual a 2 vezes a duração máxima dos pacotes

 Para garantir que, quando uma conexão for fechada, todos os pacote criados por ela também serão extintos

(41)

UDP: User Datagram Protocol



UDP: Transmite dados entre hosts sem confiabilidade

 Transmite segmentos (chamadas de datagramas do usuário)  Sem conexão

 Não confiável

 Não realiza controle de erros nem retransmite após a recepção

de um segmento incorreto

 Não usa confirmações (não é confiável)  Não realiza controle de fluxo

 Não realiza controle de congestionamento  Não reagrupa os segmentos de entrada



Cabe ao processo do usuário

(42)

Introdução ao UDP



Principal motivo de se ter o UDP em relação ao uso do IP

bruto é a adição das portas de origem e destino



Sem os campos de portas, a camada de transporte não

saberia o que fazer com o pacote



Quando um pacote UDP chega, sua carga útil é entregue ao

processo associado à porta de destino

 Associação ocorre quando a primitiva BIND ou algo semelhante

é usado



Fornece uma interface para o protocolo IP com o recurso

adicional de demultiplexação de vários processos que utilizam

OS PROTOCOLOS DA INTERNET: UDP

(43)

Introdução ao UDP



UDP é especialmente útil:

 Aplicações cliente/servidor

 DNS (Domain Name System)



Não é necessário nenhuma configuração antecipada e

também nenhum encerramento posterior



Basta enviar duas mensagens pela rede

(44)

Remote Procedure Call

Etapas na criação de uma chamada de procedimento remoto. Os stubs estão sombreados

(45)

Remote Procedure Call



Idéia: tornar uma chamada de procedimento remoto o mais

semelhante possível a uma chamada local



Stub do cliente



Stub do servidor



Esses procedimento ocultam o fato de que a chamada de

procedimento do cliente até o servidor não é local



Reunião dos parâmetros é chamada de empacotamento

(marshaling)

(46)

Remote Procedure Call



Problemas

 Passagem de parâmetros por ponteiros  Linguagem com tipificação fraca, como C

 Ex.: Procedimento que calcula o produto interno de dois vetores sem especificar o tamanho de cada vetor. Poderia terminar com um valor especial

 Não tem como determinar o tamanho do vetor a ser passado

 Nem sempre é possível deduzir os tipos dos parâmetros  Não é possível usar variáveis globais



E ainda...

 RPC não precisa usar pacotes UDP, mas RPC e UDP se

adaptam muito bem

 Mas pode ser necessário instalar uma conexão TCP (T/TCP)

 Parâmetros ou resultados maiores que o pacote UDP máximo OS PROTOCOLOS DA INTERNET: UDP

(47)

O RTP (Real-time Transport Protocol)



Aplicações multimídia em tempo real

(a) A posição do RTP na pilha de protocolos (b) O aninhamento de pacotes

(48)

O RTP (Real-time Transport Protocol)

O cabeçalho do RTP