Para muitas tarefas, os atrasos entre o cliente e o servidor são críticos, por exemplo, em jogos online, videoconferências / voz, telefonia IP, VPN, etc. Se o servidor estiver muito longe do cliente no nível da rede IP, os atrasos (popularmente conhecidos como "ping", "lag") interferirão no trabalho.A proximidade geográfica do servidor nem sempre é igual à proximidade no nível de roteamento IP. Portanto, por exemplo, um servidor em outro país pode estar "mais próximo" de você do que um servidor em sua cidade. Tudo por causa dos recursos de roteamento e rede. Como escolher um servidor o mais próximo possível de todos os clientes em potencial? O que é conectividade de rede IP? Como direcionar o cliente para o servidor mais próximo? Vejamos o artigo.
Medimos atrasos
Primeiro, aprenda como medir a latência. Essa tarefa não é tão simples quanto parece, pois para diferentes protocolos e tamanhos de pacote, os atrasos podem variar. Você também não pode perceber fenômenos de curto prazo, como falhas que duram vários milissegundos.ICMP - ping regular
Usaremos o utilitário ping do Unix, que permite definir manualmente os intervalos entre os pacotes, que a versão do ping para windows não conhece. Isso é importante, porque se as pausas entre os pacotes forem longas, você não poderá ver o que está acontecendo entre eles.Tamanho do pacote (opção -s) - por padrão, o ping envia pacotes de tamanho 64 bytes. Com pacotes tão pequenos, os fenômenos que ocorrem com pacotes grandes podem não ser perceptíveis; portanto, definiremos o tamanho do pacote para 1300 bytes.O intervalo entre pacotes (opção -i) - o tempo entre o envio de dados. Por padrão, os pacotes são enviados uma vez por segundo, leva muito tempo, os programas reais enviam centenas e milhares de pacotes por segundo, portanto, definimos 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
Esse design permite que você veja uma imagem mais realista dos atrasos.Ping sobre UDP e TCP
Em alguns casos, as conexões TCP não são tratadas da mesma maneira que os pacotes ICMP e, por esse motivo, as medidas podem diferir dependendo do protocolo. Também acontece frequentemente que o host simplesmente não responde ao ICMP e o ping regular não funciona. Assim, por exemplo, o host microsoft.com faz toda a vida .O utilitário nping dos desenvolvedores do famoso scanner nmap pode gerar qualquer pacote. Também pode ser usado para medir atrasos.Como o UDP e o TCP funcionam em outros específicos, precisamos "executar ping" em uma porta específica. Vamos tentar executar ping no TCP 80, ou seja, na porta do servidor da 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 pára. A opção -c 0 permite o envio infinito de pacotes.Para interromper o programa, pressione Ctrl + C. No final, as estatísticas serão mostradas. Vemos que o rtt médio (tempo de ida e volta) é de 101ms.MTR - traceroute em esteróides
O programa MTR (inglês My Traceroute) é um utilitário avançado para rastrear rotas para um host remoto. Diferentemente do traceroute regular do utilitário do sistema (no Windows, é o utilitário tracert), ele pode mostrar atrasos para cada host na cadeia de pacotes. Também sabe como rastrear rotas não apenas via ICMP, mas também via UDP e TCP.$ sudo mtr microsoft.com
(Clicável) A interface do programa MTR. Um rastreamento de rota foi iniciado no microsoft.com. OMTR mostra imediatamente o ping em cada host da cadeia. Além disso, os dados são atualizados constantemente enquanto o programa está sendo executado e você pode ver alterações de curto prazo.A captura de tela mostra que há perdas de pacotes no nó No.6, 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 sobre perdas de pacotes podem ser ignorados aqui.WiFi vs cable
Este tópico não é totalmente relevante para o artigo, mas, na minha opinião, é muito importante no contexto de atrasos. Eu realmente gosto de WiFi, mas se tiver a menor oportunidade de conectar um cabo à Internet, vou usá-lo. Além disso, eu sempre desencorajo as pessoas a usar câmeras WiFi.Se você joga gravadores on-line sérios, transmite streaming de vídeo, negocia na bolsa: use a Internet via cabo.Aqui está um teste visual para comparar a conectividade Wi-Fi e a cabo. Isso faz ping em um roteador WiFi, ou seja, nem mesmo na Internet. (Clicável) Comparação de ping para um roteador Wi-Fi via cabo e Wi
- Fi Pode-se observar que os atrasos no Wi-Fi são maiores em 1 ms e, às vezes, há pacotes com atrasos dez vezes maiores! E este é apenas um curto período de tempo. Nesse caso, o mesmo roteador produz atrasos estáveis <1ms.
No exemplo acima, o WiFi 802.11n a 2.4GHz é usado, apenas um laptop e um telefone estão conectados ao ponto de acesso via WiFi. Se houvesse mais clientes no ponto de acesso, os resultados seriam muito piores. É por isso que sou contra a transferência de todos os computadores do escritório para o WiFi, se houver a oportunidade de alcançá-los com um cabo.Conectividade IP
Então, aprendemos como medir o atraso no servidor, tente encontrar o servidor mais próximo de nós. Para fazer isso, podemos ver como o roteamento do nosso provedor é organizado. Para isso, é conveniente usar o serviço bgp.he.net
Ao entrar no site, vemos que nosso endereço IP pertence ao sistema autônomo AS42610 .Observando o gráfico de conectividade de sistemas autônomos, podemos ver através de quais provedores superiores 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 do provedorUsando esta ferramenta, você pode aprender como os canais de qualquer provedor são organizados, incluindo hospedagem. Veja a quais provedores está conectado diretamente. Para fazer isso, direcione o IP do servidor para a pesquisa bgp.he.net e observe o gráfico de seu sistema autônomo. Você também pode entender como um data center ou provedor de hospedagem está relacionado a outro.A maioria dos pontos de troca de tráfego fornece uma ferramenta especial chamada espelho, que permite executar ping e traceroute de um roteador específico no ponto de troca.Por exemplo, o espelho do MGTSAssim, escolhendo um servidor, podemos ver com antecedência como ele será exibido em diferentes pontos de troca de tráfego. E se nossos clientes em potencial estiverem localizados em uma determinada área geográfica, podemos encontrar a localização ideal para o servidor.Escolha o servidor mais próximo
Decidimos simplificar o processo de encontrar o servidor ideal para nossos clientes e fizemos uma página com um teste automático dos locais mais próximos: data centers RUVDS .Quando você entra na página, o script mede os atrasos do navegador para cada servidor e os exibe em um mapa interativo. Quando você clica em um data center, são exibidas informações com os resultados dos testes. O botão leva à página de teste de atraso para todos os nossos data centers. Para ver os resultados do teste, clique no ponto do data center no mapa
