Table des matières de l'article :
Au cours des derniers mois, lors de nos activités de optimisation des performances Web sur les projets clients Serveur géré SRL, nous avons constaté un comportement étrange qui nous a d'abord laissés perplexes. Nous utilisons HTTP/3 avec protocole QUIC et la compression ZSTD (Zstandard) Depuis plus de deux ans, nous avons obtenu d'excellents résultats en termes de vitesse, d'efficacité et de stabilité de connexion. Durant toute cette période, les implémentations ont toujours fonctionné parfaitement : les navigateurs ont correctement négocié HTTP/3, la compression ZSTD était activée pour HTML, CSS et JavaScript, et les performances du site étaient conformes aux attentes.
Mais soudain, quelque chose a changé. Lors de tests de routine, nous avons constaté que des connexions qui, jusqu'à récemment, étaient gérées correctement via HTTP / 3 maintenant ils se rabattaient presque toujours sur HTTP / 2, tandis que les ressources textuelles que nous avions configurées pour être compressées dans ZSTD ont été soudainement servis avec Brotli ou même gzipC’était comme si, du jour au lendemain, nos optimisations n’existaient plus.
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 naturelle pour ceux qui s'occupent d'infrastructure et de performance Web : vérifier le comportement de notre Serveur Web NGINXLa logique nous a dit qu'une mise à jour récente ou un changement dans le drapeau de compilation Cela aurait pu modifier la façon dont le serveur gérait QUIC et ZSTD. Nous avons analysé les configurations en détail, vérifié les modules chargés et même vé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 cependant surprenant. Même avec une installation propre et minimaliste, HTTP/3 n'a pas été négocié e Le ZSTD n'a toujours pas été utiliséÀ ce stade, il était clair que le problème n'était pas lié à NGINX, ni à nos configurations de serveur.
Le faux-fuyant : problèmes de réseau et de MTU
Après avoir exclu la possibilité que notre serveur web soit en cause, nous avons commencé à chercher ailleurs. HTTP / 3 Il est basé sur le protocole QUIC, qui utilise UDP plutôt que TCPNous avons émis l'hypothèse que le problème pourrait être lié à un paramètre réseau. Plus précisément, nous soupçonnions queMTU (unité de transmission maximale) pourrait 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 comprendre si le phénomène était limité à nos serveurs ou avait une portée plus large, nous avons décidé d'effectuer quelques tests sur sites Web de grandes entreprises internationalesNous avons analysé le comportement de géants tels que Amazon, Google, Microsoft et même certains grands journaux. La découverte fut surprenante : même sur ces plateformes, les connexions n'ont presque jamais été négociés en HTTP/3 e ZSTD n'a pas été utilisé.
Cela nous a permis d'écarter définitivement le problème côté serveur. Si les grandes entreprises dotées d'infrastructures de plusieurs millions de dollars, d'équipes d'ingénierie 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 devait être recherchée ailleurs. côté client.
L'idée décisive : le soupçon sur l'antivirus
En excluant tout ce qui est sous votre contrôle, vous commencez à vous intéresser aux composants que vous considérez habituellement comme acquis. Dans ce cas, l'accent a été mis sur les logiciels installés localement. Nous savions que sur les systèmes de test, ESET Antivirus NOD32.
Les antivirus modernes, pour analyser le trafic HTTPS, adoptent une stratégie que de nombreux utilisateurs ne connaissent pas : ils établissent un proxy local Ce système intercepte toutes les connexions du navigateur, analyse leur contenu et les transmet ensuite 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 algorithmes de compression, le navigateur est obligé d'effectuer une repli automatique sur des technologies plus anciennes et plus compatibles. C'est pourquoi les connexions ont soudainement été interrompues HTTP / 2 et les compressions sont revenues à l'usage Brotli ou gzip:Ce n'était pas la faute du serveur, mais plutôt une interférence côté client.
Confirmation : désinstallez votre antivirus
Pour confirmer l'hypothèse, nous avons décidé de mener une expérience drastique. Nous avons supprimé ESET Antivirus NOD32 Depuis les systèmes de test, j'ai redémarré la machine et répété les vérifications. Le résultat a été immédiat : les navigateurs ont recommencé à négocier. HTTP/3 / QUIC correctement et compression ZSTD il a recommencé à fonctionner exactement comme avant.
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 Windows modernes. 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 pourraient 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 gère partiellement ses fonctionnalités. Si le proxy n'est pas mis à jour pour prendre en charge les protocoles modernes tels que HTTP / 3 ou des compressions plus efficaces telles que ZSTDLe navigateur est contraint de négocier avec des protocoles hérités. Cela entraîne une baisse des performances, des temps de chargement plus longs et, dans notre cas, l'échec des optimisations conçues pour nos clients.
Conclusions
Cette expérience nous a appris une leçon importante. Face à des connexions HTTP/3 manquant et compressions ZSTD inactifLa première réaction a été de penser que le problème venait de nous : une configuration incorrecte, une mise à jour non testée, un paramètre erroné. La réalité, cependant, était tout autre.
Notre pile était correctement configurée et fonctionnait depuis des années. La véritable cause était un logiciel externe, qui agissait silencieusement, modifiant le comportement du navigateur sans que cela soit immédiatement visible. Dans notre cas précis, le coupable était ESET NOD32, mais la même dynamique peut se produire avec de nombreux autres programmes antivirus.
La prochaine fois que vous vous retrouverez à déboguer des fonctionnalités telles que HTTP / 3, QUIC o ZSTDAvant de remettre en question les serveurs, les CDN, les proxys et les configurations, demandez-vous si un antivirus interfère avec la négociation des protocoles. Parfois, la solution est bien plus simple qu'il n'y paraît : identifier le véritable coupable peut vous épargner des heures d'analyse inutiles.
mbri : il suffit d'identifier le véritable coupable pour économiser des heures d'analyse inutile.
