Cap03a

449 views
381 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
449
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Cap03a

  1. 1. Capítulo 3: Camada de TransporteObjetivos do Capítulo: Resumo do Capítulo:• entender os princípios por trás • serviços da camada de transporte dos serviços da camada de • multiplexação/demultiplexação transporte: • transporte sem conexão: UDP – multiplexação/demultiplexação • princípios de transferência confiável de – transferência de dados dados confiável • transporte orientado à conexão: TCP – controle de fluxo – transferência confiável – controle de congestionamento – controle de fluxo• instanciação e implementação – gerenciamento de conexão na Internet • princípios de controle de congestionamento • controle de congesetionamento do TCP
  2. 2. Protocolos e Serviços de Transporte• Fornecem comunicação lógicas entre aplicação transporte processos de aplicação em diferentes eerede enlace hosts física rede enlace tr• Os protocolos de transporte são rede física an enlace sp executados nos sistemas finais da rede física or rede t• serviço de transporte vs serviços de enlace e ló física rede gi rede : enlace co física fi• camada de rede: transferência de m rede -a dados entre computadores (end enlace -fi física m systems)• camada de transporte: transferência aplicação transporte de dados entre processos rede enlace – utiliza e aprimora os serviços física oferecidos pela camada de rede
  3. 3. Protocolos da Camada de TransporteServiços de Transporte da Internet: application transporte rede• confiável, seqüencial e unicast enlace rede física (TCP) enlace tr rede física an – congestão enlace sp física or – controle de fluxo rede t enlace e ló física rede – orientado à conexão gi enlace co física• não confiável (“best-effort”), não fi m rede -a seqüencial, entrega unicast or enlace - física fi m multicast : UDP application• serviços não disponíveis: transporte rede – tempo-real enlace física – garantia de banda – multicast confiável
  4. 4. Multiplexação de Aplicações Segmento - unidade de dados trocada Demultiplexação: entrega de entre entidades da camada de segmentos recebidos aos transporte processos de aplicação corretos – TPDU: transport protocol data unit (unidade de dados do protocolo de transporte) receptor P3 P4 dados da camada M M de aplicação aplicação cabeçalho do P1 transporte P2 segmento M M rede aplicação aplicaçãosegmento Ht M transporte transporte Hn segmento rede rede
  5. 5. Multiplexação de AplicaçõesMultiplexação:reunir dados de múltiplos 32 bitsprocesso de aplicação, juntarcabeçalhos com informações porta origem porta destinopara demultiplexação outros campos de cabeçalhomultiplexação/demultiplexação:• baseada nos número de porta do transmissor, número de porta do dados de aplicação receptor e endereços IP (mensagem) – números de porta origem e destino em cada segmento – lembre: portas com números bem-conhecidos são usadas formato do segmento TCP/UDP para aplicações específicas
  6. 6. Multiplexação: exemplos porta origem: x cliente Webhost A porta dest.: 23 servidor B host C porta origem:23 port dest.: x IP Origem: C IP Origem: C IP Dest: B IP Dest: B porta origem: y porta origem: x aplicação Telnet porta dest.: 80 porta dest.: 80 IP Origem: A IP Dest: B Servidor cliente Web porta origem : x Web B host A porta dest.: 80 aplicação: servidor Web
  7. 7. UDP: User Datagram Protocol [RFC 768]• protocolo de transporte da Internet “sem gorduras” “sem Porque existe um UDP? frescuras” • não há estabelecimento de• serviço “best effort” , segmentos conexão (que pode redundar em UDP podem ser: atrasos) – perdidos • simples: não há estado de conexão – entregues fora de ordem nem no transmissor, nem no receptor para a aplicação • cabeçalho de segmento reduzido• sem conexão: • não há controle de congestionamento: – não há apresentação entre o UDP pode enviar segmentos tão UDP transmissor e o rápido quanto desejado (e possível) receptor – cada segmento UDP é tratado de forma independente dos outros
  8. 8. Mais sobre UDP• muito usado por aplicações de mutimídia contínua (streaming) 32 bits – tolerantes à perda Tamanho, em porta origem porta destino – sensíveis à taxa bytes do segmento tamanho checksum UDP, incluíndo• outros usos do UDP cabeçalho (porque?): – DNS – SNMP Dados de Aplicação (mensagem)• transferência confiável sobre UDP: acrescentar confiabilidade na camada de aplicação – recuperação de erro específica de cada aplicação formato do segmento UDP
  9. 9. UDP checksumObjetivo: detectar “erros” (ex.,bits trocados) no segmento transmitidoTransmissor: Receptor:• trata o conteúdo do segmento • computa o checksum do segmento como seqüencia de inteiros de recebido 16 bits • verifica se o checksum calculado é• checksum: soma (complemento igual ao valor do campo checksum: de 1 da soma) do conteúdo do – NÃO - error detectado segmento – SIM - não há erros. Mas,• transmissor coloca o valor do talvez haja erros apesar checksum no campo de checksum do UDP disto? Mais depois ….
  10. 10. Princípios de Transferência Confiável de Dados• importante nas camadas de aplicação, transporte e enlace • top-10 na lista dos tópicos mais importants de redes!• caracteristicas dos canais não confiáveis determinarão a complexidade dos protocolos confiáveis de transferência de dados (rdt)
  11. 11. Transferência confiável: o ponto de partidardt_send(): chamada da camada superior, deliver_data(): chamada pela (ex., pela aplicação). Passa dados para entidade de transporte para entregar à camada superior receptora entregar dados para cima lado ladotransmissor receptorudt_send(): chamada pela entidade rdt_rcv(): chamada quando o pacote chegade transporte, para transferir pacotes ao lado receptor do canal para o receptor sobre o canal não confiável
  12. 12. Transferência confiável: o ponto de partida Etapas: • desenvolver incrementalmente o transmissor e o receptor de um protocolo confiável de transferência de dados (rdt) • considerar apenas transferências de dados unidirecionais – mas informação de controle deve fluir em ambas as direções! • usar máquinas de estados finitos (FSM) para especificar o protocolo transmissor e o receptor evento causando transição de estados ações tomadas na transição de estadoestado: quando neste “estado” o próximo estado fica estado estado 1 evento unicamente determinado 2 pelo próximo evento ações
  13. 13. Rdt1.0: transferência confiável sobre canais confiáveis• canal de transmissão perfeitamente confiável – não há erros de bits – não há perdas de pacotes• FSMs separadas para transmissor e receptor: – transmissor envia dados para o canal subjacente – receptor lê os dados do canal subjacente
  14. 14. Rdt2.0: canal com erros de bit• canal subjacente pode trocar valores dos bits num pacote – lembrete: checksum do UDP pode detectar erros de bits• a questão: como recuperar esses erros: – reconhecimentos (ACKs): receptor avisa explicitamente ao transmissor que o pacote foi recebido corretamente – reconhecimentos negativos (NAKs): receptor avisa explicitamente ao transmissor que o pacote tem erros – transmissor reenvia o pacote quando da recepção de um NAK – cenários humanos usando ACKs, NAKs?• novos mecanismos no rdt2.0 (além do rdt1.0): – deteção de erros – retorno do receptor: mensagens de controle (ACK,NAK) rcvr->sender
  15. 15. rdt2.0: especificação da FSMFSM do transmissor FSM do receptor
  16. 16. rdt2.0: em ação (ausência de erros)FSM do transmissor FSM do receptor
  17. 17. rdt2.0: em ação (cenário com erros)FSM do transmissor FSM do receptor
  18. 18. rdt2.0 tem um problema fatal!O que acontece se o ACK/NAK é Tratando duplicatas: corrompido? • transmissor acrescenta número de• transmissor não sabe o que seqüência em cada pacote aconteceu no receptor! • Transmissor reenvia o último• não pode apenas retransmitir: pacote se f ACK/NAK for perdido possível duplicata • receptor descarta (não passa para a aplicação) pacotes duplicadosO que fazer?• Transmissor envia ACKs/NAKs para reconhecer os ACK/NAK do stop and wait receptor? O que acontece se estes Transmissor envia um pacote ACK/NAK se perdem? e então espera pela resposta• retransmitir os ACK/NAK, mas do receptor isto poderia causar a retransmissão de um pacote recebido corretamente!
  19. 19. rdt2.1: transmissor, trata ACK/NAKs perdidos
  20. 20. rdt2.1: receptor, trata ACK/NAKs perdidos
  21. 21. rdt2.1: discusssãoTransmissor: Receptor:• adiciona número de seqüência • deve verificar se o pacote ao pacote recebido é duplicado• Dois números (0 e 1) bastam. Porque? – estado indica se o pacote 0 ou 1 é esperado• deve verificar se os ACK/NAK recebidos estão corrompidos • nota: receptor pode não• duas vezes o número de estados saber se seu últino – o estado deve “lembrar” se o ACK/NAK foi recebido pacote “corrente” tem número pelo transmissor de seqüência 0 ou 1
  22. 22. rdt2.2: um protocolo sem NAK• mesma funcionalidade do rdt2.1, usando somente ACKs• ao invés de enviar NAK, o receptor envia ACK para o último pacote recebido sem erro – receptor deve incluir explicitamente o número de seqüência do pacote sendo reconhecido• ACKs duplicados no ! transmissor resultam na mesma ação do NAK: retransmição do FSM do pacote corrente transmissor
  23. 23. rdt3.0: canais com erros e perdasNova Hipótese: canal de Abordagem: transmissor espera transmissão pode também um tempo “razoável” pelo perder pacotes (dados oo ACK ACKs) • retransmite se nenhum ACK for recebido neste tempo – checksum, números de seqüência, ACKs, • se o pacote (ou ACK) estiver retransmissões serão de apenas atrasado (não perdido): ajuda, mas não o bastante – retransmissão será duplicata, mas os números de seqüênciaQ: como tratar com perdas? já tratam com isso – transmissor espera até que – receptor deve especificar o certos dados ou ACKs número de seqüência do sejam perdidos, então pacote sendo reconhecido retransmite • exige um temporizador – problemas? decrescente
  24. 24. rdt3.0 sender
  25. 25. rdt3.0 em ação(a) operação sem perda (b) pacote perdido
  26. 26. rdt3.0 em ação(c) ACK perdido (d) timeout prematuro
  27. 27. Desempenho do rdt3.0• rdt3.0 funciona, mas o desempenho é sofrível• exemplo: enlace de 1 Gbps, 15 ms de atraso de propagação, pacotes de 1KB: 8kb/pct transmissão = = 8 µs 10**9 b/seg fração do tempo 8 µs Utilização = U = transmissor ocupado = = 0.00015 30,016 ms – Um pacote de 1KB cada 30 ms -> 33kB/seg de vazão sobre um canal de 1 Gbps – o protocolo de rede limita o uso dos recursos físicos!
  28. 28. Protocolos com Paralelismo (pipelining)Paralelismo: transmissor envia vários pacotes ao mesmo tempo, todos esperando para serem reconhecidos – faixa de números de seqüência deve ser aumentada – armazenamento no transmissor e/ou no receptor (a) operação do protocolo stop-and-wait (a) operação do protocolo com paralelismo• Duas formas genéricas de protocolos com paralelismo: go- Back-N, retransmissão seletiva
  29. 29. Go-Back-NTransmissor:• Número de seqüência com k bits no cabeçalho do pacote• “janela” de até N, pacotes não reconhecidos, consecutivos, são permitidos• ACK(n): reconhece todos os pacotes até o número de seqüência N (incluindo este limite). “ACK cumulativo” – pode receber ACKS duplicados (veja receptor)• temporizador para cada pacote enviado e não confirmado• timeout(n): retransmite pacote n e todos os pacotes com número de seqüência maior que estejam dentro da janela
  30. 30. GBN: FSM estendida para o transmissor
  31. 31. GBN: FSM estendida para o receptorreceptor simples:• somente ACK: sempre envia ACK para pacotes corretamente recebidos com o mais alto número de seqüência em ordem – pode gerar ACKs duplicados – precisa lembrar apenas do número de seqüência esperado (expectedseqnum)• pacotes fora de ordem: – descarte (não armazena) -> não há buffer de recepção! – reconhece pacote com o mais alto número de seqüência em ordem
  32. 32. GBN em ação
  33. 33. Retransmissão Seletiva• receptor reconhece individualmente todos os pacotes recebidos corretamente – armazena pacotes, quando necessário, para eventual entrega em ordem para a camada superior• transmissor somente reenvia os pacotes para os quais um ACK não foi recebido – transmissor temporiza cada pacote não reconhecido• janela de transmissão – N números de seqüência consecutivos – novamente limita a quantidade de pacotes enviados, mas não reconhecidos
  34. 34. Retransmissão seletiva: janelas do transmissor e do receptor (a) visão dos números de seqüência pelo transmissor (b) visão dos números de seqüência pelo receptor
  35. 35. Retransmissão seletivatransmissor receptordados da camada superior : pacote n em [rcvbase, rcvbase+N-1]• se o próximo número de seqüência • envia ACK(n) disponível está na janela, envia o • fora de ordem: armazena pacote • em ordem: entrega (tambémtimeout(n): entrega pacotes armazenados• reenvia pacote n, em ordem), avança janela para restart timer o próximo pacote ainda nãoACK(n) em [sendbase,sendbase+N]: recebido• marca pacote n como recebido pkt n em [rcvbase-N,rcvbase-1]• se n é o menor pacote não reconhecido, avança a base da • ACK(n) janela para o próximo número de caso contrário: seqüência não reconhecido • ignora
  36. 36. Retransmissão seletiva em ação
  37. 37. Retransmissão seletiva:dilemaExemplo:• seqüências: 0, 1, 2, 3• tamanho da janela=3• receptor não vê diferença nos dois cenários!• incorretamente passa dados duplicados como novos (figura a)Q: qual a relação entre o espaço de numeração seqüencial e o tamanho da janela?

×