Le problème par les faits

Une modification de la gestion de la fenêtre TCP introduite dans le noyau 2.6.7 (eh oui ! le 2.6.7 posait déjà problème) a pour effet de bord de mettre en évidence un défaut de certains routeurs et pare-feux. Ce bug (qui, à proprement parler, ne ressortit pas au noyau lui-même mais à des tierces parties) se manifeste par l’impossibilité de contacter les sites Web (mais aussi bien tout autre type de serveur causant TCP) situés en amont de ces éléments défectueux.

Le problème par les causes

Comme chacun sait, la fenêtre TCP n’est rien d’autre qu’un tampon permettant d’accumuler les paquets entrants dans la pile, ce qui dispense d’avoir à les acquitter à la queue leu leu auprès de l’expéditeur avant de recevoir le suivant.

Ainsi, par exemple, au lieu d’attendre que le paquet n° 10 soit acquitté par le récepteur avant d’envoyer le paquet n° 11, puis le n° 12, et ainsi de suite, l’émetteur connaissant la taille de la fenêtre du récepteur sait que ce dernier dispose d’un tampon de 65635 octets (le maximum hors extension) autorisant l’envoi de 43 (65635 / 1500) paquets avant saturation. Ce procédé permet d’accroître sensiblement la vitesse de transmission. L’idée est d’envoyer une rafale de paquets sans attendre l’acquittement de chaque paquet : si le récepteur accuse réception du paquet n° 1024 (en pratique, cela revient à réclamer le n° 1025), eh bien on considère qu’il acquitte du même coup les 1023 précédents !

La taille de cette fenêtre est codée sur 16 bits dans l’en-tête d’un paquet TCP, ce qui autorise un maximum de 64Ko. Sachant qu’un paquet standard a une longueur totale de 1500 octets, ça ne fait finalement pas beaucoup sur une liaison rapide (on est alors très en dessous de la seconde). C’est pourquoi la RFC 1323 – comme par hasard co-rédigée par quelqu’un de chez Cray) a introduit, entre autres extensions destinées à améliorer les performances du protocole TCP, une option permettant d’accroître la taille de la fenêtre par une astuce consistant à ajouter un coefficient multiplicateur. Ainsi, malgré le fait que la « case » destinée à indiquer la taille de la fenêtre reste codée sur 16 bits, cet artifice permet de faire « comme si » elle en contenait 32 – soit une capacité sensiblement plus importante. Chose, encore une fois, particulièrement souhaitable sur des liaisons à large bande passante, mais plus encore à forte latence (satellites géostationnaires).

Si aucune des deux parties ne gère cette extension, tout va bien. La taille de la fenêtre passée dans l’en-tête des premiers paquets échangés n’a pas a être interprêtée autrement que littéralement. Idem si l’une seulement des deux parties est capable de la gérer : puisqu’il s’agit de préserver la compatibilité, les deux s’en passent. D’ailleurs, il suffit que le premier paquet (SYN) ne comporte pas l’option, pour que le partenaire soit dans l’obligation d’y renoncer aussi.

Même ainsi, la taille des fenêtres peut différer de chaque côté : la fenêtre maximale du client est indiquée dans le premier paquet (SYN), tandis que celle du serveur est indiquée dans le paquet d’acquittement (SYN+ACK) correspondant. (Contrairement à ce qui se passe en UDP, on ne commence pas à envoyer les paquets en rafale avant d’avoir complété une première séquence d’acquittement en bonne et due forme.) Enfin le client accuse à son tour réception de la taille de fenêtre annoncée par le serveur (ACK), avant que ne puisse effectivement débuter la session TCP.

C’est seulement lorsque l’une des parties se méprend sur les intentions de l’autre que les choses se gâtent. Cela se produit si, par exemple, un pare-feu situé entre le client et le serveur remet à zéro la valeur d’échelle de la fenêtre TCP des paquets SYN et SYN+ACK qui passent entre ses pattes (de goret ;o) sans pour autant désactiver l’option (tcp window scaling). Entre-nous, c’est une curieuse manière de faire, car l’option tient sur trois octets contigüs : le premier indique le type d’option (type 3), le second la longueur requise (3 octets), et enfin le troisième contient le coefficient. Pourquoi tripoter seulement le dernier octet, ce qui revient à indiquer qu’on gère l’option sans pour autant souhaiter en bénéficier (troisième octet remis à zéro) ? Tss... tss… ça sent la parano obtuse – ou à tout le moins la configuration mal maîtrisée. On peut imaginer plusieurs jeux de règles de pare-feu produisant involontairement ce facheux résultat. En particulier si ce dernier se mêle de recréer de toute pièce les premiers paquets d’une session TCP sans être d’accord sur la taille de fenêtre acceptable avec le serveur qu’il protège dans la DMZ. (Tip : chercher les paquets susceptibles de passer sans générer d’état).

À priori, on pourrait considérer le fait que l’une des parties infère faussement que l’autre renonce au coefficient multiplicateur comme gênant mais pas rédhibitoire pour la connexion. Cela devrait seulement réduire la taille de fenêtre possible et ralentir (plus ou moins significativement, selon la bande passante) la communication.

Pourtant, en pratique, cela se passera mal la plupart du temps. Certes le serveur proprement dit gère l’option, mais comme son pare-feu lui présente un paquet dont le coefficient multiplicateur de taille de fenêtre est toujours à zéro, il prend pour argent comptant la taille de la fenêtre et ne l’ajuste pas en conséquence. Ainsi, si le client souhaite (et croit) annoncer une fenêtre de 128Ko (soit le double de ce qu’elle pourrait être si l’extension était désactivée – ce qui n’est déjà pas mal en terme d’occupation mémoire), il place la valeur 1024 dans le champ réservé à la taille de fenêtre, et 7 dans celui réservé au multiplicateur. Le calcul de la valeur réelle s’effectue par une rotation de bits sur la gauche : sept rotations égalent 128, ce qui devrait donner 1024 * 128 = 128Ko. Las ! le serveur ne voit pas le coefficient 7 mais zéro. Il considère par conséquent que la taille de fenêtre du client est de 1024 octets seulement, soit moins qu’un paquet (1500) et n’envoie donc rien du tout. (En réalité, chaque paquet placé dans la pile compte moins de 1500 octets puisque la partie IP a déjà été déjà décapsulée : pour ceux qui suivent, c’est bien de l’avoir noté, mais cela représente une très faible différence dans le calcul).

Et voilà, Madame, pourquoi votre fille est muette.

On voit que la valeur 7 retenue en pratique depuis le noyau 2.6.7 est critique. Tant que le noyau adoptait une valeur inférieure, cela se passait bien dans l’immense majorité des cas, puisqu’il y avait très peu de chances que la valeur de la fenêtre (même faussement divisée du fait que l’autre partie ne « voyait » pas le coefficient) soit inférieure à l’équivalent d’au moins un paquet. Avec une valeur de coefficient égale à 2, cela revient à diviser à tort la taille de la fenêtre par quatre. Avec une valeur de coefficient égale à 7 par défaut, cela revient cette fois à la diviser par 128. Dès lors, il y a beaucoup plus de chance que le résultat soit interprêté comme inférieur à la taille d’un seul paquet !

Le bug pré-existait (sur certains routeurs ou pare-feux), il faisait déjà problème, mais les dégats étaient limités à un ralentissement plus ou moins perceptible. C’est le coup de force qui a consisté à passer le « TCP win scale » à 7 par défaut (valeur sans doute intéressante pour les liaisons à large bande passante mais peut-être pas pour l’ADSL) qui a servi de révélateur en cassant complètement certaines connexions déjà foireuses.

Solutions possibles

Méthode individuelle et bûcheronne (peut-être sans douleur si l’on ne dispose que d’une liaison DSL et pas d’un réseau local à 100Mb), désactiver complètement le tcp window scaling.

Il est possible de rendre cela permanent en éditant le fichier /etc/sysctl.conf qui devrait se trouver dans toute distribution raisonnable.

L’option à pour effet d’annoncer aux serveurs contactés que l’on ne supporte pas l’option et doit marcher dans la plupart des cas car, du même coup, on invite le noyau à annoncer une taille de fenêtre jamais inférieure à un certain nombre de paquets.

Il est évidemment hors de question de coder cette valeur en dur dans le noyau, cela reviendrait à tirer un trait sur une fonctionnalité qui date de plusieurs années (la RFC 1323 a été publiée en mai 1992 !) Néanmoins, de nombreux utilisateurs se plaignent de ne pouvoir accéder à certains sites.

Conscient du problème, Stephane Hemminger, contributeur régulier de la liste linux-netdev a proposé une première rustine le 6 juillet dernier. Bien qu’il ait pris la précaution d’annoncer que son patch ne visait qu’à « prendre en compte la corruption du monde », celui-ci a été tout d’abord refusé par David S. Miller, le respsonsable de la partie réseau du noyau. L’argument était le suivant : si le patch est adopté, alors le bug ne sera plus apparent mais continuera d’exister (comme avant). Il est finalement préférable qu’il apparaisse en plein jour, afin de contraindre à le traiter.

Le noyau 2.6.8 (puis rapidement le 2.6.8.1, son quasi-clone à un bug NFS près) fut donc publié sans la correction, bien que le problème ait été déjà largement repéré lors de sa phase de mise au point. Évidemment, les plaintes des utilisateurs se sont multipliées, et cela a généralement contribué à mettre le bug « des autres » en évidence ;o) Aussi, surfant peut-être un peu sur l’expression de ces plaintes au sein même de la liste linux-netdev, Stephane Hemminger est revenu à la charge le 26 août (soit moins de deux mois plus tard) avec un nouveau patch destiné cette fois au noyau 2.6.9, en argumentant toujours sur la nécessité de survivre dans un monde imparfait, mais en mettant surtout en avant une nouvelle méthode de calcul de la taille de fenêtre par défaut (laquelle, certes, prend sournoisement en compte le cas des routeurs/pare-feux indélicats) et qui dispense de coder le modificateur (la fameuse valeur 7) en dur dans le noyau. « Je capitule ! » a enfin lâché le mainteneur de la partie réseau du noyau. C’est ainsi que le 2.6.9 « corrige » le problème. Et tant pis pour les distributions qui sont « sorties » avec le 2.6.8.

Tout est bien qui finit bien ? Certainement pas ! On imagine que le problème ressurgira tôt ou tard de manière cruciale, puisqu’il n’est pas vraiment résolu mais seulement contourné. Dans l’intervalle, la « boîte noire » de la gestion de la fenêtre TCP peut être refermée pour la plupart des utilisateurs – tant que son imperfection (résultat d’un compromis entre ce qui serait théoriquement souhaitable et le monde réel) ne se rappelle pas au bon souvenir des humains...

Moralité : comme on s’en serait douté, dans le bazar il ne suffit pas d’être un programmeur avisé pour voir une proposition de modification du noyau adoptée ; encore faut-il faire montre de rhétorique (diplomatie ?) Ensuite, ce n’est pas seulement dans les commentaires qu’on peut repérer la rhétorique dans le code source, mais bien déjà dans le code lui-même. La technique n’est ni « neutre », ni « pure » et, comme en politique, tout un chacun à son avis à donner, même s’il n’y est pas dûment autorisé par un diplôme ou je ne sais quelle « compétence ». Dans le logiciel libre, celà peut se lire « à code source ouvert ».