Direita ou esquerda ???

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

2. 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 Capítulo 3: Nível de transporte 3: Nível de Transporte

3. 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 Serviços de Transporte e Protocolos • Sistemas Terminais ? • Processos ? • Mensagens de aplicação ? • Protocolo de transporte ? • Protocolo de rede ? 3: Nível de Transporte

4. 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 Aplicação Transporte Rede Lig. Lógica Físico Aplicação Transporte Rede Lig. Lógica Físico Rede Lig. Lógica Físico Rede Lig. Lógica Físico Rede Lig. Lógica Físico Rede Lig. Lógica Físico Rede Lig. Lógica Físico Transporte lógico extremo-a-extremo Serviços de Transporte e Protocolos 3: Nível de Transporte

5. 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 Aplicação Transporte Rede Lig. Lógica Físico Rede Lig. Lógica Físico Rede Lig. Lógica Físico Rede Lig. Lógica Físico Rede Lig. Lógica Físico Rede Lig. Lógica Físico Transporte lógico extremo-a-extremo Protocolos de Nível de Transporte 3: Nível de Transporte

6. 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) M M M M Aplicação Transporte Rede Aplicação Transporte Rede Aplicação Transporte Rede H n Multiplexagem/Desmultiplexagem Desmultiplexagem: entrega dos segmentos recebidos para o processo de aplicação correcto Receptor P3 P4 Dados do nível de aplicação Cabeçalho do segmento P1 P2 segmento H t M segment 3: Nível de Transporte

7. 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 Multiplexagem: 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 Dados da aplicação (messagem) Formato do segmento TCP/UDP 3: Nível de Transporte

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

9. 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 !! UDP: User Datagram Protocol [RFC 768] 3: Nível de Transporte

10. 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! UDP: mais 32 bits source port # dest port # Dimensão, em bytes do segmento UDP, incluindo Cabeçalho checksum length Dados da aplicação (message) Formato do segmento UDP 3: Nível de Transporte

11. 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 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 ….. checksum UDP Objectivo: detectar “erros” (e.g., bits trocados) no segmento transmitido 3: Nível de Transporte

12. 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. Princípios da transmissão fiável 3: Nível de Transporte

13. 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 rdt_rcv():chamada quando os pacotes chegam ao canal no lado de receptor rcv-side udt_send():chamado por rdt, para transferir pacotes para o receptor através dum canal não fiável Transferência de dados fiável: início Lado do Emissor Lado do Receptor 3: Nível de Transporte

14. 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 eventos estado 1 estado 2 acções Transferência de dados fiável: início Evento que causa a transição de estado Acções a tomar na transição de estado estado: quando neste estado, o próximo estado é unicamente determinado pelo próximo evento 3: Nível de Transporte

15. 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 Rdt1.0: transferência de dados fiável sobre um canal fiável 3: Nível de Transporte

16. 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 rdt2.0: canal introduz erros nos bits 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. 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 rdt2.0tem uma deficiênciafatal! 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. 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 rdt2.1: discussão 3: Nível de Transporte

24. 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 rdt2.2: um protocol livre de NAKs Emissor FSM ! 3: Nível de Transporte

25. 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) rdt3.0: canais com erros e perdas 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. rdt3.0 funciona, mas o desempenho…. exemplo: Ligação = 1 Gbps Tempo de propagação extremo-a-extremo = 15 ms Pacote = 1KB 8 seg 30.016 mseg Desempenho de rdt3.0 8Kb/pkt T = = 8 seg transmissão 10**9 b/sec Fracção de tempo que o emissor está ocupado a enviar = = 0.00015 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. 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 Protocolos em pipeline 3: Nível de Transporte

31. Emissor: Cabeçalho do pacote com k bits para o nº de seq. “janela” de até N, pacotes consecutivos ainda não confirmados. Go-Back-N • 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 em acção 3: Nível de Transporte

33. 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 Repetição selectiva 3: Nível de Transporte

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

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

36. 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 ? Repetição selectiva :dilema 3: Nível de Transporte

37. 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 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 TCP: Visão geralRFCs: 793, 1122, 1323, 2018, 2581 Aplicação Aplicação Escrita de dados Leitura de dados socket socket door door TCP TCP Buffer de envio Buffer de recepção 3: Nível de Transporte segmento

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

39. 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 rcvr window size U A P R S F checksum ptr urgent data Opções (dimensão variável) application data (variable length) 3: Nível de Transporte

40. 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 rcvr window size U A P R S F checksum ptr urgent data Opções (dimensão variável) application data (variable length) 3: Nível de Transporte

41. 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 tempo TCP nº de sequência e ACK Host B Host A 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 Cenário simples de Telnet 3: Nível de Transporte

42. 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 evento: temporizador expira para o segmento com o nº de seq. y wait for event wait for event Retransmisssão do segmento y evento: ACK recebido com ACK y ACK processado 3: Nível de Transporte

43. TCP: transferência de dados fiável 00sendbase = initial_sequence number 01 nextseqnum = initial_sequence number 02 03 loop (forever) { 04 switch(event) 05 event: data received from application above 06 create TCP segment with sequence number nextseqnum 07 start timer for segment nextseqnum 08 pass segment to IP 09 nextseqnum = nextseqnum + length(data) 10 event: timer timeout for segment with sequence number y 11 retransmit segment with sequence number y 12 compute new timeout interval for segment y 13 restart timer for sequence number y 14 event: ACK received, with ACK field value of y 15 if (y > sendbase) { /* cumulative ACK of all data up to y */ 16 cancel all timers for segments with sequence numbers < y 17 sendbase = y 18 } 19 else { /* a duplicate ACK for already ACKed segment */ 20 increment number of duplicate ACKs received for y 21 if (number of duplicate ACKS received for y == 3) { 22 /* TCP fast retransmit */ 23 resend segment with sequence number y 24 restart timer for segment y 25 } 26 } /* end of loop forever */ Emissor TCP simplificado 3: Nível de Transporte

44. TCP geração de ACKs[RFC 1122, RFC 2581] 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” Evento Chegada ordenada de segmentos, Sem “buracos”, tudo o mais já ACKed Chegada ordenada de segmentos, Sem “buracos”, 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 3: Nível de Transporte

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