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

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

Direita ou esquerda ??? ? 3: Nível de Transporte.

Apresentações semelhantes


Apresentação em tema: "Direita ou esquerda ??? ? 3: Nível de Transporte."— Transcrição da apresentação:

1 Direita ou esquerda ??? ? 3: Nível de Transporte

2 Capítulo 3: Nível de transporte
Objectivos do capítulo: Entender os princípios subjacentes ao serviço de nível de transporte: Multiplexagem/desmultiplexagem Transferência de dados fiável Controlo de fluxo Controlo de congestão Instanciação e implementação na Internet Sumário do capítulo: Serviços de nível de transporte Multiplexagem/Desmultiplexagem Transporte sem ligação: UDP Princípios da transmissão fiável Transporte orientado à ligação: TCP Transferência fiável Controlo de fluxo Gestão de ligação Princípios de controlo de congestão Controlo de congestão em TCP 3: Nível de Transporte

3 Serviços de Transporte e Protocolos
Sistemas Terminais ? Processos ? Mensagens de aplicação ? Protocolo de transporte ? Protocolo de rede ? Ex: cartas entre “primos” amarelos e azuis !!! Sistemas Terminais = casas Processos = “primos” Mensagens de aplicação = cartas nos envelopes Protocolo de transporte = amarelo e azul Protocolo de rede = serviço postal 3: Nível de Transporte

4 Serviços de Transporte e Protocolos
Aplicação Transporte Rede Lig. Lógica Físico Transporte lógico extremo-a-extremo Fornece comunicação lógica entre processos de aplicação a funcionar em Sistemas Terminais diferentes Os Protocolos de Transporte são executados nos Sistemas Terminais Serviços de Transporte vs. Serviços de Rede: Nível de Rede: Transferência de dados entre Sistemas Terminais Nível de Transporte: Transferência de dados entre processos Confia e melhora, os serviços do Nível de Rede 3: Nível de Transporte

5 Protocolos de Nível de Transporte
Serviços de Transporte Internet: fiável, entrega ordenada uni-cast (TCP) congestão Controlo de fluxo Estabelecimento da ligação Não fiável (“best-effort”), entrega não ordenada uni-cast ou multi-cast: UDP Serviços não disponíveis: Tempo real Garantias de largura de banda Multicast fiável Aplicação Transporte Rede Lig. Lógica Físico Transporte lógico extremo-a-extremo 3: Nível de Transporte

6 Multiplexagem/Desmultiplexagem
Relembrar: segmento – unidade de dados transferido entre entidades de nível de transporte aka TPDU: Unidade de Dados do Protocolo de Transporte (transport protocol data unit) Desmultiplexagem: entrega dos segmentos recebidos para o processo de aplicação correcto Receptor P3 P4 Dados do nível de aplicação M M Aplicação Transporte Rede Cabeçalho do segmento P1 P2 M M Aplicação Transporte Rede Aplicação Transporte Rede segmento H t M H n segment 3: Nível de Transporte

7 Multiplexagem/Desmultiplexagem
Recolher dados de diferentes processos de aplicação, delimitar dados com cabeçalho (mais tarde usado para desmultiplexar) 32 bits # porto origem # porto destino Outros campos do cabeçalho multiplexagem/desmultiplexagem: Baseado no emissor/receptor: nº do porto, endereço IP Nº do porto de origem/ destino para cada segmento Relembrar: nº dos portos é bem conhecido para aplicações específicas Dados da aplicação (messagem) Formato do segmento TCP/UDP 3: Nível de Transporte

8 Multiplexagem/desmultiplexagem: exemplos
Sistema Terminal A Cliente Web Sistema Terminal C source port: x dest. port: 23 Servidor B source port:23 dest. port: x Source IP: C Dest IP: B source port: y dest. port: 80 Source IP: C Dest IP: B source port: x dest. port: 80 Utilização do porto: simples aplicação de telnet ! Source IP: A Dest IP: B source port: x dest. port: 80 Web server B Cliente Web Sistema Terminal A Utilização do porto: Servidor Web 3: Nível de Transporte

9 UDP: User Datagram Protocol [RFC 768]
Protocolo de transporte da Internet Serviço “best effort” Segmentos UDP podem ser: perdidos Entregues fora de ordem à aplicação Sem ligação Sem handshaking entre o emissor e o receptor UDP Cada segmento UDP é processado independentemente dos demais Porquê UDP ? Sem estabelecimento de ligação (que adiciona atraso) simples: não há estado da ligação no emissor, receptor Cabeçalho pequeno do segmento Não há controlo de congestão: UDP pode estoirar tão depressa quanto se queira !! 3: Nível de Transporte

10 Formato do segmento UDP
UDP: mais Usualmente utilizado para aplicações de streaming (multimédia) Tolerante a perdas Sensível ao ritmo Outras utilizações do UDP (Porquê ?): DNS SNMP Transferência fiável sobre UDP: adiciona a fiabilidade ao nível da aplicação Recuperação de erros específica da aplicação! 32 bits source port # dest port # Dimensão, em bytes do segmento UDP, incluindo Cabeçalho length checksum Dados da aplicação (message) Formato do segmento UDP 3: Nível de Transporte

11 checksum UDP Objectivo: detectar “erros” (e.g., bits trocados) no segmento transmitido Receptor: Calcula o checksum dos segmentos recebidos Verifica se o checksum calculado é igual ao do campo de checksum NÃO – erro detectado SIM – não houve erro detectado Mas podem haver erros ? Mais tarde ….. Emissor: Trata o conteúdo do segmento como uma sequência de inteiros de 16 bits checksum: adiciona ao conteúdo do segmento (complemento para 1 da soma) Emissor coloca o valor do checksum no campo de checksum do segmento UDP 3: Nível de Transporte

12 Princípios da transmissão fiável
Importante nas aplicações, transporte, ligação lógica Faz parte da lista top-10 de assuntos de rede! As características do canal não fiável determinam a complexidade do protocolo de transferência de dados fiável. 3: Nível de Transporte

13 Transferência de dados fiável: início
rdt_send(): chamado do nível de cima, (e.g., aplicação.). Envia dados para entrega no nível superior do receptor deliver_data(): chamado por rdt para entregar dados ao nível superior Lado do Emissor Lado do Receptor udt_send(): chamado por rdt, para transferir pacotes para o receptor através dum canal não fiável rdt_rcv(): chamada quando os pacotes chegam ao canal no lado de receptor rcv-side 3: Nível de Transporte

14 Transferência de dados fiável: início
Então: Desenvolvimento do emissor incremental, Lado do receptor do protocolo de transferência de dados fiável (rdt) Considerar apenas transferência de dados uni-direccional Mas a informação de controlo flui nas duas direcções Uso de máquinas de estado finitas (FSM) para especificar o emissor e o receptor Evento que causa a transição de estado Acções a tomar na transição de estado estado 1 estado: quando neste estado, o próximo estado é unicamente determinado pelo próximo evento estado 2 eventos acções 3: Nível de Transporte

15 Rdt1.0: transferência de dados fiável sobre um canal fiável
Canal que está por baixo é perfeitamente fiável Não há erros nos bits Não há perda de pacotes FSM separadas para o emissor e o receptor Emissor envia dados para o canal Receptor lê dados do canal 3: Nível de Transporte

16 rdt2.0: canal introduz erros nos bits
Canal que está por baixo pode trocar bits nos pacotes Relembrar: o checksum UDP checksum detecta erros em bits Questão: como recuperar dos erros ? acknowledgements (ACKs): receptor diz, explicitamente, ao emissor que recebeu um pacote sem erros. negative acknowledgements (NAKs): receptor diz, explicitamente, ao emissor que recebeu um pacote com erros emissor retransmite o pacote quando recebe o NAK Exemplos humanos de utilização de ACKs e NAKs? Novos mecanismos em rdt2.0 (para além de rdt1.0): detecção de erros resposta (feed-back) do receptor: mensagens de controlo (ACK,NAK) receptor  emissor 3: Nível de Transporte

17 rdt2.0: Especificação FSM
Emissor FSM Receptor FSM 3: Nível de Transporte

18 rdt2.0: em acção (sem erros)
Emissor FSM Receptor FSM 3: Nível de Transporte

19 rdt2.0: em acção (com erros)
Emissor FSM Receptor FSM 3: Nível de Transporte

20 rdt2.0 tem uma deficiência fatal!
O que acontece se os ACKs e os NAKs se corromperem? O emissor não sabe o que acontece ao receptor! Retransmissões pode ocasionar pacotes duplicados O que fazer? Emissor envia ACKs/NAKs referentes aos ACK/NAK do receptor ? O que acontece se os ACKs/NAKs do emissor se perderem ? Retransmite-se! Podem ser retransmitidos pacotes correctamente recebidos Tratamento de duplicações: Emissor acrescenta número de sequência a cada pacote Emissor retransmite pacote corrente se o ACK/NAK se corromper Receptor descarta pacotes duplicados (não os entrega aos níveis superiores). stop and wait Emissor envia um pacote e espera pela resposta do receptor 3: Nível de Transporte

21 rdt2.1: emissor, trata ACK/NAKs corrompidos
3: Nível de Transporte

22 rdt2.1: receiver, handles garbled ACK/NAKs
3: Nível de Transporte

23 rdt2.1: discussão Receptor:
Emissor: Nº de sequência adicionado a cada pacote Dois nºs de sequência (0,1) são suficientes Porquê ? Tem de verificar se os ACKs/NAKs recebidos estão corrompidos O dobro do nº de estados O estado tem de se “lembrar” se o pacote “corrente” tem o nº de sequência 0 ou 1. Receptor: Tem de verificar se recebeu pacotes duplicados o estado indicad sed se espera um pacote com o nº de sequência 0 ou 1. nota: receptor não pode saber se o último ACK/NAK chegou correctamente ao emissor 3: Nível de Transporte

24 rdt2.2: um protocol livre de NAKs
Emissor FSM a mesma funcionalidade de rdt2.1, usando ACKs apenas em vez de NAK, receptor envia ACK referente ao último pacote correctamente recebido receptor tem de incluir, explicitamente, o nº de sequência do pacote a ser confirmado, isto é, ACKed ACKs duplicados no emissor resultam na mesma acção que um NAK: retransmissão do pacote corrente ! 3: Nível de Transporte

25 rdt3.0: canais com erros e perdas
Novos pressupostos: canal que está por baixo também pode perder pacotes (dados ou ACKs) checksum, nºseq., ACKs, retransmissões ajudam, mas não são suficientes Q: como lidar com as perdas? Emissor espera até que certos dados ou ACKs se percam, depois retransmite desvantagens? Aproximação: emissor espera uma quantidade de tempo “razoável” por um ACK retransmite se o ACK não for recebido nesse tempo Se o pacote de dados (ou o ACK) se tiver atrasado (mas não perdido): Retransmissão será duplicada, mas a utilização de nº de seq. trata disso Receptor tem de especificar o nº de seq. do pacote que está a ser confirmado (ACKed) Necessário um temporizador descendente (countdown timer) 3: Nível de Transporte

26 rdt3.0: emissor 3: Nível de Transporte

27 rdt3.0: em acção 3: Nível de Transporte

28 rdt3.0: em acção 3: Nível de Transporte

29 emissor está ocupado a enviar
Desempenho de rdt3.0 rdt3.0 funciona, mas o desempenho…. exemplo: Ligação = 1 Gbps Tempo de propagação extremo-a-extremo = 15 ms Pacote = 1KB 8Kb/pkt T = = 8 seg transmissão 10**9 b/sec Fracção de tempo que o emissor está ocupado a enviar 8 seg mseg Utilização = U = = = 1KB pkt cada 30 mseg -> débito de 33KB/seg numa ligação 1 Gbps Protocolos de rede limitam o uso dos recursos físicos 3: Nível de Transporte

30 Protocolos em pipeline
Pipeline: o emissor permite múltiplos, pacotes ainda não confirmados “a-caminho” Intervalo dos números de sequência tem de aumentar Armazenamento no emissor e/ou receptor Duas formas genéricas de protocolos em pipeline: go-Back-N, selective repeat 3: Nível de Transporte

31 Go-Back-N Emissor: Cabeçalho do pacote com k bits para o nº de seq.
“janela” de até N, pacotes consecutivos ainda não confirmados. ACK(n): ACKs todos os pacotes até o nº de seq. n ACK acumulativo podem ser recebidos ACKs duplicados (ver receptor) temporizador para cada pacote a caminho timeout(n): retransmite pacote n e todos os pacotes de nº de seq. superior na janela. 3: Nível de Transporte

32 GBN: emissor ampliado FSM
Acho esta máquina de estados errada 3: Nível de Transporte

33 GBN: receptor ampliado FSM
Receptor simples: ACK: envia sempre ACK dos pacotes correcta e ordenamente recebidos com o nº de sequência superior Pode gerar ACKs duplicados Só tem de recordar o nº de seq. esperado expectedseqnum Pacotes fora de ordem: descartar (não armazenadr) -> não há armazenamento no receptor! ACK dos pacotes com o nº de seq. superior 3: Nível de Transporte

34 GBN em acção 3: Nível de Transporte

35 Repetição selectiva Receptor faz o ACK individual de todos os pacotes correctamente recebidos armazena pacotes, quando necessário, para os poder entregar por ordem aos níveis superiores Emissor apenas re-envia pacotes para os quais o ACK não tenha sido recebido. Temporizador no emissor para cada pacote não confirmado (unACKed) Janela do emissor N nº de seq. consecutivos Novamente há limite para o nº de pacotes com novo nº de seq. a serem enviados, em função dos pacotes não confirmados 3: Nível de Transporte

36 Repetição selectiva: janela do emissor e receptor
3: Nível de Transporte

37 Repetição selectiva Receptor Emissor Dados para enviar :
Se a janela tiver um º de seq. disponível, envia o pacote Temporizador expirou(n): Re-envia pacote N, re-inícia o temporizador ACK(n) em [sendbase,sendbase+N]: Marca pacote n como recebido Se n é menor do que o nº dum pacote unACKed, avança a base da janela para o próximo nº de seq. unACKed Pacote n em [rcvbase,rcvbase+N-1] envia ACK(n) fora de ordem: armazena Por ordem: entrega (também entrega por ordem os pacotes armazenados) avança a janela para o próximo pacote ainda não recebido pkt n em [rcvbase-N,rcvbase-1] ACK(n) Doutro modo: ignora 3: Nível de Transporte

38 Repetição selectiva: em acção
3: Nível de Transporte

39 Repetição selectiva : dilema
Exemplo: Nºs seq : 0, 1, 2, 3 Dimensão da janela =3 o receptor vê diferenças nos dois cenários! Dados duplicados são passados incorrectamente como novos em (a) Q: qual a relação entre o nº de seq. e a dimensão da janela ? 3: Nível de Transporte

40 TCP: Visão geral RFCs: 793, 1122, 1323, 2018, 2581 Ponto-a-ponto:
Um emissor, um receptor Cadeia de bytes ordenada e fiável: Não há “fronteiras nas mensagens” pipelined: TCP dimensão das janelas de controlo de congestão e de fluxo ajustável Buffers no emissor e receptor Transmissão de dados bi-direccional: Transmissão de dados bi-direccional na mesma ligação MSS: maximum segment size Orientado-à-ligação: handshaking (transferência de mensagens de controlo) Inicia o estado do emissor e do receptor antes de transferir os dados Fluxo controlado: Emissor não sobrecarrega o receptor Aplicação Aplicação Escrita de dados socket Leitura de dados socket door door TCP TCP Buffer de envio Buffer de recepção segmento 3: Nível de Transporte

41 TCP: estrutura do segmento
# porto origem # porto destino 32 bits application data (variable length) Número sequência Número acknowledgment rcvr window size ptr urgent data checksum F S R P A U head len not used Opções (dimensão variável) 3: Nível de Transporte

42 TCP: estrutura do segmento
32 bits # porto origem # porto destino Nº de sequência e Nº de ACKS: Contagem por bytes de dados Não segmentos ! Head Length em palavras de 32 b Dimensão sem extensões 20 B RCVR Window Size: Nº de Bytes que o receptor espera receber Opções: Negociação de parâmetros MSS (usual 1500; 536; 512 B) Factor de escala p/ janela em ligações de alto débito Número sequência Número acknowledgment head len not used U A P R S F rcvr window size checksum ptr urgent data Opções (dimensão variável) application data (variable length) 3: Nível de Transporte

43 TCP: estrutura do segmento
32 bits # porto origem # porto destino Flags de sinalização de informação urgente: U – URG: dados que o nível superior do emissor sinalizou como urgentes P – PSH: O receptor deve passar os dados para o nível superior imediata/ Flags de controlo A – ACK: valor válido no campo ACK R- RST; S- SYN; F – FIN: estabelecimento e terminação da ligação Ptr Urgent data Apontador para o último byte de dados que contém dados urgentes Número sequência Número acknowledgment head len not used U A P R S F rcvr window size checksum ptr urgent data Opções (dimensão variável) application data (variable length) 3: Nível de Transporte

44 TCP nº de sequência e ACK
Seq. #’s: Nº da cadeia de bytes do primeiro byte do segmento de dados ACKs: Nº de seq. do próximo byte esperado do outro lado ACK acumulativo Q: Como é que o receptor processa segmentos for a de ordem ? A: A especificação TCP não é clara, deixando esta questão para a implementação Host A Host B Utilizador digita ‘C’ Seq=42, ACK=79, data = ‘C’ Sistema Terminal recebe ‘C’ e e ecoa de volta o ‘C’ Seq=79, ACK=43, data = ‘C’ Sistema Terminal confirma (ACK) e ecoa o ‘C’ Seq=43, ACK=80 tempo Cenário simples de Telnet 3: Nível de Transporte

45 TCP: transferência de dados fiável
evento: dados recebidos das aplicações dos níveis superiores Emissor simplificado, assume: Transferência de dados uni-direcccional Sem controlo de fluxo Sem controlo de congestão criação, envio do segmento wait for event evento: temporizador expira para o segmento com o nº de seq. y wait for event Retransmisssão do segmento y evento: ACK recebido com ACK y ACK processado 3: Nível de Transporte

46 TCP: transferência de dados fiável
00 sendbase = initial_sequence number 01 nextseqnum = initial_sequence number 02 loop (forever) { switch(event) event: data received from application above create TCP segment with sequence number nextseqnum start timer for segment nextseqnum pass segment to IP nextseqnum = nextseqnum + length(data) event: timer timeout for segment with sequence number y retransmit segment with sequence number y compute new timeout interval for segment y restart timer for sequence number y event: ACK received, with ACK field value of y if (y > sendbase) { /* cumulative ACK of all data up to y */ cancel all timers for segments with sequence numbers < y sendbase = y } else { /* a duplicate ACK for already ACKed segment */ increment number of duplicate ACKs received for y if (number of duplicate ACKS received for y == 3) { /* TCP fast retransmit */ resend segment with sequence number y restart timer for segment y } } /* end of loop forever */ TCP: transferência de dados fiável Emissor TCP simplificado 3: Nível de Transporte

47 TCP geração de ACKs [RFC 1122, RFC 2581]
Evento Chegada ordenada de segmentos, Sem “buracos”, tudo o mais já ACKed Um ACK pendente por atraso Chegada de segmentos desordenada Nº de seq. superior ao esperado “Buraco(s)” detectados Chegada de segmento que preenche completa ou incompletamente o buraco TCP Acção no receptor ACK atrasado. Espera máxima de 500 ms pelo próximo segmento. Se não chega segmento, envia ACK Envia imediatamente um único ACK Acumulativo, referente a todos os segmentos que chegaram ordenadamente Envia ACK duplicado, indicando o nº de seq. do próximo byte esperado ACK imediato se o segmento começa no limite inferior do “buraco” 3: Nível de Transporte

48 TCP: cenários de retransmissão
Host A Seq=92, 8 bytes data ACK=100 loss timeout tempo Perda de ACK Host B X Host A Host B Seq=92, 8 bytes data Seq=100, 20 bytes data Seq=92 timeout ACK=100 Seq=100 timeout ACK=120 Seq=92, 8 bytes data ACK=120 tempo Timeout antecipado, ACKs acumulativo 3: Nível de Transporte


Carregar ppt "Direita ou esquerda ??? ? 3: Nível de Transporte."

Apresentações semelhantes


Anúncios Google