Entrega Não Garantida (Best-Effort Delivery)

1. Definição

A característica de Entrega não garantida é a premissa central e definitiva dos serviços baseados em datagramas na Camada de Transporte (ex.: UDP). Tecnicamente, isso significa que o protocolo de transporte não oferece nenhuma promessa formal de que os dados enviados pelo processo de origem chegarão intactos ao processo de destino.

Essa abordagem é frequentemente descrita pelo princípio "Fire and Forget" (Dispare e Esqueça). O remetente entrega os dados ao protocolo, e este os empurra para a rede. Uma vez que os dados deixam o remetente, a camada de transporte considera sua tarefa concluída. Se o pacote for perdido, corrompido ou duplicado em trânsito, o protocolo não tentará corrigir o erro, nem notificará o remetente sobre a falha.

2. A Abstração do "Melhor Esforço" (Best-Effort)

A entrega não garantida no nível de transporte herda o modelo "melhor esforço" da Camada de Rede (IP). Como o IP não garante a entrega, um protocolo de transporte simples (sem conexão) não possui mecanismos para corrigir as falhas do IP.

As Não-Garantias do Modelo Best-Effort

• Probabilidade, não Certeza: O serviço opera na probabilidade. Na maioria das vezes, os dados chegam porque a rede está saudável (taxa de perda típica na internet: < 1%). No entanto, o protocolo é projetado para funcionar mesmo que a entrega falhe.
• Simplicidade: Ao abdicar da responsabilidade de garantir a entrega, o protocolo elimina a necessidade de algoritmos de recuperação, janelas deslizantes e temporizadores de retransmissão.

3. Ausência de Confirmação (No Acknowledgment)

A manifestação técnica imediata da entrega não garantida é a inexistência de um mecanismo de ACK (Acknowledgment/Confirmação).

• Lógica Unidirecional: O fluxo de dados é estritamente unidirecional do ponto de vista do protocolo de transporte. Não existe um fluxo de retorno automático do receptor dizendo "Recebi o pacote 100" ou "Faltou o pacote 99".
• Invisibilidade da Perda: Se um roteador no meio do caminho estiver congestionado e descartar um pacote (drop), o remetente nunca será informado. Do ponto de vista do emissor, o pacote foi enviado e "saiu de casa". Se nunca chegar ao destino, o emissor continuará sua vida sem saber da perda, a menos que a aplicação implemente sua própria verificação (ex.: timeout na aplicação).

4. Sem Retransmissão Automática

A consequência direta da ausência de confirmações é a impossibilidade de retransmissão automática.

Comparação: TCP vs UDP (Buffer de Envio)

TCP:   send() -> copia para buffer -> transmite -> mantém cópia -> recebe ACK -> libera buffer
                                              -> timeout -> retransmite
UDP:   send() -> transmite -> libera imediatamente (sem cópia)

• Imutabilidade do Buffer (TCP): Em serviços confiáveis (como TCP), o remetente mantém uma cópia dos dados enviados em um buffer até receber uma confirmação. Se a confirmação não vier, ele reenvia a cópia.
• Disposição Imediata (UDP): No serviço de entrega não garantida, uma vez que o dado é enviado para a rede, o buffer de envio pode ser imediatamente limpo ou reutilizado. O protocolo não guarda o histórico para tentar novamente. Se o dado se perdeu, está perdido para sempre.

5. Causas Comuns de Falha de Entrega

O protocolo de entrega não garantida não protege contra as falhas inerentes da infraestrutura de rede. As causas comuns de não-entrega incluem:

Detalhamento das Principais Causas

• Congestionamento: Roteadores possuem filas de pacotes (buffers) limitadas. Se a taxa de entrada for maior que a taxa de saída, a fila enche e novos pacotes são descartados (Tail Drop). Algoritmos modernos como RED (Random Early Detection) e CoDel fazem drops aleatórios antes do estouro.
• Erros de Bit: Se o dado for alterado durante o trânsito (ruído elétrico) e o checksum falhar, o receptor descarta o pacote silenciosamente. O remetente não sabe que o receptor o jogou fora.
• Roteamento Dinâmico: Mudanças repentinas nas tabelas de roteamento podem fazer com que um pacote entre em um loop ou seja enviado para um enlace inexistente, levando ao descarte por TTL expirado (ICMP Type 11 Code 0).

6. A Responsabilidade da Camada de Aplicação

Quando uma aplicação escolhe um serviço de entrega não garantida (como usar UDP), ela assume a responsabilidade de lidar com a perda, se necessário para sua funcionalidade.

Padrões de Tratamento pela Aplicação

• Tolerância a Perda: Aplicações como streaming de áudio preferem perder um pacote (pequeno estalo) a recebê-lo 500 ms atrasado, quando o player já passou daquele ponto.
• Implementação Própria: Se a aplicação precisa que os dados cheguem (ex.: TFTP, DNS sobre UDP em modo não-trivial), ela implementa sua própria lógica de números de sequência, ACKs e retransmissões, simulando um serviço confiável sobre UDP.
• Forward Error Correction (FEC): Aplicações como Quake 3, WebRTC e streaming usam códigos de correção (Reed-Solomon, XOR parity) para recuperar perdas sem retransmissão, evitando o overhead de ACKs.

Exemplo Prático: TFTP (RFC 1350)

Cliente                Servidor
   |--- RRQ "arquivo.txt" -->|    (Read Request)
   |<-- DATA block=1 -------|    (512 bytes)
   |--- ACK block=1 -------->|
   |<-- DATA block=2 -------|
   |     (perdido!)          |
   |--- (timeout) ---------->|    (cliente retransmite último ACK)
   |--- ACK block=1 -------->|    (servidor reenvia block=2)
   |<-- DATA block=2 -------|
   |--- ACK block=2 -------->|
   ...

7. Tolerância à Perda por Tipo de Aplicação

8. Resumo das Não-Garantias

Em um serviço de entrega não garantida, o protocolo não garante que:

1. O pacote chegará ao destino final.
2. O pacote chegará dentro de um limite de tempo específico (latência).
3. O pacote não chegará duplicado.
4. O pacote chegará na mesma ordem em que foi enviado.
5. O pacote chegará sem corrupção de bits.

Essas ausências de garantias são o "preço" pago para obter um serviço de transporte extremamente rápido, com baixo overhead e escalabilidade massiva. Para a internet moderna, esse tradeoff é essencial: bilhões de dispositivos móveis, IoT e sensores funcionam precisamente porque a rede não promete o que não pode cumprir.

9. Conclusão

A entrega não garantida é uma decisão de design consciente, não uma falha. Ao alinhar as expectativas do protocolo com as realidades da rede física (que é inerentemente não confiável), o UDP oferece um serviço previsível em sua simplicidade. As aplicações escolhem o nível de confiabilidade necessário, evitando pagar pelo custo (latência, memória, CPU) de garantias que não precisam.