A necessidade por um serviço de transporte confiável. Camada de Transporte. End-to-End Protocols. End-to-End Protocols. Data Link Versus Transport (1)

Transcrição

1 Sumário Transmissão confiável Protocolo TCP Protocolo UDP Camada de Transporte Chamada remota de procedimento RPC Curso de Redes de Computadores, 2003 DCC - ICEx - UFMG Prof. José Marcos Silva Nogueira A necessidade por um serviço de transporte confiável Aplicações em qualquer sistema de computação assumem que a transferência de dados é confiável, ou seja, o sistema garante que os dados não serão: perdidos, duplicados, e entregues fora de ordem Uma internet deve prover um serviço idêntico a um sistema convencional 1 2 End-to-End Protocols End-to-End Protocols Underlying best-effort network drop messages re-orders messages delivers duplicate copies of a given message limits messages to some finite size delivers messages after an arbitrarily long delay Common end-to-end services expected to provide guarantee message delivery deliver messages in the same order they are sent deliver at most one copy of each message support arbitrarily large messages support synchronization allow the receiver to flow control the sender support multiple application processes on each host 3 4 Data Link Versus Transport (1) Potentially connects many different hosts need explicit connection establishment and termination Potentially different RTT need adaptive timeout mechanism Potentially long delay in network need to be prepared for arrival of very old packets Data Link Versus Transport (2) Potentially different capacity at destination need to accommodate different node capacity Potentially different network capacity need to be prepared for network congestion At the heart of TCP is the sliding window algorithm 5 6

2 Protocolo TCP Principal protocolo de transporte da arquitetura TCP/IP Transmission Control Protocol Existem outros como o UDP, RTP e RTCP RPC é considerado por alguns autores como sendo da camada de transporte Protocolo TCP Provê um serviço (missão) impossível? Usa um serviço datagrama não confiável para prover um serviço de entrega de dados confiável para as Deve ser capaz de compensar perdas e atrasos na subrede de comunicação de tal forma a prover o transporte de dados fim-a-fim de forma eficiente Deve ser capaz de executar essas tarefas sem sobrecarregar a sub-rede de comunicação e os roteadores 7 8 Protocolo TCP De todos os protocolos de transporte propostos, talvez o TCP seja o protocolo que executa essas funções da melhor forma possível Certamente existem outras propostas melhores quando outros ambientes (environments) são considerados, como redes de alta velocidade ou comunicação sem fio Atualmente, a maior parte das na Internet são baseadas no TCP Serviço que o TCP provê para as Conexão Serviço baseado em três fases Estabelecimento da conexão Transferência de dados Término da conexão 9 10 Serviço que o TCP provê para as Comunicação ponto-a-ponto Cada conexão TCP tem exatamente dois endpoints Confiabilidade TCP garante que os dados serão entregues da forma que foram enviados Serviço que o TCP provê para as Comunicação full-duplex TCP permite que dados sejam enviados em qualquer instante e em qualquer direção TCP pode armazenar dados de entrada e saída Libera a aplicação para continuar processando 11 12

3 Serviço que o TCP provê para as Serviço que o TCP provê para as Interface do serviço é uma seqüência de bytes TCP não identifica estruturas lógicas nos dados transmitidos Dados transmitidos são vistos como uma seqüência de bytes Inicialização confiável da conexão TCP requer que as reconheçam uma nova conexão toda vez que uma for criada Pacotes de conexões anteriores não podem aparecer como válidos Serviço que o TCP provê para as Término correto da conexão TCP garante a entrega de todos os dados antes de fechar uma conexão a pedido de uma aplicação Serviço fim-a-fim e datagramas Protocolos de transporte são chamados de protocolos fim-a-fim Provêem uma conexão entre duas em computadores distintos Conexões são virtuais Implementadas através de software já que o sub-sistema de comunicação não provê nenhuma facilidade Serviço fim-a-fim e datagramas Mensagens TCP são encapsuladas em datagramas (pacotes) IPs Pacotes são encapsulados em quadros Quadros são transmitidos como uma seqüência de bits Tratando uma seqüência de bytes Application process TCP Send buffer Byte-stream Aplicação escreve bytes TCP envia segmentos Aplicação lê bytes Write bytes Segment Segment Segment Transmit segments Application process TCP Receive buffer Read bytes 17 18

4 Tratando uma seqüência de bytes Application process Application process Serviço fim-a-fim e datagramas Write bytes Read bytes TCP Send buffer TCP Receive buffer Segment Segment Segment Transmit segments over the network Flow control: keep sender from overrunning receiver Congestion control: keep sender from overrunning network Formato do segmento TCP TCP usa o termo segmento para fazer referência a uma mensagem Formato do segmento SrcPort DstPort SequenceNum Acknowledgment HdrLen 0 Flags Checksum AdvertisedWindow UrgPtr Options (variable) Data Formato do segmento Formato do segmento Numa transmissão fim-a-fim são os processos computacionais que se comunicam Como identificar um processo em um hospedeiro? É feito indiretamente por meio de um localizador abstrato Porto, porta ou mailbox Servidores tem portos bem conhecidos (wellknown) ports Veja diretório /etc/services do Unix 23 Cada conexão é identificada com a quádupla (4-tuple): (SrcPort, SrcIPAddr, DsrPort, DstIPAddr) Onde, SrcPort porta de sistema operacional do fonte SrcIPAddr endereco IP do fonte DsrPort porta de sistema operacional do destino DstIPAddr endereço IP do destino A quádupla pode se repetir no tempo Encarnações da mesma conexão 24

5 Formato do segmento Formato do segmento Janela deslizante e controle de fluxo Acknowledgment, SequenceNum, AdvertisedWindow Sender Data (SequenceNum) Acknowledgment + AdvertisedWindow Receiver Flags SYN, FIN, RESET, PUSH, URG, ACK SYN para iniciar conexões FIN para finalizar conexões ACK quando o campo acknoledgement é válido URG o segmento contém dados urgentes que ficam no início do segmento URGPtr indica onde os dados não urgentes começam PUSH operação invocada pelo enviador ao receptor RESET receptor solicita aborto da conexão Formato do segmento Checksum Calculado sobre TCP header + data + pseudo header Pseudo header Três campos do pacote IP Número do protocolo Endereço IP fonte Endereço IP destino Comprimento do segmento TCP, inclusive cabeçalho TCP (de novo!) Controle de fluxo Baseado num mecanismo de janela No momento do estabelecimento da conexão, um buffer de recepção é alocado e seu tamanho é informado para a entidade par Controle de fluxo Em toda confirmação é enviado o espaço disponível nesse buffer Esse espaço é chamado de janela A notificação que contém o valor desse espaço é chamado de anúncio da janela (window advertisement) Controle de fluxo Tamanho máximo do segmento para o exemplo: 1000 bytes 29 30

6 Sliding Window Revisited Sending application Receiving application TCP TCP LastByteWritten LastByteRead Flow Control Send buffer size: MaxSendBuffer Receive buffer size: MaxRcvBuffer LastByteAcked Sending side LastByteAcked < = LastByteSent LastByteSent < = LastByteWritten buffer bytes between LastByteAcked and LastByteWritten LastByteSent NextByteExpected LastByteRcvd Receiving side LastByteRead < NextByteExpected NextByteExpected < = LastByteRcvd +1 buffer bytes between NextByteRead and LastByteRcvd Receiving side LastByteRcvd - LastByteRead < = MaxRcvBuffer AdvertisedWindow = MaxRcvBuffer - (NextByteExpected - NextByteRead) Flow Control Sending side LastByteSent - LastByteAcked < = AdvertisedWindow EffectiveWindow = AdvertisedWindow - (LastByteSent - LastByteAcked) LastByteWritten - LastByteAcked < = MaxSendBuffer block sender if (LastByteWritten - LastByteAcked) + y > MaxSenderBuffer Always send ACK in response to arriving data segment Persist when AdvertisedWindow = 0 Keeping the Pipe Full 16-bit AdvertisedWindow Must be big enough to allow the sender keep the pipe full The best advertised window Receiver buffers Network bandwidth Delay X bandwidth product Keeping the Pipe Full Required window size for a 100 ms RTT Bandwidth Delay x Bandwidth Product T1 (1.5 Mbps) 18KB Ethernet (10 Mbps) 122KB T3 (45 Mbps) 549KB FDDI (100 Mbps) 1.2MB STS-3 (155 Mbps) 1.8MB STS-12 (622 Mbps) 7.4MB STS-24 (1.2 Gbps) 14.8MB Keeping the Pipe Full 16 bits advertised window field is not enough to handle even a T3 (45 Mpbs) connection 16 bits field allows advertisement of 64 KB windows Solution Extensions to TCP 35 36

7 Serviço fim-a-fim e datagramas Dois cenários que afetam a confiabilidade Serviço não confiável do sub-sistema de comunicação No sub-sistema de comunicação, mensagens de uma conexão podem ser perdidas duplicadas atrasadas entregues fora de ordem e aparecerem em outra conexão Dois cenários que afetam a confiabilidade Conexões devem ser identificadas de forma única Solução: um número de 32 bits é gerado por cada entidade toda vez que uma conexão é criada Campos de sequência e janela anunciada Afetam a correção e desempenho do TCP SequenceNum: 32 bits AdvertisedWindow: 16 bits Atende o requisito de tamanho de janela ótimo SWS <= MaxSeq/ Campos de sequência SequenceNum de 32 bits O número de sequência pode se repetir Ex: um byte de sequência x pode ser enviado e mais tarde outro byte com a mesma sequencia é enviado Assume-se que os pacotes não sobrevivem além de um máximo, usualmente 120 s. Depende da rapidez com que são transmitidos os bytes Campos de sequência Proteção contra Wrap Around Tempo decorrido até o número de sequência do espaço de numeração de 32 bits dê a volta Bandwidth T1 (1.5 Mbps) Ethernet (10 Mbps) T3 (45 Mbps) FDDI (100 Mbps) STS-3 (155 Mbps) STS-12 (622 Mbps) STS-24 (1.2 Gbps) Time Until Wrap Around 6.4 hours 57 minutes 13 minutes 6 minutes 4 minutes 55 seconds 28 seconds 41 42

8 Gerenciamento de conexões É feito usando 3-way handshake (três mensagens são trocadas) TCP usa os termos Segmento de sincronização (SYN segment) para descrever mensagens durante a conexão Segmento de término (FIN finish segment) para descrever mensagens durante a desconexão Estabelecimento de conexão Active participant (client) SYN, SequenceNum = x SYN + ACK, SequenceNum = y, Acknowledgment = x + 1 ACK, Acknowledgment = y + 1 Passive participant (server) Término de conexão 3-way handshake Gerência de conexão State Transition Diagram CLOSED Active open /SYN Passive open Close Close LISTEN SYN/SYN + ACK Send/ SYN SYN/SYN + ACK SYN_RCVD SYN_SENT ACK SYN + ACK/ACK Close/FIN ESTABLISHED Close/FIN FIN/ACK FIN_WAIT_1 CLOSE_WAIT FIN/ACK ACK Close/FIN ACK + FIN/ACK Dois cenários que afetam a confiabilidade Reinicialização de um computador após uma conexão ter sido estabelecida Computador que não reinicializou não sabe do problema e considera a conexão válida Computador que reinicializou não sabe da existência da conexão e deve rejeitar esses pacotes Problema que não é simples de ser resolvido FIN_WAIT_2 FIN/ACK CLOSING ACK Timeout after two segment lifetimes TIME_WAIT LAST_ACK ACK CLOSED 47 48

9 Como alcançar a confiabilidade? Como alcançar a confiabilidade? Através de uma série de técnicas que tratam partes do problema Princípio básico para cada mensagem: Transmissão Temporização ou confirmação (positiva ou negativa) Retransmissão, se for o caso Repetição do processo um número finito de vezes Como alcançar a confiabilidade? Problema decorrente Como configurar temporizadores para comunicações em LANs e WANs? LANs: deve-se esperar pouco WANs: deve-se esperar mais Como alcançar a confiabilidade? Problema relacionado com a eficiência Rajadas de datagramas podem causar congestionamento Tempo para enviar, receber e confirmar uma mensagem pode variar uma ordem de magnitude em poucos ms TCP deve adaptar-se a diferentes condições de tráfego que podem causar diferentes atrasos num pequeno intervalo de tempo Retransmissão adaptativa Retransmissão adaptativa Protocolos de transporte anteriores ao TCP usavam um valor fixo de espera de confirmação para efeito de retransmissão No TCP esse tempo é variável TCP monitora o atraso em cada conexão e modifica o temporizador de retransmissão para acomodar mudanças Mudança é feita em função de uma análise estatística das mensagens transmitidas Na prática retransmissão adaptativa funciona bem 53 54

10 Retransmissão adaptativa Adaptive Retransmission (Original Algorithm) Measure SampleRTT for each segment/ ACK pair Compute weighted average of RTT EstRTT = α x EstRTT + β x SampleRTT where α + β = 1 α between 0.8 and 0.9 β between 0.1 and 0.2 Set timeout based on EstRTT TimeOut = 2 x EstRTT Karn/Partridge Algorithm Karn/Partridge Algorithm Após anos de uso da Internet descobriu-se um problema com o protocolo Um ACK não confirma uma transmissão Ele confirma o recebimento de um dado Ou, quando um segmento é retransmitido e um ACK chega ao transmissor É impossível determinar se o ACK deveria ser associado à primeira ou segunda transmissão para efeito de medir o RTT de amostra SampleR TT Sender Receiver Original transmission Retransmission ACK Amostra muito grande -- SampleR TT Sender Receiver Original transmission ACK Retransmission Amostra muito pequena Solution Karn/Partridge Algorithm Do not sample RTT when retransmitting Only sample for segments transmitted once Double timeout after each retransmission (rather than on last EstimatedRTT) Exponential backoff Congestion is the most likely cause of lost segments TCP should not react too aggressively to a timeout Jacobson/ Karels Algorithm New Calculations for average RTT Diff = SampleRTT - EstRTT EstRTT = EstRTT + (δ x Diff) Dev = Dev + δ( Diff - Dev) where δ is a factor between 0 and 1 Consider variance when setting timeout value TimeOut = µ x EstRTT + φ x Dev where µ = 1 and φ = 4 Notes algorithm only as good as granularity of clock (500ms on Unix) accurate timeout mechanism important to congestion control (later) 59 60

11 Controle de congestionamento Congestionamento da rede pode ser piorado se a camada de transporte retransmite pacotes que não foram perdidos Esse problema pode causar até um colapso da rede Controle de congestionamento TCP usa a quantidade de pacotes perdidos como uma medida de congestionamento Reduz a taxa de retransmissão à medida que esse valor aumenta A transmissão de mensagens é feita de forma exponencial até atingir um dado valor, quando passa a aumentar mais lentamente Controle de congestionamento Portos em conexões Números de portos abaixo de 1024 são chamados de portos bem-conhecidos 21: ftp 23: telnet Outros: RFC 1700 Conexão: Número IP + Número do porto TCP Extensions Implemented as header options Store timestamp in outgoing segments Extend sequence space with 32-bit timestamp (PAWS) Shift (scale) advertised window UDP User Datagram Protocol Protocolo de transporte não confiável (não há estabelecimento de conexão) Permite múltiplos processos de aplicação em cada hospedeiro compartilhar a mesma rede Não adiciona funcionalidade ao serviço de melhor esforço da rede subjacente 65 66

12 UDP Formato do segmento ou datagrama UDP Unreliable and unordered datagram service Adds multiplexing No flow control Endpoints identified by ports servers have well-known ports see /etc/services on Unix SrcPort Checksum DstPort Length Data Simple Demultiplexor (UDP) Header format Optional checksum psuedo header + UDP header + data Pseudo header: three IP fields (protocol number, source IP addr., dest IP addr) plus UDP length field SrcPort DstPort UDP Onde é usado: Aplicações cliente-servidor onde existe apenas uma requisição e uma resposta O custo para estabelecer uma conexão é alto quando comparado com a transferência de dados Checksum Length Data 69 70