Sourcehut, un service d’hébergement de code similaire à GitHub, GitLab, Gitea, etc., prévoit de commencer à bloquer le Go Module Mirror, un proxy qui récupère et met en cache le code des serveurs git, car il utilise trop de bande passante réseau.

À partir du 24 février, les développeurs exécutant go get ou une commande similaire sur les paquets Go, afin d’importer des modules à partir de référentiels SourceHut, verront un message d’erreur. Pour le résoudre, ils devront utiliser une solution de contournement pour récupérer le code souhaité.

Dans un Article de blog Lundi, Drew DeVault, fondateur de Sourcehut, a expliqué que cette décision découle du comportement du Go Module Mirror de Google, qu’il a décrit l’année dernière comme Une attaque par déni de service distribué dans une tentative de convaincre l’équipe Go de Google de modifier le comportement de ses systèmes.

Le proxy du module Go, selon DeVault, gère non seulement les demandes des utilisateurs via la commande go get, mais aussi, à lui seul, clone les dépôts git dans leur intégralité à partir de plusieurs serveurs qui ne coordonnent pas leurs demandes.

Le Go Module Mirror peut effectuer ces requêtes jusqu’à 2 500 fois par heure, souvent en conjonction avec jusqu’à une douzaine d’opérations de clonage. Selon DeVault, ceux-ci sont hautement redondants et peuvent entraîner la récupération d’un seul dépôt git plus de 100 fois par heure.

Cela représente environ 70% du trafic sortant de Sourcehut, avec un seul module produisant jusqu’à 4 Gio de trafic quotidien de Google.

« Le coût de la prise en charge de ce trafic n’est plus acceptable pour nous, et l’équipe Go n’a fait aucune tentative pour corriger le problème pendant cette période », a écrit DeVault. « Nous voulons éviter de causer des inconvénients aux utilisateurs de Go, mais la charge et le coût sont trop élevés pour que nous puissions continuer à justifier la prise en charge de cette fonctionnalité. »

DeVault ouvert un problème GitHub pour convaincre les ingénieurs de Go de Google de régler le problème le 24 février 2021, mais après deux ans de va-et-vient, les mesures d’atténuation mises en place n’ont eu qu’un impact minime.

D’autres mainteneurs de modules Go se sont également plaints de la consommation insouciante de ressources informatiques du Go Module Mirror.

« Hier, Go Module Mirror a téléchargé 4 gigaoctets de données de mon serveur demandant un seul module plus de 500 fois (journal joint) », a écrit le développeur Ben Lubar dans un article du 30 mai 2021. « Pour autant que je sache, je suis la seule personne au monde à utiliser ce module Go. J’apprécierais grandement un peu de mise en cache ou au moins de limitation de débit.

Russ Cox, responsable technique du langage de programmation Go chez Google, Répondu à une discussion sur la question sur Hacker News en notant que l’équipe Go a fait des progrès dans ses efforts pour résoudre le problème.

Go 1.19, a-t-il dit, inclut un moyen de télécharger des modules avec un indicateur -reuse qui permet aux opérations d’actualisation d’utiliser moins de bande passante en évitant les données inchangées. Cox a déclaré que proxy.golang.org service n’a pas encore été révisé pour prendre en charge ce changement de langue, mais qu’il figure sur la liste des travaux prévus pour cette année.

« D’une part, Sourcehut affirme que c’est un gros problème pour eux, mais d’autre part, Sourcehut nous a également dit qu’ils Je ne veux pas que nous mettions dans un cas spécial pour désactiver les actualisations en arrière-plan», a déclaré Cox, citant l’insistance de DeVault pour que Google corrige sa « mauvaise solution » et que Sourcehut ne devrait pas bénéficier d’un traitement spécial. « L’offre de désactiver les actualisations en arrière-plan jusqu’à ce qu’un correctif plus complet puisse être déployé est toujours valable, à la fois pour Sourcehut et pour toute autre personne gênée par la charge actuelle. »

Ce n’est pas la première fois que le code de Google est accusé de gaspiller la bande passante des autres. En août 2020, APNIC, le registre Internet régional pour la région Asie-Pacifique, Plaint que la décision de l’équipe Chromium en 2008 de combiner la zone de saisie des mots-clés de recherche du navigateur de Google avec sa boîte de saisie d’URL en une seule omnibox a conduit à une énorme quantité de trafic DNS.

Les données supplémentaires étaient le résultat d’un code de navigateur conçu pour distinguer les termes de recherche et les URL en vérifiant si les fournisseurs de services réseau étaient engagés dans le détournement de NXDomain, en capturant les erreurs – fautes de frappe ou requêtes pour des domaines inexistants – et en les monétisant en renvoyant des réponses liées à leurs propres services.

À l’époque, environ la moitié du trafic du serveur racine DNS – 60 milliards de requêtes par jour vers le système du serveur racine – était attribuée aux efforts de Chromium pour séparer les requêtes des URL. Google (en anglais) apprivoisé ses sondes de désambiguïsation d’URL de requête en février 2021. ®