La lucha por milisegundos. Cómo elegir el servidor con el menor ping

Para muchas tareas, los retrasos entre el cliente y el servidor son críticos, por ejemplo, en juegos en línea, video / conferencias de voz, telefonía IP, VPN, etc. Si el servidor está demasiado lejos del cliente en el nivel de la red IP, los retrasos (conocidos popularmente como "ping", "retraso") interferirán con el trabajo.

La proximidad geográfica del servidor no siempre es igual a la proximidad en el nivel de enrutamiento IP. Entonces, por ejemplo, un servidor en otro país puede estar "más cerca" de usted que un servidor en su ciudad. Todo por las características de enrutamiento y redes. ¿Cómo elegir un servidor lo más cercano posible a todos los clientes potenciales? ¿Qué es la conectividad de red IP? ¿Cómo dirigir al cliente al servidor más cercano? Miremos el artículo.





Medimos retrasos


Primero, aprenda a medir la latencia. Esta tarea no es tan simple como podría parecer, porque para diferentes protocolos y tamaños de paquetes, los retrasos pueden variar. Tampoco puede notar fenómenos a corto plazo, como fallas que duran varios milisegundos.

ICMP - ping regular


Utilizaremos la utilidad de ping de Unix, que le permite configurar manualmente los intervalos entre paquetes, que la versión de ping para Windows no conoce. Esto es importante, porque si las pausas entre los paquetes son largas, simplemente no puede ver lo que sucede entre ellos.

Tamaño de paquete (opción -s): de forma predeterminada, ping envía paquetes de un tamaño de 64 bytes. Con estos paquetes pequeños, los fenómenos que ocurren con paquetes grandes pueden no ser perceptibles, por lo que estableceremos el tamaño del paquete en 1300 bytes.

El intervalo entre paquetes (opción -i): el tiempo entre el envío de datos. Por defecto, los paquetes se envían una vez por segundo, lleva mucho tiempo, los programas reales envían cientos y miles de paquetes por segundo, por lo que establecemos el intervalo en 0.1 segundos. El programa simplemente no permite menos.

Como resultado, el comando se ve así:

ping -s 1300 -i 0.1 yandex.ru

Este diseño le permite ver una imagen más realista de los retrasos.

Haga ping sobre UDP y TCP


En algunos casos, las conexiones TCP no se manejan de la misma manera que los paquetes ICMP, y debido a esto, las mediciones pueden diferir según el protocolo. También sucede a menudo que el host simplemente no responde a ICMP y que el ping regular no funciona. Entonces, por ejemplo, el host microsoft.com hace toda la vida .

La utilidad nping de los desarrolladores del famoso escáner nmap puede generar cualquier paquete. También se puede usar para medir demoras.
Dado que UDP y TCP funcionan en unos específicos, necesitamos "hacer ping" a un puerto específico. Intentemos hacer ping a TCP 80, es decir, el puerto del 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 y se detiene. La opción -c 0 permite el envío infinito de paquetes. Para detener el programa, presione Ctrl + C. Al final, se mostrarán las estadísticas. Vemos que el rtt promedio (tiempo de ida y vuelta) es de 101 ms.

MTR - traceroute en esteroides


El programa MTR (English My Traceroute) es una utilidad avanzada para rastrear rutas a un host remoto. A diferencia del traceroute de la utilidad del sistema habitual (en Windows es la utilidad tracert), puede mostrar retrasos a cada host en la cadena de paquetes. También sabe cómo rastrear rutas no solo a través de ICMP, sino también a través de UDP y TCP.

$ sudo mtr microsoft.com


(Se puede hacer clic) La interfaz del programa MTR. Se inició un seguimiento de ruta a microsoft.com

MTR muestra inmediatamente ping a cada host en la cadena, además, los datos se actualizan constantemente mientras se ejecuta el programa y puede ver cambios a corto plazo.
La captura de pantalla muestra que hay pérdidas de paquetes en el nodo No.6, pero en realidad esto no es del todo cierto, porque algunos enrutadores simplemente pueden descartar paquetes con TTL caducado y no devolver una respuesta de error, por lo que los datos sobre pérdidas de paquetes pueden ignorarse aquí.

WiFi vs cable



Este tema no es del todo relevante para el artículo, pero en mi opinión es muy importante en el contexto de los retrasos. Realmente me gusta el WiFi, pero si tengo la más mínima oportunidad de conectar un cable a Internet, lo usaré. Además, siempre desaliento a las personas de usar cámaras WiFi.
Si juegas tiradores serios en línea, transmites video en tiempo real, intercambias en el intercambio: usa Internet por cable.

Aquí hay una prueba visual para comparar WiFi y conectividad por cable. Esto es hacer ping a un enrutador WiFi, es decir, ni siquiera a Internet. ( Se puede hacer clic) Comparación de ping a un enrutador WiFi a través de cable y WiFi Se puede ver que los retrasos de WiFi son más largos en 1 ms y ¡a veces hay paquetes con retrasos diez veces más largos! Y esto es solo un corto período de tiempo. En este caso, el mismo enrutador produce demoras estables <1 ms.

imagen




En el ejemplo anterior, se usa WiFi 802.11n a 2.4GHz, solo una computadora portátil y un teléfono están conectados al punto de acceso a través de WiFi. Si hubiera más clientes en el punto de acceso, los resultados serían mucho peores. Es por eso que estoy tan en contra de la transferencia de todas las computadoras de oficina a WiFi, si existe la oportunidad de contactarlas con un cable.

Conectividad IP


Entonces, aprendimos cómo medir el retraso al servidor, tratar de encontrar el servidor más cercano a nosotros. Para hacer esto, podemos ver cómo se organiza la ruta de nuestro proveedor. Para esto, es conveniente utilizar el servicio bgp.he.net.



Al ingresar al sitio, vemos que nuestra dirección IP pertenece al sistema autónomo AS42610 .

Mirando el gráfico de conectividad de los sistemas autónomos, podemos ver a través de qué proveedores superiores nuestro proveedor está conectado con el resto del mundo. Se puede hacer clic en cada uno de los puntos, puede ingresar y leer qué tipo de proveedor es.


Gráfico de conectividad del proveedor

Con esta herramienta, puede aprender cómo se organizan los canales de cualquier proveedor, incluido el alojamiento. Vea a qué proveedores está conectado directamente. Para hacer esto, lleve la IP del servidor a bgp.he.net search y mire el gráfico de su sistema autónomo. También puede comprender cómo un centro de datos o proveedor de alojamiento está relacionado con otro.

La mayoría de los puntos de intercambio de tráfico proporcionan una herramienta especial llamada espejo, que le permite hacer ping y trazar rutas desde un enrutador específico en el punto de intercambio.

Por ejemplo, el espejo de MGTS

Entonces, al elegir un servidor, podemos ver de antemano cómo se verá desde diferentes puntos de intercambio de tráfico. Y si nuestros clientes potenciales se encuentran en un área geográfica determinada, podemos encontrar la ubicación óptima para el servidor.

Elige el servidor más cercano


Decidimos simplificar el proceso de encontrar el servidor óptimo para nuestros clientes e hicimos una página con una prueba automática de las ubicaciones más cercanas: los centros de datos RUVDS .
Cuando ingresa a la página, el script mide los retrasos desde su navegador a cada servidor y los muestra en un mapa interactivo. Cuando hace clic en un centro de datos, se muestra información con los resultados de la prueba. El botón lleva a la página de prueba de retraso a todos nuestros centros de datos. Para ver los resultados de la prueba, haga clic en el punto del centro de datos en el mapa








All Articles