Hace un par de días, Andrea publicó unos videos de su colección de Plan Z para compartirlos con unos amigos de la Universidad que eran tan fanáticos como ella de Peirano y compañía. Pues como era de esperarse en este mundo global aparecieron «amigos» por todas partes luego de ser publicada su dirección en los foros de «El Antro».

Esto provocó de inmediato un «efecto antro» (efecto slashdot, pero con download accelerator debajo del brazo) en que las malas costumbres de algunos comenzaron a afectar el buen cumplimiento de apache.

La primera solución fué aplicar traffic shaping con el siempre a mano Wondershaper. De forma fácil pude bajar el uso de ancho de banda de salida restringiendolo a solo un par de megas. Pero esto no soluciona el problema de las malas costumbres de los aceleradores de descargas, quienes realizan decenas de conexiones por cliente.

Como ya me esperaba que mas de alguno con malas costumbres accediera al sitio, había preparado la exlusión de algunos Referers y User Agents de forma de disminuir el trafico excesivo y brutal. Algo bastante simple en un htaccess puede hacer el trabajo, por ejemplo:

<br /> <ifmodule mod_rewrite.c><br /> RewriteCond %{HTTP_USER_AGENT} ^Wget.* [NC,OR]<br /> RewriteCond %{HTTP_USER_AGENT} ^DA.* [NC]<br /> RewriteRule ^.*$ - [F,L]<br /> </ifmodule><br />

Y Wget y Download Accelerator recibirán un error 403 Forbidden. Similar lógica se puede usar con otras variables como HTTP_REFERER. Obviamente estas variables se pueden falsificar. Fácilmente con un par de clicks un GetRight o DA puede hacerse pasar por IE o Mozilla disfrazando su user-agent como “Mozilla/4.0 (compatible; MSIE 5.00; Windows 98)” entre otros, por lo que no es una solución definitiva.

Pero como la gracia es compartir los videos y no restringir su bajada a todo el mundo poniendose idiota, la mejor solucion sería restringir equitativamente el uso de los recursos. Allí comencé a buscar en mis bookmarks sobre soluciones de manejo de throttling y bandwidth en apache y me tope con dos posibles.

Una posible solución es mod_bwshare, que posee una configuración de throttling por shaping estadístico por cliente. El problema es que debes tener muy bien planeado las tasas de transferencia y servicio de archivo por tiempo determinado, y como no sabía hasta que punto iba a llegar esto, al rato ya estaba denegando el 30% del tráfico.

Otra solución que tenía en mis archivos era bw_mod, un excelente software de Iván Barrera. Con él puedes controlar el ancho de banda consumido por cliente, red y total, además de controlar el número de conexiones por cliente. Con una lógica algo parecida a los delay pools de Squid cache es bastante fácil y rápido de implementar.

Esta era la solución que estaba buscando para esta situación particular. Controlar un pool de ancho de banda de subida, de forma de conservar banda para el resto de los servicios y por otra parte asegurar una de subida estable por cliente, agregando a ésta la posibilidad de restringir la cantidad de conexiones hechas por cada cliente causadas por los malditos y poco polite aceleradores de descargas. Si un cliente se conecta mas veces de lo permitido, recibirá un lindo error 503 (o el que se decida personalizar). Totalmente recomendado y kudos para Iván Barrera.

Y por supuesto para los siempre impacientes que no comprenden las indirectas, iptables -j DROP los espera al final del pasillo.