Curso de Redes de Computadores - angel.acmesecurity.orgadriano/aulas/redes/2017/Redes1/... · •...

unesp - IBILCE - SJRP

Curso de Redes de Computadores

Adriano Mauro Cansian

adriano@acmesecurity.org

Capítulo 3 Camada de Transporte

Capítulo 3: Camada de Transporte Metas do capítulo: q  Compreender os princípios dos

serviços da camada de transporte:. •  Transferência confiável de

dados.

•  Controle de fluxo.

•  Controle de congestionamento.

q  Implementação na Internet.

O que veremos: q  Serviços da camada de transporte.

q  Multiplexação / desmultiplexação.

q  Transporte sem conexão: UDP.

q  Princípios de transferência confiável. •  Qual a ideia e como surgiu

q  Transporte orientado a conexão: TCP

•  Transferência confiável

•  Controle de fluxo

•  Gerenciamento de conexões

q  Princípios de controle de congestionamento.

q  Controle de congestionamento em TCP.

Cuidado com conceitos !

Muito material errado ou ruim na Internet! (apesar de outros muito bons)

Comparação entre as camadas

Camada Transporte à ligada a processos Comunicação lógica entre processos.

Camada de rede à ligada a hosts Comunicação lógica entre hosts.

Esta distinção é sutil, mas MUITO importante.

Correio

Rua dos Bichos, No. 32, 6905-140 Manaus, AM

Rua dos Santos, No. 400, 01419-901, S.Paulo, SP

Comparação entre camadas – exemplo: MANAUS

S.Paulo

Camada de Transporte X Camada de Rede (1) q  Exemplo:

•  6 irmãos moram numa casa em São Paulo, SP. •  e 5 irmãos em outra casa em Manaus, AM. •  Os de S. Paulo são primos daqueles em Boa Vista. •  Escrevem cartas entre SP e AM regularmente.

___________________________________________________ Os irmãos de cada lado:

q  Em São Paulo: •  João recolhe as cartas, e as entrega ao correio.

q  Em Manaus: •  Maria recolhe as cartas, e as entrega ao correio.

E os dois Também recebem e fazem a distribuição local das cartas que

chegam para os irmãos.

Correio

Rua dos Bichos, No. 32, 6905-140 Manaus, AM

Rua dos Santos, No. 400, 01419-901, S.Paulo, SP

MANAUS

S.Paulo

Camada de Transporte X Camada de Rede (2)

q  Hosts (devices / end systems) = Casas.

q  Processos = pessoas que trocam mensagens.

q  Mensagens da aplicação = cartas em envelopes.

q  Protocolo da camada de rede: •  Serviço postal (correio).

q  Protocolo da Camada de Transporte:

•  João (de um lado) e Maria (do outro).

Serviços e protocolos de TRANSPORTE (1)

q Do ponto de vista da APLICAÇÃO a camada de transporte permite enxergar os sistemas como se eles estivessem fisicamente conectados.

•  Comunicação lógica entre processos de aplicação executando em hosts diferentes.

Serviços e protocolos de TRANSPORTE (2)

Dois Serviços de transporte:

1.  Entrega confiável, ordenada, ponto a ponto: TCP.

•  Conexão (setup).

•  Controle Congestionamento.

•  Controle de fluxo.

2.  Entrega não confiável, (“melhor esforço”), não ordenada, ponto a ponto ou multiponto: UDP.

aplicação transporte

rede enlace física

enlace física

rede enlace física

enlace física

Multiplexação/desmultiplexação q  MULTIPLEXAÇÃO: Juntar dados de múltiplos

processos de aplicações, envelopando dados com cabeçalho.

q  DEMULTIPLEXAÇÃO: entrega de segmentos recebidos para os processos da camada de aplicação corretos.

M P2 aplicação

transporte rede

receptor

HtHn segmento

segmento M aplicação

transporte rede

M M P3 P4

cabeçalho de segmento

dados da camada de aplicação

Fluxo de encapsumaneto

Fluxo de desencapsulamento

Encapsulamento / desencapsulamento

14 http://www.gripinit.com/wp-content/uploads/2015/03/UDP-Encapsulation1.gif

Portas são fundamentais Multiplex / demultiplex:

q  Baseadas em números de porta e endereços IP de remetente e receptor:

•  Números de porta de remetente/receptor são enviados em cada segmento.

•  Número de porta são conhecidas para aplicações específicas (WKS): E-mail na porta 25, telnet na porta 23, http na porta 80, e assim por diante.

porta emissor porta receptor 32 bits

dados da aplicação

(mensagem)

outros campos do cabeçalho

formato genérico de segmento TCP/UDP

Os protocolos de Transporte

UDP User Datagram Protocol

UDP: User Datagram Protocol [RFC 768]

q Protocolo de transporte muito simples. q Best Effort: Serviço “melhor esforço”.

•  Faz com que segmentos UDP possam ser: •  Perdidos.

•  Entregues fora de ordem à aplicação.

q Sem conexão: •  Não há “setup” entre remetente e receptor.

•  Não há manutenção “status” (é stateless). •  Tratamento independente de cada segmento.

q Sem controle de congestionamento ou de fluxo.

UDP: User Datagram Protocol [RFC 768]

Por quê existe um UDP?

q  Elimina estabelecimento de conexão: •  Reduz delay de “partida lenta”.

q  Simples: não mantém “estado”: •  Stateless.

q  Pequeno cabeçalho de segmento: •  Mais simples = menos desperdício de dados (overhead)

q  Sem controle de congestionamento nem de fluxo: •  UDP pode transmitir o mais rápido possível que puder.

Mais sobre UDP

q  Muito utilizado para aplicações de mídia (voz, vídeo). •  São tolerantes a perdas. •  São sensíveis à taxa de

transmissão.

q  Outros usos de UDP : •  DNS (servidor de nomes). •  SNMP (gerenciamento).

q  Transferência confiável com UDP: só pode incluir confiabilidade na camada de aplicação. •  Recuperação de erro fica por

conta da aplicação!

porta origem porta dest.

32 bits

Dados de aplicação

(mensagem)

Formato de um sgmento UDP

comprimento checksum

Comprimento em bytes do

segmento UDP, incluindo

cabeçalho

Cálculo do Checksun

(válido para o UDP e o TCP)

Checksum UDP - EMISSOR Finalidade: detectar falha no segmento transmitido.

Emissor: q  Trata o segmento como sequência de inteiros de 16-bits. q  Checksum: é a soma (adição usando complemento de 1) do

conteúdo do total do segmento.

q  Considera o campo checksum como zeros (para fazer o cálculo). q  Inclui os dados carregados.

•  (checksum do IP NÃO cobre dados – visto mais adiante). •  Inclui um pseudoheader no cálculo (visto adiante).

q  Então o EMISSOR coloca complemento de um do valor da soma no campo checksum de UDP .

q  E então envia o segmento.

Pseudo Header (1) q UDP (*) usa um pseudo header no cálculo do

checksum. •  Usa informações da camada IP (16 bytes). •  Checksum usa os headers (pseudo header e header

UDP), e os dados do UDP.

q Comprimento do UDP pode ser um número ímpar de bytes. •  Algoritmo do checksum soma palavras de 16 bits. •  Solução: adicionar preenchimento (“padding)” de zeros,

no final, se necessário, caso o número de bytes seja ímpar.

•  Padding não é transmitido.

22 (*) assim como o TCP)

Pseudo Header (2)

Pseudo header IP (usado pelo UDP)

(16 bytes)

Header UDP (8 bytes)

Explique por que ocorre uma violação da independência das camadas.

http://www.gripinit.com/2015/03/29/udp-theory/ (29/04/2017)

Checksum UDP - RECEPTOR

Receptor (na chegada): q  Soma os campos de header do segmento recebido,

incluindo o valor que está no campo checksum. •  Como colocou o complemento de 1 no campo checksum,

quando somar tudo tem que resultar num valor com todos os bits iguais a 1.

q  Verifica se o valor RESULTANTE é todo igual a 1:

•  NÃO - erro detectado.

•  SIM - nenhum erro detectado.

•  Mas ainda pode haver erros? (Veremos mais adiante ….)

Exemplo de cálculo do checksum (3)

Exemplo de cálculo do checksum (1) Considere 3 palavras de 16 bits sendo transmitidas:

0110011001100110 0101010101010101 0000111100001111

A soma das duas primeiras palavras é:

0110011001100110 0101010101010101 1011101110111011

Adicionando a terceira palavra, a soma acima fica:

1011101110111011 0000111100001111 1100101011001010

q  Os complementos de 1 são obtidos convertendo todos os 0’s para 1’s , e todos os 1’s para 0’s.

Ver RFC-1071 !

0011010100110101

Assim o complemento de 1's da soma 1100101011001010

é 0011010100110101

q  Este valor se torna o checksum.

Assim o complemento de 1's da soma 1100101011001010

é 0011010100110101

q  Este valor se torna o checksum. q  No receptor, todas as palavras de 16 bits são somadas,

incluindo o campo checksum.

q  Se não foram introduzidos erros no pacote, a soma no receptor tem que resultar em 1111111111111111 uma vez que somou-se ao header o complemento de 1 da soma dele.

q  Se pelo menos um dos bits for zero, então algum erro foi introduzido no pacote.

Pergunta exercício: Por que o UDP usa checksum, se a maioria dos protocolos data-link (inferiores), incluindo o popular Ethernet,

também fornece verificação de erro ??

Lembrete 1: método Polinomial

Lembrete 2: “carry”

Exemplo de soma de verificação da Internet

q  nota •  Ao somar números, um carryout do bit mais

significativo precisa ser somado ao resultado q  exemplo: somar dois inteiros de 16 bits

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

contorna

soma soma de

verificação

Princípios de Transferência Confiável de Dados

Reliable Data Transfer (RDT)

Cenário para estudar Reliable Data Transfer (RDT) q  Queremos tornar um canal não confiável num canal confiável.

Características do canal não confiável determinam a complexidade de um protocolo de transferência confiável de dados (RDT).

Transferência confiável de dados (RDT) Como começar?

emissor receptor

rdt_rcv(): chamada quando pacote chega no lado receptor do canal.

deliver_data(): chamada por rdt para entregar dados para

camada superior.

udt_send(): chamada por ambos os lados para troca de pacotes de controle. UDT representa um unreliable data transfer (troca não confiável)

rdt_send( ): chamada da camada superior, (Ex: pela aplicação). Passa dados para entregar

à camada superior receptora

Transferência confiável de dados (rdt): como começar Iremos: q  Desenvolver passo-a-passo os lados remetente e receptor do

protocolo confiável RDT. q  Vamos Considerar apenas fluxo unidirecional de dados.

•  Mas a informação de controle flui em ambos sentidos! q  Usar máquinas de estados finitos (FSM - Finite State Machine)

para especificar remetente e receptor.

estado 1

estado 2

evento causando transição de estados ações tomadas na transição de estado

ESTADO: quando o

sistema está num

“estado”, o próximo

estado é determinado

unicamente pelo próximo

evento.

evento ações

Como iremos analisar:

q Para entender a evolução das ideias sobre RDT, vamos fazer considerações sobre características que podem estar presentes no canal. •  Exemplos: canal pode entregar dados fora de

ordem, inverter bits, perder bits, dentre outros.

q  Importante: entender que RDT ainda não é o TCP, mas é de onde ele veio. •  Trata-se de como o TCP evoluiu.

RDT 1.0: transferência confiável usando um canal confiável

q  Suposição 1.0: o canal é perfeitamente confiável. •  Não apresenta erros de bits.

•  Não apresenta perda de pacotes.

q  FSMs separadas, para remetente e receptor: •  Remetente envia dados pelo canal subjacente. •  Receptor recebe dados do canal subjacente.

Evento que causou a transição

Ações tomadas quando ocorre um

evento Observação: Isso não existe!!

RDT 2.0 - Modelo um pouco mais realista: q Bits num pacote podem ser corrompidos.

•  Falhas podem ocorrer nos componentes físicos da rede:

•  Por exemplo, quando um pacote é transmitido, acontece inversão de 1 bit.

q Entretanto, continuamos supondo que todos os pacotes transmitidos são recebidos na ordem em que são enviados. •  Ainda que bits possam estar corrompidos.

Rdt2.0: canal com erros de bits

q Canal pode inverter bits no pacote. •  O checksum pode detectar erros de bits.

q A questão é: como recuperar dos erros?

Rdt2.0: canal com erros de bits q Canal pode inverter bits no pacote.

•  O checksum pode detectar erros de bits.

q A questão é: como recuperar dos erros? •  Uma boa ideia: usar mensagens de controle.

•  Confirmação (ACK): receptor avisa explicitamente ao remetente que pacote chegou bem.

•  Negativa de Confirmação (NAK): receptor avisa explicitamente ao remetente que pacote tinha erros.

•  Emissor retransmite pacote ao receber um NAK

( Lembrar de cenários humanos usando ACKs, NAKs )

Mensagens de controle

q Permitem o receptor informar ao emissor o que foi recebido corretamente. •  E o que foi recebido com erro, exigindo

retransmissão.

q Protocolos baseados em retransmissão são chamados de Protocolos ARQ: •  Automatic Repeat reQuest.

•  Requisição Automática de Repetição.

Novas capacidades em RDT 2.0 q  3 capacidades adicionais são exigidas em protocolos de

ARQ para lidar com a presença de erros de bits:

1.  Detecção de erros: mecanismo para permitir que o receptor identifique quando erros de bit ocorreram.

2.  Realimentação (feedback) pelo receptor: mensagens de controle (ACK ou NAK) devem ser trocadas entre receptor e o emissor.

3.  Retransmissão: para corrigir os erros detectados.

Estes novos mecanismos estão presentes na proposta de protocolo rdt 2.0

rdt2.0: especificação da FSM - Emissor Possui 2 estados: Em um estado

aguarda dados da camada superior. Em outro estado, aguarda ACK ou

NACK do receptor Aguarda dados da aplicação

Aguarda ACK ou NACK do receptor

Se recebe um ACK confirmando que o dado atual foi recebido, retorna ao estado de aguardar um pacote da

camada superior

Se recebe um NACK, re-envia o último pacote atual, e retorna a

aguardar um ACK ou NACK. Não pode aceitar dados da camada

superior (stop-and-wait)

rdt2.0: especificação da FSM - Receptor

Possui apenas 1 estado: ao receber um pacote, responde com ACK ou

NACK, dependendo se o pacote está ou não corrompido.

Pacote recebido apresenta erro. Emite um NACK, e

retorna ao estado de aguardar.

Pacote recebido está íntegro. Emite um ACK,

confirmando e retorna ao estado de aguardar.

rdt2.0: em ação (sem erros)

FSM do remetente FSM do receptor

rdt2.0: em ação (cenário de erro)

FSM do remetente FSM do receptor

Mas o RDT 2.0 tem um problema fatal...

RDT 2.0 tem uma falha fatal: q O que acontece se ACK ou NACK com erro ?

•  Emissor não sabe o que aconteceu no receptor!

•  Não se pode apenas retransmitir: há possibilidade de pacotes duplicados.

•  O que fazer? q  Emissor usaria ACKs / NAKs para ACK / NAK do

receptor?

•  E se corromper ACK/NAK do remetente?

q Retransmitir? •  Pode causar retransmissão de pacote recebido certo!

RDT 2.0 tem uma falha fatal! O que acontece se ACK

ou NACK com erro ? q  Remetente não sabe o que

aconteceu no receptor! q  Não se pode apenas

retransmitir: há possibilidade de pacotes duplicados.

O que fazer? q  Remetente usa ACKs/NAKs p/

ACK/NAK do receptor? •  E se perder ACK/NAK do

remetente? q  Retransmitir?

•  Mas pode causar retransmissão de pacote recebido certo!

Lidando com duplicação: q  Emissor inclui número

de sequência para cada pacote.

q  Emissor retransmite pacote atual se ACK / NAK for recebido com erro.

q  Receptor descarta pacote duplicado.

Remetente envia um pacote, e então aguarda resposta do receptor.

Stop and wait

RDT 2.1: EMISSOR – como trata ACK/NAKs com erro Insere No. de

sequência 0 no pacote

Deve verificar se ACK/NAK

recebido tinha erro

Aguarda a chegada do No. Seq. correto

RDT 2.1: RECEPTOR – como trata ACK/NAKs com erro Deve checar se pacote recebido é duplicado.

O estado indica se No. de sequência esperado é 0 ou 1 Pacote corrompido

No. Seq. errado

RDT 2.1: discussão (1)

EMISSOR: q  Insere No. de sequência (seq#) no pacote.

q Bastam dois Nos. de sequência (0 ou 1).

q Deve verificar se ACK/NAK recebido tem erro.

q Duplicou o No. de estados (compare com RDT 2.0): •  Tem que “lembrar” se o pacote “atual” tem o

número de sequência 0 ou 1. •  Aqui surge uma das primeiras características do TCP:

manutenção de status (statefull protocol).

rdt2.1: discussão (2)

RECEPTOR: q Deve checar se pacote recebido é duplicado.

•  Estado indica se No. de sequência esperado é 0 ou 1.

q Receptor não tem como saber se último ACK/NAK foi recebido bem pelo emissor. •  Ele não tem como ter contato direto com o

emissor, a não ser por intermédio da indicação de pacotes trocados.

Exercício: RDT 2.2: um protocolo sem NAKs

q  Mesma funcionalidade que RDT 2.1, mas apenas com ACKs.

q  Ao invés de NAK, receptor envia ACK para o último pacote recebido corretamente.

•  Receptor deve incluir explicitamente o No. de sequência do pacote confirmado.

q  ACK duplicado no emissor resulta na mesma ação que o NAK: retransmite pacote atual.

EMISSOR

Fica como exercício fazer esta abstração sem NAK

RDT 3.0: canal com erros e perdas (1)

Nova suposição: além de corromper dados, o canal também pode perder pacotes.

•  Pode perder dados ou ACKs. •  Só vamos usar ACKs e não mais NAKs.

q Como lidar com perdas? •  Como detectar perda de pacotes ? •  O que fazer quando pacotes são perdidos?

Checksum, No. de sequência, ACKs, e retransmissões podem

ajudar, mas não serão suficientes.

rdt3.0: canais com erros e perdas (2)

q Solução: emissor aguarda o ACK que está em trânsito, por um determinado tempo.

q Exige uso de temporizadores (timers). •  Se há evento de Timeout à esgotamento do timer:

•  Retransmite se nenhum ACK for recebido neste tempo.

q  Mas: se pacote (ou o ACK) está apenas atrasado (não

perdido):

•  A retransmissão será duplicada. •  Mas o uso de número de sequência resolve este problema.

•  Receptor deve avisar o número de sequência do pacote que está sendo confirmado.

RDT 3.0: EMISSOR

Esgotou o timer: reenvia o anterior

Inicia o timer e aguarda o ack

RDT 3.0 em ação (1)

RDT 3.0 em ação (2)

Descarta pkt1 duplicado

Descarta pkt0 duplicado

RDT – últimas palavras q Terminamos os estudos da criação dos

protocolos RDT e das ideias que deram origem a eles. •  Eles serão a base para o TCP, mas ainda não são o

q Em seguida veremos agora os protocolos dutados, que se juntarão ao RDT para formar o TCP.

É importante entender bem as ideias do RDT, para poder prosseguir.

Protocolos “dutados” (pipelined)

Problema com protocolo stop & wait q  Em longas distâncias: retardo fim-a-fim é grande. q  Pacote pode estar em trânsito, e ainda não foi

confirmado. q  O emissor fica bloqueado até receber o ACK do

pacote anterior.

Desempenho de rdt3.0 q  RDT 3.0 funciona, porém seu desempenho é muito ruim. q  Exemplo - considere:

•  Link de 1 Gbps (10**9 bits/seg); •  Pacote de 1 KByte (8K bits) •  Retardo fim-a-fim de 15 ms :

T transmissão = 8 kbits/pacote 10**9 b/seg = 8 microseg

Desempenho = 8 microseg 30.016 mseg = 0,00027 = 0,027 %

Pacote de 1KB a cada 30 mseg → vazão de 33 Kbyte / seg num enlace 1 Gbps.

Conclusão: Protocolo limita uso dos recursos físicos.

Tempo de ida e volta = 30 ms + 16 microseg

Protocolos “dutados” (pipelined) Dutagem (pipelining): emissor admite múltiplos

pacotes em trânsito, ainda não confirmados. •  Faixa de números de sequência deve ser aumentada. •  Exigirá Buffers no remetente e/ou no receptor.

q  Duas formas genéricas de protocolos “dutados”: •  Volta-N (GBN – Go Back N) •  Retransmissão Reletiva (SR - Selective Repeat).

GBN - Go Back N (1)

q Também conhecido como “Volta-N”.

Permite o EMISSOR enviar múltiplos pacotes, sem aguardar ACK do receptor.

q Entretanto:

•  Não poderá haver mais do que um valor máximo de N pacotes não confirmados no canal.

GBN - Go Back N (2)

[0, send_base - 1] = Pacotes transmitidos e confirmados (verde)

[send_base, nextseqnum - 1] = Pacotes enviados mas não confirmados (amarelo)

[nextseqnum, send_base + N - 1] = Disponíveis para serem usados imediatamente, assim que dados chegarem da camada superior (azul).

Sequence number ≥ (send_base + N) : não podem ser usados até que um pacote não confirmado que esteja atualmente no duto tenha sido confirmado (brancos).

send_base = Seq. # do pacote mais antigo não confirmado no duto. nextseqnum = Menor Seq. # não usado (Seq.# do próximo a enviar).

GBN - Go Back N (3) q  No EMISSOR: O intervalo de números de sequência

para pacotes transmitidos, mas ainda não confirmados, poder ser visto como uma janela (window) de tamanho N sobre o intervalo de números de sequência.

q  À medida que o protocolo opera, a janela se desloca sobre o espaço de números de sequência: sliding-window protocol = Janela deslizante.

Pergunta: por que limitar o número de pacotes não confirmados ? (exercício)

GBN: FSM estendida do EMISSOR (1/3)

Chamada superior: verifica se a janela está cheia. Se não está, forma o pacote e envia. Se está cheia, recusa.

Recebe um ACK(n): confirma que todos pacotes até, e inclusive, o No. de sequência n foram recebidos no receptor: “ACK cumulativo” pode receber ACKs duplicados.

Temporizador Timeout(n): retransmite pacote n e todos os pacotes com No. de sequência maiores na janela.

Se ocorrer um esgotamento do temporizador, o emissor reenvia TODOS os pacotes que tinham sido previamente enviados, mas que ainda não tinham sido reconhecidos. Temporizador: é um cronômetro

para o pacote mais antigo transmitido, mas que ainda não foi reconhecido 2

• Se for recebido um ACK, e ainda houver pacotes enviados mas ainda não confirmados, o timer será reiniciado. • Se não houver nenhum pacote pendente (aguardando confirmação), então o timer é desligado. Temporizador: é um cronômetro

para o pacote mais antigo transmitido, mas que ainda não foi reconhecido

GBN: FSM estendida do RECEPTOR

Receptor é muito simples: q  Usa apenas ACK: sempre envia ACK para pacote recebido

o.k. com o maior número de sequência em ordem. •  Pode gerar ACKs duplicados •  Só precisa se lembrar do expectedseqnum

q  Se recebe Pacote fora de ordem: •  Descarta (não armazena) → receptor não usa buffers. (TCP usa!) •  Manda ACK de pacote com maior No. de sequência em ordem.

expectedseqnum = expectedseqnum + 1

GBN em ação

Janela = 4. Envia de 0 a 3 e o 2 se perde

Confirma os pacotes 0 e 1

Pacote 2 se perdeu. Descarta o 3 e pede o 2 (confirma o 1).

Descarta o 4 e o 5, e continua pedindo o 2.

Timeout do ack de 2. Retransmite o 2.

GBN não é o TCP q  GBN incorpora quase todas as técnicas que serão encontradas

nos componentes do TCP (visto mais adiante):

•  Número de sequência.

•  Checksum.

•  ACK cumulativos.

•  Timeouts.

•  Operação de retransmissão.

q  Entretanto existem diferenças entre o TCP e o GBN.

q  Por exemplo: implementações TCP fazem buffering de segmentos recebidos corretamente, mas fora de ordem.

q  TCP é um híbrido de GBN e Repetição Seletiva (a seguir).

Problemas do GBN

q GBN tem problemas de performance. •  Se o tamanho da janela é grande e o atraso da

rede também é grande, muitos pacotes podem estar no duto.

•  Um único erro em um segmento resulta na retransmissão de um grande número de segmentos, a maioria desnecessários.

q À medida em que a probabilidade de erro do canal cresce, o duto fica lotado de retransmissões desnecessárias.

Repetição Seletiva

Repetição seletiva (1/2)

q Evita retransmissões desnecessárias.

q Emissor: retransmite apenas os pacotes que suspeita terem sido recebidos com erro pelo receptor.

q  Receptor: confirma individualmente todos os pacotes recebidos corretamente.

•  Armazena pacotes no buffer, se necessário, para posterior entrega em ordem à camada superior.

Repetição seletiva (2/2)

q Uma vez que o emissor apenas re-envia pacotes para os quais o ACK não foi recebido à Complica um pouco:

•  É necessário um Timer de EMISSOR para cada pacote sem ACK.

q Janela do emissor: •  N números de sequência consecutivos.

•  Deve limitar os Nos. de sequência de pacotes enviados, mas ainda não reconhecidos.

Repetição seletiva: janelas de remetente e receptor

O emissor já terá recebido confirmação para alguns pacotes

da janela.

Repetição seletiva no EMISSOR (1/2)

q Dados recebidos de acima: •  Emissor verifica o próximo No. sequência disponível.

•  Se o No. de sequência estiver dentro da janela do emissor, os dados são empacotados e enviados;

•  Caso contrário são bufferizados ou devolvidos à camada superior para transmissão posterior.

q  Timeout: temporizadores são usados para proteger contra perda de pacotes. •  Somente um único pacote será transmitido no

caso de timeout.

Repetição seletiva no EMISSOR (2/2)

q ACK recebido: emissor marca o pacote como recebido. •  Se o número de sequência do pacote for igual à send_base, então a base da janela avança até o pacote com o menor número de sequência não-confirmado.

•  Se houver pacotes não transmitidos, com números de sequência que caem agora dentro da janela, estes pacotes são transmitidos.

Repetição seletiva: janelas de emissor e receptor

O emissor já terá recebido confirmação para alguns pacotes

da janela.

Eventos de SR no receptor (1) 1.) Pacote com número de sequência no intervalo

[ rcv_base, rcv_base+N-1] é recebido corretamente: •  Neste caso, o pacote recebido cai dentro da janela do receptor. •  Um ACK seletivo é retornado ao remetente. •  Se o pacote não foi recebido previamente, ele é armazenado. •  Se este pacote tiver um número de sequência igual à base da janela da

recepção (rcv_base), então este pacote, e os quaisquer pacotes previamente armazenados e numerados em sequência (começando com o rcv_base) são entregues à camada superior.

•  A janela de recepção é movida então para a frente pela quantidade do número total dos pacotes entregues à camada superior.

2.) Pacote com número de sequência é recebido dentro de [ rcv_base-N, rcv_base-1 ]:

•  Neste caso, um ACK deve ser gerado, mesmo que este seja um pacote que o receptor já tenha confirmado previamente.

3.) Caso contrário: Ignora o pacote.

Eventos de SR no receptor (2)

Intervalo dentro da janela [ rcv_base, rcv_base+N-1]

[ rcv_base-N, rcv_base-1 ]: pacotes já confirmados anteriormente

4.) Pacote com número de sequência é recebido dentro de [ rcv_base-N, rcv_base-1 ]: Neste caso, um ACK deve ser gerado, mesmo que este seja um pacote que o receptor já tenha confirmado previamente.

Repetição seletiva - resumo

Dados de cima: q  Se próximo No. de sequência

na janela à envia o pacote.

Timeout(n): q  Reenvia pacote n. q  Reinicia o temporizador.

ACK(n) em [sendbase,sendbase+N]: q  Marca pacote n como

“recebido”. q  Se N for menor pacote não

confirmado, avança base da janela ao próximo No. de sequência não confirmado.

•  Pacote n dentro de [rcvbase, rcvbase+N-1]: Envia ACK(n). Fora de ordem: buffering. Em ordem: entrega (tb. entrega pacotes em ordem do buffer), avança janela p/ próximo pacote ainda não recebido. •  Pacote n em [rcvbase-N,rcvbase-1]

ACK(n), mesmo que já tenha enviado antes. •  Senão:

Ignora.

receptor emissor

Retransmissão seletiva em ação

2 perde pkt2

buferizados Janela se move depois de

recebidos ack0 e ack1

Retransmissão seletiva em ação

2 perde pkt2

buferizados Janela se move depois de

recebidos ack0 e ack1

Completa com o pkt2 que faltava, entrega 2,3,4,5 à

camada superior, e envia ack2.

Repetição seletiva: dilema

Exemplo: q  Nos. de sequência:

0, 1, 2 e 3. q  Tamanho de janela = 3.

q  Exercício:

Qual a diferença entre os dois cenários (a.) e (b.) para o receptor?

Repetição seletiva: dilema

Exemplo: q  Nos. de sequência : 0, 1, 2 e 3. q  Tamanho de janela = 3. q  Receptor não vê diferença entre

os dois cenários (a.) e (b.) !!!

Pergunta / exercício: Qual a relação entre tamanho de No. de sequência e tamanho de janela?

Um tamanho de janela que seja igual ao tamanho de numeração sequencial, menos 1, não vai funcionar.

A implementação do TCP

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

q Processo-a-processo: •  Peer process fala diretamente com outro peer process.

q  Entrega fluxo de bytes ordenados e confiável:

q Dutado (pipelined): •  Tamanho da janela ajustado por controle de fluxo e

congestionamento do TCP.

q Usa Buffers de envio e recepção, e variáveis de estado para cada conexão.

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

q O tráfego é Full Duplex: •  Fluxo de dados bi-direcional na mesma conexão.

•  MSS: é o tamanho máximo de segmento de dados. (Falaremos de MSS mais adiante)

q É orientado a conexão: •  Handshaking de 3 vias (troca de msgs de controle)

inicia estado de remetente, receptor antes de trocar dados.

q Tem o Fluxo controlado: o receptor não será afogado.

1500 bytes, 536 bytes ou 512 bytes

TCP: estrutura do segmento

No. porta origem No. porta dest

32 bits

dados da aplicação

(tamanho variável)

número de sequência (SEQ#) número de confirmação (ACK#)

janela receptor

ptr dados urg. checksum F S R P A U tam.

cab. sem uso

Opções (tamanho variável)

URG: dados urgentes (pouco usado)

ACK: No. ACK é válido

PSH = push: força envio de dados imediatamente.

RST, SYN, FIN: gestão de conexão

(comandos de estabelecimento,

liberação)

No. bytes que o receptor quer aceitar: Controle de Fluxo.

Contagem de dados por bytes (não segmentos!)

checksum Internet

(como UDP)

Tamanho do header em palavras de 32 bits

20 bytes fixos no header

Header TCP q  Porta Origem e Porta Destino identificam o processo de aplicação que está enviando dados e o processo de

aplicação que irá receber os dados.

q  Número de sequência (SEQ#) identifica os bytes enviados. Na prática ele é a identificação do primeiro byte de dados contido no segmento enviado. Os demais são seqüenciados a partir deste byte.

q  Acknowledgement (ACK#) identifica os bytes que foram recebidos e tratados sem erro pelo destino, bem como a sequência do próximo byte esperado.

q  Tamanho header : número decimal de palavras de 32 bits do header TCP tipicamente contém valor 5 (4 bits).

q  Reservado é um campo ainda não utilizado (6 bits) à veja exercício no final deste material

q  Window identifica o tamanho da janela para o controle de fluxo

q  Checksum destina-se a verificação de erros de transmissão. É calculado usando o pseudo header, o header TCP e também a área de dados.

q  Urgent Pointer é um ponteiro para dados urgentes, contidos na área de dados (caso bit U setado para 1).

TCP: Gerenciamento de Conexões

TCP: Gerenciamento de Conexões (1)

q  Emissor e receptor TCP estabelecem “conexão” antes de trocar dados.

q  Full duplex: fluxo de dados segue nos dois sentidos.

q  Inicializam variáveis TCP: •  Números de sequência e confirmação.

•  Buffers, informações de controle de fluxo (por ex. RcvWindow) e temporizadores.

q  Cliente: é aquele que inicia a conexão. •  Active Open

q  Servidor: é aquele chamado pelo cliente. •  Passive Open.

TCP: Iniciando Conexão (1) Inicialização em 3 passos (3-way handshake):

(1): Cliente envia segmento de controle de início de conexão TCP ao servidor.

•  Bit SYN do TCP é ajustado como 1 e Bit ACK como 0. (SYN=1; ACK=0) •  Cliente envia seu No. de Sequência inicial Seq#C1 (32 bits)

(2): Servidor recebe (SYN=1, ACK=0) e Seq#C1

•  Responde com pacote setando bits SYN=1 E ACK=1

•  Confirma SYN# do cliente recebido setando ACK# = (Seq#C+1).

•  Envia seu Seq#S1 (No. Seq. inicial do servidor) •  Aloca buffers, especifica No. seq. inicial de servidor para o receptor.

(3): Cliente recebe SYN=1; ACK=1 à responde com segmento ACK confirmando o número de sequencia recebido e começa a enviar dados. (SYN=0; ACK=1)

TCP: Iniciando Conexão (2)

(SYN=1; ACK=0)

(SYN=1; ACK=1)

(SYN=0; ACK=1)

Cliente confirma o No. seq. do server, e começa a enviar dados seguindo seu No. de seq.

Servidor confirma o No. seq. do cliente, e envia seu próprio

No. de seq.

Estabelecimento da Conexão

Cliente A

Server B

SYN 1415531521:1415531521 (0) <mss 1024>

SYN 1823083482: 1823083482 (0) <mss 1024> ACK 1415531522

.... , ACK 1823083483

Exemplo – captura de pacotes:

svr4 % telnet bsdi.discardTrying 192.82.148.3 ...Connected to bsdi.Escape character is '^]'.^] #type Control, right bracket to talk to the Telnettelnet> quit #terminate the connectionConnection closed.

Extraído de: TCP/IP Illustrated Vol.1 – Richard Stevens

Listen – SYN RCV - Established

TCP: Números de sequência e ACKs q  Nos. de sequência: é o

“número” do primeiro byte de

dados do segmento.

q  ACKs: No. de sequência do

próximo segmento esperado (em bytes).

•  ACK cumulativo.

q  Como receptor trata segmentos

fora da ordem?

•  Especificação do TCP é

omissa - deixado ao

implementador.

•  Maioria das

implementações: buferiza.

Host A Host B

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

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

Seq=43, ACK=80

Usuário tecla ‘C’

A reconhece chegada do ‘C’ ecoado

B reconhece chegada de ‘C’, ecoa ‘C’ de volta

cenário simples de telnet

Conexão já em andamento…

ACKs duplicados q First time ack é sinal que está tudo ok.

q Mas, o que acontece se o emissor recebe um ACK duplicado? •  “re-reconhece” um segmento para qual o emissor

já tenha recebido ACK anteriormente.

q Veremos em seguida como isso é usado pelo TCP...

Lidando com ACKs duplicados e retransmissões.

q  No TCP os segmentos são enviados em paralelo (pipeline).

q  Os ACKs são cumulativos.

•  A chegada de um ACK confirma anteriores.

q  TCP usa único timer de retransmissão. •  É um timer para o segmento mais antigo sem ACK.

q  Retransmissões são disparadas por: •  Eventos de timeout.

•  ACKs duplicados.

q  Inicialmente, para facilitar o entendimento, vamos considerar um emissor TCP simplificado: •  Ignorar controle de fluxo e controle de congestionamento. •  Serão vistos mais adiante.

Eventos de emissor TCP (1)

q Quando dados são recebidos da aplicação:

•  Cria segmento com seq#

•  O número seq# é número da cadeia de bytes do

primeiro byte de dados no segmento.

•  Inicia timer, se ainda não tiver iniciado.

•  É um timer para o segmento mais antigo sem ACK.

•  Intervalo de expiração: Time-Out-Interval

Eventos de emissor TCP (2)

EVENTOS: 1.) Evento Timeout: q  Retransmite segmento que causou timeout.

q  Reinicia timer.

2.) ACK recebido: q  Confirma o seguimento corrente, e todos os demais

segmentos anteriores ainda sem ACK. •  Atualiza aqueles que sabidamente foram recebidos.

•  Receptor não enviaria um ACK se não tivesse enviado os anteriores.

q  Reinicia timer (se houver segmentos pendentes)

TCP: cenários de retransmissão (1)

Indica que B recebeu tudo

certo, até o 100 (aguarda o 120)

Recebe a indicação que B recebeu tudo

certo, até o 100, e não re-envia nada.

O ACK do primeiro

segmento se perde.

Envia dois segmentos de

uma vez, e aguarda.

Cenário ACK cumulativo

Hosp. A

Seq = 100, 20 bytes dados

Timeout prematuro

Hosp. B

Hosp. A

ACK = 100

Cenário de ACK perdido

Hosp. B

tempo Se

SendBase = 100

SendBase = 120

Sendbase = 100

Host A

ACK = 100

perda ti

Cenário ACK cumulativo

Host B

SendBase = 120

Chegada dentro do timer: indica que B

recebeu tudo certo, até o 100, e está

aguardando o 120

Tratando segmentos faltantes: ACKs repetidos (1)

q  Quando um receptor recebe um segmento com um número de sequência maior do que próximo número de sequência esperado, ele detecta uma falha no fluxo de dados •  Detecta segmento faltante.

q  TCP não usa NACK: •  O receptor não pode emitir não-ACK para o emissor.

•  Ao invés disso: “re-reconhece” o último byte “em ordem” dos dados que ele recebeu corretamente.

•  Isto é, ele gera um ACK em duplicata para o último byte recebido corretamente.

Tratando segmentos faltantes: ACKs repetidos (2)

q  Período de timeout é relativamente grande: •  Pode haver longo atraso antes de reenviar pacote perdido.

q  É necessário detectar segmentos perdidos por meio de ACKs duplicados •  Emissor geralmente envia muitos segmentos um após o

outro.

•  Se um segmento for perdido, provavelmente haverá muitos ACKs duplicados para esse segmento.

•  Isso é tratado com a “retransmissão rápida”.

Retransmissão rápida (1) q Se o emissor receber três ACKs

duplicados (ou seja, 4 ACKs idênticos) para o mesmo segmento que ele já enviou:

•  Assume que foi perdido o segmento em seguida ao segmento que foi confirmado 4X

•  O TCP executa uma retransmissão rápida.

•  Re-envia o segmento faltante, mesmo antes que o temporizador esgote

•  Definido pelo RFC 2581.

Entendendo os 3 “ACKs duplicados” (1)

ACK xxxxxxx523

ACK xxxxxxx523 Ain

1o. ACK duplicado

2o. ACK duplicado

3o. ACK duplicado

A chegada de 4 ACKs idênticos antes de vencer o timer do ACK, resulta na “retransmissão rápida”.

Hosp. A

Hosp. B

reenvia seq X2

seq # x1 seq # x2 seq # x3 seq # x4 seq # x5

ACK x1

ACK x1 ACK x1 ACK x1

ACKs duplicados três vezes

Entendendo os 3 “ACKs duplicados” (2)

event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } else { increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) { resend segment with sequence number y }

Algoritmo de retransmissão rápida:

ACK duplicado para segmento já com ACK

retransmissão rápida

RFC 2581 - TCP Congestion Control

" The TCP sender SHOULD use the "fast retransmit" algorithm to detect and repair loss, based on incoming duplicate ACKs. The fast retransmit algorithm uses the arrival of 3 duplicate ACKs (4 identical ACKs without the arrival of any other intervening packets) as an indication that a segment has been lost. After receiving 3 duplicate ACKs, TCP performs a retransmission of what appears to be the missing segment, without waiting for the retransmission timer to expire."

http://www.faqs.org/rfcs/rfc2581.html

Resposta de ACKs no TCP [RFCs 1122, 2581]

Encerramento da Conexão

q Half Close •  Conexões TCP são full-duplex.

•  Cada lado da conexão deve finalizar a conexão de forma independente.

•  Quando um dos lados envolvidos recebe uma solicitação de finalização, deve enviar a notificação para a aplicação.

•  Uma aplicação após receber o pedido de finalização ainda pode mandar dados.

TCP: Fechando uma Conexão

Encerrando uma conexão:

1: cliente envia segmento de controle FIN ao servidor.

2: servidor recebe FIN, responde com ACK. Também pede encerramento da conexão, enviando FIN.

3: cliente recebe FIN, responde com ACK.

•  Entre em “espera temporizada” - responderá com ACK a FINs recebidos

4: servidor, recebe ACK.

Conexão encerrada.

cliente

servidor

fechar

fechada

Half-close captura de pacotes:

svr4 % telnet bsdi.discardTrying 192.82.148.3 ...Connected to bsdi.Escape character is '^]'.^] #type Control, right bracket to talk to the Telnettelnet> quit #terminate the connectionConnection closed.

Extraído de: TCP/IP Illustrated Vol.1 – Richard Stevens

Half-Close / Time-wait detalhado

http://www.tcpipguide.com/free/t_TCPConnectionTermination-2.htm

TCP: Ciclo de vida do SERVIDOR

Exercício: estudar o ciclo de vida do servidor TCP

TCP: Ciclo de vida do CLIENTE

Exercício: estudar o ciclo de vida do cliente TCP

Exercício: Estudar as transições de

estado do TCP

Exercício: Estudar as transições de estado do TCP

TCP: RTT e timeout

-  Timer adaptativo. -  Outros timers.

RTT e timeout adaptativo do TCP (1)

Como definir o valor de timeout do TCP? q  Deveria ser maior que RTT.

•  Mas RTT varia bastante.

q  Se for muito curto: ocorre timeout prematuro.

•  Resulta em retransmissões desnecessárias

q  Se for muito longo

•  Resulta em baixa reação a perda de segmentos.

Então: Como estimar o RTT

(EstimatedRTT)?

Como estimar o RTT (EstimatedRTT)? q  SampleRTT: tempo medido da transmissão do segmento

até receber o ACK.

q  Assim, o SampleRTT vai variar. •  É bom que o RTT estimado seja “mais estável” possível.

•  Usa-se a média de diversas medições recentes,

e não apenas SampleRTT atual.

EstimatedRTT = (1 - α)*EstimatedRTT + α*SampleRTT

❒ Média exponencial ponderada móvel .

❒  Influência da amostra mais antiga diminui exponencialmente rápido. ❒  Dá mais peso às medidas mais recentes.

Valor típico: α = 0,125

(determinado empiricamente)

Relação entre RTT amostra e RTT estimado

Mas o Timeout ainda é definido da seguinte maneira: q  EstimatedRTT deve oferecer mais “margem de segurança”.

•  Oferecer maior margem de segurança se há grande variação em SampleRTT .

•  Então é necessário considerar quanto varia o SampleRTT.

•  Primeira estimativa do quanto SampleRTT se desvia de EstimatedRTT é DevRTT:

TimeoutInterval = EstimatedRTT + 4*DevRTT

DevRTT = (1-β)* DevRTT + β*|SampleRTT - EstimatedRTT| (geralmente β = 0,25, definido empiricamente)

e depois definir intervalo de timeout:

Exercício: Pesquisar e estudar algoritmo Jacobson / Karels.

Se você pensa que acabou… (1)

q  Temporizador adaptativo de retransmissão não é o único usado pelo TCP.

q  Na verdade são 4 timers.

•  Timer Retransmissão adaptativo (visto)

+ 1.  Timer de Persistência.

2.  Timer Keep-alive.

3.  Timer Time-wait.

1. Timer de persistência

q É usado para evitar impasse. •  Receptor envia pacote de tamanho de janela 0,

pedindo para emissor aguardar. (Mais adiante ficará mais claro o que significa um “tamanho de janela zero”)

•  Emissor faz um teste de tempos em tempos, usando o timer de persistência, para ver se pode voltar a transmitir (devido a risco de perda do pacote de atualização do receptor).

2. Timer keep alive

q Temporizador keep alive •  (“mantenha vivo”):

•  Para verificar conexões inativas por muito tempo.

•  Um lado verifica se o outro ainda está lá.

3. Temporizador Time Wait

q  Temporizador time wait (“tempo de espera”):

•  Usado para encerramento de sessão.

•  É ajustado para 2 vezes o tempo de vida máximo de um pacote (TTL - Time to Live).

•  Tenta garantir que quando uma sessão for encerrada, todos os pacotes criados por ela já tenham sido entregues.

MSS e numeração de segmentos

MSS (Maximum Segment Size)

q O MSS representa o tamanho do maior bloco de dados que o TCP permite enviar num único segmento. •  Para a maioria dos computadores o MSS é

ajustado automaticamente pelo SO.

•  Default (obrigatório): 536 bytes. •  (20 bytes IP, 20 bytes TCP, para um total de 576 bytes).

•  Ethernet padrão: 1460 bytes. •  (20 bytes IP, 20 bytes TCP, para um total de 1500 bytes)

Quanto maior o MSS, melhor

q Em geral: quanto maior o MSS, melhor o desempenho da rede. •  Mais dados são enviados num único segmento.

•  Quanto maior a quantidade de dados enviados em um único bloco, menor o overhead de headers TCP e IP.

•  Desde que não ocorra fragmentação. (Trataremos fragmentação no protocolo IP; associado ao MTU)

•  O MSS está limitado pelo MTU, que está limitado pela tecnologia ou protocolo da camada de enlace.

•  Esta relação será discutida mais adiante, junto com a discussão sobre MTU na camada de rede.

MSS e numeração de segmentos

Aplicação quer enviar 500.000 bytes de dados, Num TCP com MSS = 1.000 bytes

Transmissão TCP: 500 partes de 1.000 bytes

1o. segmento último segmento

O No. de sequência do emissor é incrementado pelo No. de bytes enviados

Controle de FLUXO no TCP

TCP: Controle de Fluxo (1)

buffering pelo receptor

RcvBuffer = tamanho do Buffer de recepção. RcvWindow = informa ao emissor quantidade de espaço vazio no buffer do receptor.

Este valor é mantido como variável em cada lado da conexão (lembrar que é Full Duplex).

Para emissor não esgotar os buffers do receptor, transmitindo demais, ou muito rapidamente.

TCP: Controle de Fluxo (2) q  RECEPTOR: explicitamente avisa o emissor da quantidade de

espaço livre disponível (que muda dinamicamente).

•  Campo RcvWindow (janela) no segmento TCP .

q  EMISSOR: mantém a quantidade de dados transmitidos, porém ainda não reconhecidos, MENOR que o valor mais recente de RcvWindow.

(para cada lado da conexão)

Troca de informações sobre controle de fluxo TCP (0) 4 Kb = Tamanho do buffer do receptor.

(1) Aplicação envia 2 Kb

(2) Receptor confirma e avisa que pode enviar mais 2

(4) Receptor confirma e pede para aguardar

(buffer cheio) win=0 (...) Emissor aguarda...

(5) Aplicação lê 2 Kb do TCP ; Receptor

TCP avisa que pode enviar mais 2 Kb

(reconfirma o último recebido e envia janela de 2048)

(6) Receptor agora pode enviar até 2

Kb; envia o 1 Kb que falta.

(3) Aplicação envia 3 Kb, mas emissor TCP só pode enviar 2 Kb

Controle de Congestionamento

Princípios de Controle de Congestionamento (1)

Congestionamento: q  Trata emissor enviando dados mais rapidamente do

que a rede pode suportar.

•  Atenção! É diferente de controle de fluxo. •  Retransmissão de pacotes trata o sintoma do

congestionamento da rede: perda de segmentos.

•  Mas não trata a causa do congestionamento:

•  Origens tentando enviar dados numa taxa muito alta, na qual a rede não está suportando.

Princípios de Controle de Congestionamento (2)

q Como se manifesta:

•  Perda (drop) de pacotes •  Esgotamento de buffers em roteadores.

•  Retransmissão de pacotes. •  Devido aos drops.

•  Longos atrasos •  Grande filas nos buffers dos roteadores.

Solução para o Congestionamento

q Solução para o congestionamento: reduzir a taxa de transmissão de dados.

Não inserir novos pacotes na rede, até que os antigos tenham saído.

•  Ou seja, até que os antigos tenham sido entregues.

q TCP à tenta alcançar esse objetivo.

•  Manipulando dinamicamente o tamanho da janela.

Controle de congestionamento TCP: busca por largura de banda adequada

❒  Busca por largura de banda: ❒  Aumenta taxa de transmissão no recebimento do ACK até

ocorrer perda.

❒  Depois diminui taxa de transmissão, quando ocorre perda. ❒  Aumentar com ACK ok, e diminuir na perda, pois largura de banda

disponível está mudando, dependendo de outras conexões na rede.

❒  Com que velocidade aumentar/diminuir? Veremos detalhes a seguir

ACKs sendo recebidos, de modo que aumenta taxa

X perda e diminuição de taxa

comportamento “dente de serra”

do TCP

O que o TCP faz para evitar congestionamentos:

q  Quando uma conexão é estabelecida, um lado escolhe um tamanho de janela adequado. •  Veremos mais adiante como ocorre a escolha.

q  O receptor especifica uma janela a partir do tamanho de seu buffer. •  Indica o quanto ele está disposto a receber.

q  Se o transmissor se mantiver dentro do tamanho da janela, não haverá problemas causados pela sobrecarga dos buffers no receptor.

•  Mas eles ainda podem ocorrer devido a congestionamentos internos na rede.

TCP: Controle de Congestionamento (1)

q Existem dois problemas potenciais: •  Capacidade do receptor. •  Capacidade da rede.

q Deve-se tratar cada um em separado. q  Para isso, cada transmissor mantém duas janelas:

•  Janela fornecida pelo receptor. RcvWin

•  Janela de congestionamento:

CongWin Vejamos

TCP: Controle de Congestionamento (2)

q Cada uma identifica o número de bytes que o transmissor pode enviar. •  Pode enviar o valor mínimo das duas janelas.

q Então, a quantidade máxima de dados não confirmados que um host pode enviar em uma conexão deve ser:

LastByteSent - LastByteAcked ≤ min{CongWin, RcvWin}

TCP: Controle de Congestionamento q  Controle é fim a fim (sem apoio da rede). q  Taxa de transmissão é limitada pela tamanho da

janela de congestionamento Congwin:

Congwin

A janela efetiva é o mínimo do que o transmissor e o receptor consideram viável.

Veremos exemplo a seguir....

TCP: Controle de Congestionamento

q A janela efetiva é o mínimo do que o transmissor e o receptor consideram viável.

Exemplos:

1.  Se o receptor disser: “envie 8KB”, mas... •  se o transmissor souber que qualquer rajada com

mais de 4 KB poderá congestionar a rede, •  ele enviará apenas 4 KB.

2.  Se o receptor disser: “envie 8KB”, mas... •  Se o transmissor souber que rajadas de até 32 KB

passam pela rede sem problemas, •  ele enviará os 8 KB solicitados.

TCP: Controle de Congestionamento

q A janela efetiva é o mínimo do que o transmissor e o receptor consideram viável.

Exemplos:

1.  Se o receptor disser: “envie 8KB”, mas... •  se o transmissor souber que qualquer rajada com

mais de 4 KB poderá congestionar a rede, •  ele enviará apenas 4 KB.

2.  Se o receptor disser: “envie 8KB”, mas... •  Se o transmissor souber que rajadas de até 32 KB

passam pela rede sem problemas, •  ele enviará os 8 KB solicitados.

Como funciona o controle: q  Sondagem para banda a ser usada:

•  Transmitir o mais rápido possível sem perder pacotes

(ou seja, Congwin ajustado ao máximo possível)

•  Aumentar Congwin até perder pacotes à vai causar congestionamento.

•  Quando houver perdas: diminuir Congwin.

•  Depois volta a à sondagem, aumentando novamente.

q  Duas “fases” 1.  Partida lenta. 2.  Prevenção de congestionamento.

q  Variáveis importantes: •  congwin. •  threshold:

•  define limiar entre fases de partida lenta e controle de congestionamento. •  Também chamado de “patamar”.

Tudo explicado a seguir..

Partida lenta e sondagem do congestionamento (1)

q Conexão é estabelecida → transmissor ajusta a variável congwin igual ao MSS. •  Em seguida, ele envia este segmento.

•  Se esse segmento for confirmado antes de ocorrer um timeout, então o transmissor:

•  Adicionará o número de bytes de 1 MSS na janela de congestionamento, de modo que ela tenha capacidade equivalente a 2 MSS.

– Ou seja: congwin++ •  Enviará os 2 segmentos...

(continua...)

Partida lenta e sondagem do congestionamento (2)

q  À medida que cada um desses segmentos for confirmado, a janela de congestionamento é aumentada em um tamanho deste segmento máximo, de tal forma que - quando ambos forem confirmados - a janela terá agora 4 vezes o valor inicial. •  Quando a janela de congestionamento chegar a n segmentos,

e se todos os n segmentos forem confirmados a tempo, a janela de congestionamento será aumentada pelo número de bytes correspondentes aos n segmentos.

q  Cada rajada confirmada duplica a janela de congestionamento atual: crescimento exponencial.

q  Chamado de “partida lenta” (slow start).

TCP: Partida lenta

q  A cada RTT ocorre um aumento exponencial no tamanho da janela. •  Partida não é tão lenta!

Algoritmo de Partida Lenta inicializa: Congwin = 1 for (cada segmento c/ ACK) Congwin++ until (evento de perda OR CongWin > threshold)

Estação A

um segmento

Estação B

dois segmentos

quqtro segmentos

Veremos o que é isso a seguir...

Quando parar o crescimento?

q Mas, quando parar o crescimento ? •  Obviamente à este crescimento terá de ser

interrompido em algum momento, devido a congestionamento da rede ou capacidade do receptor.

q Para isso é usado o parâmetro de threshold.

q Vejamos como...

Threshold q Controle de congestionamento TCP utiliza um

terceiro parâmetro limitante: threshold. •  Também chamado de “limiar” ou “patamar”.

q  Threshold → definido inicialmente como 64KB.

•  O crescimento exponencial é interrompido quando o threshold é alcançado.

•  Então o crescimento passa a ser linear. •  Quando atingir o threshold, a variável congwin

passa a aumentar de 1 MSS para cada rajada.

Threshold e o timeout

q  Quando há um timeout, o threshold é atribuído à metade da janela de congestionamento atual, e a janela de congestionamento é reinicializada para 1 MSS.

q  O algoritmo reduz o tamanho da janela de congestionamento à metade, e depois retoma seu crescimento a partir daí.

(Ficará mais fácil de entender no gráfico a seguir)

TCP: Evitar Congestionamento (1)

(3) Quando há timeout, congwin

volta para 1 MSS, e threshold cai pela

metade

timeout

(2) Quando atinge threshold, o

crescimento passa a ser linear

(fase de “prevenção de congestionamento”)

(2.1) Quando atinge o threshold o aumento é de um segmento máximo para cada rajada em vez de um para cada segmento.

(1) Fase de “partida lenta”

TCP: Evitar Congestionamento (2) Evitar congestionamento /* partida lenta acabou */ /* Congwin > threshold */ Until (event de perda) { cada w segmentos reconhecidos: Congwin++ } threshold = Congwin/2 Congwin = 1 faça partida lenta.

timeout

Comportamento do TCP Congestion Control

1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0

Time(seconds)

304050

Exercício – TCP Reno x TCP Tahoe:

q Existem diferentes implementações de controle de congestionamento. 1.  Estudar a diferença entre “TCP Reno” e “TCP

Tahoe”.

2.  Entender a diferença entre retransmissão rápida (Fast Retransmit) e recuperação rápida (Fast Recovery). •  Responda: como isso isso impacta o controle de

congestionamento?

Justeza do TCP Meta de justeza: se N sessões

TCP compartilham o mesmo enlace, cada uma deve ganhar 1/N da capacidade do enlace.

q  Desconsiderando a fase de partida lenta: TCP usa “AADM”: •  Aumento Aditivo,

Decremento Multiplicativo

•  Aumenta janela em 1 a cada RTT.

•  Diminui janela por fator de 2 quando um evento de perda acontece.

AADM / Additive-Increase, Multiplicative-Decrease (AIMD)

TCP conexão 1

Roteador gargalo

capacidade R

TCP conexão 2

ECN - Explicit Congestion Notification flags (RFC-3168)

•  NS (1 bit): ECN-nonce concealment protection (*) experimental: see RFC 3540. •  CWR (1 bit): Congestion Window Reduced (CWR) flag is set by the sending host to

indicate that it received a TCP segment with the ECE flag set and had responded in congestion control mechanism (added to header by RFC 3168).

•  ECE (1 bit): ECN-Echo has a dual role, depending on the value of the SYN flag:

•  If the SYN flag is set (1), that the TCP peer is ECN capable. •  If the SYN flag is clear (0), that a packet with Congestion Experienced flag set

(ECN=11) in IP header was received during normal transmission (added to header by RFC 3168). This serves as an indication of network congestion (or impending congestion) to the TCP sender.

(*) O “NS” ainda é experimental e não aparece em algumas representações

https://www.icir.org/floyd/ecn.html

ECN - Explicit Congestion Notification flags

167 (*) O “NS” ainda é experimental e não aparece em algumas representações

Capítulo 3: Sumário q  Princípios associados aos serviços da camada

de transporte: •  Multiplexação /

desmultiplexação

•  Transferência confiável de dados

•  Controle de fluxo •  Controle de congestionamento

q  Instanciação e implementação na Internet. •  UDP

•  TCP Próximo capítulo: q  Saímos da “borda” da rede

(camadas de aplicação e transporte).

q  Entraremos no “núcleo” da rede.

Curso de Redes de Computadores - angel.acmesecurity.orgadriano/aulas/redes/2017/Redes1/... · •...

Documents

Transcript of Curso de Redes de Computadores - angel.acmesecurity.orgadriano/aulas/redes/2017/Redes1/... · •...

Redes Redes ÓÓpticas Redes Ópticas MetroMetro -Acesso ...rudge/pdf/IE309-d1_RedOptAcess=f219_vrF.pdf · Redes Redes ÓÓpticas MetroMetro -Acesso =Parte 1= Maio 2019 Redes Ópticas

Redes de Computadores 1 Parte IV - gta.ufrj.brmiguel/docs/redes1/aula4-6f.pdf · – Serviço provido pela camada física não garante que o fluxo de bits seja livre de erros •

Protocolos de Acesso ao Meio - midiacom.uff.brdebora/redes1/pdf2/04_redes1.pdf · protocolo de acesso. ... Passagem de Permissão - Token Passing O token ... permissão livre O momento

CIÊNCIA DA COMPUTAÇÃO – REDES DE COMPUTADORES – UTP – 2003 1/4/2014 14:23Professor Roberto Amaral – Serviços de Redes1 Arquitetura.

Programação Introdução - angel.acmesecurity.orgadriano/lc/2009/6-LC-quimica-2009... · Compiladores e interpretadores (1) • Para que um computador possa "entender" um programa

Cursos de Ciência da Computação – Redes de Computadores – Serviços de Redes - 2003 27/07/03 13:58Professor Roberto Amaral – Serviços de Redes1 Emulador.

Adriano Mauro Cansian Redes de Computadoresadriano/aulas/redes/2017/Redes1/re… · Curso de Redes de Computadores Aula Inaugural 2008 Prof. Dr. Adriano Mauro Cansian 3 unesp - IBILCE

Redes de Computadores 1 - GTA / COPPE / UFRJmiguel/docs/redes1/aula5.pdf · • Protocolo de enlace usado em linhas ponto-a-pontona Internet – Mais simples que o HDLC • Orientado

O ETANOL E SUAS REDES1 - pressfolios-production.s3 ... · O ETANOL E SUAS REDES1 ... o nosso trabalho visa tecer a rede de atores ... O documento mais expressivo desta mediação

Linguagem Computacional - angel.acmesecurity.orgadriano/aulas/lc/2015/4-algoritmos... · 1 - Algoritmos Prof. Dr. Adriano Mauro Cansian 2 Noções de Lógica ! Lógica: estudo filosófico

Disciplina: Redes de Computadores I - Laboratório Mídiacomdebora/redes1/pdf2/05_redes1.pdf · Rede sem Fio Ad-Hoc E-1 E-2 BSS = ESS BSA (Basic Service Area) = célula BSS (Basic

Curso de Redes de Computadores - angel.acmesecurity.orgadriano/redes/2011/net-adr-2011... · Executar algoritmos e protocolos de roteamento • RIP, OSPF, BGP, dentre outros. ...

Arquitetura de Redes de Computadores – Luiz Paulo Maia Camada de Redes1 Arquitetura de Redes de Computadores Luiz Paulo Maia Camada de Redes.

Redes de Computadores 1 - GTA / COPPE / UFRJmiguel/docs/redes1/aula4.pdf · Exemplo de contagem de caracteres (fonte: Tanenbaum) EEL878: Redes de Computadores 1 – Del-Poli/UFRJ

2015 - Federal University of Rio de Janeiro › ensino › eel878 › redes1-2015... · [3] Kurose, J., Information-centric networking: The evolution from circuits to packets to content.

IPv6 - angel.acmesecurity.orgadriano/aulas/redes/2016/Redes-II/... · Limite de Encaminhamento (Hop Limit): Tem 8 bits de comprimento. Define o limite máximo de roteadores pelos

Administração Central - CESUfatecbauru.edu.br/assets/upload/curso/06301-redes1.pdf · que aprova, em extrato, o Catálogo Nacional dos Cur sos Superiores de Tecnologia (CNCST).

Redes de Computadores 1 - GTA / COPPE / UFRJmiguel/docs/redes1/aula3.pdf · – Redes terrestres sem-fio – Satélite – Raios laser transmitidos pelo ar EEL878: Redes de Computadores

Linguagem Computacional - angel.acmesecurity.orgadriano/aulas/lc/2016/5-estruturas... · 2 3 1. Estrutura de Controle: Seleção n Permite escolher uma ou mais ações. • Determina

Redes Wireless - angel.acmesecurity.orgadriano/aulas/redes/2016/Redes-II/... · Introdução Não possuem cabos! Meio de transmissão não guiado Possibilita todo um hall de novas