Successfully reported this slideshow.

Redes de computadores II - 4.Camada de Transporte TCP e UDP

7,265 views

Published on

  • Be the first to comment

Redes de computadores II - 4.Camada de Transporte TCP e UDP

  1. 1. Camada de Transporte Prof. Mauro Tapajós
  2. 2. Introdução <ul><li>Sua função é oferecer transporte de dados confiável e efetivo entre uma máquina origem até uma máquina destino
  3. 3. Dois tipos de serviço de transporte: orientado a conexão e não-orientado a conexão
  4. 4. O estabelecimento de conexão (nestes tipos de serviços) garante que: </li></ul><ul><ul><li>Um lado saiba da existência do outro
  5. 5. Haja negociação de parâmetros
  6. 6. Sejam alocados recursos da entidade de transporte </li></ul></ul>
  7. 7. Por que a Camada de Transporte? <ul><li>Camada de rede pode não oferecer um serviço confiável
  8. 8. Isola as aplicações de quaisquer imperfeições no trânsito de pacotes (perdas, duplicatas, etc)
  9. 9. Permite desenvolvimento de rotinas básicas que funcionariam em qualquer tipo de plataforma de rede (o que pode variar muito – IP, Novell, SNA )
  10. 10. Permite a entrega de dados à aplicações específicas numa máquina </li></ul>
  11. 11. Protocolos de Transporte <ul><li>Camada de enlace : comunicação entre vizinhos diretamente conectados na mesma tecnologia de rede </li></ul><ul><li>Camada de Transporte : comunicação fim-a-fim através de diversas tecnologias de rede </li></ul>
  12. 12. Multiplexação <ul><li>Várias aplicações usam o mesmo protocolo de transporte para suas conexões
  13. 13. Tendência normal ao uso de várias conexões de transporte sobre um mesmo circuito virtual
  14. 14. Uso de várias conexões para um mesmo fluxo de dados visando aumentar a taxa de bits total </li></ul>
  15. 15. Protocolos de Transporte - Endereçamento <ul><li>Necessidade de endereçamento para aplicações de rede
  16. 16. Protocolo de início de conexão – deve saber com qual das aplicações na máquina vai se comunicar
  17. 17. Servidor de nomes/diretórios – alternativa que indica serviços registrados que podem mudar de endereço de rede e transporte </li></ul>
  18. 18. Encapsulamento de Protocolos de Transporte
  19. 19. Estabelecimento de Conexões <ul><li>Estabelecimento de conexões: problemas com pacotes duplicados pela rede </li></ul><ul><li>Solução: “ handshake ”de 3 passos </li></ul>
  20. 20. Desconexão <ul><li>Desconexão – não é um problema tão simples como parece
  21. 21. Normalmente é usado uma desconexão de 3 passos com temporizadores </li></ul>Desconexão assimétrica : interrupção abrupta da comunicação com possível perda de dados Desconexão simétrica : assume duas conexões unidirecionais e exige que cada uma seja desconectada em separado
  22. 22. Desconexão – Problema dos dois exércitos Como sincronizar o ataque azul?
  23. 23. Protocolos de Transporte <ul><li>Implementados nos hosts finais e não nos roteadores
  24. 24. Controle de fluxo: necessário como na camada de enlace de dados , só que fim-a-fim
  25. 25. Diferença básica: numa pilha de transporte podem existir várias conexões ao mesmo tempo – exige disponibilidade de buffers – não é um esquema independente para cada link (o espaço de memória é único para todas as conexões)
  26. 26. Uma possível solução – janelas deslizantes de tamanho variável e ajustado pelo transmissor </li></ul>
  27. 27. Protocolos de Transporte
  28. 28. Protocolos de Transporte TCP/IP <ul><li>S uas implementações normalmente são em software (bibliotecas)
  29. 29. No conjunto de protocolos TCP/IP temos a oferta de serviço orientado a conexão e confiável (protocolo TCP) e serviço não- orientado a conexão baseado em datagrama ( protocolo UDP)
  30. 30. Outros protocolos de transporte: protocolos OSI TP0, TP1, TP2, TP3 e TP4 </li></ul>
  31. 31. Transmission Control Protocol (TCP) <ul><li>Apresentado primeiramente na RFC 793, com o tempo foram registradas várias evoluções </li></ul>
  32. 32. Protocolo TCP <ul><li>Baseado na transferência de sequências de bytes entre buffers de transmissão e recepção
  33. 33. Bem projetado: não mudou muito desde sua aparição nos anos 60
  34. 34. Suporta aplicações básicas como TELNET, FTP e correio eletrônico
  35. 35. Especifica o formato dos dados e confirmações usadas na transferência daqueles, garantindo a correta entrega dos dados de clientes a servidores e vice-versa
  36. 36. Implementa suporte para detecção de erros e disparo de retransmissões quando necessário
  37. 37. Permite que múltiplas aplicações num sistema possam se comunicar concorrentemente tratando a operação multiplexada </li></ul>
  38. 38. Conexões TCP <ul><li>Baseado no conceito de sockets ( endpoints )
  39. 39. Um socket em TCP é identificado por uma porta e o endereço IP da máquina
  40. 40. Um mesmo socket pode suportar várias conexões ao mesmo tempo
  41. 41. Não suporta multicasting e broadcasting (sempre é ponto-a-ponto e full-duplex )
  42. 42. Cada conexão é identificada pelos números dos sockets nas duas pontas
  43. 43. Sockets é também o nome de uma biblioteca de subrotinas que provê acesso às facilidades TCP/IP </li></ul>
  44. 44. Software TCP
  45. 45. Cabeçalho TCP
  46. 46. Cabeçalho TCP <ul><li>Portas (origem e destino)
  47. 47. Sequence number : do primeiro byte deste segmento
  48. 48. Acknowledgement number : próximo byte a receber
  49. 49. Data Offset - Header lenght : comprimento do cabeçalho em palavras de 32 bits </li></ul>
  50. 50. Cabeçalho TCP <ul><li>Urgent Pointer: indica até onde vão os dados considerados urgentes neste segmento ( out-of-band data)
  51. 51. Window Size : tamanho da janela sendo usada. Caso seja 0 significa interromper a transmissão de mais segmentos temporariamente até o envio de valor maior que zero novamente </li></ul><ul><li>De maneira semelhante aos cabeçalhos IPv4, é possível se ter cabeçalhos opcionais no TCP </li></ul>
  52. 52. Cabeçalho TCP <ul><li>Bits de Controle: </li></ul><ul><li>Checksum : computado sobre o cabeçalho TCP e o seguinte </li></ul>pseudo-cabeçalh o:
  53. 53. Exemplo: Encapsulamento TCP sobre Ethernet
  54. 54. Algumas Opções TCP - Performance <ul><li>Normalmente negociadas na conexão
  55. 55. mss ( maximum segment size ) - maior tamanho suportado de um segmento único
  56. 56. wscale ( window scale ) – expande o valor máximo do tamanho da janela (window) – usado somente nos segmentos SYN - RFC 1323
  57. 57. timestamp – uso em medições RTTM ( Round Trip Time Measurements ) e checagem de segmentos duplicados antigos – RFC 1323
  58. 58. sack ( selective ack ) – estratégia de confirmação selective repeat – RFC 2018 </li></ul>
  59. 59. Estabelecimento de Conexões TCP <ul><li>Pedidos de conexão utilizam o bit SYN=1
  60. 60. Pedidos de desconexão utilizam o bit FIN=1 </li></ul><ul><li>Conexões através de 3-way handshake
  61. 61. Mantidas com segmentos keepalive
  62. 62. A desconexão é simétrica (cada direção é desfeita separadamente)
  63. 63. Temporizadores são usados na desconexão para evitar o problema dos dois exércitos </li></ul>
  64. 64. Desconexão TCP
  65. 65. Controles do TCP <ul><li>Segmentos vazios (sem dados) keepalive podem ser usados para confirmações e controle
  66. 66. Controle de congestionamento é implicitamente feito , já que a solução é baixar a taxa de dados que entra na rede
  67. 67. Este controle é feito com base nos limites do receptor (janela TCP) e da rede (janela de congestionamento)
  68. 68. O controle de temporizadores não é tão simples (as respostas da rede IP dependem de vários fatores) </li></ul>
  69. 69. Controle de Fluxo TCP <ul><li>Uso de segmentos (cabeçalho TCP mais um ou mais bytes de dados a serem transmitidos)
  70. 70. Numera individualmente os bytes sendo transmitidos para controle de fluxo
  71. 71. Utiliza um esquema de janela deslizante para confirmar a informação recebid a
  72. 72. Caso um segmento seja maior que 65495 bytes (limite do pacote IP=64k) ou maior que o MTU da rede, ele deve ser fragmentado (podendo gerar problemas de confirmação e remontagem na recepção) </li></ul>
  73. 73. Piggybacking TCP A N SEQ ACK WIN B N SEQ ACK WIN
  74. 74. Controle de Fluxo de Segmentos TCP
  75. 75. Small Packet Problem <ul><li>Causado por aplicações que enviem apenas 1 byte por vez (algumas aplicações tem este perfil como terminais remotos)
  76. 76. Isto obriga o receptor a receber o byte e confirmá-lo com todo um segmento
  77. 77. Após ler o byte, o receptor envia novamente todo um segmento com o novo valor no campo window
  78. 78. Isto causa uma sequência de segmentos pequenos (1 byte de payload ) na rede que devem ser transportados junto com os 40 bytes do cabeçalho TCP/IP. Perda significativa de performance! </li></ul>
  79. 79. Small Packet Problem - Exemplo 1 SEQ=0 ACK = 1 WIN = 4095 Application does a 1B write Empty 1 Application reads 1 B Empty ACK = 1 WIN = 4096 1 SEQ=1 ACK = 2 WIN = 4095 ACK = 2 WIN = 4096 1 Application reads 1 B Empty Application does a 1B write
  80. 80. Silly Window Sindrome <ul><li>Causado por aplicações que leiam apenas 1 byte por vez do seu buffer de recepção
  81. 81. Estes receptores logo tem seu buffer cheio. Ao ler apenas 1 byte, o TCP envia todo um segmento para confirmá-lo e liberando o envio de apenas mais um byte (campo window )
  82. 82. Após receber a confirmação, o transmissor segue e envia mais um segmento com somente 1 byte
  83. 83. Mais uma vez Isto causa uma sequência de segmentos pequenos na rede que devem ser transportados junto com os 40 bytes do cabeçalho TCP/IP. Perda significativa de performance! </li></ul>
  84. 84. Silly Window Sindrome - Exemplo 4K SEQ=0 ACK = 4096 WIN = 0 Application does a 4K write Empty Application reads 1 B ACK = 4096 WIN = 1 1 SEQ=4096 ACK = 4097 WIN = 0 ACK = 4097 WIN = 1 Application reads 1 B Full 4095 Application does a 1K write Full 4095
  85. 85. Como resolver estes casos? <ul><li>Algoritmo de NAGLE : na transmissão, envie o primeiro byte e mantenha os demais em buffer. Ao receber a confirmação, envie todos os demais num único segmento
  86. 86. Algoritmo de CLARK : na recepção, não permita leituras de 1 byte somente. Exije que haja um considerável espaço de buffer para se ler. Este espaço é o menor entre o tamanho máximo de segmento passado durante e conexão e a metade do seu buffer
  87. 87. Deve haver cuidado com o tempo de resposta que pode crescer com estes procedimentos! </li></ul>
  88. 88. Round Trip Time - RTT <ul><li>RTT = tempo do pacote chegar ao destino + tempo para o ACK retornar
  89. 89. Usado para cálculos de tempo máximo de espera de uma confirmação ( timeouts ) </li></ul>Network
  90. 90. Slow Start TCP <ul><li>Método implícito de controle de congestionamento </li></ul><ul><li>Inicia com o envio de 1 segmento e segue aumentando até chegar no limite ( threshold ) ou haverem perdas de pacotes </li></ul>
  91. 91. Controle de Congestionamento TCP <ul><li>TCP: responsabilidade pelo controle de congestionamento fim-a-fim
  92. 92. Uso da “ congestion window ” - inicia com valor igual ao máximo tamanho de segmento na conexão e é duplicado a cada ACK recebido
  93. 93. Em casos de congestionamento ( timeout de segmentos), a congestion window voltará ao valor inicial
  94. 94. O valor máximo que poderá ser enviado será o mínimo entre a congestion window e o último valor de window recebido) </li></ul>
  95. 95. Controle de Congestionamento TCP – Congestion Window Threshold: metade do valor da CW no slow start (início em 64k) Congestion avoidance
  96. 96. TCP – Congestion Avoidance <ul><li>Após o “threshold” a curva cresce de forma linear
  97. 97. Este estado é chamado de “ congestion avoidance ”
  98. 98. Nele, a CW aumenta de forma linear, aumentando em 1, desde que todos os segmentos na janela tenham sido confirmados -> suavização da curva </li></ul>
  99. 99. Timers TCP <ul><li>Controlam a temporização do protocolo – algo já visto que é difícil num protocolo de transporte
  100. 100. Timer de retransmissão – o quanto se espera pela confirmação de um segmento (TCP usa um algoritmo que recalcula o timer pelo RTT) </li><ul><li>Algoritmo de Karn -> dobra o timer de retransmissão e não recalcula o RTT em segmentos retransmitidos -> evitar recálculos errados do RTT (o ack que chegou é do segmento original ou da retransmissão?) </li></ul><li>Timer de persistência – o quanto se espera para se poder transmitir de novo (window ≠ 0)
  101. 101. Timer de keepalive – quando a conexão ficar em silêncio, checa de o outro lado está lá (controverso) </li></ul>
  102. 102. Limitações TCP <ul><li>Cabeçalhos extensos para um protocolo de transporte
  103. 103. Checksum falho para integridade a nível de transporte e redundante quando se usa protocolos de camada 2 confiáveis (como HDLC ou Ethernet)
  104. 104. A funcionalidade de dados “ urgent ” não é uma solução completa de sinalização out-of-band por que é submetida ao mesmo controle de fluxo dos dados normais
  105. 105. Entrega rápida de tráfego de mensagens deve usar a opção de “ push ” </li></ul>
  106. 106. User Datagram Protocol (UDP) <ul><li>Descrito na RFC 768 com posteriores evoluções
  107. 107. Oferece às aplicações a capacidade de enviar pacotes IP encapsulados (e não um fluxo de bytes) por um protocolo de transporte sem conexão
  108. 108. Basicamente oferece a capacidade de endereçamento de aplicação em portas ao protocolo IP </li></ul>
  109. 109. Protocolo UDP Utilizado quando: <ul><li>É necessário o envio de mensagens de multicast ou broadcast
  110. 110. O overhead gerado por procedimentos de conexão é injustificado ou não é tolerado pela aplicação em uso
  111. 111. Aplicações de amostragem de dados (Ex.: sensores)
  112. 112. Serviços request-response (a aplicação toma a responsabilidade de verificar mensagens que não chegam)
  113. 113. Aplicações de tempo-real onde temporização é o mais importante </li></ul>
  114. 114. Cabeçalho UDP <ul><li>Portas de origem e destino
  115. 115. Lenght : é o comprimento de todo o segmento UDP
  116. 116. Checksum : é calculado sobre todo o segmento e mais o mesmo pseudo-cabeçalho usado em TCP </li></ul>
  117. 117. Algumas Portas Conhecidas ( Well-Known )
  118. 118. O que é um S ocket ? <ul><li>Uma estrutura de dados que representa um ponto final na comunicação entre aplicações
  119. 119. Suas facilidades normalmente são disponiblizadas numa biblioteca (API) </li></ul>
  120. 120. Biblioteca Sockets <ul><li>Primitivas na forma de uma biblioteca que oferece serviços básicos de transporte </li></ul>
  121. 121. S ocket s
  122. 122. Sockets TCP (Exemplo)

×