Cómo leer la pérdida de paquetes antes de culpar al cable

Una pérdida del dos por ciento a lo largo de una tanda larga de ping parece una cifra sobre la que se puede actuar, y rara vez lo es. No dice dónde desaparecieron las respuestas, si desaparecieron juntas ni cómo vivió ese intervalo una aplicación concreta. Una pérdida repartida por igual a lo largo de un minuto y una pérdida agrupada dentro de un solo intercambio producen resultados muy distintos para el mismo porcentaje.

Compare tres medidas en lugar de confiar en una: lo que vio la sonda, lo que hicieron los contadores de la interfaz y lo que la aplicación esperó en realidad.

Qué mide realmente un porcentaje de ping

Una sonda de eco prueba una dirección de un protocolo con un tamaño de paquete, al ritmo que usted haya elegido. Un túnel que transporta una subida grande hace algo completamente distinto, y un enlace que descarta sondas pequeñas no es necesariamente el enlace que está dañando la transferencia. El porcentaje además aplasta la información de tiempo que más importa, porque diez respuestas perdidas en una ráfaga no son lo mismo que diez respuestas perdidas con una hora de separación. Tampoco puede decirle qué lado del túnel descartó algo.

Conserve el resultado de la sonda como una pista sobre la ruta. Después busque el momento y el límite que lo produjeron.

Compare diferencias de contadores, no totales de por vida

Tome lecturas con marca de tiempo antes y después de la ventana en la que apareció el síntoma, en ambos extremos y en cualquier puerto de conmutador que controle. Registre el volumen de tráfico junto con errores, descartes y cambios de estado del enlace, porque un total distinto de cero acumulado durante meses describe historia, no este incidente. Un contador que se movió en tres durante la pausa es una observación distinta de un contador que marca tres mil y nunca cambió.

ip -s link show dev eth0
nstat -az TcpRetransSegs TcpExtTCPTimeouts
date -u +%Y-%m-%dT%H:%M:%SZ

Los paquetes descartados por errores de recepción y los paquetes descartados por otros motivos viven en contadores separados, y esa distinción cambia el seguimiento. Los contadores de errores apuntan a la capa física o de controlador, mientras que la presión de colas y los descartes por política apuntan a algún lugar por encima. Conserve también la dirección y el nombre de la interfaz, porque un aumento de errores de recepción en un enlace ascendente y un contador de paquetes de túnel no son intercambiables.

Si un controlador expone contadores físicos detallados, léalos con la documentación de ese adaptador. Asignar un solo significado a cada campo llamado “drop” en dos fabricantes es como una peculiaridad contable normal se convierte en un diagnóstico de hardware.

Cómo un segmento perdido se convierte en una espera larga

Una aplicación puede esperar mucho más que un solo viaje de ida y vuelta después de perder un segmento. TCP estima el tiempo de ida y vuelta, calcula un temporizador de retransmisión a partir de esa estimación y retrocede cuando una retransmisión también falla, así que un solo segmento perdido en el momento equivocado puede detener una petición durante un intervalo notable. Ese mecanismo se especifica en RFC 6298, y explica por qué una tasa de pérdida que parece trivial todavía puede sentirse.

Sin embargo, no toda pausa es un tiempo de espera de retransmisión. La misma espera puede venir de la resolución de nombres, un servidor lento o una aplicación que reintenta su propia petición tras un fallo. Separe esos casos alineando la operación fallida con las observaciones de transporte y con los eventos de sesión del propio túnel. Una interrupción en la ruta de datos sin reconexión es un evento distinto de un apretón de manos nuevo y un intercambio de credenciales.

Donde la captura esté permitida, manténgala estrecha. Lo que necesita saber es si los paquetes o acuses de recibo esperados se detienen en un límite concreto, no el hecho de que exista alguna retransmisión en algún lugar de una traza ocupada.

Cambie un límite sin mover los demás

Si las pruebas apuntan a un enlace local, sustituya un cable o puerto aprobado como comparación controlada y deje todo lo demás en paz. Mantenga el extremo, la aplicación y la carga de trabajo comparables, y cambie exactamente un límite por intento. Comparar un portátil con cable con uno inalámbrico mientras también cambia salidas y protocolos no le dice nada que pueda atribuir.

Los contadores locales limpios no certifican el resto de la ruta. Limitan la parte que usted ve, y el informe honesto dice qué límites se observaron y cuáles no. Lo que quiere al final es una afirmación de que una observación cambió cuando ocurrió una intervención, no una anécdota sobre un cable malo elevada a regla universal.