Porque a velocidade aos servidores UE é menor no Speedtest

O Speedtest marcou 290 Mbps. A velocidade real com servidores na UE sai mais perto dos 38 Mbps. Uma diferença de cerca de oito vezes custa a ignorar. E quase sempre a culpa é da longa rota internacional, não do seu equipamento nem do nosso serviço.

A versão curta

O Speedtest e uma ligação real a um servidor distante medem coisas diferentes. O Speedtest mede a capacidade bruta da sua linha local, numa rota muito curta. O trabalho real com servidores da UE depende da latência e do estado dos canais internacionais que o seu tráfego atravessa. Um resultado alto no Speedtest diz-lhe apenas que a linha está saudável. A velocidade baixa para a UE vem da física das ligações longas e da carga nas redes de trânsito.

Como é a diferença

É uma só linha, medida duas vezes com minutos de intervalo. Primeiro o Speedtest, contra um servidor que ele próprio escolheu.

Dois pormenores desse painel explicam quase todo o número. Em "Connections" está "Multi", ou seja, a cifra soma vários fluxos ao mesmo tempo. E o servidor escolhido fica no mesmo país. Agora a mesma linha medida contra os servidores por onde os webinars passam mesmo, no passo "Speed" do nosso teste de ligação.

A descarga cai cerca de oito vezes. O envio desce apenas de 26 para 16, uma queda bem mais suave. Nenhuma das cifras diz que a linha está avariada. O resto do artigo explica para onde vai cada uma delas.

No segundo painel há uma coisa a ler com atenção. "TO YOU" é o que recebe e "FROM YOU" é o que envia. É você quem apresenta? Então o número que conta é "FROM YOU", porque a câmara, o microfone e o ecrã sobem todos. Quem só assiste depende antes de "TO YOU". Na medição acima, 15,98 Mbps de subida são cerca de dez vezes aquilo de que um apresentador precisa.

As legendas dos ecrãs estão em inglês, porque a interface foi fotografada nessa versão. Numa interface em português os mesmos pontos têm nomes portugueses e ficam nos mesmos sítios.

O que o Speedtest mede na verdade

O Speedtest foi construído para mostrar o número mais alto possível. Por isso o resultado só em parte reflete o trabalho real com servidores distantes.

• Escolhe o servidor mais próximo. O Speedtest fica com o nó de menor latência, quase sempre dentro da rede do seu operador ou na mesma cidade. O tráfego até lá faz um caminho curto e nunca toca em canais internacionais.
• Abre muitas ligações em paralelo. O Speedtest corre vários fluxos TCP ao mesmo tempo, normalmente de 4 a 16, e soma a velocidade deles. Assim contorna o limite que uma ligação única encontra nas rotas longas, e a secção seguinte explica-o. Os programas reais trabalham muitas vezes com um fluxo ou dois, por isso nunca ganham esse bónus.
• A latência é mínima. Numa rota curta o tempo de ida e volta, o RTT, não passa de alguns milissegundos, e o TCP tem tempo de acelerar até à velocidade plena da linha.

O Speedtest mostra, portanto, o débito de laboratório da sua linha. Não mostra o que vai conseguir ao trocar dados com um servidor noutro país.

O produto largura de banda por latência e a janela TCP

A maior parte da diferença assenta num único mecanismo.

O TCP envia dados em janelas. O emissor empurra um pedaço de dados e espera pela confirmação de chegada antes de seguir. A velocidade máxima de uma ligação TCP única sai de uma fórmula simples.

Velocidade = tamanho da janela / latência (RTT)

Para encher a linha, a janela tem de chegar ao produto largura de banda por latência, o BDP.

BDP = largura de banda × RTT

Faça as contas para essa linha de 290 Mbps, com uma latência até um servidor da UE de cerca de 50 ms.

BDP = 290 000 000 bit/s × 0,05 s = 14 500 000 bits = 1,81 MB

Ou seja, cerca de 1,8 MB de dados têm de estar em trânsito a cada instante para a linha saturar. Um dos lados ficou preso a uma janela limitada, os clássicos 64 KB sem escalonamento? Então o teto de uma ligação única sai assim.

Velocidade = 65 536 bytes × 8 bits / 0,05 s ≈ 10,5 Mbps

É por isso que uma ligação única a um servidor distante não passa dos 10 a 20 Mbps. Pouco importa que a linha tenha centenas de megabits. Numa rota curta, com um RTT de 2 ms, a mesma janela daria mais de 260 Mbps. Daí o problema nunca aparecer no Speedtest. Quanto maior a latência, mais forte o efeito. Nada está avariado aqui, porque o protocolo comporta-se mesmo assim.

A latência e a física das ligações longas

A latência numa rota longa junta várias parcelas, e algumas delas não se removem de todo.

A luz viaja na fibra ótica a cerca de 200 000 km/s. É bem mais devagar do que no vácuo, por causa do índice de refração do vidro. Cada mil quilómetros de rota acrescenta uns 5 ms num sentido, portanto uns 10 ms na ida e volta. E as rotas reais raramente seguem a direito, por isso saem quase sempre mais longas do que a distância geográfica.

Depois há o atraso em cada nó intermédio. Cada router processa o pacote, mete-o em fila e passa-o adiante. No caminho até um servidor da UE há tipicamente 10 a 20 desses nós, os saltos, e cada um cobra a sua parte. Quanto mais alto o RTT que daí resulta, mais baixo fica o teto de uma ligação única, pela fórmula acima.

A perda de pacotes e o efeito no TCP

Mesmo uma perda pequena de pacotes num canal internacional corta a velocidade final com força. O TCP lê um pacote perdido como sinal de congestão, trava e depois volta a subir a velocidade. A relação está na equação de Mathis.

Velocidade ≈ MSS / (RTT × √p)

MSS é o tamanho máximo do segmento, normalmente à volta de 1460 bytes. RTT é a latência e p é a fração de pacotes perdidos. A velocidade cai com a raiz quadrada da taxa de perda e depende diretamente da latência.

Na prática os números são dramáticos. Com um RTT de 50 ms e um MSS normal, mesmo 0,1 por cento de perda limita uma ligação única a uns 7 Mbps. Um por cento de perda baixa-a para cerca de 2,3 Mbps, e 2 por cento levam-na abaixo de 1,7 Mbps. Nas rotas de trânsito longas, perder 1 a 2 por cento nas horas de ponta é inteiramente normal. Nesses valores a perda morde mais do que o limite da janela acima. É isto que torna inutilizável à noite uma rota que de manhã parecia apenas lenta.

Encaminhamento e peering

O caminho do seu tráfego até um servidor da UE não é direto. Passa por uma cadeia de operadores e pelo protocolo de encaminhamento BGP. O BGP escolhe a rota por razões comerciais e técnicas, não pela distância mais curta.

Daí saem vários problemas típicos. Uma rota pode dar a volta por um terceiro país havendo um caminho mais curto. Sobem então a latência e o risco de perda. O tráfego atravessa também as junções entre redes, ou seja, pontos de peering e canais de trânsito. É numa junção congestionada que a velocidade cai. O encaminhamento assimétrico é vulgar, com os pacotes a ir por um caminho e a voltar por outro. Isso torna qualquer diagnóstico mais difícil de ler. A capacidade internacional também se compra, não se recebe. O operador que comprou pouco fica sem ela na hora de ponta.

Congestão nos canais internacionais do seu operador

O tráfego local, dentro da cidade e dentro do país, tem folga de sobra na maioria dos operadores. Por isso o Speedtest contra um servidor próximo mostra sempre um número alto. Os canais internacionais custam mais e compram-se em volume limitado. Na hora de ponta da noite passam a ser o estrangulamento. Daí a velocidade para a UE oscilar tanto ao longo do dia, enquanto o Speedtest local se mantém alto.

Outros fatores técnicos

Para além das causas principais, há mais algumas coisas que pesam na velocidade até um servidor distante.

MTU e fragmentação. Se o MTU ao longo da rota for menor do que o esperado, os pacotes fragmentam-se e a eficiência desce. Um PMTUD mal configurado, ou seja, a descoberta do MTU do caminho, leva a buracos negros e a transferências paradas.

Bufferbloat. Buffers grandes demais nos nós intermédios sobem a latência sob carga. Baralham também os algoritmos de controlo de fluxo do TCP, e a velocidade real desce ainda mais.

Modelação e prioridades, o chamado QoS. Alguns operadores estrangulam de propósito o tráfego internacional, ou um tipo concreto de tráfego. Isso aparece logo na sua velocidade.

Peso do protocolo. Os cabeçalhos de TCP, de IP e da cifra comem parte da largura de banda. Numa rota curta isso é invisível. Numa rota longa, somado à perda e à latência, já conta.

O seu ambiente local. Wi-Fi em vez de cabo, um router de casa sobrecarregado, um antivírus ou uma VPN no aparelho baixam todos a velocidade real. Ponha-os de lado antes de olhar mais longe.

Porque isto não é problema do equipamento nem do serviço

Um resultado alto no Speedtest prova que o seu equipamento e a sua linha local estão saudáveis. Dão a velocidade devida. A queda no trabalho com servidores da UE vem de outro lado. São quatro coisas. A latência da rota longa e o limite da janela numa ligação TCP única. Depois a perda de pacotes e o estado dos canais internacionais do seu operador. Tudo isso fica fora do nosso serviço e fora do seu equipamento. Pertence ao troço de rede entre o seu operador e os operadores de espinha dorsal.

Antes de correr atrás dos números, vale a pena pôr isto em perspetiva. Um webinar precisa de muito menos do que uma transferência de ficheiros. Por isso 20 Mbps para a UE não nos incomodam nada. Um apresentador precisa de uns 1,6 Mbit/s de subida, ou 3,2 com partilha de ecrã. Um participante precisa do suficiente para receber cada orador no ar, e os requisitos técnicos trazem as contas todas. Aqui a estabilidade pesa mais do que a velocidade bruta. Se os seus eventos correm bem, a diferença face ao Speedtest é uma curiosidade, não uma avaria a corrigir.

Como verificar por si

Umas quantas verificações apertam o cerco à causa.

• Corra o Speedtest à mão e escolha um servidor na Alemanha ou na Finlândia. Todos os nossos servidores estão na UE, entre a Alemanha, a França, os Países Baixos e a Finlândia. Mas o tráfego dos webinars anda nas máquinas alemãs e finlandesas. As holandesas e as francesas enviam os emails de convite dos eventos, por isso medir contra essas duas fala-lhe de uma rota que os seus webinars nunca usam. Contra a Alemanha ou a Finlândia vê a velocidade real da rota que conta na prática, em vez da rota até ao servidor local mais próximo.
• Trace a rota. Corra tracert no Windows, ou traceroute no macOS e no Linux, contra o nosso servidor, e fica com a cadeia de nós e a latência de cada um. Para ver melhor a perda e a latência, use o utilitário mtr, ou o WinMTR no Windows, e deixe-o a correr uns minutos na hora de ponta.
• Compare uma ligação com várias. Se uma descarga em vários fluxos é rápida e um fluxo único é lento, está confirmado o limite da janela TCP na rota longa.
• Se tiver meios técnicos, use o iperf3 para medir o débito até ao nó distante diretamente, primeiro com um fluxo e depois com vários.

O nosso teste do equipamento leva também a um teste dedicado de qualidade da internet, com velocidade, ping e jitter. É uma maneira rápida de registar o estado da linha num dado momento.

O que fazer

As suas verificações mostram latência alta ou perda de pacotes no troço internacional? Fale com o seu operador e leve dados concretos, o traçado da rota e uma leitura do mtr com a hora apontada. Ajustar a rota ou alargar a ligação internacional é trabalho do operador. Do nosso lado damos-lhe os endereços dos nossos servidores para um diagnóstico dirigido e ajudamos a ler os resultados. Abra o chat online e enviamos-lhos.

Em resumo

Um resultado do Speedtest perto de 290 Mbps confirma que a linha está saudável. A queda para menos de 40 Mbps com servidores da UE é esperada. Vem da latência da rota longa e do limite da janela numa ligação TCP única. Vem também da perda de pacotes e da carga nos canais internacionais do seu operador. Essas causas ficam na rede entre si e nós, não no seu equipamento nem no nosso serviço. Um diagnóstico simples da rota mostra qual das quatro está a fazer o estrago.

Perguntas frequentes

Devo pagar uma linha mais rápida para resolver isto?

Não. Um webinar precisa de muito menos do que uma transferência de ficheiros, e 20 Mbps para a UE não nos incomodam nada. Um apresentador precisa de uns 1,6 Mbit/s de subida, ou 3,2 com partilha de ecrã. Os requisitos técnicos trazem as contas todas. Aqui a estabilidade pesa mais do que a velocidade bruta. Se os seus eventos correm bem, a diferença face ao Speedtest é uma curiosidade, não uma avaria a corrigir.

A minha descarga caiu oito vezes e o envio quase não mexeu. Qual conta?

O envio, se for você a apresentar. A câmara, o microfone e o ecrã sobem todos, e essa é a cifra "FROM YOU". Quem só assiste depende antes de "TO YOU". A mesma medição lê-se de outra maneira, conforme o seu papel no evento. Na leitura acima o envio desceu apenas de 26 para 16 Mbps, cerca de dez vezes aquilo de que um apresentador precisa.

Que servidor do Speedtest devo escolher para uma comparação justa?

Um na Alemanha ou na Finlândia. Todos os nossos servidores estão na UE, entre a Alemanha, a França, os Países Baixos e a Finlândia. Mas o tráfego dos webinars anda nas máquinas alemãs e finlandesas. As holandesas e as francesas enviam os emails de convite dos eventos. Medir contra essas duas fala-lhe de uma rota que os seus webinars nunca usam.

Há aqui alguma coisa que eu possa resolver sozinho?

Comece pelo seu lado. Wi-Fi em vez de cabo, um router de casa sobrecarregado, um antivírus ou uma VPN no aparelho baixam todos a velocidade real. Se isso estiver limpo e as verificações continuarem a mostrar latência alta ou perda no troço internacional, o conserto é do seu operador. Fale com ele e leve dados concretos, o traçado da rota e uma leitura do mtr com a hora apontada. Podemos dar-lhe os endereços dos nossos servidores para um diagnóstico dirigido, por isso abra o chat online e enviamos-lhos.

Porque é que a rota está boa de manhã e inutilizável à noite?

Os canais internacionais compram-se em volume limitado e passam a ser o estrangulamento na hora de ponta da noite. O tráfego local tem folga de sobra. Daí o Speedtest contra um servidor próximo manter-se alto o dia inteiro. A perda de pacotes segue a mesma curva. Perder 1 a 2 por cento nas rotas de trânsito longas em horas de ponta é inteiramente normal. Com um RTT de 50 ms, um por cento de perda segura uma ligação única em cerca de 2,3 Mbps. É isso que torna inutilizável uma rota apenas lenta.