RC - SL03 - Camada de Transporte

4,350 views

Published on

Slide da aula da unidade 3 que trata da Camada de Transporte da arquitetura TCP/IP na disciplina redes de computadores

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

No Downloads
Views
Total views
4,350
On SlideShare
0
From Embeds
0
Number of Embeds
13
Actions
Shares
0
Downloads
307
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

RC - SL03 - Camada de Transporte

  1. 1. Universidade Federal da Paraíba Centro de Ciências Aplicadas e Educação Departamento de Ciências Exatas Redes de Computadores: Camada de Transporte Prof. Rafael Marrocos Magalhães rafael@dce.ufpb.br 20 de Setembro de 2011 UFPB - CCAE - DCE Esta apresentação contém partes, ou mesmo slides inteiros, da apresentação original disponibilizada por J.F Kurose e K.W. Ross, com permissão para utilização como material de apoio instrucional. E, conforme solicitação do original, incluí aqui a nota de direito autoral.quarta-feira, 28 de setembro de 11 1
  2. 2. Motivação Como as aplicações se comunicam?quarta-feira, 28 de setembro de 11 2
  3. 3. Sumário Serviços da camada de transporte Multiplexação e demultiplexação Transporte não orientado para conexão: UDP Princípios de transferência confiável de dados Transporte orientado para conexão: TCP Princípios de controle de congestionamento Controle de congestionamento: TCPquarta-feira, 28 de setembro de 11 3
  4. 4. Sumário 3.1 Serviços da camada de transporte Multiplexação e demultiplexação Transporte não orientado para conexão: UDP Princípios de transferência confiável de dados Transporte orientado para conexão: TCP Princípios de controle de congestionamento Controle de congestionamento: TCPquarta-feira, 28 de setembro de 11 4
  5. 5. Serviços e protocolos Serviços da camada de transportede transporte !  oferecem comunicação lógica aplicação entre processos de aplicação transporte rede rodando em hospedeiros enlace física diferentes !  protocolos de transporte rodam em sistemas finais "  lado remetente: divide as msgs da aplicação em segmentos, passa à camada de rede "  lado destinatário: remonta os segmentos em msgs, passa à aplicação camada de aplicação transporte rede enlace !  mais de um protocolo de física transporte disponível às aplicações "  Internet: TCP e UDPquarta-feira, 28 de setembro de 11 5
  6. 6. Camada de transporte Transporte X Rede versus rede Camada de transporte !  camada de rede: versus rede comunicação lógica entre hospedeiros !  camada de rede: analogia com a família: !  camada de transporte: comunicação lógica entre hospedeiros X comunicação mandando 12 crianças lógica entre processos carta a 12 crianças conta com e amplia os !  camada de transporte: !  processos = crianças "  serviços da camada de comunicação lógica !  msgs da aplicação = rede entre processos cartas nos envelopes "  conta com e amplia os !  hospedeiros = casas serviços da camada de rede !  protocolo de transporquarta-feira, 28 de setembro de 11 6
  7. 7. da de transportes rede Analogiada de rede: analogia com a família:nicação lógica 12 crianças mandando hospedeiros carta a 12 criançasda de transporte: !  processos = criançasnicação lógica !  msgs da aplicação = processos cartas nos envelopesta com e amplia os !  hospedeiros = casasviços da camada dee !  protocolo de transporte = Ana e Bill !  protocolo da camada de rede = serviço postal quarta-feira, 28 de setembro de 11 7
  8. 8. Protocolos da camada Protocolos de transporte de transporte da Internet !  remessa confiável e em aplicação transporte rede ordem (TCP) enlace física "  controle de congestionamento rede enlace rede enlace "  controle de fluxo física física "  estabelecimento da conexão rede enlace !  remessa não confiável e física desordenada: UDP rede enlace física "  extensão sem luxo do IP pelo network rede data link enlace “melhor esforço” physical física rede aplicação transporte enlace !  serviços não disponíveis: física rede enlace física "  garantias de atraso "  garantias de largura de bandaquarta-feira, 28 de setembro de 11 8
  9. 9. Sumário Serviços da camada de transporte 3.2 Multiplexação e demultiplexação Transporte não orientado para conexão: UDP Princípios de transferência confiável de dados Transporte orientado para conexão: TCP Princípios de controle de congestionamento Controle de congestionamento: TCPquarta-feira, 28 de setembro de 11 9
  10. 10. Multiplexação/ Multiplexação demultiplexação e demultiplexaçãodemultiplexação no destinatário: multiplexação no remetente: entregando segmentos colhendo dados de múltiplos recebidos ao socket correto sockets, envelopando dados com cabeçalho (usados depois = socket = processo para demultiplexação) aplicação P3 P1 P1 aplicação P2 P4 aplicação transporte transporte transporte rede rede rede enlace enlace enlace física física física hospedeiro 2 hospedeiro 3 hospedeiro 1quarta-feira, 28 de setembro de 11 10
  11. 11. Como funciona a Como funciona: demultiplexação Como funciona a demultiplexação demultiplexação !  hospedeiro recebe !  hospedeiro recebe datagramas IP datagramas IP 32 bits bits 32 "  cada datagrama tem "  cada datagrama tem endereçoIP de origem, # porta origem # porta destinodestino # porta origem # porta endereço IP de origem, endereçoIP de destino endereço IP de destino "  cada datagrama carrega 1 1 "  cada datagrama carrega outros campos de cabeçalho outros campos de cabeçalho segmentoda camada de segmento da camada de transporte transporte "  cada segmento tem "  cada segmento tem dados da número de porta de dados da número destino de de porta aplicação origem, aplicação (mensagem) origem, destino (mensagem) !  hospedeiro usa endereços IP !  hospedeirode porta para & números usa endereços IP & números segmento ao direcionar de porta para formato do segmento TCP/UDP direcionar segmento ao socket apropriado formato do segmento TCP/U socket apropriadoquarta-feira, 28 de setembro de 11 11
  12. 12. demultiplexação não orientada para conexão Demultiplexação não orientada para conexão !  quando hospedeiro !  cria sockets com números recebe segmento UDP: de porta: "  verifica número de porta DatagramSocket mySocket1 = new de destino no segmento DatagramSocket(12534); "  direciona segmento UDP DatagramSocket mySocket2 = new para socket com esse DatagramSocket(12535); número de porta !  socket UDP identificado por !  datagramas IP com tupla de dois elementos: diferentes endereços IP (endereço IP destino, número porta de origem e/ou números destino) de porta de origem direcionados para o mesmo socketquarta-feira, 28 de setembro de 11 12
  13. 13. demultiplexação não orientada para conexão DatagramSocket serverSocket = new DatagramSocket(6428); P2 P1 P1 P3 SP: 6428 SP: 6428 DP: 9157 DP: 5775 SP: 9157 SP: 5775 cliente DP: 6428 DP: 6428 Cliente servidor IP: A IP: C IP:B SP oferece “endereço de retorno”quarta-feira, 28 de setembro de 11 13
  14. 14. Demultiplexaçãoorientada para conexão demultiplexação orientada para conexão!  socket TCP identificado !  hospedeiro servidor pode por tupla de 4 elementos: admitir muitos sockets "  endereço IP de origem TCP simultâneos: "  número de porta de origem "  cada socket identificado "  endereço IP de destino por usa própria tupla de 4 "  número de porta de destino !  servidores Web têm!  hospedeiro destinatário diferentes sockets para usa todos os quatro cada cliente conectando valores para direcionar "  HTTP não persistente terá segmento ao socket diferentes sockets para cada requisição apropriadoquarta-feira, 28 de setembro de 11 14
  15. 15. demultiplexação orientada para conexão P1 P4 P5 P6 P2 P1 P3 SP: 5775 DP: 80 S-IP: B D-IP:C SP: 9157 SP: 9157 cliente DP: 80 DP: 80 cliente servidor IP: A S-IP: A IP: C S-IP: B IP:B D-IP:C D-IP:Cquarta-feira, 28 de setembro de 11 15
  16. 16. Demultiplexação orientada demultiplexação orientada para conexão para conexão: servidor Web threadedWEB Servidor P1 P4 P2 P1 P3 SP: 5775 DP: 80 S-IP: B D-IP:C SP: 9157 SP: 9157 cliente DP: 80 DP: 80 cliente servidor IP: A S-IP: A IP: C S-IP: B IP:B D-IP:C D-IP:Cquarta-feira, 28 de setembro de 11 16
  17. 17. Sumário Serviços da camada de transporte Multiplexação e demultiplexação 3.3 Transporte não orientado para conexão: UDP Princípios de transferência confiável de dados Transporte orientado para conexão: TCP Princípios de controle de congestionamento Controle de congestionamento: TCPquarta-feira, 28 de setembro de 11 17
  18. 18. UDP: User Datagram UDP: User Datagram Protocol Protocol [RFC 768] RFC 768 !  protocolo de transporte da Internet “sem luxo”, básico Por que existe um UDP? !  serviço de “melhor esforço”, !  sem estabelecimento de segmentos UDP podem ser: conexão (que pode gerar atraso) "  perdidos !  simples: sem estado de "  entregues à aplicação conexão no remetente, fora da ordem destinatário !  cabeçalho de segmento !  sem conexão: pequeno "  sem handshaking entre !  sem controle de remetente e destinatário congestionamento: UDP UDP pode transmitir o mais rápido possível "  cada segmento UDP tratado independente dos outrosquarta-feira, 28 de setembro de 11 18
  19. 19. Quem usa UDP? DNS Stream Multimídia RIP VoIP SNMP NFS Muitos outros...quarta-feira, 28 de setembro de 11 19
  20. 20. UDP: User Datagram Protocol UDP: mais !  normalmente usado para streaming de aplicações de 32 bits multimídia tamanho, # porta origem # porta dest. "  tolerante a perdas em bytes, do tamanho soma verif. "  sensível à taxa segmento UDP, incluindo !  outros usos do UDP cabeçalho "  DNS "  SNMP dados da !  transferência confiável por aplicação UDP: aumenta confiabilidade (mensagem) na camada de aplicação "  recuperação de erro específica da aplicação! formato de segmento UDPquarta-feira, 28 de setembro de 11 20
  21. 21. Soma de Verificação Soma de verificação UDP objetivo: detectar “erros” (p. e., bits invertidos) no segmento transmitido destinatário: remetente: !  calcula soma de verificação do !  trata conteúdo de segmento recebido segmento como sequência !  verifica se soma de verificação de inteiros de 16 bits !  soma de verificação calculada igual ao valor do (checksum): adição (soma campo de soma de verificação: por complemento de 1) do "  NÃO – erro detectado conteúdo do segmento "  SIM – nenhum erro !  remetente coloca valor da soma de verificação no detectado. Mas pode haver campo de soma de erros mesmo assim? Veja verificação UDP mais adiante ….quarta-feira, 28 de setembro de 11 21
  22. 22. Exemplo de soma de verificação da Exemplo Internet !  nota "  Ao somar números, um carryout do bit mais significativo precisa ser somado ao resultado !  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 contorna 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 soma 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 soma de 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 verificaçãoquarta-feira, 28 de setembro de 11 22
  23. 23. Sumário Serviços da camada de transporte Multiplexação e demultiplexação Transporte não orientado para conexão: UDP 3.4 Princípios de transferência confiável de dados Transporte orientado para conexão: TCP Princípios de controle de congestionamento Controle de congestionamento: TCPquarta-feira, 28 de setembro de 11 23
  24. 24. Princípios Importante também nas três camadas: aplicação, transporte e enlace Está na lista dos 10 tópicos mais importantes no desenvolvimento das redes de computadores! As características do canal confiável são determinantes na complexidade do protocolo de transferência confiável Protocolo fictício de estudo [rdt]quarta-feira, 28 de setembro de 11 24
  25. 25. Transferência confiável dede Transferência confiável dados: introdução dados: introdução rdt_send(): chamado de cima, (p. e., deliver_data(): chamado pela pela apl.). Dados passados para remeter rdt para remeter dados para cima à camada superior do destinatário lado lado remetente destinatário udt_send(): chamado pela rdt_rcv(): chamado quando pacote rdt, para transferir pacote por chega no lado destinatário do canal canal não confiável ao destinatárioquarta-feira, 28 de setembro de 11 25
  26. 26. Protocolo fictício vamos: !  desenvolver de forma incremental os lados remetente e destinatário do protocolo de transferência confiável de dados (rdt) !  considerar apenas a transf. de dados unidirecional "  mas informações de controle fluirão nas duas direções! !  usar máquinas de estado finito (FSM) para especificar remetente, destinatário evento causando transição de estado ações tomadas sobre transição de estado estado: quando neste “estado”, próximo estado estado 1 evento estado determinado 2 exclusivamente pelo ações próximo eventoquarta-feira, 28 de setembro de 11 26
  27. 27. Rdt1.0: transferência [rdt 1.0] : transferência confiável por canal confiável confiável por canal confiável !  canal subjacente perfeitamente confiável "  sem erros de bit "  sem perda de pacotes !  FSMs separadas para remetente e destinatário: "  remetente envia dados para canal subjacente "  destinatário lê dados do canal subjacente Espera rdt_send(dados) Espera rdt_rcv(pacote) chamada chamada extract (pacote, dados) de cima packet = make_pkt(dados) de baixo deliver_data(dados) udt_send(pacote) remetente destinatárioquarta-feira, 28 de setembro de 11 27
  28. 28. Rdt2.0: canal2.0] : canal com erros de bit [rdt com errosde bit !  canal subjacente pode inverter bits no pacote "  soma de verificação para detectar erros de bit !  a questão: como recuperar-se dos erros: "  reconhecimentos (ACKs): destinatário diz explicitamente ao remetente que o pacote foi recebido OK "  reconhecimentos negativas (NAKs): destinatário diz explicitamente ao remetente que o pacote teve erros "  remetente retransmite pacote ao receber NAK !  novos mecanismos no rdt2.0 (além do rdt1.0): "  detecção de erro "  feedback do destinatário: msgs de controle (ACK,NAK) destinatário->remetentequarta-feira, 28 de setembro de 11 28
  29. 29. [rdt 2.0] : especificação de uma máquina de estado finita rdt2.0: especificação da FSM rdt_send(dados) snkpkt = make_pkt(dados, soma_verif) udt_send(pctenv) destinatário rdt_rcv(pctrec) && isNAK(pctrec) Espera Espera rdt_rcv(pctrec) && chamada ACK ou udt_send(pctenv) corrupt(pctrec) de cima NAK udt_send(NAK) rdt_rcv(pctrec) && isACK(pctrec) Espera !" chamada remetente de baixo rdt_rcv(pctrec) && notcorrupt(pctrec) extract(pctrec,dados) deliver_data(dados) udt_send(ACK)quarta-feira, 28 de setembro de 11 29
  30. 30. [rdt 2.0] : operação sem erros rdt2.0: operação sem erros rdt_send(dados) snkpkt = make_pkt(dados, soma_verif) udt_send(pctenv) rdt_rcv(pctrec) && isNAK(pctrec) Espera Espera rdt_rcv(pctrec) && chamada ACK ou udt_send(pctenv) corrupt(pctrec) de cima NAK udt_send(NAK) rdt_rcv(pctrec) && isACK(pctrec) Espera !" chamada de baixo rdt_rcv(pctrec) && notcorrupt(pctrec) extract(pctrec,dados) deliver_data(dados) udt_send(ACK)quarta-feira, 28 de setembro de 11 30
  31. 31. [rdt 2.0] : operação com erros rdt2.0: cenário de erro rdt_send(dados) snkpkt = make_pkt(dados, soma_verif) udt_send(pctenv) rdt_rcv(pctrec) && isNAK(pctrec) Espera Espera rdt_rcv(pctrec) && chamada ACK ou udt_send(pctenv) corrupt(pctrec) de cima NAK udt_send(NAK) rdt_rcv(pctrec) && isACK(pctrec) Espera !" chamada de baixo rdt_rcv(pctrec) && notcorrupt(pctrec) extract(pctrec,dados) deliver_data(dados) udt_send(ACK)quarta-feira, 28 de setembro de 11 31
  32. 32. [rdt 2.0] : problema nesta versão! rdt2.0 tem uma falha fatal! O que acontece se ACK/ tratando de duplicatas: NAK for corrompido? !  remetente retransmite !  remetente não sabe o que pacote atual se ACK/NAK aconteceu no destinatário! corrompido !  não pode simplesmente !  remetente acrescenta retransmitir: possível número de sequência a cada duplicação pacote !  destinatário descarta (não sobe) pacote duplicado pare e espere remetente envia um pacote, depois espera resposta do destinatárioquarta-feira, 28 de setembro de 11 32
  33. 33. [rdt 2.1] : remetente ACK/NACKs corrompidos rdt2.1: tratamento de trata de ACK/NAKs corrompidos rdt_send(dados) remetente pctenv = make_pkt(0, dados, checksum) udt_send(pctenv) rdt_rcv(pctrec) && ( corrupt(pctrec) || Espera Espera isNAK(pctrec) ) chamada 0 ACK ou NAK 0 udt_send(pctenv) de cima rdt_rcv(pctrec) && notcorrupt(pctrec) rdt_rcv(pctrec) && isACK(pctrec) && notcorrupt(pctrec) && isACK(pctrec) !" !" Espera Espera ACK ou chamada 1 rdt_rcv(pctrec) && NAK 1 de cima ( corrupt(pctrec) || isNAK(pctrec) ) rdt_send(dados) udt_send(pctenv) pctenv = make_pkt(1, dados, checksum) udt_send(pctenv)quarta-feira, 28 de setembro de 11 33
  34. 34. [rdt 2.1] : tratamento de ACK/NACKs corrompidos rdt_rcv(pctrec) && notcorrupt(pctrec) destinatário && has_seq0(pctrec) extract(pctrec,dados) deliver_data(dados) pctenv = make_pkt(ACK, chksum) udt_send(pctenv) rdt_rcv(pctrec) && (corrupt rdt_rcv(pctrec) && (corrupt (pctrec) (pctrec) = make_pkt(NAK, chksum) pctenv = make_pkt(NAK, chksum) pctenv udt_send(pctenv) udt_send(pctenv) Espera Espera rdt_rcv(pctrec) && 0 de 1 de rdt_rcv(pctrec) && not corrupt(pctrec) && cima baixo not corrupt(pctrec) && has_seq1(pctrec) has_seq0(pctrec) pctenv = make_pkt(ACK, chksum) pctenv = make_pkt(ACK, chksum) udt_send(pctenv) udt_send(pctenv) rdt_rcv(pctrec) && notcorrupt(pctrec) && has_seq1(pctrec) extract(pctrec,dados) deliver_data(dados) pctenv = make_pkt(ACK, chksum) udt_send(pctenv)quarta-feira, 28 de setembro de 11 34
  35. 35. rdt2.1: discussão [rdt 2.1] : considerações remetente: destinatário: !  # seq acrescentado ao !  deve verificar se pkt pacote recebido está !  dois #s seq. (0,1) duplicado bastarão. Por quê? "  estado indica se 0 ou 1 é # seq. esperado do !  deve verificar se ACK/ pacote NAK recebido foi !  nota: destinatário não corrompido sabe se seu último !  o dobro de estados ACK/NAK foi recebido "  estado de “lembrar” se OK no remetente pacote “atual” tem # seq. 0 ou 1quarta-feira, 28 de setembro de 11 35
  36. 36. [rdt 2.2] : um protocolo sem NAK*rdt2.2: um protocolo sem NAK !  mesma funcionalidade de rdt2.1, usando apenas ACKs !  em vez de NAK, destinatário envia ACK para último pacote recebido OK "  destinatário precisa incluir explicitamente # seq. do pacote sendo reconhecido com ACK !  ACK duplicado no remetente resulta na mesma ação de NAK: retransmitir pacote atualquarta-feira, 28 de setembro de 11 36
  37. 37. rdt2.2: fragmentos do [rdt 2.2] : um protocolo sem NAK* remetente, destinatário rdt_send(dados) pctenv = make_pkt(0, dados, checksum) udt_send(pctenv) rdt_rcv(pctrec) && ( corrupt(pctrec) || Espera Espera ACK isACK(pctrec,1) ) chamada 0 de cima 0 udt_send(pctenv) fragmento FSM do remetente rdt_rcv(pctrec) && notcorrupt(pctrec) rdt_rcv(pctrec) && && isACK(pctrec,0) (corrupt(pctrec) || !" has_seq1(pctrec)) Espera fragmento FSM 0 de udt_send(pctenv) baixo do destinatário rdt_rcv(pctrec) && notcorrupt(pctrec) && has_seq1(pctrec) extract(pctrec,dados) deliver_data(dados) pctenv = make_pkt(ACK1, chksum) udt_send(pctenv)quarta-feira, 28 de setembro de 11 37
  38. 38. rdt3.0: canais: canais erros [rdt 3.0] com com erros e perdas e perda nova suposição: canal técnica: remetente espera subjacente também quantidade “razoável” de pode perder pacotes tempo por ACK (dados ou ACKs) !  retransmite se não chegar ACK "  soma de verificação, # nesse tempo seq., ACKs, !  se pct (ou ACK) simplesmente retransmissões serão atrasado (não perdido): úteis, mas não "  retransmissão será suficientes duplicada, mas os #s de seq. já cuidam disso "  destinatário deve especificar # seq. do pacote sendo reconhecido com ACK !  requer contador regressivoquarta-feira, 28 de setembro de 11 38
  39. 39. [rdt 3.0] : canais com erros e perdas remetente rdt3.0 rdt_send(dados) remetente rdt_rcv(pctrec) && pctenv = make_pkt(0, dados, checksum) udt_send(pctenv) ( corrupt(pctrec) || start_timer isACK(pctrec,1) ) rdt_rcv(pctrec) !" !" Espera Espera timeout chamada 0 ACK0 udt_send(pctenv) de cima start_timer rdt_rcv(pctrec) && notcorrupt(pctrec) rdt_rcv(pctrec) && isACK(pctrec,1) && notcorrupt(pctrec) stop_timer && isACK(pctrec,0) stop_timer Espera Espera timeout chamada 1 udt_send(pctenv) ACK1 de cima start_timer rdt_rcv(pctrec) rdt_send(dados) !" rdt_rcv(pctrec) && ( corrupt(pctrec) || pctenv = make_pkt(1, dados, checksum) isACK(pctrec,0) ) udt_send(pctenv) start_timer !"quarta-feira, 28 de setembro de 11 39
  40. 40. [rdt 3.0] : em açãordt3.0 em açãoquarta-feira, 28 de setembro de 11 40
  41. 41. [rdt 3.0] : em açãoquarta-feira, 28 de setembro de 11 41
  42. 42. [rdt 3.0] : desempenho Desempenho do rdt3.0 !  rdt3.0 funciona, mas com desempenho ruim !  ex.: enlace 1 Gbps, 15 ms atraso propriedade, pacote 8000 bits: "  U remet: utilização – fração do tempo remet. ocupado enviando "  Pct. 1 KB cada 30 ms -> 33 kB/s vazão em enlace de 1 Gbps "  protocolo de rede limita uso de recursos físicos!quarta-feira, 28 de setembro de 11 42
  43. 43. rdt3.0: operação pare e pare e espere [rdt 3.0] : operação tipo esperequarta-feira, 28 de setembro de 11 43
  44. 44. Protocolos com paralelismo Protocolos com paralelismo paralelismo: remetente permite múltiplos pacotes “no ar”, ainda a serem reconhecidos "  intervalo de números de sequência deve ser aumentado "  buffering no remetente e/ou destinatário !  duas formas genéricas de protocolo com paralelismo: Go-Back-N, repetição seletivaquarta-feira, 28 de setembro de 11 44
  45. 45. Paralelismo: utilizaçãoutilização do canal Paralelismo aumenta aumentada Aumento de utilização por fator de 3!quarta-feira, 28 de setembro de 11 45
  46. 46. rotocolos com paralelismo Protocolos com paralelismo Go-back-N: visão geral Repetição seletiva: visão geral !  remetente: até N pacotes !  remetente: até pacotes não não reconhecidos na reconhecidos na pipeline pipeline !  destinatário: reconhece (ACK) !  destinatário: só envia ACKs pacotes individuais cumulativos !  remetente: mantém "  não envia pct ACK se temporizador para cada pct sem houver uma lacuna ACK !  remetente: tem "  se o temporizador expirar: temporizador para pct sem retransmite apenas o pacote ACK mais antigo sem ACK "  se o temporizador expirar: retransmite todos os pacotes sem ACKquarta-feira, 28 de setembro de 11 46
  47. 47. Go-Back-N Go-Back-N remetente: !  # seq. de k bits no cabeçalho do pacote !  “janela” de até N pcts consecutivos sem ACK permitidos !  ACK(n): ACK de todos pcts até inclusive # seq. n – “ACK cumulativo” "  pode receber ACKs duplicados (ver destinatário) !  temporizador para cada pacote no ar !  timeout(n): retransmite pct n e todos pcts com # seq. mais alto na janelaquarta-feira, 28 de setembro de 11 47
  48. 48. GBN:Máquina de estado estendida GBN FSM estendido no remetente rdt_send(dados) remetente if (nextseqnum < base+N) { pctenv[nextseqnum] = make_pkt(nextseqnum,dados,chksum) udt_send(pctenv[nextseqnum]) if (base = = nextseqnum) start_timer nextseqnum++ } !" else refuse_data(dados) base = 1 nextseqnum = 1 timeout start_timer Espera udt_send(pctenv[base]) rdt_rcv(pctrec) udt_send(pctenv[base+1]) && corrupt(pctrec) … udt_send(pctenv [nextseqnum-1]) rdt_rcv(pctrec) && notcorrupt(pctrec) base = getacknum(pctrec)+1 If (base = = nextseqnum) stop_timer else start_timerquarta-feira, 28 de setembro de 11 48
  49. 49. Máquina de estado estendida GBN GBN: FSM estendido no destinatário destinatário default udt_send(pctenv) rdt_rcv(pctrec) && notcurrupt(pctrec) !" && hasseqnum(pctrec,expectedseqnum) expectedseqnum = 1 Espera extract(pctrec,dados) pctenv = deliver_data(dados) make_pkt(expectedseqnum,ACK,chksum) pctenv = make_pkt(expectedseqnum,ACK,chksum) udt_send(pctenv) expectedseqnum++ apenas ACK: sempre envia ACK para pct recebido corretamente com # seq. mais alto em ordem "  pode gerar ACKs duplicados "  só precisa se lembrar de expectedseqnum !  pacote fora de ordem: "  descarta (não mantém em buffer) -> sem buffering no destinatário! "  reenvia ACK do pct com # seq. mais alto em ordemquarta-feira, 28 de setembro de 11 49
  50. 50. GBN em operação Go-Back-N em açãoquarta-feira, 28 de setembro de 11 50
  51. 51. Repetição seletiva Repetição seletiva !  destinatário reconhece individualmente todos os pacotes recebidos de modo correto "  mantém pcts em buffer, se for preciso, para eventual remessa em ordem para a camada superior !  remetente só reenvia pcts para os quais o ACK não foi recebido "  temporizador no remetente para cada pct sem ACK !  janela do remetente "  N # seq. consecutivos "  novamente limita #s seq. de pcts enviados, sem ACKquarta-feira, 28 de setembro de 11 51
  52. 52. Repetição seletiva: janelas Repetição seletiva: janelas de remetente, destinatário remetente destinatárioquarta-feira, 28 de setembro de 11 52
  53. 53. Repetição seletiva Repetição seletiva remetente destinatário dados de cima: pct n em [rcvbase, rcvbase +N-1] !  se próx. # seq. disponível na janela, envia pct !  envia ACK(n) !  fora de ordem: buffer timeout(n): !  em ordem: entrega !  reenvia pct n, reinicia (também entrega pcts em temporizador ordem no buffer), avança ACK(n) em [sendbase,sendbase janela para próximo pct +N]: ainda não recebido !  marca pct n como recebido pct n em [rcvbase-N,rcvbase-1] !  se n menor pct com ACK, !  ACK(n) avança base da janela para próximo # seq. sem ACK caso contrário: !  ignoraquarta-feira, 28 de setembro de 11 53
  54. 54. Repetição seletiva em Repetição seletiva em ação operaçãoquarta-feira, 28 de setembro de 11 54
  55. 55. Repetição seletiva: Repetição seletiva: dilema dilema Exemplo: !  # seq.: 0, 1, 2, 3 !  tamanho janela = 3 !  destinatário não vê diferença nos dois cenários! !  passa incorretamente dados duplicados como novos em (a) P: Qual o relacionamento entre tamanho do # seq. e tamanho de janela?quarta-feira, 28 de setembro de 11 55
  56. 56. Sumário Serviços da camada de transporte Multiplexação e demultiplexação Transporte não orientado para conexão: UDP Princípios de transferência confiável de dados 3.5 Transporte orientado para conexão: TCP Princípios de controle de congestionamentoquarta-feira, 28 de setembro de 11 56
  57. 57. TCP: Visão geral TCP: Visão geral RFCs: 793, 1122, 1323, 2018, 2581 !  ponto a ponto: !  dados full duplex: "  um remetente, um destinatário "  dados bidirecionais fluem !  cadeia de bytes confiável, em na mesma conexão ordem: "  MSS: tamanho máximo do "  sem “limites de mensagem” segmento !  paralelismo: !  orientado a conexão: "  congestionamento TCP e controle de fluxo definem "  apresentação (troca de tamanho da janela msgs de controle) inicia !  buffers de envio & recepção estado do remetente e destinatário antes da troca de dados !  fluxo controlado: "  remetente não sobrecarrega destinatárioquarta-feira, 28 de setembro de 11 57
  58. 58. Estrutura do segmento TCP TCP: Estrutura do segmento 32 bits URG: dados urgentes contagem por (quase não usado) porta origem porta destino bytes de dados (não segmentos!) ACK: # ACK número sequência válido número reconhecimento compr. não cab. usado UA P R S F janela recepção # bytes PSH: empurrar dados destinatário agora (quase não usado) soma verificação ponteiro dados urg. pode aceitar RST, SYN, FIN: opções (tamanho variável) estab. conexão (comandos setup, teardown) dados da soma de verificação da Internet aplicação (como em UDP) (tamanho variável)quarta-feira, 28 de setembro de 11 58
  59. 59. TCP: número de seqüência [#s] e ACKs do TCP#s sequência e ACKs do TCP#’s de sequência: "  “número” na cadeia de bytes do 1o byte nos dados do segmentoACKs: "  # seq do próximo byte esperado do outro lado "  ACK cumulativoP: como o destinatário trata segmentos fora de ordem "  R: TCP não diz – a critério do implementador cenário telnet simplesquarta-feira, 28 de setembro de 11 59
  60. 60. TCP: tempoe volta volta [RTT] e timeout Tempo de ida de ida e e timeout do TCP P: Como definir o valor P: Como estimar o RTT? de timeout do TCP? !  SampleRTT: tempo medido !  maior que RTT da transmissão do segmento "  mas RTT varia até receber o ACK !  muito curto: "  ignora retransmissões timeout prematuro !  SampleRTT variará; "  retransmissões queremos RTT estimado desnecessárias “mais estável” !  muito longo: baixa "  média de várias medições reação a perda de recentes, não apenas segmento SampleRTT atualquarta-feira, 28 de setembro de 11 60
  61. 61. TCP: tempo de ida e volta [RTT] e timeout EstimatedRTT = (1- #)*EstimatedRTT + #*SampleRTT !  média móvel exponencial ponderada !  influência da amostra passada diminui exponencialmente rápido !  valor típico: # = 0,125quarta-feira, 28 de setembro de 11 61
  62. 62. Amostras de RTTs estimados: Amostras de RTTs estimados quarta-feira, 28 de setembro de 11 62
  63. 63. Tempo de ida TCP: tempo dee volta e [RTT] e timeout ida e volta timeout do TCP definindo o timeout !  EstimtedRTT mais “margem de segurança” "  grande variação em EstimatedRTT -> maior margem de seg. !  primeira estimativa do quanto SampleRTT se desvia de EstimatedRTT: DevRTT = (1-$)*DevRTT + $*|SampleRTT-EstimatedRTT| (geralmente, $ = 0,25) depois definir intervalo de timeout TimeoutInterval = EstimatedRTT + 4*DevRTTquarta-feira, 28 de setembro de 11 63
  64. 64. TCP: transferência confiável de dados Transferência confiável de dados no TCP !  TCP cria serviço rdt !  retransmissões são em cima do serviço não disparadas por: confiável do IP "  eventos de timeout !  segmentos em paralelo "  ACKs duplicados !  ACKs cumulativos !  inicialmente, considera !  TCP usa único remetente TCP temporizador de simplificado: ignora ACKs duplicados retransmissão "  "  ignora controle de fluxo, controle de congestionamentoquarta-feira, 28 de setembro de 11 64
  65. 65. TCP: transferência confiável de dados eventos no remetente remetente TCP: Eventos de dados recebidos da apl.: timeout: !  cria segmento com # !  retransmite segmento seq que causou timeout !  # seq # é número da !  reinicia temporizador cadeia de bytes do ACK recebido: primeiro byte de dados !  Reconhecem-se no segmento segmentos sem ACK anteriores !  inicia temporizador, se "  atualiza o que ainda não tiver iniciado sabidamente tem ACK (pense nele como para "  inicia temporizador se o segmento mais antigo houver segmentos pendentes sem ACK) !  intervalo de expiração: TimeOutIntervalquarta-feira, 28 de setembro de 11 65
  66. 66. RemetenteTCP (simplificado) RemetenteTCP (simplificado) de dados TCP: transferência confiável NextSeqNum = InitialSeqNum NextSeqNum = InitialSeqNum SendBase = InitialSeqNum SendBase = InitialSeqNum loop (forever) { switch(event) { loop (forever) switch(event) event: data received from application above Comentário: event: data received from application above create TCP segment with sequence number NextSeqNum Comentário: if (timer currently not running) sequence number NextSeqNum create TCP segment with •  SendBase-1: último byte •  SendBase-1: último byte if (timer currently not running) cumulativo com ACK start timer start timer cumulativo com ACK pass segment to IP Exemplo: pass segment to IP Exemplo: NextSeqNum = NextSeqNum + length(dados) NextSeqNum = NextSeqNum + length(dados) •  SendBase-1 = = 71; •  SendBase-1 71; y = = 73, de modo que y 73, de modo que event: timer timeout event: timer timeout retransmit not-yet-acknowledged segment with destinatário deseja 73+ ; ; destinatário deseja 73+ retransmit not-yet-acknowledged segment with smallest sequence number smallest sequence number y > SendBase, de modo que y > SendBase, de modo que start start timer timer novos dados têm ACK novos dados têm ACK event: ACKACK received, with ACK field valueyof y event: received, with ACK field value of if (y > SendBase) { { if (y > SendBase) SendBase = y = y SendBase if (there are currently not-yet-acknowledged segments) if (there are currently not-yet-acknowledged segments) startstart timer timer } } } /* end of loop loop forever */ } /* end of forever */ quarta-feira, 28 de setembro de 11 66
  67. 67. TCP: cenários de de retransmissão TCP: cenários retransmissão Hosp. A Hosp. B Hosp. A Hosp. B Seq = Seq = 92, 8 92, 8 bytes bytes dados Seq = dados Seq = 92 timeout 100, 20 by tes d a timeout 0 dos = 10 ACK X loss Seq = Seq = 92, 8 92, 8 bytes Sendbase bytes dados dados = 100 Seq = 92 timeout SendBase = 120 = ACK 100 SendBase = 100 SendBase = 120 Timeout prematuro tempo tempo Cenário de ACK perdidoquarta-feira, 28 de setembro de 11 67
  68. 68. TCP: cenários de retransmissão Host A Host B Seq = 92, 8 bytes dados 10 0 timeout Seq = 100, 2 AC K= 0 byte s dado s X perda SendBase A CK = = 120 120 tempo Cenário ACK cumulativoquarta-feira, 28 de setembro de 11 68
  69. 69. TCP: geração de ACK TCP: geração de ACK [RFC 1122, RFC 2581]quarta-feira, 28 de setembro de 11 69
  70. 70. Erro no slide original. TCP: retransmissão rápida Retransmissão rápida Correto: 4 ACKs idênticos (1 original, 3 duplicatas). Vide RFC 2581… Erro no slide original.Retransmissão rápida !  período de timeout Correto: 4 ACKs idênticos !  se remetente recebe 3 ACKs (1 original, 3 duplicatas). relativamente grande: para os Vide RFC 2581… ele mesmos dados, longo atraso antes de "  supõe que segmento após!  período de timeout perdido reenviar pacote !  se dados com ACK foi perdido: remetente recebe 3 ACKs relativamente grande: !  detecta segmentos para os mesmos dados, ele "  retransmissão rápida: " perdidos porantes de ACKs longo atraso meio de supõe reenvia segmento antes que que segmento após duplicados reenviar pacote perdido dadosocom ACK foi perdido: temporizador expire!  detecta segmentos "  remetente geralmente "  retransmissão rápida: perdidos por meiosegmentos um envia muitos de ACKs reenvia segmento antes que duplicados o outro após o temporizador expire "  se segmento for perdido, "  remetente geralmente provavelmente haverá envia muitos segmentos um muitos ACKs duplicados após o outro para esse segmento "  se segmento for perdido, provavelmente haverá muitos11ACKs duplicadosquarta-feira, 28 de setembro de 70
  71. 71. TCP: retransmissão rápida Hosp. A Hosp. B seq # x1 seq # x2 seq # x3 ACK x1 seq # x4 X seq # x5 ACK x1 ACK x1 ACK x1 ACKs duplicados três vezes reenv ia seq X2 timeout tempoquarta-feira, 28 de setembro de 11 71
  72. 72. Algoritmo de retransmissão rápida TCP: Algoritmo retransmissão rápida: 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 } ACK duplicado para retransmissão rápida segmento já com ACKquarta-feira, 28 de setembro de 11 72
  73. 73. TCP: Controle de fluxo Controle de fluxo TCP controle de fluxo !  lado receptor da conexão TCP tem um remetente não estourará buffer do destinatário buffer de recepção: transmitindo muitos dados muito rapidamente espaço datagramas de buffer dados TCP processo da !  serviço de IP (atualmente) (no buffer) aplicação não usado compatibilização de velocidades: compatibiliza a taxa de envio do remetente !  processo da aplicação com a de leitura da pode ser lento na aplicação receptora leitura do bufferquarta-feira, 28 de setembro de 11 73
  74. 74. TCP: Controle de fluxo - funcionamento Controle de fluxo TCP: como funciona espaço !  destinatário: anuncia datagramas de buffer dados TCP processo da IP (atualmente) (no buffer) aplicação espaço de buffer não não usado usado incluindo valor de rwnd rwnd no cabeçalho do RcvBuffer segmento (suponha que destinatário TCP !  remetente: limita # de descarte segmentos fora de bytes com ACKa rwnd ordem) "  garante que buffer do !  espaço de buffer não usado: destinatário não estoura = rwnd = RcvBuffer-[LastByteRcvd - LastByteRead]quarta-feira, 28 de setembro de 11 74
  75. 75. Gerenciamento da TCP: Gerenciamento da conexão conexão TCP lembre-se: Remetente e destinatário TCP estabelecem “conexão” antes apresentação de 3 vias: que troquem segmentos etapa 1: hosp. cliente envia segmento dados SYN do TCP ao servidor !  inicializa variáveis TCP: "  especifica # seq. inicial "  #s seq.: "  sem dados "  buffers, informação de etapa 2: hosp. servidor recebe SYN, controle de fluxo (p. e. responde com segmento SYNACK RcvWindow) !  cliente: inicia a conexão "  servidor aloca buffers Socket clientSocket = new "  especifica # seq. inicial do Socket("hostname","port #"); servidor !  servidor: contactado pelo etapa 3: cliente recebe SYNACK, responde com segmento ACK, que cliente Socket connectionSocket = pode conter dados welcomeSocket.accept();quarta-feira, 28 de setembro de 11 75
  76. 76. TCP: Gerenciamento da conexão fechando uma conexão: cliente servidor fecha cliente fecha socket: FIN clientSocket.close(); etapa 1: sistema final do ACK fecha cliente envia segmento de FIN controle TCP FIN ao servidor temporizada espera ACK etapa 2: servidor recebe FIN, responde com ACK. Fecha conexão, envia FIN. fechadoquarta-feira, 28 de setembro de 11 76
  77. 77. TCP: Gerenciamento da conexão etapa 3: cliente recebe cliente servidor FIN, responde com ACK fechado FIN "  entra em “espera temporizada” – responderá com ACK ACK fechando aos FINs recebidos FIN etapa 4: servidor recebe temporizada ACK - conexão fechada ACK espera fechado Nota: Com pequena modificação, pode tratar de FINs simultâneos. fechadoquarta-feira, 28 de setembro de 11 77
  78. 78. ciclo de vida d servidor TCP ciclo de vida do servidor TCP ciclo de vida do cliente TCPo de vida donte TCP quarta-feira, 28 de setembro de 11 78
  79. 79. Sumário Serviços da camada de transporte Multiplexação e demultiplexação Transporte não orientado para conexão: UDP Princípios de transferência confiável de dados Transporte orientado para conexão: TCP 3.6 Princípios de controle de congestionamento Controle de congestionamento: TCPquarta-feira, 28 de setembro de 11 79
  80. 80. Princípios de controle de de Princípios de controle congestionamento congestionamento Congestionamento: !  informalmente: “muitas fontes enviando muitos dados muito rápido para a rede tratar” !  diferente de controle de fluxo! !  manifestações: "  pacotes perdidos (estouro de buffer nos roteadores) "  longos atrasos (enfileiramento nos buffers do roteador) !  um dos maiores problemas da rede!quarta-feira, 28 de setembro de 11 80
  81. 81. Causas / custos do congestionamento: cenário 1 Causas/custos do congestionamento: cenário 1 !  dois remetentes, dois destinatários !  um roteador, infinitos buffers !  sem retransmissão !  grandes atrasos quando congestionado !  vazão máxima alcançávelquarta-feira, 28 de setembro de 11 81
  82. 82. Causas/custos do Causas / custos do congestionamento: cenário 2 congestionamento: cenário 2 !  um roteador, buffers finitos !  retransmissão do pacote perdido pelo remetentequarta-feira, 28 de setembro de 11 82
  83. 83. Causas / custos do congestionamento: cenário 2 !  sempre: " = % %"out (vazão) in !  retransmissão “perfeita” apenas quando há perda: %" > %"out in !  retransmissão do pacote adiado (não pedido) torna %" maior in (que o caso perfeito ) para o mesmo %" out R/2 R/2 R/2 R/3 %out %out %out R/4 R/2 R/2 R/2 %in %in %in a. b. c. “custos” do congestionamento: !  mais trabalho (retransmissão) para determinada “vazão” !  retransmissões desnecessárias: enlace transporta várias cópias do pacotequarta-feira, 28 de setembro de 11 83
  84. 84. Causas/custos do Causas / custos do congestionamento: cenário 3 congestionamento: cenário 3 !  quatro remetentes P: O que acontece quando%" !  caminhos com vários saltos in e in %" aumentam ? !  timeout/retransmissãoquarta-feira, 28 de setembro de 11 84
  85. 85. Causas / custos do congestionamento: cenário 3 H % o o st u A t H o st B outro “custo” do congestionamento: !  quando pacote é descartado, qualquer capacidade de transmissão “upstream” usada para esse pacote foi desperdiçada!quarta-feira, 28 de setembro de 11 85
  86. 86. Técnicaspara controle dede Técnicas para controle congestionamento congestionamento duas técnicas amplas para controle de congestionamento: controle de controle de congestionamento fim a congestionamento fim: assistido pela rede: !  roteadores oferecem !  nenhum feedback explícito da feedback aos sistemas rede finais !  congestionamento deduzido da "  único bit indicando perda e atraso observados do congestionamento sistema final (SNA, DECbit, TCP/IP !  técnica tomada pelo TCP ECN, ATM) "  taxa explícita que o remetente deve enviar no enlace de saídaquarta-feira, 28 de setembro de 11 86
  87. 87. Exemplo:de caso: de congestionamento ATM ABR Estudo controle controle de congestionamento ATM ABR ABR: taxa de bit células RM (gerenciamento de disponível: recursos) : !  “serviço elástico” !  enviadas pelo remetente, intercaladas com células de dados !  se caminho do remetente “sobrecarregado”: !  bits na célula RM definida por comutadores (“assistido pela rede”) "  remetente deve usar largura de banda "  bit NI: sem aumento na taxa disponível (congestionamento leve) !  se caminho do remetente "  bit CI: indicação de congestionado: congestionamento "  remetente sufocado à !  células RM retornadas ao remetente taxa mínima garantida pelo destinatário, com bits intactosquarta-feira, 28 de setembro de 11 87
  88. 88. Exemplo: controle de congestionamento ATM ABR !  campo ER (explicit rate) de 2 bytes na célula RM "  comutador congestionado pode reduzir valor de ER na célula "  taxa de envio do remetente é taxa máxima admissível no caminho !  bit EFCI nas células de dados: defina como 1 no comutador congestionado "  se a célula de dados anterior à célula RM tiver EFCI definido, remetente define bit CI na célula RM retornadaquarta-feira, 28 de setembro de 11 88
  89. 89. Sumário Serviços da camada de transporte Multiplexação e demultiplexação Transporte não orientado para conexão: UDP Princípios de transferência confiável de dados Transporte orientado para conexão: TCP Princípios de controle de congestionamento 3.7 Controle de congestionamento: TCPquarta-feira, 28 de setembro de 11 89
  90. 90. Controle de controle de congestionamento TCP: congestionamento TCP: buscabuscalargura por por largura de banda de banda !  “procura por largura de banda”: aumenta taxa de transmissão no recebimento do ACK até por fim ocorrer perda; depois diminui taxa de transmissão "  continua a aumentar no ACK, diminui na perda (pois largura de banda disponível está mudando, dependendo de outras conexões na rede) ACKs sendo recebidos, X perda e diminuição de taxa de modo que aumenta taxa X taxa de emissão X X comportamento X “dente de serra” do TCP tempo !  P: Com que velocidade aumentar/diminuir? "  detalhes a seguirquarta-feira, 28 de setembro de 11 90
  91. 91. Controle de congestionamento TCP: detalhes TCP: detalhes !  remetente limita taxa limitando número de bytes sem ACK “na pipeline”: LastByteSent-LastByteAcked & cwnd "  cwnd: difere de rwnd (como, por quê?) "  remetente limitado por min(cwnd,rwnd) bytes !  aproximadamente, cwnd! cwnd taxa = bytes/seg RTT RTT !  cwnd é dinâmico, função do congestionamento de rede percebido ACK(s)quarta-feira, 28 de setembro de 11 91
  92. 92. Controle de congestionamento TCP: mais detalhes TCP: mais detalhes evento de perda de segmento: ACK recebido: aumenta reduzindo cwnd! cwnd! !  timeout: sem resposta do !  fase de partida lenta: destinatário "  aumento exponencialmente "  corta cwnd para 1 rápido (apesar do nome) no início da conexão, ou após !  3 ACKs duplicados: pelo o timeout menos alguns segmentos !  prevenção de passando (lembre-se da retransmissão rápida) congestionamento: "  aumento linear "  corta cwnd pela metade, menos agressivamente do que no timeoutquarta-feira, 28 de setembro de 11 92

×