Table des matières de l'article :
Ces derniers mois, lors de l'optimisation des performances web pour les clients Managed Server SRL , nous avons constaté un comportement inhabituel qui nous a d'abord intrigués. Nous utilisons HTTP/3 avec le protocole QUIC et la compression ZSTD (Zstandard) depuis plus de deux ans, avec d'excellents résultats en termes de vitesse de connexion, d'efficacité et de stabilité. Pendant toute cette période, les implémentations ont toujours fonctionné parfaitement : les navigateurs négociaient correctement HTTP/3, la compression ZSTD était activée pour HTML, CSS et JavaScript, et les performances du site étaient conformes à nos attentes.
Mais soudain, quelque chose a changé. Lors de tests de routine, nous avons constaté que les connexions qui fonctionnaient correctement auparavant via HTTP/3 basculaient désormais presque systématiquement vers HTTP/2 , tandis que les ressources textuelles configurées pour être compressées dans ZSTD étaient soudainement servies avec Brotli , voire gzip . C'était comme si, du jour au lendemain, nos optimisations avaient disparu.
Cette situation était à la fois inhabituelle et frustrante. Étant donné que notre pile était configurée de manière stable et fonctionnelle depuis des années, il était incompréhensible qu'elle se comporte soudainement différemment. Cela a conduit à une enquête technique approfondie pour comprendre ce qui se passait.
L'enquête initiale : soupçons concernant NGINX
La première étape était la plus logique pour ceux qui travaillent dans l'infrastructure et les performances web : vérifier le comportement de notre serveur web NGINX . Il était évident qu'une mise à jour récente ou une modification des options de compilation avait pu altérer la façon dont le serveur gérait QUIC et ZSTD. Nous avons donc analysé les configurations en détail, vérifié les modules chargés et même revérifié la compatibilité des versions utilisées.
Pour dissiper tout doute, nous avons également créé un environnement de test entièrement propre, en installant NGINX de A à Z avec les paramètres minimaux nécessaires, sans aucune personnalisation. L'idée était simple : éliminer toute interférence externe possible et observer le comportement du protocole et de la compression dans un contexte isolé.
Le résultat fut pourtant surprenant. Même avec une installation propre et minimale, HTTP/3 n'était pas négocié et ZSTD n'était toujours pas utilisé . À ce stade, il était clair que le problème n'était lié ni à NGINX, ni à la configuration de notre serveur.
Le faux-fuyant : problèmes de réseau et de MTU
Après avoir écarté l'hypothèse que notre serveur web soit en cause, nous avons cherché d'autres pistes. Le protocole HTTP/3 reposant sur QUIC , qui utilise UDP au lieu de TCP , nous avons supposé que le problème pouvait être lié à un paramètre réseau. Nous avons notamment soupçonné que l' unité de transmission maximale (MTU) pouvait influencer la négociation du protocole.
Nous avons testé plusieurs configurations : d'abord la valeur par défaut de 1500 1400 octets, puis des paramètres plus conservateurs, comme 1300 2, voire XNUMX XNUMX octets, pour voir si des paquets plus petits faciliteraient la transition vers QUIC. Cependant, même dans ce cas, les résultats sont restés inchangés : la connexion continuait de revenir à HTTP/XNUMX et la compression restait bloquée sur Brotli ou gzip.
Il était clair que le problème ne venait ni de notre pile ni du réseau. Mais le plus étrange était qu'en comparant les journaux historiques, nous avons découvert que les négociations fonctionnaient parfaitement jusqu'à quelques semaines plus tôt. À partir de ce moment, nous avons commencé à soupçonner qu'un facteur extérieur à notre infrastructure influençait le comportement de la connexion.
La découverte : même les plus grands ont le même problème
Pour déterminer si le phénomène était limité à nos serveurs ou s'il avait une portée plus large, nous avons décidé de réaliser des tests sur les sites web de grandes entreprises internationales . Nous avons analysé le comportement de géants comme Amazon, Google, Microsoft , et même de grands journaux. La découverte fut surprenante : même sur ces plateformes, les connexions n'étaient quasiment jamais négociées en HTTP/3 et le protocole ZSTD n'était pas utilisé.
Cela nous a permis d'écarter définitivement le problème côté serveur. Si de grandes entreprises dotées d'infrastructures de plusieurs millions de dollars, d'équipes d'ingénieurs dédiées et de processus d'optimisation avancés étaient incapables de gérer correctement HTTP/3 et ZSTD, il était clair que la cause se situait côté client.
L'idée décisive : le soupçon sur l'antivirus
Lorsqu'on élimine tout ce qui est sous notre contrôle, on commence à s'intéresser aux éléments que l'on tient généralement pour acquis. Dans ce cas précis, l'attention s'est portée sur les logiciels installés localement. Nous savions que l'antivirus ESET NOD32 était présent sur les systèmes de test.
Pour analyser le trafic HTTPS, les antivirus modernes utilisent une stratégie méconnue de nombreux utilisateurs : ils configurent un proxy local qui intercepte toutes les connexions du navigateur, analyse leur contenu, puis les transmet au serveur distant. Autrement dit, le navigateur ne communique jamais directement avec le site, mais avec un intermédiaire capable de modifier, filtrer ou réinterpréter la connexion.
Si ce proxy ne prend pas en charge les dernières versions des protocoles ou des algorithmes de compression, le navigateur est contraint de recourir automatiquement à des technologies plus anciennes, mais compatibles. C'est pourquoi les connexions ont soudainement basculé vers HTTP/2 et que la compression est revenue à Brotli ou gzip : le problème ne venait pas du serveur, mais d'une interférence côté client.
Confirmation : désinstallez votre antivirus
Pour confirmer cette hypothèse, nous avons décidé de mener une expérience radicale. Nous avons désinstallé ESET NOD32 Antivirus des systèmes de test, redémarré les machines et répété les tests. Les résultats ont été immédiats : les navigateurs ont recommencé à négocier correctement HTTP/3/QUIC et la compression ZSTD a retrouvé son fonctionnement normal.
Après des semaines de tests, d'exclusions et de vérifications, nous avons finalement trouvé la cause. L'antivirus, avec son proxy local, interférait avec la négociation des connexions et empêchait les optimisations que nous avions mises en œuvre depuis longtemps.
Pourquoi cela se produit et pourquoi cela ne concerne pas seulement ESET
Ce que nous avons découvert n'était pas un bug isolé, mais une conséquence directe du fonctionnement des antivirus modernes pour Windows. Nombre d'entre eux, et pas seulement ESET, utilisent la même stratégie d'interception via un proxy HTTPS local. Cela signifie que des logiciels comme Avast, Kaspersky, Bitdefender, McAfee et bien d'autres peuvent provoquer exactement le même comportement.
Lorsqu'un antivirus s'interpose entre le navigateur et le réseau, il prend le contrôle de la connexion et en gère partiellement les fonctionnalités. Si le proxy n'est pas à jour pour prendre en charge les protocoles modernes comme HTTP/3 ou une compression plus performante comme ZSTD , le navigateur est contraint d'utiliser des protocoles obsolètes. Il en résulte des performances dégradées, des temps de chargement plus longs et, dans notre cas, l'inefficacité des optimisations conçues pour nos clients.
Conclusions
Cette expérience nous a appris une leçon importante. Face aux problèmes de connexion HTTP/3 et à la compression ZSTD inactive , notre première réaction a été de penser que le problème venait de nous : une mauvaise configuration, une mise à jour non testée, un paramètre incorrect. La réalité était pourtant tout autre.
Notre configuration était correcte et fonctionnait parfaitement depuis des années. La véritable cause était un logiciel externe qui, sans que nous nous en apercevions, modifiait le comportement du navigateur. Dans notre cas précis, il s'agissait d'ESET NOD32 , mais ce même problème peut se produire avec de nombreux autres antivirus.
La prochaine fois que vous devrez déboguer des fonctionnalités comme HTTP/3 , QUIC ou ZSTD , avant de remettre en question les serveurs, les CDN, les proxys et les configurations, demandez-vous si un antivirus n'interfère pas avec la négociation du protocole. Parfois, la solution est bien plus simple qu'il n'y paraît : identifier le véritable coupable peut vous éviter des heures d'analyse inutiles.
mbri : il suffit d'identifier le véritable coupable pour économiser des heures d'analyse inutile.
