A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

3: Camada de Transporte3a-1 Capítulo 3: Camada de Transporte Metas do capítulo: Ø compreender os princípios atrás dos serviços da camada de transporte:

Apresentações semelhantes


Apresentação em tema: "3: Camada de Transporte3a-1 Capítulo 3: Camada de Transporte Metas do capítulo: Ø compreender os princípios atrás dos serviços da camada de transporte:"— Transcrição da apresentação:

1

2 3: Camada de Transporte3a-1 Capítulo 3: Camada de Transporte Metas do capítulo: Ø compreender os princípios atrás dos serviços da camada de transporte: ü multiplexação/ demultiplexação ü transferência confiável de dados ü controle de fluxo ü controle de congestionamento Ø instanciação e implementação na Internet dos protocolos de transporte ü UDP ü TCP Resumo do Capítulo: Ø serviços da camada de transporte Ø multiplexação/demultiplexação Ø transporte sem conexão: UDP Ø princípios de transferência confiável de dados Ø transporte orientado a conexão: TCP ü transferência confiável ü controle de fluxo ü gerenciamento de conexões Ø princípios de controle de congestionamento Ø controle de congestionamento em TCP

3 3: Camada de Transporte3a-2 Serviços e protocolos de transporte Ø provê comunicação lógica entre processos de aplicação executando em hosts diferentes Ø protocolos de transporte executam em sistemas terminais ü emissor: fragmenta a mensagem da aplicação em segmentos e os envia para a camada de rede; ü receptor: rearranja os segmentos em mesnagens e os transmite para a camada de aplicação; Ø Mais de um protocolo de transporte disponível para as aplicações ü Internet: TCP e UDP aplicação transporte rede enlace física rede enlace física aplicação transporte rede enlace física rede enlace física rede enlace física rede enlace física rede enlace física transporte lógico fim a fim

4 3: Camada de Transporte3a-3 Camada de Rede versus Camada de Transporte Ø camada de rede : comunicação lógica entre hosts ou sistemas; Ø camada de transporte: comunicação lógica entre processos ü depende dos serviços da camada de rede ü extende os serviços da camada de rede Analogia de Casas: 12 crianças enviando cartas para 12 crianças Ø processos = crianças Ø Mensagens da aplicação = cartas no envelope Ø hosts = casas Ø Protolo de transporte = Ann e Bill Ø Protocolo da camada de rede = serviço de correio

5 3: Camada de Transporte3a-4 Multiplexação/demultiplexação aplicação transporte rede enlace física P1 aplicação transporte rede enlace física aplicação transporte rede enlace física P2 P3 P4 P1 host 1 host 2 host 3 = processo= socket entrega de segmentos recebidos para os processos da camada de apl corretos Demultiplexação no receptor: juntar dados de múltiplos processos de apl, envelopando dados com cabeçalho (usado depois para demultiplexação) Multiplexação no emissor:

6 3: Camada de Transporte3a-5 Como demultiplexação funciona Ø host recebe os datagramas IP ü Cada datagrama tem um endereço IP de origem e de destino; ü Cada datagrama carrega 1 segmento da camada de transporte; ü Cada segemento tem um número de porta de origem e um de destino ü lembrete: número de porta bem conhecido para aplicações específicas Ø host usa o endereço IP e o número de porta para direcionar o segmento para o socket apropriado; porta remetenteporta receptor 32 bits dados da aplicação (mensagem) outros campos do cabeçalho formato de segmento TCP/UDP

7 3: Camada de Transporte3a-6 Demultiplexação não orientada a conexão Ø Cria sockets com os números de porta DatagramSocket mySocket1 = new DatagramSocket(99111); DatagramSocket mySocket2 = new DatagramSocket(99222); Ø Socket UDP identificado pela 2-tupla: (endereço IP destino, no porta destino) Ø Quando o host recebe o segmetno UDP: ü Verifica o número da porta de destino no segmento ü Direciona o segmento UDP para o socket correspondente ao número da porta; Ø Datagramas IP com diferentes endereços IP de origem e/ou números de porta de origem são direcionados para o mesmo socket

8 3: Camada de Transporte3a-7 Demultiplexação não orientada a conexão (cont) DatagramSocket serverSocket = new DatagramSocket(6428); Client IP:B P3 client IP: A P1 P3 server IP: C SP: 6428 DP: 9157 SP: 9157 DP: 6428 SP: 6428 DP: 5775 SP: 5775 DP: 6428 SP provê endereço de retorno

9 3: Camada de Transporte3a-8 Demultiplexação orientada a conexão Ø Identificação do socket, 4-tupla: ü endereço IP de origem ü número da porta de origem ü endereço IP de destino ü número da porta de destino Ø Hosts receptor usa estes valores da tupla para direcionar os segmentos para o socket apropriado Ø host servidor deve suportar múltiplos sockets TCP simultaneamente: ü Cada socket é identificado por sua 4-tupla Ø servidores Web tem diferentes sockets para cada cliente ü HTTP não persistente tem diferentes sockets para cada requisição

10 3: Camada de Transporte3a-9 Demultiplexação orientada a conexão (cont) cliente IP:B P3 cliente IP: A P1 P3 servidor IP: C SP: 80 DP: 9157 SP: 9157 DP: 80 SP: 80 DP: 5775 SP: 5775 DP: 80 P4

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

12 3: Camada de Transporte3a-11 Mais sobre UDP Ø muito utilizado para apls. de meios contínuos (voz, vídeo) ü tolerantes de perdas ü sensíveis à taxa de transmissão Ø outros usos de UDP (por quê?): ü DNS (nomes) ü SNMP (gerenciamento) Ø transferência confiável com UDP: incluir confiabilidade na camada de aplicação ü recuperação de erro específica à apl.! porta origemporta dest. 32 bits Dados de aplicação (mensagem) UDP segment format comprimento checksum Comprimento em bytes do segmento UDP, incluindo cabeçalho

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

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

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

16 3: Camada de Transporte3a-15 Transferência confiável de dados (rdt): como começar Etapas: Ø desenvolver incrementalmente os lados remetente, receptor do protocolo RDT Ø considerar apenas fluxo unidirecional de dados ü mas info de controle flui em ambos os sentidos! Ø Usar máquinas de estados finitos (FSM) p/ especificar remetente, receptor estado: neste estado o próximo estado é determinado unicamente pelo próximo evento estado 1 estado 2 evento causando transição de estados ações tomadas na transição de estado evento ações

17 3: Camada de Transporte3a-16 Rdt1.0: transferência confiável usando um canal confiável Ø canal subjacente perfeitamente confiável ü não tem erros de bits ü não tem perda de pacotes Ø FSMs separadas para remetente, receptor: ü remetente envia dados pelo canal subjacente ü receptor recebe dados do canal subjacente

18 3: Camada de Transporte3a-17 Rdt2.0: canal com erros de bits Ø canal subjacente pode inverter bits no pacote ü lembre-se: checksum UDP pode detectar erros de bits Ø a questão: como recuperar dos erros? ü reconhecimentos (ACKs): receptor avisa explicitamente ao remetente que pacote chegou bem ü reconhecimentos negativos (NAKs): receptor avisa explicitamente ao remetente que pacote tinha erros ü remetente retransmite pacote ao receber um NAK ü cenários humanos usando ACKs, NAKs? novos mecanismos em rdt2.0 (em relação ao rdt1.0 ): ü deteção de erros ü realimentação pelo receptor: msgs de controle (ACK,NAK) receptor->remetente

19 3: Camada de Transporte3a-18 rdt2.0: especificação da FSM FSM do remetenteFSM do receptor

20 3: Camada de Transporte3a-19 rdt2.0: em ação (sem erros) FSM do remetenteFSM do receptor

21 3: Camada de Transporte3a-20 rdt2.0: em ação (cenário de erro) FSM do remetenteFSM do receptor

22 3: Camada de Transporte3a-21 rdt2.0 tem uma falha fatal! O que acontece se ACK/NAK com erro? Ø Remetente não sabe o que passou no receptor! Ø não se pode apenas retransmitir: possibilidade de pacotes duplicados O que fazer? Ø remetente usa ACKs/NAKs p/ ACK/NAK do receptor? E se perder ACK/NAK do remetente? Ø retransmitir, mas pode causar retransmissão de pacote recebido certo! Lidando c/ duplicação: Ø remetente inclui número de seqüência p/ cada pacote Ø remetente retransmite pacote atual se ACK/NAK recebido com erro Ø receptor descarta (não entrega) pacote duplicado Remetente envia um pacote, e então aguarda resposta do receptor para e espera

23 3: Camada de Transporte3a-22 rdt2.1: remetente, trata ACK/NAKs c/ erro

24 3: Camada de Transporte3a-23 rdt2.1: receptor, trata ACK/NAKs com erro

25 3: Camada de Transporte3a-24 rdt2.1: discussão Remetente: Ø no. de seq no pacote Ø bastam dois nos. de seq. (0,1). Por quê? Ø deve checar se ACK/NAK recebido tinha erro Ø duplicou o no. de estados ü estado deve lembrar se pacote corrente tem no. de seq. 0 ou 1 Receptor: Ø deve checar se pacote recebido é duplicado ü estado indica se no. de seq. esperado é 0 ou 1 Ø note: receptor não tem como saber se último ACK/NAK foi recebido bem pelo remetente

26 3: Camada de Transporte3a-25 rdt2.2: um protocolo sem NAKs Ø mesma funcionalidade que rdt2.1, só com ACKs Ø ao invés de NAK, receptor envia ACK p/ último pacote recebido bem ü receptor deve incluir explicitamente no. de seq do pacote reconhecido Ø ACK duplicado no remetente resulta na mesma ação que o NAK: retransmite pacote atual FSM do remetente !

27 3: Camada de Transporte3a-26 rdt3.0: canais com erros e perdas Nova suposição: canal subjacente também pode perder pacotes (dados ou ACKs) ü checksum, no. de seq., ACKs, retransmissões podem ajudar, mas não serão suficientes P: como lidar com perdas? ü remetente espera até ter certeza que se perdeu pacote ou ACK, e então retransmite ü eca!: desvantagens? Abordagem: remetente aguarda um tempo razoável pelo ACK Ø retransmite e nenhum ACK recebido neste intervalo Ø se pacote (ou ACK) apenas atrasado (e não perdido): ü retransmissão será duplicada, mas uso de no. de seq. já cuida disto ü receptor deve especificar no. de seq do pacote sendo reconhecido Ø requer temporizador

28 3: Camada de Transporte3a-27 rdt3.0: remetente

29 3: Camada de Transporte3a-28 rdt3.0 em ação

30 3: Camada de Transporte3a-29 rdt3.0 em ação

31 3: Camada de Transporte3a-30 Desempenho de rdt3.0 Ø rdt3.0 funciona, porém seu desempenho é muito ruim Ø exemplo: enlace de 1 Gbps, retardo fim a fim de 15 ms, pacote de 1KB: ü Utilização: fração do tempo remetente ocupado ü pac. de 1KB a cada 30 mseg -> vazão de 33kB/seg num enlace de 1 Gbps ü protocolo limita uso dos recursos físicos! T transmitir = 8kb/pkt 10**9 b/sec = 8 microsec L (tamanho do pacote - bits) R (taxa de transmissão, bps) = U emissor = = microsegundos L / R RTT + L / R =

32 3: Camada de Transporte3a-31 rdt3.0: operação para e espera bit primeiro pacote transmitido, t = 0 emissor receptor RTT último bit transmitido, t = L / R bit do primeiro pacote recebido último bit do pacote recebido, envia ACK ACK recebido, envia próximo pacote, t = RTT + L / R U emissor = = microsegundos L / R RTT + L / R =

33 3: Camada de Transporte3a-32 Protocolos dutados (pipelined) Dutagem (pipelining): remetente admite múltiplos pacotes em trânsito, ainda não reconhecidos ü faixa de números de seqüência deve ser aumentada ü buffers no remetente e/ou no receptor Ø Duas formas genéricas de protocolos dutados: volta-N, retransmissão seletiva

34 3: Camada de Transporte3a-33 Pipelining: aumenta utilização bit primeiro pacote transmitido, t = 0 emissorreceptor RTT último bit transmitido, t = L / R primeiro bit do pacote recebido último bit recebido, envia ACK ACK recebido, envia próximo pacote, t = RTT + L / R último bit do 2 o pacote recebido, envia ACK último bit do 3 o pacote recebido, envia ACK Aumenta a utilização de um fator de 3 U emissor = = microsegundos 3*L / R RTT + L / R =

35 3: Camada de Transporte3a-34 Volta-N Remetente: Ø no. de seq. de k-bits no cabeçalho do pacote Ø admite janela de até N pacotes consecutivos não reconhecidos Ø ACK(n): reconhece todos pacotes, até e inclusive no. de seq n - ACK cumulativo ü pode receber ACKs duplicados (veja receptor) Ø temporizador para cada pacote em trânsito Ø timeout(n): retransmite pacote n e todos os pacotes com no. de seq maiores na janela

36 3: Camada de Transporte3a-35 Volta-N: FSM estendida do remetente

37 3: Camada de Transporte3a-36 Volta-N: FSM estendida do receptor receptor simples: Ø usa apenas ACK: sempre envia ACK para pacote recebido bem com o maior no. de seq. em-ordem ü pode gerar ACKs duplicados só precisa se lembrar do expectedseqnum Ø pacote fora de ordem: ü descarta (não armazena) -> receptor não usa buffers! ü manda ACK de pacote com maior no. de seq em-ordem

38 3: Camada de Transporte3a-37 Volta-N em ação

39 3: Camada de Transporte3a-38 Retransmissão seletiva Ø receptor reconhece individualmente todos os pacotes recebidos corretamente ü armazena pacotes no buffer, conforme precisa, para posterior entrega em-ordem à camada superior Ø remetente apenas re-envia pacotes para os quais ACK não recebido ü temporizador de remetente para cada pacote sem ACK Ø janela do remetente ü N nos. de seq consecutivos ü outra vez limita nos. de seq de pacotes enviados, mas ainda não reconhecidos

40 3: Camada de Transporte3a-39 Retransmissão seletiva: janelas de remetente, receptor

41 3: Camada de Transporte3a-40 Retransmissão seletiva dados de cima: Ø se próx. no. de seq na janela, envia pacote timeout(n): Ø reenvia pacote n, reiniciar temporizador ACK(n) em [sendbase,sendbase+N]: Ø marca pacote n recebido Ø se n for menor pacote não reconhecido, avança base da janela ao próx. no. de seq não reconhecido pacote n em [rcvbase, rcvbase+N-1] Ø envia ACK(n) Ø fora de ordem: buffer Ø em ordem: entrega (tb. entrega pacotes em ordem no buffer), avança janela p/ próxima pacote ainda não recebido pacote n em [rcvbase-N,rcvbase-1] Ø ACK(n) senão: Ø ignora receptor remetente

42 3: Camada de Transporte3a-41 Retransmissão seletiva em ação

43 3: Camada de Transporte3a-42 Retransmissão seletiva: dilema Exemplo: Ø nos. de seq : 0, 1, 2, 3 Ø tam. de janela =3 Ø receptor não vê diferença entre os dois cenários! Ø incorretamente passa dados duplicados como novos em (a) Q: qual a relação entre tamanho de no. de seq e tamanho de janela?

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

45 3: Camada de Transporte3a-44 TCP: estrutura do segmento no. porta origem no. porta dest 32 bits dados da aplicação (tam. variável) número de seqüência número de reconhecimento janela receptor ptr dados urg. checksum F SR PAU tam. cab. sem uso Opções (tam. variável) URG: dados urgentes (pouco usados) ACK: no. ACK válido PSH: envia dados já (pouco usado) RST, SYN, FIN: gestão de conexão (comandos de estabelecimento, liberação) no. bytes rcpt quer aceitar contagem de dados por bytes (não segmentos!) checksum Internet (como UDP)

46 3: Camada de Transporte3a-45 TCP: n o s. de seq. e ACKs N o s. de seq.: ü númerodentro do fluxo de bytes do primeiro byte de dados do segmento ACKs: ü n o de seq do próx. byte esperado do outro lado ü ACK cumulativo P: como receptor trata segmentos fora da ordem? ü R: espec do TCP omissa - deixado ao implementador Estação A Estação B Seq=42, ACK=79, data = C Seq=79, ACK=43, data = C Seq=43, ACK=80 Usuário tecla C A reconhece chegada do C ecoado B reconhece chegada de C, ecoa C de volta tempo cenário simples de telnet

47 3: Camada de Transporte3a-46 TCP: Tempo de Resposta (RTT) e Temporização P: como escolher valor do temporizador TCP? Ø maior que o RTT ü note: RTT pode variar Ø muito curto: temporização prematura ü retransmissões são desnecessárias Ø muito longo: reação demorada à perda de segmentos P: como estimar RTT? RTTamostra : tempo medido entre a transmissão do segmento e o recebimento do ACK correspondente ü ignora retransmissões, segmentos com ACKs cumulativos RTTamostra vai variar, queremos amaciador de RTT estimado usa várias medições recentes, não apenas o valor corrente ( RTTamostra)

48 3: Camada de Transporte3a-47 TCP: Tempo de Resposta (RTT) e Temporização RTT_estimado = (1- )* RTT_estimado + x*RTT_amostra Ø média corrente exponencialmente ponderada Ø influência de cada amostra diminui exponencialmente com o tempo valor típico de : Escolhendo o intervalo de temporização RTT_estimado mais uma margem de segurança variação grande em RTT_estimado -> margem de segurança maior Temporização = RTT_estimado + 4*Desvio Desvio = (1- )* Desvio + *|RTT_amostra - RTT_estimado| valor típico de : 0.25

49 3: Camada de Transporte3a-48 Exemplo estimativa RTT

50 3: Camada de Transporte3a-49 TCP: transferência confiável de dados Ø TCP cria serviço rdt sobre o serviço não confiável IP Ø Utiliza pipeline para enviar segmentos Ø ACKS cumulativos Ø TCP usa temporizador para retransmissão Ø Retransmissões são disparadas por: ü timeout ü Acks duplicados Ø Inicialmente considere um TCP emissor simplificado: ü ignore acks duplicados ü ignore controle de fluxo e controle de congestionamento;

51 3: Camada de Transporte3a-50 Eventos doTCP emissor: Dados recebidos da aplic: Ø Cria o segmento com n o de seq X Ø seq X é o número do primeiro byte do segmento Ø Inicia o temporizador se ele não foi iniciado anteriormente Intervalo de expiração: TimeOutInterval timeout: Ø Retransmite o segmento que causou o timeout Ø Reinicializa o temporizador Ack recebido: Ø Se reconhece segmentos não reconhecidos anteriormente ü Atualiza a informação sobre pacotes reconhedidos ü Inicia o temporizador se existem ainda segmentos não reconhecidos

52 3: Camada de Transporte3a-51 TCP: transfe- rência confiável de dados 00 sendbase = número de seqüência inicial 01 nextseqnum = número de seqüência inicial loop (forever) { 04 switch(event) 05 event: dados recebidos da aplicação acima 06 cria segmento TCP com número de seqüência nextseqnum 07 inicia temporizador para segmento nextseqnum 08 passa segmento para IP 09 nextseqnum = nextseqnum + comprimento(dados) 10 event: expirado temporizador de segmento c/ no. de seqüência y 11 retransmite segmento com número de seqüência y 12 calcula novo intervalo de temporização para segmento y 13 reinicia temporizador para número de seqüência y 14 event: ACK recebido, com valor de campo ACK de y 15 se (y > sendbase) { /* ACK cumulativo de todos dados até y */ 16 cancela temporizadores p/ segmentos c/ nos. de seqüência < y 17 sendbase = y 18 } 19 senão { /* é ACK duplicado para segmento já reconhecido */ 20 incrementa número de ACKs duplicados recebidos para y 21 if (número de ACKs duplicados recebidos para y == 3) { 22 /* TCP: retransmissão rápida */ 23 reenvia segmento com número de seqüência y 24 reinicia temporizador para número de seqüência y 25 } 26 } /* fim de loop forever */ Remetente TCP simplificado

53 3: Camada de Transporte3a-52 TCP: cenários de retransmissão Estação A Seq=92, 8 bytes de dados ACK=100 perda temporização tempo cenário do ACK perdido Estação B X Seq=92, 8 bytes de dados ACK=100 Host A Seq=100, 20 bytes de dados ACK=100 Temp.p/ Seq=92 temporização prematura, ACKs cumulativos Host B Seq=92, 8 bytes de dados ACK=120 Seq=92, 8 bytes de dados Temp. p/ Seq=100 ACK=120 tempo

54 3: Camada de Transporte3a-53 TCP: cenários de retransmissão (cont) Host A Seq=92, 8 bytes data ACK=100 loss timeout Cenário de ACK cumulativo Host B X Seq=100, 20 bytes data ACK=120 time

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

56 3: Camada de Transporte3a-55 Fast Retransmit Ø Período de timeout é geralmente longo: ü Longo atraso até a retransmissão do segmento perdido Ø Detectar segmentos perdidos via ACKs duplicados ü Emissores geralmente enviam vários segmentos ü Se um segmento é perdido, provavelmente vão ser recebidos ACKs duplicados Ø Se o emissor recebe 3 ACKs para o mesmo segmento, supõe que o segemtno subseqüente foi perdido: ü fast retransmit: retransmite o segmetno antes que o temporizador expire

57 3: Camada de Transporte3a-56 evento: ACK recebido, com valor de ACK igual a y if(y > SendBase) { SendBase = y if (existem segemtnos ainda não reconhecidos) inicializa o temporizador } else { incrementa o contador de ACKs duplicados para y if (contador de ACKs duplicados para y = 3) { retransmite o segmento com n o seq y } Algoritmo Fast retransmit: Um ACK duplicado para um segmento já reconhecido previamente fast retransmit

58 3: Camada de Transporte3a-57 remetente não esgotaria buffers do receptor por transmitir muito, ou muito rápidamente controle de fluxo TCP: Controle de Fluxo Ø Lado receptor de uma conexão TCP tem um buffer de recepção: Ø Processo da aplicação pode ser lento para retirar os dados do buffer Ø Serviço de compatibilização de velocidades: compatibilizar a taxa de envio do emissor com a taxa de recebimento dos dados da aplicação do receptor

59 3: Camada de Transporte3a-58 Controle de Fluxo TCP: como funciona ? (Suponha que o TCP receptor discarte pacotes fora de ordem) = RcvWindow = RcvBuffer-[LastByteRcvd - LastByteRead] Ø receptor: explicitamente avisa o remetente da quantidade de espaço livre disponível (muda dinamicamente) campo RcvWindow no segmento TCP remetente: mantém a quantidade de dados transmitidos, porém ainda não reconhecidos, menor que o valor mais recente de RcvWindow ü Garante que não tenha overflow no buffer do receptor

60 3: Camada de Transporte3a-59 TCP: Gerenciamento de Conexões Lembrete: Remetente, receptor TCP estabelecem conexão antes de trocar segmentos de dados Ø inicializam variáveis TCP: ü nos. de seq. buffers, info s/ controle de fluxo (p.ex. RcvWindow ) Ø cliente: iniciador de conexão Socket clientSocket = new Socket("hostname","port number"); Ø servidor: contactado por cliente Socket connectionSocket = welcomeSocket.accept(); Inicialização em 3 tempos: Passo 1: sistema cliente envia segmento de controle SYN do TCP ao servidor ü especifica no. inicial de seq ü sem dados Passo 2: sistema servidor recebe SYN, responde com segmento de controle SYNACK ü aloca buffers ü especifica no. inicial de seq. Passo 3: sistema cliente recebe SYNACK, responde com um segmento de ACK, que pode conter dados

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

62 3: Camada de Transporte3a-61 TCP: Gerenciamento de Conexões (cont.) Passo 3: cliente recebe FIN, responde com ACK. ü Entre em espera temporizada - responderá com ACK a FINs recebidos Step 4: servidor, recebe ACK. Conexão encerrada. Note: com pequena modificação, consegue tratar de FINs simultâneos. cliente FIN servidor ACK FIN fechando fechada espera temporizada fechada

63 3: Camada de Transporte3a-62 TCP: Gerenciamento de Conexões (cont.) Ciclo de vida de cliente TCP Ciclo de vida de servidor TCP

64 3: Camada de Transporte3a-63 Princípios de Controle de Congestionamento Congestionamento: Ø informalmente: muitas fontes enviando muitos dados muito rapidamente para a rede poder tratar Ø diferente de controle de fluxo! Ø manifestações: ü perda de pacotes (esgotamento de buffers em roteadores) ü longos atrasos (enfileiramento nos buffers dos roteadores) Ø um dos 10 problemas mais importantes em redes!

65 3: Camada de Transporte3a-64 Causas/custos de congestionamento: cenário 1 Ø dois remetentes, dois receptores Ø um roteador, buffers infinitos Ø sem retransmissão Ø grandes retardos qdo. congestionada Ø vazão máxima alcançável

66 3: Camada de Transporte3a-65 Causas/custos de congestionamento: cenário 2 Ø Um roteador, buffers finitos Ø retransmissão pelo remetente de pacote perdido Buffer finito compatilhado Host A in : dados originais Host B out ' in : dados originais, mais dados retransmitidos

67 3: Camada de Transporte3a-66 Causas/custos de congestionamento: cenário 2 Ø sempre: (goodput) Ø retransmissão perfeito apenas quando perda: Ø retransmissão de pacote atrasado (não perdido) faz maior (que o caso perfeito) para o mesmo in out = in out > in out custos de congestionamento: Ø mais trabalho (retransmissão) para dado goodput Ø retransmissões desnecessárias: enviadas múltiplas cópias do pacote

68 3: Camada de Transporte3a-67 Causas/custos de congestionamento: cenário 3 Ø quatro remetentes Ø caminhos com múltiplos enlaces Ø temporização/retransmissão in P: o que acontece à medida que e crescem ? in Buffer finito compartilhado Host A in : dados originais Host B out ' in : dados originais, mais dados retransmitidos

69 3: Camada de Transporte3a-68 Causas/custos de congestionamento: cenário 3 Outro custo de congestionamento: Ø quando pacote é descartado, qq. capacidade de transmissão já usada (antes do descarte) para esse pacote foi desperdiçado! HostAHostA HostBHostB o u t

70 3: Camada de Transporte3a-69 Abordagens de controle de congestionamento Controle de congestionamento fim a fim : Ø não tem realimentação explícita pela rede Ø congestionamento inferido das perdas, retardo observados pelo sistema terminal Ø abordagem usada pelo TCP Controle de congestionamento com apoio da rede: Ø roteadores realimentam os sistemas terminais ü bit único indicando congestionamento (SNA, DECbit, TCP/IP ECN, ATM) ü taxa explícita p/ envio pelo remetente Duas abordagens amplas para controle de congestionamento:

71 3: Camada de Transporte3a-70 Estudo de caso: controle de congestionamento no ABR da ATM ABR: available bit rate: Ø serviço elástico Ø se caminho do remetente sub-carregado: ü remetente deveria usar banda disponível Ø se caminho do remetente congestionado: ü remetente reduzido à taxa mínima garantida células RM (resource management): Ø enviadas pelo remetente, intercaladas com células de dados Ø bits na célula RM iniciados por comutadores (apoio da rede) ü bit NI: não aumente a taxa (congestionamento moderado) ü bit CI: indicação de congestionamento Ø células RM devolvidos ao remetente pelo receptor, sem alteração dos bits

72 3: Camada de Transporte3a-71 Estudo de caso: controle de congestionamento em ABR da ATM Ø Campo ER (explicit rate) de 2 bytes na célula RM ü comutador congestionado pode diminuir valor ER na célula ü taxa do remetente assim ajustada p/ menor valor possível entre os comutadores do caminho Ø bit EFCI em células de dados ligado por comutador congestionado ü se EFCI ligado na célula de dados antes da célula RM, receptor liga bit CI na célula RM devolvida

73 3: Camada de Transporte3a-72 TCP: Controle de Congestionamento Ø controle fim a fim (sem apoio da rede) Ø taxa de transmissão limitada pela tamanho da janela de congestionamento: LastByteSent-LastByteAcked CongWin CongWin é dinâmica, e é função do congestionamento na rede; Como TCP detecta congestionamento? Ø Evento de perda = timeout ou 3 acks duplicados TCP emissor reduz taxa de transmissão ( CongWin ) depois de um evento de perda Três mecanismos: ü AIMD ü slow start ü conservative after timeout events

74 3: Camada de Transporte3a-73 TCP: Controle de Congestionamento Ø w segmentos, cada um c/ MSS bytes, enviados por RTT: throughput = w * MSS RTT Bytes/sec Congwin

75 3: Camada de Transporte3a-74 TCP: Controle de Congestionamento Ø duas fases ü partida lenta ü evitar congestionamento Ø variáveis importantes: Congwin threshold: define limiar entre fases de partida lenta, controle de congestionamento Øsondagem para banda utilizável: idealmente: transmitir o mais rápido possível ( Congwin o máximo possível) sem perder pacotes aumentar Congwin até perder pacotes (congestionamento) perdas: diminui Congwin, depois volta a à sondagem (aumento) novamente

76 3: Camada de Transporte3a-75 TCP AIMD multiplicative decrease (decréscimo multiplicativo: reduz CongWin pela metade depois de um evento de perda additive increase (crescimento aditivo): aumenta CongWin de 1 MSS a cada RTT na ausência de um evento de perda: probing Conexão TCP de longa duração

77 3: Camada de Transporte3a-76 TCP: Partida lenta (Slow Start) Quando a conexão começa, CongWin = 1 MSS ü Exemplo: MSS = 500 bytes & RTT = 200 msec ü Taxa inicial = 20 kbps Ø A banda disponível deve ser >> MSS/RTT Ø Quando a conexão começa, aumenta a taxa exponencialmente até o primeiro evento de perda Ø Resumo: taxa inicial baixa, mais cresce rapidamente (crescimento exponencial)

78 3: Camada de Transporte3a-77 TCP: Partida lenta (slow start) Ø Quando a conexão começa, aumenta a taxa exponencialmente até que ococra uma perda Dobra CongWin a cada RTT, através do incremento de CongWin, a cada ACK recebido inicializa: Congwin = 1 for (cada segmento c/ ACK) Congwin++ until (evento de perda OR CongWin > threshold) Estação A um segmento RTT Estação B tempo dois segmentos quqtro segmentos Algoritmo Partida Lenta

79 3: Camada de Transporte3a-78 Refinamento Ø Depois de 3 DupACKs: CongWin é reduzida a metade ü Janela cresce linearmente Ø Mas depois de um evento de timeout: CongWin é reduzida a 1 MSS; ü Janela cresce exponencialmente até o valor do threshold, e depois cresce linearmente o recebimento de 3 ACKs duplicados indica que a rede tem condição de transmitir alguns segmentos Ocorrência de timeout antes de 3 ACKs duplicados é mais alarmante Filosofia :

80 3: Camada de Transporte3a-79 Refinamento (mais) Q: Quando o crescimento deve mudar de exponencial para linear ? A: Quando CongWin atinge 1/2 do seu valor antes do timeout. Implementação: Ø Threshold variável Ø Quando ocorre uma perda, faz-se Threshold = CongWin/2

81 3: Camada de Transporte3a-80 TCP: Prevenção do Congestionamento (congestion Avoidance /* partida lenta acabou */ /* Congwin > threshold */ Until (event de perda) { cada w segmentos reconhecidos: Congwin++ } threshold = Congwin/2 Congwin = 1 faça partida lenta 1 1: TCP Reno pula partida lenta (recuperação rápida) depois de três ACKs duplicados prevenção congestionamento

82 3: Camada de Transporte3a-81 Resumo: Controle de Congestionamento Quando CongWin está abaixo do Threshold, o emissor está na fase de slow-start, e a janela cresce exponencialmente Quando CongWin está acima do Threshold, o emissor está na fase de congestion-avoidance, e a janela cresce linearmente Quando são recebidos três ACK duplicados, faz-se Threshold = CongWin/2 e CongWin = Threshold. Quando ocorre um timeout, faz-se Threshold = CongWin/2 e CongWin = 1 MSS.

83 3: Camada de Transporte3a-82 Meta de eqüidade: se N sessões TCP compartilham o mesmo enlace de gargalo, cada uma deve ganhar 1/N da capacidade do enlace Eqüidade TCP TCP conexão 1 Roteador gargalo capacidade R TCP conexão 2

84 3: Camada de Transporte3a-83 Por quê TCP é justo? Duas sessões concorrentes: Ø Aumento aditivo dá gradiente de 1, enquanto vazão aumenta Ø decrementa multiplicativa diminui vazão proporcionalmente R R compartilhamento igual da banda Vazão da conexão 1 Vazão da conexão 2 evitar congestionamento: aumento aditivo perda: diminui janela por fator de 2 evitar congestionamento: aumento aditivo perda: diminui janela por fator de 2

85 3: Camada de Transporte3a-84 Eqüidade (mais) Eqüidade e UDP Ø Aplic. Multimídia geralmente não usam TCP ü Não desejam que a taxa seja reduzida pelo controle de congestionamento Ø Geralmente usam UDP: ü audio/video a taxa constante, toleram perdas de pacotes Ø Área de pesquisa: TCP friendly Eqüidade e conexões TCP paralelas Ø Nada previne que aplic. abram várias conexões simultânceas entre os 2 hosts; Ø Wrowsers fazem isto Ø Exemplo: enlace com taxa igual a R, com 9 conexões; ü Nova aplic. requer uma conexão TCP, recebe R/10 da taxa ü Nova aplic. requer 11 conexões TCP, recebe R/2 da taxa

86 3: Camada de Transporte3a-85 TCP: modelagem de latência P: Quanto tempo custa para receber um objeto de um servidor WWW depois de enviar o pedido? Ignorando o congestionamento, a latência é influenciada por: Ø Estabelecimento de conexão TCP Ø retardo de transferência de dados Ø Slow start Notação, suposições: Ø Supomos um enlace entre cliente e servidor de taxa R Ø Supomos: janela de congestionamento fixo, W segmentos Ø S: MSS (bits) Ø O: tamanho do objeto (bits) Ø sem retransmissões (sem perdas, sem erros) Tamanho da janela: Ø Assume-se: janela de transmissão fixa, igual a w segmentos; Ø Depois janelas dinâmicas, modelando slow start

87 3: Camada de Transporte3a-86 Janela de congestionamento de tamanho fixo (1) Primeiro caso: WS/R > RTT + S/R: ACK do primeiro segmento na janela chega antes de enviar todos dados na janela latência = 2RTT + O/R

88 3: Camada de Transporte3a-87 Janela de congestionamento de tamanho fixo (2) Segundo caso: Ø WS/R < RTT + S/R: aguarda ACK depois de enviar todos os dados na janela latência = 2RTT + O/R + (K-1)[S/R + RTT - WS/R]

89 3: Camada de Transporte3a-88 TCP: modelagem de latência: Slow Start(1) Ø Agora supomos que a janela cresce de acordo com o algoritmo de Slow Start. Ø Mostramos que a latência de um objeto de tamanho O é: Onde: - P é o número de vezes TCP para no servidor: - onde Q é o número de vezes que o servidor pararia se o objeto fosse de tamanho infinito. - e K é o número de janelas que cobrem o objeto.

90 3: Camada de Transporte3a-89 TCP: modelagem de latência: Slow Start(2) Exemplo: O/S = 15 segmentos K = 4 janelas Q = 2 P = min{K-1,Q} = 2 Servidor para P=2 vezes Componentes da Latência: 2 RTT for connection estab and request O/R to transmit object time server idles due to slow start Servidor para: P = min{K-1,Q} vezes

91 3: Camada de Transporte3a-90 TCP: modelagem de latência: (3) R S R S RTTP R O R S R S R O TempoBloqueioRTT R O P k P k P p p )12(][2 ]2[2 2latencia tempo de bloqueio após a k-ésima janela 2 1 R S RTT R S k até quando o servidor recebe reconhecimento tempo quando o servidor inicia o envio do segmento RTT R S tempo para enviar a k-ésima janela 2 1 R S k RTT inicia conexão TCP pede objeto primeira janela = S/R segunda janela = 2S/R terceira janela = 4S/R quarta janela = 8S/R transmissão completa objeto entregue tempo no cliente tempo no servidor

92 3: Camada de Transporte3a-91 Modelagem HTTP Ø Assuma que páginas Web consistem de: ü 1 página HTML base (com tamanho igual a O bits) ü M imagens (cada uma com O bits) Ø HTTP não-persistente : ü M+1 conexões TCP em série ü Tempo de resposta = (M+1)O/R + (M+1)2RTT + soma dos períodos de inatividade Ø HTTP persistente : ü 2 RTT para requisitar e receber o arquivo base HTML ü 1 RTT para requisitar e receber M imagens ü Tempo de resposta = (M+1)O/R + 3RTT + soma dos períodos de inatividade Ø HTTP não-persistente com X conexões paralelas ü 1 TCP conexão para o arquivo base ü M/X conjuntos de conexões paralelas para as imagens ü Tempo de resposta = (M+1)O/R + (M/X + 1)2RTT + soma dos períodos de inatividade

93 3: Camada de Transporte3a Kbps 100 Kbps 1 Mbps 10 Mbps HTTP: tempo de resposta (em segundos) RTT = 100 msec, O = 5 Kbytes, M=10 e X=5 Para redes com valores de banda baixos, o tempo de conexão e resposta e domindado pelo tempo de transmissão Conexões persistentes não apresentam melhora significativa em relação a conexões paralelas não-persistente persistente paralela não- persistente

94 3: Camada de Transporte3a Kbps 100 Kbps 1 Mbps 10 Mbps não-persistente persistente paralela não- persistente HTTP: tempo de resposta (em segundos) RTT =1 seg, O = 5 Kbytes, M=10 e X=5 Para valores grandes de RTT, o tempo de resposta é dominado pelo atraso do estabelecimento da conexão e slow start. Conexões persistentes possibilita uma melhora importante para a redução do atraso: particularmente em redes com grandes valores de atrasoXbanda (delay bandwidth)

95 3: Camada de Transporte3a-94 Capítulo 3: Resumo Ø Princípios atrás dos serviços da camada de transporte: ü multiplexação/ demultiplexação ü transferência confiável de dados ü controle de fluxo ü controle de congestionamento Ø instanciação e implementação na Internet ü UDP ü TCP Próximo capítulo: Ø saímos da borda da rede (camadas de aplicação e transporte) Ø entramos no núcleoda rede


Carregar ppt "3: Camada de Transporte3a-1 Capítulo 3: Camada de Transporte Metas do capítulo: Ø compreender os princípios atrás dos serviços da camada de transporte:"

Apresentações semelhantes


Anúncios Google