4 pontos por GN⁺ 2024-01-17 | 1 comentários | Compartilhar no WhatsApp
  • Um proxy TCP escrito em Go que permite simular vários tipos de latência de rede variável

Exemplo básico de uso

  • Cria uma nova instância escutando na porta 2000 para fazer proxy do tráfego TCP para localhost:80, com latência base de 100ms, amplitude de onda senoidal de 100ms (latência adicional máxima de 200ms, mínima de 0) e período de 1 minuto:
    speedbump --latency=100ms --sine-amplitude=100ms --sine-period=1m --port=2000 localhost:80  
    
  • Ou, ao executar o speedbump usando a imagem de contêiner kffl/speedbump:
    docker run --net=host kffl/speedbump:latest --latency=100ms --sine-amplitude=100ms \  
      --sine-period=1m --port=2000 localhost:80  
    
  • Cria uma nova instância com latência base de 300ms e latência em onda dente de serra com amplitude de 200ms e período de 2 minutos, como mostrado no gráfico abaixo:
    speedbump --latency=300ms --saw-amplitude=200ms --saw-period=2m --port=2000 localhost:80  
    
  • É possível executar simultaneamente a soma de várias latências.
  • O Speedbump pode ser usado como biblioteca Go por meio do pacote lib.

Opinião do GN⁺:

  • O Speedbump é uma ferramenta útil para simular latência de rede e pode ajudar a testar e otimizar o desempenho de aplicações baseadas em rede.
  • Como foi escrito em Go, é familiar para desenvolvedores Go e oferece recursos para simular facilmente vários padrões de latência.
  • É open source e segue a licença Apache 2.0, então pode continuar sendo aprimorado por meio de contribuições da comunidade.

1 comentários

 
GN⁺ 2024-01-17
Comentários do Hacker News
  • Ao testar implementações de ActivityPub em diferentes tamanhos e condições de rede, pesquisei trabalhos semelhantes. Aprendi a usar o comando tc para adicionar latência a uma interface específica, e isso também funciona bem em contêineres Docker. Ele talvez já esteja instalado em muitos sistemas.
    • Exemplo de comando: tc qdisc add dev eth0 root netem delay 100ms
  • Na Netflix, foi desenvolvida uma ferramenta chamada "latency monkey". Detectar quando serviços downstream ficam lentos é muito mais difícil do que detectar quando um serviço está indisponível. Essa ferramenta descarta pacotes em uma determinada proporção para induzir retransmissões, o que faz com que os pacotes sofram atraso ou cheguem fora de ordem. Muitos problemas foram encontrados no código de tratamento de erros para acesso à rede.
  • Todo engenheiro de software que trabalha com aplicações de internet deveria usar ferramentas como essa no dia a dia. QUIC e TCP são ambos necessários, e ela deveria conseguir capturar todo o UDP, incluindo DNS. Tenho certeza de que, se os desenvolvedores não estivessem usando ambientes de computação de alto desempenho, 90% dos webapps desapareceriam.
  • Muitos aplicativos têm desempenho ruim em condições de conectividade intermitente. Os desenvolvedores de apps podem ajudar os outros testando conectividade intermitente simulada. Muitos apps não têm um recurso de "caixa de saída", como clientes de e-mail. Há uma pergunta sobre quem poderia desenvolver um toxiproxy de referência, um "mutador de casos de teste", para simular problemas comuns de conexão em situações de ajuda humanitária em desastres.
  • No Mac, é possível fazer algo parecido usando ferramentas nativas. Foi fornecido um exemplo de comando para simular a velocidade de uma conexão de rede.
  • Ao tentar simular uma rede lenta no Mac, foi encontrado o Network Link Conditioner. Ele pode ser usado sem configuração de proxy ou outras configurações e precisa ser instalado a partir das ferramentas adicionais do Xcode.
  • Faz muito tempo que não estou ativo, mas o nome "comcast" já diz muita coisa.
  • Uma ferramenta semelhante usada no Windows é o "clumsy".
  • No FreeBSD também existe um recurso chamado "dummynet", que permite injetar latência, limitação de largura de banda, tamanho de fila e perda de pacotes como parte do ipfw. É a mesma funcionalidade do macOS.
  • Nunca vou esquecer que, no meu primeiro emprego, meu gerente configurou o firewall FreeBSD IPFW para deixar as respostas ICMP lentas. Sempre que alguém enviava um ping, o tempo de resposta parecia o mais alto possível. Meu gerente era um brincalhão.