REDES DE COMPUTADORES Camada de Transporte. Alexandre Augusto Giron

Transcrição

1 REDES DE COMPUTADORES Camada de Transporte Alexandre Augusto Giron

2 ROTEIRO Visão geral da camada de transporte Protocolos UDP TCP Princípios do controle de congestionamento

3 A camada de transporte: visão geral Fornecer serviços de comunicação entre processos de aplicação Localizados em sistemas finais diferentes Comunicação lógica e não física

4 Relembrando Camada de Aplicação Pacotes são denominados Mensagens Camada de Transporte Pacotes são denominados...

5 Relembrando Camada de Aplicação Pacotes são denominados Mensagens Camada de Transporte Pacotes são denominados segmentos (mensagens da camada de aplicação quebradas em pacotes menores, com cabeçalho TCP ou UDP)

6 Fluxo geral Lado emissor: quebra as mensagens da aplicação, forma os segmentos envia para a camada de rede Lado receptor: Recebe os segmentos, realiza a montagem dos mesmos e passa para a aplicação

7 Diferença entre a camada de transporte e de rede Camada de transporte: comunicação lógica de processos Porta de origem, e destino Camada de rede: comunicação lógica de hospedeiros Endereço na rede: IP Serviços são independentes Ex: Transporte pode fornecer segurança (criptografia) mesmo que a camada de rede não forneça!

8 Por que camada de transporte? Camada de rede IP: serviço de entrega de melhor esforço Não garante a entrega dos pacotes Não garante a integridade, nem entrega em ordem Qual a responsabilidade da camada de transporte? Ampliar o serviço de entrega IP

9 Multiplexação/Demultiplexação Demultiplexação Entregar os dados da camada de transporte ao socket (porta receptora) Camada de transporte examina cabeçalho do segmento, verifica qual a porta e direciona o segmento ao socket Multiplexação Reunir dados (que podem vir de diferentes portas), encapsular com informações de cabeçalho e passar o segmento pra camada de rede

10 Multiplexação/Demultiplexação Demultiplexação Entregar os dados da camada de transporte ao socket (porta receptora) Camada de transporte examina cabeçalho do segmento, verifica Através qual das a porta e direciona o segmento ao socket Multiplexação portas de origem/destino!!! Reunir dados (que podem vir de diferentes portas), encapsular com informações de cabeçalho e passar o segmento pra camada de rede

11 Números de porta Número de 16 bits 0 a Classificação Portas de 0 a 1023: reservadas ou bem conhecidas (HTTP, FTP...) Portas de 1024 a 49151: portas registradas Xbox game port: 3074 Portas de a 65535: dinâmicas e/ou privadas Mais em: s/service-names-port-numbers/servicenames-port-numbers.xhtml

12 Multiplexação orientada a conexão No TCP, pode-se abrir conexões simultâneas Um servidor http (80) pode aceitar várias conexões Então o socket é identificado por 4 elementos IP de origem Porta de origem IP destino Porta de destino

13 Multiplexação/Demultiplexação orientada a conexão

14 Multiplexação/Demultiplexação orientada a conexão

15 Multiplexação/Demultiplexação Por isso que o TCP usa os quatro campos UDP trabalha de forma diferente Clientes diferentes são direcionados ao mesmo socket Socket UDP 2 elementos: IP destino e porta destino Direciona dois clientes para o mesmo processo Mas o segmento também possui porta de origem e de destino!

16 Protocolos da camada de transporte TCP: Transmission Control Protocol UDP: User Datagram Protocol

17 UDP visão geral Protocolo de transporte simplificado Não possui serviço de conexão Não há apresentação entre o transmissor e o receptor Cada segmento é tratado de forma independente Serviço não confiável de transferência Não garante entrega confiável: pacotes podem ser perdidos Entregues fora de ordem

18 UDP visão geral Então por que usar? Não há estabelecimento de conexão: minimiza atrasos Implementação e modelo simplificado não há estado de conexão Menos informações de cabeçalho UDP mais rápido: Não há controle de congestionamento UDP pode enviar segmentos na taxa desejada (ou possível)

19 TCP visão geral O que o TCP fornece? Serviço orientado para conexão: Aplicações (cliente e servidor) trocam informações de conexão Conexão Full-Duplex Serviço confiável de transporte Dados entregues sem erro e na ordem correta

20 TCP visão geral O que o TCP fornece? Mecanismo de controle de congestionamento Limita a capacidade de transmissão Efeito negativo em aplicações de áudio e vídeo em tempo real Mecanismo de controle de fluxo Compatibilização de velocidade entre origem e destino

21 TCP vs UDP TCP Serviço orientado para conexão UDP Serviço Não orientado para conexão Garante entrega confiável Relativamente mais lento Segmentação e envio em ordem Mecanismo de reenvio de pacotes perdidos Mais robusto Demultiplexação para socket exclusivo Não garante entrega Mais rápido Não garante envio em ordem Não possui mecanismo de reenvio Mais simples Pode realizar demultiplexação de pacotes de um ou mais clientes para o mesmo socket

22 Transporte não orientado para conexão: UDP DNS usa o UDP como protocolo de transporte DNS passa mensagem para o UDP UDP adiciona poucos campos de cabeçalho Envia ao destino (servidor DNS) Se o pacote se perdeu: Tenta o envio a outro servidor DNS Informa a aplicação que não obteve resposta

23 Transporte não orientado para conexão: UDP Qual a vantagem de uma aplicação usar o UDP? Sem atraso de conexão Melhor controle (nível de aplicação) sobre o envio dos dados: Como e quando Pequena sobrecarga de cabeçalho de pacote TCP: 20 bytes por segmento UDP: 8 bytes por segmento

24 Segmento UDP

25 Segmento UDP Cabeçalho: 4 campos de 2 bytes cada Números de porta para a multiplexação Comprimento especifica o tamanho do segmento UDP, em bytes Soma de verificação (checksum): se existem erros introduzidos no segmento Verificação de erros fim a fim

26 Soma de verificação Fluxo geral: Remetente: complemento de 1 da soma das palavras de 16 bits (considerando o vai-um ) Remetente coloca no campo Soma de Verificação Envia o segmento UDP

27 Soma de verificação Fluxo geral: Receptor calcula o valor do checksum do segmento UDP recebido Realiza uma soma com valor do campo de cabeçalho recebido (Soma de verificação) Todos os bits ligados (=1): Não há erros Um bit desligado (=0): erro detectado Algoritmo (e medições) definido na RFC rfc1071.txt

28 Soma de verificação (Exemplo) Suponha três palavras de 16 bits Soma das duas primeiras:

29 Soma de verificação (Exemplo) Suponha três palavras de 16 bits Soma das duas primeiras:

30 Soma de verificação (Exemplo) Soma-se a terceira com o resultado anterior Novo resultado: Vai-um é somado

31 Soma de verificação (Exemplo) Complemento de 1 após as somas: Em vermelho, está o valor do checksum Remetente envia o segmento UDP com o checksum

32 Soma de verificação (Exemplo) No destinatário: Soma das 3 palavras e ao final soma-se o valor do checksum = = (com vai-um )

33 Soma de verificação (Exemplo) No destinatário: Soma das 3 palavras e ao final soma-se o valor do checksum (com vai-um ) = Sem erros! Segmento OK

34 Exercício em sala Calcule o checksum para as seguintes palavras:

35 Transferência confiável com UDP Entrega confiável usando UDP é possível? Sim, se a confiabilidade for embutida na aplicação

36 Princípios da Transferência Confiável Fundamental para muitas aplicações de rede Protocolo de transferência confiável deve fornecer um canal confiável Nenhum dado corrompido Nenhum dado perdido Entregues em ordem Modelo oferecido pelo TCP

37 Princípios da Transferência Confiável Canal confiável: Serviço

38 Princípios da Transferência Confiável Camada de rede pode ser não confiável Exemplo: TCP (confiável) sobre IP (não-confiável) Como implementar esse serviço?

39 Princípios da Transferência Confiável

40 Construindo um protocolo confiável Desenvolver incrementalmente o lado transmissor e o receptor de um protocolo confiável RDT: Reliable Data Transfer Considerar transferência unidirecional de dados

41 Construindo um protocolo confiável Protocolo RDT 1.0: Transferência confiável sobre canal também confiável Transmissor envia dados ao canal subjacente Receptor lê os dados do canal Especificado com Máquinas de Estado Finito

42 Construindo um protocolo confiável: RDT 1.0

43 Construindo um protocolo confiável RDT 1.0 Lado transmissor recebe a solicitação camada de aplicação (rdt_send()) Cria um pacote e o envia para dentro do canal (udt_send(packet)) UDT: não se preocupa com a confiabilidade pois o canal subjacente é confiável Lado receptor recebe o pacote (rdt_rcv(packet)) e passa para a camada superior (aplicação)

44 Construindo um protocolo confiável RDT 2.0 Mas a dificuldade é se o canal não for confiável Solução: Reconhecimentos Positivos ou negativos Três responsabilidades 1. Detecção de erros 2. Realimentação: reconhecimento ao transmissor: ACK ou NAK 3. Retransmissão: um pacote recebido com erro no destinatário é retransmitido

45 Construindo um protocolo confiável RDT 2.0 Lado Transmissor

46 Construindo um protocolo confiável RDT 2.0 Lado Receptor

47 Construindo um protocolo confiável RDT 2.0 A cada envio, o transmissor aguarda resposta positiva ou negativa ACK: envio OK, volta a aguardar dados da aplicação NAK: falha no envio, retransmite o pacote Remetente não envia novos dados até receber confirmação

48 Construindo um protocolo confiável RDT 2.0 O receptor, a cada pacote recebido envia a resposta Positiva, se o pacote foi recebido sem erros, e então extrai os dados Negativa, se o pacote contem erros

49 Construindo um protocolo confiável RDT 2.0 Problema!!! E se houver a resposta (ACK/NAK) estiver corrompida?? Se um ACK ou NAK estiver corrompido, o transmissor não sabe o que realmente aconteceu Pacote foi entregue sem erros ou não?

50 Construindo um protocolo confiável RDT 2.1 Solução: números de sequência Considera que ACK ou NAK podem ser corrompidos, mas não perdidos Utiliza numeração de pacotes Para o protocolo pare e espere : um bit (sequência 0 ou 1)

51 RDT 2.1 (Transmissor)

52 RDT 2.1 (Transmissor) Transmissor realiza a numeração de seus pacotes n de sequência 1 ou 0 neste caso (consideramos apenas pacotes corrompidos, e não perda no canal)

53 RDT 2.1 (Receptor) Porém o receptor deve Verificar se o pacote recebido é ou não uma retransmissão N de sequência

54 RDT 2.1 (Receptor)

55 RDT 2.1 (Receptor)

56 Construindo um protocolo confiável RDT 2.1 Suponha agora que o canal subjacente é completamente não confiável Dados podem ser corrompidos Pode perder pacotes Como detectar perda? E o que fazer?

57 Construindo um protocolo confiável RDT 3.0 Suponha agora que o canal subjacente é completamente não confiável Dados podem ser corrompidos Pode perder pacotes RDT 3.0

58 RDT 3.0 Questões Como detectar a perda de pacotes? Como recuperar Diversas abordagens para lidar com perda de pacotes

59 RDT 3.0 Vamos supor que um pacote Transmitido pelo emissor seja perdido Ou que a confirmação (ACK) enviada pelo destinatário seja perdida Dificuldade em diferenciar: Perda de pacote de um atraso demorado Esperar toda vez pelo atraso máximo?

60 RDT 3.0 Abordagem prática Temporizador: escolha ponderada do tempo que poderia acontecer a perda Se não receber ACK, retransmite Pode acontecer de receber pacotes duplicados rdt 2.1 já resolve (n s sequência)

61 RDT 3.0 Emissor deve: 1. Acionar o temporizador a cada pacote 2. Responder a uma interrupção do temporizador 3. Parar o temporizador

62 RDT 3.0 (emissor)

63 RDT 3.0 (emissor)

64 RDT 3.0 Situações

65 RDT 3.0 Situações Exercícios: 1. E se o ACK for perdido? 2. E se o temporizador estourar antes da confirmação chegar (sem perda)?

66 RDT 3.0 Situações

67 RDT 3.0 Considerações Funciona! Porém o desempenho é sofrível Sem paralelismo (pare-e-espere)

68 RDT 3.0 Considerações Exemplo: Enlace de 1 Gbps (taxa) Atraso de propagação: 15 ms Pacotes de 1KB Tempo:

69 RDT 3.0 Considerações

70 RDT 3.0 Considerações U: fração de tempo que o emissor ficou ocupado Percentual de 0,0266 % de tempo ocupado Vazão do enlace: 8 kb / 30,008 = 267 kbps Usou 267 kbps de 1 Gbps

71 RDT 3.0 Considerações Qual a solução? Substituir modo pare-e-espere por paralelismo Envio de 1 ou mais pacotes sem esperar pelo ACK

72 RDT 3.0 Considerações Consequências do paralelismo N de sequência devem ser ampliados Usávamos apenas 0 e 1 Reserva de buffers para mais de um pacote Abordagens Go-Back-N Repetição Seletiva

73 Go-Back-N Emissor envia múltiplos pacotes sem esperar por reconhecimento (ACK) Limitado a N pacotes (máximo de pacotes não reconhecidos) Conhecido como sliding window (protocolo de janela deslizante)

74 Go-Back-N Definições: N: tamanho da janela Base: n de sequencia do primeiro pacote não reconhecido NextSeqNum: menor n de sequência ainda não utilizado (próximo pacote)

75 Go-Back-N Definições: N: tamanho da janela Base: n de sequencia do primeiro pacote não reconhecido NextSeqNum: menor n de sequência ainda não utilizado (próximo pacote) [0,base-1]: pacotes já enviados e reconhecidos [base,nextseqnum-1] enviados mas sem reconhecimento

76 Go-Back-N

77 Go-Back-N

78 Go-Back-N Número de sequencia possui k bits Assim, a faixa de n s será [0, 2 k - 1]

79 Go-Back-N Fluxo: 1. Chamada vinda de cima 2. Recebimento de um ACK 3. Esgotamento de temporização

80 1 Chamada vinda de cima Emissor verifica se há N pacotes não reconhecidos (janela cheia) Se não estiver cheia Pacote é criado, base e nextseqnum atualizadas Pacote é enviado Se estiver cheia Camada de Aplicação aguarda

81 2 Recebimento de um ACK Reconhecimento cumulativo: Um reconhecimento com n N indica que todos os pacotes até N chegaram Se um reconhecimento estiver faltando, há a retransmissão do pacote ausente e dos seguintes!

82 3 Esgotamento de temporização Se houver esgotamento de temporização Emissor reenvia todos os pacotes que foram enviados mas que ainda não foram reconhecidos

83 No destinatário Se o último pacote (N) for recebido e estiver na ordem Envia um reconhecimento (N) Qualquer outro caso Descarta o pacote Envia o reconhecimento do último pacote que chegou em ordem

84 Go-Back-N (Operação com N=4)

85 Go-Back-N video & applet Funny GBN SkFyRRrI Aplicativo GBN: ortapplets/gbn/gbnindex.html

86 Go-Back-N Desvantagem do GBN: Um pacote errado pode causar retransmissão de vários desnecessariamente Se a probabilidade de erros no canal aumentar, as retransmissões desnecessárias também aumentam

87 Repetição Seletiva (SR) Surgiu para tentar evitar as retransmissões desnecessárias Reconhecimento Individual

88 Repetição Seletiva (SR) Novamente: N: tamanho da janela Diferença para o GBN é que o SR permite pacotes não reconhecidos e reconhecidos dentro da janela

89 Repetição Seletiva (SR)

90 Repetição Seletiva (SR): Fluxo Chamada vinda de cima: Verifica se a janela está cheia, similar ao GBN Reconhecimento Emissor marca o pacote referente ao ACK recebido Se o número for igual ao base, desliza a janela Esgotamento de temporização: Cada pacote tem o seu temporizador

91 SR destinatário Se um pacote anterior não tiver sido recebido, e o subsequente tiver Pacote irá para o buffer Quando o pacote anterior chegar, desliza a janela

92 SR destinatário Note que o SR realiza buffering de pacotes que chegaram no destinatário Se o(s) anterior(es) não chegaram ainda Permite recebimento fora de ordem: diminui a quantidade de retransmissões (comparado ao GBN)

93 SR problema Cenários em que o remetente não sabe se o emissor está enviando um novo pacote ou está retransmitindo

94 SR problema

95 SR problema

96 SR problema Isso ocorre porque a Janela é muito grande Comparada ao intervalo dos n de sequência N=3 [0,1,2,3]: 4 valores para n sequência Então qual deve ser o tamanho de N? Deve ser menor ou igual ao tamanho do intervalo

97 SR applet Aplicativo SR: ansportapplets/sr/srindex.html

98 E o TCP? O protocolo TCP é implementado como um protocolo GBN ou SR??? TCP é híbrido entre GBN e SR Veremos mais adiante!

99 TCP TRANSMISSION CONTROL PROTOCOL

100 TCP Protocolo de transporte confiável Reconhecimentos, retransmissões Temporizador, detecção de erros N s de sequência Orientado a conexão TCP apenas nos sistemas finais!

101 TCP Segmentos TCP

102 TCP Orientado a conexão Ponto a ponto: único remetente e único destinatário Conexão Full-duplex Apresentação de três vias 3-way handshake

103 3-way handshake Introdução 1. Processo cliente envia solicitação 1. Segmento TCP (sem carga útil) 2. Processo servidor responde 1. Confirma conexão com segmento TCP (sem carga útil) 3. Conexão é estabelecida 1. Processo cliente confirma com segmento TCP (pode conter carga)

104 TCP TCP realiza envio de dados com o uso de buffer de envio Tamanho máximo de segmento (Maximum segment size - MSS) Quantidade máxima de dados que pode ser colocada em um segmento Não considera o cabeçalho, apenas dados da aplicação Unidade máxima de transmissão (Maximum transmission unit MTU) Tamanho máximo para garantir que um segmento (que será encapsulado em um datagrama IP) caiba em um quadro da camada de enlace Tamanhos típicos: 1460, 536 ou 512 bytes

105 TCP Buffers de Envio e recepção

106 TCP Quando há um envio grande, o TCP fragmenta o segmento Vários pedaços de tamanho MSS Último pedaço com o tamanho que sobrar

107 Estrutura do segmento TCP Cabeçalho Números de porta (fonte/destino) Soma de verificação Número de sequência / Número de reconhecimento Janela de recepção Comprimento de cabeçalho Campo Opções Campo Flag

108 Cabeçalho TCP

109 Dados do segmento TCP Definido pelo MSS

110 Cabeçalho TCP (Flag) Campo Flag (6 bits) ACK: reconhecimento válido (ou não) RST, SYN e FIN: estabelecimento de conexão PSH: deve passar dados para a camada de aplicação URG: deve passar dados para camada de aplicação marcados com urgência Usa também um ponteiro para indicar o último byte urgente PSH e URG não são muito usados

111 Número de sequência e reconhecimento Dados do cabeçalho muito importantes TCP vê dados da aplicação como uma cadeia de bytes ordenada N s de sequência sobre a cadeia de bytes e não sobre a sequência de segmentos N de sequência para um segmento é o número do primeiro byte do segmento

112 Exemplo A quer enviar dados para B por TCP bytes a serem enviados MSS de 1 KB Quantos segmentos serão construídos? Quais os n s de sequência utilizados?

113 Exemplo bytes a serem enviados MSS de 1 KB # Segmentos: / = N de sequência: 0; 2 N : 1.000; 3 n :

114 Exemplo Lembrando que o n de sequência é inserido no campo de cabeçalho O número inicial nem sempre é 0 Negociado (aleatoriamente) na conexão

115 Exercício Novamente, A deseja enviar dados para B por TCP Dados: 540 bytes MSS: 100 bytes Quantos segmentos serão utilizados? Quais os números de sequência utilizados, considerando início em 0?

116 Exercício Novamente, A deseja enviar dados para B por TCP Dados: 540 bytes MSS: 100 bytes Quantos segmentos serão utilizados? R: 6 540/100 = 5 seg. cheios + 1 com 40 bytes Quais os números de sequência utilizados? R: 1 : 0, 2 : 100; 3 : 200; 4 : 300; 5 : 400; 6 : 500;

117 Número de reconhecimento no TCP Ideia parecida com o n de sequência O n de reconhecimento é dado pelo n de sequência do próximo byte

118 Número de reconhecimento no TCP Suponha que B está enviando para A MSS igual a 536 A recebeu 1 segmento Byte 0 até 535 O número de reconhecimento que A responde é igual a 536

119 Número de reconhecimento no TCP Suponha que B está enviando para A MSS igual a 536 A recebeu 1 e o 3 segmento 1 : Byte 0 a : Byte 1072 a 1607 Como A envia o reconhecimento? A envia reconhecimento duplicado: 536 E o segmento 3? É descartado? Em geral, NÃO Após o segmento 2 chegar, A envia n de reconhecimento igual a 1608 (Próximo faltando)

120 Número de reconhecimento no TCP Nem sempre é enviado um segmento especialmente para cada reconhecimento Há casos que os reconhecimentos pegam carona em segmentos contendo dados Situação conhecida como Piggyback Aproveitando-se mais do serviço Full-duplex

121 Estimativa de RTT e Temporização Retransmissão pode ser necessária Tempo de viagem de ida e volta (RTT) é variável Como definir um temporizador? Se o tempo definido for muito curto? Se o tempo definido for muito longo?

122 Estimativa de RTT e Temporização Retransmissão pode ser necessária Como definir um temporizador? Se o tempo for muito curto Temporização pode ser prematura Retransmissão desnecessária Se o tempo for muito longo Muito tempo ocioso (aguardando reconhecimento) Recuperação lenta

123 Estimativa de RTT e Temporização Como definir um temporizador? Estimativa de RTT SampleRTT: quantidade de tempo entre o envio de segmento até o momento que é recebido o reconhecimento TCP não mede um SampleRTT para cada segmento Mede um por vez : estima para um dos segmentos dentro da janela Também não computa para segmentos retransmitidos Os valores de SampleRTT são variáveis de segmento a segmento?????

124 Estimativa de RTT e Temporização Sim! Congestionamento nos roteadores, atrasos de fila, variações de carga... Para isso, o TCP realiza uma média EstimatedRTT = (1- α) * EstimatedRTT Em geral, α = 0,125 (RFC 2988) + α * SampleRTT

125 Estimativa de RTT e Temporização EstimatedRTT é uma combinação ponderada entre o valor antigo de EstimatedRTT e o novo SampleRTT

126 Estimativa de RTT e Temporização

127 Estimativa de RTT e Temporização DevRTT: armazena as variações de SampleRTT e EstimatedRTT Média ponderada da diferença entre Sample e Estimated Se houver muita variação DevRTT será grande

128 Estimativa de RTT e Temporização Conhecendo os valores Sample, Estimated e DevRTT, qual deve ser utilizado para o Temporizador?? Deve ser maior ou igual ao EstimatedRTT Para evitar retransmissões desnecessárias Mas não pode ser muito maior Recuperação de perdas muito lenta

129 Estimativa de RTT e Temporização Assim, o Temporizador pode ser definido com EstimatedRTT mais uma margem Margem grande quando houver variação Margem pequena quando variação for pequena Temp. = EstimatedRTT + (4*DevRTT)

130 TCP MECANISMOS DE TRANSFERÊNCIA CONFIÁVEL DO TCP

131 Transferência Confiável do TCP Camada de Rede: Protocolo IP Serviço de melhor esforço para entrega Assim, o TCP cria um serviço de entrega confiável Sobre o IP Sem perdas, sem corrompimento e em ordem

132 Transferência Confiável do TCP Usa os princípios do RDT 3.0 Com paralelismo Em geral o TCP usa apenas um temporizador Temporizador não é individual Associado com o segmento mais antigo não-reconhecido

133 Eventos: Transmissão e Retransmissão (1) //Remetente TCP simplificado while (true){... switch (EVENT) EVENT: Dados da aplicação criarsegmentotcp(); if (TIMER not running) starttimer(); passarsegmentoparaip();

134 Eventos: Transmissão e Retransmissão (2) //Remetente TCP simplificado EVENT: Timeout retransmitirsegmento(sendbase); starttimer();

135 Eventos: Transmissão e Retransmissão (3) //Remetente TCP simplificado... } EVENT: ACK recebido do Destinatário com valor X if (x > SendBase) { } SendBase = x; if (Existe segmento ainda não reconhecido) starttimer();

136 Eventos: Transmissão e Retransmissão (3) //Remetente TCP simplificado... EVENT: ACK X if (x > SendBase) { } } Está reconhecendo Um ou mais bytes ainda não reconhecidos SendBase = x; if (Existe segmento ainda não reconhecido) starttimer();

137 Cenários Interessantes Algumas situações no TCP 1 Cenário: Perda do ACK 2 Cenário: ACK atrasado 3 Cenário: ACK cumulativo e Duplicação da temporização

138 Cenários Interessantes: 1 ACK perdido TCP se recupera

139 Cenários Interessantes: 2 - ACK atrasado - Apenas o seg. 92 é retransmitido

140 Cenários Interessantes: 3 Sabemos que o TCP utiliza os valores EstimatedRTT, SampleRTT e DevRTT Mas e na retransmissão? Esses valores não são mais usados O timeout é duplicado!

141 Cenários Interessantes: 3 A cada retransmissão o TCP ajusta o Temporizador ACK cumulativo: Evita a retransmissão de Seq=92!

142 Cenários Interessantes: 3 Se no envio de Seq=92 o temporizador estava em 0,75 s Ao retransmitir, o TCP ajusta para 1,5s Nova retransmissão? 3,0s... O que pode causar a retransmissão?

143 Cenários Interessantes: 3 O que pode causar a retransmissão? Congestionamento na rede! Retransmissão imediata pode piorar a situação Duplicar temporizador: forma simples de controle de congestionamento

144 Retransmissão Rápida O temporizador pode ficar muito longo Atraso na recuperação Solução alternativa: ACK Duplicado Emissor envia vários segmentos Ocorrendo perda, poderão surgir vários ACKs duplicados

145 Retransmissão Rápida Solução alternativa: ACK Duplicado Se o TCP receber 3 ACKs duplicados Assumirá que o segmento foi perdido Retransmissão rápida: antes do temporizador

146 Retransmissão Rápida

147 Para não confundir ACK Duplicado ~ ACK Cumulativo Duplicado: Emissor recebe ACKs com mesmo valor ACK Cumulativo: exemplo Dois segmentos enviados (1 e 2) Destino recebe 1 e 2 Destino envia ACK com valor 2 e 3 Emissor só recebe o ACK com valor 3 ACK com valor 3 acumula o anterior Indica que recebeu os dois segmentos.

148 Transferência confiável do TCP TCP protocolo com paralelismo GBN ou SR? Semelhança com GBN Segmentos não recebem ACK individual, mas recebem ACK cumulativo Diferença básica: TCP (em geral) não descarta pacotes fora de ordem!

149 Transferência confiável do TCP TCP protocolo com paralelismo GBN ou SR? Semelhança com SR Armazena segmentos recebidos fora de ordem Retransmite os pacotes não recebidos RFC 2018: modificação para o TCP Para permitir reconhecimento individual (seletivo)

150 TCP CONTROLE DE FLUXO DO TCP

151 Controle de Fluxo Se a aplicação do lado receptor demorar para ler os dados recebidos Novos envios poderão saturar o buffer de recebimento Controle de Fluxo Compatibilização das velocidades Taxa de envio <= Taxa de leitura

152 Controle de Fluxo Janela de recepção Campo do cabeçalho TCP Noção do espaço livre no buffer do destino

153 Controle de Fluxo Considere que Dados LastByteRead: N do último byte lido no buffer pela aplicação LastByteRcvd: N do último byte recebido no buffer

154 Controle de Fluxo Para o TCP não saturar o buffer LastByteRcvd LastByteRead <= RcvBuffer (tamanho) TCP ajusta a janela de recepção Rwindow = RcvBuffer (LastByteRcvd LastByte Read)

155 Controle de Fluxo 1. A informa a B quanto espaço ele tem disponível em seu buffer 1. Coloca o valor de Rwindow no campo de janela de recepção 2. B estabelece Rwindow = RcvBuffer 2. A monitora duas variáveis (LastByteSent e LastByteAcked) 1. (Último byte enviado e último reconhecido) 3. A mantém a quantidade de dados sempre menor que Rwindow Rwindow >= LastByteSent LastByteAcked

156 Controle de Fluxo: exemplo Considere Buffer de 4 KB negociado Aplicação em A enviará 8 KB para B Quantidade de dados lidos por B: 4 KB

157 Controle de Fluxo: exemplo 8KB de dados Buffer suporta 4KB, RcvBuffer: 4 KB

158 Controle de Fluxo: exemplo Aplicação em A repassa 4 KB para o Buffer de envio

159 Controle de Fluxo: exemplo A pode enviar 4 KB

160 Controle de Fluxo: exemplo Considere envio de 4KB por vez 4096 bytes (0 a 4095) N Seq: 0

161 Controle de Fluxo: exemplo B recebe 4KB Confirma o recebimento, mas informa que o buffer está cheio! Rwindow = 0 ACK = 4096 Rwindow = 0

162 Controle de Fluxo: exemplo Aplicação ainda tem dados, insere no buffer mais 4 KB, mas não pode enviar TCP bloqueia o remetente enquanto B não enviar outro valor de Rwindow!

163 Controle de Fluxo: exemplo Aplicação em B consome os dados do buffer ACK = 4096 Rwindow = 4096

164 Controle de Fluxo: exemplo A pode enviar novos dados 4096 bytes (4096 a 8191) N Seq: 4096

165 Controle de Fluxo: exemplo Novamente, o buffer de B está cheio: Qual o valor de Rwindow?????? ACK = 8192 Rwindow =?????

166 Controle de Fluxo: exemplo Novamente, o buffer de B está cheio ACK = 8192 Rwindow = 0

167 Controle de Fluxo: exemplo A requer novo envio, e novamente o TCP está bloqueando o envio

168 Controle de Fluxo: exemplo B consome os dados

169 Controle de Fluxo: exemplo Confirma que pode receber novos dados ACK = 8192 Rwindow = 4096

170 Controle de Fluxo: exemplo A envia novos dados 4096 bytes (8192 a 12287) N Seq: 8192

171 Controle de Fluxo: exemplo A requer mais um envio B recebe os novos dados e confirma buffer cheio! ACK = Rwindow = 0

172 Controle de Fluxo: exemplo A requer novo envio, e novamente o TCP está bloqueando

173 Controle de Fluxo: exemplo B consome os dados, e aí sim A poderá enviar novamente, mediante confirmação com Rwindow!

174 Controle de Fluxo: exemplo B consome os dados, e aí sim A poderá enviar novamente, mediante confirmação com Rwindow! ACK = Rwindow = 4096

175 Controle de Fluxo: exemplo A realiza seu último envio 4096 bytes (12288 a 16383) N Seq: 12288

176 Controle de Fluxo: exemplo B recebe os dados confirma buffer cheio! ACK = Rwindow = 0

177 Controle de Fluxo: exemplo B consome os dados do buffer envia confirmação A não tem novos dados, então o envio é finalizado. ACK = Rwindow = 4096

178 Controle de Fluxo: exemplo Detalhe: Consideramos que B responde a A em qualquer alteração no buffer Na prática, TCP responde para A apenas quando há segmentos a reconhecer Gera um problema!

179 Controle de Fluxo - Problema Problema: suponha que A acabe de enviar dados, e recebe um Rwindow = 0 Se B não tem mais nada a reconhecer, A ficará bloqueado: nunca será informado que Rwindow mudou de valor A solução é A continuar a enviar dados (1 byte) para B, quando Rwindow = 0

180 Controle de Fluxo Assim, na prática, cada recebimento de um Rwindow = 0 é confirmado Com um novo envio: Segmento Simbólico de 1 byte Assume-se que esse byte não é consumido Assim B irá responder a esses envios

181 Controle de Fluxo na prática A requer mais um envio B recebe os novos dados e confirma buffer cheio! ACK = Rwindow = 0

182 Controle de Fluxo na prática A envia um segmento simbólico com 1 byte a cada Rwindow=0 recebido Até que o buffer esteja disponível novamente. 1 byte N Seq: 12288

183 Controle de Fluxo Applet w_kurose_network_2/applets/flow/fl owcontrol.html

184 Não confunda!!! Controle de fluxo: Compatibilização de velocidades da taxa de envio do emissor com a taxa do receptor Não saturar o buffer do receptor Controle de congestionamento: Congestionamento dentro da rede IP (roteadores...)

185 E no UDP? O que acontece quando temos o UDP?

186 E no UDP? O que acontece quando temos o UDP? Não há controle de fluxo Emissor envia os dados Se o buffer estiver cheio no receptor Pacotes são descartados!

187 Exercício Mostre o passo-a-passo de um envio de dados com controle de fluxo, considerando: Buffer de 8 KB negociado Aplicação em A enviará 16 KB para B Quantidade de dados lidos por B: 8 KB Em algum momento A enviará um segmento simbólico para B? Por que?

188 Exercício 24 KB 16 KB 8 KB RcvBuffer: 8 KB

189 TCP PRINCÍPIOS DO CONTROLE DE CONGESTIONAMENTO

190 Controle de congestionamento Contexto geral Mecanismos vistos até agora não tratam as causas do congestionamento Retransmissão evita perda; mas não trata a causa É necessário regular os emissores (fontes) de dados

191 Controle de congestionamento Contexto geral Causas e custos do congestionamento: 3 cenários Dois emissores, um roteador com buffer de tamanho ilimitado Dois emissores, um roteador com buffer de tamanho limitado Quatro emissores, roteadores com buffers limitados e múltiplos trajetos

192 Cenário 1 Considere 2 hospedeiros enviando dados Cada um com taxa de envio: λ in b/s Suponha que não há controle de fluxo, detecção de erros Despreze carga de cabeçalho e sobrecarga das camadas mais baixas Os pacotes então Passarão por um roteador E por um enlace de saída de capacidade R

193 Cenário 1

194 Cenário 1 O n de bytes/segundo no destinatário é a vazão por conexão Se a taxa de trans. (in) for maior que R/2 A vazão sempre será R/2 Enlace compartilhado!

195 Cenário 1 Mas há um problema: Se a vazão se aproximar de R/2 O atraso médio aumenta exponencialmente Grandes atrasos de Fila! Não há perda: cenário de roteador ilimitado

196 Cenário 2 Considere duas modificações Roteador com buffer limitado As duas conexões são confiáveis

197 Cenário 2

198 Cenário 2 O enlace é compartilhado Se cheio: descarta novos pacotes Outro custo de uma rede congestionada: Perda? Retransmissão de pacotes E se o temporizador estourar prematuramente? Outro custo: retransmissão desnecessária

199 Cenário 3 Considere agora 4 emissores Conexões confiáveis

200 Cenário 3

201 Cenário 3 Conexão A-C

202 Cenário 3 Com o aumento da carga Sempre que um pacote é descartado no segundo roteador (no caso R 2 ) O trabalho realizado por R 1 é desperdiçado Assim Se houve perda em R n, a capacidade de transmissão de R 1... R n-1 foi desperdiçada

203 Abordagens de congestionamento Controle fim-a-fim Rede não oferece suporte explícito à camada de transporte Congestionamento é observado : perda de pacotes na rede Abordagem do TCP Controle assistido pela rede Roteadores fornecem informações sobre o estado da rede Bit único, taxa de transmissão suportada, pacotes de congestionamento

204 Controle de Congestionamento do TCP Ideia geral: 1. TCP obriga a reduzir a taxa de envio em função de congestionamento percebido 2. Se o TCP perceber que a rede se recuperou: aumenta a taxa 3. Se ainda há congestionamento: reduz a taxa

205 Controle de Congestionamento TCP O controle é fim-a-fim Rede IP por padrão não fornece informações de congestionamento Janela de congestionamento Cwindow Ao detectar, limita o envio: LastByteSent LastByteAcked <= min(cwindow, Rwindow) (Último byte enviado último reconhecido)

206 Controle de Congestionamento TCP Janela de Congestionamento, assim como a de Recepção, limita a quantidade de dados enviados 0 16 B 32 B 48 B 64 B Suponha Cwindow= 48

207 Último Byte reconhecido: 31 Último Byte enviado: bytes não reconhecidos 32 <= Cwindow Controle de Congestionamento TCP Janela de Congestionamento, assim como a de Recepção, limita a quantidade de dados enviados 0 16 B 32 B 48 B 64 B Suponha Cwindow= 48

208 Último Byte reconhecido: 31 Último Byte enviado: bytes não reconhecidos 32 <= Cwindow Controle de Congestionamento TCP E se Cwindow= 32, O segmento n 64, neste caso, pode ser enviado? 0 16 B 32 B 48 B 64 B

209 Controle de Congestionamento TCP Mas como detectar congestionamento? Evento de perda Esgotamento de temporização 3 ACKs duplicados no emissor Evento indica congestionamento

210 Controle de Congestionamento TCP Suponha que houve apenas atraso Se os reconhecimentos chegarem a uma taxa relativamente baixa Janela é aumentada a uma taxa baixa Se os reconhecimentos chegarem mais rapidamente A Janela é aumentada a uma taxa mais alta! Por isso, diz-se que o TCP é autorregulado

211 Controle de Congestionamento TCP Algoritmo de controle: três partes 1. Aumento Aditivo, Diminuição Multiplicativa (AIMD) 2. Partida Lenta (Slow Start SS) 3. Reação a esgotamento de temporização

212 TCP AIMD Aumento Aditivo Adiciona 1 MSS para a janela (Cwindow) a cada RTT Crescimento linear Diminuição Multiplicativa Diminui Cwindow pela metade após evento de perda Implica na redução na taxa de transmissão do emissor

213 TCP AIMD

214 Partida Lenta Aumento do AIMD pode ser muito lento Com o Partida Lenta Valor de Cwindow é dobrado a cada RTT Taxa inicial lenta, mas crescimento é mais rápido Se há perda Estabelece um limiar (ssthresh) TCP passa a atuar como AIMD Diminui Cwindow pela metade Novos envios: aumento linear

215 Partida Lenta

216 Controle de Congestionamento do TCP Assim, o TCP inicia com Partida Lenta Crescimento exp. até o limiar Mas usa o AIMD para prevenção de congestionamento Aumento linear Após alcançar o limiar (ssthresh) Ou com 3 ACKs duplicados

217 Controle de Congestionamento do TCP TCP Reno é a versão mais atual

218 Controle de Congestionamento do TCP

219 Controle de Congestionamento do TCP

220 Controle de Cong. do TCP - RESUMO Quando Cwindow está abaixo do limiar TCP Partida Lenta: crescimento exp. Quando Cwindow está acima do limiar Prevenção por AIMD: crescimento linear Com 3 ACKs duplicados Limiar ajustado para Cwindow / 2 Cwindow diminuído pela metade (AIMD) Estouro de temporizador Limiar ajustado para Cwindow / 2 Cwindow = 1 MSS (Partida Lenta)

221 TCP GERENCIAMENTO DA CONEXÃO TCP

222 Conexão TCP Aspecto importante Impacto nos atrasos Alvo de ataques TCP orientado à conexão Apresentação de 3 vias Bits do cabeçalho do TCP utilizado no processo

223 Conexão TCP - 3 etapas 1. Emissor envia um segmento TCP (sem carga útil) com bit SYN ligado Segmento conhecido como SYN. Também insere o n de sequência inicial também no cabeçalho 2. Destinatário extrai o segmento, aloca os buffers e variáveis e envia uma resposta de aceitação (sem carga útil) Bit SYN ligado, ACK ajustado (n sequencia+1) Segmento conhecido como SYNACK 3. Emissor também reserva os buffers e variáveis, ao receber a resposta do destinatário. É enviado mais um segmento, com ACK e SYN desligado, N de sequência + 1 adicionado ao cabeçalho Segmento pode conter carga útil

224 Conexão TCP - 3 etapas

225 Conexão TCP - 3 etapas

226 Conexão TCP Problema: Segurança Um dos ataques mais conhecidos ao TCP Ataque SYN Flood Objetivo de esgotar recursos do destino Denial-of-Service (DoS)

227 SYN Flood Quando o destino recebe uma solicitação Aloca recursos: buffers, variáveis Assim, se um atacante Enviar vários segmentos SYN, sem concluir a conexão (3 etapa) Vários recursos serão alocados, até que haja o esgotamento Novos clientes não conseguirão se conectar

228 SYN Flood É um DoS bem conhecido Outra variação é utilizar-se de vários emissores para o ataque Distributed Denial-of-Service (DDoS)

229 Proteção contra o SYN Flood SYN Cookies Proteção efetiva contra o SYN Flood Mudança na ação tomada pelo destino Recursos não são alocados imediatamente

230 Proteção contra o SYN Flood SYN Cookies Quando o destino recebe um segmento SYN, não aloca os recursos, mas cria um n de sequência inicial, um hash de endereços IP de fonte e de destino e um número secreto O n de sequência criado aleatoriamente é o cookie Assim, se o solicitante for válido, um ACK com valor cookie + 1 será recebido no destino Apenas se o solicitante for válido, o destino criará a conexão aberta No Linux: # echo 1 > /proc/sys/net/ipv4/tcp_syncookies

231 Proteção contra o SYN Flood Mesmo assim, a proteção é difícil Dificuldade em determinar se é um solicitante legítimo ou não Centenas de solicitantes Outras variações desse ataque

232 Conexão TCP Os Processos comunicantes podem encerrar a conexão Recursos liberados Solicitação de qualquer um dos lados da comunicação

233 Conexão TCP Fechamento: Solicitante envia um segmento (sem carga) com bit FIN ligado Destino recebe e reconhece o recebimento (envia segmento com ACK) Destino envia seu segmento de finalização (bit FIN ligado) Solicitante reconhece o segmento recebido

234 Conexão TCP - Fechamento

235 RESUMO Camada de transporte fornece comunicação lógica Multiplexação/Demultiplexação através das portas de origem/destino Dois protocolos de transporte principiais TCP UDP

236 RESUMO UDP Sem conexão, protocolo simplificado Não garante a entrega dos dados Sem controle de fluxo ou congestionamento TCP Orientado a conexão (3 vias) Transferência confiável Controle de fluxo e congestionamento

237 RESUMO: Mecanismos de transferência confiável Mecanismo Descrição Soma de Verificação Detecção de erros de bits de um pacote Reconhecimento Avisa que um ou mais pacotes foi recebido Reconhecimento negativo Avisa a falha no recebimento, nem sempre é utilizado N de sequência Numeração sequencial de pacotes (gaps ou lacunas permitem detecção de perda (ou duplicação) de pacote Temporizador Janela, parelismo Controlar a retransmissão de um pacote, se ele ou o seu ACK foi perdido Restringe o envio simultâneo de pacotes; Paralelismo pode ser adquirido com GBN ou SR

238 RESUMO Controle de Fluxo Rwindow: compatibilização de velocidades Diferente de Controle de Congestionamento Cwindow: limita o envio de acordo com eventos da rede

239 Para Casa Leitura do cap. 3 (Livro do Kurose) Lista de Exercícios 3 (Camada de Transporte)