Informações erradas sobre TCP em que programadores acreditam

NetworkManager ou networkd

• NetworkManager ou networkd

  • O usuário explica por que mudou para um gerenciamento baseado em wpa_supplicant
  • Apresenta uma lista de crenças erradas sobre TCP
  • Aborda equívocos sobre a confiabilidade do TCP

• Lista de crenças erradas sobre TCP

  • TCP é sempre confiável
  • TCP é confiável na maior parte do tempo
  • TCP não é confiável, mas o remetente e o destinatário acabarão concordando sobre os bytes transmitidos
  • É possível garantir confiabilidade construindo um protocolo orientado a mensagens sobre TCP
  • Existe algo como um pacote TCP
  • Não existe algo como um pacote TCP
  • Se a conexão com o host remoto falhar, ele está offline
  • O algoritmo de Nagle é bom
  • O algoritmo de Nagle é ruim
  • Não é preciso se preocupar com o algoritmo de Nagle
  • TCP trata a rede de forma transparente
  • Se a rede é transparente para TCP, também é transparente para IP
  • Se a rede é transparente para HTTP/1.1, também é transparente para TCP
  • Redes que não são transparentes para protocolos padrão são excepcionais
  • TCP é implementado sobre IP

• Explicação

  • Se a conexão cair enquanto um ACK estiver pendente, o remetente não pode saber se o segmento foi recebido
  • São necessários algoritmos como Paxos ou Raft, e no mínimo três nós
  • Esse problema também ocorre em protocolos como SMTP

• Opiniões adicionais

  • Duas partes podem chegar a um acordo por meio de um link incerto
  • É possível concordar sobre um subconjunto dos bytes transmitidos
  • O conjunto de bytes acordado pode ser 0, e pode crescer
  • Paxos não é necessário

• Discussão adicional

  • Não é possível saber o intervalo exato do conjunto de bytes acordado
  • Crenças erradas sobre transparência de rede causam problemas
  • Existem redes que bloqueiam ICMP ou descartam pacotes que não entendem
  • É necessário conhecimento sobre controle de congestionamento

Resumo do GN⁺

• Este artigo trata de crenças erradas sobre a confiabilidade do TCP e inclui uma discussão sobre a escolha de ferramentas de gerenciamento de rede
• Explica que os problemas de confiabilidade do TCP exigem algoritmos complexos como o Paxos
• Destaca que crenças erradas sobre transparência de rede podem causar problemas reais
• Apresenta vários fatores a considerar ao escolher ferramentas de gerenciamento de rede

[GN⁺]

Opiniões no Hacker News

• O formato de "falsehoods programmers believe" não é claro e causa confusão

  • Não dá para entender a discussão sobre a existência de pacotes TCP
  • É um conteúdo que gera confusão filosófica

• Surpreende que a conexão continue ativa mesmo depois de desconectar e reconectar o cabo Ethernet

  • O TCP foi projetado para continuar funcionando mesmo se uma bomba cair

• É possível garantir entrega "at most once" ou "at least once", mas é impossível garantir entrega "exactly once"

  • Muitos desenvolvedores juniores acham que a ausência de garantia de entrega "exactly once" é um bug

• Se a conexão cair enquanto o ACK ainda estiver pendente, o remetente não tem como saber se o segmento foi recebido

  • O TCP fornece um pipe bidirecional, e a garantia de entrega correta é responsabilidade da aplicação
  • Se uma requisição HTTP for interrompida antes de receber resposta, o remetente deve assumir que a requisição não chegou ao servidor e tentar de novo em uma nova conexão

• Há quem se pergunte se o autor nunca ouviu falar em códigos de correção de erro

  • Frames TCP ou Ethernet incluem bytes de FEC
  • HTTP over TLS usa frames de dados criptografados, e se houver perda de dados eles se tornam irrecebíveis
  • Grande parte da internet moderna é baseada nesse paradigma

• Ao usar hardware próprio dentro de um datacenter, dá para ignorar detalhes de baixo nível

  • Limites de largura de banda, limites de RPS de pacotes e latência continuam sendo importantes

• Este artigo não é um texto finalizado, e o título do envio no HN pode induzir ao erro

• Isso lembra um problema que tentavam resolver quando trabalhavam no VKontakte

  • Ao enviar uma mensagem no metrô, ela chega ao servidor, mas o sinal cai antes de a resposta voltar
  • O cliente interpreta isso como falha no envio da mensagem e tenta novamente
  • Resolveram o problema usando um "ID aleatório" gerado pelo cliente
  • O Telegram envia todas as respostas não confirmadas da conexão anterior quando o cliente se reconecta ao servidor

• Muita gente não entende que TCP não é uma chamada de função

  • Recentemente surgiu um novo limitador de taxa de TCP em um estado extremamente problemático
  • A maioria dos contêineres provavelmente está sofrendo com problemas de Bufferbloat