Para muitas tarefas, os atrasos entre o cliente e o servidor são críticos, por exemplo em jogos online, videoconferência/conferência de voz, telefonia IP, VPN, etc. Se o servidor estiver muito longe do cliente no nível da rede IP, os atrasos (popularmente chamados de “ping”, “lag”) interferirão no trabalho.
A proximidade geográfica de um servidor nem sempre é igual à proximidade no nível do roteamento IP. Assim, por exemplo, um servidor em outro país pode estar “mais próximo” de você do que um servidor na sua cidade. Tudo devido às peculiaridades de roteamento e construção da rede.
Como escolher um servidor o mais próximo possível de todos os potenciais clientes? O que é conectividade de rede IP? Como direcionar um cliente para o servidor mais próximo? Vamos descobrir no artigo.
Medindo atrasos
Primeiro, vamos aprender como medir atrasos. Esta tarefa não é tão simples quanto pode parecer porque os atrasos podem variar para diferentes protocolos e tamanhos de pacotes. Você também pode perder eventos de curto prazo, como quedas que duram alguns milissegundos.
ICMP - ping normal
Usaremos o utilitário Unix ping, que permite definir manualmente os intervalos entre o envio de pacotes, o que a versão ping para Windows não pode fazer. Isto é importante porque se houver longas pausas entre os pacotes, você simplesmente não verá o que está acontecendo entre eles.
Tamanho do pacote (opção -s) - por padrão, o utilitário ping envia pacotes de 64 bytes. Com pacotes tão pequenos, os fenômenos que ocorrem com pacotes maiores podem não ser perceptíveis, por isso definiremos o tamanho do pacote para 1300 bytes.
Intervalo entre pacotes (opção -i) — tempo entre envios de dados. Por padrão, os pacotes são enviados uma vez por segundo, isso é muito longo, programas reais enviam centenas e milhares de pacotes por segundo, então definiremos o intervalo para 0.1 segundo. O programa simplesmente não permite menos.
Como resultado, o comando fica assim:
ping -s 1300 -i 0.1 yandex.ru
Este design permite que você veja uma imagem mais realista dos atrasos.
Ping via UDP e TCP
Em alguns casos, as conexões TCP são processadas de forma diferente dos pacotes ICMP e, por causa disso, as medições podem variar dependendo do protocolo. Muitas vezes também acontece que o host simplesmente não responde ao ICMP e o ping normal não funciona. É isso que um anfitrião faz durante toda a vida, por exemplo. microsoft.com.
Utilitário
Como o UDP e o TCP operam em portas específicas, precisamos fazer “ping” em uma porta específica. Vamos tentar fazer ping no TCP 80, ou seja, na porta do servidor web:
$ sudo nping --tcp -p 80 --delay 0.1 -c 0 microsoft.com
Starting Nping 0.7.80 ( https://nmap.org/nping ) at 2020-04-30 13:07 MSK
SENT (0.0078s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40 seq=3401731188 win=1480
SENT (0.1099s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40 seq=3401731188 win=1480
RCVD (0.2068s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=43 id=0 iplen=44 seq=1480267007 win=64240 <mss 1440>
SENT (0.2107s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40 seq=3401731188 win=1480
RCVD (0.3046s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=43 id=0 iplen=44 seq=1480267007 win=64240 <mss 1440>
SENT (0.3122s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40 seq=3401731188 win=1480
RCVD (0.4247s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=42 id=0 iplen=44 seq=2876862274 win=64240 <mss 1398>
Max rtt: 112.572ms | Min rtt: 93.866ms | Avg rtt: 101.093ms
Raw packets sent: 4 (160B) | Rcvd: 3 (132B) | Lost: 1 (25.00%)
Nping done: 1 IP address pinged in 0.43 seconds
Por padrão, o nping envia 4 pacotes e para. Opção -c 0 permite o envio infinito de pacotes; para parar o programa, você precisa pressionar Ctrl+C. As estatísticas serão mostradas no final. Vemos que o valor médio de rtt (tempo de ida e volta) é 101ms.
MTR - traceroute com esteróides
Programa
$ sudo mtr microsoft.com
(Clicável) Interface do programa MTR. O rastreamento de rota para microsoft.com foi iniciado
O MTR mostra imediatamente o ping para cada host da cadeia, e os dados são constantemente atualizados enquanto o programa está em execução e alterações de curto prazo podem ser vistas.
A captura de tela mostra que o nó nº 6 tem perdas de pacotes, mas na verdade isso não é totalmente verdade, porque alguns roteadores podem simplesmente descartar pacotes com TTL expirado e não retornar uma resposta de erro, portanto, os dados de perda de pacotes podem ser ignorados aqui.
Wi-Fi x cabo
Este tema não é totalmente relevante para o artigo, mas na minha opinião é muito importante no contexto de atrasos. Eu realmente adoro WiFi, mas se tiver a menor oportunidade de me conectar à Internet com um cabo, irei usá-lo. Também sempre desencorajo as pessoas de usarem câmeras WiFi.
Se você joga jogos de tiro online sérios, faz streaming de vídeo ou negocia na bolsa de valores: use a Internet via cabo.
Aqui está um teste visual para comparar conexões WiFi e a cabo. Este é um ping para o roteador WiFi, ou seja, ainda nem para a Internet.
(Clicável) Comparação de ping para um roteador WiFi via cabo e via WiFi
Percebe-se que no WiFi o atraso é 1ms maior e às vezes há pacotes com atrasos dez vezes maiores! E este é apenas um curto período de tempo. Ao mesmo tempo, o mesmo roteador produz atrasos estáveis de <1ms.
No exemplo acima, é usado WiFi 802.11n a 2.4 GHz, apenas um laptop e um telefone estão conectados ao ponto de acesso WiFi. Se houvesse mais clientes no ponto de acesso, os resultados seriam muito piores. É por isso que sou tão contra mudar todos os computadores do escritório para WiFi se for possível alcançá-los com um cabo.
Conectividade IP
Então, aprendemos a medir atrasos no servidor, vamos tentar encontrar o servidor mais próximo de nós. Para fazer isso, podemos ver como funciona o roteamento do nosso provedor. É conveniente usar o serviço para isso
Ao acessar o site, vemos que nosso endereço IP pertence ao sistema autônomo
Observando o gráfico de conectividade dos sistemas autônomos, podemos ver através de quais provedores de nível superior nosso provedor está conectado ao resto do mundo. Cada um dos pontos é clicável, você pode entrar e ler que tipo de provedor é.
Gráfico de conectividade dos sistemas autônomos do provedor
Com esta ferramenta, você pode estudar como estão estruturados os canais de qualquer provedor, inclusive de hospedagem. Veja a quais provedores ele está diretamente conectado. Para fazer isso, você precisa inserir o endereço IP do servidor na busca por bgp.he.net e observar o gráfico de seu sistema autônomo. Você também pode entender como um data center ou provedor de hospedagem está conectado a outro.
A maioria dos pontos de troca de tráfego fornece uma ferramenta especial chamada espelho, que permite executar ping e rastrear a rota de um roteador específico no ponto de troca.
Aqui, por exemplo,
Assim, na hora de escolher um servidor, podemos ver com antecedência como ficará nos diferentes pontos de troca de tráfego. E se nossos potenciais clientes estiverem localizados em uma determinada área geográfica, podemos encontrar a localização ideal para o servidor.
Selecione o servidor mais próximo
Decidimos simplificar o procedimento para encontrar o servidor ideal para nossos clientes e criamos uma página com teste automático de locais próximos:
Quando você visita uma página, o script mede os atrasos do seu navegador para cada servidor e os exibe em um mapa interativo. Ao clicar em um data center, são exibidas informações com resultados de testes.
O botão leva você à página de teste de latência de todos os nossos data centers. Para visualizar os resultados do teste, clique no ponto do data center no mapa
Fonte: habr.com