Transporte

1. Transporte Referência: • Slides extraídos do material dos professores Jim Kurose e Keith Ross relativos ao livro “Redes de Computadores e a Internet – Uma abordagem top-down”, segunda e terceira edições • Alterações nos slides, incluindo sequenciamento, textos, figuras e novos slides, foram realizadas conforme necessidade

2. aplicação transporteeerede 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 rede enlace física aplicação transporte rede enlace física Protocolos e Serviços de Transporte • Fornecem comunicação lógicas entre processos de aplicação em diferentes hosts • Os protocolos de transporte são executados nos sistemas finais da rede • serviço de transporte vs serviços de rede : • camada de rede: transferência de dados entre computadores (end systems) • camada de transporte: transferência de dados entre processos • utiliza e aprimora os serviços oferecidos pela camada de rede

3. application 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 rede enlace física application transporte rede enlace física Protocolos da Camada de Transporte Serviços de Transporte da Internet: • confiável, seqüencial e unicast (TCP) • congestionamento • controle de fluxo • orientado à conexão • não confiável, não seqüencial, entrega unicast or multicast: UDP • serviços não disponíveis: • tempo-real • garantia de banda • multicast confiável

4. M M aplicação transporte rede M M aplicação transporte rede aplicação transporte rede H n Multiplexação de Aplicações Demultiplexação: entrega de segmentos recebidos aos processos de aplicação corretos Segmento - unidade de dados trocada entre entidades da camada de transporte • TPDU: transport protocol data unit (unidade de dados do protocolo de transporte) receptor P3 P4 dados da camada de aplicação cabeçalho do segmento P1 P2 segmento H t M segmento

5. Multiplexação: Multiplexação de Aplicações reunir dados de múltiplos processo de aplicação, juntar cabeçalhos com informações para demultiplexação 32 bits multiplexação/demultiplexação: • baseada nos número de porta do transmissor, número de porta do receptor e endereços IP • números de porta origem e destino em cada segmento • lembre: portas com números bem-conhecidos são usadas para aplicações específicas porta origem porta destino outros campos de cabeçalho dados de aplicação (mensagem) formato do segmento TCP/UDP

6. porta origem: x porta dest.: 23 porta origem:23 port dest.: x IP Origem: C IP Dest: B porta origem: y porta dest.: 80 IP Origem: C IP Dest: B porta origem: x porta dest.: 80 IP Origem: A IP Dest: B porta origem : x porta dest.: 80 Multiplexação: exemplos cliente Web host C servidor B host A aplicação Telnet Servidor Web B cliente Web host A aplicação: servidor Web

7. Porque existe um UDP? não há estabelecimento de conexão (que pode redundar em atrasos) simples: não há estado de conexão nem no transmissor, nem no receptor cabeçalho de segmento reduzido não há controle de congestionamento: UDP pode enviar segmentos tão rápido quanto desejado (e possível) UDP: User Datagram Protocol [RFC 768] • protocolo de transporte da Internet “sem gorduras” “sem frescuras” • serviço “best effort” , segmentos UDP podem ser: • perdidos • entregues fora de ordem para a aplicação • sem conexão: • não há apresentação entre o UDP transmissor e o receptor • cada segmento UDP é tratado de forma independente dos outros

8. Mais sobre UDP 32 bits • muito usado por aplicações de mutimídia contínua (streaming) • tolerantes à perda • sensíveis à taxa • outros usos do UDP: • DNS • SNMP • transferência confiável sobre UDP: acrescentar confiabilidade na camada de aplicação • recuperação de erro específica de cada aplicação porta origem porta destino Tamanho, em bytes do segmento UDP, incluíndo cabeçalho checksum tamanho Dados de Aplicação (mensagem) formato do segmento UDP

9. Receptor: computa o checksum do segmento recebido verifica se o checksum calculado é igual ao valor do campo checksum: NÃO - error detectado SIM - não há erros. Mas, talvez haja erros apesar disto! UDP checksum Objetivo: detectar “erros” (ex.,bits trocados) no segmento transmitido Transmissor: • trata o conteúdo do segmento como seqüencia de inteiros de 16 bits • checksum: soma (complemento de 1 da soma) do conteúdo do segmento • transmissor coloca o valor do checksum no campo de checksum do UDP

10. Caracteristicas dos canais não confiáveis determinarão a complexidade dos protocolos confiáveis de transferência de dados Necessário usar ACKs (e também NACKs, mas são desnecessários) Princípios de Transferência Confiável de Dados • Importante nas camadas de aplicação, transporte e enlace

11. Tratando duplicatas: transmissor acrescenta número de seqüência em cada pacote Transmissor reenvia o último pacote se ACK for perdido receptor descarta (não passa para a aplicação) pacotes duplicados stop and wait Há um problema fatal! O que acontece se o ACK é corrompido? • transmissor não sabe o que aconteceu no receptor! • não pode apenas retransmitir: possível duplicata O que fazer? • Transmissor envia ACKs para reconhecer os ACKs do receptor? O que acontece se estes ACKs se perdem? • retransmitir os ACKs, mas isto poderia causar a retransmissão de um pacote recebido corretamente! Transmissor envia um pacote e então espera pela resposta do receptor

12. Receptor: deve verificar se o pacote recebido é duplicado estado indica se o pacote 0 ou 1 é esperado nota: receptor pode não saber se seu últino ACK foi recebido pelo transmissor Discussão (Stop and Wait) Transmissor: • adiciona número de seqüência ao pacote • Dois números (0 e 1) bastam. Porque? • deve verificar se os ACKs recebidos estão corrompidos • estado da transmissão deve “lembrar” se o pacote “corrente” tem número de seqüência 0 ou 1

13. Duas formas genéricas de protocolos com paralelismo: go-Back-N, retransmissão seletiva Protocolos com Paralelismo (pipelining) Paralelismo: transmissor envia vários pacotes “ao mesmo tempo” (em seqüência), todos esperando para serem reconhecidos • faixa de números de seqüência deve ser aumentada • armazenamento no transmissor e/ou no receptor (a) operação do protocolo stop-and-wait (a) operação do protocolo com paralelismo

14. Go-Back-N Transmissor: • Número de seqüência com k bits no cabeçalho do pacote • “janela” de até N, pacotes não reconhecidos, consecutivos, são permitidos • ACK(n): reconhece todos os pacotes até o número de seqüência N (incluindo este limite). “ACK cumulativo” • pode receber ACKS duplicados (veja receptor) • temporizador para cada pacote enviado e não confirmado • timeout(n): retransmite pacote n e todos os pacotes com número de seqüência maior que estejam dentro da janela

15. GBN em ação

16. Retransmissão Seletiva • receptor reconhece individualmente todos os pacotes recebidos corretamente • armazena pacotes, quando necessário, para eventual entrega em ordem para a camada superior • transmissor somente reenvia os pacotes para os quais um ACK não foi recebido • transmissor temporiza cada pacote não reconhecido • janela de transmissão • N números de seqüência consecutivos • novamente limita a quantidade de pacotes enviados, mas não reconhecidos

17. Retransmissão seletiva: janelas do transmissor e do receptor (a) visão dos números de seqüência pelo transmissor (b) visão dos números de seqüência pelo receptor

18. Retransmissão seletiva em ação

19. ponto-a-ponto: um transmissor, um receptor confiável, seqüêncial byte stream: não há distorção nas mensagens pipelined: (transmissão de vários pacotes em confirmação) Controle de congestionamento e de fluxo definem tamanho da janela buffers de transmissão e de recepção TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 • dados full-duplex: • transmissão bi-direcional na mesma conexão • MSS: maximum segment size • orientado à conexão: • handshaking (troca de mensagens de controle) inicia o estado do transmissor e do receptor antes da troca de dados • controle de fluxo: • transmissor não esgota a capacidade do receptor aplicação aplicação envia dados lê dados socket socket port port TCP TCP buffe de txr buffer de rx segment

20. Estrutura do Segmento TCP 32 bits URG: dados urgentes (pouco usado) contagem por bytes de dados (não segmentos!) porta origem porta destino número de seqüência ACK: campo de ACK é válido número de reconhecimento tam. cabec. não usado janela de recep. U A P R S F PSH: produz envio de dados (pouco usado) número de bytes receptor está pronto para aceitar checksum dados urgentes RST, SYN, FIN: estabelec. de conexão (comandos de criação e término) Opções (tamanho variável) dados de aplicação (tamanho variável) Internet checksum (como no UDP)

21. tempo Números de Seqüência e ACKs do TCP Host B Host A Usuário digita ‘C’ Números de seqüência: • número do primeiro byte no segmentos de dados ACKs: • número do próximo byte esperado do outro lado • ACK cumulativo: forma como o receptor trata segmentos fora de ordem • alguns pontos ficam a critério da implementação como fazer Seq=42, ACK=79, data = ‘C’ host confirma recepção de ‘C’, e ecoa o ’C’ de volta Seq=79, ACK=43, data = ‘C’ host confirma recepção do ‘C’ ecoado Seq=43, ACK=80 cenário telnet simples

22. Three way handshake: Passo 1: sistema final cliente envia TCP SYN ao servidor especifica número de seqüência inicial Passo 2: sistema final servidor que recebe o SYN, responde com segmento SYNACK reconhece o SYN recebido aloca buffers especifica o número de seqüência inicial do servidor Passo 3:o sistema final cliente reconhece o SYNACK TCP: Estabelecimento de Conexão TCP transmissorestabelececonexão com o receptor, antes mesmo de enviar dados: • inicializarvariáveis: • números de seqüência • buffers, controle de fluxo (ex. RcvWindow) • cliente: iniciadordaconexão Socket clientSocket = new Socket("hostname","port number"); • servidor:chamadopelocliente Socket connectionSocket = welcomeSocket.accept();

23. TCP: Término de Conexão Fechando uma conexão: cliente fecha o socket:clientSocket.close(); Passo 1: o cliente envia o segmento TCP FIN ao servidor Passo 2:servidor recebe FIN, responde com ACK. Fecha a conexão, envia FIN. • Passo 3:clienterecebe FIN, responde com ACK. • entra“esperatemporizada” • vairesponder com ACK a FINs recebidos • Passo 4:servidor, recebe ACK. Conexãofechada.

24. controle de fluxo TCP: Controle de Fluxo transmissor não deve esgotar os buffers de receção enviando dados rápido demais receptor: explicitamente informa o transmissor da área livre no buffer (dinamicamente mudando) • campo RcvWindow nosegmento TCP transmissor: mantém a quantidade de dados transmitidos mas não reconhecidos menor que o último RcvWindow recebido RcvBuffer= tamanho do Buffer de recepção do TCP RcvWindow = total de espaço livre no buffer armazenamento de recepção

25. Q: Como estimar o RTT? SampleRTT: tempo medido da transmissão de um segmento até a respectiva confirmação ignora retransmissões e segmentos reconhecidos de forma cumulativa SampleRTT varia de forma rápida, é desejável um amortecedor para a estimativa do RTT usar várias medidas recentes, não apenas o último SampleRTT obtido TCP Round Trip Time e Temporização Q: como escolher o valor da temporização do TCP (time-out)? • maior que o RTT • nota: RTT varia • muito curto: temporização prematura • retransmissões desnecessárias • muito longo: a reação à perda de segmento fica lenta

26. TCP Round Trip Time e Temporização EstimatedRTT = (1-x)*EstimatedRTT + x*SampleRTT • Média móvel com peso exponential • influencia de uma dada amostra decresce de forma exponencial • valor típico de x: 0.1 Definindo a temporização • EstimtedRTT mais “margem de segurança” • grandes variações no EstimatedRTT -> maior margem de segurança Temporização = EstimatedRTT + 4*Desvios Desvios = (1-x)*Desvio + x*|SampleRTT-EstimatedRTT|

27. TCP Round Trip Time e Temporização

28. Princípios de Controle de Congestionamento Congestionamento: • informalmente: “muitas fontes enviando dados acima da capacidade da rede tratá-los” • diferente de controle de fluxo! • sintomas: • perda de pacotes (saturação de buffer nos roteadores) • atrasos grandes (filas nos buffers dos roteadores) • um dos 10 problemas mais importantes na Internet!

29. Causas/custos do congestionamento   in in Causas/custos do congestionamento: cenário 3 P.:o que acontece quando e aumentam?  Quatro transmissores  Caminhos com múltiplos saltos  Temporizações/retransmissões

30. w * MSS vazão = Bytes/seg RTT TCP: Controle Congestionamento • controle fim-a-fim (não há assistência da rede) • taxa de transmissão é limitada pelo tamanho da janela, Congwin, sobre os segmentos: Congwin • w segmentos, cada um com MSS bytes enviados em um RTT:

31. TCP: Controle Congestionamento • Realiza um “teste” para reconhecer a taxa possível: • idealmente: transmitir tão rápido quanto possível (Congwin tão grande quanto possível) sem perdas • aumentar Congwin até que ocorra perda (congestionamento) • perda: diminuirCongwin, então ir testando (aumentando) outra vez • Duas “fases”” • slow start • congestion avoidance • Variáveisimportantes: • Congwin • threshold: define o limite entre a fase slow start e a fase congestion avoidance

32. algoritmo Slowstart tempo TCP Slowstart Host A Host B one segment • aumento exponencial (por RTT) no tamanho da janela (não tão lento!) • evento de perda : temporização (Tahoe TCP) e/ou 3 ACKs duplicados (Reno TCP) initializar: Congwin = 1 para (cada segmento reconhecido Congwin++ até (evento perda OU CongWin > threshold) RTT two segments four segments

33. TCP: Congestion Avoidance Congestion avoidance /* acabou slowstart */ /* Congwin > threshold */ Até (evento perda) { cada w segmentos “acked”: Congwin++ } threshold = Congwin/2 Congwin = 1 (*) realiza slowstart (*) (*) TCP Reno pula a fase slowstart (recuperaçaõ rápida) após três ACKs duplicados

34. RetransmissãoRápida TCP AIMD • Com freqüência, o tempo de expiração é relativamentelongo: • Longo atraso antes de reenviar um pacoteperdido • Pode-se detectarsegmentosperdidospormeio de ACKs duplicados: - Transmissorfreqüentementeenviamuitossegmentosao receptor - Se um segmento é perdido, haverádesordenamento e, portanto, muitosACKs duplicados. • ACK duplicado: receptor reenvia ACK do último byte de dados recebidoemordemqdochega um segmentofora de ordem • Se o transmissorrecebe 3 ACKs para o mesmo dado, elesupõeque o segmentoapós o dado confirmadofoiperdido: • Retransmissãorápida:perda é decretada e reenvia-se o segmento antes do temporizadorexpirar

35. AIMD TCP AIMD Reduçãomultiplicativa:diminui oCongWinpelametadeapós o evento de perda Aumentoaditivo:aumenta oCongWincom 1 MSS a cada RTT naausência de eventos de perda: probing conexão TCP de longa-vida

36. Eqüidade do TCP Objetivo de eqüidade: se K sessões TCP compartilham o mesmo enlace do gargalo com largura de banda R, cada uma deve ter taxa média de R/K

37. Porque o TCP é justo? Duas sessões competindo pela banda:  O aumento aditivo fornece uma inclinação de 1, quando a vazão aumenta  Redução multiplicativa diminui a vazão proporcionalmente perda: reduz janela por um fator de 2 prevenção de congestionamento: aumento aditivo

38. Eqüidade do TCP Eqüidade Eqüidade e UDP  Aplicações multimedia normalmente não usam TCP  Não querem a taxa estrangulada pelo controle de congestionamento  Em vez disso, usam UDP:  Trafega áudio/vídeo a taxas constantes, toleram perda de pacotes várea de pesquisa: TCP amigável Eqüidade e conexões TCP paralelas  Nada previne as aplicações de abrirem conexões paralelas entre 2 hosts.  Web browsers fazem isso  Exemplo: enlace de taxa R suportando 9 conexões;  Novas aplicações pedem 1 TCP, obtém taxa de R/10  Novas aplicações pedem 11 TCPs, obtém R/2!