RC - SL03 - Camada de Transporte

  • 3,320 views
Uploaded on

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

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

More in: Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
3,320
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
247
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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. Motivação Como as aplicações se comunicam?quarta-feira, 28 de setembro de 11 2
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Quem usa UDP? DNS Stream Multimídia RIP VoIP SNMP NFS Muitos outros...quarta-feira, 28 de setembro de 11 19
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. [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. [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. [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. [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. [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. [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. 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. [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. 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. 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. [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. [rdt 3.0] : em açãordt3.0 em açãoquarta-feira, 28 de setembro de 11 40
  • 41. [rdt 3.0] : em açãoquarta-feira, 28 de setembro de 11 41
  • 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. rdt3.0: operação pare e pare e espere [rdt 3.0] : operação tipo esperequarta-feira, 28 de setembro de 11 43
  • 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. 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. 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. 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. 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. 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. GBN em operação Go-Back-N em açãoquarta-feira, 28 de setembro de 11 50
  • 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. Repetição seletiva: janelas Repetição seletiva: janelas de remetente, destinatário remetente destinatárioquarta-feira, 28 de setembro de 11 52
  • 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. Repetição seletiva em Repetição seletiva em ação operaçãoquarta-feira, 28 de setembro de 11 54
  • 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. 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. 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. 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. 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. 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. 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. Amostras de RTTs estimados: Amostras de RTTs estimados quarta-feira, 28 de setembro de 11 62
  • 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. 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. 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. 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. 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. 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. TCP: geração de ACK TCP: geração de ACK [RFC 1122, RFC 2581]quarta-feira, 28 de setembro de 11 69
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  • 93. TCP: partida lenta Partida lenta do TCP !  quando conexão começa, cwnd = 1 MSS Hosp. A Hosp. B "  exemplo: MSS = 500 bytes & um segme RTT = 200 ms nto RTT "  taxa inicial = 20 kbps !  largura de banda disponível pode dois segm entos ser >> MSS/RTT "  desejável subir rapidamente para taxa respeitável quatro seg mentos !  aumenta taxa exponencialmente até o primeiro evento de perda ou quando o patamar é alcançado "  cwnd duplo a cada RTT tempo "  feito incrementando cwnd por 1 para cada ACK recebidoquarta-feira, 28 de setembro de 11 93
  • 94. Transição dentro/fora TCP: transição dentro/fora partida rápida da partida rápida ssthresh: patamar de cwnd mantido pelo TCP !  um evento de perda: define ssthresh como cwnd/2 "  lembre-se (metade) da taxa TCP quando ocorreu perda de congestionamento !  quando transição de cwnd > = ssthresh: da partida lenta para fase de prevenção de congestionamento duplicate ACK dupACKcount++ new ACK cwnd = cwnd+MSS dupACKcount = 0 !" transmite novos segmento(s), como permitido cwnd = 1 MSS ssthresh = 64 KB cwnd > ssthresh dupACKcount = 0 partida !" prevenção de lenta timeout congestionamento ssthresh = cwnd/2 cwnd = 1 MSS timeout dupACKcount = 0 retransmite segmento que falta ssthresh = cwnd/2 cwnd = 1 MSS dupACKcount = 0 retransmite segmento que faltaquarta-feira, 28 de setembro de 11 94
  • 95. TCP: prevenção dede congestionamento TCP: prevenção congestionamento !  quando cwnd > ssthresh AIMD cresce cwnd de forma linear !  ACKs: aumenta cwnd em 1 "  aumenta cwnd em 1 MSS por RTT MSS por RTT: aumento aditivo "  aborda possível !  perda: corta cwnd ao meio congestionamento mais lento que na partida lenta (perda sem timeout detectado): diminuição "  implementação: cwnd = multiplicativa cwnd + MSS/cwnd para cada ACK recebido AIMD: Additive Increase Multiplicative Decreasequarta-feira, 28 de setembro de 11 95
  • 96. congestionamento TCP: TCP: Máquina de estado visão geral partida cwnd > ssthresh prevenção lenta de cong. perda: timeout perda: timeout perda: novo ACK perda: timeout 3dupACK recup. perda: rápida 3dupACKquarta-feira, 28 de setembro de 11 96
  • 97. congestionamento TCP: detalhes TCP: Máquina de estado (detalhes)quarta-feira, 28 de setembro de 11 97
  • 98. Tipos de TCP: Tahoe e Reno Tipos populares de TCPquarta-feira, 28 de setembro de 11 98
  • 99. Resumo: controle de TCP: resumo do controle de congestionamento congestionamento TCP !  quando cwnd < ssthresh, remetente na fase de partida lenta, janela cresce exponencialmente. !  quando cwnd > = ssthresh, remetente está na fase de prevenção de congestionamento, janela cresce linearmente. !  quando ocorre o ACK duplicado triplo, ssthresh definido como cwnd/2, cwnd definido como ~ssthresh !  quando ocorre o timeout, ssthresh definido como cwnd/2, cwnd definido como 1 MSS.quarta-feira, 28 de setembro de 11 99
  • 100. TCP: Vazão Vazão do TCP !  P: Qual é a vazão média do TCP como função do tamanho da janela, RTT? "  ignorando partida lenta !  seja W o tamanho da janela quando ocorre a perda "  quando janela é W, a vazão é W/RTT "  logo após perda, janela cai para W/2, vazão para W/2RTT. "  após a vazão: 0,75 W/RTTquarta-feira, 28 de setembro de 11 100
  • 101. Futuros versões para taxas elevadas TCP: do TCP: TCP sobre pipes “longos, gordos” !  exemplo: segmentos de 1500 bytes, RTT de 100 ms, deseja vazão de 10 Gbps !  exige tamanho de janela W = 83.333 segmentos no ar !  vazão em termos da taxa de perda: !  L = 2 · 10-10 Uau! !  novas versões do TCP para alta velocidadequarta-feira, 28 de setembro de 11 101
  • 102. TCP: Equidade Equidade do TCP objetivo da equidade: se K sessões TCP compartilharem o mesmo enlace de gargalo da largura de banda R, cada uma deve ter uma taxa média de R/K conexão TCP 1 capacidade de gargalo do conexão roteador R TCP 2quarta-feira, 28 de setembro de 11 102
  • 103. TCP: Porque ele é justo? Por que o TCP é justo? duas sessões concorrentes: !  aumento aditivo dá inclinação 1, pois vazão aumenta !  diminuição multiplicativa diminui vazão proporcionalmente R compartilhamento de largura de banda igual Vazão da conexão 2 perda: diminui janela por fator de 2 prevenção de congestionamento: aumento aditivo perda: diminui janela por fator de 2 prevenção de cong.: aumento aditivo Vazão da conexão 1 Rquarta-feira, 28 de setembro de 11 103
  • 104. TCP: Porque ele é justo? Equidade (mais) equidade e UDP qquidade e conexões TCP !  aplicações de multimídia paralelas normalmente não usam !  nada impede que a TCP aplicação abra conexões "  não desejam que a taxa seja sufocada pelo paralelas entre 2 controle de hospedeiros. congestionamento !  navegadores Web fazem !  em vez disso, use UDP: isso "  envia áudio/vídeo em !  exemplo: enlace de taxa R taxa constante, tolera admitindo 9 conexões; perdas de pacotes "  nova aplicação solicita 1 TCP, recebe taxa R/10 "  nova aplicação solicita 11 TCPs, recebe R/2!quarta-feira, 28 de setembro de 11 104
  • 105. Recapitulando princípios controle de fluxo multiplexação controle de congestionamento demultiplexação casos UDP transferência confiável casos TCPquarta-feira, 28 de setembro de 11 105
  • 106. Dúvidas ?quarta-feira, 28 de setembro de 11 106
  • 107. Referências Camada de aplicação: Capítulo 3 Seções 3.1 até 3.7 (aprox. 80 páginas, 8hrs de leitura [6min/pág])quarta-feira, 28 de setembro de 11 107