Curso de Redes de Computadores - angel.acmesecurity.orgadriano/aulas/redes/2016/Redes-I/3... ·...

UNESP - IBILCE - SJRP - Curso de Redes de Computadores Capítulo 3

Prof. Dr. Adriano Mauro Cansian 1

unesp - IBILCE - SJRP

1

Curso de Redes de Computadores

Adriano Mauro Cansian

[email protected]

Capítulo 3 Camada de Transporte


2

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 !

3

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


4

Comparação entre as camadas

Camada Transporte à processos •  Protocolo da Camada de Transporte fornece

comunicação lógica entre processos, rodando em hosts diferentes (peer process).

Camada de rede à hosts •  Protocolo da Camada de Rede fornece comunicação

lógica entre hosts.

Camada de transporte repousa exatamente sobre a camada de rede.

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




5

Camada de Transporte X Camada de Rede (1)

q Exemplo: •  10 irmãos numa casa em São Paulo, SP. •  e 10 irmãos em outra casa em Manaus, AM. •  Os de SP são primos daqueles em Boa Vista. •  Escrevem cartas entre SP e AM semanalmente.

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.

q  Também recebem e fazem a distribuição local das cartas que chegam.


Correio

6

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

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




Correio

7

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

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


8

Camada de Transporte X Camada de Rede (2)

q  Hosts (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).




9

Serviços e protocolos de TRANSPORTE (1)

q  comunicação lógica entre processos de aplicação executando em hosts diferentes.

q  Protocolos de transporte rodam em sistemas finais.

•  Camada de rede: dados transferidos entre hosts.

•  Camada de transporte: dados transferidos entre processos.

aplicação transporte

rede enlace física

rede

enlace física


rede enlace física

rede

enlace física

rede

enlace física

rede

enlace física

rede

enlace física


10

Serviços e protocolos de TRANSPORTE (2)

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

•  Mesmo que existam vários roteadores, links e outros equipamentos no caminho.

q A Camada de Aplicação não tem que se preocupar com a infra-estrutura de interligação, usada para carregar as mensagens.




11

Protocolos da camada de transporte

Dois Serviços de transporte na Internet:

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

•  Controle Congestionamento.

•  Controle de fluxo.

•  Estabelecimento de conexão (setup).

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


rede enlace física

rede

enlace física


rede enlace física

rede

enlace física

rede

enlace física

rede

enlace física

rede

enlace física


Fluxo de encapsumaneto

12




Fluxo de desencapsulamento

13


14

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

processos de aplicações, encapsulando dados com cabeçalho (usado depois para demultiplexação).


rede

M P2 aplicação

transporte rede

receptor

HtHn segmento

segmento M aplicação

transporte rede

P1 M

M M P3 P4

cabeçalho de segmento

dados da camada de aplicação




15

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

processos de aplicações, envelopando dados com cabeçalho (usado depois para demultiplexação).

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


rede

M P2 aplicação

transporte rede

receptor

HtHn segmento


transporte rede

P1 M

M M P3 P4




16


rede

M P2 aplicação

transporte rede

Multiplexação/desmultiplexação (2)

q  Segmento - Unidade de dados trocada entre entidades da camada de transporte. •  Ou TPDU- Transport protocol Data Unit, ou 4-PDU (PDU da

camada 4). •  No exemplo abaixo: P1 com P3, e P2 com P4.

receptor

HtHn segmento


transporte rede

P1 M

M M P3 P4






17

Multiplexação/desmultiplexação (3)

Multiplexação/demultiplexação: 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


18

estação A

Multiplexação/desmultiplexação: exemplos servidor

B porta orig.: x

porta dest: 23

porta orig:23 porta dest: x

uso de portas: aplicação telnet

Cliente WWW estação A

servidor WWW B

Web client host C

IP orig: C IP dest: B

porta orig: x porta dest: 80

IP orig : C IP dest: B

porta orig: y porta dest: 80

Uso de portas : servidor WWW

IP orig: A IP dest: B

porta orig: x porta dest: 80




19

UDP: User Datagram Protocol [RFC 768] q  Protocolo de transporte da

Internet “mínimo”. q  Best Effort: Serviço “melhor

esforço”, resulta que segmentos UDP podem ser: •  Perdidos. •  Entregues à aplicação fora

de ordem de envio. q  Sem conexão:

•  Não há “setup” UDP entre remetente e receptor.

•  Tratamento independente de cada segmento UDP.

Por quê existe um UDP? q  Elimina estabelecimento de

conexão (o que pode causar retardo).

q  Simples: não se mantém “estado” da conexão no remetente/receptor.

q  Pequeno cabeçalho de segmento. Mais simples.

q  Sem controle de congestionamento: UDP pode transmitir o mais rápido possível.


20

Mais sobre UDP

q  Muito utilizado para aplicações de meios contínuos (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




21

Checksum UDP

Emissor: q  Trata conteúdo do segmento

como seqüência de inteiros de 16-bits.

q  Campo checksum zerado. q  Checksum: soma (adição

usando complemento de 1) do conteúdo do segmento.

q  Emissor coloca complemento de um do valor da soma no campo checksum de UDP .

q  Envia...

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

segmento recebido, incluindo o valor 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 computado é todo igual a 1: •  NÃO - erro detectado. •  SIM - nenhum erro detectado. •  Mas ainda pode haver erros?

(Veremos mais adiante ….)

Meta: detectar falha no segmento transmitido.


22

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 !

soma

0011010100110101




23

Lembrete 1: método Polinomial


Lembrete 2: “carry”

24




25


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 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 ??


26


Assim o complemento de 1's da soma 1100101011001010

é 0011010100110101

q  Este valor se torna o checksum.




Pseudo Header (1)

q O UDP (assim como o TCP) usa um pseudo header no cálculo do checksum, com informações do 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 “pad” de zeros , no final, se

necessário. •  Pad não é transmitido.

27


Pseudo Header (2)

28

Pseudo header IP (usado pelo UDP)

(16 bytes)

Header UDP (8 bytes)

Violação da independência das camadas. Pergunta-se: Por quê ?




29

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

Reliable Data Transfer (RDT)


30

Princípios de Transferência confiável de dados Reliable Data Transfer (RDT) q  Importante nas camadas de transporte e também de enlace. q  No topo da lista dos 10 tópicos mais importantes em redes!

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




31

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.

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

à camada superior receptora


32

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 idéias 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. •  É como o TCP evoluiu.

33


34

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




35

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,

propagado ou “bufferizado”, inverte um 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.


36

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

•  O checksum UDP pode detectar erros de bits.

q A questão é: como recuperar dos erros? •  Boa idéia: usar mensagens de controle. •  Confirmação (ACK): receptor avisa explicitamente

ao remetente que pacote chegou bem. •  Confirmação negativa (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 )




37

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


38

Novas capacidades em RDT 2.0

q  Três capacidades adicionais são exigidas em protocolos de ARQ para lidar com a presença de erros de bits: •  Detecção de erros: mecanismo para permitir que o

receptor identifique quando erros de bit ocorreram. •  Realimentação (feedback) pelo receptor:

mensagens de controle (ACK, NAK) trocadas entre receptor e o emissor.

•  Retransmissão: para corrigir os erros detectados.

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




39

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)

12

3


40

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.




41

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

FSM do remetente FSM do receptor


42

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

FSM do remetente FSM do receptor




Mas o RDT 2.0 tem uma falha fatal...

43


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!

44




45

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 recebido com erro.

q  Receptor descarta pacote duplicado.

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

Stop and wait


46

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

1

2

3

4




47

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

1

2


48

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)

•  Estado deve “lembrar” se o pacote “atual” tem No. de sequência 0 ou 1.

•  Aqui surge uma das primeiras características do TCP: manutenção de status (statefull protocol).




49

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.


50

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




51

RDT 3.0: canais com erros e perdas (1)

q 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? •  Ou seja, 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.


52

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

q Abordagem: remetente aguarda um determinado tempo pelo ACK em trânsito.

q Exige uso de temporizadores (timers). •  Timeout à esgotamento do timer. •  Retrasmisão ocorre se nenhum ACK recebido neste tempo.

q  Se pacote (ou ACK) está apenas atrasado (não perdido): •  A retransmissão será duplicada.

•  Mas 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.




53

RDT 3.0: EMISSOR

Esgotou o timer: reenvia o anterior

Inicia o timer e aguarda o ack


54

RDT 3.0 em ação (1)




55

RDT 3.0 em ação (2)

Descarta pkt1 duplicado


RDT – últimas palavras

q Aqui terminamos os estudos da criação dos protocolos RDT e das idéias que deram origem a eles.

q Eles serão a base para o TCP, mas ainda não são o TCP.

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

q É importante que, neste ponto, você tenha entendido bem as idéias do RDT, para poder prosseguir.

56




57

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, ainda não confirmado.

58




59

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

•  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 33kByte/seg num enlace de 1 Gbps !

Protocolo limita uso dos recursos físicos!

Tempo de ida e volta = 30 ms + 16 microseg


60

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

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

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




61

GBN - Go Back N (1)

q Também conhecido como “Volta-N”. q Emissor: pode enviar múltiplos pacotes,

sem aguardar ACK do receptor. q Entretanto:

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


62

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)

[nextseqn, send_base + N - 1] = Disponíveis para serem usados imediatamente, assim que dados chegarem da camada superior (azul). Sequence number ≥ (base + N) : não podem ser usados até que um pacote não confirmado que esteja atualmente no duto tenha sido confirmado.

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




63

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 seqüê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 ?


64

GBN: FSM estendida do EMISSOR 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.

1

2 3




65

GBN: FSM estendida do EMISSOR

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


66

GBN: FSM estendida do EMISSOR

• 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




67

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


68

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.




69

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).


70

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.




71

Repetição Seletiva


72

Repetição seletiva q  Evita retransmissões desnecessárias.

•  O emissor retransmite apenas os pacotes que ele suspeita terem sido recebidos com erro pelo receptor.

q  Receptor confirma individualmente todos os pacotes recebidos corretamente. •  Armazena pacotes no buffer, conforme necessário, para

posterior entrega em ordem à camada superior.

q  Emissor apenas re-envia pacotes para os quais o ACK não foi recebido. •  Complica um pouco:

•  Timer de EMISSOR para cada pacote sem ACK.

q  Janela do emissor •  N números de sequência consecutivos. •  Outra vez limita Nos. de seqüência de pacotes enviados, mas

ainda não reconhecidos.




73

Repetição seletiva: janelas de remetente e receptor

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

da janela.


74

Repetição seletiva no EMISSOR

q  Dados recebidos de acima: O emissor verifica o próximo número de sequência disponível para o pacote. •  Se o número 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.

q  ACK recebido: Se um ACK for recebido, o 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.




75

Repetição seletiva: janelas de remetente e receptor

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

da janela.


76

Repetição seletiva no receptor (1) q  Pacote com número de seqüência no intervalo

[ rcv_base, rcv_base+N-1] é recebido corretamente: •  Neste caso, o pacote recebido cai dentro da janela do receptor e um

pacote seletivo de ACK é 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 pelo número total dos pacotes entregues à camada superior.

q  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.

q  Caso contrário: Ignora o pacote.




77

Repetição seletiva no receptor (2)

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

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

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.


78

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

79

Tim

eout

pkt

2

perde pkt2

buferizados Janela se move depois de

recebidos ack0 e ack1


Retransmissão seletiva em ação

80

Tim

eout

pkt

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

81


82

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.) !!! q  Ele incorretamente

entrega dados duplicados como sendo novos no caso (a.) acima.

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

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




O TCP

A implementação do TCP

83


84

TCP: Visão geral (1) RFCs: 793, 1122, 1323, 2018, 2581 q É Peer-to-Peer (P2P):

•  Único emissor transmite para um único receptor.

q Fornece fluxo de bytes ordenados e confiável: •  Não estruturado em mensagens.

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.

socketdoor

TCPsend buffer

TCPreceive buffer

socketdoor

segment

applicationwrites data

applicationreads data




85

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


86

TCP: estrutura do segmento

No. porta origem No. porta dest

32 bits

dados da aplicação

(tamanho variável)

número de seqüência 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 é representa o tamanho total do frame TCP.

q  Reservado é um campo ainda não utilizado.

q  FLAGS identifica as flags especiais de operação (S-syn, F-fin, P-psh, R-rst, A-ack, U-urg)

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).


88

TCP: Gerenciamento de Conexões




89

TCP: Gerenciamento de Conexões (1)

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

q  Conexão é 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

exemplo RcvWindow) e temporizador. q  Cliente: é aquele que inicia a conexão.

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

•  Passive Open.


90

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

(1): Cliente envia segmento de controle SYN do TCP ao servidor. •  Bit SYN do TCP é ajustado como 1. (SYN=1; ACK=0) •  Cliente especifica No. de Seqüência inicial.

(2): Servidor recebe SYN, responde com segmento de controle SYN-ACK

•  Ajusta SYN=1 E ACK=1 (SYN=1; ACK=1)

•  Confirma SYN recebido. •  Aloca buffers, especifica No. seq. inicial de servidor para o

receptor. (3): Cliente recebe SYN=1; ACK=1, e responde com segmento de

controle ACK e começa a enviar dados. (SYN=0; ACK=1)




91

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




93

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

tempo

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 ? •  Ou seja, uma “duplicata de ACK”, que “re-

reconheça” um segmento para qual o emissor já tenha recebido ACK anteriormente.

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

94




Transferência confiável de dados no TCP

q  TCP cria serviço rdt sobre o serviço não confiável do IP.

q  Segmentos enviados em paralelo (pipeline).

q  ACKs cumulativos. q  TCP usa único

temporizador de retransmissão.

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

q  Inicialmente, considera remetente TCP simplificado: •  Para entender: Ignorar

controle de fluxo, controle de congestionamento.

•  Serão vistos mais adiante.


Eventos de remetente TCP: q  Dados 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 temporizador, se ainda não tiver iniciado (pense nele como o timer para o segmento mais antigo sem ACK)

q  Intervalo de expiração: TimeOutInterval

EVENTOS: Timeout: q  Retransmite segmento

que causou timeout q  Reinicia temporizador ACK recebido: q  Reconhecem-se

segmentos sem ACK anteriores •  atualiza o que

sabidamente tem ACK •  inicia temporizador se

houver segmentos pendentes




97

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


Hosp. A

Seq = 100, 20 bytes dados

ACK = 100

tempo

Timeout prematuro

Hosp. B


ACK =

120


Seq

= 92

tim

eout

ACK =

120

Hosp. A


ACK = 100

loss

tim

eout

Cenário de ACK perdido

Hosp. B

X


ACK =

100

tempo

Seq

= 92

tim

eout

SendBase = 100

SendBase = 120

SendBase = 120

Sendbase = 100





Host A


ACK = 100

perda

tim

eout

Cenário ACK cumulativo

Host B

X


ACK =

120

tempo

SendBase = 120

Chegada dentro do timer: indica que B

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

aguardando o 120



100

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: •  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.


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: •  Ele assume que foi perdido o segmento em

seguida ao segmento que foi confirmado 4 vezes.

•  Neste caso, o TCP executa uma retransmissão rápida.

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

•  [RFC 2581].

102




Entendendo os 3 “ACKs duplicados” (1)

103

ACK xxxxxxx523

ACK xxxxxxx523

ACK xxxxxxx523

ACK xxxxxxx523 Ain

da n

ão

ocor

reu

timeo

ut

1o. ACK duplicado

2o. ACK duplicado

3o. ACK duplicado

Tim

er

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


Hosp. A

tim

eout

Hosp. B

tempo

X

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

106

" 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




107

Resposta de ACKs no TCP [RFCs 1122, 2581]

Evento Ação do receptor TCP

Chegada do segmento em ordem, com número de seqüência previsto: todos os dados até o No. de seq. previsto já reconhecidos; nenhum “buraco” nos dados recebidos.

Promove ACK atrasado ! Espera até 500ms pela chegada de um outro segmento em ordem. Se o próximo segmento não chegar em ordem neste intervalo, emita um ACK do anterior.

Chegada de um segmento em ordem com número de seqüência previsto. Um outro segmento em ordem aguardando transmissão de ACK. Nenhum “buraco” nos dados recebidos.

Emita imediatamente um único ACK cumulativo. Confirmando ambos os segmentos em-ordem.

Chegada do segmento fora de ordem com número de seqüência mais alto do que esperado ! detectada falha na sequência.

Emita imediatamente o ACK duplicado, indicando o número de seqüência do próximo segmento esperado.

Chegada de segmento que completa parcial ou completamente uma falha nos dados recebidos.

Emita imediatamente o ACK, contanto que o segmento comece no fim mais baixo da falha.


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.




109

TCP: Fechando uma Conexão (1)

Encerrando uma conexão:

Passo 1: cliente envia segmento de controle FIN ao servidor.

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

( Segue.... → )

cliente

FIN

servidor

ACK

ACK

FIN

fechar

fechar

fechada

espe

ra

tem

pori

zada


110

TCP: Fechando uma Conexão (2)

Passo 3: cliente recebe FIN, responde com ACK.

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

Step 4: servidor, recebe ACK. Conexão encerrada.

cliente

FIN

servidor

ACK

ACK

FIN

fechando

fechando

fechada

espe

ra

tem

pori

zada

fechada




111

TCP: Ciclo de vida do SERVIDOR

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


112

TCP: Ciclo de vida do CLIENTE

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




113

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


TCP: RTT e timeout

-  Retransmissão adaptativa. -  Outros timers.

114




RTT e timeout do TCP (1)

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

•  Mas RTT varia 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)? q  SampleRTT: tempo medido da transmissão do segmento até receber o ACK.

•  Ignora retransmissões. q  Assim, o SampleRTT vai variar. q  Mas é bom que o RTT estimado seja “mais estável”.

•  Usa-se a média de várias medições recentes, e não apenas SampleRTT atual.


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

❒ Média móvel exponencial ponderada. ❒  Influência da amostra passada diminui

exponencialmente rápido. ❒  Dá mais valor (peso) às medidas mais recentes.

❒  Valor típico: α = 0,125 (determinado empiricamente)





Relação entre RTT amostra e RTT estimado


O Timeout é definido da seguinte maneira: q  EstimtedRTT mais “margem de segurança”

•  Se há grande variação em EstimatedRTT oferece maior margem de segurança.

q  Primeira estimativa do quanto SampleRTT se desvia de EstimatedRTT:

TimeoutInterval = EstimatedRTT + 4*DevRTT

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

e depois definir intervalo de timeout:


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




119

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 (já visto) •  Timer de Persistência. •  Timer Keep-alive. •  Timer Time-wait.


120

Temporizador de persistência

q Temporizador de persistência: •  Para evitar impasse.

•  Receptor envia pacote de tamanho de janela 0, pedindo para emissor aguardar.

•  De tempos em tempos o emissor faz um teste para ver se pode enviar (devido a risco de perda do pacote de atualização do receptor)




121

Temporizador 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á.


122

Temporizador Time Wait

q  Temporizador time wait (“tempo de espera”): •  É usado durante o encerramento de uma

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

123


MSS (Maximum Segment Size)

q O MSS representa o tamanho do maior bloco de dados que o TCP permite enviar num único segmento para o destino.

q Para a maioria dos computadores o MSS é ajustado automaticamente pelo sistema operacional. •  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. •  Desde que não ocorra fragmentação.

(Trataremos fragmentação no protocolo IP; associado ao MTU)

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

•  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.


126

MSS e numeração de segmentos

Aplicação quer enviar 500.000 bytes de dados, Em 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




127

Controle de FLUXO no TCP


128

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.




129

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

espaço livre disponível (que muda dinamicamente). •  Campo RcvWindow (janela) no segmento TCP .

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)


130

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

Kb.

(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




131

Controle de Congestionamento


132

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.

133


134

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

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

perda. ❒  Depois diminui taxa de transmissão.

❒  Aumentar com ACK e diminui 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

X

X X

X perda e diminuição de taxa

taxa

de

emis

são

tempo

comportamento “dente de serra”

do TCP


136

O que o TCP faz para evitar congestionamentos:

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

q  O receptor pode especificar 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 e les a inda podem ocor re r dev ido a

congestionamentos internos na rede.




137

TCP: Controle de Congestionamento (1)

q Deve-se entender que existem dois problemas potenciais: •  Capacidade do receptor. •  Capacidade da rede.

→ 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


138

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:

!LastByteSent - LastByteAcked ≤ min{CongWin, RcvWin}!

!




139

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....


140

TCP: Controle de Congestionamento

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

Exemplos: q 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.

q 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.




141

Como funciona o controle:

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...

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 à isso causa congestionamento.

•  Quando houver perdas: diminuir Congwin.

•  Depois volta a à sondagem (aumentando) novamente.


142

Partida lenta e sondagem do congestionamento (1)

q Conexão é estabelecida → transmissor ajusta a variável congwin (janela de congestionamento) igual ao MSS. •  Em seguida, ele envia este segmento máximo. •  Se esse segmento for confirmado antes de

ocorrer um timeout, então o transmissor: •  Adicionará o número de bytes de 1 segmento na

janela de congestionamento, de modo que ela tenha capacidade equivalente a 2 segmento máximos.

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




143

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).


144

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

RTT

Estação B

tempo

dois segmentos

quqtro segmentos

Veremos o que é isso a seguir...




Comportamento do TCP Congestion Control

145

60

20

1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0

Time (seconds)

70

304050

10


Quando parar o crescimento?

q Mas, quando parar o crescimento ? q 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...

146




147

Threshold

q Algoritmo de controle de congestionamento TCP → utiliza um terceiro parâmetro limitante: o 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 um MSS para cada rajada.


148

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í.




149

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”


150

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




Exercício – TCP Reno x TCP Tahoe:

q Existem diferentes implementações de controle de congestionamento.

q Estudar a diferença entre “TCP Reno” e “TCP Tahoe”.

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

151


152

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




153

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/2016/Redes-I/3... ·...

Documents

Transcript of Curso de Redes de Computadores - angel.acmesecurity.orgadriano/aulas/redes/2016/Redes-I/3... ·...