Análisis Palm
Análisis Windows MobileMiércoles, 11 de Noviembre de 2009
Cómo reducir el consumo de ancho de banda de tu Web a la mitad
Una página Web es, como muchas cosas en esta vida, algo sencillo de crear, pero difícil de mantener. Para evitar desagradables sorpresas, y conseguir que todo vaya razonablemente bien, es recomendable llevar un control periódico de los parámetros básicos, tales como páginas servidas, ancho de banda consumido, actividad de los web spiders (por ejemplo el de Google), etc.
Una herramienta que me ha resultado bastante fiable para controlar algunos de estos parámetros es Awstats. Se trata de un script que analiza los ficheros de log del servidor Web de nuestra página, para generar una serie de páginas con tablas y gráficas resumen de gran cantidad de parámetros. Podéis verlo en funcionamiento en esta demo. Para rizar el rizo, se puede instalar también Jawstats, un frontend que recoge los datos que ha recopilado Awstats y los muestra en una Web mucho más dinámica y agradable. También hay una demo disponible de Jawstats.
Jawstats muestra de manera atractiva información sobre nuestra Web
Lo que hoy quiero contaros es cómo, a partir de los datos de Awstats, conseguí reducir el ancho de banda consumido por la PDA de tungsteno en nada menos que un 66%. Revisando la pestaña de “spiders” descubrí que uno de ellos estaba consumiendo cientos de veces más ancho de banda que los demás, con un consumo de casi 2Gb diarios. Esto supone 60Gb al mes, lo cual puede arruinar a más de un webmaster que tenga su sitio alojado en un hosting que cobre según el ancho de banda consumido.
Además el spider aparece en la lista como “no _user_agent”. Revisando esta vez Awstats recibo una descripción algo más clara de este spider: “Unknown robot (identified by empty user agent string)”. Está claro que el spider se está identificando con una cadena vacía. Revisando los ficheros de log de mi hosting (concretamente el access.log del Apache) veo que corresponde con entradas como ésta:
X.X.X.X - - [01/Nov/2009:04:53:02 -0800] "GET /wp-content/imagenes/bluetooth-carwhisperer.jpg HTTP/1.0" 200 28567 "-" "-"
Mientras que una entrada correspondiente a un spider normal sí que identifica el user agent:
X.X.X.X - - [01/Nov/2009:01:33:54 -0700] "GET /de/2006/05/13/pagina-interesante-acerca-de-la-palm-tx/ HTTP/1.1" 200 16060 "-"
"Baiduspider+(+http://www.baidu.com/search/spider.htm)"
Buscando por la red ví que este spider “anónimo” estaba creando problemas a muchos otros webmasters, además de no porporcionar en principio ningún servicio, al menos legal. Así que lo que tenía que hacer era rechazar las visitas de este tipo. Para ello, si usamos Apache como servdor Web, no hay más que editar el archivo .htaccess de la carpeta raíz de nuestra Web, y añadir las siguientes líneas:
#Unknown robot (identified by empty user agent string)
RewriteCond %{REQUEST_METHOD} !^HEAD$
RewriteCond %{REQUEST_URI} !^.*robots\.txt$
RewriteCond %{REQUEST_URI} !/favicon\.ico$
RewriteCond %{HTTP_REFERER} ^$ [NC]
RewriteCond %{HTTP_USER_AGENT} ^$ [NC]
RewriteCond %{HTTP_REFERER} ^-?$ [NC]
RewriteCond %{HTTP_USER_AGENT} ^-?$ [NC]
RewriteRule .* - [F]
Las líneas “RewriteCond” definen las condiciones para que la regla aplique, la línea “RewriteRule” es la que realmente deniega el acceso si éstas aplican. Las tres primeras condiciones excluyen algunas peticiones lícitas, y las cuatro últimas son las que identifican las que se realizan con user-agent vacío o sólo el carácter guión.
El resultado, tras unos días de prueba, es que este spider indeseado ha dejado de acceder completamente a la Web, y el ancho de banda diario ha caído enormemente, contrastado tanto en el Jawstats como en los datos proporcionados por mi hosting.
Así que si estáis teniendo un consumo inusual de ancho de banda en vuestra web, desde hace unos meses, revisad la actividad de los spiders.
Por: Marcos González Troyas en General
RSS comentarios | Trackback | 
Imprimir este post
| Compártelo: |           |
General
Aunque en principio pareciera ser una buena idea lo que haces, en realidad no es muy conveniente en una serie de casos. Esto es debido a que hay muchas herramientas y websites (mal construídas), que no detallan el user agent al momento de acceder a tu website, y por lo tanto, con esta regla los bloqueas completamente. Por ello sería bueno que verifiques a quien / quienes estás bloqueando, y ver de darle acceso a quienes consideres que deban tenerlo. La otra opción es identificar quien o quienes son los ips desde donde te estaban atacando el site, y bloquearlos directamente…
Efectivamente, aunque como primera medida de contención este método es efectivo, ahora viene la parte dura de análisis, intentando localizar las IPs principales de este abuso, para crear una regla más precisa que no haga pagar a justos por pecadores.