Para muchas tareas, los retrasos entre el cliente y el servidor son críticos, por ejemplo en juegos en línea, videoconferencias/conferencias de voz, telefonía IP, VPN, etc. Si el servidor está demasiado lejos del cliente a nivel de red IP, los retrasos (popularmente llamados "ping", "lag") interferirán con el trabajo.
La proximidad geográfica de un servidor no siempre equivale a proximidad a 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 debido a las peculiaridades del enrutamiento y la construcción de la red.
¿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 un cliente al servidor más cercano? Averigüemos en el artículo.
Medición de retrasos
Primero, aprendamos cómo medir los retrasos. Esta tarea no es tan sencilla como parece porque los retrasos pueden variar según los diferentes protocolos y tamaños de paquetes. También es posible que se pierdan eventos a corto plazo, como caídas que duran unos pocos milisegundos.
ICMP: ping normal
Usaremos la utilidad ping de Unix; le permite configurar manualmente los intervalos entre el envío de paquetes, lo que la versión de ping para Windows no puede hacer. Esto es importante porque si hay pausas largas entre paquetes, es posible que simplemente no veas lo que sucede entre ellos.
Tamaño del paquete (opción -s): de forma predeterminada, la utilidad ping envía paquetes de 64 bytes de tamaño. Con paquetes tan pequeños, los fenómenos que ocurren con paquetes más grandes pueden no ser perceptibles, por lo que estableceremos el tamaño del paquete en 1300 bytes.
Intervalo entre paquetes (opción -i) — tiempo entre envíos de datos. De forma predeterminada, los paquetes se envían una vez por segundo, esto es muy largo, los programas reales envían cientos y miles de paquetes por segundo, por lo que estableceremos el intervalo en 0.1 segundos. El programa simplemente no permite menos.
Como resultado, el comando tiene este aspecto:
ping -s 1300 -i 0.1 yandex.ru
Este diseño le permite ver una imagen más realista de los retrasos.
Hacer ping a través de UDP y TCP
En algunos casos, las conexiones TCP se procesan de manera diferente a los paquetes ICMP y, debido a esto, las mediciones pueden variar según el protocolo. También sucede a menudo que el host simplemente no responde a ICMP y el ping normal no funciona. Esto es lo que hace un anfitrión toda su vida, por ejemplo. microsoft.com.
Utilidad de los desarrolladores del famoso escáner nmap puede generar cualquier paquete. También se puede utilizar para medir retrasos.
Dado que UDP y TCP operan en puertos específicos, necesitamos hacer "ping" a un puerto específico. Intentemos hacer ping al TCP 80, es decir, al 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
De forma predeterminada, nping envía 4 paquetes y se detiene. Opción -c 0 permite el envío interminable de paquetes; para detener el programa, debe presionar Ctrl+C. Las estadísticas se mostrarán al final. Vemos que el valor promedio de rtt (tiempo de ida y vuelta) es 101 ms.
MTR - traceroute con esteroides
programa My Traceroute es una utilidad avanzada para rastrear rutas a un host remoto. A diferencia de la utilidad habitual del sistema traceroute (en Windows esta es la utilidad tracert), puede mostrar retrasos en cada host en la cadena de paquetes. También puede rastrear rutas no sólo a través de ICMP, sino también a través de UDP y TCP.
$ sudo mtr microsoft.com
(Se puede hacer clic) Interfaz del programa MTR. Se inició el seguimiento de ruta a microsoft.com
MTR muestra inmediatamente el ping a cada host de la cadena y los datos se actualizan constantemente mientras el programa se ejecuta y se pueden ver cambios a corto plazo.
La captura de pantalla muestra que el nodo 6 tiene pérdidas de paquetes, pero en realidad esto no es del todo cierto, porque algunos enrutadores pueden simplemente descartar paquetes con un TTL caducado y no devolver una respuesta de error, por lo que los datos de pérdida de paquetes se pueden ignorar aquí.
Wi-Fi frente a 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 amo el WiFi, pero si tengo la más mínima oportunidad de conectarme a Internet con un cable, lo usaré. También siempre desaconsejo a la gente que utilice cámaras WiFi.
Si juegas shooters serios en línea, transmites vídeos o comercias en la bolsa de valores: utiliza Internet por cable.
Aquí tienes una prueba visual para comparar las conexiones WiFi y por cable. Este es un ping al enrutador WiFi, es decir, ni siquiera a Internet todavía.
(Se puede hacer clic) Comparación de ping a un enrutador WiFi por cable y por WiFi
Se puede ver que en WiFi el retraso es 1 ms más largo y, a veces, hay paquetes con retrasos diez veces más largos. Y esto es sólo un corto período de tiempo. Al mismo tiempo, el mismo enrutador produce retrasos estables de <1 ms.
En el ejemplo anterior, se utiliza WiFi 802.11n a 2.4 GHz, solo una computadora portátil y un teléfono están conectados al punto de acceso WiFi. Si hubiera más clientes en el punto de acceso, los resultados serían mucho peores. Por eso estoy tan en contra de cambiar todos los ordenadores de la oficina a WiFi si es posible llegar a ellos mediante un cable.
Conectividad IP
Entonces, hemos aprendido a medir los retrasos en el servidor, intentemos encontrar el servidor más cercano a nosotros. Para ello, podemos fijarnos en cómo funciona el enrutamiento de nuestro proveedor. Es conveniente utilizar el servicio para esto.
Cuando accedemos al sitio, vemos que nuestra dirección IP pertenece al sistema autónomo. .
Al observar el gráfico de conectividad de los sistemas autónomos, podemos ver a través de qué proveedores de nivel superior está conectado nuestro proveedor 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 de los sistemas autónomos del proveedor.
Con esta herramienta podrás estudiar cómo se estructuran los canales de cualquier proveedor, incluido el hosting. Vea a qué proveedores está conectado directamente. Para hacer esto, debe ingresar la dirección IP del servidor en la búsqueda bgp.he.net y mirar el gráfico de su sistema autónomo. También puede comprender cómo se conecta un centro de datos o proveedor de alojamiento a otro.
La mayoría de los puntos de intercambio de tráfico proporcionan una herramienta especial llamada Looking Glass, que le permite hacer ping y rastrear la ruta desde un enrutador específico en el punto de intercambio.
Aquí, por ejemplo, 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 una determinada zona geográfica, podremos buscar la ubicación óptima para el servidor.
Seleccione el servidor más cercano
Decidimos simplificar el procedimiento para encontrar el servidor óptimo para nuestros clientes y creamos una página con pruebas automáticas de ubicaciones cercanas: .
Cuando visita una página, el script mide los retrasos desde su navegador hasta 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 las pruebas.
El botón lo lleva a la página de prueba de latencia para todos nuestros centros de datos. Para ver los resultados de la prueba, haga clic en el punto del centro de datos en el mapa.
Fuente: habr.com