Informações erradas sobre TCP nas quais programadores acreditam

• Assim como o NetworkManager pode interpretar uma breve instabilidade de conexão como “sem rede”, alguns softwares confiam mais no próprio julgamento de estado do que na recuperação do TCP, mas isso pode ser perigoso em redes reais
• A crença de que “os dados enviados chegam”, “os dois lados acabam concordando sobre quais bytes foram entregues” e “isso pode ser garantido com protocolos de aplicação como HTTP ou SMTP” falha em algumas situações
• Se a conexão cair enquanto um ACK ainda está sendo processado, o remetente não tem como saber se o segmento foi recebido, e essa limitação não pode ser resolvida apenas com um único fluxo TCP entre duas partes, como no Two Generals’ Problem
• O SMTP também trata esse problema nas RFC 1047 e RFC 2821, e no momento em que a responsabilidade pela entrega muda de lado existe uma zona ambígua em que uma falha de conexão pode causar transmissão duplicada ou perda
• Se você tratar redes estranhas como exceções ou ignorar detalhes de funcionamento como algoritmo de Nagle, controle de congestionamento e bloqueio de ICMP, fica fácil interpretar incorretamente falhas reais

---

O problema de concluir o estado da rede antes do TCP

• Um usuário do NetworkManager enfrentou no passado instabilidade na conexão sem fio em ambientes de roaming entre dormitório e campus, e viveu situações em que uma pequena perda de pacotes fazia o sistema inteiro receber o estado de “sem rede”
• Na época, havia chance de a rede voltar logo, e a recuperação normal do TCP, mesmo com forte aumento de latência, ainda podia permanecer transparente para as aplicações
• Esse caso se conecta ao problema de aplicações ou componentes do sistema interpretarem rápido demais como falha uma interrupção temporária que o TCP conseguiria tratar

Crenças comuns, mas erradas, sobre TCP

• As frases abaixo aparecem com frequência em discussões sobre TCP, mas cada uma delas é falsa pelo menos em alguns casos
  • TCP é confiável, então todos os dados enviados chegam ao outro lado
  • TCP é confiável na maior parte do tempo
  • Mesmo que o TCP não ofereça confiabilidade no sentido pleno, remetente e receptor acabam concordando com exatidão sobre quais bytes foram transmitidos
  • Se você construir um protocolo de aplicação orientado a mensagens, como HTTP ou SMTP, sobre TCP, dá para obter essa garantia
  • Existe algo como “pacote TCP”
  • Não existe algo como “pacote TCP”
  • Se você não consegue se conectar a um host remoto conhecido, então está offline
  • O algoritmo de Nagle é bom
  • O algoritmo de Nagle é ruim
  • Não é preciso se preocupar com o algoritmo de Nagle
  • Basta pensar no TCP como um pipe Unix bidirecional atravessando a rede
  • Se a rede é transparente para o TCP, então também é transparente para o IP
  • Se a rede é transparente para o HTTP/1.1, então também é transparente para o TCP
  • Redes estranhas que não são transparentes a protocolos padrão são excepcionais e podem ser ignoradas
  • O TCP é implementado sobre o IP

Por que é difícil concordar exatamente sobre os bytes entregues

• Os problemas 1 a 4 acima, ligados à confiabilidade do TCP, se relacionam com o Two Generals’ Problem
• Se a conexão cair enquanto um ACK ainda está em processamento, o remetente não tem como confirmar se aquele segmento foi recebido
• Essa limitação não desaparece mesmo que você empilhe camadas mais complexas sobre o TCP
• Não é possível criar essa garantia sobre um único fluxo TCP entre duas partes; para isso, seria preciso algo semelhante a Paxos ou Raft e no mínimo 3 nós
• O mesmo tipo de problema se aplica não só ao TCP, mas também a serviços entre duas partes baseados em UDP ou IP

A zona cinzenta da responsabilidade de entrega exposta pelo SMTP

• O SMTP deixa esse problema bem visível porque é um serviço em que ambos os lados precisam se preocupar explicitamente com o recebimento da mensagem
• A RFC 1047 trata desse problema sob a ótica do SMTP, e a RFC 2821 determina que implementações devem seguir o conselho central da RFC 1047
• No exemplo do SMTP, os seguintes estados são distintos
  • É possível chegar a um ponto em que ambos os lados concordam que o email foi transmitido do cliente para o servidor
  • Também é possível chegar a um ponto em que ambos os lados concordam que o servidor assumiu a responsabilidade pela entrega do email
  • Mas antes disso é inevitável passar por um estado ambíguo em que não está claro quem detém naquele momento a responsabilidade pela entrega do email
• Se a conexão cair nesse estado ambíguo, o email será duplicado ou perdido
• A especificação do SMTP define qual lado deve preferir a duplicação do email, mas não dá para saber o quanto isso foi testado nas implementações reais
• O objetivo de Paxos e Raft não é apenas alcançar o estado final em si, mas evitar esse tipo de estado ambíguo

Os limites do conhecimento que restam no acordo entre duas partes

• Um comentário argumenta que, mesmo em um link não confiável porém não malicioso, duas partes podem concordar sobre algum conjunto de bytes no sentido de que “foi entregue e ambos sabem disso”
• Na discussão complementar, conclui-se que uma das partes pode saber que o conjunto acordado inclui pelo menos os primeiros N bytes, mas não pode saber que o conjunto acordado é exatamente os primeiros N bytes
• Portanto, pode até existir um conjunto de bytes “certamente entregue e conhecido por ambos”, mas depois dele permanece uma zona cinzenta em que remetente e receptor não conseguem determinar o estado de conhecimento um do outro
• Ignorar essa diferença facilita o surgimento de falhas estranhas em sistemas distribuídos

Redes reais e as armadilhas das camadas inferiores

• A crença de que “redes estranhas que não são transparentes a protocolos padrão podem ser ignoradas” já causou problemas várias vezes
• buffer bloat é citado como um caso em que roteadores quebram mecanismos de controle de congestionamento
• Redes que bloqueiam ICMP ou descartam tráfego que não entendem também podem causar problemas
• A ideia de que “não é preciso entender controle de congestionamento” também se aproxima de um entendimento errado do TCP
  • Um subexemplo disso é a noção de que “se a velocidade desejada não vier, basta abrir várias conexões TCP”