Revista INGE CUC,Volumen 8, Nmero 1, Octubre de 2012, pp.

149-162

Servidor Proxy Cach:

Comprensin y asimilacin tecnolgica 1

Artculo de Investigacin - Fecha de recepcin: 1 de agosto de 2012 - Fecha de aceptacin: 6 de septiembre de 2012

Carlos E. Gmez
Magster en Ingeniera en Sistemas y Computacin, Licenciado en Matemticas y Computacin, Universidad del Quindo. Armenia,
Colombia, carloseg@grid.edu.co

Luis E. Seplveda
Ingeniero de Sistemas y Computacin, Magster en Software Libre, Universidad del Quindo. Armenia, Colombia,
lesepulveda@grid.edu.co

Christian A. Candela
Ingeniero de Sistemas y Computacin, Magster en Comercio Electrnico, Universidad del Quindo. Armenia, Colombia,
christiancandela@grid.edu.co

Resumen
Los proveedores de acceso a Internet usualmente incluyen el concepto de aceleradores de
Internet para reducir el tiempo promedio que tarda un navegador en obtener los archivos
solicitados. Para los administradores del sistema es difcil elegir la configuracin del servidor
proxy cach, ya que es necesario decidir los valores que se deben usar en diferentes variables.
En este artculo se presenta la forma como se abord el proceso de comprensin y asimilacin
tecnolgica del servicio de proxy cach, un servicio de alto impacto organizacional. Adems,
este artculo es producto del proyecto de investigacin Anlisis de configuraciones de ser-
vidores proxy cach, en el cual se estudiaron aspectos relevantes del rendimiento de Squid
como servidor proxy cach.

Palabras clave
Proxy server, proxy cach server, proxy cach, cach web, Squid.

1. Artculo derivado del proyecto de investigacin: Anlisis de configuraciones de servidores proxy cach, del Grupo de
Investigacin en Redes, Informacin y Distribucin - GRID, Universidad del Quindo, 2011.

149
 Servidor Proxy Cach: Comprensin y asimilacin tecnolgica

Web Proxy Caching:

Understanding and technological assimilation
Abstract
Internet Service Providers (ISPs) usually include the concept of internet accelerators to re-
duce browsers response time for obtaining requested files. For systems administrators is
difficult to choose the proxy cache server configuration, considering that it is necessary to
decide the values to be used in different variables. This article sets out the way in which the
process of understanding and technology assimilation of the proxy cache server was address,
which in turn is a high-impact organizational service. Moreover, this article is a product from
the research project titled Configuration Analysis of Proxy Cache Servers, where relevant
aspects of Squid as proxy cache server were studied.

Keywords
Proxy server, proxy cache server, proxy caching, web caching, Squid.

150
 Revista INGE CUC,Volumen 8, Nmero 1, Octubre de 2012, pp. 149-162

INTRODUCCIN tpicamente contiene el objeto solicitado

[12]. La interaccin entre el cliente y el ser-
Una de las principales actividades que de-
vidor web es ilustrada en la Fig. 1.
sarrolla un usuario de Internet es navegar
entre las millones de pginas y sitios web.
Como es bien conocido, la web es amplia-
mente usada en todo el mundo y el Protocolo
de Transferencia de Hipertexto (HyperText
Transfer Protocol - HTTP) es considerado
como el motor que permite el intercambio
de informacin y define la forma como los
navegadores (programas cliente web) soli-
Fig. 1 Interaccin entre cliente y servidor web
citan objetos a los servidores web y cmo
los servidores entregan la informacin so- Cuando se solicita un archivo desde un na-
licitada [12]. vegador a un servidor web, el archivo tarda
un tiempo en ser recibido por el navegador.
HTTP es un protocolo de la capa de apli-
El tiempo total est relacionado con varia-
cacin del modelo TCP/IP y es el corazn
bles como la cantidad de bytes del archivo
de la web. Las especificaciones tcnicas del
solicitado, la distancia entre el servidor web
protocolo HTTP estn definidas en los do-
y el navegador; la capacidad de comuni-
cumentos RFC 1945 [3] y 2616 [7]. HTTP
cacin de los distintos enlaces fsicos por
es implementado por dos tipos de progra-
donde debe pasar el mensaje, la eficiencia
mas: un programa servidor tal como Apa-
de los dispositivos activos intermedios y el
che Web Server [1] y un programa cliente,
trfico [12].
por ejemplo el navegador Mozilla Fire-
fox [13]. Compartir el acceso a Internet para una or-
ganizacin, ms que una opcin es una ne-
El programa cliente y el programa servidor
cesidad, bien sea por la falta de direcciones
usualmente son ejecutados en diferentes
IP pblicas para acceder a la red, o por ra-
hosts y se comunican entre s mediante el
zones de seguridad. Las dos soluciones ms
intercambio de mensajes HTTP. El protoco-
aceptadas para ofrecer el servicio de acce-
lo HTTP define la forma como los navega-
so compartido a Internet son el uso de un
dores solicitan objetos (archivos) a un ser-
servicio de traduccin de direcciones de red
vidor y cmo los servidores los transfieren
(NAT), o la implementacin de un servidor
a los clientes. Cuando un usuario solicita
proxy.
una pgina web (o hace clic en un enlace),
el navegador genera y enva uno o varios El servicio NAT consiste en la intercepta-
mensajes de solicitud HTTP al servidor. El cin de datagramas IP salientes y entran-
servidor recibe cada solicitud y responde tes, de manera que sea posible convertir
con un mensaje de respuesta HTTP el cual las direcciones IP pertenecientes a una red

151
 Servidor Proxy Cach: Comprensin y asimilacin tecnolgica

interna para hacerlas compatibles con una
red externa. Tpicamente, el servicio NAT
es prestado por un router o un host confi-
gurado con ms de una tarjeta de red y se
utiliza generalmente para pasar de una red
interna, en la cual los hosts tienen configu-
radas direcciones IP privadas, para permitir
el acceso a Internet. En este proceso, el dis-
positivo intermedio modifica tanto la direc-
cin IP origen (la direccin local), como el
nmero de puerto origen y esta informacin
es registrada en una tabla. Cuando llegan
los mensajes de respuesta desde el exterior,
los mensajes tambin son interceptados, y
se modifican nuevamente la direccin IP
y el nmero de puerto destino, de acuer-
do con la informacin registrada. De este
modo es posible entregar correctamente
cada datagrama IP recibido. Esta solucin
es realizada en la capa de red, aunque de al-
guna manera utiliza informacin de la capa
de transporte segn el modelo de referencia
TCP/IP [12].
Por su parte, un servidor proxy es una so-
lucin software implementada en la capa
de aplicacin la cual intercepta los mensa-
jes de solicitud HTTP (y otros protocolos),
para hacer la solicitud en representacin de
los usuarios de la red corporativa. Gene-
ralmente un servidor proxy se ubica en la
frontera entre la red corporativa y la red del
proveedor de acceso a Internet [8].
En las dos soluciones mencionadas, todas
las solicitudes pasan a travs de un disposi-
tivo intermedio, lo que ocasiona un cuello
de botella y en consecuencia se hace ms
lento el servicio de acceso a Internet a los
usuarios. Sin embargo, es posible aprove-
char la ubicacin de un servidor proxy para
guardar all copias de archivos que hayan
sido descargados por algn navegador de
la red corporativa, los cuales probablemen-
te sean solicitados en el futuro por algn
usuario de la red. Las copias de los obje-
tos estarn ms cerca de los usuarios, por lo
tanto, sern entregadas mucho ms rpido,
mejorando significativamente el rendimien-
to de todo el sistema. Esta tcnica es am-

Fig. 2 Servidor proxy cach en una red corporativa

152
 Revista INGE CUC,Volumen 8, Nmero 1, Octubre de 2012, pp. 149-162
pliamente utilizada en diferentes sistemas y
es conocida con el nombre de cache, dando
lugar al trmino servidor proxy cach [6].
La interaccin entre el cliente y el servidor
web con un servidor proxy en el medio es
ilustrada en la Fig. 2.
La configuracin de Squid es realizada me-
diante la asignacin de valores a un nmero
cercano a 200 directivas en un archivo de
configuracin, similar al de otros servicios
en sistemas tipo Unix. La mayora de es-
tas directivas tiene un valor asignado por
defecto; sin embargo, es necesario ajustar
algunos de estos valores para tener un servi-
dor Squid operando con una configuracin
bsica [15].
Las directivas de Squid se pueden agrupar en
siete categoras, de acuerdo con sus carac-
tersticas. Un primer grupo de directivas de
identificacin; un segundo grupo establece
el control de acceso bsico; el tercer grupo
establece el control de acceso avanzado; en
cuarto lugar, las directivas de configuracin
bsica de cach; en quinto lugar, la configu-
racin avanzada de cach; un sexto grupo
dedicado al cach distribuido; y un grupo
de directivas dedicado al control de ancho
de banda. Las directivas que tienen relacin
con el proyecto de investigacin son las di-
rectivas de configuracin bsica del cach,
entre las que se encuentran la especificacin
del directorio de cach, el espacio en disco,
los lmites al tamao de los archivos que se
van a almacenar en cach, la estructura de
directorios de cach, y las polticas de re-
emplazo; y las directivas de configuracin
avanzada de cach, especficamente los sis-
temas de archivos y los esquemas de alma-
cenamiento [15].
La seleccin de los parmetros con que se
va a configurar y los valores que se van a
asignar, generalmente est basada en la ex-
periencia, en heursticas y en los valores
que se asignan por defecto [10].
El rendimiento de un servidor proxy cach
depende de su ubicacin en la red corpo-
rativa, de las solicitudes realizadas por los
usuarios y de los intereses comunes de
ellos. Para medir el rendimiento de un ser-
vidor proxy cach, se contabilizan los acier-
tos y fallos en la bsqueda de los objetos
que sean solicitados por los usuarios [6].
Usualmente, es necesario esperar un tiempo
determinado para obtener estadsticas acer-
ca de las solicitudes de los usuarios y de las
respuestas del servidor proxy. Con base en
esas estadsticas se pueden tomar decisio-
nes para su reconfiguracin.
El proyecto de investigacin Anlisis de
configuraciones de servidores proxy ca-
ch, del cual este artculo es producto, fue
desarrollado con el fin de identificar pa-
rmetros de configuracin de un servidor
proxy cach relacionados con su desempe-
o, en busca de soluciones que mejoren las
condiciones en las que los usuarios de una
organizacin utilicen un servicio de acceso
compartido a Internet. Lo anterior permite
acercar este conocimiento tecnolgico a la
comunidad acadmica y, en consecuencia, a
la sociedad y la industria mediante su inte-
raccin con profesionales en el rea de in-
fraestructura de tecnologa informtica.
153
 Servidor Proxy Cach: Comprensin y asimilacin tecnolgica

La metodologa empleada en el desarrollo TRABAJO RELACIONADO

del proyecto corresponde a una adaptacin
de la Metodologa de la Investigacin Tec-
nolgica, propuesta por Sonia Ros en 1998
[14], para su aplicacin en proyectos de
Infraestructura de Tecnologa Informtica.
Producto de la adaptacin de esta metodo-
loga, se identificaron cinco etapas: Estu-
dios previos, Anlisis del problema, Diseo
de la solucin, Implementacin y Pruebas.
Para adelantar la investigacin, fue necesa-
rio entender el funcionamiento del servicio
prestado por los servidores proxy cach y
asimilar la tecnologa. El servidor proxy ca-
ch seleccionado para el desarrollo del tra-
bajo fue Squid, entre otras, por las siguien-
tes cuatro razones: est basado en software
libre, lo que implica acceso al cdigo fuente
y la posibilidad de modificarlo de acuerdo
con las necesidades; es ampliamente utili-
zado en el mundo; est bastante documen-
tado; y proporciona diferentes posibilidades
para analizar su comportamiento. Adems,
se analizaron antecedentes de investigacio-
nes realizadas en trabajos relacionados, a
partir de los cuales se identificaron algunas
estrategias de investigacin, mtricas de de-
sempeo utilizadas en estudios similares, y
se analizaron los resultados de un estudio
publicado sobre el rendimiento de Squid.
El resto del artculo est estructurado de la
siguiente manera: A continuacin se presen-
ta el trabajo relacionado; luego se hace una
descripcin de la metodologa empleada en
el desarrollo del proyecto; despus se mues-
tra el esquema de trabajo y la automatiza-
cin del proceso de pruebas se encuentra
posteriormente. Al final, las conclusiones.
Desde que se origin la web, a comienzos
de la dcada del noventa, el nmero de usua-
rios ha crecido continuamente y el desem-
peo ha sido una preocupacin constante
para los investigadores. El uso de cach en
la web ha sido una estrategia ampliamente
estudiada para esta problemtica, por lo que
se realiz un anlisis de la forma como se
han desarrollado otros trabajos de investi-
gacin en temas relacionados con el anlisis
de desempeo de servidores proxy cach.
Se destacan tres elementos encontrados. En
primer lugar, la estrategia utilizada por los
investigadores para realizar sus estudios; en
segundo lugar, las mtricas utilizadas para
medir el desempeo; y en tercer lugar, prue-
bas de desempeo que han sido publicadas
por [15] como punto de referencia del de-
sempeo de Squid.
Estrategias de investigacin
Segn [5] y [16], los trabajos de investi-
gacin sobre el desempeo de servidores
proxy cach utilizan diferentes tcnicas
para la recoleccin de datos. Algunas si-
guen mtodos formales, mientras que otras
son evaluaciones empricas; sin embargo,
todas son ampliamente aceptadas y utili-
zadas. Entre las tcnicas ms populares se
encuentran la simulacin de redes con datos
artificiales; la implementacin de sistemas
reales en redes aisladas; y el anlisis de ar-
chivos log reales. A continuacin una breve
descripcin de estas tcnicas.

154
 Revista INGE CUC,Volumen 8, Nmero 1, Octubre de 2012, pp. 149-162
Simulacin de redes con datos artificiales
La simulacin es un mecanismo de evalua-
cin que no obliga implementaciones com-
pletas aunque requieren el conocimiento
detallado del sistema que se desea evaluar.
Sistemas reales en redes aisladas
Esta tcnica consiste en crear escenarios
controlados en los cuales se eliminan varia-
bles que a pesar de ser reales pueden distor-
sionar los resultados obtenidos.
Anlisis de archivos log reales
Es una prctica usada con frecuencia debi-
do a que los datos son obtenidos a partir del
comportamiento real de los usuarios.
Mtricas de desempeo
En estudios acerca del desempeo de los
servidores proxy cach [16] seala que hay
trabajos orientados a mejorar las mtricas
como el hit rate y el byte hit rate; otros
trabajos pretenden disminuir la latencia
experimentada por el usuario; y algunos
ms intentan disminuir el trfico hacia el
exterior de la red. Sin embargo, hay algu-
nas mtricas no tradicionales que pueden
tener incidencia en el desempeo del servi-
dor proxy cach como la cancelacin de la
conexin entre el cliente y el servidor, y la
influencia que tiene el uso de cookies [4]; la
proporcin de reduccin de costo [2]; las ta-
sas mxima y promedio de ancho de banda
consumido, el porcentaje de trfico de red
ahorrado debido al uso local de recursos al-
macenados en cach y la cantidad de trfico
que puede ser atribuido al uso y administra-
cin del cach [16].
Las dos mtricas de desempeo ms acepta-
das para evaluar el desempeo de un cach
son el hit rate y el byte hit rate [6]. Sin em-
bargo, la reutilizacin de objetos que estn
almacenados en el cach depende en gran
medida de las preferencias de los usuarios.
Adems, alcanzar un nivel mayor en el hit
rate o en el byte hit rate, no necesariamente
conduce a mejorar significativamente el de-
sempeo del cach [16].
Desempeo de Squid con respecto
al sistema de archivos y al esquema
de almacenamiento
Squid ofrece una variedad de opciones en
el proceso de instalacin y configuracin,
especialmente relacionadas con el alma-
cenamiento de los archivos en disco. Los
sistemas de archivos son caractersticos de
un sistema operativo particular. Casi todas
las versiones de Unix tienen una implemen-
tacin del UFS (Unix File System), el cual
tambin es conocido como el FFS (Berkeley
Fast File System). El sistema de archivos
por defecto de GNU/Linux es ext2fs, aun-
que recientemente nuevos sistemas de ar-
chivos han sido desarrollados como ext3fs
y ext4fs. Muchos sistemas operativos tam-
bin soportan tecnologas de sistemas de
archivos ms nuevas. Estas incluyen nom-
bres y acrnimos como advfs, xfs y reiserfs.
Squid puede funcionar con cinco esquemas
de almacenamiento: ufs, aufs, diskd, coss y
null. Estos esquemas tienen diferentes pro-
piedades y tcnicas para organizar y acce-
155
 Servidor Proxy Cach: Comprensin y asimilacin tecnolgica
der a los datos almacenados en el cach me-
diante llamadas a operaciones del sistema
de archivos [15].
En [15] se publicaron los resultados de unas
pruebas de desempeo de Squid en las cua-
les se hicieron anlisis sobre sistemas de
archivos y esquemas de almacenamiento en
sistemas operativos distintos. Las pruebas
realizadas al utilizar el sistema operativo
GNU/Linux se relacionan mejor con el pro-
yecto de investigacin.
METODOLOGA
El proyecto de investigacin se enmarc
dentro de la investigacin tecnolgica en
ciencias de la ingeniera. La metodologa
empleada correspondi a una adaptacin de
la metodologa propuesta por [14] para su
aplicacin en proyectos de infraestructura
de tecnologa informtica. Producto de la
adaptacin de esta metodologa, se identifi-
caron cinco etapas: Estudios previos, An-
lisis del problema, Diseo de la solucin,
Implementacin y Pruebas.
Los estudios previos corresponden a la pri-
mera etapa del proyecto. En esta etapa se
identific el problema objeto de estudio a
partir de la oportunidad que representa para
el Grupo GRID impactar positivamente
el desarrollo de sus actividades misiona-
les como son la investigacin, la docencia
y la proyeccin social. Posteriormente, se
realiz la bsqueda y organizacin de la
informacin, continuando con la revisin
bibliogrfica y el anlisis de trabajos rela-
cionados, obteniendo el estado general del
156
tema. Esta etapa finaliz con la formulacin
del proyecto.
El anlisis del problema consiste en enten-
der la situacin objeto de estudio. Se inici
con la identificacin de los servicios funda-
mentales que ofrece Squid como servidor
proxy cach. Luego, se examin el formato
del archivo de configuracin de Squid para
reconocer y analizar los parmetros relacio-
nados con su desempeo.
El diseo de la solucin se refiere a la bs-
queda de ideas y al planteamiento de alter-
nativas que conduzcan a resolver el proble-
ma objeto de estudio. El diseo inici con
la adaptacin de un modelo abstracto por
capas con un enfoque descendente, defi-
nido en [11]. Este modelo es un referente
abstracto del cual se pueden derivar diseos
con especificaciones particulares, como las
de este proyecto, ya que permite indepen-
dizar funciones o responsabilidades y ocul-
tar detalles internos de las distintas capas.
Para este caso se dise un ambiente virtual
controlado sobre el cual se puso en funcio-
namiento Squid en diferentes topologas de
red, las cuales fueron de gran utilidad en la
realizacin del estudio. Posteriormente, se
disearon escenarios de prueba con diferen-
tes configuraciones del servidor Squid, y se
crearon archivos para ser almacenados en
un servidor web (Apache Web Server). Para
finalizar esta etapa se dise un sistema au-
tomatizado de pruebas a partir de sincroni-
zacin de archivos.
La implementacin corresponde a la etapa
en la que se materializa el diseo realizado.
Se utilizaron los recursos fsicos disponi-
 Revista INGE CUC,Volumen 8, Nmero 1, Octubre de 2012, pp. 149-162
bles, se instal una herramienta de virtuali-
zacin empresarial, se crearon las mquinas
y dispositivos virtuales con sus respectivos
sistemas operativos y configuracin de red.
La parte final de la implementacin consis-
ti en la instalacin y configuracin del ser-
vidor web y del servidor proxy cach.
La etapa de pruebas permite validar el tra-
bajo realizado. Para facilitar la compren-
sin del procedimiento utilizado en el pro-
yecto de investigacin, se establecieron dos
fases: la estructura y el proceso de pruebas,
las cuales se describen a continuacin.
Estructura de las pruebas
Fue necesario definir ciertos elementos para
establecer la estructura de las pruebas. Es-
tos elementos son: la mtrica de desempeo
empleada; los archivos de prueba almace-
nados en el servidor web; y los parmetros
de configuracin del servidor Squid que
fueron analizados.
Mtrica de desempeo
Las mtricas de desempeo que se tuvieron
en cuenta son hit rate, byte hit rate y tiempo
promedio de descarga de cada objeto web
(archivo de prueba). Sin embargo, las dos
primeras fueron descartadas debido a que
tienen una alta relacin con las preferencias
de utilizacin del servicio por parte de los
usuarios, las cuales no estn directamente
relacionadas con el objeto de estudio del
proyecto de investigacin. Por lo tanto, las
pruebas realizadas se orientaron a medir el
tiempo promedio de descarga de archivos
de prueba previamente identificado.
Archivos de prueba
Como se ha mencionado, para realizar una
prueba en este estudio, se deba medir el
tiempo promedio de descarga de un objeto
web. Por lo tanto, se necesitaban archivos
disponibles para descargar, los cuales de-
ban estar almacenados en el servidor web
y que el cliente los tuviera debidamente
identificados al momento de hacer las soli-
citudes. Es de anotar que el tamao de cada
archivo est directamente relacionado con
el tiempo que tarda obtenerlo desde cuando
se realiz la solicitud. En este estudio se uti-
lizaron archivos de tamaos diferentes.
Parmetros de configuracin del servidor Squid
El objetivo del proyecto de investigacin
era analizar distintas configuraciones en
un servidor proxy cach y la herramienta
seleccionada para realizar las pruebas fue
Squid Cache. Dado que la configuracin de
Squid se realiza mediante un archivo pla-
no de configuracin en el cual se especifi-
can los valores de un nmero importante
de parmetros, se procedi a identificar los
parmetros ms relevantes con respecto al
desempeo del servidor Squid. Los princi-
pales parmetros de configuracin estaban
relacionados con el sistema de archivos y
el esquema de almacenamiento, y son cohe-
rentes con lo expresado por [15].
Proceso de pruebas
Dado que el objetivo era calcular el tiempo
promedio al realizar descargas de objetos
web, se dise el proceso de pruebas con
los pasos que se describen a continuacin:
157
 Servidor Proxy Cach: Comprensin y asimilacin tecnolgica
1. Seleccin de un archivo de configura-
cin especfico con un conjunto de par-
metros cuyos valores estn determina-
dos.
2. Inicio del servidor proxy cach Squid
con el cach vaco.
3. Solicitud de un archivo determinado al
servidor web. Esta solicitud se realiza
un nmero de veces especificado, para
un conjunto determinado de archivos.
4. Registro del tiempo de inicio y fin de
cada archivo descargado, para medir el
tiempo transcurrido en cada descarga.
5. Realizacin de los anlisis respectivos.
ESQUEMA DE TRABAJO
Para la realizacin de las pruebas del pro-
yecto de investigacin se dise un esque-
ma de trabajo dividido en capas, cada una
de ellas orientada a un conjunto de activi-
dades relacionadas. El esquema propuesto
se puede observar en la Fig. 3.
Fig. 3 Esquema de trabajo por capas
158
Capa fsica
La capa fsica del esquema de trabajo del
proyecto de investigacin consisti en un
Servidor Dell Power Edge T100 equipado
con un procesador Intel Xeon de cuatro n-
cleos de 2.4 GHz, 4 GB de memoria Ram
y disco duro de 500 GB. Este equipo fue
adquirido con el fin de implementar virtua-
lizacin empresarial por hardware (paravir-
tualizacin) para el desarrollo de los pro-
yectos del grupo de investigacin en Redes,
Informacin y Distribucin - GRID, de la
Universidad del Quindo.
Capa de virtualizacin
Para dar un adecuado aprovechamiento a los
recursos de hardware disponibles, y adems
eliminar posibles errores presentes tanto en
los medios fsicos de transmisin de datos
como en equipos activos, se implement
un ambiente virtual controlado para formar
una red aislada. En la implementacin del
ambiente virtual se utiliz VMware ESXi,
una versin gratuita de VMware, la cual
permite dar los primeros pasos en virtua-
lizacin empresarial de ltima generacin.
ESXi utiliza un hipervisor o monitor de m-
quinas virtuales, el cual es un componente
de software que acta directamente sobre el
hardware para permitir la creacin de m-
quinas virtuales sin necesidad de un siste-
ma operativo host optimizando el hardware
disponible. El hipervisor administra recur-
sos hardware como memoria, procesador,
disco y dispositivos perifricos, para ser
asignados a las mquinas virtuales de acuer-
do con las necesidades y segn el caso [9].
 Revista INGE CUC,Volumen 8, Nmero 1, Octubre de 2012, pp. 149-162

Capa de mquinas virtuales ferentes. El primer segmento representaba

la red local o corporativa y el segundo seg-
Se utilizaron tres mquinas virtuales (Fig.
mento representaba una red externa en la
4) en las cuales se configur el sistema ope-
cual se encontraba el servidor web. Para la
rativo GNU/Linux Debian Lenny (Versin
conexin de los equipos se utilizaron swit-
5). La seleccin de este sistema operativo
ches virtuales proporcionados por VMware
se hizo de manera arbitraria, debido a que
ESXi. Es de resaltar que en esta topologa
podra haberse utilizado cualquier otra dis-
no se presentaban mensajes en difusin que
tribucin. Sin embargo, se eligi por ser una
pudieran alterar el rendimiento de la red, ni
distribucin altamente reconocida por su
se consideraron los retrasos cada vez que un
estabilidad y aplicacin en la configuracin
paquete pasaba a travs de un dispositivo
de servidores, adems de tener una gran co-
activo local. Por otra parte, a pesar de si-
munidad de desarrolladores alrededor del
mular el paso entre dos redes diferentes, no
mundo. Las tres mquinas tenan la misma
se contaba con enrutadores intermedios que
configuracin: Procesador 2 GHz, memoria
pudieran aumentar el retardo extremo a ex-
Ram: 1 GB, disco duro: 20 GB. En cuanto
tremo. Tampoco se tuvo en cuenta el retraso
a la configuracin de la red, tanto el cliente
ocasionado por el acceso a la red externa
como el servidor web contaban con una tar-
ni los retrasos producidos por el proceso de
jeta de red, mientras que el servidor proxy
resolucin de nombres de dominio, lo cual
cach tena dos.
estaba fuera del alcance del proyecto. La
Fig. 5 muestra la topologa de red.
Capa de red
La capa de red del esquema de trabajo co- Capa de servicios
rresponde a la topologa de red emplea- En la capa de servicios se adicionaron ro-
da para el desarrollo del proyecto. En este les especficos a cada una de las mquinas
caso, las tres mquinas virtuales estaban virtuales creadas para desempear las fun-
configuradas en dos segmentos de red di- ciones necesarias para la realizacin de las

Fig. 4 Capa de mquinas virtuales

159
 Servidor Proxy Cach: Comprensin y asimilacin tecnolgica

Fig. 5 Topologa de red

pruebas. De esta manera, se implement un Por lo anterior, y con el fin de aumentar la

servidor web, un servidor proxy cach y un
cliente web, tal como se puede apreciar en
la Fig. 6.
AUTOMATIZACIN
DEL PROCESO DE PRUEBAS
Para la ejecucin de una prueba era necesa-
rio invertir una cantidad de tiempo conside-
rable, debido a que se trataba de un proceso
dispendioso, que usualmente era realizado
en forma manual. Esta situacin limitaba la
adquisicin de informacin determinante
para el estudio de las configuraciones del
servidor proxy cach. Adems, poda indu-
cir al error humano en la ejecucin de estas
actividades.
cantidad de informacin recolectada para
la realizacin de los anlisis de una manera
gil y fcilmente repetible y precisa, se di-
se un ambiente de pruebas automatizado
para su ejecucin sobre los servicios ilus-
trados en la Fig. 6. Este ambiente consista
en tres componentes: un generador de soli-
citudes que funcionaba en el cliente; un car-
gador automtico de archivos de configura-
cin que se ejecutaba en el mismo equipo
donde corra el servidor proxy cach; y una
zona compartida comunicada por la red lo-
cal, la cual era utilizada para sincronizacin
a partir de archivos compartidos. Para evi-
tar la intervencin de un usuario se dise
un procesamiento de archivos en lote, a par-

Fig. 6. Capa de servicios

160
 Revista INGE CUC,Volumen 8, Nmero 1, Octubre de 2012, pp. 149-162
tir de los cuales se definieron: los archivos
disponibles para descargar, la cantidad de
veces que deba ser descargado un archivo
y los archivos de configuracin del servidor
Squid que seran cargados para la ejecucin
de cada prueba. Por otra parte, el registro de
actividades en bitcoras (archivos log) per-
mita obtener la informacin necesaria para
calcular los tiempos promedio necesarios
para los anlisis de cada archivo de configu-
racin. El ambiente automatizado de prue-
bas se desarroll a partir de la combinacin
de herramientas disponibles en el sistema
operativo, shell scripts y aplicaciones soft-
ware construidas a la medida en lenguaje C.
CONCLUSIONES, APORTE
Y TRABAJO FUTURO
La configuracin por defecto de Squid no es
apropiada para todos los ambientes de pro-
duccin. Es necesario estudiar las necesida-
des de la organizacin y, con base en ellas,
realizar los ajustes respectivos, los cuales
pueden ser tan sencillos como modificar
un parmetro de configuracin, o tan com-
plejos como recompilar el software y/o el
kernel del sistema operativo (si ste lo per-
mite); utilizar varias estructuras de archivos
para alojar los cachs y tal vez ajustar una
variedad de parmetros en el archivo de
configuracin, sin dejar de lado la adecuada
seleccin del hardware para la instalacin
del servicio.
El comportamiento de una configuracin
es altamente dependiente de los ambientes
de ejecucin particulares y lo que puede ser
conveniente en un escenario puede ser in-
conveniente en otro. Determinar los valores
de los parmetros de configuracin adecua-
dos para un ambiente especfico es una ta-
rea no trivial; por lo tanto, las pruebas reali-
zadas en el proyecto de investigacin sirven
de referencia para que los administradores
de servidores Squid realicen ajustes a sus
archivos de configuracin.
El ambiente automatizado desarrollado
dentro de este proyecto es un valor agrega-
do para los administradores de infraestruc-
tura de redes, ya que puede ser aplicado a
servicios similares en mltiples platafor-
mas, siempre y cuando su comportamiento
est basado en parmetros especificados en
un archivo de configuracin.
La infraestructura para virtualizacin em-
presarial fue probada y funciona eficiente-
mente, lo que permite aprovechar este re-
curso en futuros proyectos de investigacin.
Como trabajo futuro, quedan muchas ideas
para profundizar, entre las que se destacan
la automatizacin de la asignacin de los
valores de los parmetros de configuracin
mediante la aplicacin de inteligencia arti-
ficial; el uso de cachs cooperativos (distri-
buidos y jerrquicos); el uso de servidores
proxy cach sobre plataformas de red basa-
das en IPv6; implementar un robot multi-
hilo que simule ambientes con acceso con-
currente al servidor proxy cach; y realizar
estudios acerca de configuraciones propias
del sistema operativo y de hardware que
afecten el rendimiento del servidor proxy
cach.
161
 Servidor Proxy Cach: Comprensin y asimilacin tecnolgica
REFERENCIAS
[1] Apache. The Apache Software Founda-
tion. [Online] Disponible en: http://www.
apache.org/, 2010.
[2] R. Ayani, Cost-based Proxy Caching.
Proceedings of the International Sym-
posium on Distributed Computing and
Applications to Business, Engineering and
Science, pp. 218-222. Wuxi, 2002.
[3] T. Berners-Lee, RFC 1945. Hypertext
Transfer Protocol -- HTTP/1.0, 1996.
[4] R. Cceres et al., Web Proxy Caching:
The devil is in the details. Workshop on
Internet Server Performance. Madison,
Wisconsin USA, 1998.
[5] B. Davison, A survey of proxy cache eval-
uation techniques, 1999.
[6] B. Davison, A Web Caching Primer.
IEEE Internet Computing, Volume 5,
Number 4, 38-45, 2001.
[7] R. Fielding, RFC 2616. Hypertext Trans-
fer Protocol -- HTTP/1.1, 1999.
[8] H. Flynn, Designing And Building Enter-
prise DMZs. Syngress Media Inc., 2006.
[9] B. Goldworm and A. Skamarock, Blade
Servers and Virtualization: Transform-
ing Enterprise Computing While Cutting
Costs. Willey Publishing Inc., 2007.
162
[10] C. E. Gmez and L. E. Seplveda, Anli-
sis de configuraciones de servidores proxy
cach, Informe Final. Universidad del
Quindo, 2010.
[11] C. E. Gmez and L. E. Seplveda, Me-
jorando la calidad de servicio a traves de
configuraciones adecuadas de servidores
proxy cache. Primer Seminario Taller
Latinoamericano de Instrumentacion,
Control y Telecomunicaciones SICOTEL.
Universidad del Quindio, 2012.
[12] J. Kurose, Computer Networking: A top-
down approach, 5th Edition. Massachus-
sets: Addison Wesley, 2010.
[13] Mozilla, Firefox. [Online] Disponible en:
http://www.mozilla.org/firefox/, 2010.
[14] S. Ros, Metodologa de la Investigacin
Tecnolgica. Ediciones Hispanoamerica-
nas Ltda., 1998.
[15] D. Wesseles, Squid: The definitive guide.
OReilly & Associates, Inc., 2004.
[16] D. Zeng, Efficient Web Content Deli-
very Using Proxy Caching Techniques.
IEEE Transactions on Systems, Man, And
Cybernetics-Part C: Applications and Re-
views, 2004.