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). Em termos técnicos, 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.

Esta 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.

1. A Abstração do “Melhor Esforço” (Best-Effort)

A entrega não garantida no nível de transporte reflete e 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.

• Probabilidade, não Certeza: O serviço opera na probabilidade. Na maioria das vezes, os dados chegam porque a rede está saudável. No entanto, o protocolo é projetado para funcionar mesmo que a entrega falhe. Ele não depende do sucesso para manter a estabilidade do sistema.
• Simplicidade: Ao abdicar da responsabilidade de garantir a entrega, o protocolo elimina a necessidade de complexos algoritmos de recuperação de erros, janelas de retransmissão e temporizadores de espera.

2. 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. O remetente envia dados para o destino. 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 “saio da casa”. Se ele 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: um timeout na aplicação).

3. Sem Retransmissão Automática

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

• Imutabilidade do Buffer: 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: 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, ele está perdido para sempre.

4. Causas da 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:

• Congestionamento (Enchimento de Filas): 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). O protocolo de transporte não sabe disso.
• Erros de Bit (Corrupção): 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.

5. 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 de dados, se isso for necessário para sua funcionalidade.

• Tolerância a Perda: Algumas aplicações (ex: streaming de áudio) escolhem este serviço especificamente porque preferem não receber dados antigos (retransmitidos) a chegar atrasados. A perda de dados é aceitável e preferível.
• Implementação Própria: Se a aplicação precisa que os dados cheguem (ex: TFTP - Trivial File Transfer Protocol), ela deve implementar sua própria lógica de números de sequência, ACKs e retransmissões dentro da aplicação (na camada de aplicação), simulando um serviço confiável sobre um transporte não confiável.

6. 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.

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.