curso de redes de computadores - angel.acmesecurity.orgadriano/aulas/redes/2017/redes1/... · •...
TRANSCRIPT
unesp - IBILCE - SJRP
1
Curso de Redes de Computadores
Adriano Mauro Cansian
Capítulo 3 Camada de Transporte
unesp - IBILCE - SJRP
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.
2
unesp - IBILCE - SJRP
Cuidado com conceitos !
3
Muito material errado ou ruim na Internet! (apesar de outros muito bons)
unesp - IBILCE - SJRP
4
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.
unesp - IBILCE - SJRP
Correio
5
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
João
Maria
unesp - IBILCE - SJRP
6
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.
unesp - IBILCE - SJRP
Correio
7
Rua dos Bichos, No. 32, 6905-140 Manaus, AM
Rua dos Santos, No. 400, 01419-901, S.Paulo, SP
MANAUS
S.Paulo
unesp - IBILCE - SJRP
8
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).
unesp - IBILCE - SJRP
9
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.
unesp - IBILCE - SJRP
10
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
rede
enlace física
aplicação transporte
rede enlace física
rede
enlace física
rede
enlace física
rede
enlace física
rede
enlace física
unesp - IBILCE - SJRP
11
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.
aplicação transporte
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
unesp - IBILCE - SJRP
Fluxo de encapsumaneto
12
unesp - IBILCE - SJRP
Fluxo de desencapsulamento
13
unesp - IBILCE - SJRP
Encapsulamento / desencapsulamento
14 http://www.gripinit.com/wp-content/uploads/2015/03/UDP-Encapsulation1.gif
unesp - IBILCE - SJRP
15
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
unesp - IBILCE - SJRP
Os protocolos de Transporte
UDP User Datagram Protocol
16
unesp - IBILCE - SJRP
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.
17
unesp - IBILCE - SJRP
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.
18
unesp - IBILCE - SJRP
19
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
unesp - IBILCE - SJRP
Cálculo do Checksun
(válido para o UDP e o TCP)
20
unesp - IBILCE - SJRP
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.
21
unesp - IBILCE - SJRP
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)
unesp - IBILCE - SJRP
Pseudo Header (2)
23
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)
unesp - IBILCE - SJRP
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 ….)
24
unesp - IBILCE - SJRP
Exemplo de cálculo do checksum (3)
25
unesp - IBILCE - SJRP
26
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
unesp - IBILCE - SJRP
27
Exemplo de cálculo do checksum (2)
Assim o complemento de 1's da soma 1100101011001010
é 0011010100110101
q Este valor se torna o checksum.
unesp - IBILCE - SJRP
28
Exemplo de cálculo do checksum (2)
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 ??
unesp - IBILCE - SJRP
29
Lembrete 1: método Polinomial
unesp - IBILCE - SJRP
Lembrete 2: “carry”
30
unesp - IBILCE - SJRP
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
unesp - IBILCE - SJRP
32
Princípios de Transferência Confiável de Dados
Reliable Data Transfer (RDT)
unesp - IBILCE - SJRP
33
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).
unesp - IBILCE - SJRP
34
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
unesp - IBILCE - SJRP
35
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
unesp - IBILCE - SJRP
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.
36
unesp - IBILCE - SJRP
37
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!!
unesp - IBILCE - SJRP
38
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.
unesp - IBILCE - SJRP
39
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?
unesp - IBILCE - SJRP
40
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 )
unesp - IBILCE - SJRP
41
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.
unesp - IBILCE - SJRP
42
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
unesp - IBILCE - SJRP
43
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
unesp - IBILCE - SJRP
44
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.
unesp - IBILCE - SJRP
45
rdt2.0: em ação (sem erros)
FSM do remetente FSM do receptor
unesp - IBILCE - SJRP
46
rdt2.0: em ação (cenário de erro)
FSM do remetente FSM do receptor
unesp - IBILCE - SJRP
Mas o RDT 2.0 tem um problema fatal...
47
unesp - IBILCE - SJRP
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!
48
unesp - IBILCE - SJRP
49
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
unesp - IBILCE - SJRP
50
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
unesp - IBILCE - SJRP
51
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
unesp - IBILCE - SJRP
52
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).
unesp - IBILCE - SJRP
53
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.
unesp - IBILCE - SJRP
54
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
unesp - IBILCE - SJRP
55
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.
unesp - IBILCE - SJRP
56
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.
unesp - IBILCE - SJRP
57
RDT 3.0: EMISSOR
Esgotou o timer: reenvia o anterior
Inicia o timer e aguarda o ack
1
2
unesp - IBILCE - SJRP
58
RDT 3.0 em ação (1)
unesp - IBILCE - SJRP
59
RDT 3.0 em ação (2)
Descarta pkt1 duplicado
Descarta pkt0 duplicado
unesp - IBILCE - SJRP
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
TCP.
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.
60
unesp - IBILCE - SJRP
61
Protocolos “dutados” (pipelined)
unesp - IBILCE - SJRP
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.
62
unesp - IBILCE - SJRP
63
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
unesp - IBILCE - SJRP
64
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).
unesp - IBILCE - SJRP
65
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.
unesp - IBILCE - SJRP
66
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).
unesp - IBILCE - SJRP
67
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)
unesp - IBILCE - SJRP
68
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.
1
2 3
unesp - IBILCE - SJRP
69
GBN: FSM estendida do EMISSOR (2/3)
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
unesp - IBILCE - SJRP
70
GBN: FSM estendida do EMISSOR (3/3)
• 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
unesp - IBILCE - SJRP
71
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
unesp - IBILCE - SJRP
72
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.
unesp - IBILCE - SJRP
73
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).
unesp - IBILCE - SJRP
74
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.
unesp - IBILCE - SJRP
75
Repetição Seletiva
unesp - IBILCE - SJRP
76
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.
unesp - IBILCE - SJRP
77
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.
unesp - IBILCE - SJRP
78
Repetição seletiva: janelas de remetente e receptor
O emissor já terá recebido confirmação para alguns pacotes
da janela.
unesp - IBILCE - SJRP
79
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.
unesp - IBILCE - SJRP
80
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.
unesp - IBILCE - SJRP
81
Repetição seletiva: janelas de emissor e receptor
O emissor já terá recebido confirmação para alguns pacotes
da janela.
unesp - IBILCE - SJRP
82
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.
unesp - IBILCE - SJRP
83
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.
unesp - IBILCE - SJRP
84
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
unesp - IBILCE - SJRP
Retransmissão seletiva em ação
85
Tim
eout
pkt
2 perde pkt2
buferizados Janela se move depois de
recebidos ack0 e ack1
unesp - IBILCE - SJRP
Retransmissão seletiva em ação
86
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.
unesp - IBILCE - SJRP
Repetição seletiva: dilema
87
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?
unesp - IBILCE - SJRP
88
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.
unesp - IBILCE - SJRP
O TCP
A implementação do TCP
89
unesp - IBILCE - SJRP
90
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.
unesp - IBILCE - SJRP
91
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
unesp - IBILCE - SJRP
92
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
unesp - IBILCE - SJRP
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 FLAGS identifica as flags especiais de operação ( U-urg | A-ack | P-push | , R-rst | S-syn | F-fin )
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).
unesp - IBILCE - SJRP
94
TCP: Gerenciamento de Conexões
unesp - IBILCE - SJRP
95
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.
unesp - IBILCE - SJRP
96
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)
unesp - IBILCE - SJRP
97
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.
unesp - IBILCE - SJRP
Estabelecimento da Conexão
Cliente A
Server B
SYN 1415531521:1415531521 (0) <mss 1024>
SYN 1823083482: 1823083482 (0) <mss 1024> ACK 1415531522
.... , ACK 1823083483
unesp - IBILCE - SJRP
Exemplo – captura de pacotes:
99
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
unesp - IBILCE - SJRP
Listen – SYN RCV - Established
100
unesp - IBILCE - SJRP
101
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.
tempo
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…
unesp - IBILCE - SJRP
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...
102
unesp - IBILCE - SJRP
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.
unesp - IBILCE - SJRP
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
unesp - IBILCE - SJRP
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)
unesp - IBILCE - SJRP
106
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
unesp - IBILCE - SJRP
Hosp. A
Seq = 100, 20 bytes dados
tempo
Timeout prematuro
Hosp. B
Seq = 92, 8 bytes dados
Seq = 92, 8 bytes dados
Seq
= 92
tim
eout
Hosp. A
Seq = 92, 8 bytes dados
ACK = 100
loss
tim
eout
Cenário de ACK perdido
Hosp. B
X
Seq = 92, 8 bytes dados
ACK =
100
tempo Se
q =
92 t
imeo
ut
SendBase = 100
SendBase = 120
SendBase = 120
Sendbase = 100
TCP: cenários de retransmissão (2)
unesp - IBILCE - SJRP
Host A
Seq = 92, 8 bytes dados
ACK = 100
perda ti
meo
ut
Cenário ACK cumulativo
Host B
X
Seq = 100, 20 bytes dados
ACK =
120
tempo
SendBase = 120
Chegada dentro do timer: indica que B
recebeu tudo certo, até o 100, e está
aguardando o 120
TCP: cenários de retransmissão (3)
unesp - IBILCE - SJRP
109
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.
unesp - IBILCE - SJRP
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”.
unesp - IBILCE - SJRP
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.
111
unesp - IBILCE - SJRP
Entendendo os 3 “ACKs duplicados” (1)
112
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”.
unesp - IBILCE - SJRP
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)
timer
timer
unesp - IBILCE - SJRP
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
unesp - IBILCE - SJRP
RFC 2581 - TCP Congestion Control
115
" 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
unesp - IBILCE - SJRP
116
Resposta de ACKs no TCP [RFCs 1122, 2581]
unesp - IBILCE - SJRP
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.
unesp - IBILCE - SJRP
118
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
FIN
servidor
ACK
ACK
FIN
fechar
fechar
fechada
espe
ra
tem
pori
zada
1
2
3
4
unesp - IBILCE - SJRP
Half-close captura de pacotes:
119
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
unesp - IBILCE - SJRP
Half-Close / Time-wait detalhado
120
http://www.tcpipguide.com/free/t_TCPConnectionTermination-2.htm
unesp - IBILCE - SJRP
121
TCP: Ciclo de vida do SERVIDOR
Exercício: estudar o ciclo de vida do servidor TCP
unesp - IBILCE - SJRP
122
TCP: Ciclo de vida do CLIENTE
Exercício: estudar o ciclo de vida do cliente TCP
unesp - IBILCE - SJRP
123
Exercício: Estudar as transições de
estado do TCP
unesp - IBILCE - SJRP
124
Exercício: Estudar as transições de estado do TCP
unesp - IBILCE - SJRP
TCP: RTT e timeout
- Timer adaptativo. - Outros timers.
125
unesp - IBILCE - SJRP
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)?
unesp - IBILCE - SJRP
RTT e timeout adaptativo do TCP (2)
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.
unesp - IBILCE - SJRP
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)
RTT e timeout adaptativo do TCP (3)
unesp - IBILCE - SJRP
Relação entre RTT amostra e RTT estimado
unesp - IBILCE - SJRP
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:
RTT e timeout adaptativo do TCP (4)
Exercício: Pesquisar e estudar algoritmo Jacobson / Karels.
unesp - IBILCE - SJRP
131
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.
unesp - IBILCE - SJRP
132
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).
unesp - IBILCE - SJRP
133
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á.
unesp - IBILCE - SJRP
134
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.
unesp - IBILCE - SJRP
MSS e numeração de segmentos
135
unesp - IBILCE - SJRP
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)
unesp - IBILCE - SJRP
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.
unesp - IBILCE - SJRP
138
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
unesp - IBILCE - SJRP
139
Controle de FLUXO no TCP
unesp - IBILCE - SJRP
140
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.
unesp - IBILCE - SJRP
141
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)
unesp - IBILCE - SJRP
142
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
unesp - IBILCE - SJRP
143
Controle de Congestionamento
unesp - IBILCE - SJRP
144
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.
unesp - IBILCE - SJRP
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.
145
unesp - IBILCE - SJRP
146
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.
unesp - IBILCE - SJRP
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
X
X X
X perda e diminuição de taxa
taxa
de
emis
são
tempo
comportamento “dente de serra”
do TCP
unesp - IBILCE - SJRP
148
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.
unesp - IBILCE - SJRP
149
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
unesp - IBILCE - SJRP
150
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}
unesp - IBILCE - SJRP
151
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....
unesp - IBILCE - SJRP
152
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.
unesp - IBILCE - SJRP
153
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.
unesp - IBILCE - SJRP
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..
154
unesp - IBILCE - SJRP
155
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...)
unesp - IBILCE - SJRP
156
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).
unesp - IBILCE - SJRP
157
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...
unesp - IBILCE - SJRP
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...
158
unesp - IBILCE - SJRP
159
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.
unesp - IBILCE - SJRP
160
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)
unesp - IBILCE - SJRP
161
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”
unesp - IBILCE - SJRP
162
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
unesp - IBILCE - SJRP
Comportamento do TCP Congestion Control
163
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
unesp - IBILCE - SJRP
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?
164
unesp - IBILCE - SJRP
165
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
unesp - IBILCE - SJRP
ECN - Explicit Congestion Notification flags (RFC-3168)
166
• 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
unesp - IBILCE - SJRP
ECN - Explicit Congestion Notification flags
167 (*) O “NS” ainda é experimental e não aparece em algumas representações
unesp - IBILCE - SJRP
168
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.