Não Confiável (Unreliable / Best-Effort)

1. Definição Técnica

No contexto da arquitetura de redes, o termo "Não Confiável" (Unreliable) possui uma definição técnica precisa que muitas vezes causa confusão para iniciantes. Ele não significa que o serviço é falho, quebrado ou propenso a erros sistêmicos. Pelo contrário, significa que o protocolo não oferece garantias sobre o sucesso da entrega. É uma filosofia de projeto conhecida como "Melhor Esforço" (Best-Effort).

No serviço de Datagrama (tipicamente implementado pelo UDP), a camada de transporte trata o envio de dados como um ato de "disparar e esquecer" (fire-and-forget). Ela entrega os dados à Camada de Rede e espera que cheguem, mas não implementa nenhum mecanismo para verificar se chegaram, corrigir erros ou repetir o envio se falharem.

Diferença entre "Não Confiável" e "Quebrado"

2. Ausência de Garantia de Entrega

A característica central do serviço não confiável é que o remetente não recebe confirmação (ACK - Acknowledgment) do receptor.

• Perda de Pacotes: Se um roteador estiver congestionado e descartar um datagrama, ou se houver ruído na linha física e o datagrama for corrompido, o protocolo de transporte não fará nada para recuperar o pacote.
• Inércia do Emissor: Uma vez que o pacote é enviado para a rede, a responsabilidade do emissor termina. Se o receptor nunca receber o pacote, o emissor não será notificado. O pacote simplesmente desaparece no "éter" digital.
• Implicação: Se a aplicação de usuário precisa saber que o dado foi entregue (como em uma transferência de arquivo bancário), ela não deve depender de um serviço não confiável sem implementar suas próprias verificações na camada de aplicação.

Estatísticas Típicas de Perda na Internet

Em condições normais, a maioria dos pacotes chega. Mas o protocolo não pode assumir isso; deve estar preparado para falhas.

3. Ausência de Garantia de Ordem

O serviço não confiável não mantém qualquer estado sobre a sequência dos pacotes. Cada datagrama é uma entidade independente.

• Roteamento Dinâmico: Como a rede IP pode rotear cada pacote por caminhos diferentes (load balancing ECMP ou falhas transitórias), o datagrama número 2 pode chegar antes do datagrama número 1.
• Chegada Desordenada: O protocolo de transporte entrega os dados à aplicação exatamente na ordem em que chegam do IP. Se a ordem estiver errada, a aplicação receberá os dados bagunçados.
• Sem Reordenação: Diferente de serviços confiáveis (como o TCP), o serviço de datagrama não possui números de sequência lógica para reordenar os dados antes de passá-los para a aplicação.

4. Corrupção de Dados

Embora a maioria dos serviços de datagrama (como o UDP) possua um campo de Checksum para detectar erros, a política de tratamento de erro é brutal: descarte puro e simples.

• Detecção, não Correção: Se o checksum do cabeçalho/dados estiver errado, o receptor descarta o pacote silenciosamente.
• Sem Recuperação: O receptor não envia uma mensagem de erro de volta pedindo uma retransmissão (como o TCP faria com SACKs ou ACKs negativos). O dado é perdido, e o protocolo segue adiante.

Camadas de Detecção de Erro

[Aplicação] -> [UDP checksum] -> [IP checksum] -> [Ethernet FCS (CRC-32)]
                       |               |                 |
                       |               |                 v
                       |               |            Drop no enlace
                       |               v
                       |         Drop no host receptor
                       v
                 Drop no host receptor

A proteção é em camadas, mas nenhuma camada corrige o erro: todas apenas descartam. A correção é responsabilidade da aplicação (se necessária).

5. A Vantagem da Não Confiabilidade

Pode parecer contraditório que um sistema de comunicação deseje ser não confiável, mas essa característica é o segredo da eficiência e velocidade de certas aplicações.

Comparação de Overhead: TCP vs UDP

• Baixa Latência: Não há necessidade de esperar por handshakes de três vias antes de enviar dados. O dado é enviado imediatamente. Não há tempo gasto esperando confirmações de entrega antes de enviar o próximo pacote.
• Baixo Overhead (Sobrecarga): Como não é necessário manter buffers de retransmissão, timers complexos, janelas deslizantes ou tabelas de estado de conexão, o processamento de CPU e o consumo de memória são mínimos.
• Independência de Estado: O servidor ou roteador não precisa lembrar quem enviou o quê anteriormente. Ele apenas processa o pacote atual.

Medição Prática de Latência

Consulta DNS a 8.8.8.8 com 20 ms de RTT:

• UDP: ~20 ms (1 RTT só do dado)
• TCP (com TLS 1.2): ~120 ms (TCP handshake 40 ms + TLS handshake 80 ms)
• TCP (com TLS 1.3): ~60 ms (TCP handshake 40 ms + TLS 1-RTT 20 ms)
• QUIC (UDP + TLS 1.3): ~20 ms (0-RTT em conexões retomadas)

A diferença explica por que Google, Cloudflare e Facebook migraram seus serviços para QUIC sobre UDP.

6. Quando "Não Confiável" é Ideal

O serviço não confiável é a escolha correta quando a correção perfeita dos dados é menos importante do que a velocidade ou a frescor da informação.

Cenários Típicos

Cenários que Exigem Confiabilidade (NÃO use UDP)

• Transferência de arquivos (FTP, SCP, SFTP) → TCP
• E-mail (SMTP, IMAP) → TCP
• Web browsing (HTTP/1, HTTP/2) → TCP
• Transações bancárias → TCP
• Shell remoto (SSH) → TCP
• Acesso a banco de dados → TCP

7. Resumo das Garantias Ausentes

Para definir tecnicamente um serviço de Datagrama como "Não Confiável", significa que ele não garante:

1. Que o pacote chegará. (Pode ser perdido por roteadores congestionados).
2. Que chegará na ordem certa. (Pode chegar fora de sequência).
3. Que chegará sem erros. (Erros detectados levam ao descarte do pacote).
4. Que não chegará duplicado. (Pacotes IP podem se replicar e chegar duas vezes).
5. Que chegará dentro de um tempo limite. (Latência pode variar arbitrariamente).

É responsabilidade da aplicação (ou de uma camada de protocolo superior) adicionar essas garantias se elas forem necessárias. Exemplos de camadas de aplicação que adicionam confiabilidade sobre UDP: TFTP (RFC 1350), QUIC (RFC 9000), DCCP (RFC 4340), SCTP (parcialmente sobre UDP).

8. Conclusão

A "não confiabilidade" do UDP não é um defeito, mas uma escolha de design alinhada com o princípio fim-a-fim: a rede oferece o mínimo (entrega best-effort), e os extremos decidem quanto de confiabilidade precisam pagar. Essa separação de responsabilidades permite que a mesma rede atenda desde transferências bancárias ultraconfiáveis (sobre TCP) até streaming de vídeo em tempo real para bilhões de dispositivos (sobre UDP), cada um usando exatamente o nível de serviço que necessita.