02 - Serviço Confiável
video: https://youtu.be/... no frontmatter da nota.Serviço Confiável
O Serviço Confiável é a função primária e mais complexa do modelo de Circuito Virtual na Camada de Transporte (ex: TCP). Enquanto a Camada de Rede subjacente (IP) é inerentemente não confiável ("melhor esforço"), o serviço confiável da Camada de Transporte atua como uma camada de abstração que esconde todas as falhas da rede da aplicação.
Para a aplicação, o serviço confiável garante que o canal de comunicação seja perfeito: tudo o que é enviado é recebido, na ordem correta, sem corrupção e sem duplicação. Para alcançar isso sobre uma infraestrutura falha, o protocolo de transporte implementa um conjunto rigoroso de mecanismos de controle de erro, recuperação e gerenciamento de estado.
1. As Quatro Garantias Fundamentais
Um serviço é considerado confiável apenas quando fornece garantias explícitas sobre quatro aspectos da transferência de dados:
- Garantia de Entrega (No Loss): O protocolo garante que todos os dados enviados pelo transmissor chegarão ao receptor. Se um pacote se perder no caminho, o protocolo detectará essa perda e recuperará o dado.
- Garantia de Integridade (No Corruption): Os dados não podem ser alterados durante o trânsito. Qualquer erro de bit (0 virando 1) é detectado e corrigido (geralmente via retransmissão).
- Garantia de Ordenação (In-Order Delivery): Os dados devem ser entregues à aplicação receptora exatamente na mesma sequência em que foram enviados. Como a rede IP pode embaralhar os pacotes, o serviço confiável deve reordená-los.
- Garantia de Não Duplicação (No Duplication): Se a rede entregar acidentalmente uma cópia duplicada de um pacote (o que pode acontecer em cenários de retransmissão), o serviço confiável deve descartar a cópia extra, entregando apenas uma instância do dado para a aplicação.
2. Mecanismos de Implementação da Confiabilidade
Para cumprir essas garantias sobre uma rede "best-effort", o serviço confiável utiliza uma série de mecanismos técnicos coordenados:
A. Números de Sequência (Sequence Numbers)
Cada byte (ou segmento, dependendo da implementação) de dados enviado é numerado sequencialmente. Isso cria uma ordem lógica inquestionável.
- Função: Permite que o receptor identifique lacunas (pacotes perdidos) e pacotes fora de ordem. Se o receptor tem o byte 1000 e recebe o byte 3000, ele sabe que os bytes entre 1001 e 2999 estão faltando ou a caminho.
- Remontagem: O receptor usa esses números para montar o fluxo de bytes na ordem correta antes de passá-lo para a aplicação.
B. Confirmação de Recebimento (Acknowledgment - ACK)
O receptor envia feedback de volta para o remetente.
- ACK Cumulativo (TCP): O receptor envia um número de ACK indicando o próximo byte que espera receber. Por exemplo, enviar
ACK 2001significa "recebi tudo até o byte 2000 corretamente, estou esperando o 2001". Isso confirma implicitamente o recebimento de todos os bytes anteriores. - ACK Seletivo (SACK - Selective ACK): Extensão do TCP (RFC 2018) que permite ao receptor informar explicitamente quais blocos não contíguos já recebeu, otimizando a retransmissão em redes com alta perda.
C. Temporizadores e Retransmissão (Timers and Retransmission)
O remetente não assume que o dado chegou apenas porque o enviou. Ele inicia um temporizador (timer) para cada pacote não confirmado.
- Timeout: Se o temporizador expirar antes do remetente receber o ACK correspondente, o remetente assume que o pacote foi perdido.
- Ação: O remetente retransmite (envia novamente) o pacote. Este ciclo continua até que o ACK seja recebido ou a conexão seja abandonada.
- Retransmissão Rápida (Fast Retransmit): Em alguns protocolos (como o TCP), se o remetente receber múltiplos ACKs duplicados (ex: três ACKs seguidos para o mesmo número), ele infere que um pacote foi perdido e o retransmite imediatamente, sem esperar o timeout expirar.
- Cálculo do RTO (Retransmission Timeout): O TCP usa algoritmos como o de Karn e o algoritmo EWMA para estimar o RTT dinamicamente e ajustar o RTO, evitando retransmissões prematuras ou tardias.
D. Verificação de Soma (Checksum)
Embora a Camada de Rede tenha um checksum, ele é fraco (cobre apenas o cabeçalho IP). O serviço confiável (TCP) implementa seu próprio checksum que cobre o cabeçalho de transporte, o cabeçalho de dados e a carga útil (payload).
- Se o segmento chegar corrompido (erro de bit), o checksum falhará, o segmento será descartado silenciosamente e o remetente eventualmente fará a retransmissão devido à falta de ACK.
3. O Papel dos Buffers
A confiabilidade exige o uso de memória (buffers) tanto no envio quanto na recepção para gerenciar o fluxo não confiável da rede.
- Buffer de Reenvio (Sending Buffer): O remetente deve manter uma cópia de todos os dados enviados mas ainda não confirmados (ACKed). Se um pacote for perdido, ele precisa dos dados no buffer para retransmitir. Somente após receber o ACK, ele pode liberar esse espaço na memória.
- Buffer de Recepção (Receiving Buffer): O receptor precisa armazenar dados que chegaram fora de ordem. Se recebeu o pacote 3 antes do 2, ele guarda o 3 no buffer e aguarda o 2 chegar para montar a sequência correta antes de entregar à aplicação. Ele também filtra duplicatas aqui.
4. Controle de Fluxo x Controle de Congestionamento
A confiabilidade está intimamente ligada a dois controles complementares:
| Mecanismo | Objetivo | Como Opera |
|---|---|---|
| Controle de Fluxo | Proteger o receptor de sobrecarga | Janela deslizante (Window Size no cabeçalho TCP) |
| Controle de Congestionamento | Proteger a rede de saturação | Algoritmos: Slow Start, Congestion Avoidance, Fast Recovery |
Sem esses controles, retransmissões em massa poderiam agravar congestionamento e gerar avalanche de pacotes, comprometendo a própria confiabilidade.
5. Custo da Confiabilidade
A confiabilidade tem preço:
- Latência Adicional: Cada retransmissão adiciona pelo menos 1 RTT ao fluxo.
- Memória: Cada conexão TCP consome de 1 KB a 4 KB de RAM para TCB e buffers.
- CPU: Cálculo de checksum, manutenção de timers e reordenação exigem processamento.
- Largura de Banda: ACKs e retransmissões consomem banda adicional (overhead de 5-10% típico).
6. Exemplo Prático de Recuperação
Cenário: download de 4 segmentos (Seq 1, 2, 3, 4) onde o segmento 2 se perde.
Emissor -> Seg 1 -> Receptor (entrega à aplicação, envia ACK 2)
Emissor -> Seg 2 X PERDIDO
Emissor -> Seg 3 -> Receptor (buffera, envia ACK 2 duplicado)
Emissor -> Seg 4 -> Receptor (buffera, envia ACK 2 duplicado)
Emissor recebe 3x ACK 2 -> Fast Retransmit do Seg 2
Emissor -> Seg 2 -> Receptor (entrega 2,3,4 à aplicação, envia ACK 5)
7. Aplicações que Demandam Confiabilidade
| Aplicação | Por quê? |
|---|---|
| HTTP/HTTPS (web) | Erro em HTML/JS quebra a renderização |
| SMTP (e-mail) | Mensagem incompleta é inaceitável |
| FTP/SFTP | Arquivo corrompido é inútil |
| SSH | Comando mal interpretado é catastrófico |
| BGP (rotas) | Informação de rota inconsistente quebra a internet |
8. A Abstração para a Aplicação
O resultado final do serviço confiável é que a aplicação de software (navegador, cliente de e-mail) não precisa se preocupar com a física da rede.
- Ilusão de Perfeição: Do ponto de vista do programador, é como se houvesse um cabo dedicado e infalível conectando as duas aplicações. O programador escreve dados em um soquete e lê dados dele, sem precisar implementar timers, retransmissões ou verificação de erros. A complexidade de tornar a comunicação confiável é totalmente encapsulada dentro da implementação do protocolo (o kernel do sistema operacional).
9. Conclusão
O Serviço Confiável é o contrato mais exigente da Camada de Transporte. Sua construção sobre redes não confiáveis exige combinação sofisticada de sequenciamento, confirmações, temporizadores e buffers. Apesar do custo em memória e latência, esse modelo tornou possível o surgimento da web, do e-mail e do comércio eletrônico, garantindo que a internet funcione como um meio confiável de transporte de dados mesmo sobre infraestruturas físicas sujeitas a ruído, perdas e congestionamentos.