Prof. Evandro Cantú

1. Prof. Evandro Cantú REDES DE COMPUTADORES

2. Prof. Evandro Cantú, Dr. Eng. cantu@sj.cefetsc.edu.br www.sj.cefetsc.edu.br/wiki Slides adaptados de J. Kurose & K. Ross (http://www.aw-bc.com/kurose-ross/), e J. A. Suruagy (http://www.nuperc.unifacs.br/suruagy/redes/index.html) 2 Curso de Capacitação Intelbras Redes Computadores Maio 2007

3. Camada de Transporte • aprender os protocolos da camada de transporte da Internet: • UDP: transporte sem conexão • TCP: transporte orientado a conexões • Controle de congestionamento do TCP Objetivos: • compreender os princípios atrás dos serviços da camada de transporte: • multiplexação/demultiplexação • transferência confiável de dados • controle de fluxo • controle de congestionamento

4. aplicação transporte rede enlace física rede enlace física rede enlace física rede enlace física rede enlace física transporte lógico fim a fim rede enlace física aplicação transporte rede enlace física Serviços e protocolos de transporte • provê comunicação lógica entre processos de aplicação executando em hospedeiros diferentes • protocolos de transporte executam em sistemas finais: • lado transmissor: quebra as mensagens das aplicações em segmentos, repassa-os para a camada de rede • lado receptor: remonta as mensagens a partir dos segmentos, repassa-as para a camada de aplicação • existem mais de um protocolo de transporte disponível para as aplicações • Internet: TCP e UDP

5. Camadas de Transporte x Rede • camada de rede: comunicação lógica entre hospedeiros • camada de transporte: comunicação lógica entre processos • depende da camada rede e estende os serviços por ela oferecidos

6. aplicação transporte rede enlace física rede enlace física rede enlace física rede enlace física rede enlace física transporte lógico fim a fim rede enlace física aplicação transporte rede enlace física Protocolos da camada de transporte Internet • entrega confiável, ordenada (TCP) • controle de congestionamento • controle de fluxo • estabelecimento de conexão (“setup”) • entrega não confiável, não ordenada: UDP • extensão sem “frescuras” do “melhor esforço” do IP • serviços não disponíveis: • garantias de atraso • garantias de largura de banda

7. Multiplexação no transmisspr: Demultiplexação no receptor: aplicação P4 aplicação aplicação P1 P2 P3 P1 transporte transporte transporte rede rede rede enlace enlace enlace física física física host 3 host 2 host 1 Multiplexação/demultiplexação Entrega dos segmentos recebidos ao socket correto reúne dados de muitos sockets, envelopa os dados com o cabeçalho (usado posteriormente para a demultiplexação) = socket = processo

8. Como funciona a demultiplexação 32 bits porta remetente porta receptor outros campos do cabeçalho dados da aplicação (mensagem) • host recebe os datagramas IP • cada datagrama possui os endereços IP da origem e do destino • cada datagrama transporta 1 segmento da camada de transporte • cada segmento possui números das portas origem e destino (lembre: números de portas bem conhecidas para aplicações específicas) • host usa os endereços IP e os números das portas para direcionar o segmento ao socket apropriado formato de segmento TCP/UDP

9. Quando host recebe segmento UDP: verifica no. da porta de destino no segmento encaminha o segmento UDP para o socket com aquele no. de porta Datagramas IP com diferentes endereços IP origem e/ou números de porta origem são encaminhados para o mesmo socket Demultiplexação sem Conexões • socket UDP identificado pela dupla: (end IP dest, no. da porta destino)

10. P1 P2 P1 P3 SP: 6428 SP: 6428 DP: 9157 DP: 5775 SP: 9157 SP: 5775 cliente IP: A DP: 6428 DP: 6428 Cliente IP:B servidor IP: C Demultiplexação sem Conexões SP (source port) provê “endereço de retorno”

11. Servidor pode dar suporte a muitos sockets TCP simultâneos: cada socket é identificado pela sua própria 4-dupla Servidores Web têm sockets diferentes para cada conexão cliente HTTP não persistente terá sockets diferentes para cada pedido Demultiplexação Orientada a Conexões • Socket TCP identificado pela 4-dupla: • endereço IP origem • número da porta origem • endereço IP destino • número da porta destino • receptor usa todos os quatro valores para direcionar o segmento para o socket apropriado

12. P1 P2 P6 P1 P4 P5 P3 SP: 5775 DP: 80 SP: 9157 cliente IP: A DP: 80 Demultiplexação Orientada a Conexões S-IP: B D-IP:C SP: 9157 DP: 80 Cliente IP:B servidor IP: C S-IP: A S-IP: B D-IP:C D-IP:C

13. P1 P2 P1 P3 SP: 5775 DP: 80 SP: 9157 cliente IP: A DP: 80 Demultiplexação Orientada a Conexões: Servidor Web com Threads P4 S-IP: B D-IP:C SP: 9157 DP: 80 Cliente IP:B servidor IP: C S-IP: A S-IP: B D-IP:C D-IP:C

14. Por quê existe um UDP? elimina estabelecimento de conexão (o que pode causar retardo) simples: não se mantém “estado” da conexão no remetente/receptor pequeno cabeçalho de segmento sem controle de congestionamento: UDP pode transmitir o mais rápido possível UDP: User Datagram Protocol [RFC 768] • Protocolo de transporte da Internet mínimo, “sem frescura”, • Serviço “melhor esforço”, segmentos UDP podem ser: • perdidos • entregues à aplicação fora de ordem do remesso • sem conexão: • não há “setup” UDP entre remetente, receptor • tratamento independente de cada segmento UDP

15. Mais sobre UDP Comprimento em bytes do segmento UDP, incluindo cabeçalho • muito utilizado para apls. de meios contínuos (voz, vídeo) • tolerantes de perdas • sensíveis à taxa de transmissão • outros usos de UDP: • DNS (nomes) • SNMP (gerenciamento) • transferência confiável com UDP: incluir confiabilidade na camada de aplicação • recuperação de erro específica à apl.! 32 bits porta origem porta dest. checksum comprimento Dados de aplicação (mensagem) Formato do segmento UDP

16. Receptor: calcula checksum do segmento recebido verifica se checksum computado é zero: NÃO - erro detectado SIM - nenhum erro detectado. Mas ainda pode ter erros? Veja depois …. Checksum UDP Meta: detectar “erro” (e.g., bits invertidos) no segmento transmitido Remetente: • trata conteúdo do segmento como seqüência de inteiros de 16-bits • campo checksum zerado • checksum: soma (adição usando complemento de 1) do conteúdo do segmento • remetente coloca complemento do valor da soma no campo checksum de UDP

17. Exemplo do Checksum Internet • Note • Ao adicionar números, o transbordo do bit mais significativo deve ser adicionado o resultado • Exemplo: adição de 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 transbordo soma checksum

18. características do canal não confiável determinam a complexidade de um protocolo de transferência confiável de dados (rdt) Princípios de Transferência confiável de dados (rdt) • importante nas camadas de transporte, enlace • na lista dos 10 tópicos mais importantes em redes!

19. rdt_send():chamada de cima, (p.ex.,pela apl.). Dados recebidos p/ entregar à camada sup. do receptor deliver_data():chamada por rdt p/ entregar dados p/ camada superior udt_send():chamada por rdt, p/ transferir pacote pelo canal ñ confiável ao receptor rdt_rcv():chamada quando pacote chega no lado receptor do canal Transferência confiável de dados (rdt) send side receive side

20. transmissão full duplex: fluxo de dados bi-direcional na mesma conexão MSS: tamanho máximo de segmento orientado a conexão: handshaking (troca de msgs de controle) inicia estado de remetente, receptor antes de trocar dados fluxo controlado: receptor não será afogado ponto a ponto: 1 remetente, 1 receptor fluxo de bytes, ordenados, confiável: não estruturado em msgs com paralelismo (pipelined): tam. da janela ajustado por controle de fluxo e congestionamento do TCP buffers de envio e recepção TCP: Visão geral RFCs: 793, 1122, 1323, 2018, 2581

21. 32 bits no. porta origem no. porta dest número de seqüência número de reconhecimento tam.cab. sem uso janela receptor U A P R S F checksum ptr dados urg. Opções (tam. variável) dados daaplicação (tam. variável) TCP: estrutura do segmento URG: dados urgentes (pouco usados) contagem de dadospor bytes (não segmentos!) ACK: no. ACK válido PSH: envia dados já (pouco usado) no. bytes rcpt quer aceitar RST, SYN, FIN: gestão de conexão (comandos deestabelecimento, liberação) checksum Internet (como UDP)

22. Números de sequência (Seq): “número”dentro do fluxo de bytes do primeiro byte de dados do segmento Números de Reconhecimento (Ack): no. de seq do próx. byte esperado do outro lado ACK cumulativo tempo TCP: Seq e Ack Estação B Estação A Usuário tecla ‘C’ Seq=42, ACK=79, data = ‘C’ B reconhece chegada de ‘C’, ecoa ‘C’ de volta Seq=79, ACK=43, data = ‘C’ A reconhece chegada do ‘C’ecoado Seq=43, ACK=80 cenário simples de telnet

23. P: como escolher valor do temporizador TCP? maior que o RTT (Round Trip Time) note: RTT pode variar muito curto: temporização prematura retransmissões são desnecessárias muito longo: reação demorada à perda de segmentos P: como estimar RTT? RTTamostra: tempo medido entre a transmissão do segmento e o recebimento do ACK correspondente Como o RTT_amostra vai varia, usa-se várias medições recentes, não apenas o valor corrente. TCP: Tempo de Resposta e Temporização

24. Exemplo de estimativa do RTT:

25. Escolhendo o intervalo de temporização RTT_estimado mais uma “margem de segurança” grande variação no RTT_estimado -> maior margem de segurança primeiro estima o quanto a RTTamostra desvia do RTT_estimado, então, seta o temporizador para: TCP: Tempo de Resposta (RTT) e Temporização Temporização = RTT_estimado + 4*Desvio_RTT

26. O TCP cria um serviço confiável sobre o serviço não confiável do IP Segmentos em série (pipelined) Acks cumulativos O TCP usa um único temporizador para retransmissões As retransmissões são disparadas por: estouros de temporização acks duplicados Considere inicialmente um transmissor TCP simplificado: ignora acks duplicados ignora controles de fluxo e de congestionamento Transferência de dados confiável do TCP

27. Dados recebidos da aplicação: Cria segmento com no. de seqüência (nseq) nseq é o número de seqüência do primeiro byte do segmento Liga o temporizador se já não estiver ligado (temporização do segmento mais antigo ainda não reconhecido) Valor do temporizador: calculado anteriormente estouro do temporizador: Retransmite o segmento que causou o estouro do temporizador Reinicia o temporizador Recepção de Ack: Se reconhecer segmentos ainda não reconhecidos atualizar informação sobre o que foi reconhecido religa o temporizador se ainda houver segmentos pendentes (não reconhecidos) Eventos do transmissor TCP:

28. Host A Host B Seq=92, 8 bytes data ACK=100 Seq=92 timeout timeout X loss Seq=92, 8 bytes data ACK=100 tempo tempo cenário de perda de ACK TCP: cenários de retransmissão Host A Host B Seq=92, 8 bytes data Seq=100, 20 bytes data ACK=100 ACK=120 Seq=92, 8 bytes data Sendbase = 100 SendBase = 120 ACK=120 Seq=92 timeout SendBase = 100 SendBase = 120 estouro prematuro do temporizador

29. Host A Host B Seq=92, 8 bytes data ACK=100 Seq=100, 20 bytes data timeout X loss ACK=120 tempo Cenário de ACK cumulativo TCP: cenários de retransmissão SendBase = 120

30. TCP geração de ACKs [RFCs 1122, 2581] Ação do Receptor TCP ACK retardado. Espera até 500ms p/ próx. segmento. Se não chegarsegmento, envia ACK envia imediatamente um único ACK cumulativo envia ACK duplicado, indicando no. de seq.do próximo byte esperado ACK imediato se segmento no início da lacuna Evento no Receptor chegada de segmento em ordem sem lacunas, anteriores já reconhecidos chegada de segmento em ordem sem lacunas, um ACK retardado pendente chegada de segmento fora de ordem, com no. de seq. maior que esperado -> lacuna chegada de segmento que preenche a lacuna parcial oucompletamente

31. O intervalo do temporizador é freqüentemente bastante longo: longo atraso antes de retransmitir um pacote perdido Detecta segmentos perdidos através de ACKs duplicados. O transmissor normalmente envia diversos segmentos Se um segmento se perder, provavelmente haverá muitos ACKs duplicados. Se o transmissor receber 3 ACKs para os mesmos dados, ele supõe que o segmento após os dados reconhecidos se perdeu: Retransmissão rápida: retransmite o segmento antes que estoure o temporizador Retransmissão rápida

32. Lado receptor da conexão TCP possui um buffer de recepção: serviço de casamento de velocidades: adaptando a taxa de transmissão à taxa de leitura da aplicação receptora Controle de Fluxo do TCP Controle de fluxo o transmissor não inundará o buffer do receptor transmitindo muito e rapidamente • Processo da apl. pode demorar a ler do receptor

33. (Suponha que o receptor TCP receba segmentos fora de ordem) espaço livre no buffer = RcvWindow = RcvBuffer-[LastByteRcvd - LastByteRead] O receptor anuncia o espaço livre incluindo o valor da RcvWindow nos segmentos O transmissor limita os dados não reconhecidos ao tamanho da RcvWindow Garante que o buffer do receptor não transbordará Controle de Fluxo do TCP: como funciona

34. Lembrete: Remetente, receptor TCP estabelecem “conexão” antes de trocar segmentos de dados inicializam variáveis TCP: nos. de seq. buffers, info s/ controle de fluxo (p.ex. RcvWindow) cliente: iniciador de conexão servidor: contactado por cliente Inicialização em 3 tempos: Passo 1: sistema cliente envia segmento de controle SYN do TCP ao servidor especifica no. inicial de seq não envia dados Passo 2: sistema servidor recebe SYN, responde com segmento de controle SYNACK aloca buffers especifica no. inicial de seq. servidor-> receptor Passo 3: receptor recebe SYNACK, responde com segmento ACK que pode conter dados. TCP: Gerenciamento de Conexões

35. Encerrando uma conexão: cliente fecha soquete: Passo 1: sistema cliente envia segmento de controle FIN ao servidor Passo 2:servidor recebe FIN, responde com ACK. Encerra a conexão, enviando FIN. TCP: Gerenciamento de Conexões (cont.) cliente servidor fechar FIN ACK fechar FIN ACK espera temporizada fechada

36. Passo 3:cliente recebe FIN, responde com ACK. Entre em “espera temporizada” - responderá com ACK a FINs recebidos Passo 4:servidor, recebe ACK. Conexão encerrada. TCP: Gerenciamento de Conexões (cont.) cliente servidor fechando FIN ACK fechando FIN ACK esperatemporizada fechada fechada

37. TCP: Gerenciamento de Conexões (cont.) Ciclo de vidade servidor TCP Ciclo de vidade cliente TCP

38. Congestionamento: informalmente: “muitas fontes enviando muitos dados muito rapidamente para a rede poder tratar” diferente de controle de fluxo! manifestações: perda de pacotes (esgotamento de buffers em roteadores) longos atrasos (enfileiramento nos buffers dos roteadores) um dos 10 problemas mais importantes em redes! Princípios de Controle de Congestionamento

39. Controle de congestionamento fim a fim : não tem realimentação explícita pela rede congestionamento inferido a partir das perdas, retardo observados pelo sistema terminal abordagem usada pelo TCP Controle de congestionamento com apoio da rede: roteadores realimentam os sistemas terminais bit indicando congestionamento (ATM) taxa explícita p/ envio pelo remetente Abordagens de controle de congestionamento Duas abordagens amplas para controle de congestionamento:

40. controle fim-a-fim (sem assistência da rede) transmissor limita a transmissão: LastByteSent-LastByteAcked  CongWin Praticamente, CongWin é dinâmica, em função do congestionamento percebido da rede Como o transmissor percebe o congestionamento? evento de perda = estouro do temporizador ou 3 acks duplicados transmissor TCP reduz a taxa (CongWin) após evento de perda três mecanismos: AIMD partida lenta conservador após eventos de estouro de temporização CongWin taxa = Bytes/seg RTT Controle de Congestionamento do TCP

41. decrescimento multiplicativo: corta CongWin pela metade após evento de perda AIMD do TCP crescimento aditivo: incrementa CongWin de 1 MSS a cada RTT na ausência de eventos de perda: sondagem Conexão TCP de longa duração

42. No início da conexão, CongWin = 1 MSS Exemplo: MSS = 500 bytes & RTT = 200 mseg taxa inicial = 20 kbps largura de banda disponível pode ser >> MSS/RTT é desejável um crescimento rápido até uma taxa considerável Partida Lenta do TCP • No início da conexão, aumenta a taxa exponencialmente até o primeiro evento de perda

43. No início da conexão, aumenta a taxa exponencialmente até o primeiro evento de perda: duplica CongWin a cada RTT através do incremento da CongWin para cada ACK recebido Resumo: taxa inicial é baixa mas cresce rapidamente de forma exponencial tempo TCP: Partida lenta (mais) Estação A Estação B um segmento RTT dois segmentos quqtro segmentos

44. Após 3 ACKs duplicados: corta CongWin pela metade a janela depois cresce linearmente Mas após estouro de temporizador: CongWin é reduzida a 1 MSS; janela cresce exponencialmente até um limiar, depois cresce linearmente Refinamento Filosofia: • 3 ACKs duplicados indica que a rede é capaz de entregar alguns segmentos • estouro de temporizador antes de 3 ACKs duplicados é mais “alarmante”.

45. P:Quando o crescimento exponencial deve mudar para linear? R: Quando CongWin atinge 1/2 do seu valor antes do estouro do temporizador. Implementação: Limiar (Threshold) variável Com uma perda o limiar passa a ser 1/2 da CongWin imediatamente anterior à perda. Refinamento (mais)

46. Resumo: Controle de Congestionamento do TCP • Quando a CongWin está abaixo do limiar, transmissor está na fase de início lento, janela cresce exponencialmente. • Quando a CongWin está acima do limiar, transmissor está na fase de evitar congestionamento, janela cresce linearmente. • Quando chegam ACKs triplicados, Limiar passa a ser CongWin/2 e CongWin passa ao valor do Limiar. • Quando estoura o temporizador, Limiar passa a ser CongWin/2 e CongWin passa a ser 1 MSS.

47. Controle de congestionamento do transmissor TCP