Ajustando opciones visuales

Dando por hecho que ya tenemos una captura de datos en condiciones (con conexiones a páginas web y descargas de algún fichero) desde una tarjeta conectada al exterior mediante un router, lo primero que hemos de averiguar es si realmente tenemos un problema con dicho periférico que impide que nuestra conexión a internet no sea todo lo fluída que debiera. Es interesante saber descartar desde un primer momento todo aquello que no nos vaya a hacer falta durante nuestro análisis y para lograr este propósito utilizaremos el cuadro Filter y sus diferentes opciones. Por ejemplo, usaremos el filtro tcp OR http OR dns, para quedarnos sólo con los paquetes relativos a las conexiones vía web.

Seguidamente deberemos adaptar la columna Time a nuestros intereses, que no son otros que determinar un posible problema de velocidad ocasionado por un router. Para ello, la columna del tiempo ha de representar el valor en relación al paquete anterior y no en relación al comienzo de la captura (valor por defecto). El cambio de los valores de esta columna lo hacemos a través del menú View/Time Display Format y, en nuestro caso, elegiremos la opción Seconds Since Previous Packet. Mediante la presentación del tiempo en este formato, podremos determinar de una forma más sencilla si existe un problema con la velocidad.

Periodo de latencia

Toda conexión a una página web comienza con algo muy parecido a lo siguiente:

Desde la dirección IP de máquina local (192.168.0.102) se realiza una petición al servidor DNS (80.58.61.254) en relación con la dirección requerida por el navegador (statse.webtrends.akadns.net), que es respondida desde el servidor DNS con una dirección IP o, en este caso, con un subdominio relativo(statse.webtrendslive.com) que habrá que traducir igualmente a la dirección IP final que interesa (63.236.111.50). Una situación típicamente anómala que podemos encontrarnos en esta transacción es la repetición de la petición al servidor DNS (Standard query A) varias veces antes de obtener la respuesta CNAME. La respuesta del servidor produciría una salida parecida a la siguiente:

Esta salida nos indica una respuesta fallida a una de las peticiones DNS realizadas por nuestra máquina. Como se han producido varias peticiones y una de ellas ya obtuvo respuesta, ahora llega el momento en el que la respuesta al resto de peticiones ya no tiene sentido. De ahí el ICMP Destination unreachable justo después de la respuesta del servidor DNS.

Una vez obtenida la dirección, la máquina cliente y el servidor comenzarán la negociación en tres pasos del protocolo TCP (SYN, SYN/ACK, ACK). En un escenario sin errores, dicha negociación ha de comenzar de forma inmediata una vez se ha obtenido la dirección correcta del servidor DNS. Observemos en nuestro caso como la respuesta al requerimiento anterior se produce cuatro milésimas (0.004164 segundos) después:

La respuesta SYN/ACK del servidor no debería exceder de un par de décimas de segundo en condiciones muy desfavorables, siendo un valor entre media y una décima lo habitual en condiciones normales. Una respuesta del servidor por encima de las tres décimas de segundo nos tiene que hacer pensar en que existe algún tipo de lastre que excede a la propia máquina cliente, sobre todo si ese retardo se produce de forma constante.

Pero no hemos de fijarnos únicamente en los tiempos de respuesta. Un indicio claro de que las cosas no van bien lo tendremos al analizar los paquetes con información TCP Retransmission y unos tiempos de respuesta demasiado altos.

Los paquetes TCP Retransmission se originan cuando el cliente no obtiene respuesta a un requerimiento y vuelve a realizar dicho requerimiento. En la imágen de ejemplo, se vuelve a solicitar la página raiz al servidor (GET / HTTP/1.1). La acumulación de paquetes de este tipo a lo largo de la captura y, lo más importante, el periodo de latencia entre estos requerimientos y la repuesta final del servidor sirven para hacernos una idea del alcance del problema. Cuando empezamos a ver periodos de latencia de más de dos o tres segundos, el problema empieza a ser ciertamente grave.

Acorralando al problema

Si estamos ante un problema de transmisión (por una lentitud exagerada) y ya hemos descartado que el fallo se esté originando en la máquina cliente (debemos probar la transmisión interna haciendo peticiones a un servidor local) o en el servidor remoto (como en el capítulo anterior, será necesario comprobar en varias ocasiones las repuestas de varios servidores), tendremos que comprobar el hardware al que está conectada nuestra máquina, desde la salida de nuestra tarjeta de red, pasando por el cable y terminando en los distintos dispositivos de distribución (routers, switches, ...). El método más eficaz para comprobar si nuestra situación tiene origen en nuestro hardware, a parte del típico reinicio de todos los componentes, es el cambio de dicha maquinaria por otra que haga la misma función. Si bien no suele haber problemas para realizar esta operación en redes empresariales, en un entorno más "casero" es probable que no tengamos acceso a este tipo de funcionalidad. Es entonces cuando deberemos hacer uso de todos los recursos a nuestro alcance: desde las pruebas de veocidad utilizando el software interno de los routers, hasta la conexión al exterior mediante módems u otros dispositivos que hagan que el problema quede delimitado en un componente concreto.

Si una vez terminadas las pruebas y las comprobaciones, llegamos a la conclusión de que nuestro hardware no es el culpable de la situación, deberemos seguir hacia arriba en la cadena de conexión, aunque aquí las limitaciones con las que nos vamos a encontrar serán más que evidentes, pues dichos componentes no suelen pertenecernos.

Filtrado de paquetes (Anexo)

Wireshark pone a nuestra disposición un potente sistema de filtrado de paquetes, accesible mediante la escritura en un cuadro de la parte superior izquierda llamado Filter.

El funcionamiento de este cuadro es muy sencillo. Para empezar todo lo escribamos en él vendrá precedido por defecto del operador is present. Es decir, que si queremos filtrar la salida sólo por las capturas del protocolo TCP, escribiremos tcp en el cuadro y pulsaremos el botón Apply. Los operadores disponibles para el filtrado son los siguientes:

is present Operador por defecto
eq, ==     Igual a
ne, !=     Distinto de
gt, >      Mayor que
lt, <      Menor que
ge, >=     Mayor o igual que
le, <=     Menor o igual que

Si, por ejemplo, queremos eliminar todas las capturas que tengan presente el protocolo ARP (Address Resolution Protocol), innecesario para los fines de este capítulo concreto, escribiremos !arp en el cuadro de filtrado.

Por último, tenemos a nuestra disposición dos operadores más que nos permitirán filtrar por una búsqueda concreta (contains) o por una coincidencia de expresión en Perl (match). Veamos un ejemplo de su uso:

http contains "http://www.wireshark.org";

Esta línea filtrará presentará en pantalla todo aquello que coincida con la dirección HTTP dada.

wsp.user_agent matches "(?i)cldc"

La línea anterior buscará un Agente WAP WSP concreto. El operador sólo funcionará en protocolos o campos de protocolo que se representen mediante una cadena de texto.

Por último, resaltar que podemos construir nuestro filtro a través de un pequeño asistente, accesible mediante el botón Expression. Dicho asistente nos presentará una ventana con todos los campos disponibles y los distintos operadores a usar. Para mayor información, es recomendable leerse la ayuda del programa en realación a los filtros.

Sólo los usuarios registrados pueden escribir comentarios.
Por favor, valídate o regístrate.

Powered by AkoComment 2.0!