Lag en juegos, teletrabajo, etc

Buenas printertale 

Precisamente lo que hacen este tipo de herramientas es medir el retraso que se va acumulando por cada tramo por los que pasan. De existir cualquier acumulación de retraso en cualquier segmento, estas herramientas lo detectan. Expuse el ejemplo de una carrera porque ilustra relativamente bien todo esto.

Tomemos 10 corredores que tienen que pasar por 10 puntos de control antes de llegar a la meta, y van saliendo uno a uno cronometrando el tiempo en cada punto de control y en la llegada. Cuando todos han llegado, se reúnen los 10 que controlaban los tiempos en cada punto.

El que estaba en la meta mide un tiempo medio de 100, y cuenta que han llegado 10 corredores. Este, el de la meta, no está valorando en que tramo han corrido más o menos, su función es simplemente que han llegado todos y el tiempo estimado.

Este es el dato fundamental con independencia de lo que pasase en medio o los datos que tengan recogido sus otros 9 compañeros. Y por física básica sabe igualmente que los 10 corredores han pasado previamente por los 9 puntos de control, o no estarían allí... no se pueden teletransportar.

Si los datos de la meta son correctos, por lo general importa bien poco en que parte del camino han corrido algo más rápido o más lentos... como si se han caído en algún momento en un tramo y han tenido que correr enormemente más rápido en otro. Es decir, si cuenta que han llegado los 10 que salieron, y el tiempo que han tardado es lo razonable.

Entonces para que están los otros puntos de control, o para que importan?? Importan si los resultados no son adecuados.Por qué?? Bueno, es obvio, si en la meta cuentan sólo 9 corredores, gracias a los puntos de control pueden saber desde que tramo dejaron de pasar los 10, y por ende saber el tramo donde uno de ellos abandonó la carrera, por ejemplo. Porque si uno abandona en el segundo tramo, en el primer punto de control seguirán siendo 10, pero ya en el siguiente contarán 9, y en el siguiente obviamente otros 9 si no ha abandonado ningún otro.

Según cuentas, dices que realmente no parece que haya un "abandono", y simplemente es que llegan tarde y luego se apelotonan en la meta. Sí, claro que podría pasar, pero es que ese escenario es precisamente otros de los que se pueden observar, ya que recordemos estamos midiendo el tiempo en la meta y en los puntos anteriores. Pero para que esto ocurra tendrían que darse dos supuestos que en tus pruebas no se dan:

1º. El tiempo medio en la meta tendría que ser mucho más alto, obviamente. Da igual que se apelotonen en el último tramo porque han ido más rápido, el tiempo medido final es el tiempo medido final.

2º. Dado que cada punto de control mide su propio registro, es muy sencillo ver más o menos el tiempo invertido en cada tramo. Si en un tramo empiezan a tropezarse o porque el suelo está enfangado, al pasar por ese punto de control con respecto al anterior o los siguientes, se verá un tiempo mayor. De echo esto es lo normal, siempre hay nodos o puntos en los que la latencia entre ellos es mínima y otros en las que es muy alta. Por eso es tan importante partir del tiempo del destino, de la meta.

Como creo que ya he dicho, no tienes por qué creerlo, simplemente te digo como funciona un Ping/Tracert y como circula el tráfico desde un origen a un destino en Internet. Es más, te invito a que busques información en Internet sobre ello para que veas como funcionan, que implican, el motivo por el cual un nodo puede exhibir un % porcentaje en paquetes perdidos que no son reales... etc etc etc.

Con respecto a nodos que dices que no aparecen en mis tracert, es básicamente por rutas dinámicas y destinos diferentes constantemente, simplemente lancé dos o tres pruebas rápidas a los primeros dominios que se me pasaron, pero eso no significa que gran parte de mi trafico no circule igualmente por dichos nodos... bueno, los mismos mismos probablemente no por geografía, hora, día, destino... te ponía los otros para que vieses que, efectivamente, daba exactamente igual que un nodo pusiese 100%, 50%, 3%... si en el destino final pone 0% son 0%, exactamente por la misma analogía de la carrera anteriormente descrita.

Dicho de otro modo... tenemos la certeza absoluta que salen 10 y llegan 10. Ahora llega el del punto de control 2 y dice que el solo ha contado a 1 por ahí... en el punto de control 2 dice que han llegado 4, el punto de control 6 dice que han pasado por allí los 10, y el punto final dice que son 10. ¿Cual es la verdad? Pues hay cosas que podemos asegurar y otras que no. Sabemos al 100%:

1. Han salido 10. De echo los paquetes los lanza tu propio equipo, el sabe perfectamente que ha lanzado 10, no 9 ni 8, sino 10.

2. Aunque en la analogía anterior hablo de una meta, los tracert/ping realmente la meta es el propio punto de origen... cuenta los paquetes que envía, y las respuesta que obtiene de cada uno de ellos. Si no obtiene respuesta de uno de ellos lo da por perdido. Así que por el mismo punto primero, si cuenta que han llegado 10 respuestas, han llegado 10 respuestas.

3. También podemos asegurar que los paquetes ni se dividen ni se clonan en mitad de camino. Es decir que si quedan 8 siguen quedando 8, no pasan a ser de forma milagrosa 9 o 10.

Si tenemos en cuenta todo ello, asumimos como es lógico que los puntos intermedios, algunos de ellos han contado mal... en la analogía de la carrera.

Dentro de Internet es aun más sencillo, porque los propios protocolos usados y la configuración tanto de Router, nodos intermedios, puntos finales... se suele discriminar el tráfico ICMP, o dicho de otro modo, es como si de antemano supieses que los puntos de control intermedio que pones en la carrera tienen el movil a mano y claro... pueden pillarles haciendo una foto o distraídos en un momento dado, y no contabilizarlo de forma correcta.

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

La explicación por la que algunos nodos discriminan el tráfico ICMP o no, creo que ya la he dado. Por lo general es por una cuestión tan sencilla de ahorro de ancho de banda par evitar el uso de estas herramientas. En algunos casos, cuando vemos claramente un 100% en un nodo intermedio, es un bloqueo completo. Bueno, no es un bloqueo realmente porque no se bloquea nada, lo que hacen es no responder simplemente al origen, y al no responder, el origen estima que se ha perdido su paquete. Pero este valor puede ser cualquier otro número arbitrario, puede ser un 1%, un 10%, un 50%, un 99%... la única diferencia es el % de paquetes que discrimina el nodo.

El ejemplo más simple que tienes es tu propio Router. Tu propio Router está configurado para discriminar el tráfico ICMP. Captura del Firewall de un Router, esto es habitual encontrarlo en casi cualquier Router doméstico:

Por ejemplo, en este caso, el último DROP hace que mi Router bloquee el 100% de cualquier PING. Es decir, que si mi equipo hace de destino y alguien intenta hacerle un WinMTR por ejemplo, le dirá que mi equipo/Router está caído y tendrá un 100% de pérdidas. Ahora imaginemos que esa regla los permite y acepta. Vale, miremos la anterior por abajo, que vemos a la derecha "icmptype 8 limit: avg 1/sec burst 5"

Esa instrucción lo que hace es limitar los ping. No hace un bloqueo de 100%, es un bloqueo parcial. Entender como funciona en iptables esto igual sería extenderse bastante más por lo que implica el Burst 5, pero vamos digamos que con esa regla en el Firewall y quitando el DROP mencionado de la última, si alguien intentase usar una herramienta como WinMTR, dependiendo de la velocidad de envío empezaría a bloquear paquetes. El Burst 5 garantizaría los primeros 5, esos llegarían si o sí independientemente del tiempo de espaciado entre ellos. Pero a partir de ahí el sistema tan solo permitiría un ping por segundo, bloqueando cualquier otro. Desde el punto de vista de quien lanza WinMTR, le podría aparecer un % diferente. Repito que lo anterior no es exactamente como funciona Burst, pero par facilitar la lectura digamos que es así.

Bien, esto ocurre constantemente en tu propio Router, en el mío, en el de cualquiera (no es del todo cierto porque realmente no todos aplican estas restricciones básicas, pero es habitual). En un servidor final o un nodo intermedio es en esencia similar... solo que hay una enorme diferencia. En el ejemplo anterior se da por sentado que tan solo hay una persona que está realizando un ping/tracert. Un nodo final o servidor final los recibe constantemente!! Es decir, que dicho límite no solo lo disparas tú, sino que se está activando por cualquiera que en ese momento esté enviando paquetes similares a ese nodo/destino.

Ejemplo de esto... pongamos que un nodo tiene algo similar establecido. Si envías un ping por segundo de media, en principio NUNCA vas a disparar la protección. WinMTR usa por defecto 1 segundo entre cada prueba.... verdad?? FALSO!! Tú lo estás bombardeando solo con 1 por segundo, pero no sabes cuantas otras peticiones más está teniendo. Si en ese momento no existiese nadie mas en toda la red... tendrías 0% paquetes perdido. Si en la red existiese otra persona y con la misma cadencia, probablemente se te iría a un 50% de pérdida de media (si los tiempos fuesen perfectos), porque para el nodo/servidor ha alcanzado el límite de 1/seg.

Así es como funcionan estos "límites". Dependiendo de como configuren su Firewall/reglas para tratar este tráfico, podemos ver cosas tan dispares como un 0%, un 5%, un 50%, un 99% o un 100%. Piensa que además todo el ejemplo anterior es únicamente con una sola regla en iptables y muy concreta, en mi caso es avg 1/sec Burst 5, pero esos valores pueden configurarse como uno quiera, bloqueando más o menos en función. Y por supuesto, podemos quitar dicha regla también. Si la quitamos, el servidor/nodo responderá el 100% de peticiones, es decir, tendremos un 0% siempre de paquetes perdidos.

Todo ello afecta únicamente al tráfico ICMP, no al tráfico real. No podemos saber como se ve afectado el tráfico real en tránsito, porque no podemos inducir a los nodos intermedios a que nos respondan, ni siquiera la servidor final. Por eso estas herramientas son esenciales... pero tan solo para diagnosticar problemas de transmisión, no de procesamiento. Si se sabe usar e interpretar correctamente WinMTR u otro tipo de herramientas similares, podemos saber generalmente si existe cualquier tipo de problema en tránsito, sin importar si algún nodo intermedio bloquea de forma completa o parcial las respuestas ICMP.

-----------

Para terminar, lo que dices de manipulación de tráfico potencial por parte de Movistar, vamos a separar las cosas. LaLiga puede amenazar lo que quiera y con lo que quiera. Pero quien ordena un bloqueo es la justicia. Es más, y es noticia estos días, si queda demostrado que efectivamente el problema de acceso a Cloudflare era por bloqueo, este bloqueo no es porque Movistar lo haya impuesto por que le haya dado la gana, sino porque ha existido una orden judicial a los ISP para bloquear el acceso a ciertos servicios.

Cuestión muy diferente es las medidas que cada ISP aplica para bloquear el acceso a dicho servicios. Según se está viendo, algunos ISP lo han realizado por DNS, otros por IP. El juez es cierto que por lo general no impone como se debe de realizar estos bloqueos, simplemente ordena a los ISP que se bloquee. Ya ha habido muchos problemas al respecto de esto y de como cada uno lo implementa, y es posible incluso que por el modo que Movistar lo ha bloqueado le pueda caer un buen paquete, ya veremos. Ahora bien, lo que decía en el hilo de CloudFlare, no es una conspiración ni gaitas, en caso de que se confirme es un mandato judicial que lo ha ordenado, no que le haya dado la gana a Movistar hacerlo.


Saludos.