Porque diminuem as velocidades da VPN WireGuard com uma latência elevada

Introdução

Muitos utilizadores ficam surpreendidos quando se ligam, a partir de outro país, ao servidor WireGuard do seu router GL.iNet e descobrem que as velocidades da Internet são significativamente inferiores às velocidades gigabit simétricas de casa ou às velocidades igualmente rápidas do local onde estão no estrangeiro (por exemplo, num Airbnb). Normalmente, a responsabilidade pode ser do fornecedor de serviços de Internet (ISP), do lado do servidor ou do cliente. No entanto, a latência é um fator muitas vezes ignorado, apesar de ter um impacto muito real e significativo no débito, ou seja, nas velocidades de download/upload. Este artigo procura estabelecer expectativas realistas e explicar porque é que as velocidades diminuem quando existe uma latência elevada (indicada pelos resultados do ping).

O que é a latência e porque é importante?

A latência é o tempo que os dados demoram a percorrer o trajeto do seu dispositivo até ao servidor VPN e de volta. É frequentemente medida em milissegundos (ms). Por exemplo, se o seu router GL.iNet no Vietname estiver a ligar-se a um servidor VPN no Texas, o tempo de ida e volta (RTT) pode facilmente atingir 250-300 ms.

Mesmo que a sua velocidade de Internet seja tecnicamente «rápida», uma latência elevada pode limitar seriamente o desempenho real de download e upload, sobretudo ao utilizar protocolos baseados em TCP (como HTTPs, transferências de ficheiros ou a maioria das aplicações). Lembre-se de que, embora o próprio WireGuard utilize UDP, o tráfego que passa pelo túnel VPN (tráfego web, streaming, etc.) é frequentemente baseado em TCP. O WireGuard encapsula esses dados TCP em UDP e envia-os pela Internet.

O estrangulamento do TCP: o débito está ligado à latência

Esta é a fórmula fundamental que rege o desempenho do TCP:

Tamanho da janela TCP = Débito x RTT
Comecemos por algumas definições:

• Tamanho da janela TCP é a quantidade de dados que o sistema permite ter «em trânsito» (sem confirmação de receção) antes de exigir essa confirmação.
• Débito é a velocidade efetiva, ou seja, a quantidade de dados por segundo que pode enviar ou receber.
• RTT (Round-Trip Time, ou tempo de ida e volta) é o atraso entre o envio e a receção de pacotes.

Um exemplo real de um membro do subreddit da GL.iNet

Imagine que está no Vietname e se liga ao seu servidor VPN WireGuard de casa, no Texas, a funcionar num router GL.iNet Flint 2.

• Localização do servidor: Texas, Estados Unidos
  
  • Velocidades locais (fibra simétrica) 700 Mbps de download / 940 Mbps de upload
• Localização do cliente: Vietname
  
  • Velocidades locais (sem VPN): 455 Mbps de download / 634 Mbps de upload
    
  • Velocidades locais (com o cliente VPN WireGuard ativado): 47.3 Mbps de download / 12.1 Mbps de upload, ping de 288 ms

Primeiro, identifiquemos algumas limitações comuns a qualquer ligação de rede:

1. Variações no desempenho do ISP e congestionamento na sua zona: as velocidades podem variar em múltiplos de 100 Mbps
2. Desempenho do Wi-Fi: muito variável consoante o ambiente físico, as interferências de outros dispositivos sem fios, as capacidades do dispositivo cliente e a natureza intrinsecamente half-duplex do Wi-Fi (em oposição ao funcionamento full-duplex da Ethernet)
   • Para uma explicação detalhada sobre o desempenho realista do Wi-Fi, leia: https://www.wiisfi.com/ A 1.ª limitação está fora do seu controlo. A 2.ª também está, na sua maioria, fora do seu controlo, embora possa potencialmente ser eliminada através de ligações Ethernet com fios sempre que possível.

O produto largura de banda-atraso

À primeira vista, os resultados do teste de velocidade da VPN do lado do cliente podem parecer dececionantes, mas, na realidade, são bastante bons tendo em conta a latência envolvida. Eis a explicação, utilizando a fórmula anterior:
Tamanho da janela TCP = 47.3 Mbps x 0.288 segundos
　 　 　 　    = 13.6 Mb, ou ~1.7 MB

Uma janela TCP de 1.7 MB é, na verdade, bastante grande, e conseguir esse valor numa ligação com uma latência de 288 ms significa que o TCP está a funcionar razoavelmente bem. Mas como é isto possível se o campo original do tamanho da janela TCP está limitado a apenas 65,535 bytes (cerca de 64 KB)?

Escalonamento da janela TCP para melhorar o desempenho

A resposta está numa funcionalidade chamada escalonamento da janela TCP (TCP Window Scaling), introduzida para suportar redes modernas com elevada largura de banda e latência. Como a Microsoft descreve neste artigo, o campo do tamanho da janela TCP tem apenas 16 bits, o que limita a janela sem escalonamento a 65,535 bytes. Para ultrapassar esta limitação, foi introduzida a opção de escalonamento da janela TCP no RFC 7323, permitindo deslocar o tamanho da janela para a esquerda até 14 bits e aumentando efetivamente o tamanho máximo da janela para 1 GB. O fator de escala é negociado durante o estabelecimento da ligação TCP em três passos. Depois de ativado, permite aos terminais multiplicar o tamanho original da janela. Os algoritmos de controlo de congestionamento dos sistemas operativos dos dispositivos cliente trabalham constantemente para determinar o escalonamento correto do tamanho da janela. Em alguns casos, como no sistema operativo Microsoft Windows, o «ajuste automático» do tamanho da janela faz um trabalho particularmente fraco na maximização do débito de download.

Exemplo do tamanho da janela TCP negociado pelo sistema operativo e do efeito da latência no débito Fonte: duckware.com/blog/how-windows-is-killing-internet-download-speeds

Porque não basta continuar a aumentar o tamanho da janela TCP

Em última análise, o tamanho da janela TCP depende da largura de banda disponível e do tempo de ida e volta. No entanto, não basta aumentar o tamanho da janela para obter um débito superior. A partir de certo ponto, janelas maiores exigem mais memória e capacidade de processamento tanto no emissor como no recetor, o que pode sobrecarregar dispositivos e redes, aumentar a perda de pacotes e reduzir o desempenho.

Por isso, no cenário anterior, uma janela TCP de cerca de 1.7 MB é, na verdade, bastante normal e reflete uma ligação com bom desempenho, dada a latência elevada. O limite superior geral de cerca de 2 MB pode funcionar como um teto prático para muitos sistemas modernos, equilibrando o débito e a utilização de recursos. Com uma janela de 2 MB e uma latência de 288 ms, o débito teórico máximo seria de aproximadamente 55.5 Mbps, o que explica porque é difícil alcançar velocidades acima deste valor, apesar de existirem ligações à Internet muito mais rápidas em ambas as extremidades (servidor e cliente). Se reorganizarmos as variáveis da equação anterior para calcular o débito, podemos ver que, com uma latência de 80 ms e uma janela de 2 MB, poderíamos teoricamente atingir cerca de 200 Mbps. Infelizmente, as leis da física impedem-nos de alcançar esta latência devido à distância física (Texas <-> Vietname).

Conclusão

Esperamos que este artigo tenha ajudado a compreender melhor o tema e a ter expectativas mais realistas quanto às velocidades de download/upload da próxima vez que utilizar a sua VPN WireGuard no estrangeiro. Por fim, lembre-se de que os routers gerem muitas sessões TCP em simultâneo. Embora o tão apreciado GL.iNet Flint 2 tenha uns generosos 1 GB de RAM DDR4, o router do lado do cliente ligado a esse Flint 2 pode ter muito menos RAM e, por isso, ser o fator limitante do escalonamento do tamanho da janela TCP.

Para mais informações e sugestões de resolução de problemas e para compreender a sua configuração de VPN WireGuard, consulte a seguinte publicação no fórum da GL.iNet: https://forum.gl-inet.com/t/how-to-troubleshoot-wireguard/42502

Apresentamos os routers domésticos da GL.iNet