Perdida Paquetes CS2 y Faceit

Buenas mrk992 

Tus test de WinMTR no muestran ninguna pérdida de paquetes real, compañero. Es muy habitual mal interpretar una traza, donde el problema de base viene en entender como funciona un tracert a la hora de detectar pérdidas de paquetes reales.

En un ping/tracert, lo más importante es mirar siempre el salto final. Tan solo cuando en el salto final vemos datos "preocupantes", podemos trazar el problema, y es aquí donde un desglose completo es realmente importante. ¿Por qué? Porque la latencia, al igual que la pérdida de paquetes real, es acumulativa. Del mismo modo que la latencia va subiendo poco a poco con cada salto, una pérdida de paquetes reales, le sucede lo mismo.

En el salto final, copio y pego tu resultado, en negrita los valores importantes

| ns3108961.ip-54-37-254.eu - 0 | 2301 | 2301 | 28 | 30 | 46 | 30 |

Ese 0% implica 0% de pérdididas. De más de 2000 paquetes, que es una muestra bastante generosa, no se ha perdido uno solo. Y ojo, con 2000 paquetes, que se pierdiese alguno por el camino tampoco sería extremadamente raro, dado que es una muestra bastante amplia (por cierto, bien por tu parte, cuanto más grande sea la muestra, los resultados son más realistas debido a que se estabilizan las estadísticas).

Con la latencia, tenemos dos indicativos más importantes, el mejor paquete, y la media. La media nos sirve para saber la latencia media que tenemos en términos globales, mientras que la combinación del mejor y la media nos va a decir lo estable que es la conexión. Cuanto más cercano sea su valor entre ellos, más estable es la conexión, o lo que generalmente llamamos Jitter.  En tu caso, tenemos una latencia media final de 30ms, un resultado extremadamente bueno, y un jitter de solo 2ms (diferencia entre el mejor y la media), lo cual es un resultado igualmente excepcional.

Lo único que ese tracer nos indica es que tienes una conexión extremadamente estable hacia ese destino en particular, con una latencia muy buena, y sin ningún paquete perdido.

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

Bien,  como te lo estarás preguntado por qué entonces aparecen algunos saltos con supuestas pérdidas, te lo explico también. Sucede ni más ni menos por como funciona un tracert o un ping.

Ambas herramientas se basan en inducir a un nodo (o host final) a responder con un tipo de tráfico y protocolo especial, llamado ICMP. No son iguales, el PING hace uso del protocolo ICMP Echo request para "forzar" que el nodo que sea responda a su vez con un ICMP Echo Reply. Un tracert no es así, un tracert lo que hace es enviar paquetes con un tiempo de vida (TTL) que va aumentando de 0 a 1 por cada nodo que quiere descubrir, aprovechándose del comportamiento de que un paquete cuando pasa por un nodo/Router, decrece el TTL del paquete en 1, y si el valor llega a cero el paquete se descarta... generalmente devolviendo un paquete ICMP al origen de TTL sobrepasado. Es esto lo que se quiere inducir con un tracert, "obligar" a un nodo de red a que responda con un paquete ICMP, para descubrir la IP de origen de ese nodo.

Bien, el "problema", es que los nodos de red o incluso los host finales, no están obligados a responder con el tráfico ICMP pertinente. Por ahorro de ancho de banda o simplemente por configuración, los nodos de red o host finales pueden configurarse para no responder a este tipo de tráfico, o discriminar el tráfico. Los Tracert/ping asumen esa no respuesta como un paquete perdido, porque no han recibido respuesta. Pero no han recibido respuesta no porque se haya perdido, sino porque no contestan porque están configurados para no contestar, o contestar 1 de cada X.

Así por ejemplo, hay nodos como el 4 que dice que hay un 5% de pérdidas, u otros como el 8 que dice que hay un 100%.

Teniendo en cuenta todo esto, ¿como saber entonces si realmente existe una pérdida real o una discriminación del tráfico ICMP? Pues realmente muy sencillo. Si en el salto 4 existiese realmente una pérdida de un 5%, de 1986 llegan 1902 (se pierden 16 paquetes), en el salto 5 veríamos como poco una pérdida aproximada de 16 paquetes, porque se habrían ido en el salto anterior, y en salto 6 veríamos igualmente una pérdida aproximada de 16 paquetes también como poco. Es obvio, para llegar al salto 5, antes han tenido que pasar por el 4º. Y si en el 5 se perdiesen adicionalmente otros 10 paquetes, tanto en el 5 como en los siguientes veríamos aproximadamente unos 26, la suma de lo que se ha perdido en el 4 y en el 5. No?

Más absurdo aun, si en el salto 8 realmente existiese un 100% de pérdidas... ¿como podría alcanzar el tráfico el salto siguiente?

Es decir, imagínate una carrera de 100 corredores. En el primer tramo se caen 10 en un agujero... cuantos quedan en el segundo tramo? Pues como mucho unos 90!! O más absurdo aun, imagina que en el tramo cuarto absolutamente todos caen a un pozo!! ¿Pues si todos se han caído dentro, como diablos va a llegar alguien a la meta? Si alguien llega a la meta, o salieron más de 100 corredores, o no se contaron bien los que se cayeron al pozo, obviamente.

Aquí pasa lo mismo, simplemente la discriminación del tráfico ICMP de algunos nodos, hace que herramientas tipo ping/tracert vean en esos nodos paquetes perdidos, a pesar de que no es real 🙂

Si no te queda claro y quieres que te explique algo mejor cualquier punto, estaré encantado.

Saludos.