Microsoft Fiddler HTTP Debugger

lun 16/04/2007, Javier Ruiz Jiménez

Fiddler (violín) es un proxy HTTP (intermediario) que captura las solicitudes realizadas por el navegador y permite inspeccionar en detalle la comunicación con el servidor web.  (Leer introducción al artículo: Cómo analizar, optimizar y mejorar la velocidad de carga de un sitio Web).

Descarga del Software

Para comenzar las pruebas debemos descargar el software desde la página http://www.fiddlertool.com/fiddler/ e instalarlo. Es posible que nos pida instalar Microsoft .NET Framework v1.1 si no lo hemos instalado previamente.

Eliminación de la caché del navegador

Para realizar las pruebas simularemos que es la primera vez que accedemos al sitio web o la aplicación que vamos a probar, para ello eliminaremos la caché del navegador.

La caché del navegador se elimina en el menú herramientas del navegador, opciones de Internet, Historial de Exploración, eliminar, eliminar archivos temporales de Internet.

Ejecución de las pruebas

Cerrar el navegador y volverlo a abrir. Pulsar sobre el icono de fiddler.

Comprobaremos que el navegador ahora navega a través de un Proxy. Ir al menú herramientas del navegador, opciones de Internet, Conexiones, Configuración de la LAN, Servidor proxy.

Configuración del Proxy en Internet Explorer 7

En Servidor Proxy debe aparecer la IP 127.0.0.1 y el puerto 8888. En el caso de Internet Explorer 7 sobre Windows Vista es necesario cambiar esta dirección y poner el nombre de la máquina.

El entorno de trabajo

Fiddler

El panel izquierdo muestra las peticiones realizadas por el navegador, la parte derecha permite consultar los detalles de cada solicitud.

Ahora pulsamos sobre la pestaña Session Inspector para comenzar las pruebas. Es posible que ya aparezcan algunas solicitudes en la parte izquierda.

Realicemos la primera prueba visitando la web de Google. http://www.google.com/webhp

Listado de peticiones HTTP

En Fiddler aparecen 4 peticiones al servidor. Para examinar una petición la seleccionamos y consultamos los detalles a la derecha.

La primera petición es el contenido HTML de la página y es la que indica al navegador que debe descargar tres recursos adicionales, en este caso tres imágenes.

Google recibe muchas visitas al día y ha optimizado su página inicial al máximo, por ejemplo incluyendo los estilos CSS dentro del HTML o comprimiendo la comunicación.

Petición al servidor

El panel derecho está dividido en dos partes, la petición del navegador al servidor y la respuesta del servidor al navegador. Fiddler nos indica que la respuesta recibida está codificada y debemos pulsar dos veces con el ratón para descodificarla.

Analisis de la primera petición del navegador

GET /webhp HTTP/1.1
Accept: */*
Accept-Language: es-es
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; .NET CLR 1.1.4322)
Host: www.google.com
Proxy-Connection: Keep-Alive
Pragma: no-cache
Cookie: PREF=ID=12d6d9d8a4d4e5de:TB=2:LD=en:CR=2:....

 

GET /webhp HTTP/1.1

Indica que solicitamos el recurso webhp utilizando el protocolo http/1.1. Indica que se utiliza la versión 1.1 del protocolo http.

La versión http 1.1. incluye mejoras en los siguientes apartados:
• Cache (age, max-age, Etag, Cache-Control)
• Compresión entre servidores intermedios (Transfer-Encoding)
• Optimización de ancho de banda (petición de rango, continuación y parada, conexión persistente, entubamiento)
• Transmisión de mensajes sin conocer el tamaño previo
• Host header para la conservación de direcciones IP
• Notificación de errores
• Seguridad, Integridad y Autenticación
• Negociación de contenido (idioma, tipo de contenido, encapsulación, …)

Las siguientes cabeceras o headers hacen uso de las mejoras introducidas por http 1.1.

Accept: */*

Indica que el navegador o agente aceptará cualquier tipo de contenido (texto, imagen, audio, fichero comprimido, xml…)

Accept-Language: es-es

Las cabeceras anteriores se utilizan para negociar el tipo de contenido que el navegador desea recibir.

UA-CPU: x86

Es una cabecera propia de Internet Explorer 7 que indica el tipo de CPU del dispositivo. Se puede utilizar en el lado del servidor (Server side) para ofrecer recursos específicos para el tipo de CPU, por ejemplo ejecutables.

Accept-Encoding: gzip, deflate

Indica que el navegador solicita contenido comprimido en formato gzip y que es capaz de descomprimirlo.

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; .NET CLR 1.1.4322)

Esta cabecera identifica el agente que realiza la solicitud, en este caso se trata de Internet Explorer 7 (MSIE 7.0) con algunos extras (.NET). El nombre Mozilla en realidad corresponde al utilizado por Netscape y su uso en Internet Explorer se ha mantenido por razones históricas.

Originalmente esta cabecera se usaba para servir el contenido más apropiado a cada dispositivo, excluir ciertos programas de descarga masiva e identificar en el análisis de logs las visitas de los buscadores y el tipo de navegadores utilizados por los visitantes al sitio web. Actualmente el uso de esta información se debe hacer con precaución pues muchos agentes permiten cambiar el identificador para tomar otra personalidad.

Host: www.google.com

El host header indica al servidor el nombre de la máquina de la cual se solicita el recurso. Esta cabecera permite que una dirección IP sea utilizada por más de un nombre de máquina y que al llegar la petición al servidor pueda distinguir de qué máquina y dominio se trata. En el caso de los proveedores de alojamiento masivo es habitual que una sola dirección IP sirva miles de dominios, así mismo se utiliza para equilibradores de carga y configuraciones de alta disponibilidad.

Esta cabecera permite la conservación de direcciones IP

Proxy-Connection: Keep-Alive

Indica al Proxy que la comunicación se mantiene abierta, aunque en http 1.1 este es el comportamiento por defecto.

Pragma: no-cache

Se trata de una directiva http 1.0 que se mantiene por compatibilidad pues el agente no sabe si el servidor al que está solicitando la página implementa el protocolo en su versión 1.0 o en la 1.1.
Indica a todos los servidores en el camino que incluso si disponen de una copia en caché deberán contactar con el servidor origen y solicitar la página de nuevo. Es decir se solicita explícitamente una página fresca. Es equivalente a "Cache-Control: no-cache" en HTTP/1.1.

Cookie: PREF=ID=12d6d9d8a4d4e5de:TB=2:LD=en:CR=2:....

Al realizar una petición a un servidor el navegador comprueba si tiene cookies de anteriores visitas y las envía junto con la petición. Las cookies sirven para almacenar información en el lado del cliente e identificar al usuario durante la sesión (http es un protocolo sin sesión). En este caso indica que en una anterior visita a Google el navegador recibió una cookie que incluye información para identificar posteriores visitas.

Respuesta del Servidor

Analisis de la primera respuesta del servidor

Estas son las cabeceras enviadas por el servidor al navegador como respuesta a la primera petición:

HTTP/1.1 200 OK
Cache-Control: private
Date: Sun, 08 Apr 2007 20:14:53 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 5230
X-TR: 1
Server: GWS/2.1

 

HTTP/1.1 200 OK

El servidor indica que la petición es correcta y el contenido devuelto es el solicitado. Al tratarse de una petición GET el recurso solicitado se devuelve en la respuesta.

Cache-Control: private

Indica que ninguno de los servidores intermedios que actúen como caché pública debe utilizar esta respuesta para responder a otras peticiones del mismo recurso. Sin embargo las caches privadas, como la del navegador del usuario, si pueden cachear la respuesta.

Esta cabecera no indica que la información transmitida sea privada o se transmita de forma segura para garantizar su privacidad.
Otros valores para Cache-Control son: public, no-cache, no-store, no-transform, must-revalidate, proxy-revalidate, max-age, s-maxage

Date: Sun, 08 Apr 2007 20:14:53 GMT

Indica la fecha y hora en la que el servidor respondió a la petición. Se supone que tanto el servidor como los intermediarios y el cliente tienen la hora actualizada y no existe desfase, sin embargo multitud de servidores no están correctamente sincronizados y envían información errónea.

Content-Type: text/html; charset=UTF-8

Indica al navegador que el contenido devuelto es del tipo texto Html codificado en UTF-8.

Muchos usuarios de Windows piensan que el navegador sabe el tipo de recurso que está abriendo al examinar la extensión que aparece después del nombre, así por ejemplo imagen.gif sería del tipo GIF. En realidad el navegador no usa la extensión cuando se comunica con un servidor utilizando en su lugar el Content-Type.

Nota: El servidor si examina la extensión para asignar un Content-Type correcto en el caso de recursos estáticos. Esta cabecera permite que un recurso pueda ser generado de forma dinámica por un script de servidor y el cliente pueda abrirlo correctamente.

Content-Length: 5230

Indica el tamaño de la respuesta en Bytes. En contenidos generados dinámicamente no siempre es posible conocer el tamaño, en otros casos no es conveniente pues obligaría a retener la respuesta hasta que esté completa en un buffer.

X-TR: 1

Es una cabecera enviada por los servidores de Google y no tiene significado especial para los navegadores.

Server: GWS/2.1

Es una cabecera enviada por los servidores de Google que indica que el servidor utiliza el Google Web Server Versión 2.1.

Análisis de las siguientes peticiones

Hemos visto como interpretar las cabeceras de la comunicación http, veamos ahora qué implica para una aplicación. Durante la primera visita a la página de Google descargamos una página HTML y tres imágenes. Fiddler nos indica en la primera pestaña las estadísticas sobre el tipo de recursos y su tamaño:

Request Count: 4
Bytes Sent: 3.025
Bytes Received: 18.836

RESPONSE CODES
--------------
HTTP/200: 4

RESPONSE BYTES (by Content-Type)
--------------
image/png: 7.226
text/html: 2.169
image/gif: 8.641
~headers: 800

 

Las imágenes suponen el 88% del tráfico generado. Veamos lo que sucede si visitamos de nuevo la página de Google.

El navegador sólo ha pedido la página HTML, las imágenes no se han solicitado de nuevo. 

Segunda petición al servidor

En la segunda visita el ahorro es de 16 KBytes. No es una cantidad muy alta, pero si lo multiplicamos por el número de visitas a la web de Google podemos hablar de millones de Bytes ahorrados,  una mejora sustancial en el tiempo de carga para los usuarios recurrentes y un ahorro de costes muy importante.