Para moitas tarefas, os atrasos entre o cliente e o servidor son críticos, por exemplo en xogos en liña, videoconferencias/voz, telefonía IP, VPN, etc. Se o servidor está demasiado lonxe do cliente a nivel de rede IP, entón os atrasos (popularmente chamados "ping", "lag") interferirán co traballo.
A proximidade xeográfica dun servidor non sempre é igual á proximidade a nivel de enrutamento IP. Así, por exemplo, un servidor doutro país pode estar "máis próximo" a ti que un servidor da túa cidade. Todo debido ás peculiaridades do enrutamento e da construción da rede.
Como elixir un servidor que estea o máis próximo posible a todos os potenciais clientes? Que é a conectividade de rede IP? Como dirixir un cliente ao servidor máis próximo? Descubrímolo no artigo.
Medición de atrasos
En primeiro lugar, imos aprender a medir os atrasos. Esta tarefa non é tan sinxela como pode parecer porque os atrasos poden variar segundo os diferentes protocolos e tamaños de paquete. Tamén podes perderte eventos a curto prazo, como caídas que duran uns milisegundos.
ICMP - ping regular
Usaremos a utilidade ping de Unix; permíteche configurar manualmente os intervalos entre o envío de paquetes, cousa que a versión de ping para Windows non pode facer. Isto é importante porque se hai longas pausas entre os paquetes, pode que simplemente non vexa o que está a suceder entre eles.
Tamaño do paquete (opción -s): por defecto, a utilidade ping envía paquetes de 64 bytes de tamaño. Con paquetes tan pequenos, os fenómenos que ocorren con paquetes máis grandes poden non ser perceptibles, polo que estableceremos o tamaño do paquete en 1300 bytes.
Intervalo entre paquetes (opción -i) — tempo entre os envíos de datos. Por defecto, os paquetes envíanse unha vez por segundo, isto é moi longo, os programas reais envían centos e miles de paquetes por segundo, polo que estableceremos o intervalo en 0.1 segundos. O programa simplemente non permite menos.
Como resultado, o comando ten o seguinte aspecto:
ping -s 1300 -i 0.1 yandex.ru
Este deseño permítelle ver unha imaxe máis realista dos atrasos.
Ping a través de UDP e TCP
Nalgúns casos, as conexións TCP son procesadas de forma diferente aos paquetes ICMP e, por iso, as medicións poden variar dependendo do protocolo. Tamén ocorre a miúdo que o servidor simplemente non responde a ICMP e o ping normal non funciona. Isto é o que fai un anfitrión toda a súa vida, por exemplo. microsoft.com.
Utilidade dos desenvolvedores do famoso escáner nmap pode xerar calquera paquete. Tamén se pode usar para medir atrasos.
Dado que UDP e TCP operan con uns específicos, necesitamos "ping" a un porto específico. Tentemos facer ping ao TCP 80, é dicir, ao porto 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 defecto, nping envía 4 paquetes e detén. Opción -c 0 permite o envío infinito de paquetes; para deter o programa, cómpre premer Ctrl+C. As estatísticas mostraranse ao final. Vemos que o valor medio de rtt (tempo de ida e volta) é de 101 ms.
MTR - traceroute en esteroides
Programa My Traceroute é unha utilidade avanzada para rastrexar rutas a un host remoto. A diferenza da utilidade habitual do sistema traceroute (en Windows esta é a utilidade tracert), pode mostrar atrasos a cada host da cadea de paquetes. Tamén pode rastrexar rutas non só a través de ICMP, senón tamén a través de UDP e TCP.
$ sudo mtr microsoft.com
(Se pode facer clic) Interface do programa MTR. Comezou o rastrexo de rutas a microsoft.com
MTR mostra inmediatamente o ping a cada host da cadea e os datos actualízanse constantemente mentres o programa está en execución e pódense ver os cambios a curto prazo.
A captura de pantalla mostra que o nodo 6 ten perdas de paquetes, pero de feito isto non é totalmente certo, porque algúns enrutadores poden simplemente descartar paquetes cun TTL caducado e non devolver unha resposta de erro, polo que os datos de perda de paquetes poden ignorarse aquí.
WiFi vs cable
Este tema non é totalmente relevante para o artigo, pero na miña opinión é moi importante no contexto dos atrasos. Encántame moito o WiFi, pero se teño a menor oportunidade de conectarme a Internet cun cable, usarei. Tamén sempre desanimo á xente a usar cámaras WiFi.
Se xogas a tiradores en liña serios, transmites vídeos ou operas en bolsa: utiliza Internet por cable.
Aquí tes unha proba visual para comparar conexións WiFi e cable. Este é un ping ao enrutador WiFi, é dicir, nin sequera a Internet aínda.
(Se pode facer clic) Comparación do ping cun enrutador WiFi por cable e por WiFi
Pódese ver que a través de WiFi o atraso é 1ms máis longo e ás veces hai paquetes con atrasos dez veces máis! E isto é só un curto período de tempo. Ao mesmo tempo, o mesmo enrutador produce atrasos estables de <1 ms.
No exemplo anterior, utilízase WiFi 802.11n a 2.4 GHz, só un portátil e un teléfono están conectados ao punto de acceso WiFi. Se houbese máis clientes no punto de acceso, os resultados serían moito peores. É por iso que estou tan en contra de cambiar todos os ordenadores de oficina a WiFi se é posible chegar a eles cun cable.
Conectividade IP
Entón, aprendemos a medir os atrasos do servidor, imos tentar atopar o servidor máis próximo a nós. Para iso, podemos ver como funciona o enrutamento do noso provedor. É conveniente utilizar o servizo para iso
Cando accedemos ao sitio, vemos que o noso enderezo IP pertence ao sistema autónomo .
Ao observar o gráfico de conectividade dos sistemas autónomos, podemos ver a través de que provedores de nivel superior está conectado o noso provedor co resto do mundo. Cada un dos puntos pódese facer clic, podes entrar e ler que tipo de provedor é.
Gráfico de conectividade dos sistemas autónomos do provedor
Usando esta ferramenta, podes estudar como se estruturan as canles de calquera provedor, incluído o hospedaxe. Consulta a que provedores está directamente conectado. Para iso, cómpre introducir o enderezo IP do servidor na busca de bgp.he.net e mirar a gráfica do seu sistema autónomo. Tamén podes entender como un centro de datos ou provedor de hospedaxe está conectado a outro.
A maioría dos puntos de intercambio de tráfico proporcionan unha ferramenta especial chamada espello, que che permite facer ping e rastrexar desde un enrutador específico no punto de intercambio.
Aquí, por exemplo, de MGTS
Así, ao elixir un servidor, podemos ver de antemán como se verá desde diferentes puntos de intercambio de tráfico. E se os nosos clientes potenciais están situados nunha determinada zona xeográfica, podemos atopar a localización óptima para o servidor.
Seleccione o servidor máis próximo
Decidimos simplificar o procedemento para atopar o servidor óptimo para os nosos clientes e creamos unha páxina con probas automáticas de localizacións próximas: .
Cando visitas unha páxina, o script mide os atrasos do teu navegador a cada servidor e móstraos nun mapa interactivo. Cando fai clic nun centro de datos, móstrase información cos resultados da proba.
O botón lévache á páxina de proba de latencia de todos os nosos centros de datos. Para ver os resultados da proba, fai clic no punto do centro de datos do mapa
Fonte: www.habr.com