- Tout comme NetworkManager peut interpréter une brève instabilité de connexion comme une « absence de réseau », certains logiciels font davantage confiance à leur propre évaluation d’état qu’à la récupération TCP, ce qui peut être risqué sur les réseaux réels
- Les croyances selon lesquelles « les données envoyées arrivent », « les deux côtés finissent par se mettre d’accord sur les octets transmis » ou « un protocole applicatif comme HTTP ou SMTP peut garantir cela » se brisent dans certaines situations
- Si la connexion est rompue pendant le traitement d’un ACK, l’émetteur ne peut pas savoir si le segment a été reçu, et cette limite ne peut pas être résolue avec un simple flux TCP à deux parties, comme dans le Two Generals’ Problem
- SMTP traite également ce problème dans les RFC 1047 et RFC 2821 : au moment où la responsabilité de la livraison change de main, il existe une zone ambiguë où une défaillance de connexion peut entraîner un envoi en double ou une perte
- En considérant les réseaux étranges comme des exceptions, ou en ignorant des détails comme l’algorithme de Nagle, le contrôle de congestion ou le blocage d’ICMP, on risque de mal interpréter les pannes réelles
Le problème de conclure à l’état du réseau avant TCP
- Un utilisateur de NetworkManager avait autrefois subi une instabilité de connexion sans fil dans un environnement d’itinérance entre résidence universitaire et campus, et avait constaté qu’une légère perte de paquets suffisait à signaler à tout le système une « absence de réseau »
- À ce moment-là, le réseau pouvait très bien revenir rapidement, et la récupération TCP habituelle pouvait rester transparente pour l’application, même au prix d’une forte hausse de la latence
- Cet exemple rejoint le problème des applications ou composants système qui interprètent trop vite comme un échec une panne temporaire que TCP aurait pu gérer
Croyances courantes mais fausses à propos de TCP
- Les affirmations suivantes reviennent souvent lorsqu’on parle de TCP, mais chacune est fausse dans au moins certains cas
- TCP est fiable, donc toutes les données envoyées arrivent à l’autre extrémité
- TCP est généralement fiable
- Même si TCP ne fournit pas une fiabilité au sens complet, l’émetteur et le récepteur finissent par se mettre exactement d’accord sur les octets transmis
- Construire un protocole applicatif orienté messages comme HTTP ou SMTP au-dessus de TCP permet d’obtenir cette garantie
- Il existe une chose appelée paquet TCP
- Il n’existe pas de chose appelée paquet TCP
- Si l’on ne peut pas se connecter à un hôte distant bien connu, on 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 soucier de l’algorithme de Nagle
- Il suffit de voir TCP comme un pipe Unix bidirectionnel passant par le réseau
- Si un réseau est transparent pour TCP, il l’est aussi pour IP
- Si un réseau est transparent pour HTTP/1.1, il l’est aussi pour TCP
- Les réseaux étranges qui ne sont pas transparents pour les protocoles standard sont exceptionnels et peuvent être ignorés
- TCP est implémenté au-dessus d’IP
Pourquoi il est difficile de se mettre exactement d’accord sur les octets livrés
- Les problèmes 1 à 4 ci-dessus liés à la fiabilité de TCP se rattachent au Two Generals’ Problem
- Si la connexion est rompue alors qu’un ACK est encore en cours de traitement, l’émetteur n’a aucun moyen de confirmer si le segment correspondant a été reçu
- Cette limite ne disparaît pas en empilant des couches complexes au-dessus de TCP
- Cette garantie ne peut pas être créée au-dessus d’un unique flux TCP à deux parties ; elle nécessite une approche similaire à Paxos ou Raft, ainsi qu’au moins trois nœuds
- Le même type de problème s’applique non seulement à TCP, mais aussi à UDP et aux services à deux parties basés sur IP
La zone grise de la responsabilité de livraison révélée par SMTP
- SMTP est un service où les deux côtés doivent explicitement se préoccuper de savoir si le message a été reçu, ce qui rend ce problème bien visible
- La RFC 1047 traite ce problème du point de vue de SMTP, et la RFC 2821 stipule que les implémentations doivent suivre les conseils essentiels de la RFC 1047
- Dans l’exemple SMTP, les états suivants sont distingués
- On peut atteindre un point où les deux côtés s’accordent sur le fait que l’e-mail a été transmis du client au serveur
- On peut aussi atteindre un point où les deux côtés s’accordent sur le fait que le serveur a pris la responsabilité de livrer l’e-mail
- Mais avant cela, il faut nécessairement passer par un état ambigu où l’on ne sait pas clairement qui porte actuellement la responsabilité de livrer l’e-mail
- Si la connexion est rompue dans cet état ambigu, l’e-mail sera dupliqué ou perdu
- La spécification SMTP désigne le côté qui doit dupliquer l’e-mail, mais on ne sait pas dans quelle mesure cela a été testé dans les implémentations réelles
- L’objectif de Paxos et de Raft est moins d’atteindre l’état final lui-même que d’éviter ce type d’état ambigu
Les limites de la connaissance dans un accord à deux parties
- Un commentaire estime que, même sur un lien non fiable mais non malveillant, deux parties peuvent s’accorder sur le fait qu’un certain ensemble d’octets a été « livré et que les deux côtés le savent »
- Une discussion complémentaire précise qu’une partie peut savoir que l’ensemble convenu contient au moins les N premiers octets, mais pas que l’ensemble convenu correspond exactement aux N premiers octets
- Ainsi, même s’il peut exister un ensemble d’octets « certainement livré et connu des deux côtés », il reste ensuite une zone grise où l’émetteur et le récepteur ne peuvent pas fixer avec certitude l’état de connaissance de l’autre
- Passer à côté de cette distinction favorise les défaillances étranges dans les systèmes distribués
Les pièges des réseaux réels et des couches inférieures
- La croyance selon laquelle « les réseaux étranges qui ne sont pas transparents pour les protocoles standard peuvent être ignorés » a causé des problèmes à plusieurs reprises
- Le buffer bloat est présenté comme un exemple où des routeurs cassent les mécanismes de contrôle de congestion
- Les réseaux qui bloquent ICMP ou rejettent le trafic qu’ils ne comprennent pas peuvent également poser problème
- La croyance selon laquelle « il n’est pas nécessaire de connaître le contrôle de congestion » relève elle aussi d’une mauvaise compréhension de TCP
- Un sous-exemple est l’idée selon laquelle « si l’on n’obtient pas le débit voulu, il suffit d’ouvrir plusieurs connexions TCP »
Aucun commentaire pour le moment.