Les fausses idées sur TCP auxquelles les programmeurs croient

NetworkManager ou networkd

• NetworkManager ou networkd

  • L’utilisateur explique pourquoi il est passé à une gestion basée sur wpa_supplicant
  • Il présente une liste de fausses croyances sur TCP
  • Il aborde les malentendus concernant la fiabilité de TCP

• Liste des fausses croyances sur TCP

  • TCP est toujours fiable
  • TCP est fiable la plupart du temps
  • TCP n’est pas fiable, mais l’émetteur et le récepteur finiront tout de même par s’accorder sur les octets transmis
  • Construire un protocole orienté message au-dessus de TCP permet de garantir la fiabilité
  • Les paquets TCP existent
  • Les paquets TCP n’existent pas
  • En cas d’échec de connexion à un hôte distant, celui-ci est hors ligne
  • L’algorithme de Nagle est une bonne chose
  • L’algorithme de Nagle est une mauvaise chose
  • Il n’est pas nécessaire de se préoccuper de l’algorithme de Nagle
  • TCP traite le réseau de manière transparente
  • Si le réseau est transparent pour TCP, il l’est aussi pour IP
  • Si le réseau est transparent pour HTTP/1.1, il l’est aussi pour TCP
  • Un réseau qui n’est pas transparent pour les protocoles standards est exceptionnel
  • TCP est implémenté sur la base d’IP

• Explication

  • Si la connexion est interrompue alors qu’un ACK est en attente, l’émetteur ne peut pas savoir si le segment a été reçu
  • Des algorithmes comme Paxos ou Raft sont nécessaires, avec au moins trois nœuds
  • Ce problème apparaît aussi dans des protocoles comme SMTP

• Avis supplémentaire

  • Deux parties peuvent parvenir à un accord via un lien incertain
  • Elles peuvent s’accorder sur un sous-ensemble des octets transmis
  • L’ensemble des octets convenus peut être nul, puis augmenter
  • Paxos n’est pas nécessaire

• Discussion supplémentaire

  • Il est impossible de connaître la portée exacte de l’ensemble des octets convenus
  • Les fausses croyances sur la transparence du réseau causent des problèmes
  • Certains réseaux bloquent ICMP ou abandonnent les paquets qu’ils ne comprennent pas
  • Une connaissance du contrôle de congestion est nécessaire

Résumé de GN⁺

• Cet article traite des fausses croyances sur la fiabilité de TCP et inclut une discussion sur le choix des outils de gestion réseau
• Il explique que les problèmes de fiabilité de TCP nécessitent des algorithmes complexes comme Paxos
• Il souligne que les fausses croyances sur la transparence du réseau peuvent provoquer de vrais problèmes
• Il présente divers éléments à prendre en compte lors du choix d’un outil de gestion réseau

[GN⁺]

Avis Hacker News

• Le format « falsehoods programmers believe » manque de clarté, ce qui prête à confusion

  • Le débat sur l’existence même des paquets TCP est difficile à comprendre
  • Le contenu crée une confusion philosophique

• Surprise de voir qu’une connexion reste active même après avoir débranché puis rebranché un câble Ethernet

  • TCP a été conçu pour continuer à fonctionner même si des bombes tombent

• Il est possible de garantir une livraison « at most once » ou « at least once », mais pas une livraison « exactly once »

  • Beaucoup de développeurs juniors pensent que l’absence de garantie « exactly once » est un bug

• Si la connexion est coupée alors qu’un ACK est encore en attente, l’émetteur ne peut pas savoir si le segment a été reçu

  • TCP fournit un tube bidirectionnel, et la garantie d’une livraison exacte relève de la responsabilité de l’application
  • Si une requête HTTP est interrompue avant de recevoir une réponse, l’émetteur doit supposer que la requête n’est pas arrivée au serveur et réessayer via une nouvelle connexion

• Certains se demandent si les gens n’ont jamais entendu parler des codes de correction d’erreurs

  • Les trames TCP ou Ethernet contiennent des octets de FEC
  • HTTP over TLS utilise des trames de données chiffrées, et en cas de perte de données, elles deviennent irrécupérables
  • Une grande partie de l’Internet moderne repose sur ce paradigme

• Lorsqu’on utilise son propre matériel à l’intérieur d’un datacenter, on peut ignorer les détails de bas niveau

  • Les limites de bande passante, les limites de RPS sur les paquets et la latence restent néanmoins importantes

• Cet article n’est pas un texte abouti, et le titre de soumission sur HN peut induire en erreur

• Cela rappelle un problème qu’on essayait de résoudre chez VKontakte

  • En envoyant un message dans le métro, il arrivait au serveur mais le signal coupait avant l’arrivée de la réponse
  • Le client interprétait cela comme un échec d’envoi et réessayait
  • Le problème a été résolu à l’aide d’un « random ID » généré côté client
  • Telegram envoie toutes les réponses non confirmées pendant la connexion précédente lorsque le client se reconnecte au serveur

• Beaucoup de gens ne comprennent pas que TCP n’est pas un appel de fonction

  • Récemment, un nouveau limiteur de débit TCP est sorti dans un état vraiment très mauvais
  • La plupart des conteneurs souffrent probablement de problèmes de Bufferbloat