Introducción
Dos visitantes de Grove informan de esperas al abrir información de Lantern Photography. La referencia normal y ambas visitas afectadas están grabadas en una captura. Determinarás si el intervalo largo aparece después de enviar una solicitud o antes de que aparezca la siguiente.
Debes conocer los filtros HTTP, Follow TCP Stream y los enlaces de solicitud/respuesta del laboratorio anterior. Este comienza en un entorno Desktop nuevo e independiente. Aprenderás referencias temporales y dos intervalos definidos con precisión; no hace falta programar ni reparar servidores. Estas grabaciones controladas permiten conclusiones sobre tiempos de paquetes, no sobre renderizado del navegador o CPU del servidor.
Medir una solicitud y su respuesta
En este paso medirás la primera transacción de detalles de Aspen. Comienza en Desktop, abre Applications → Terminal Emulator desde el menú inferior izquierdo y ejecuta Wireshark con la nueva entrada.
wireshark /home/labex/project/event-page/input/casebook.pcapng
Maximiza Wireshark. El servicio es 127.0.0.1:18182. Maple (127.0.0.5) es la referencia normal; Aspen (127.0.0.6) y Elm (127.0.0.7) son las visitas notificadas; Pine (127.0.0.8) no está relacionado. Cada visita solicita lista, detalles, programa y detalles otra vez en una conexión persistente. Persistente significa que permanece abierta durante varios intercambios de solicitud/respuesta.
Filtra los mensajes HTTP de Aspen:
ip.addr == 127.0.0.6 && http
Selecciona el primer GET de detalles. Expande HTTP y lee X-Request: aspen-02. Usa Response in frame → right-click → Go to Linked Packet para localizar su respuesta real y comprueba el enlace inverso Request in frame. Las tramas de entrada son solicitud 42 y respuesta 46.
En la respuesta busca Time since request. Haz clic derecho y elige Apply as Column. El valor ronda 1.6017 segundos. Un segundo son 1.000 milisegundos, por lo que equivale a unos 1601.7 ms.
Es el intervalo entre la trama de análisis HTTP de la solicitud y la de su respuesta correspondiente en esta grabación. Wireshark puede decodificar el mensaje completo en el último segmento de reensamblado. No lo llames tiempo de CPU del servidor, tiempo de carga del navegador ni tiempo hasta el primer byte de respuesta.
Comprueba visualmente el intervalo con una referencia temporal. Selecciona la trama 42 y elige Edit → Set/Unset Time Reference; en esta versión el atajo es Ctrl+T. En View → Time Display Format, selecciona Seconds Since Beginning of Capture. Este formato usa la referencia cuando hay una establecida. La solicitud se marca *REF* y actúa como cero; la respuesta aparece unos 1,6017 segundos después. Tras comparar, haz clic derecho en el paquete de referencia y usa el mismo comando para quitarla.
No uses Seconds Since Previous Captured Packet ni Previous Displayed Packet para este emparejamiento. Un vecino de la lista no tiene por qué ser la solicitud correspondiente. Cambiar el filtro también cambia el paquete anterior mostrado. Las referencias temporales no se guardan permanentemente en la captura: registra números de trama explícitos y el intervalo medido para que otro analista pueda reproducirlo.
Busca la siguiente solicitud de programa, aspen-03, en la trama 48. La pausa entre la respuesta de detalles 46 y la solicitud 48 ronda 0.3 ms. Establece la respuesta como referencia, lee el tiempo relativo de la solicitud de programa y quita la referencia. Esta pausa es la segunda métrica: el intervalo entre esas dos tramas de análisis concretas, no una medida general del tiempo de reflexión del usuario.
Aquí la trama 46 está marcada *REF*. Lee la columna Time de la trama 48: 0.000312566 segundos equivalen aproximadamente a 0.3 ms. La columna independiente Time since request de la trama 46 sigue describiendo su propio par de solicitud/respuesta; son intervalos diferentes.
Crea /home/labex/project/event-page/output/timing.csv con una segunda terminal de Desktop y Mousepad. Abre otra vez Applications → Terminal Emulator y ejecuta:
mousepad /home/labex/project/event-page/output/timing.csv
Las columnas identifican la visita, la primera solicitud de detalles, su respuesta, la siguiente solicitud de programa, ambos intervalos en milisegundos y la etapa observada. Usa after para un intervalo largo de solicitud a respuesta, before para una pausa larga antes de la siguiente solicitud y normal cuando ninguno sea largo. En estas grabaciones, un intervalo largo supera 800 ms: es un umbral didáctico, no un objetivo de producción. Se aceptan valores redondeados con un error máximo de 5 ms.
visit,request_frame,response_frame,next_request_frame,response_ms,gap_ms,stage
aspen,42,46,48,1601.7,0.3,after
Guarda con Ctrl+S. La evidencia sitúa la espera larga de Aspen después de su solicitud de detalles. No identifica la causa interna del servidor ni demuestra que todos los componentes de red funcionen bien.
Comparar la pausa y conservar la evidencia
En este paso compararás Elm y la visita normal Maple con Aspen, y conservarás las conversaciones completas requeridas. Comienza en Desktop, volviendo a Wireshark y a la entrada original. Quita cualquier referencia temporal antes de iniciar otra medición.
Filtra Elm:
ip.addr == 127.0.0.7 && http
Sigue la respuesta real de la primera solicitud de detalles mediante los enlaces HTTP. elm-02 corresponde a solicitud 74 y respuesta 78. Su intervalo de solicitud a respuesta ronda 0.3 ms. Busca la siguiente solicitud de programa, elm-03, en la trama 80. Establece la trama 78 como referencia; la 80 aparece unos 1.6012 segundos después. Quita la referencia al terminar.
El intervalo largo de Elm ocurre después de la respuesta anterior, pero antes de la siguiente solicitud. El registro de paquetes establece esa posición. No permite distinguir entre un temporizador del cliente, trabajo de aplicación o una persona que retrasa una acción. No lo clasifiques como fallo del frontend sin más pruebas.
Repite con Maple usando ip.addr == 127.0.0.5 && http. Su primera solicitud de detalles, su respuesta y su solicitud de programa son las tramas 12, 16 y 17. Ambos intervalos son inferiores a un milisegundo. Esta referencia normal muestra cómo puede ser la misma secuencia sin la espera prolongada.
Vuelve a Mousepad y sustituye la tabla por las tres visitas, conservando la fila de Aspen. Usa los números de trama de la entrada original y milisegundos:
visit,request_frame,response_frame,next_request_frame,response_ms,gap_ms,stage
maple,12,16,17,0.3,0.1,normal
aspen,42,46,48,1601.7,0.3,after
elm,74,78,80,0.3,1601.2,before
Guarda el archivo. Las dos visitas afectadas tienen una demora igualmente llamativa en posiciones distintas. La Duration total de una conexión no permite distinguirlas. Conservar solo la última solicitud de cada flujo tampoco emparejaría correctamente las solicitudes repetidas de detalles.
En Wireshark inspecciona una respuesta de programa. Su cuerpo HTTP es mayor y está dividido en segmentos TCP. Selecciona la respuesta e inspecciona Reassembled TCP y el título JSON completo Lantern Photography. El espacio en blanco final es relleno sintético de prácticas, no objetos JSON adicionales. El intervalo de las tramas de análisis incluye la finalización del mensaje; esto ilustra por qué no equivale automáticamente al tiempo del primer byte.
Conserva ahora las conexiones completas de Maple, Aspen y Elm. || significa que puede cumplirse cualquiera de las condiciones. Sustituye el filtro de visualización por:
ip.addr == 127.0.0.5 || ip.addr == 127.0.0.6 || ip.addr == 127.0.0.7
No añadas && http: la exportación también necesita los segmentos TCP anteriores. Elige File → Export Specified Packets, selecciona Displayed → All packets y guarda PCAPNG como /home/labex/project/event-page/output/evidence.pcapng. Excluye Pine. Si ya existe una salida, confirma únicamente la sustitución del archivo de salida de este curso, nunca la entrada original.
Abre la exportación y comprueba las tres visitas y sus respuestas completas. Los números de trama exportados pueden diferir; tu tabla hace referencia explícita a la entrada original. Si está incompleta, vuelve a abrir la entrada y repite la exportación de conexiones completas. Si un filtro nuevo no muestra filas, comprueba el archivo abierto y la dirección del cliente; borra el filtro para recuperar la lista.
La conclusión útil es precisa: el intervalo largo de Aspen sigue a una solicitud de detalles, mientras que el de Elm precede a su siguiente solicitud de programa. La transacción normal Maple queda conservada para comparar. No se cambió configuración del servidor ni se exige afirmar una causa interna más concreta.
Resumen
Usaste los enlaces de solicitudes, Time since request y las referencias temporales de Wireshark para comparar dos posiciones de espera distintas. Conservaste una referencia normal y conversaciones legibles de forma independiente. Tu conclusión localiza la espera observada sin atribuirle una causa interna de aplicación o red que no hayas observado.
