Picos de lag al router

Buenas lsnfm 

Si miras muchos post de este mismo foro sobre latencia en general, que he analizado con diferentes servicios juegos etc, al final lo que importa son 3 cosas: Latencia final, jitter y paquetes perdidos reales. Lo de reales es importante y daría para otro hilo, pero basta decir que la inmensa mayoría de problemas de paquetes perdidos que se dicen, no son reales.

De la latencia final lo importante además no es ni un mínimo ni un máximo, es la media. Pero entonces, a caso no es importante los picos? Sí, mucho, cuando son habituales, por eso he dicho que otra cuestión importante es el jitter, que es precisamente esto lo que nos mide.

Yo para medir el jitter lo que hago es ni más ni menos que comparar el valor mínimo con el valor medio. Si la diferencia entre ambos es de 2ms, para mi el jitter es de 2ms, y esto me indica la cantidad de picos que existen. Es decir, pongamos que tienes latencia mínima 1, latencia máxima 100 y media de 50ms. Pues tenemos un jitter de 50ms, eso me dice que para que salga esa media no ha existido un pico de 100, han existido muchos muchos picos constantes, lo suficiente para que la media se vaya a 50ms, una salvajada. Pero si la media es de 2ms en ese mismo ejemplo, y existe un pico de 100ms, sé que el pico es anecdótico, porque sus aportaciones han sido incapaces de prácticamente variar el valor

-------------

Respecto a lo que preguntas del tráfico ICMP... a ver, es de baja prioridad y no. La respuesta es un poquito más compleja, porque puede parecer contradictoria.

Por un lado, tenemos el tráfico ping  repercute muy poco en cuanto a procesado. Esto no es porque se priorice más o menos, sino por como funciona el protocolo ICMP Echo. En esencia cuando un dispositivo envía un ICMP Echo Request a un equipo, se espera que reciba de forma automática un ICMP Echo Reply desde el destino. De este modo se puede calcular el tiempo que tarda desde que enviamos la petición hasta que nos llega la contestación. Es decir, lo que llamamos latencia por lo general (aunque la latencia es mucho más que eso), es el tiempo de ida y vuelta. Se usa ping porque repito es un protocolo específico para esto, al igual que otras de las muchas mañas que se pueden hacer con ICMP.

Esto requiere muy poco procesado porque el propio kernel del Router/dispositivo lo tiene de serie, es algo así casi como una respuesta automática. Por supuesto, se puede configurar un equipo para no responder a estos echo request (ping), y el efecto que tendría sería que desde tu punto de vista ese equipo está caído... cuando a lo mejor simplemente es que está configurado para no responder.

Ahora bien, que requiera poco procesado, no quiere decir que no ocupe ancho de banda, o que no pueda tener una repercusión en el ancho de banda. O por supuesto que no se tenga que procesar como cualquier otro paquete por un Router o nodo intermedio. Es más, uno puede enviar un ping del tamaño que quiera, incluso usando la longitud máxima de payload (datos) que puede llevar un paquete con MTU de 1492 ( máximo para nuestras conexiones)

En ipv6 el payload máximo que podemos usar es es 1444, 1492 menos la cabecera IPv6 (40) menos la cabecera ICMP (8). 1492-40-8 = 1444. (1464 para ipv4)

Es decir, que si enviamos un ping con una longitud de 1464/1444 (ipv4/ipv6), estamos enviando una ristra de paquetes de datos del máximo tamaño que podemos hacerlo. Esto, desde el punto de vista de procesamiento del paquete por nodos intermedios, es mucho más realista. Pero repito que esto no tiene que ver con el trabajo que le cuesta al equipo final el procesar la respuesta, es más, al destino le da igual que la longitud sea 1 que 100, es un ping, eso quiere decir que devuelve el mismo paquete de vuelta pero usando un ICMP reply... no solo con la misma longitud, repito, sino con los mismos datos.

------------------

Ahora bien, y por eso decía que podía parecer contradictorio, al margen de todo lo anterior hay que tener en cuenta dos cosas.

Primero, más allá de tu Router, la neutralidad de Internet impide de forma categórica tratar de forma diferente cualquier tipo de tráfico. Es decir, que el ISP o una red europea no puede relentizar o quitar prioridad a tu tráfico P2P y priorizar el tráfico DNS. Es ilegal. Lo mismo pasa por tanto con el tráfico ICMP. Dentro de tu red la cosa es diferente, tu puedes usar QoS de forma personalizada para priorizar cierto tipo de tráfico frente a otro, interesante cuando se tiene la red sobrecargada o el puñetero bufferbloat. Pero una vez que el tráfico sale de tu Router, es indiferente.

Pero existe un "pero". La red como digo no puede priorizar nada, pero un nodo intermedio, o incluso un servidor final puede si le da la real gana desde  filtrar (no contestar) al tráfico ICMP, o discriminarlo, es decir, tratarlo con menos prioridad o aceptar 1 de cada 3 o como se quiera. Es más, nuestros propios Router por lo general aplican restricciones de este tipo para ICMP, para evitar bombardeos, el Firewall del Router empieza a funcionar y evita este tráfico... normalmente no lo evita, sino lo pondera.

Esto provoca que muchas veces usar un ping se aleja enormemente de la realidad. Primero porque el destino hacia el que se envía puede estar discriminándolo de algún modo, y segundo porque el procesamiento que hace de ello es mínimo. El tráfico de un juego por ejemplo, tiene el servidor que procesarlo, darle sentido, construir la respuesta y enviarla de vuelta, datos que pueden ir desde encriptados, ofuscados, en cadenas que requieren cierto número de paquetes antes de responder... todo eso es latencia. Esto los gammer lo saben bien, a lo mejor te dice que un ping es de 40ms y el juego te dice que la latencia es de 60ms... obviamente, porque un ping al final te va a medir digamos lo mínimo de lo mínimo (siempre que no discrimine el tráfico ICMP el destino final.

------

Así que a tu respuesta, de si existe un modo mejor.... me temo que no. A día de hoy lo más práctico y rápido y fiable es usar un ping, aunque a veces podamos tener la sospecha de que el destino está jugando con el tráfico ICMP. Si te quieres asegurar más aun, puedes siempre como digo usar un ping con longitud máxima, lo puse más arriba, para que sea más fidedigno.

Existen sistemas alternativos realmente... la latencia se mide al final contando el tiempo desde que envías un paquete, el que sea, hasta que el servidor remoto responde con otro, el que sea, y te llega. Realmente se pueden enviar cualquier tipo de paquete en el que podamos "forzar" al destino a respondernos. SI lo hace podemos medir la latencia. Una herramienta muy útil para esto es nping:

Lo que le he dicho a nping es que envíe un paquete TCP al puerto 443 de google.es. ¿De 11ms que obtenemos con un ping, de pronto vemos que se ha disparado a 60ms de media? Obviamente, el 443 es el puerto del servidor Web, con lo que la carga que el propio servidor va a tener en ese puerto es muy superior, el paquete no está siendo contestado directamente por el kernel, sino por propio servidor Web al que se ha pasado. Si haces pruebas en tu red local, verás enormes diferencias si usas puertos como el 22, el 443... cada uno puede arrojar valores muy muy diferentes, incluso hacia el mismo destino.

Cuando realmente queremos ver el tiempo de respuesta por todo el trayecto, usamos por ende ping, porque es lo que menos sobrecarga va a llevar. Si queremos ver la respuesta específica de un servicio concreto de un servidor específico, sí podemos usar nping, pero teniendo en cuenta, y sabiendo interpretar realmente que nos está diciendo ese valor. Si lo envías por ejemplo al Router de Movistar al puerto 443, posiblemente te de un valor elevado, porque el servidor Web del Router pues da para lo que da... jajajajaja, pero esto no tiene que ver con los paquetes que circulan por él, sino los que se envía específicamente a él al servidor web. No sé si entiendes lo que digo, esto no tiene afectación alguna a tu tráfico.

Saludos.