technology

Sourcehut evitará o Go Module Mirror do Google por causa da ganância • Strong The One

.

Sourcehut, um serviço de hospedagem de código semelhante ao GitHub, GitLab, Gitea e similares, planeja começar a bloquear o Go Module Mirror, um proxy que busca e armazena em cache o código dos servidores git, porque está usando muita largura de banda da rede.

A partir de 24 de fevereiro, os desenvolvedores que executam go get ou um comando semelhante em pacotes Go, para importar módulos dos repositórios SourceHut, verão uma mensagem de erro. Para resolvê-lo, eles terão que usar uma solução alternativa para buscar o código desejado.

Em um postagem no blog na segunda-feira, Drew DeVault, fundador da Sourcehut, explicou que esta decisão decorre do comportamento do Go Module Mirror do Google, que ele descreveu no ano passado como um ataque distribuído de negação de serviço na tentativa de convencer a equipe Go do Google a alterar o comportamento de seus sistemas.

O proxy do módulo Go, de acordo com DeVault, não apenas lida com as solicitações do usuário por meio do comando go get, mas também, por conta própria, clona repositórios git em sua totalidade de vários servidores que não coordenam suas solicitações.

O Go Module Mirror pode fazer essas solicitações até 2.500 vezes por hora, geralmente em conjunto com até uma dúzia de operações de clone. Estes, DeVault, diz que são altamente redundantes e podem resultar em um único repositório git sendo buscado mais de 100 vezes por hora.

Isso representa aproximadamente 70% do tráfego de saída da Sourcehut, com um único módulo produzindo até 4 GiB de tráfego diário do Google.

“O custo de suportar esse tráfego não é mais aceitável para nós, e a equipe Go não fez nenhuma tentativa de corrigir o problema durante esse período”, escreveu DeVault. “Queremos evitar causar transtornos aos usuários do Go, mas a carga e o custo são muito altos para continuarmos justificando o suporte a esse recurso.”

DeVault aberto um problema do GitHub para convencer os engenheiros Go do Google a lidar com o problema em 24 de fevereiro de 2021, mas após dois anos de idas e vindas, as mitigações implementadas tiveram apenas um impacto mínimo.

Outros mantenedores do módulo Go também reclamaram sobre o consumo descuidado de recursos de computação do Go Module Mirror.

“Ontem, o Go Module Mirror baixou 4 gigabytes de dados do meu servidor solicitando um único módulo mais de 500 vezes (log anexado)”, escreveu o desenvolvedor Ben Lubar em uma postagem de 30 de maio de 2021. “Até onde eu sei, sou a única pessoa no mundo usando este módulo Go. Eu apreciaria muito algum cache ou pelo menos limitação de taxa.”

Russ Cox, líder de tecnologia de linguagem de programação Go no Google, respondeu para uma discussão sobre o problema no Hacker News, observando que a equipe Go tem feito progressos em seus esforços para resolver o problema.

O Go 1.19, disse ele, inclui uma maneira de baixar módulos com um sinalizador -reuse que faz com que as operações de atualização usem menos largura de banda, evitando dados inalterados. Cox disse que o serviço proxy.golang.org ainda não foi revisado para suportar essa mudança de idioma, mas está na lista de trabalhos planejados para este ano.

“Por um lado, Sourcehut afirma que isso é um grande problema para eles, mas, por outro lado, Sourcehut também nos disse que eles não quer que coloquemos em um caso especial para desativar as atualizações em segundo plano“, disse Cox, citando a insistência de DeVault de que o Google corrigisse sua “solução errada” e que Sourcehut não deveria receber tratamento especial. qualquer outra pessoa que esteja incomodada com a carga atual.”

Esta não é a primeira vez que o código do Google é acusado de desperdiçar a largura de banda de outras pessoas. Em agosto de 2020, APNIC, o Registro Regional da Internet para a região da Ásia-Pacífico, reclamou que a decisão da equipe do Chromium em 2008 de combinar a caixa de entrada de palavras-chave de pesquisa do navegador do Google com sua caixa de entrada de URL como uma única omnibox levou a uma enorme quantidade de tráfego de DNS.

Os dados extras foram o resultado do código do navegador projetado para distinguir entre termos de pesquisa e URLs, verificando se os provedores de serviços de rede estavam envolvidos no sequestro do NXDomain, capturando erros – erros de digitação ou consultas para domínios inexistentes – e monetizando-os retornando respostas vinculadas a seus próprios serviços.

Na época, cerca de metade do tráfego do servidor raiz do DNS – 60 bilhões de consultas ao sistema do servidor raiz por dia – era atribuída ao esforço do Chromium para separar as consultas dos URLs. Google domesticou suas sondagens de desambiguação de URL de consulta em fevereiro de 2021. ®

.

Mostrar mais

Artigos relacionados

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Botão Voltar ao topo