ANÁLISIS DE CONFIGURACIONES DE SERVIDORES PROXY CACHÉ INFORME FINAL
Investigador Principal: Carlos Eduardo Gómez Montoya, MSc
Coinvestigador: Luis Eduardo Sepúlveda Rodríguez, MSc
Universidad del Quindío Armenia, Quindío Junio de 2010
CONTENIDO
Pag 1.
INTRODUCCIÓN .................................................................................................................................. 1
2.
OBJETIVOS ........................................................................................................................................... 5 2
.
2
.
1
2
.
.
O
b
j
e
t
i
v
o
O
b
j
e
t
i
v
o
G
e
n
e
r
a
.
.
.
.
.
.
.
.
3.
s
E
s
p
e
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
l
c
í
f
i
c
o
s
PROTOCOLO HTTP Y SERVIDORES PROXY CACHÉ ................................................................ 7 3
.
1
.
R
3
.
2
E
.
3
.
4
.
D
O
S
E
N
L
A
T
R
A
N
S
F
E
R
E
N
C
5
W
E
B
Y
E
L
P
R
O
T
O
C
O
L
O
H
T
T
.
.
A
.
D
.
.
.
.
E
.
.
.
I
.
.
.
.
.
N
.
F
.
.
.
O
.
.
.
R
.
.
.
M
.
.
.
.
A
.
.
.
C
.
.
.
.
I
.
.
Ó
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
N
.
.
.
.
.
.
9
P
Protocolo HTTP ............................................................................................................................. 9
3.2.2.
Mensajes HTTP ............................................................................................................................12
.
.
E
N
D
I
M
I
E
N
T
O
D
E
L
P
R
O
T
O
C
O
L
O
H
T
T
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
9
P
3.3.1.
Tipos de conexiones en el protocolo HTTP......................................................................19
3.3.2.
Caché ................................................................................................................................................23
.
.
E
R
V
I
D
O
R
E
S
P
R
O
X
Y
C
A
C
H
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
0
É
3.4.1.
Análisis de desempeño de una solución basada en el uso de un servidor proxy
caché
32
3.4.2.
Mensajes de solicitud condicionales ...................................................................................36
3.4.3.
Otras líneas de encabezado HTTP asociadas al uso de un caché ............................39
.
.
I
4.
I
3.2.1.
S
3
R
.
A
R
3
A
.
L
3
T
M
P
L
E
M
E
N
T
A
C
I
O
N
E
S
D
E
S
E
R
V
I
D
O
R
E
S
P
R
O
X
Y
C
A
C
H
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
0
É
3.5.1.
Squid ................................................................................................................................................40
3.5.2.
DeleGate..........................................................................................................................................41
3.5.3.
Apache Web Server ....................................................................................................................42
3.5.4.
Microsoft ISA Server ..................................................................................................................43
3.5.5.
EngageIP Cache Server .............................................................................................................44
3.5.6.
Sun Java System Web Proxy Server ....................................................................................45
ANÁLISIS DE CONFIGURACIONES DE SERVIDORES PROXY CACHÉ ................................ 47 4
.
1
.
.
C
4
.
2
O
N
F
I
G
U
R
A
C
I
Ó
N
D
E
S
Q
U
I
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
7
D
4.1.1.
La directiva cache_dir ...............................................................................................................49
4.1.2.
Directiva maximum_object_size ...........................................................................................49
.
.
T
R
A
B
A
J
O
R
E
L
A
C
I
O
N
A
D
O
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
0
4.2.1.
Estrategias de investigación...................................................................................................50
4.2.2.
Métricas de desempeño ...........................................................................................................51
4.2.3.
Pruebas de desempeño de
S
q
i
u
con diferentes sistemas de archivos y
d
diferentes esquemas de almacenamiento .............................................................................................52 4
.
3
.
.
D
4
.
4
E
.
I
S
.
E
S
T
O
M
A
D
A
S
P
A
R
A
E
L
D
E
S
A
R
R
O
L
L
E
S
A
R
R
O
L
L
O
D
E
L
A
M
B
I
E
N
.
M
B
I
E
N
T
E
S
V
I
R
T
U
A
L
E
.
.
T
.
.
.
E
.
.
.
D
.
.
.
.
.
E
.
.
P
.
.
.
.
.
R
.
.
.
U
.
.
E
L
P
R
O
Y
E
C
T
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
4
O
.
.
.
.
B
.
.
.
A
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
8
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
1
S
.
.
.
.
.
.
S
Virtualización ...............................................................................................................................61
.
7
E
Archivos de prueba (objetos Web)......................................................................................57
.
6
D
4.3.3. .
5
O
Métricas de desempeño y parámetros de configuración ...........................................56
.
S
4
N
4.3.2.
4.5.1. .
O
Casos de estudio y arquitecturas .........................................................................................54
A
4
I
4.3.1.
D
4
C
I
S
T
E
M
A
D
E
A
R
C
H
I
V
O
S
D
E
R
E
D
N
(
F
S
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
3
)
4.6.1.
Configuración del servidor .....................................................................................................64
4.6.2.
Configuración del cliente .........................................................................................................66
.
.
S
O
F
T
W
A
R
E
D
E
S
A
R
R
O
L
L
A
D
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
7
O
4.7.1.
Aplicación en el lado servidor ...............................................................................................67
4.7.2.
Aplicación en el lado cliente ...................................................................................................73
5.
PRUEBAS REALIZADAS .................................................................................................................. 83
6.
CONCLUSIONES, APORTE Y TRABAJO FUTURO ..................................................................... 89
REFERENCIAS BIBLIOGRÁFICAS .......................................................................................................... 91
LISTA DE FIGURAS
F
i
g
u
r
a
1
I
n
t
F
i
g
u
r
a
2
F
i
g
u
r
a
3
F
i
g
u
r
a
4
U
s
o
d
e
l
m
é
t
o
d
o
G
E
T
c
o
n
f
o
r
m
u
l
a
r
i
o
s
–
P
a
r
t
e
F
i
g
u
r
a
5
U
s
o
d
e
l
m
é
t
o
d
o
G
E
T
c
o
n
f
o
r
m
u
l
a
r
i
o
s
–
P
a
r
t
e
F
i
g
u
r
a
6
F
i
g
u
r
a
7
F
i
g
u
r
a
F
i
g
u
r
a
9
F
i
g
u
r
a
1
0
F
i
g
u
r
a
1
1
F
i
g
u
r
a
1
2
S
F
i
g
u
r
a
1
3
A
F
i
g
u
r
a
1
4
E
j
e
m
p
l
o
d
e
u
n
m
e
n
s
a
j
e
d
e
s
o
l
i
c
i
t
u
d
H
T
T
P
e
F
i
g
u
r
a
1
5
E
j
e
m
p
l
o
d
e
u
n
m
e
n
s
a
j
e
d
e
s
o
l
i
c
i
t
u
d
H
T
T
P
c
F
i
g
u
r
a
1
6
E
j
e
m
p
l
o
d
e
u
n
m
e
n
s
a
j
e
d
e
F
i
g
u
r
a
1
7
F
i
g
u
r
a
1
F
i
g
u
r
a
1
F
i
g
u
r
a
F
i
g
u
r
F
i
g
u
r
F
o
E
t
D
8
i
f
r
o
l
C
u
e
i
n
c
l
l
u
d
i
M
e
l
t
i
i
n
d
e
d
n
o
n
s
a
j
a
a
i
T
c
a
c
i
t
n
d
t
i
e
u
a
o
a
r
n
r
e
a
l
.
.
.
.
.
o
.
a
i
p
.
.
.
.
.
.
a
.
H
.
.
.
.
.
.
.
T
.
.
.
.
.
.
.
.
n
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
2
3
.
T
.
.
.
P
.
.
r
.
i
.
.
.
i
.
.
.
r
.
.
o
.
.
.
.
.
c
.
.
.
.
a
T
s
e
r
v
i
d
o
r
W
e
b
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
5
o
.
.
i
.
.
.
n
e
.
.
s
.
.
l
v
o
n
c
n
c
n
.
u
l
g
u
.
.
r
n
e
.
s
.
d
i
e
.
o
E
.
o
n
t
c
n
G
.
t
i
e
p
i
n
.
e
l
n
.
o
c
.
a
.
j
e
.
e
.
b
p
e
d
u
.
t
.
a
o
i
d
.
.
n
n
d
a
.
p
.
.
.
n
l
.
.
u
i
n
P
.
.
v
o
.
.
I
.
.
.
a
.
.
.
e
.
.
.
é
n
.
.
h
l
.
.
.
s
a
.
P
a
c
.
.
T
y
.
.
T
.
g
a
.
.
H
r
.
.
2
c
.
.
i
n
.
i
a
d
t
.
.
.
e
t
.
i
.
c
.
t
o
c
u
.
n
d
i
i
.
.
.
e
.
.
n
.
.
.
r
a
l
a
.
e
o
n
o
W
p
o
i
.
l
.
.
b
u
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
7
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
7
n
s
e
r
v
i
d
o
r
p
r
o
x
y
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
8
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
8
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
4
A
r
q
u
i
t
e
c
t
u
r
a
p
a
r
a
e
l
c
a
s
o
d
e
e
s
t
u
d
i
o
9
A
r
q
u
i
t
e
c
t
u
r
a
p
a
r
a
e
l
c
a
s
o
d
e
e
s
t
u
d
i
o
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
2
0
A
r
q
u
i
t
e
c
t
u
r
a
p
a
r
a
e
l
c
a
s
o
d
e
e
s
t
u
d
i
o
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
a
2
1
A
r
q
u
i
t
e
c
t
u
r
a
p
a
r
a
e
l
c
a
s
o
d
e
e
s
t
u
d
i
o
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
a
2
A
r
q
u
i
t
e
c
t
u
r
a
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
d
e
l
a
s
o
l
u
c
i
ó
n
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
.
a
l
.
.
1
.
n
T
.
.
c
.
.
T
n
o
a
.
a
o
e
v
.
a
y
d
i
.
c
i
.
t
c
x
.
H
s
s
c
t
t
.
u
.
.
P
s
d
a
s
.
t
a
r
e
.
i
d
o
u
.
t
.
e
o
.
d
.
e
r
.
u
T
e
p
s
c
p
.
r
.
t
u
d
t
.
P
T
n
.
i
p
a
e
n
c
H
r
.
T
s
a
t
d
r
s
s
i
o
e
.
i
e
a
i
p
c
r
s
d
a
d
p
v
e
c
o
r
r
a
l
i
t
i
T
r
s
b
l
H
e
e
e
o
d
d
r
W
s
u
u
e
r
e
t
e
e
s
n
r
l
c
t
a
a
i
n
i
p
p
o
d
c
a
s
d
e
j
s
s
e
i
a
e
e
n
e
n
é
o
s
i
j
l
r
c
v
a
o
n
e
e
a
r
e
h
i
d
n
m
c
o
x
e
e
n
r
s
s
e
d
e
n
e
m
e
e
s
e
d
o
n
y
m
e
j
p
e
e
n
a
m
a
r
j
u
s
o
t
n
a
m
l
c
n
E
e
c
l
n
e
b
e
s
n
i
e
u
n
d
e
n
u
G
r
t
l
r
e
t
i
e
e
e
o
d
l
l
t
l
e
a
W
b
l
m
e
s
e
ó
r
n
c
a
n
e
e
m
e
d
a
u
o
c
c
i
r
u
n
r
n
n
e
ó
c
i
e
o
i
e
t
e
u
g
d
n
n
e
o
c
e
e
d
o
a
n
g
o
l
m
ó
o
t
p
e
S
l
a
i
i
t
p
m
s
c
a
m
e
E
c
m
r
j
a
m
e
o
E
r
r
j
F
8
e
.
.
.
.
.
.
6
6
1
INTRODUCCIÓN
1
INTRODUCCIÓN
El Protocolo de transferencia de hipertexto - HTTP es un protocolo de la capa de aplicación del modelo TCP/IP y es el corazón de la Web. El protocolo HTTP define la forma como los clientes Web solicitan objetos a un servidor y cómo los servidores los transfieren a los clientes (Kurose, 2010).
Es ampliamente conocido que una de las principales actividades que desarrolla un usuario de Internet es navegar entre las millones de páginas y sitios Web. Para poder hacerlo, los usuarios acceden a un navegador (programa cliente HTTP), tal como Mozilla Firefox (Mozilla, 2010), Opera (Opera, 2010) o Internet Explorer (Microsoft, Internet Explorer, 2010), entre otros. El tiempo que tardan en ser descargados los objetos Web solicitados por los usuarios puede hacer no muy grata la experiencia de navegar por Internet.
La disminución del tiempo de descarga de los objetos Web no es sólo un asunto comercial entre los usuarios y los proveedores de acceso a Internet, también es un asunto de desempeño. El desempeño del protocolo HTTP es un problema complejo en el que se pueden identificar un número muy significativo de variables, muchas de las cuales están fuera del control tanto de los usuarios como de los administradores de los sitios Web. Lo anterior debido a que todos los equipos que existen entre el usuario y el servidor Web, junto con el software que se ejecuta en ellos van a contribuir en el tiempo total que se demora obtener cada uno de los objetos que un usuario solicita a un servidor Web.
El caché de Web, también llamado servidor proxy, es una herramienta que puede ayudar significativamente a disminuir el tiempo promedio de la descarga de objetos desde un servidor Web. Un servidor proxy es un programa intermediario que resuelve las solicitudes HTTP, el cual se ubica usualmente dentro de la red local y su función es mantener copias locales de los objetos Web que han sido solicitados recientemente
Análisis de configuraciones de servidores proxy caché
por sus clientes con el fin de entregarlos más rápidamente que si se trajeran desde el servidor de origen. Los servidores proxy caché son cada vez más utilizados porque aprovechan las conexiones rápidas con los clientes lo que ayuda a disminuir el tráfico hacia los servidores de origen en Internet.
La configuración inicial de un servidor proxy caché requiere establecer los valores a ciertos parámetros. La selección de los parámetros a configurar y los valores a asignar, generalmente está basada en la experiencia, en heurísticas y en los valores que se asignan por defecto.
El rendimiento de un servidor proxy caché depende de su ubicación en la red corporativa, de las solicitudes realizadas por los usuarios y de los intereses comunes de ellos. Para medir el rendimiento de un servidor proxy caché, se contabilizan los aciertos y fallos en la búsqueda de los objetos que sean solicitados por los usuarios (Davison, A Web Caching Primer, 2001). La efectividad del caché es juzgada por su r
a
t
e
h
i
t
, es decir, el número de aciertos – hits, dividido entre el número de intentos – la
suma de los aciertos más los fallos (Provost, 2010).
Usualmente, es necesario esperar un tiempo determinado para obtener estadísticas acerca de las solicitudes de los usuarios y de las respuestas del servidor proxy. Con base en esas estadísticas se pueden tomar decisiones para su reconfiguración.
Este proyecto de investigación:
r
“
A
n
á
l
i
s
i
s
d
e
c
o
n
f
i
g
u
a
r
c
i
o
n
e
s
d
e
s
e
v
r
i
d
o
r
e
s
p
a
o
x
y
c
c
h
é
”
fue desarrollado con el fin de determinar los valores de los parámetros básicos de configuración de servidores proxy caché con los que se obtenga el menor tiempo promedio de descarga de los objetos solicitados.
Este informe final está organizado de la siguiente manera: Los objetivos se pueden encontrar en el capítulo 2. El contexto teórico dentro del cual se encuentra el trabajo se presenta en el capítulo 3. El capítulo 4 contiene el trabajo desarrollado y en el
2
INTRODUCCIÓN
3
capítulo 5 se analizan las pruebas realizadas y los resultados obtenidos. El trabajo finaliza con las conclusiones, los aportes y el trabajo futuro en el capítulo 6.
AnĂĄlisis de configuraciones de servidores proxy cachĂŠ
4
OBJETIVOS
5
OBJETIVOS
Objetivo General
Determinar los valores de los parámetros básicos de configuración de servidores proxy, obtenidos de las pruebas realizadas a diferentes casos de estudio, con los que se obtenga el mejor rendimiento con una métrica especificada.
Objetivos Específicos
•
Diseñar las arquitecturas de servidores proxy para los diferentes casos de estudio.
•
Establecer las métricas a utilizar en cada uno de los casos de estudio.
•
Diseñar diferentes ambientes virtuales que soporten los diferentes casos de estudio.
•
Seleccionar o implementar un generador de solicitudes Web para cada uno de los diferentes casos de estudio en los ambientes apropiados.
•
Seleccionar o implementar un analizador de archivos log del servidor proxy para obtener las métricas establecidas.
•
Analizar los resultados de las métricas para determinar los valores de los parámetros que mejor se ajustan a cada caso de estudio.
AnĂĄlisis de configuraciones de servidores proxy cachĂŠ
6
PROTOCOLO HTTP Y SERVIDORES PROXY CACHÉ
7
PROTOCOLO HTTP Y SERVIDORES PROXY CACHÉ RETARDOS EN LA TRANSFERENCIA DE INFORMACIÓN
Idealmente, las redes de computadores deberían ofrecer un servicio de transferencia inmediata, sin retardos ni pérdida de datos. Sin embargo, la realidad es muy distinta, debido a las restricciones físicas de los diferentes medios de transmisión utilizados (Kurose, 2010). Cada medio de transmisión tiene su campo de acción determinado en términos principalmente de ancho de banda y retardo (Tanenbaum, 2003).
Cuando un mensaje se origina en un host y se dirige a un host de destino, posiblemente debe pasar por una serie de enrutadores intermedios. Cada uno de estos enrutadores necesariamente adiciona un retardo a la transmisión del paquete que lleva el mensaje. Al sumar todos los retardos que sufre un paquete desde su host origen hasta llegar a su destino, se conoce como el retardo extremo a extremo. En ese retardo extremo a extremo intervienen diferentes clases de retardos: retardo de procesamiento, retardo por colas, retardo de transmisión y retardo de propagación (Kurose, 2010).
Retardo de procesamiento. Ocurre en los enrutadores intermedios y tiene que ver con el tiempo que tarda un enrutador en procesar un datagrama IP antes de reenviarlo por alguna interfaz de salida. El procesamiento consiste en tareas como la revisión de la suma de comprobación del encabezado del datagrama IP, la reducción del campo TTL, la generación de una nueva suma de comprobación y la toma de decisión sobre la interfaz de salida necesaria para enviar el paquete al siguiente enrutador.
Retardo por colas. Este retardo ocurre en los enrutadores cuando una interfaz de salida está ocupada, y llega un al menos otro paquete que debe salir por la misma interfaz. En ese caso, el paquete
o paquetes que acaban de llegar deberán ser
Análisis de configuraciones de servidores proxy caché
almacenados en los buffers de la interfaz del enrutador (si hay espacio disponible), esperando a ser atendidos. El tiempo que debe esperar un paquete en el buffer de una de las interfaces de salida de un enrutador se llama retardo por colas y es dependiente del tráfico.
Retardo de transmisión. El retardo de transmisión es el tiempo que tarda un paquete en ser transmitidos todos los bits de un paquete de tamaño L (medido en bits) al enlace de comunicación a una velocidad R determinada por la capacidad de transmisión del enlace (medida en bits por segundo). Es decir, el retardo de transmisión se puede calcular como L/R y el resultado se mide en segundos (Kurose, 2010).
Retardo de propagación. Es el tiempo que toma un bit en propagarse de un extremo a otro de un enlace. Los bits se desplazan a la velocidad de propagación del enlace, la cual depende de las propiedades físicas del medio de transmisión utilizado. Esta velocidad de propagación usualmente varía entre 2 x 108 m/s y 3 x 108 m/s. El retardo de propagación entonces se calcula como el cociente entre la longitud del medio físico o distancia entre los enlaces d (medido en metros) sobre la velocidad s (medida en metros/seg), es decir, el retardo de propagación se puede calcular como d/s y se mide en segundos (Kurose, 2010).
Para entender mejor el retardo de transmisión y el retardo de propagación, considere los ejemplos a continuación.
¿Cuánto tiempo tarda la transmisión y propagación de un paquete de 1000 bytes sobre un enlace de 2500 Km de longitud, a una velocidad de 2.5 x 108 m/s y una velocidad de transmisión de 2 Mbps?
Retardo de transmisión =
1000 bytes 8000 bits 4 seg 2 Mbps = 2000000 bits / seg = 1000 =4ms
8
PROTOCOLO HTTP Y SERVIDORES PROXY CACHÉ
2500 Km
2500 Km
9
1 seg
Retardo de propagación = 2 .5× 108 m/ seg = 250000 Km /seg = 100
= 10 ms
LA WEB Y EL PROTOCOLO HTTP
Hasta comienzos de la década de 1990 Internet fue usada principalmente por investigadores, académicos y estudiantes universitarios para entrar en hosts remotos, para transferir archivos de un host local a un host remoto y viceversa y para recibir y enviar correo electrónico. Aunque esas aplicaciones fueron (y continúan siendo) extremadamente útiles, Internet fue esencialmente desconocida fuera de la comunidad académica y de investigación (Kurose, 2010). Luego, a comienzos de la década de 1990, surgió una nueva aplicación, la World Wide Web, una aplicación de Internet que permite enlazar información, representada generalmente en forma de páginas Web, las cuales pueden contener texto, gráficas, animaciones, audio, video e hipervínculos. Los enlaces dentro de las páginas Web permiten conectar una página Web con otros recursos, bien sea localmente o en servidores remotos, sin necesidad de conocer la real ubicación del recurso (Hofmann, 2005).
El principal atractivo para la mayoría de los usuarios es que la Web permite que los usuarios reciban lo que quieren y en el momento que lo deseen. Además, los hipervínculos y motores de búsqueda ayudan a los usuarios a navegar a través de un enorme conjunto de sitios Web (Kurose, 2010).
Protocolo HTTP
HTTP (HyperText Transfer Protocol – Protocolo de transferencia de hipertexto) es un protocolo de la capa de aplicación del modelo TCP/IP y es el corazón de la Web. Está definido en los RFC 1945 (Berners-Lee, 1996) y 2616 (Fielding, 1999). HTTP es implementado por dos tipos de programas: un programa cliente y un programa servidor. El programa cliente y el programa servidor son ejecutados en diferentes
Análisis de configuraciones de servidores proxy caché
hosts y se comunican entre sí mediante el intercambio de mensajes HTTP. El protocolo HTTP define la estructura de esos mensajes y la forma son intercambiados por el cliente y el servidor (Kurose, 2010).
Página Web
Una página Web (también llamado documento Web) se compone de objetos. Un objeto es simplemente un archivo que puede ser HTML, una imagen JPEG, un applet de Java, o un clip de video. Todo objeto Web es alcanzable mediante un único URL (Kurose, 2010). Un URL (Uniform Resourse Locator – Localizar Uniforme de recursos) es la forma más común de identificar un recurso Web. Un URL describe la ubicación específica de un objeto en un servidor Web particular, indicando de manera precisa y sin ambigüedad el nombre de host, el número de puerto y la ruta completa del objeto en
ese
servidor
(Gourley,
2002).
Por
ejemplo,
al
observar
el
URL:
http://grid.uniquindio.edu.co/proyecto437/informe.pdf se pueden destacar el nombre de host: grid.uniquindio.edu.co y la ruta del objeto en ese host1 /proyecto437/informe.pdf.
La mayoría de las páginas Web se componen de un archivo HTML y varios objetos que son referenciados dentro del archivo HTML. Por ejemplo, si una página Web contiene texto HTML y cinco imágenes JPEG, entonces la página Web tiene seis objetos: el archivo HTML base más las cinco imágenes. El archivo HTML base tiene referencias a los otros objetos en la página los cuales son especificados mediante los URLs de los objetos.
Los navegadores (conocidos como clientes HTTP) más populares son Internet Explorer (Microsoft, Internet Explorer, 2010) y Mozilla Firefox (Mozilla, 2010), 1
El nombre grid.uniquindio.edu.co es un ejemplo de un nombre de dominio
completamente cualificado (Full Qualify Domain Name) y sus detalles conceptuales se salen del alcance de este documento.
10
PROTOCOLO HTTP Y SERVIDORES PROXY CACHÉ
11
mientras que los servidores Web más conocidos son Apache Web Server (Apache, 2010) y Microsoft Internet Information Server (Microsoft, 2010).
El protocolo HTTP define la forma como los clientes Web solicitan objetos a un servidor y cómo los servidores los transfieren a los clientes. Cuando un usuario solicita una página Web (o hace clic en un enlace), el navegador genera y envía un mensaje de solicitud HTTP al servidor. El servidor recibe las solicitudes y responde con mensajes de respuesta HTTP que contienen los objetos solicitados. La interacción entre el cliente y el servidor es ilustrada en la Figura 1 Interacción entre cliente y servidor Web (Kurose, 2010).
Figura 1 Interacción entre cliente y servidor Web
El protocolo HTTP usa TCP como protocolo de capa de transporte. El cliente HTTP debe iniciar una conexión TCP con el servidor y una vez que está establecida, el navegador y el servidor intercambian los mensajes de solicitud y respuesta. Dado que TCP proporciona un servicio de transferencia de datos confiable, el protocolo HTTP supone una entrega correcta de los datos en el destino sin necesidad de preocuparse por la pérdida de datos o los detalles de cómo TCP recupera los datos perdidos o la forma como los reordena antes de ser entregados en el destino (Kurose, 2010).
Análisis de configuraciones de servidores proxy caché
Mensajes HTTP
El protocolo HTTP permite la interacción entre un programa cliente y un programa servidor a través del intercambio de mensajes. Existen dos tipos de mensajes HTTP: el mensaje de solicitud ( H
T
T
P
R
e
q
u
e
s
) y el mensaje de respuesta ( H
t
T
T
P
R
e
s
p
o
n
s
e
). A
continuación se hace una breve descripción del formato de cada uno de ellos.
Mensaje de solicitud HTTP
Un mensaje de solicitud HTTP tiene la estructura que se puede apreciar en la Figura 2Figura 2.
Figura 2 Formato general de un mensaje de solicitud HTTP
Algunos aspectos a destacar sobre los mensajes de solicitud HTTP son los siguientes: El mensaje está escrito en texto ASCII, lo que significa que las personas pueden entenderlo; el mensaje se compone de una línea de solicitud HTTP ( r
serie de líneas de encabezado ( h
a
e
e
l
i
n
e
secuencia de caracteres \r\n que significan
u
e
s
t
l
i
n
e
) y una
), cada una de ellas finalizada con una
r
d
q
e
s
a
C
r
r
a
i
r
g
e
R
e
t
u
n
y
L
i
n
e
F
e
e
d
. El mensaje
termina con una línea en blanco. Un ejemplo de un mensaje de solicitud HTTP se puede apreciar en la Figura 3 .
Figura 3 Ejemplo de un mensaje de solicitud HTTP
12
PROTOCOLO HTTP Y SERVIDORES PROXY CACHÉ
13
A continuación una explicación más detallada del mensaje de solicitud HTTP de la Figura 3:
•
La línea de solicitud tiene tres campos: el campo método, el campo URL y el campo versión del protocolo HTTP (Gourley, 2002). El campo método puede tomar valores como: GET, POST, HEAD, PUT y DELETE. La gran mayoría de las solicitudes HTTP usan el método GET. El método GET es usado cuando el navegador solicita un objeto, con el objeto solicitado identificado en el campo URL. En este ejemplo, el navegador está solicitando mediante el método GET el objeto
index.html
cuya
ruta
completa
en
el
servidor
es
/proyecto437/index.html. La versión utilizada en el ejemplo es HTTP 1.1.
•
La línea de encabezado Host: grid.uniquindio.edu.co\r\n especifica el host en el cual está almacenado el objeto.
•
Con la línea de encabezado Connection: Keep-Alive\r\n, el navegador está diciendo al servidor que espera que la conexión no se cierre después de enviar el objeto solicitado (Gourley, 2002).
•
La línea de encabezado User-Agent: Mozilla/4.0 (compatible; MSIE 8.0)\r\n es usado por las aplicaciones cliente para identificarse. El valor cambia entre los distintos navegadores y entre las versiones de un navegador particular (Gourley, 2002). Esta línea de encabezado es útil porque el servidor puede enviar diferentes versiones del mismo objeto para diferentes versiones de navegadores, aunque todas sean accedidas usando el mismo URL (Kurose, 2010). En este caso, se trata de un navegador Microsoft Internet Explorer 8.0 (Microsoft, Internet Explorer, 2010), compatible con Mozilla 4.0.
•
La línea de encabezado Accept-Language: es-co\r\n, es una de las muchas formas de negociar el contenido disponible en HTTP. En este caso, el cliente le
Análisis de configuraciones de servidores proxy caché
informa al servidor que el Español de Colombia es el idioma preferido (Kurose, 2010).
Además de las líneas de solicitud y de encabezado ya analizadas, al final de un mensaje de solicitud HTTP se puede apreciar una línea en blanco (terminada con \r\n) y un componente adicional llamado
E
n
t
i
t
y
b
o
d
y
. El
E
n
t
i
t
y
b
o
d
y
puede contener texto plano,
datos binarios, o estar vacío. Cuando se usa el método GET, el
e
n
t
i
t
y
b
o
d
y
es vacío,
pero es usado con el método POST, por ejemplo cuando el usuario diligencia un formulario. Con un mensaje POST, el usuario está solicitando una página Web del servidor, pero el contenido específico de la página Web que recibirá como respuesta depende de lo que el usuario escribió en los campos del formulario (Gourley, 2002).
Es posible usar formularios HTML con el método GET, caso en el que los datos escritos en el formulario se pasan a través del URL solicitado. Por ejemplo, si un formulario usa el método GET (Kurose, 2010).
Figura 4 Uso del método GET con formularios – Parte 1
Figura 5 Uso del método GET con formularios – Parte 2
14
PROTOCOLO HTTP Y SERVIDORES PROXY CACHÉ
15
Observe que en la Figura 5 que luego de diligenciar el formulario de la Figura 4, el URL lleva un símbolo
?
seguido de parejas atributo=valor (tranword=handshake,
dict=enes y B10=Search). En este caso, el servidor recibe los datos del formulario para encontrar la traducción de la palabra handshake usando un diccionario InglésEspañol y los datos son enviados luego de hacer clic sobre el botón Search.
El método HEAD es similar al método GET. Cuando un servidor recibe una solicitud con el método HEAD, responde con un mensaje HTTP, pero no envía el objeto solicitado. Este método es usado para la depuración de aplicaciones. Los métodos PUT y DELETE permiten a los usuarios subir un objeto a un directorio específico o borrarlo (Kurose, 2010).
Otras líneas de encabezado para los mensajes de solicitud [Tanenbaum] [Gourley]:
•
Accept: Indica el tipo de objetos que el cliente puede manejar. Es decir, el tipo de contenido que el cliente usa. El valor puede incluir una lista de valores de calidad (q) que le indican al servidor el grado de preferencia, siendo 1.0 el más alto y 0.0 el más bajo. Por ejemplo, Accept: image/gif;q=1.0.
•
Accept-Charset: Indica los conjuntos de caracteres que son aceptables o preferidos por el cliente. El valor es una lista de conjuntos de caracteres, y puede incluir un valor de calidad como en el caso anterior. Por ejemplo: Accept-Charset: iso-latin-1. Otros conjuntos de caracteres podrían ser: iso8859-13 y US-ASCII.
•
Authorization: Es utilizada para enviar una indicación que el cliente se puede autenticar con el servidor. Esta línea de encabezado es enviada cuando el servidor responde con el código de estado 401 Authentication Required. El valor de esta línea de encabezado depende del esquema de autenticación que use el servidor.
Análisis de configuraciones de servidores proxy caché
•
Date: Indica la fecha y hora en la que es enviado el mensaje de solicitud.
Mensaje de respuesta HTTP
Un mensaje de respuesta HTTP tiene la siguiente estructura que se muestra en la Figura 6.
Figura 6 Formato general de un mensaje de respuesta HTTP
Algunos aspectos a destacar acerca de los mensajes de respuesta HTTP son los siguientes. El mensaje está escrito en texto ASCII, al igual que el mensaje de solicitud; el mensaje se compone de una línea de solicitud estado ( s
líneas de encabezado ( h
a
e
e
l
caracteres \r\n que significan
i
n
e
a
C
t
u
s
l
i
n
e
) y una serie de
), cada una de ellas finalizada con una secuencia de
r
d
a
t
s
r
r
a
i
r
g
e
R
e
t
u
n
encabezado sigue una línea en blanco y luego el
y e
n
L
i
t
n
i
F
e
t
y
b
e
o
e
d
d
y
. Después de las líneas de con el objeto solicitado (si
corresponde). Un ejemplo de un mensaje de solicitud HTTP se puede apreciar en la Figura 7.
Figura 7 Ejemplo de un mensaje de respuesta HTTP
A continuación una explicación más detallada del mensaje de respuesta HTTP de la Figura 7:
16
PROTOCOLO HTTP Y SERVIDORES PROXY CACHÉ
17
La línea de estado tiene tres campos: el campo de versión del protocolo, un
•
código de estado y un mensaje asociado con el código de estado. En este ejemplo, la versión del protocolo es HTTP/1.1, el código numérico es un número de tres dígitos que describe lo que pasó con la solicitud, en este caso 200 y un mensaje (OK) que indican que la solicitud ha sido recibida y procesada correctamente , por lo que el objeto será enviado al cliente en el entity body (Gourley, 2002).
La línea de encabezado Date: Wed, 07 Oct 2009 20:09:43 GMT\r\n especifica
•
la fecha y hora de creación del mensaje de respuesta HTTP (Gourley, 2002).
La línea de encabezado Server: Apache/1.3.0 (Unix)\r\n indica que el mensaje
•
fue generado por un servidor Web Apache (Kurose, 2010).
La línea de encabezado Last-Modified: Tue, 1 Sep 2009 14:29:17 GMT\r\n
•
especifica la fecha de la última modificación (Kurose, 2010).
La línea de encabezado Content-Length: 4565\r\n indica el tamaño del objeto
•
que se está enviando, medido en bytes (Kurose, 2010).
La línea de encabezado Content-Type: text/html\r\n indica que el objeto en el
• e
n
t
i
t
y
b
o
d
y
es texto HTML (Kurose, 2010).
El código de estado y la frase asociada indican el resultado de la solicitud. Algunos códigos de estado de uso común y sus correspondientes frases son (Kurose, 2010):
200 OK: La solicitud es exitosa y la información es retornada en la respuesta.
Análisis de configuraciones de servidores proxy caché
301 Moved Permanently: El objeto solicitado ha sido movido permanentemente; el nuevo URL es especificado en la línea de encabezado Location: del mensaje de respuesta. El software cliente automáticamente recuperará el nuevo URL.
400 Bad Request: Este es un código de error genérico el cual indica que la solicitud no pudo ser entendida por el servidor.
404 Not Found: El documento solicitado no existe en este servidor.
505 HTTP Version Not Supported: La versión del protocolo HTTP no es soportada por este servidor.
En general, los códigos de estado que se envían en un mensaje de respuesta HTTP se pueden resumir de la siguiente forma [Tanenbaum]:
1xx: Información. 2xx: Éxito. 3xx: Redirección. 4xx: Error en el cliente. 5xx: Error en el servidor.
Para establecer las líneas de encabezado que serán incluidas en un mensaje de solicitud HTTP, los navegadores usan el tipo de navegador, la versión del protocolo HTTP y algunos parámetros de configuración del usuario, entre otras consideraciones. De igual manera, los servidores Web especifican de acuerdo con el tipo de servidor y algunos parámetros de configuración las líneas de encabezado que son incluidas en los mensajes de respuesta (Kurose, 2010).
Otras líneas de encabezado para los mensajes de respuesta (Tanenbaum, 2003) y (Gourley, 2002):
18
PROTOCOLO HTTP Y SERVIDORES PROXY CACHÉ
19
Content-Encoding: Indica la forma como se codificó el contenido. Por ejemplo: Content-Encoding: gzip.
Content-Language: Indica el idioma natural utilizado en la página. Por ejemplo: Content-Language: en,fr.
RENDIMIENTO DEL PROTOCOLO HTTP
El rendimiento en el protocolo HTTP ha sido una constante preocupación desde sus inicios. El uso de conexiones persistentes o no persistentes, junto con el manejo de caché son condiciones importantes que pueden afectar el rendimiento de este protocolo.
Tipos de conexiones en el protocolo HTTP
Un navegador se conecta a un servidor Web estableciendo una conexión TCP, generalmente en el puerto 80. En muchas aplicaciones de Internet, el cliente y el servidor se comunican durante un período de tiempo dentro del cual el cliente hace una serie de solicitudes y el servidor responde cada una de ellas. Dependiendo de la aplicación y la forma como se usa, la serie de solicitudes puede ser hecha en forma consecutiva, periódicamente a intervalos regulares, o intermitentemente.
Si cada pareja de mensajes solicitud/respuesta debería ser enviada en una conexión TCP separada, se conoce como conexión no persistente. En cambio, si todas las solicitudes y sus correspondientes respuestas son enviadas sobre la misma conexión TCP se dice que hay una conexión persistente. HTTP, en la versión 1.1 del protocolo, la versión actual, usa una conexión persistente por defecto (Kurose, 2010).
Análisis de configuraciones de servidores proxy caché
HTTP con conexiones no persistentes
Los pasos para transferir una página Web del servidor al cliente para el caso de conexiones no persistentes se describen a continuación. Suponga que la página Web consiste en un archivo HTML base y cinco imágenes JPEG, y que los seis objetos residen en el mismo servidor. Además suponga que el URL para el archivo HTML base es: http://grid.uniquindio.edu.co/proyecto437/index.html. Este es un escenario convencional (Kurose, 2010):
1. El
cliente
HTTP
inicia
una
conexión
TCP
con
el
servidor
Web
grid.uniquindio.edu.co en el puerto 80, el cual es el número de puerto por defecto para el protocolo HTTP. 2. El cliente HTTP envía un mensaje de solicitud HTTP al servidor. El mensaje de solicitud incluye el nombre de ruta /proyecto437/index.html. 3. El servidor HTTP recibe el mensaje de solicitud, recupera el objeto /proyecto437/index.html del disco, encapsula el objeto en un mensaje de respuesta HTTP, y lo envía al cliente. 4. El servidor HTTP dice a TCP que cierre la conexión TCP cuando esté seguro que el cliente ha recibido la respuesta correctamente. 5. El cliente HTTP recibe el mensaje de respuesta y la conexión TCP termina. El mensaje indica que el objeto encapsulado es un archivo HTML. El cliente extrae el archivo del mensaje de respuesta, examina el archivo HTML y busca las referencias de los otros objetos. 6. Los primeros cuatro pasos son repetidos por cada uno de los demás objetos JPEG referenciados.
Cuando el navegador recibe la página Web, la muestra al usuario. Dos navegadores diferentes pueden interpretar (mostrar al usuario) una página Web en forma un tanto diferente. HTTP no tiene nada que ver con la forma como el cliente interpreta la página Web. Las especificaciones de HTTP (Berners-Lee, 1996) y (Fielding, 1999)
20
PROTOCOLO HTTP Y SERVIDORES PROXY CACHÉ
21
definen solo el protocolo de comunicación entre el programa cliente HTTP y el programa servidor HTTP (Kurose, 2010).
Los pasos ilustrados usan conexiones no persistentes, donde cada conexión TCP es cerrada después que el servidor envía los objetos. Note que cada conexión TCP transporta exactamente un mensaje de solicitud y uno de respuesta. Así, en este ejemplo,
cuando
un
usuario
solicita
la
página
http://grid.uniquindio.edu.co/proyecto437/index.html,
Web se
asociada deben
al
URL
crear
seis
conexiones TCP (Kurose, 2010).
Por lo regular, los navegadores actuales pueden manejar entre 5 y 10 conexiones TCP en paralelo con el fin de agilizar la descarga de los objetos. Es importante tener en cuenta que el uso de conexiones paralelas reduce el tiempo de respuesta del servidor (Kurose, 2010).
Para hacer una estimación de la cantidad de tiempo que transcurre desde cuando el cliente solicita un archivo base HTML hasta que el archivo completo es recibido en el cliente se acostumbra definir el round trip time (RTT) como el tiempo que toma un paquete pequeño en viajar del cliente al servidor y volver al cliente. El RTT incluye el retardo de propagación del paquete, el delay por colas en enrutadores y switches intermedios, y el delay por procesamiento del paquete (Kurose, 2010).
Análisis de configuraciones de servidores proxy caché
Figura 8 Estimación del tiempo necesario para descargar un objeto de un servidor Web
Como se muestra en la Figura 8, cuando un usuario hace clic en un enlace, el navegador inicia una conexión TCP entre él y el servidor Web. Esta solicitud de conexión se conoce como
r
t
h
w
e
e
-
a
a
y
-
h
a
n
d
s
– el cliente envía un pequeño
k
h
e
segmento TCP al servidor, el servidor acusa el recibo y responde con un pequeño segmento TCP y finalmente, el cliente envía de vuelta otro acuse de recibo al servidor. El tiempo que duran las primeras dos partes del
r
t
h
w
e
e
-
a
a
y
RTT. Después de completar las primeras dos partes del
-
a
h
n
d
s
r
t
h
e
w
e
e
-
equivale a un
k
h
a
a
y
-
h
a
n
d
s
cliente envía el mensaje de solicitud HTTP combinado con la tercera parte del w
a
a
y
-
h
a
n
d
s
h
k
e
, el
k
h
e
r
t
h
e
e
-
en la solicitud de conexión TCP. Una vez que el mensaje de solicitud
llega al servidor, el servidor envía el archivo HTML base en la conexión TCP. Esta solicitud/respuesta HTTP consume otro RTT. Así, aproximadamente, el tiempo total de una respuesta es 2 RTTs más el tiempo de transmisión del archivo HTML (Kurose, 2010).
22
PROTOCOLO HTTP Y SERVIDORES PROXY CACHÉ
23
HTTP con conexiones persistentes
Con conexiones persistentes, el servidor deja abierta la conexión TCP después de enviar una respuesta. Las solicitudes siguientes y sus correspondientes respuestas entre el mismo cliente y el servidor pueden ser enviadas sobre la misma conexión.
En particular, una página Web completa (en el ejemplo anterior, compuesta de un archivo HTML base y las cinco imágenes JPEG) pueden ser enviadas sobre una sola conexión TCP persistente. Estas solicitudes por objetos pueden ser hechas una tras otra, sin esperar las respuestas de las solicitudes pendientes (usando
p
i
p
e
l
i
n
i
n
g
), para
agilizar la descarga. Cuando el servidor recibe las solicitudes en secuencia, envía los objetos uno tras otro. La Figura 9 muestra las diferencias en el uso de conexiones persistentes con y sin pipelining. El modo por defecto de HTTP usa conexiones persistentes con pipelining (Kurose, 2010).
Figura 9 Diferencia entre conexiones persistentes con y sin pipelining
Caché
Un caché es un mecanismo ampliamente utilizado en las ciencias de la computación para mejorar el desempeño de algunos sistemas al ofrecer la posibilidad de almacenar
Análisis de configuraciones de servidores proxy caché
algunos datos que probablemente serán usados en el futuro en un lugar más cercano de donde están ubicados usualmente. Entonces, si el sistema necesita un elemento, primero lo solicita al caché (Davison, A Web Caching Primer, 2001). Un caché está presente en diferentes contextos. Entre los más destacados se encuentran: la memoria caché (en los microprocesadores), el caché de disco, el caché de Web y el caché en los servidores DNS.
En el caché de memoria, el objetivo es disminuir el tiempo de envío de datos desde la memoria principal de un computador al microprocesador. El caché de los microprocesadores modernos es una memoria, que comparada con la memoria principal es más pequeña, más costosa y con un tiempo de acceso mucho menor, lo que la hace mucho más rápida. Esta memoria tiene un tamaño fijo construido dentro del microprocesador y se llama caché de nivel 1 (L1). La mayoría de los computadores personales también traen una memoria caché externa llamada caché de segundo nivel (L2) (Gómez, 2007).
El caché de disco trabaja bajo el mismo principio de la memoria caché de los microprocesadores. El caché está ubicado en la memoria principal (RAM) y el objetivo es aumentar la velocidad de acceso a los datos que están en el disco. Los datos accedidos más recientemente del disco (y los sectores adyacentes) son almacenados en el caché. Cuando un programa necesita acceder a los datos del disco, primero revisa si los datos están en el caché. El caché de disco puede mejorar significativamente el desempeño de aplicaciones, porque acceder datos de la RAM es mucho más rápido que hacerlo del disco duro (Gómez, 2007).
El caché de Web es también llamado servidor proxy. Un servidor proxy es un programa intermediario que resuelve las solicitudes HTTP. Un servidor proxy por lo general está ubicado dentro de la red local y su función es mantener copias locales de los objetos Web que han sido solicitados recientemente por sus clientes. Cuando se realiza una solicitud HTTP, primero se busca en el caché para verificar si allí hay una copia del recurso solicitado. Si se encuentra en el caché, no es necesario ir hasta la
24
PROTOCOLO HTTP Y SERVIDORES PROXY CACHÉ
25
fuente original en Internet para dar respuesta a la solicitud. Por el contrario, si no hay una copia del sitio Web en el caché, es el proxy el que se encarga de hacer la solicitud al servidor Web de origen. Cuando recibe los objetos solicitados, el proxy los almacena en caché y los envía al cliente que realizó la solicitud inicialmente. El caché de Web se usa cada vez más, porque aprovecha las conexiones rápidas entre los clientes y el caché, y disminuye significativamente el tráfico en organizaciones con una gran cantidad de usuarios, por ejemplo una universidad (Kurose, 2010).
Los servidores de nombres de dominio en Internet usan ampliamente el caché para mejorar el rendimiento reduciendo el número de mensajes que viajan por la red. Cuando un servidor DNS recibe una respuesta que contiene la pareja (nombre de host, dirección IP), puede guardarla en su memoria local. De este modo, cuando llegue otra consulta para el mismo host, el servidor DNS puede resolver esa consulta rápidamente aún si no es el servidor DNS autoritativo para el host solicitado (Kurose, 2010).
Extendiendo el concepto de caché de disco, los sistemas distribuidos mejoran notablemente su rendimiento si se puede guardar una copia local de datos que se requieren con frecuencia y cuya fuente original es remota. El beneficio real del caché depende de la calidad de los enlaces entre los diferentes sitios del sistema distribuido (Gómez, 2007).
Para medir el rendimiento de un caché, se contabilizan los aciertos y fallos en la búsqueda de los objetos que sean solicitados por los usuarios del caché. Un acierto (hit) se cuenta cada vez que un objeto solicitado está en el caché. Por el contrario, un fallo (miss) se acumula si el objeto solicitado no se encuentra almacenado en el caché (Davison, A Web Caching Primer, 2001). La efectividad del caché es juzgada por su r
, es decir, el número de aciertos (
a
t
(
e
h
a
r
c
i
e
a
t
o
s
+
f
l
l
o
s
homogéneo, el
i
t
s
h
i
t
) dividido entre el número de intentos
) (Provost, 2010). Cuando se trata de objetos que tienen tamaño r
h
i
t
a
t
e
es una medida adecuada, pero si el tamaño de los objetos es
variable, como sucede en la mayoría de las ocasiones, el medida de desempeño. El
r
b
y
t
e
h
i
t
a
t
e
r
b
y
t
e
h
i
t
a
t
e
es una mejor
se define como la cantidad de bytes que suman
Análisis de configuraciones de servidores proxy caché
las solicitudes atendidas por el caché sobre la cantidad de bytes que suman las solicitudes realizadas (Davison, A Web Caching Primer, 2001). Para entender mejor el cálculo del
r
h
i
y del
a
t
t
e
r
b
y
t
e
h
i
t
a
t
e
, observe el siguiente ejemplo:
Suponga que se solicitan tres objetos, el objeto 1 que mide 200 KBytes, el objeto 2 que mide 100 KBytes y el objeto 3 que mide 300 KBytes. Si al hacer la solicitud al caché se obtienen los objetos 1 y el 2, entonces el que el
r
b
y
t
e
h
i
t
a
t
e
r
h
i
t
a
t
e
es 2/3, es decir, un 66.66% mientras
es 1/2 (300 KBytes / 600 KBytes), es decir, el 50%.
Se debe tener en cuenta que no todos los objetos son susceptibles de ser almacenados en caché. Por ejemplo, los objetos que cambian constantemente (por ejemplo el precio del dólar) o los que son particulares de un usuario (por ejemplo el saldo en la cuenta del banco) (Davison, A Web Caching Primer, 2001).
Habitualmente, después de la ocurrencia de una falla de caché (cache miss) el dato que no fue encontrado es almacenado en el caché para tratar de anticiparse a una nueva solicitud por el mismo objeto, aprovechando una propiedad de los sistemas de caché conocida como la localidad temporal. También existe la localidad espacial, la cual consiste en almacenar en caché datos cercanos de aquel que produjo una falla de caché (Davison, A Web Caching Primer, 2001). El aprovechamiento del principio de localidad hace que el caché aumente el desempeño del sistema.
Buscando mejorar aún más el desempeño de muchos sistemas de caché, se utilizan técnicas de caché inteligente, donde se trata de predecir los datos que serán accedidos en el futuro para almacenarlos en el caché. Las estrategias para determinar cuáles datos deben estar en el caché constituyen un problema muy interesante en las ciencias de la computación (Gómez, 2007).
26
PROTOCOLO HTTP Y SERVIDORES PROXY CACHÉ
27
Componentes de un caché
Un caché se puede distinguir por sus componentes los cuales determinan el comportamiento e influyen directamente en su rendimiento. Estos componentes corresponde a la gestión de caché, la política de reemplazo y la estrategia de resolución (D'Orazio, 2005).
La gestión de caché se encarga del direccionamiento de los elementos que se almacenan en el caché. También maneja la búsqueda cuando se necesita extraer algún elemento del caché. La política de reemplazo elige los elementos que serán desalojados del caché cuando no hay suficiente espacio para insertar un nuevo elemento. Por su parte, la estrategia de resolución determina la acción a seguir cuando hay fallas de caché producido por objetos que han sido desalojados o que no han sido almacenados del caché.
Gestión de caché
La gestión de caché se encarga de las políticas de ubicación o direccionamiento de los elementos que se almacenan en el caché, es decir, especifica la forma de acceder a los datos. Además, establece las políticas de escritura y de búsqueda (D'Orazio, 2005).
Las políticas de escritura determinan la forma como se maneja la escritura de objetos que actualmente están almacenados en caché con respecto a la fuente original. Existen dos políticas principales:
Write Back o escritura asincrónica. El objetivo es aplazar la escritura en la fuente original lo más que se pueda para no degradar el desempeño. Si el objeto que se encuentra en el caché ha sido actualizado, se marca para que cuando sea desalojado del caché se actualice la fuente original (Vakali, 2001).
Análisis de configuraciones de servidores proxy caché
Write through o escritura sincrónica. El objetivo es mantener la coherencia entre el caché y la fuente original escribiendo en el caché y luego, en un corto período de tiempo en la fuente original. La principal desventaja es el bajo desempeño con respecto a la escritura
W
r
a
i
t
k
b
e
c
(Vakali, 2001).
La búsqueda es el procedimiento que se realiza cuando se necesita extraer algún elemento del caché. Puede ser secuencial, binaria, basada en árboles ordenados o con técnicas de
a
h
s
h
i
n
g
. Establecer el método de búsqueda adecuado depende del tamaño
del caché y del tiempo de ejecución que se desee manejar (D'Orazio, 2005).
El método de búsqueda debe estar de acuerdo con el tamaño del caché. Así, la búsqueda secuencial puede ser efectiva cuando el caché es pequeño. Sin embargo, para cachés de mayor tamaño, se recomienda el uso de estructuras de datos más sofisticadas que puedan ser más eficientes, como es el caso de listas enlazadas, árboles ordenados o técnicas de
a
h
s
h
i
n
g
(D'Orazio, 2005).
Política de reemplazo
Para tener un buen desempeño de caché es necesario mantener almacenados en caché los objetos populares y reemplazar aquellos que son usados rara vez (HewlletPackard, 2009). Sin embargo, al almacenar elementos en el caché llega el momento en el que se llena. En ese caso, es necesario eliminar objetos del caché. Para seleccionar el objeto u objetos que deberán ser desalojados del caché cuando no hay espacio suficiente para almacenar un objeto nuevo, se aplica una política de reemplazo. Se pueden usar técnicas basadas en tiempo, en frecuencia o en el tamaño de los objetos que están almacenados en el caché o que se quieren guardar allí (Davison, A Web Caching Primer, 2001). Las basadas en tiempo eliminan el ítem más reciente o más antiguo en el caché para dar paso al nuevo elemento que se va a insertar en el caché. Con base en la frecuencia de acceso, se puede eliminar el elemento que tenga menor cantidad de uso. Si se tiene en cuenta el tamaño de los objetos, se puede desalojar del caché el elemento más grande o el más pequeño. Otra técnica es la aleatoria donde se
28
PROTOCOLO HTTP Y SERVIDORES PROXY CACHÉ
29
elimina cualquier elemento al azar (Advanced Networking Applications - ANA) y (D'Orazio, 2005).
Las políticas de reemplazo más usadas son (Advanced Networking Applications ANA):
•
Aleatoria: Se elimina cualquier elemento.
•
LRU: Least Recently Used. El elemento que se desaloja del caché es el menos usado recientemente.
•
LFU: Least Frecuently Used. Con esta política de reemplazo se elimina del caché el elemento menos frecuentemente usado.
•
LFRU: Combina LRU y LFU.
•
Más grande: Se desaloja del caché el objeto de mayor tamaño.
•
Más pequeño: Se desaloja del caché el objeto de menor tamaño.
•
FIFO: First In First Out. El elemento que se elimina del caché es el primer elemento que ha ingresado, es decir, el que lleva más tiempo en el caché.
•
LIFO: Last In First Out El elemento que se elimina del caché es el último elemento que ha ingresado, es decir, el que lleva menos tiempo en el caché.
•
GreedyDual-Size (GD-S): Se mantiene un peso para cada objeto almacenado en el caché. El peso es calculado como una relación entre el tamaño del objeto, la frecuencia de acceso y la edad del objeto almacenado en el caché (HewlletPackard, 2009).
Estrategia de resolución
La estrategia de resolución determina la acción a seguir cuando hay fallos de caché producidos por objetos que han sido desalojados o que no están almacenados en el caché. Un cache miss se resuelve buscando el objeto, bien sea en un caché de nivel superior (si se trata de un caché jerárquico) o en la fuente original (Gómez, 2007).
Análisis de configuraciones de servidores proxy caché
Algunas políticas de resolución son las siguientes:
Storage: Si el objeto solicitado no se encuentra en el caché, se busca directamente en el repositorio original de datos. Parent: Si el objeto solicitado no se encuentra en el caché, se busca en el caché de nivel superior. Sibling: Si el objeto solicitado no se encuentra en el caché, se busca en un caché del mismo nivel.
SERVIDORES PROXY CACHÉ
Con la popularidad de Internet, tanto los enrutadores como los enlaces de comunicación presentan frecuentes índices de sobrecarga. Una solución aceptada en forma universal es el uso de caché para disminuir el tiempo en que son entregados los objetos solicitados. Según (Davison, A survey of proxy cache evaluation techniques, 1999) existen tres clases de caché clásicos, dependiendo de la ubicación: Caché en el programa cliente (por ejemplo, el navegador), caché compartido en la red de los clientes (comúnmente llamado servidor proxy caché) y caché frente a un servidor Web (también llamado Reverse Proxy o Surrogate).
En esta sección se tratará el tema de servidores proxy caché, los cuales almacenan objetos Web que han sido solicitados con el fin de poder entregarlos más rápidamente en caso de ser solicitados en el futuro.
Un servidor proxy caché puede ser útil especialmente si las páginas que son almacenadas en el caché son accedidas con frecuencia por los usuarios (Tanenbaum, 2003). Típicamente, un caché Web es un servicio que ofrece un proveedor de acceso a Internet, una Universidad o una empresa a través de un servidor proxy, el cual actúa como intermediario (Kurose, 2010). Un servidor proxy caché ofrece unos beneficios tales como la reducción del consumo de ancho de banda, la reducción de carga en los
30
PROTOCOLO HTTP Y SERVIDORES PROXY CACHÉ
31
servidores, la disminución en la latencia percibida por el usuario y el aumento de la disponibilidad, en algunos casos. Sin embargo, también presenta sus inconvenientes, la posibilidad de entregar objetos desactualizados al usuario y la imprecisión en las estadísticas debido a la falta de registro de acceso en el servidor Web de todas las solicitudes (Davison, A Web Caching Primer, 2001).
Para poder utilizar un caché, como en la Figura 10, el navegador de los usuarios debe ser configurado para que todas las solicitudes (salvo algunas excepciones previamente establecidas) se dirijan al servidor proxy especificado en lugar de hacerlo hacia el servidor de origen de los objetos solicitados. Si el servidor proxy tiene el objeto lo entrega de inmediato, en caso contrario, el servidor hace la solicitud al servidor de origen y al obtener el objeto, lo almacena en el caché para usarlo en el futuro (Tanenbaum, 2003).
Además, puede ser conveniente utilizar conexiones
persistentes entre el proxy y los servidores de origen para reducir el tiempo de establecimiento de conexión TCP para descargar objetos Web, ya que la mayoría de los objetos solicitados por los usuarios son pequeños (Davison, A Web Caching Primer, 2001).
Figura 10 Solicitudes Web mediante servidor proxy caché
Lo que hace más atractivo un caché Web son beneficios potenciales frente a la reducción en el consumo de ancho de banda, la disminución en la latencia experimentada por el usuario y el ahorro en la carga que se impone sobre los
Análisis de configuraciones de servidores proxy caché
servidores de origen (Davison, A Web Caching Primer, 2001). Sin embargo, existen algunos inconvenientes que pueden que pueden afectar a los usuarios.
El principal problema es la posibilidad de entregar objetos desactualizados con respecto a los que se encuentren almacenados en el servidor de origen. Otro aspecto a considerar es que el uso de caché mejora la latencia solo si se presentan aciertos en la búsqueda de los objetos en el caché, mientras que la ocurrencia de fallas de caché generalmente disminuyen la velocidad en una pequeña cantidad. Además, el caché es altamente dependiente de la popularidad de los objetos solicitados y esta popularidad depende en principalmente de los usuarios y del hecho que muchos objetos son solicitados una sola vez (Davison, A Web Caching Primer, 2001).
Un aspecto a tener en cuenta es que no todos los contenidos son susceptibles de ser almacenados en caché, bien sea porque se modifiquen con demasiada frecuencia o porque se trate de objetos que son producidos “al vuelo” y dependen de los datos enviados por el usuario en un formulario Web.
Análisis de desempeño de una solución basada en el uso de un servidor proxy caché
Suponga
que
un
navegador
solicita
http://grid.uniquindio.edu.co/proyecto437/logo.jpg
al
el servidor
objeto Web
grid.uniquindio.edu.co. A continuación el procedimiento que se realiza, tanto en el cliente como en el servidor.
1. El navegador establece una conexión TCP al servidor proxy y le envía un mensaje de solicitud HTTP por el objeto logo.jpg. 2. El servidor proxy verifica si tiene una copia del objeto almacenada localmente. Si la tiene, lo retorna al navegador del cliente dentro de un mensaje de respuesta HTTP.
32
PROTOCOLO HTTP Y SERVIDORES PROXY CACHÉ
33
3. Si el servidor proxy no tiene el objeto, abre una conexión TCP al servidor origen, es decir a grid.uniquindio.edu.co. El proxy entonces envía un mensaje de solicitud HTTP al servidor a través de la conexión TCP. Después de recibir esta solicitud, el servidor origen envía el objeto dentro de un mensaje de respuesta HTTP al servidor proxy. 4. Cuando el servidor proxy recibe el objeto, lo guarda en su espacio de almacenamiento y envía una copia al navegador del cliente, dentro de un mensaje de respuesta HTTP (sobre una conexión TCP existente entre el navegador del cliente y el servidor proxy).
Note que un servidor proxy caché es a la vez cliente y servidor. Cuando recibe solicitudes del cliente y envía las respuestas al navegador, es un servidor. Cuando envía solicitudes y recibe respuestas de un servidor de origen, es un cliente (Kurose, 2010).
Los
servidores
proxy
han
sido
desarrollados
porque
pueden
disminuir
sustancialmente el tiempo de respuesta para una solicitud de un cliente y porque pueden reducir sustancialmente el tráfico en el enlace a Internet de una institución. Mediante la reducción de tráfico, la institución no tiene que aumentar el ancho de banda tan rápidamente, y de ese modo puede reducir costos (Kurose, 2010).
Considere el siguiente ejemplo, tomado de (Kurose, 2010), en el contexto de la Figura 11¡Error! No se encuentra el origen de la referencia.. Esta figura muestra la red institucional de una empresa e Internet. La red institucional es una red LAN con una capacidad de transmisión de 100 Mbps (100 millones de bits por segundo). Un enrutador en la red institucional y otro en Internet están conectados mediante un enlace de 20 Mbps (20 millones de bits por segundo). Los servidores de origen están conectados a Internet pero no se sabe exactamente su localización. Suponga que el tamaño promedio de cada objeto es 1.000.000 de bits y que la tasa promedio de solicitudes de los navegadores de la institución a los servidores de origen es de 20 objetos por segundo. Suponga también que los mensajes de solicitud HTTP son muy
Análisis de configuraciones de servidores proxy caché
pequeños y la sobrecarga de tráfico es despreciable. Finalmente asuma que el tiempo estimado desde cuando el enrutador en el lado de Internet del enlace reenvía un mensaje de solicitud HTTP hasta que recibe la respuesta es de 2 segundos (Kurose, 2010).
Figura 11 Cuello de botella entre una red institucional e Internet
Considere el tiempo de respuesta total como el tiempo desde que el navegador solicita un objeto hasta que lo recibe. Una estimación de este tiempo es la suma del delay de la LAN, el delay de acceso y el delay de Internet (Kurose, 2010).
Con 20 solicitudes de un objeto por segundo en la LAN, y con un tamaño promedio de 1.000.000 por objeto, se están realizando solicitudes de 20.000.000 de bits cada segundo.
Así, el porcentaje de utilización de la LAN es: 20Mbps / 100Mbps = 0.20 = 20%.
Si todas las solicitudes deben salir hacia Internet, entonces el porcentaje de utilización del canal de acceso es: 20Mbps / 20Mbps = 1.00 = 100%.
Con una utilización del 20% sobre la LAN, el retardo de transmisión es de algunos milisegundos; por lo que para este escenario el retardo de propagación es tan
34
PROTOCOLO HTTP Y SERVIDORES PROXY CACHÉ
35
pequeño que no va a ser considerado. Sin embargo, en el canal de acceso a Internet el asunto es diferente, debido a que se está copando todo el canal (100% de utilización), lo que ocasiona que el retardo de un enlace puede llegar a ser muy grande. Así, aunque es difícil de estimar por el nivel de congestión del canal, el tiempo de respuesta promedio para satisfacer una solicitud es inaceptable para los usuarios de una institución (Kurose, 2010).
Una posible solución es incrementar el acceso a 100 Mbps como se puede observar en la Figura 12. Esta solución bajará la intensidad del tráfico en el canal de acceso al 20%, lo cual significa que el retardo de transmisión entre los dos enrutadores se traduce es tan pequeño como el retardo en la LAN (no considerado en este escenario). En este caso, el tiempo total de respuesta es aproximadamente dos segundos, es decir, el retardo de Internet. Sin embargo, esta solución también significa que la institución debe realizar una importante inversión en la actualización de su canal de acceso a Internet de 20 Mbps a 100 Mbps, lo que representa una costosa solución (Kurose, 2010).
Figura 12 Solución al incrementar la capacidad del canal de acceso institucional
Ahora considere la alternativa de instalar un caché en la red institucional en lugar de aumentar la capacidad del enlace de comunicación hacia Internet. Esta solución es ilustrada en la Figura 13 (Kurose, 2010).
Análisis de configuraciones de servidores proxy caché
Figura 13 Adicionar un caché a la red corporativa
Si se asume que el servidor proxy de la institución tiene un
r
h
i
t
a
t
e
del 40%, 4 de cada
10 solicitudes serán satisfechas casi inmediatamente, mientras que las otras 6 solicitudes necesitan ser atendidas por los servidores de origen. Es decir, sólo el 60% de las solicitudes pasan a través del enlace de acceso, lo que permite obtener un retardo despreciable comparado con el retardo de Internet de 2 segundos. Dadas estas consideraciones, el retardo promedio por lo tanto es 0.4 × 0.0seg + 0.6 × 2.0Seg ≈ 1.2 segundos.
De este modo, la segunda solución proporciona un tiempo de respuesta mucho menor que la primera solución y no requiere un aumento de la capacidad de canal por parte de la institución, sino la instalación y configuración de un servidor proxy caché, una solución económica y eficiente (Kurose, 2010).
Mensajes de solicitud condicionales
Determinar el tiempo que los objetos deben permanecer en el caché es difícil debido a la dificultad que existe para predecir el comportamiento de las solicitudes de los usuarios. Por lo tanto, una forma de determinar si la página está vigente o no mediante es el uso de la línea de encabezado Last-Modified. De este modo, se puede establecer el tiempo de almacenamiento con base en la fecha/hora en que el objeto fue modificado por última vez. Por ejemplo, si el objeto fue modificado hace dos horas,
36
PROTOCOLO HTTP Y SERVIDORES PROXY CACHÉ
37
se puede mantener durante dos horas en el caché. Esta forma de establecer el tiempo que un objeto estará en el caché no es infalible, pero entrega buenos resultados. Otro mecanismo para controlar la obsolescencia de los objetos es usar mensajes de solicitud condicionales por parte de los servidores proxy a los servidores de origen de los objetos, los cuales se explican a continuación (Tanenbaum, 2003).
Aunque el caché puede reducir el tiempo de respuesta percibido por el usuario, introduce un nuevo problema – la copia del objeto que reside en el caché puede estar desactualizada. En otras palabras, el objeto alojado en el servidor Web puede haber sido modificado después que la copia fue almacenada en el caché de servidor proxy. Afortunadamente, HTTP tiene un mecanismo que permite a un caché verificar que sus objetos estén actualizados. Este mecanismo es llamado GET condicional (conditional GET) si el mensaje usa el método GET y si incluye una línea de encabezado IfModified-Since: (Kurose, 2010).
Para ilustrar cómo funciona el GET condicional, observe el ejemplo a continuación. Primero, un proxy caché envía un mensaje de solicitud HTTP en nombre de un navegador que lo ha solicitado (Kurose, 2010).
Figura 14 Ejemplo de un mensaje de solicitud HTTP enviado por un cliente Web
Segundo, el servidor Web envía un mensaje de respuesta con el objeto solicitado al caché.
Figura 15 Ejemplo de un mensaje de solicitud HTTP condicional enviado por un servidor proxy
Análisis de configuraciones de servidores proxy caché
El caché reenvía el objeto al navegador que solicitó pero también almacena una copia del objeto localmente. Es de anotar que el caché también almacena la fecha de la última modificación junto con el objeto (Kurose, 2010).
Tercero, una semana después, otro navegador solicita el mismo objeto a través del caché, y el objeto aún está en el caché. Ya que este objeto puede haber sido modificado en el servidor Web la semana anterior, el caché ejecuta un chequeo de actualización mediante un GET condicional. Específicamente envía (Kurose, 2010):
Figura 16 Ejemplo de un mensaje de respuesta HTTP a un GET condicional
Note que el valor de la línea de encabezado If-modified-since: es exactamente igual al valor de la línea de encabezado Last-Modified: que fue enviada por el servidor hace una semana. Este GET condicional está diciéndole al servidor que envíe el objeto sólo si el objeto ha sido modificado desde la fecha especificada. Suponga que el objeto no ha sido modificado desde el Sat, 17 Oct 2009 16:29:31. Entonces, el cuarto paso es que el servidor envía un mensaje de respuesta al caché (Kurose, 2010):
Figura 17 Mensaje GET condicional
En este caso, el cuerpo de entidad es vacío.
Vemos que en respuesta al GET condicional, el servidor Web envía un mensaje de respuesta pero no incluye el objeto solicitado. Incluir el objeto solicitado podría gastar ancho de banda e incrementar el tiempo de respuesta percibido por el usuario,
38
PROTOCOLO HTTP Y SERVIDORES PROXY CACHÉ
39
particularmente si el objeto es grande. Note que este último mensaje de respuesta tiene el código 304 Not Modified en la línea de status, la cual dice al caché que puede reenviar la copia que tiene almacenada del objeto solicitado por el navegador del usuario (Kurose, 2010).
Otras líneas de encabezado HTTP asociadas al uso de un caché
Adicional a las líneas de encabezado Date, Last-Modified e If-Modified-Since, existen otras líneas de encabezado que son de especial interés cuando se usa un caché. A continuación, una breve descripción de ellas.
ETag: Representa una firma ( e
a
n
t
i
t
y
t
g
) para el objeto y permite hacer una prueba
más fuerte que If-Modified-Since. Un
a
e
n
t
i
t
y
t
g
es básicamente una forma de
identificar un objeto (Gourley, 2002). Si la firma del objeto solicitado consiste con la firma del objeto almacenado en caché, son considerados equivalentes (Davison, A Web Caching Primer, 2001).
Cache-Control: Es usada para indicar la forma como se va a almacenar el objeto en el caché. Por ejemplo, la línea de encabezado Cache-Control: no-cache indica que el objeto no debe ser almacenado en caché y Cache-Control: max-age=3600 establece una medida en segundos del tiempo que deberá permanecer el objeto almacenado en el caché (Gourley, 2002).
Expires: Esta línea de encabezado permite establecer un tiempo (fecha-hora) en la cual el objeto deja de ser válido (Gourley, 2002). Esta información es muy útil cuando un objeto cambia muy poco. La fecha de expiración indica cuánto tiempo puede mantenerse vigente el objeto sin necesidad de contactar al servidor de origen para validar el objeto (Davison, A Web Caching Primer, 2001).
Análisis de configuraciones de servidores proxy caché
IMPLEMENTACIONES DE SERVIDORES PROXY CACHÉ
En la actualidad existen diferentes implementaciones de servidores proxy caché. Algunas de ellas se presentan a continuación.
Squid
Squid es la más popular de las implementaciones de servidor proxy caché (Rodríguez, 2010). Como servidor proxy, actúa como intermediario entre los clientes Web (los navegadores de Internet) y los servidores de origen, aceptando solicitudes de clientes y reenviándolas a los servidores, con la posibilidad de almacenar en caché contenido que puede ser reutilizado en el futuro. La idea es que las peticiones por objetos almacenados en el caché de
S
q
u
i
d
pueden ser atendidas rápidamente sin necesidad de
consultar los servidores Web de origen con el fin de disminuir el tiempo en que va a ser atendido el cliente (Wesseles, 2004).
Los principales beneficios de utilizar este software en redes corporativas son los siguientes (Wesseles, 2004):
•
Disminuir el ancho de banda en la conexión a Internet.
•
Reducir el tiempo promedio que toma la descarga de los objetos Web solicitados.
•
Recoger estadísticas acerca del tráfico Web de la red de la organización.
•
Realizar control del acceso a contenido inapropiado.
•
Asegurarse que únicamente los usuarios autorizados tienen acceso a Internet en las condiciones establecidas y de acuerdo con algunos criterios previamente asignados.
S
q
u
i
d
nace a mediados de los años 90 como una evolución del proyecto Harvest y fue
publicado bajo licencia GNU GPL. La licencia GNU GPL significa que si alguien
40
PROTOCOLO HTTP Y SERVIDORES PROXY CACHÉ
distribuye
S
q
u
i
, debe hacerlo con el código fuente. Con el paso de los años,
d
crecido en tamaño y características. Actualmente
S
q
u
i
S
q
u
i
41
d
ha
es apoyado por un número
d
importante de voluntarios que lo desarrollan y le dan soporte.
S
q
u
i
d
funciona sobre sistemas operativos Unix, así como también en Windows. En
cuanto a los requisitos básicos de funcionamiento,
S
q
u
i
d
no es muy exigente. Sin
embargo, en una organización deben analizarse cuidadosamente las capacidades del equipo con el fin de no convertir a
S
q
u
i
d
en un cuello de botella.
La capacidad de memoria y la capacidad del disco son dos elementos fundamentales. Aunque no es una regla absolutamente rígida, una recomendación de (Wesseles, 2004) es que por cada GB de disco duro para almacenar objetos en caché se debe disponer de 512 MB de memoria RAM.
S
q
u
i
d
tiene su sitio Web oficial en: http://www.squid-cache.org/. Actualmente la
última versión estable es la 3.1. El código fuente está disponible para descargar y compilar, o una versión compilada que también puede ser usada si no es necesario personalizar
S
q
u
i
d
antes de ponerlo en funcionamiento.
DeleGate
DeleGate (DeleGate Home Page, 2010) es un gateway de nivel de aplicación multipropósito, o un servidor proxy el cual puede ser ejecutado en múltiples plataformas, tales como Unix, Windows, MacOS y OS/2. DeleGate es un intermediario de comunicaciones para varios protocolos (HTTP, FTP, SMTP, POP, entre otros), aplicando caché y control de acceso a las solicitudes enviadas por los clientes hacia los servidores.
Análisis de configuraciones de servidores proxy caché
Se originó como un proyecto pequeño en 1994 y ha tenido un crecimiento sostenido como servidor proxy de propósito general. Además de ser un servidor proxy, DeleGate también puede ser usado como servidor Web.
Las principales características de DeleGate son:
Permite la construcción fácil de un firewall gracias a la flexibilidad en el control de acceso; reduce el tráfico mediante el uso de caché; mejora el tiempo de respuesta mediante la reutilización de objetos y uso de conexión compartida a Internet; permite ser intermediario entre protocolos no seguros y protocolos seguros; y soporta extensión de servicios de valor agregado mediante filtros que se le pueden adaptar.
Apache Web Server
Apache Web Server (Apache, 2010) es un proyecto de a
F
o
u
n
d
t
i
o
n
a
T
h
e
A
p
w
c
h
e
s
o
f
t
a
r
e
que desarrolla y mantiene un servidor Web open-source, gratuito,
potente. Apache puede funcionar sobre diferentes plataformas y su principal objetivo es proporcionar servicios HTTP de manea segura, eficiente y extensible. Según (Netcraft, 2010), Apache Web Server es el servidor Web más usado en la industria informática mundial.
Dentro de sus características, Apache Web Server es modular. Lo que significa que algunos componentes pueden incluirse o no, de acuerdo con el servicio que se desea ofrecer. Apache Web Server puede ser compilado con un módulo que le permite actuar como servidor proxy caché, y luego configurado mediante un proceso sencillo que le permite activar el servicio (Apache Module mod_proxy, 2010).
42
PROTOCOLO HTTP Y SERVIDORES PROXY CACHÉ
43
Microsoft ISA Server
ISA Server (Internet Security and Acceleration Server) de Microsoft es una herramienta de seguridad que combina las funciones de firewall y servidor proxy caché para ser usado en redes corporativas brindando agilidad y seguridad en el acceso a redes externas a una organización.
ISA Server protege las comunicaciones entre los clientes internos de una organización e Internet, con la ventaja de acelerar el uso de las aplicaciones más frecuentes. Cuando se realizan solicitudes HTTP a servidores externos, el servidor proxy de ISA Server puede almacenar el objeto u objetos solicitados en caché para futuras utilizaciones
ISA Server implementa un caché de los objetos solicitados con frecuencia para mejorar el desempeño de la red. Sin embargo, este servicio por defecto está deshabilitado, debido a que el uso del caché ocupa espacio en disco y debe ser explícitamente asignado (Microsoft, ISA Server 2006 Enterprise Edition Quick Start Guide, 2010).
ISA Server utiliza almacenamiento proactivo en caché y maneja funciones de autoconfiguración para actualizar el contenido en función del tiempo de almacenamiento de los objetos. Igualmente el caché de ISA Server puede ser precargado en horarios de bajo consumo por parte de los usuarios (Microsoft, Introducción a ISA Server, 2004).
La historia de ISA Server inicia en la aplicación Proxy Server 1.0 en 1996, pasando a la versión 2.0 en 1999. Luego en el año 2000 es liberado ISA Server 2000, posteriormente en 2004 y 2006 salen nuevas versiones y en el año 2007 sale al mercado Intelligent Application Gateway 2007. En la actualidad, Forefront Threat Management Gateway 2010 es uno de los últimos desarrollos de Microsoft en términos de seguridad.
Análisis de configuraciones de servidores proxy caché
Al igual que
S
q
u
i
d
, ISA Server no es muy exigente en cuanto a los requisitos mínimos
de hardware. Los requisitos para ISA Server 2004 son: Pentium III a 550 MHz o superior, sistema operativo Microsoft Windows 2000 Server, 256 MB de RAM, Disco duro con 150 MB de espacio disponible más el espacio para el caché Web (Microsoft, Introducción a ISA Server, 2004). Se debe ser muy cuidadoso al implementar una solución corporativa ISA Server debe ser instalado en un servidor que no lo convierta en un cuello de botella.
EngageIP Cache Server
Es una solución de servidor proxy caché de alto desempeño. Reduce la demanda de ancho de banda general, reduce los costos y mejora el desempeño en la red corporativa. Según (Logisense, 2010) las funciones de proxy permite una optimización de los recursos de la red mediante el caché de contenido y se fundamenta en el trabajo colaborativo de múltiples servidores.
EngageIP Cache Server viene en presentación para múltiples plataformas y como servidor dedicado (appliance) lo que le permite adaptarse a las necesidades de los clientes.
Entre las características principales se encuentran el control basado en reglas, registro en logs en tiempo real, notificación de eventos, Interface gráfica de usuario basada en Web con capacidad monitoreo y administración remota, capacidades para precargar el caché y control de ancho de banda.
Los beneficios de este producto son los siguientes:
•
Reducción del consumo de ancho de banda e incremento del desempeño en la red.
44
PROTOCOLO HTTP Y SERVIDORES PROXY CACHÉ
•
45
Operación confiable que ha sido desplegada en cientos de proveedores de red comercial.
•
Operación completamente transparente.
•
Administración basada en Web para fácil configuración y obtención de reportes.
•
Servicios adicionales como compresión de archivos que disminuyen el tiempo de entrega de objetos.
•
Soluciones flexibles basadas en software o servidores dedicados
•
Múltiples plataformas para la ejecución, tales como Windows Server o Linux.
Sun Java System Web Proxy Server
Es un servidor proxy caché que funciona sobre Solaris y otras plataformas Unix y las versiones de servidor de Windows. Este servidor proxy recibe solicitudes de la red y las reenvía adecuadamente de acuerdo con las solicitudes realizadas. Actúa como administrador de tráfico de red, reduce el número de solicitudes a servidores remotos de contenido y alivia el tráfico de la red. El resultado es que disminuye el tiempo de espera de los usuarios y mejora el desempeño general de la red. También proporciona un gateway seguro para la distribución de contenido, un caché de contenido con entrega rápida de recursos solicitados frecuentemente, y actúa como punto de control para el tráfico de Internet, haciendo que las comunicaciones administradas sean eficientes y seguras (Sun Microsystems, 2010).
AnĂĄlisis de configuraciones de servidores proxy cachĂŠ
46
ANÁLISIS DE CONFIGURACIONES DE SERVIDORES PROXY CACHÉ
47
ANÁLISIS DE CONFIGURACIONES DE SERVIDORES PROXY CACHÉ Este proyecto de investigación fue desarrollado con la intención de identificar parámetros de configuración de un servidor proxy caché que tengan relación directa con su desempeño. Posteriormente se realizaron pruebas que para establecer los valores de esos parámetros con los que se obtenga el menor tiempo promedio de descarga de los objetos solicitados.
El servidor proxy caché seleccionado para el desarrollo del trabajo fue
S
q
u
i
d
, entre
otras, por las siguientes cuatro razones: está basado en software libre, lo que implica acceso al código fuente y la posibilidad de modificarlo de acuerdo con las necesidades del usuario; es ampliamente utilizado en el mundo; está bastante documentado; y proporciona diferentes posibilidades para analizar su comportamiento.
CONFIGURACIÓN DE SQUID
La configuración básica de
q
S
u
i
d
se realiza mediante el uso del archivo de
configuración squid.conf, el cual típicamente se almacena en el directorio /etc/squid/, pero si se necesita compilar el código fuente, puede ser ubicado en otro directorio. Este archivo puede ser modificado utilizando cualquier editor de texto plano y el proceso de configuración consiste en establecer los valores a los cerca de 200 parámetros (Wesseles, 2004). Según (Barrios), los parámetros básicos de configuración de
S
q
u
i
d
son aquellos que describen la información de red asociada al
servicio y al conjunto de clientes a los que se les ha autorizado o negado el acceso al servicio. Igualmente, la ubicación de la estructura de archivos y directorios donde se almacenarán los archivos en caché.
Para los administradores de
S
q
u
i
d
, el desempeño es una preocupación constante,
debido a que al incrementar la cantidad de solicitudes, el número de operaciones de lectura y escritura sobre el caché repercute directamente en las operaciones de
Análisis de configuraciones de servidores proxy caché
entrada y salida sobre los dispositivos de almacenamiento (disco) lo cual tiende a formar cuellos de botella que degradan el servicio (Wesseles, 2004). Esta situación debe ser enfrentada a través de mecanismos que presten servicios diferenciados dependiendo de la necesidad de una organización. Estos servicios son implementados por
S
q
u
q
S
i
d
u
i
d
a través de esquemas de almacenamiento.
tiene cinco esquemas de almacenamiento diferentes:
u
f
,
s
a
u
f
s
,
,
k
d
i
s
d
c
o
s
,y
s
n
u
l
l
.
Los esquemas de almacenamiento tienen diferentes propiedades y técnicas para organizar y acceder a los datos del caché en el disco.
Según (Wesseles, 2004), los esquemas de almacenamiento
u
f
y
s
son
a
u
f
s
estructuralmente idénticos, con la posibilidad de cambiar entre ellos sin afectar los datos almacenados en caché. La diferencia principal entre ellos radica en la implementación del proceso que realiza las operaciones sobre el disco. En
u
f
las
s
operaciones de entrada y salida sobre el disco son realizadas por el hilo principal de ejecución de
S
q
u
i
, mientras que el
d
hay un
a
u
f
s
p
o
o
de hilos disponible para
l
aprovechar la multitarea en computadores con más de un núcleo de procesamiento.
Por su parte, el esquema de almacenamiento
k
d
i
s
d
(
i
) es similar a
a
k
d
s
d
m
e
o
n
s
a
u
f
s
en
la forma como ejecutan las operaciones de entrada y salida de disco y en su estructura, pero con el apoyo de un proceso auxiliar (
) el cual se encarga de
a
d
e
m
o
n
realizar las operaciones de entrada y salida de disco. El esquema
k
d
i
s
d
es
particularmente útil si se desea utilizar más de un directorio de caché en discos duros independientes para almacenar los objetos.
El esquema de almacenamiento
c
o
s
s
( C
O
r
y
c
l
i
c
b
j
e
c
t
S
t
o
a
g
e
S
c
h
e
m
e
) es un
implementación experimental que pretende el desarrollo de un sistema de archivos apropiado para
S
q
u
i
d
. Este esquema utiliza un solo archivo grande para almacenar
todos los objetos en caché.
48
ANÁLISIS DE CONFIGURACIONES DE SERVIDORES PROXY CACHÉ
El esquema de almacenamiento
n
u
l
49
es una implementación mínima que lee de o
l
escribe datos en el disco sin almacenar en caché y son utilizados únicamente con propósitos de ocultar el origen real de las peticiones.
Por lo tanto, la configuración asociada al almacenamiento y recuperación de los archivos en caché es determinante en el rendimiento de
S
q
u
i
. La directiva
d
a
c
r
c
h
e
_
d
i
permite realizar esta configuración.
La directiva cache_dir La directiva dice a
q
S
u
a
c
i
h
e
_
d
r
c
h
e
_
d
i
es una de las más importantes en el archivo
.
s
q
u
i
d
c
o
n
f
. Ella le
dónde y cómo almacenar los archivos del caché en el disco. La directiva
d
toma los siguientes argumentos:
r
c
a
c
i
•
Esquema de almacenamiento:
•
Directorio: Es un directorio del sistema de archivos que será utilizado por S
•
q
u
i
d
u
f
s
,
a
u
f
s
,
k
d
i
s
d
,
c
o
s
s
,y
n
u
l
l
.
para almacenar los objetos en caché.
Tamaño: Es la cantidad de espacio total disponible para la estructura de archivos y directorios que almacena el caché.
•
L1 y L2: Especifican el número de directorios del caché de primer y segundo nivel.
Directiva maximum_object_size
Esta directiva establece un límite máximo a los objetos que pueden ser almacenados en el caché.
Análisis de configuraciones de servidores proxy caché
TRABAJO RELACIONADO
Antes de tomar las decisiones que condujeron el desarrollo del trabajo, se revisó la forma como otros investigadores en el mundo han realizado trabajos en temas relacionados.
Desde que se originó la Web a comienzos de la década del 90, el número de usuarios ha crecido continuamente y el desempeño ha sido una preocupación constante para los investigadores. El uso de caché en la Web ha sido una respuesta ampliamente estudiada para esta problemática, por lo que se realizó un análisis de la forma como se han desarrollado otros trabajos de investigación en temas relacionados con el análisis de desempeño de servidores proxy caché, con el fin de dar un mejor aprovechamiento a servidores proxy caché y disminuir el tiempo promedio de descarga de objetos Web desde los servidores de origen hacia los equipos de los usuarios finales.
Se destacan tres elementos encontrados. En primer lugar, la estrategia utilizada por los investigadores para realizar sus estudios; en segundo lugar, las métricas utilizadas para medir el desempeño; y en tercer lugar, pruebas de desempeño que han sido publicadas por (Wesseles, 2004) como punto de referencia del desempeño de
S
q
u
i
d
.
Estrategias de investigación
Según (Davison, A survey of proxy cache evaluation techniques, 1999) y (Zeng, 2004), los trabajos de investigación sobre el desempeño de servidores proxy caché utilizan diferentes técnicas para la recolección de datos. Algunas siguen métodos formales, mientras que otras son evaluaciones empíricas, sin embargo, todas ampliamente aceptadas y utilizadas. Entre las técnicas más populares se encuentran la simulación de redes con datos artificiales; la implementación de sistemas reales en redes aisladas; y el análisis de archivos estas técnicas.
l
o
g
reales. A continuación una breve descripción de
50
ANÁLISIS DE CONFIGURACIONES DE SERVIDORES PROXY CACHÉ
51
Simulación de redes con datos artificiales: La simulación es un mecanismo de evaluación que no obliga implementaciones completas aunque requieren el conocimiento detallado del sistema que se desea evaluar. El inconveniente principal de esta forma de evaluación, es la dificultad de caracterizar adecuadamente los datos artificiales (objetos y solicitudes). Para definir los datos artificiales, se puede utilizar una distribución particular (por ejemplo, la ley de
Z
i
p
f
) o iniciar con suposiciones que
delimitan el entorno en el que se realizan las pruebas.
Sistemas reales en redes aisladas: Esta técnica consiste en crear escenarios controlados en los cuales se eliminan variables que a pesar de ser reales pueden distorsionar los resultados obtenidos. El principal inconveniente de esta técnica es que puede generar expectativas de desempeño difíciles de alcanzar en la realidad.
Análisis de archivos log reales: Usar archivos log de solicitudes reales de clientes puede es una práctica usada con frecuencia debido a que los datos son obtenidos a partir del comportamiento real de los usuarios. Sin embargo, es posible que reflejen un orden impreciso de las solicitudes, debido a la forma como se registra la estampa de tiempo en el archivo archivos
l
o
g
l
o
g
. También es posible que la información contenida en los
estudiados haya dejado de ser útil.
Métricas de desempeño
En los estudios acerca del desempeño de los servidores proxy caché (Zeng, 2004), se señala que hay trabajos orientados a mejorar las métricas como el r
a
t
e
r
h
i
t
a
t
e
y el
b
y
t
e
h
i
t
; otros trabajos pretenden disminuir la latencia experimentada por el usuario; y
otros intentan disminuir el tráfico hacia el exterior de la red. Sin embargo, hay algunas métricas no tradicionales que pueden tener incidencia en el desempeño del servidor proxy caché como la cancelación de la conexión entre el cliente y el servidor, y la influencia que tiene el uso de
k
c
o
o
i
e
s
(Caceres, 1998); la proporción de reducción de
Análisis de configuraciones de servidores proxy caché
costo (Ayani, 2002); las tasas máxima y promedio de ancho de banda consumido, el porcentaje de tráfico de red ahorrado debido al uso local de recursos almacenados en caché y la cantidad de tráfico que puede ser atribuido al uso y administración del caché (Zeng, 2004).
Las dos métricas desempeño más ampliamente aceptadas para evaluar el desempeño de un caché, son el
r
h
i
y el
a
t
t
e
r
b
y
t
e
h
i
t
a
t
e
(Davison, A Web Caching Primer, 2001).
Sin embargo, la reutilización de objetos que estén almacenados en el caché depende en gran medida de las preferencias de los usuarios. Además, alcanzar un nivel mayor en el
r
h
i
t
a
t
e
o el
r
b
y
t
e
h
i
t
a
t
e
, no necesariamente conduce a mejorar
significativamente el desempeño del caché (Zeng, 2004).
Pruebas de desempeño de Squid con diferentes sistemas de archivos y diferentes esquemas de almacenamiento
S
q
u
i
d
ofrece una variedad de opciones en el proceso de instalación y configuración,
especialmente relacionadas con el almacenamiento de los archivos en disco. En (Wesseles, 2004) se publicaron los resultados de unas pruebas de desempeño de S
q
u
i
d
en las cuales se hicieron análisis sobre los sistemas de archivos y esquemas de
almacenamiento en cinco sistemas operativos distintos. A continuación se mencionan los aspectos más relevantes.
Se hicieron pruebas de desempeño utilizando
W
r
e
b
P
o
l
y
a
g
p
h
(Web-polygraph), una
herramienta para realización de pruebas de comparación de intermediarios HTTP. Estas pruebas fueron realizadas durante un período que tardó varios meses y su propósito principal era proporcionar resultados que permitieran comparar diferentes configuraciones de
S
q
u
i
d
y sus características. Por lo tanto, se minimizaron algunas
diferencias entre los sistemas de archivos y sistemas de almacenamiento que fueron probados para hacer que los resultados fueran comparables.
52
ANÁLISIS DE CONFIGURACIONES DE SERVIDORES PROXY CACHÉ
53
Para el ambiente de pruebas se configuraron cinco servidores idénticos desde el punto de vista del hardware (sevidores IBM Netfinity con 500 MHz, CPU Pentium III, 1 GB de memoria RAM, tarjeta de red Fast Ethernet y 3 discos duros SCSI de 8 GB) mientras que los sistemas operativos que se instalaron son los siguientes: G
N
U
,
/
L
i
n
u
x
,
N
e
t
B
D
S
y
O
p
e
B
n
S
D
a
o
S
i
En las pruebas se utilizó la versión almacenamiento
c
o
s
s
de
a
5
.
2
b
t
S
l
e
q
S
u
i
d
e
B
S
D
,
, y sólo para el esquema de
se utilizó una versión distinta, debido a que
s
e
.
r
l
r
F
característica experimental. Dado que
q
S
u
i
c
o
s
es una
s
viene preparado para una ejecución por
d
defecto, fue necesario recompilarlo para habilitar los esquemas de almacenamiento.
Para la realización de las pruebas, fue necesario diseñar unos archivos de trabajo que fueran comunes a todas las pruebas. Las métricas de desempeño utilizadas, fueron el r
t
h
o
u
g
h
p
u
t
, el tiempo de respuesta y el
r
h
i
t
a
t
e
.
Como resultado de las pruebas, lo más interesante fue el respuestas por segundo y un
r
h
i
t
a
t
e
r
t
h
o
u
g
h
p
u
t
, medido en
dentro de lo esperado. Sin embargo, en cuanto al
tiempo de respuesta, todos los resultados dieron números muy cercanos, aunque dentro de lo esperado. Como dice (Wesseles, 2004), los resultados obtenidos pueden variar dependiendo de cada prueba en particular.
Las pruebas realizadas al utilizar el sistema operativo
G
N
U
son las más
/
L
i
n
u
x
relacionados con este proyecto de investigación. Los mejores resultados fueron obtenidos con el esquema de almacenamiento embargo, dado que
c
o
s
c
o
s
s
, seguido de
a
u
f
s
y
k
d
i
s
d
. Sin
es una característica experimental, no necesariamente es una
s
opción a tener en cuenta para un sistema en producción, por lo que (Wesseles, 2004) recomienda el uso de resultado fue
e
x
t
2
f
s
.
a
u
f
s
. Con respecto a los sistemas de archivos, el que dio mejor
Análisis de configuraciones de servidores proxy caché
DECISIONES TOMADAS PARA EL DESARROLLO DEL PROYECTO
Para el desarrollo de este trabajo, tomando en cuenta las ideas iniciales que lo inspiraron y con base en la información obtenida de los trabajos consultados, se tomaron las siguientes decisiones que permitieron orientar las actividades del proyecto de investigación.
Casos de estudio y arquitecturas
Se analizaron cuatro posibles casos de estudio, los cuales se presentan a continuación:
Caso de estudio 1: Los clientes y el servidor Web están en la misma LAN
Figura 18 Arquitectura para el caso de estudio 1
El caso de estudio 1 (Figura 18), es el caso general en el cual no hay presencia de un servidor proxy caché. Los clientes están en la misma red LAN que el servidor Web y la respuesta del servidor Web es muy rápida. Este caso de estudio no se tuvo en cuenta para la realización de las pruebas porque no se pone en duda si el servidor proxy caché mejora o no el acceso al servidor Web, sino cuáles configuraciones en el servidor proxy caché son mejores para un caso específico.
54
ANÁLISIS DE CONFIGURACIONES DE SERVIDORES PROXY CACHÉ
55
Caso de estudio 2: Los clientes, el servidor Web y el servidor proxy caché están en la misma LAN
Figura 19 Arquitectura para el caso de estudio 2
Para el caso de estudio 2 (Figura 19), se incorpora el servidor proxy caché en la misma red LAN en la que se encuentran los clientes y el servidor Web. Este caso de estudio no fue evaluado, porque los clientes podrían solicitar directamente los objetos Web (los archivos de prueba) directamente al servidor Web, caso en el que el proceso de descarga es más rápido que al utilizar un servidor proxy caché intermediario.
Caso de estudio 3: Un cliente y el servidor proxy en la misma LAN, el servidor Web y el servidor proxy caché en otra LAN
Figura 20 Arquitectura para el caso de estudio 3
El caso de estudio 3 (Figura 20), es finalmente el que se eligió para realizar las pruebas. El servidor proxy caché y el cliente están en una red LAN, mientras que el servidor proxy caché y el servidor Web están en una red LAN diferente. El servidor proxy caché cuenta con dos tarjetas de red, cada una configurada en un segmento de
Análisis de configuraciones de servidores proxy caché
red diferente, de tal forma que el cliente no se puede conectar directamente al servidor Web, solo a través del servidor proxy caché. Se han eliminado los equipos activos intermedios (switches o routers) con el fin de evitar tiempos que puedan “contaminar” los resultados obtenidos.
Caso de estudio 4: Los clientes y el servidor proxy en la misma LAN, el servidor Web en algún lugar de Internet
Figura 21 Arquitectura para el caso de estudio 4
El caso más común es aquel en el que los clientes y el servidor proxy caché se encuentran en la misma red LAN, pero los servidores Web se encuentran en cualquier lugar de Internet. Este caso de estudio fue descartado para la realización de las pruebas porque es difícil estimar los tiempos que pueden tomar los mensajes de solicitud o respuesta HTTP mientras pasan por Internet.
Métricas de desempeño y parámetros de configuración
Las métricas de desempeño del servidor proxy caché que se tuvieron en cuenta para este estudio fueron
r
h
i
t
a
t
e
,
r
b
y
t
e
h
i
t
a
t
e
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 relación con las preferencias de utilización del servicio
56
ANÁLISIS DE CONFIGURACIONES DE SERVIDORES PROXY CACHÉ
57
por parte de los clientes, las cuales no están directamente relacionadas con el objeto de estudio.
Además, después de analizar la documentación de
S
q
u
i
d
, se llegó a la conclusión que
su desempeño tiene una alta relación con el sistema de archivos utilizado y con los esquemas de almacenamiento disponibles, debido a la forma como
S
q
u
i
d
realiza los
llamados a las operaciones de entrada y salida en el sistema (apertura, lectura, escritura y cierre de archivos). Por lo tanto, se tomó la decisión de realizar las pruebas teniendo en cuenta los esquemas de almacenamiento de
q
S
u
i
y medir el tiempo
d
promedio de descarga de cada uno de los objetos Web solicitados, de diferentes tamaños.
Los parámetros de configuración que se utilizaron para la realización de las pruebas fueron:
•
El tamaño del caché, medido en MBytes;
•
El tamaño máximo de un objeto que puede ser almacenado en caché, medido en MBytes;
•
El esquema de almacenamiento, el cual puede ser
u
f
s
,
a
u
f
s
y
k
d
i
s
d
con un (1)
demonio activo y una (1) estructura de archivos para el caché.
Archivos de prueba (objetos Web)
Para realizar las pruebas se crearon archivos de 100, 200 y 500 bytes, 1, 2, 5, 10, 20, 50, 100, 200 y 500 Kilobytes; y 1, 2, 5, 10, 20 y 50 Megabytes. Sin embargo, al final solo quedaron los siete archivos más grandes, para obtener resultados más significativos. A continuación el nombre de cada archivo, el cual identifica también su tamaño:
Análisis de configuraciones de servidores proxy caché
•
O-12-500KBytes.txt
•
O-13-1MBytes.txt
•
O-14-2MBytes.txt
•
O-15-5MBytes.txt
•
O-16-10MBytes.txt
•
O-17-20MBytes.txt
•
O-18-50MBytes.txt
DESARROLLO DEL AMBIENTE DE PRUEBAS
Para realizar las pruebas, se creó un sistema real en una red aislada lo que proporciona un ambiente controlado en el cual se han eliminado algunas condiciones que pueden afectar la recolección de datos.
Se creó un generador de solicitudes para que los objetos Web pudieran ser descargados desde un servidor Web predefinido a través del servicio prestado por un servidor proxy caché previamente configurado. Los objetos Web solicitados por el generador de solicitudes tienen nombre conocido y están almacenados en el servidor Web. Es por este motivo que el
r
h
i
t
a
t
e
y el
r
b
y
t
e
h
i
t
a
t
e
no fueron considerados.
La métrica de desempeño seleccionada fue la latencia experimentada por el usuario, es decir, el tiempo que tarda un objeto desde el momento en que se solicita hasta que es recibido y almacenado en el lado del cliente. De este modo, no se van a considerar las preferencias de los usuarios, porque no se relacionan con el objeto de estudio.
Dado que se midió el tiempo de descarga de los objetos solicitados, se creó un sistema de registro de los distintos eventos que ocurren desde cuando el objeto es solicitado hasta cuando es efectivamente almacenado en el cliente. En este caso, los archivos de registro ( l
o
g
) son luego leídos y analizados para poder contabilizar el tiempo
promedio que duró cada descarga.
58
ANÁLISIS DE CONFIGURACIONES DE SERVIDORES PROXY CACHÉ
59
La realización de las pruebas es una tarea dispendiosa y monótona que bien puede hacerse en forma manual, con la posibilidad de tener que repetirla en muchas ocasiones cada vez que surge un cambio importante en el trabajo desarrollado. Sin embargo, con el fin de facilitar la realización de pruebas de una manera automatizada donde se pudieran repetir una y otra vez con el fin de obtener los mejores resultados, se diseñó y desarrolló un robot (software) que se ejecutara automáticamente, tanto en el lado del cliente como en el lado del servidor proxy caché.
El robot en el lado del cliente es un generador de solicitudes HTTP (diferente a un navegador de Internet), mientras que en el lado del servidor es un sistema que carga archivos de configuración almacenados en un directorio específico. Un archivo de configuración determina la forma como funciona el servidor proxy caché robot está desarrollado en lenguaje distribución utilizada fue
del sistema operativo
r
s
h
e
l
l
s
a
c
i
p
t
r
5
D
e
b
i
n
L
e
n
n
y
(
V
e
s
i
ó
n
)
G
N
U
q
S
u
i
. El
d
. La
/
L
i
n
u
x
.
La forma como trabaja el gestor de solicitudes es realizando peticiones de objetos Web a un servidor HTTP al cual puede acceder a través del servidor proxy. Para la realización de esta investigación, los objetos solicitados siempre están disponibles en el servidor Web (no se considera el caso de un objeto que no vaya a ser encontrado en el servidor Web). Además, se construyó un ambiente virtual controlado utilizando virtualización empresarial de tercera generación.
Cada vez que se descarga un objeto se va construyendo un archivo de registro con los tiempos de cada una de las descargas y al final se obtiene un archivo de resultados que almacena el tiempo promedio de descarga de cada objeto solicitado, con los cuales se pueden construir gráficas que permiten el análisis del comportamiento de cada una de las configuraciones reunidas en un archivo de configuración del servidor proxy
S
q
u
i
d
.
Por su parte, el robot en el lado del servidor proxy caché inicia una configuración y queda en modo de espera hasta que el cliente haya terminado de hacer todas las
Análisis de configuraciones de servidores proxy caché
descargas programadas. Para coordinar las actividades del cliente y el servidor, se utiliza una zona de archivos compartida a través del sistema de archivos de red ( N
F
S
)
el cual se ha configurado de manera sincrónica. Cada vez que el servidor ha cargado una nueva configuración, activa un semáforo mediante la creación de un archivo en la zona compartida la cual es actualizada casi instantáneamente, permitiendo al cliente saber que el servidor está listo y que puede iniciar las descargas de los objetos Web programados para ser descargados. El cliente cuando inicia una descarga, activa un semáforo mediante la creación de otro archivo el cual le indica al servidor que el cliente está ocupado realizando una prueba.
La automatización incluye una tarea programada tanto en el cliente como en el servidor proxy la cual intenta ser realizada cada minuto, a través del servicio de automatización de tareas propio del sistema operativo llamado
. La presencia de
r
c
o
n
ciertos archivos en la zona compartida actúa como semáforo facilitando la coordinación apropiada para lanzar los procesos en los momentos adecuados sin necesitar la intervención de usuario alguno.
Una prueba consiste en un cliente que solicita un número determinado de veces los objetos Web que obtiene de una lista almacenada en un archivo de texto; y un servidor que usa un archivo de configuración. Una prueba completa se efectúa cuando el servidor utiliza una serie de archivos de configuración, los cuales tienen que ser probados con todas y cada una de las solicitudes del lado del cliente.
Es importante tener en cuenta que en el desarrollo de este proyecto de investigación se han aislado una serie de variables que pueden afectar los resultados a obtener. Al tener un ambiente virtual se han eliminado los posibles errores que se puedan presentar en los medios físicos de transmisión de datos; al usar un
w
s
i
t
c
h
virtual, no
hay colisiones y como el ambiente es controlado y no hay equipos adicionales a los necesarios, no se presentan mensajes en
r
b
a
o
a
d
c
s
t
que puedan alterar el rendimiento
de la red, ni se consideran los retrasos cada vez que se pasa por un dispositivo activo local. Por otra parte, a pesar de simular un servidor Web externo, no hay enrutadores
60
ANÁLISIS DE CONFIGURACIONES DE SERVIDORES PROXY CACHÉ
61
intermedios que puedan aumentar el retardo extremo a extremo. Tampoco se tiene en cuenta el retraso ocasionado por el acceso a Internet ni los retrasos por el proceso de resolución de nombres de dominio lo cual estaría fuera de control. La Figura 22 muestra los componentes del ambiente de pruebas creado para el desarrollo del proyecto. Se pueden identificar el servidor Web, el servidor proxy caché, el cliente, el cargador de configuraciones en el servidor proxy caché, el gestor de descargas en el cliente y la zona de archivos compartida
N
F
S
.
Figura 22 Arquitectura de la solución
AMBIENTES VIRTUALES
Virtualización
La virtualización es la capacidad de crear una abstracción lógica a partir de recursos computacionales físicos (Goldworm, 2007). En la década de los años 60, IBM creó el concepto de memoria virtual para su aplicación en un mainframe, lo que produjo grandes cambios en la computación de la época. Más tarde, en los años 70, también creó el concepto de máquina virtual, permitiendo dividir un único computador físico en diferentes computadores virtuales completos y funcionales para poder ejecutar diferentes aplicaciones al mismo tiempo, permitiendo un mejor aprovechamiento de la inversión (Goldworm, 2007).
Análisis de configuraciones de servidores proxy caché
La virtualización tomó un nuevo aire a partir de los años 90, cuando el estándar de la industria era la arquitectura x86 y los computadores de esa época se enfrentaban a problemas muy similares a los que tenían los mainframes en la década de 1960, especialmente la subutilización de recursos (VMware).
Según (VMware), una máquina virtual es un contenedor de software aislado el cual puede ejecutar su propio sistema operativo y aplicaciones como si fuera un computador real. De este modo, una máquina virtual se comporta exactamente igual que un computador físico y está dotada de sus propios recursos computacionales como un subconjunto del computador host donde se encuentre alojada, es decir tiene su propio procesador, memoria RAM, disco duro, tarjeta de red y dispositivos periféricos virtuales.
Algunas ventajas del uso de máquinas virtuales son las siguientes (VMware):
•
La compatibilidad con prácticamente todos los sistemas operativos para arquitectura x86 lo que le permite a una máquina virtual la ejecución de aplicaciones tal como si fuera un computador físico.
•
El aislamiento entre las máquinas virtuales aunque estén alojadas en el mismo computador físico. Esto permite manejarlas como si se tratara de máquinas independientes, lo que aumenta la disponibilidad en caso de fallo, porque un fallo en una de ellas no afecta las demás.
•
El encapsulamiento de una máquina virtual completa en un conjunto reducido de archivos facilita la realización de copias de seguridad en medios de almacenamiento externo y la portabilidad de un computador físico a otro, independientemente del hardware físico.
En el mercado existen diferentes herramientas de virtualización, para diferentes aplicaciones. Hay versiones comerciales y basadas en software libre. Algunas son para realizar prácticas en computadores de escritorio y otras son completas
62
ANÁLISIS DE CONFIGURACIONES DE SERVIDORES PROXY CACHÉ
63
infraestructuras utilizadas para la virtualización de servidores en ambientes de producción.
Para la realización de este proyecto de investigación se utilizó versión gratuita de
a
w
r
M
V
e
a
w
r
M
V
E
e
S
X
i
, una
que permite dar los primeros pasos en virtualización
empresarial de última generación.
E
S
X
i
utiliza un hipervisor o monitor de máquina virtual (VMware), el cual es un
componente de software que actúa directamente sobre el hardware para permitir la creación de máquinas virtuales sin necesidad de un sistema operativo host optimizando el uso de los recursos hardware disponibles. El hipervisor virtualiza recursos hardware como memoria, procesador, disco y dispositivos periféricos, para ser asignados a las máquinas virtuales de acuerdo con las necesidades (Goldworm, 2007).
SISTEMA DE ARCHIVOS DE RED (NFS)
El sistema de archivos de red ( N
F
S
por sus siglas en inglés:
N
r
w
e
t
o
k
F
i
l
e
S
y
s
t
e
m
) es un
servicio que permite acceder a archivos localizados en hosts remotos como si estuvieran almacenados en el host local en forma transparente para los usuarios. Es recomendable que
N
F
S
sea utilizado únicamente en redes de área local, debido a que
únicamente realiza una comprobación básica de los equipos que tienen acceso a la información compartida.
El sistema de archivos
N
F
S
es utilizado en este proyecto de investigación por el
software desarrollado para mantener una zona compartida entre el servidor proxy donde se modifican las configuraciones del servidor y el cliente donde se realizan las descargas programadas de los objetos Web. Cuando el servidor está listo crea un archivo en la zona compartida el cual se refleja casi inmediatamente en el cliente. La existencia de este archivo funciona como un semáforo que le da paso a la descarga de
Análisis de configuraciones de servidores proxy caché
una nueva prueba en el cliente. Por su parte, al iniciar una prueba, el cliente crea un archivo en la zona compartida. Este archivo se refleja casi de inmediato en el servidor actuando también como un semáforo, donde la presencia de este archivo indica que el cliente está descargando archivos y se encuentra ocupado. Al terminar la prueba, el cliente elimina el archivo y esta acción es tomada como una señal para que el servidor se reconfigure, tomando el siguiente archivo de configuración que hace parte de la prueba.
A continuación se hace una breve explicación del proceso de configuración del sistema NFS, tanto en el lado del servidor como en el lado del cliente.
Configuración del servidor
Se deben instalar los paquetes necesarios: portmap, unfs3, nfs-user-server y nfskernel-server. En
G
N
U
/
a
L
i
n
u
D
x
b
e
i
n
, la instalación se puede realizar utilizando el
comando apt-get install, y esperar a que se realice el procedimiento correspondiente.
• • • • •
a
a
p
t
-
g
e
t
i
n
s
t
p
t
-
g
e
t
i
n
s
t
p
t
-
g
e
t
i
n
s
t
p
t
-
g
e
t
i
n
s
t
p
t
-
g
e
t
i
n
s
t
a
r
p
a
l
l
o
l
l
l
l
n
f
s
-
l
l
n
f
s
-
l
l
n
f
s
-
m
t
p
a
a
u
n
f
s
3
a
a
r
a
a
u
s
r
e
s
-
v
e
r
k
e
r
e
r
n
e
l
-
s
e
v
r
e
a
c
o
m
m
o
n
El servicio portmap permite a un cliente conectarse con un servidor utilizando el protocolo RPC y se encarga además de la seguridad de la conexión. Si el servicio portmap ya está instalado y se encuentra detenido, se puede iniciar mediante el comando /etc/init.d/portmap start.
A continuación se debe identificar el directorio que se va a exportar. En el caso de este proyecto de investigación, /Proyecto-437-Servidor/semaforos, es el nombre del
64
ANÁLISIS DE CONFIGURACIONES DE SERVIDORES PROXY CACHÉ
65
directorio que se va a exportar, en la máquina virtual donde se instaló el servidor proxy caché.
El siguiente paso es editar el archivo /etc/exports, utilizando cualquier editor. En ese archivo, se debe escribir la línea:
/Proyecto-437-Servidor/semaforos 172.30.30.77 (rw, sync, no-subtree-check)
donde: /Proyecto-437-Servidor/semaforos es el nombre del directorio que se está exportando; 172.30.30.77 es la dirección IP del equipo que está autorizado para a
m
o
n
el directorio exportado; (rw, sync, no-subtree-check) establece los permisos
r
t
y condiciones de exportación.
El significado de los permisos es el siguiente:
rw, utilizado para lectura y escritura. Esto quiere decir que el cliente que puede a
m
o
n
el directorio exportado, tiene permiso de escribir en los archivos compartidos.
r
t
sync, se utiliza para indicar que antes de realizar alguna acción, es necesario escribir en disco. Esto puede ser un poco más lento pero evita problemas de consistencia en los archivos. no-subtree-check, se utiliza para agilizar la tasa de transferencia, debido a que con esta opción no se tiene que verificar si el archivo solicitado pertenece o no al directorio exportado.
Para no tener conflictos con los usuarios en el computador cliente, se asignó como propietario del directorio exportado con el comando chown -R nobody nogroup /Proyecto-437-Servidor/semaforos, siendo el usuario nobody y el grupo nogroup, un nombre de usuario y nombre de grupo especiales propios del sistema a
D
e
b
i
n
.
G
N
U
/
L
i
n
u
x
Análisis de configuraciones de servidores proxy caché
Finalmente, se debe ejecutar el comando /etc/exportfs -a para actualizar la lista de directorios exportados. Es de anotar que todas estas operaciones deben ser realizadas por el superusuario del sistema.
Configuración del cliente
Se debe crear un directorio en el cliente con el propósito de
a
m
o
n
t
r
el directorio
exportado por el servidor. En este caso, se creó el directorio /Proyecto-437Cliente/semaforos, en la máquina virtual en la que se ejecutan las solicitudes de los objetos.
A continuación, con el fin de crear una configuración permanente del directorio a
m
o
n
t
d
o
en el cliente, se debe editar el archivo /etc/fstab y agregar la siguiente línea:
172.30.30.79:/Proyecto-437-Servidor/semaforos Cliente/semaforos
nfs rw, sync
0
/Proyecto-437-
0
donde 172.30.30.79:/Proyecto-437-Servidor/semaforos corresponde a la ubicación específica del
directorio exportado en el servidor
N
F
S
; /Proyecto-437-
Cliente/semaforos especifica el punto de montaje en el host local; nfs es el sistema de archivos; rw significa que el directorio será montado con permisos de lectura y escritura; sync, indica que todas las modificaciones realizadas en el cliente se reflejen en el servidor prácticamente en el mismo momento en que se realizan, o si se realizan en el servidor, los cambios se reflejen en el cliente. Los dos valores al final son
a
f
l
g
s
. La
primera indica si se almacenan los errores por si surge algún problema, mientras la segunda indica si se desea realizar comprobaciones periódicas de integridad. En este caso, ambas flags se han dejado en 0, es decir, desactivadas.
Al igual que en la configuración del servidor, estas operaciones deben ser realizadas por el superusuario del sistema.
66
ANÁLISIS DE CONFIGURACIONES DE SERVIDORES PROXY CACHÉ
67
SOFTWARE DESARROLLADO
Como ya se mencionó, se han desarrollado dos aplicaciones utilizando el lenguaje r
s
c
i
p
t
del sistema
G
N
U
a
r
5
L
i
n
u
x
D
e
b
i
L
n
e
n
n
y
(
e
V
s
i
ó
s
h
e
l
l
; una en el lado servidor (donde
/
)
n
está instalado el servidor proxy caché) y otra en el lado del cliente desde donde se realizan las pruebas.
Aplicación en el lado servidor
En el lado servidor se creó un script llamado cargarConfiguracion.sh. Fue desarrollado usando el lenguaje
de
r
S
h
e
l
l
S
c
i
p
t
G
N
U
. El script inicia con la
/
L
i
n
u
x
definición de variables globales, las cuales tienen alcance dentro de todo el script. Estas variables globales en su mayoría corresponden a las rutas donde se encuentran los archivos que se utilizan para asignar una configuración a
S
q
u
i
d
.
Este script se compone de seis funciones, las cuales se ejecutan en secuencia al iniciar el script. La condición para que se ejecute este script es que el servicio
S
q
u
i
d
esté
activo. En caso contrario, el script termina.
A continuación, las funciones que hacen parte del script cargarConfiguracion.sh:
verificacionDescargaActual: Esta función verifica la existencia del archivo clienteDescargando.flag en la zona de archivos compartidos. Si el cliente se encuentra en un proceso de descarga, el script termina y es necesario esperar hasta la siguiente ejecución programada en el
r
c
o
n
. Es decir, la ejecución del script
cargarConfiguracion.sh en el lado cliente.
cargarValoresIniciales: Esta función cuenta el número de archivos existentes en el directorio configuraciones. Luego, carga los valores que están almacenados en los archivos configuracionActualServidor.num y descargaActualCliente.num en la
Análisis de configuraciones de servidores proxy caché
zona de archivos compartidos, la cual se encuentra en el directorio semaforos, tanto en el lado del cliente como en el lado del servidor.
validarSemaforo: En esta función se verifica si el número de configuración del servidor es mayor que el número de configuración en el cliente. Cuando esto sucede, el cliente está en proceso de descarga y el script termina. En caso contrario, no pasa nada y el flujo continúa con la siguiente instrucción.
bajarSquid: Esta función elimina el archivo servidorListo.flag. Luego detiene el servicio
S
q
u
i
d
y elimina completamente el caché.
cambioConfiguracion: Esta función selecciona el nombre del archivo de configuración que sigue y lo escribe en el archivo configuracionActualServidor.txt. A continuación, reemplaza el archivo de configuración de prueba como el archivo de configuración de
S
q
u
i
d
con el nombre squid.conf.
subirSquid: Esta función crea el caché, sube el servicio
S
q
u
i
d
(lo activa), hace una
pausa de cinco segundos, crea el caché y crea el archivo servidorListo.flag para que el cliente reciba la señal que indica que el servidor ha cambiado su configuración y el cliente puede iniciar una nueva descarga de los objetos de una prueba.
A continuación el código completo del script cargarConfiguración.sh.
cargarConfiguracion.sh
#!/bin/bash #----------------------------------------------------------------------# Nombre Script: cargarConfiguracion.sh # Propósito: Cargar una nueva configuración para el servicio squid # Autor: GRID # Fecha: Mayo de 2010 #----------------------------------------------------------------------# Definición de variables globales rutaSquid="/usr/local/squid/etc/squid.conf";
68
ANÁLISIS DE CONFIGURACIONES DE SERVIDORES PROXY CACHÉ
rutaBase="/Proyecto-437-Servidor"; rutaScripts="$rutaBase/scripts"; rutaSemaforos="/$rutaBase/semaforos"; rutaConfiguraciones="$rutaScripts/configuraciones"; PIDSquid="/usr/local/squid/var/logs/squid.pid"; registroLog="$rutaBase/bitacora/registro.log"; servidorListo="$rutaSemaforos/servidorListo.flag"; clienteDescargando="$rutaSemaforos/clienteDescargando.flag"; configuracionActualServidorNumero=""; configuracionActualServidorNombre=""; descargaActualCliente=""; numeroLineas=""; # # # # #
Verificación del semáforo corespondiente al proceso de descargas por parte del cliente. Si se encuentra el archivo llamado "/Proyecto-437-Servidor/semaforos/clienteDescargando" no se debe realizar ningua operación y se debe esperar hasta la siguiente ejecución programada en el cron.
function verificacionDescargaActual () { if [ -f $clienteDescargando ] then echo $(date)" - No es posible cambiar la configuración, cliente descargando..." >> $registroLog; exit 1; fi } function cargarValoresIniciales () { # Contar el número de archivos de configuración del directorio de # configuraciones numeroLineas=$(ls -1 "$rutaConfiguraciones" | wc -l); configuracionActualServidorNumero=$(head -n 1 "$rutaSemaforos/configuracionActualServidor.num"); descargaActualCliente=$(head -n 1 "$rutaSemaforos/descargaActualCliente.num"); } function bajarSquid () { #Eliminando el archivo "/Proyecto-437#Servidor/semaforos/servidorListo.flag" #para evitar que el cliente intente realizar descargas en medio de este #proceso rm -f $rutaSemaforos/servidorListo.flag # Detener el servicio $rutaScripts/bajarSquid.sh sleep 45 # Borrar el caché $rutaScripts/borrarCache.sh } # archivos en "/Proyecto-437-Servidor/script/configuraciones" function cambioConfiguracion() { # Realizando la asignación respectiva del archivo de configuración # que se encuentre en turno configuracionActualServidorNombre=$(ls -1 "$rutaConfiguraciones" | awk 'NR=='$configuracionActualServidorNumero'{print}');
69
Análisis de configuraciones de servidores proxy caché
echo $configuracionActualServidorNombre > $rutaSemaforos/configuracionActualServidor.txt; # Realizando el cambio de configuración cp $rutaConfiguraciones/$configuracionActualServidorNombre $rutaSquid; } function subirSquid () { # Crear el caché $rutaScripts/crearCache.sh # Subir el servicio $rutaScripts/subirSquid.sh # Realizar pausa para dar tiempo al proceso de arranque de Squid sleep 5 # Copia del archivo que indica que Squid está listo para que el # cliente inicie el proceso de descarga. touch $servidorListo; } function validarSemaforo () { if [ $configuracionActualServidorNumero -gt $descargaActualCliente ] then # Se debe esperar a que se realicen la descarga completamente echo $(date)" - Se debe esperar a que el cliente indique que ha terminado satisfactoriamente las descargas" >> $registroLog; exit 1; fi configuracionActualServidorNumero=$(($configuracionActualServidorNumero + 1)); if [ $configuracionActualServidorNumero -gt $numeroLineas ] then { echo $(date)" - Ha finalizado el proceso de pruebas." >> $registroLog; # Se debe proceder a quitar el archivo "/Proyecto-437# Sevidor/semaforos/servidorListo.flag" rm -f $servidorListo bajarSquid; exit 0; } fi # Escribiendo el nuevo valor en el archivo echo $configuracionActualServidorNumero > $rutaSemaforos/configuracionActualServidor.num } # Inicio del script # Verificacion de la existencia del archivo que indica que el servidor # Squid esta listo if [ -f $PIDSquid ] then { verificacionDescargaActual; cargarValoresIniciales;
70
ANÁLISIS DE CONFIGURACIONES DE SERVIDORES PROXY CACHÉ
validarSemaforo; bajarSquid; cambioConfiguracion; subirSquid; } else { echo $(date)" - Squid no esta en ejecución" >> $registroLog; exit 1; } fi
Los siguientes son scripts de apoyo para cargarConfiguracion.sh.
bajarSquid.sh
#!/bin/bash # Script bajarSquid # Propósito: Realizar la detención del proceso squid y borrar el caché # del disco echo "Bajando el proceso squid"; #/etc/init.d/squid stop /usr/local/squid/sbin/squid -k shutdown
borrarCache.sh
#!/bin/bash # Script borrarCache # Propósito: Realizar el borrado de la estructura de directorios donde es # almacenado el caché para el servicio squid echo "Borrando el caché de Squid"; #rm -Rf /var/spool/squid/* rm -Rf /usr/local/squid/var/cache/* echo "Borrando los archivos log relacionados con squid" #rm -Rf /var/log/squid/*
crearCache.sh
#!/bin/bash # Script crearCache # Propósito: Realizar la creación de la estructura de directorios de para # almacenar el cache del servicio squid.
71
Análisis de configuraciones de servidores proxy caché
# Importante: Se debe tener detenido el servicio Squid antes de realizar esta actividad # Creando el el cachépara el servicio squid echo "Creando directorios para el caché de Squid"; #/usr/sbin/squid -z /usr/local/squid/sbin/squid –z
subirSquid.sh
#!/bin/bash # Script SubiSquid # Propósito: Realizar la inicialización del servicio squid creando el # caché de disco echo "Subiendo el servicio Squid"; #/etc/init.d/squid start /usr/local/squid/sbin/squid –D
Es importante tener en cuenta que hay una estructura de directorios definida para que el script pueda funcionar en el servidor.
El directorio scripts, contiene los scripts que ya se explicaron. Dentro de ese directorio, se encuentra otro directorio llamado configuraciones en el cual se almacenan los archivos de configuración que tienen ya definidos los valores de los parámetros que se van a poner a prueba, sin importar el nombre que tenga asignado cada archivo.
En el directorio semaforos se encuentra la zona de archivos compartidos. En este directorio
se
almacenan
los
archivos
configuracionActualServidor.num
y
descargaActualCliente.num, los cuales almacenan un número que indica cuál es la configuración actual (el número) que tiene activa el servidor y el número de la prueba que
está
haciendo
el
cliente.
Además,
se
almacena
el
archivo
configuracionActualServidor.txt, el cual indica el nombre del archivo de configuración que actualmente se está probando en el servidor. Dependiendo si el
72
ANÁLISIS DE CONFIGURACIONES DE SERVIDORES PROXY CACHÉ
73
servidor está listo o no, se puede tener un archivo llamado servidorListo.flag. Igualmente, mientras el cliente se encuentre realizando una prueba, en este directorio se puede tener un archivo llamado clienteDescargando.flag. Por tratarse de una zona de archivos compartida, cualquier cambio que se haga en los archivos de este directorio en el servidor, se replica en el cliente casi inmediatamente.
El directorio bitacora almacena el archivo registro.log en el cual se escribe todo lo que vaya pasando con la ejecución del script en el lado del servidor. Este archivo se puede leer para saber si se han presentado errores en la ejecución de las pruebas.
Aplicación en el lado cliente
El generador de solicitudes es un componente de software diseñado y desarrollado a la medida. Es un conjunto de programas que permite la descarga de los objetos Web que se han creado y almacenado en el Servidor Web y medir el tiempo promedio de esas descargas.
El script inicia con la definición de variables globales, las cuales tienen alcance dentro de todo el script. Estas variables globales en su mayoría corresponden a las rutas donde se encuentran los archivos que se utilizan para realizar una descarga por parte del cliente.
Este script se compone de seis funciones, las cuales se ejecutan en secuencia al iniciar el script. La condición para que se ejecute este script es que el servicio
S
q
u
i
d
esté
activo y el servidor esté listo, es decir, que el archivo servidorListo.flag se encuentre almacenado dentro del directorio semaforos (zona de archivos compartidos). En caso contrario, el script termina.
A continuación, las funciones que hacen parte del script iniciarDescargas.sh:
Análisis de configuraciones de servidores proxy caché
verificacionDescargaActual: Esta función verifica la existencia del archivo clienteDescargando.flag en la zona de archivos compartidos. Si el cliente se encuentra en un proceso de descarga, el script termina y es necesario esperar hasta la siguiente ejecución programada en el
r
c
o
n
. Es decir, una nueva ejecución del script
iniciarDescargas.sh en el lado cliente.
cargarValoresIniciales: Esta función carga los valores que están almacenados en los archivos configuracionActualServidor.num y descargaActualCliente.num en la zona de archivos compartidos, la cual se encuentra en el directorio semaforos, tanto en el lado del cliente como en el lado del servidor. También se obtiene del archivo url.txt la dirección del servidor Web al cual se le van a hacer las peticiones; del archivo http_proxy.txt, la dirección IP del servidor proxy caché y el número de puerto; y del archivo numeroDescargas.num el número de veces que se va a descargar cada archivo de prueba.
validarSemaforo: En esta función se verifica si el número de configuración del servidor es mayor que el número de configuración en el cliente. Cuando esto sucede, se debe iniciar el proceso de descarga por parte del cliente. En caso contrario, y el script termina.
prepararDescarga: Esta función crea el directorio en el cual se va a almacenar cada uno de los objetos descargados. El nombre del directorio incluye la fecha y la hora.
ejecutarDescarga: Esta función recorre el archivo listaObjetosWeb.txt para obtener los nombres de los archivos de prueba que va a descargar. Cada archivo se descarga el número de veces que esté especificado en el archivo numeroDescargas.num. Para descargar el archivo se utiliza el comando wget de
G
N
U
/
L
i
n
u
x
. Por cada objeto Web
solicitado se escribe un archivo llamado Estadistica.NombreObjeto.txt, donde NombreObjeto es tomado del archivo ListaObjetos.txt. Durante el proceso de descarga se escribe en el archivo de salida de cada objeto y se almacena en el directorio llamado resultados. Como los archivos se descargan con el fin de tomar
74
ANÁLISIS DE CONFIGURACIONES DE SERVIDORES PROXY CACHÉ
75
medidas del tiempo que se ha demorado cada uno de los archivos descargados, al terminar se borran los archivos de prueba. De este modo, se evita almacenar información innecesaria que se aloja en los discos de la máquina virtual cliente utilizada para la realización de las pruebas.
realizarCalculos: Esta función realiza los cálculos del tiempo promedio de descarga de cada objeto Web, apoyado en un componente desarrollado en lenguaje . Se utilizó C
este lenguaje de programación debido a que el
de
r
h
S
e
l
l
c
S
i
p
t
G
N
U
/
L
i
n
u
x
carece de las
funciones matemáticas de precisión que se necesitan para realizar los cálculos en milisegundos, microsegundos y nanosegundos. Al terminar de hacer el cálculo del tiempo, se escriben los resultados en el archivo resultados.csv y se almacena en el mismo directorio donde se almacenan los archivos de salida producto de la descarga del objeto. El archivo con extensión .csv ( c
a
o
m
m
a
s
e
p
r
a
v
t
e
d
a
l
u
e
) puede ser leído por
un programa de hojas de cálculo, a partir del cual se pueden realizar las gráficas estadísticas.
A continuación el código completo del script iniciarDescargas.sh.
iniciarDescargas.sh
#!/bin/bash #-----------------------------------------------------------------------# Nombre Script: iniciarDescarga.sh # Propósito: Scrip principal de inicio automático de descargas del lado # del cliente # Autor: GRID # Fecha: Mayo de 2010 #-----------------------------------------------------------------------#Definicion de variables locales rutaBase="/Proyecto-437-Cliente"; rutaScripts="$rutaBase/scripts"; rutaResultados="$rutaBase/resultados"; listaObjetosWeb="$rutaScripts/listaObjetosWeb.txt"; rutaSemaforos="$rutaBase/semaforos"; clienteDescargando="$rutaSemaforos/clienteDescargando.flag"; servidorListo="$rutaSemaforos/servidorListo.flag";
Análisis de configuraciones de servidores proxy caché
registroLog="$rutaBase/bitacora/registro.log"; rutaTemporal="$rutaBase/temporal"; configuracionActualServidorNumero="" configuracionAcutalServidorNombre="" descargaActualCliente="" http_proxy=""; url=""; numeroDescargas=""; function verificacionDescargaActual () { # Verifica si aún se encuentra en un proceso de descargas por parte del # cliente if [ -f $clienteDescargando ] then echo $(date)" - No procede porque el cliente se encuentra descargando..." >> $registroLog; exit 1; fi } function cargarValoresIniciales () { configuracionActualServidorNumero=$(head -n 1 "$rutaSemaforos/configuracionActualServidor.num"); descargaActualCliente=$(head -n 1 "$rutaSemaforos/descargaActualCliente.num"); configuracionActualServidorNombre=$(head -n 1 "$rutaSemaforos/configuracionActualServidor.txt"); url=$(head -n 1 "$rutaScripts/url.txt"); export http_proxy="$(head -n 1 $rutaScripts/http_proxy.txt)"; numeroDescargas=$(head -n 1 "$rutaScripts/numeroDescargas.num"); } function validarSemaforo () { if [ $configuracionActualServidorNumero -gt $descargaActualCliente ] then # Se debe proceder a realizar las descargas echo $(date)" - Iniciando el proceso de descarga" >> $registroLog; else { echo $(date)" - Esperando el cambio de configuracion de Squid" >> $registroLog; exit 1; } fi } function prepararDescarga () { marcaFecha=$(date +"%F_%H-%M"); directorioDescarga="$rutaResultados/$configuracionActualServidorNom bre-$marcaFecha" mkdir $directorioDescarga;
76
ANÁLISIS DE CONFIGURACIONES DE SERVIDORES PROXY CACHÉ
} function ejecutarDescarga() { #Definicion de variables listaObjetosWeb="$rutaScripts/listaObjetosWeb.txt"; #Se recorre el archivo especificado donde se determinan los objetos #web a obtener. for nombreObjetoWeb in $(cat $listaObjetosWeb); do #echo "$nombreObjetoWeb" ; echo "Archivo de salida Descargas servidor Web para el objeto Web [$nombreObjetoWeb] " > $directorioDescarga/salida.$nombreObjetoWeb echo "----------------------------------------" >> $directorioDescarga/salida.$nombreObjetoWeb echo " " >> $directorioDescarga/salida.$nombreObjetoWeb echo "Inicio del proceso de descarga ... " >> $directorioDescarga/salida.$nombreObjetoWeb contador=1; while [ $contador -le $numeroDescargas ] do echo "----------------------------------------" >> $directorioDescarga/salida.$nombreObjetoWeb echo "Descarga No [$contador] " >> $directorioDescarga/salida.$nombreObjetoWeb echo "----------------------------------------" >> $directorioDescarga/salida.$nombreObjetoWeb tLlegada=$(date +"%s %N"); wget $url/$nombreObjetoWeb >> $directorioDescarga/salida.$nombreObjetoWeb 2>> $directorioDescarga/salida.$nombreObjetoWeb tSalida=$(date +"%s %N"); echo "$tLlegada $tSalida" >> $directorioDescarga/estadistica.$nombreObjetoWeb ((contador=$contador + 1)) # Borrando los archivos descargados, todos inician con la letra O `rm -rf O*` done done } # ----------------------------------------------------------------------# Definición de función para la realización de los cálculos de los tiempo # de descarga function realizarCalculos () { # Establecer el nombre de la prueba en el archivo de resultados echo $configuracionActualServidorNombre > $directorioDescarga/resultados.csv #Se recorreo el archivo especificado donde se determian los objetos #web a obtener. for nombreObjetoWeb in $(cat $listaObjetosWeb); do echo -n "$nombreObjetoWeb," >> $directorioDescarga/resultados.csv echo "`$rutaBase/scripts/calcularTiempo $directorioDescarga/estadistica.$nombreObjetoWeb`" >> $directorioDescarga/resultados.csv done
77
Análisis de configuraciones de servidores proxy caché
} # INICIO DEL SCRIPT # Verifica si está disponible el servicio Squid if [ -f $servidorListo ] then verificacionDescargaActual cargarValoresIniciales; validarSemaforo; # Establecimiento del semáforo para indicar que se están # realizando descargas touch $clienteDescargando prepararDescarga; ejecutarDescarga; realizarCalculos; # Escribiendo el nuevo valor en el archivo "indiceDescarga" descargaActualCliente=$(($descargaActualCliente + 1)); echo $descargaActualCliente > $rutaSemaforos/descargaActualCliente.num # Eliminando el semáforo para indicar que ya se han realizado # las descargas rm -f $clienteDescargando else echo $(date)" - Esperando nueva configuracion del Servidor Squid" >> $registroLog; exit 1; fi
calcularTiempo.c
Es un programa desarrollado en lenguaje C. Se utiliza para calcular el tiempo que tarda cada una de las descargas de cada uno de los objetos. Lee del archivo Estadistica.NombreObjeto.txt cuatro columnas por cada una de las n filas, donde n es el número de descargas de cada objeto, y las columnas corresponden al tiempo antes y después de la descarga. Cada tiempo está expresado en dos columnas, la primera corresponde a la estampa de tiempo y la segunda a los nanosegundos respectivos). El resultado es un archivo con el cálculo del tiempo promedio que toma descargar el objeto, es decir, el promedio de la diferencia de los tiempos en cada fila, en milisegundos.
Un ejemplo del archivo Estadistica.NombreObjeto.txt que posteriormente es procesado por el componente calcularTiempo se presenta a continuación:
78
ANÁLISIS DE CONFIGURACIONES DE SERVIDORES PROXY CACHÉ
1268922502 1268922502 1268922507 1268922508 1268922509
574107064 823072296 004076915 514300005 445636231
1268922502 1268922506 1268922508 1268922509 1268922509
814359733 995714398 506386148 437852558 961328174
A continuación, el código fuente del programa calcularTiempo.c.
#include<stdio.h> #include<stdlib.h> #include<string.h> int main(int argc, char * argv[]) { int i, t1, t2, tiempo, cantidad; FILE *archivo; char nombreArchivo[200]; char renglon[100]; char *t1_1; char *t1_2; char *t2_1; char *t2_2; cantidad = 0; unsigned long v1_1, v1_2,v2_1,v2_2,resultado, segundos, nanosegundos; float microsegundos, milisegundos, promedio; char *endp; strcpy(nombreArchivo, argv[1]); promedio = 0.0; if( ( archivo =fopen(nombreArchivo,"r") ) == NULL ) printf(" ERROR"); else { while(!feof(archivo)) { t1_1= ""; t1_2= ""; t2_1= ""; t2_2= ""; fgets(renglon,100,archivo); t1_1 = strtok(renglon," "); t1_2 = strtok(NULL," "); t2_1 = strtok(NULL," "); t2_2 = strtok(NULL," "); if (t2_2 { v1_1 = v1_2 = v2_1 = v2_2 =
!= NULL) strtod(t1_1, strtod(t1_2, strtod(t2_1, strtod(t2_2,
&endp); &endp); &endp); &endp);
//Calculando el tiempo que tardó el proceso de descarga if ( v2_2 == v1_2) {
79
Análisis de configuraciones de servidores proxy caché
segundos = v2_1 - v1_1; nanosegundos = 0; } else if ( v2_2 > v1_2 ) { segundos = v2_1 - v1_1; nanosegundos = v2_2 - v1_2; } else { segundos = ((v2_1 - v1_1) -1); nanosegundos = (1000000000 + (v2_2 - v1_2)); } microsegundos = nanosegundos / 1000.0; milisegundos = nanosegundos / 1000000.0; promedio += milisegundos; // Se convierten los segundos a milisegundos segundos = segundos * 1000; promedio += segundos; } cantidad++; } } fclose(archivo); promedio = promedio /1000.0; printf("%.2f\n",promedio ); return 0; }
ListaObjetosWeb.txt
En este archivo de texto se almacenan los nombres de los archivos (objetos Web) que serán utilizados para realizar una prueba de descarga. En cada línea se debe especificar el nombre de cada archivo, sin importar de qué tipo de archivo se trata. El script EjecutarDescargas.sh lee cada línea de este archivo para formar una solicitud por un objeto Web. Por cada una de las descargas de cada uno de los objetos se escribe un archivo llamado Estadistica.NombreObjeto.txt, con los tiempos antes y después de hacer la descarga. A continuación un ejemplo del contenido del archivo ListaObjetosWeb.txt.
O-12-500KBytes.txt O-13-1MBytes.txt O-14-2MBytes.txt
80
ANÁLISIS DE CONFIGURACIONES DE SERVIDORES PROXY CACHÉ
81
O-15-5MBytes.txt O-16-10MBytes.txt O-17-20MBytes.txt O-18-50MBytes.txt
Salida.csv
El archivo Salida.csv es el archivo que tiene los resultados consolidados con el promedio del tiempo que tardó cada objeto Web solicitado en ser descargado. El contenido de este archivo es posteriormente manipulado para poder obtener las gráficas estadísticas a partir de los datos almacenados. A continuación, el contenido de uno de los archivos con el nombre Salida.csv. Observe que en la primera línea, aparece el nombre del archivo de configuración que fue utilizado para la realización de la prueba. A partir de la segunda hasta la última línea del archivo, corresponde al nombre de cada objeto, por ejemplo, O-15-5MBytes.txt, seguido del tiempo promedio asociado a ese objeto en particular. Del nombre del archivo, en este caso, se puede deducir el tamaño.
00-squid,conf_Original O-12-500KBytes.txt,2.53 O-13-1MBytes.txt,3.58 O-14-2MBytes.txt,5.45 O-15-5MBytes.txt,11.08 O-16-10MBytes.txt,21.95 O-17-20MBytes.txt,43.78 O-18-50MBytes.txt,130.02
Al igual que en el lado del servidor, en el lado del cliente también hay una estructura de directorios definida para que el script pueda funcionar.
El directorio scripts, contiene el script iniciarDescargas.sh, el programa calcularTiempo (el ejecutable ya compilado), y los archivos con la información del servidor Web y el servidor proxy caché.
Análisis de configuraciones de servidores proxy caché
En el directorio semaforos se encuentra la zona de archivos compartidos, la cual funciona igual que lo explicado en el lado del servidor; y el directorio bitacora donde se almacena el archivo registro.log en el cual se escribe todo lo que vaya pasando con la ejecución del script en el lado del cliente.
82
PRUEBAS REALIZADAS
83
PRUEBAS REALIZADAS
En la ejecución de este proyecto de investigación fueron realizadas una gran cantidad de pruebas donde se observaron diferentes comportamientos del servidor proxy caché
S
q
u
operativo
i
. Se crearon tres máquinas virtuales en las cuales se configuró el sistema
d
G
N
U
. La selección de este sistema operativo
/
a
r
5
L
i
n
u
x
D
e
b
i
n
L
e
n
n
y
(
e
V
s
i
)
n
ó
se hizo de manera arbitraria, debido a que podría haberse utilizado cualquier otra distribución. Sin embargo, se eligió por ser una distribución estable y ampliamente utilizada en la configuración de servidores, además de tener una gran comunidad de desarrolladores alrededor del mundo.
Para la creación de las máquinas virtuales se utilizó
W
v
a
m
r
e
E
S
X
i
. Las tres máquinas
tenían la misma configuración: Procesador 2 GHz, Memoria Ram: 1 GB, Disco duro: 20 GB. Se configuró el servidor Web (
a
A
( S
q
u
i
d
p
c
h
e
) en la primera, el servidor proxy caché
) en la segunda y el cliente en la tercera.
Se analizaron diferentes parámetros de configuración para realizar las pruebas, específicamente los que se consideraron que impactan de manera más significativamente el desempeño de
S
q
u
i
. Los parámetros seleccionados fueron: el
d
tamaño del caché; el tamaño máximo de un objeto que va a ser almacenado en el caché; el esquema de almacenamiento.
Al realizar diferentes combinaciones de estos pocos parámetros, podría salir una gran cantidad de archivos de configuración de
S
q
u
i
. Por lo tanto, se redujeron las
d
combinaciones al utilizar los siguientes valores para los parámetros seleccionados.
Para el tamaño del caché, se consideraron 100MB y 1000MB; para el tamaño máximo de un objeto en el caché, se consideraron 4MB y 54 MB; para los esquemas de almacenamiento se tuvieron en cuenta
u
f
s
,
a
u
f
s
y
k
d
i
s
d
.
Análisis de configuraciones de servidores proxy caché
Se crearon archivos de prueba de 500KB, 1MB, 2MB, 5MB, 10MB, 20MB y 50MB.
Se realizaron las siguientes pruebas:
Prueba 1: Esquemas de almacenamiento:
u
f
s
,
a
u
f
s
y
k
d
i
s
d
, con los siete archivos de
prueba. Tamaño del caché: 100MB, tamaño máximo de un objeto para ser almacenado en caché: 4MB.
En esta prueba, es importante tener en cuenta que los archivos de 5MB, 10MB, 20MB y 50 MB no fueron almacenados en caché por superar el tamaño máximo para que un objeto sea almacenado en caché. Esto ocasiona una falla de caché y el correspondiente aumento en la obtención del archivo solicitado, debido a que el servidor proxy caché debe solicitar el archivo al servidor de origen. En los archivos más pequeños, el esquema de almacenamiento
a
u
f
s
dio mejor resultado, sin embargo, a medida que el
tamaño de los archivos crece, el resultado mejor fue para el esquema de almacenamiento
k
d
i
s
d
.
Prueba 2: Esquemas de almacenamiento:
u
f
s
,
a
u
f
s
y
k
d
i
s
d
, con los siete archivos de
prueba. Tamaño del caché: 100MB, tamaño máximo de un objeto para ser almacenado en caché: 54MB.
84
PRUEBAS REALIZADAS
85
Para esta prueba todos los archivos pueden ser almacenados en caché ya que no superan el tamaño máximo permitido. En este caso, los esquemas de almacenamiento u
f
s
y
a
u
f
s
presentan resultados similares, mientras que los tiempos con el esquema de
almacenamiento
k
d
i
s
d
son significativamente mayores en todos los casos, excepto en
el archivo de 500 KB.
Prueba 3: Esquemas de almacenamiento:
u
f
s
,
a
u
f
s
y
k
d
i
s
d
, con los siete archivos de
prueba. Tamaño del caché: 1000MB, tamaño máximo de un objeto para ser almacenado en caché: 4MB.
Análisis de configuraciones de servidores proxy caché
En esta prueba, los archivos de más de 4MB no fueron almacenados en caché por superar el tamaño máximo permitido, lo que ocasiona una falla de caché. El tamaño del caché ha cambiado a 1000MB. En los archivos más pequeños, el esquema de almacenamiento
u
f
s
dio mejor resultado, sin embargo, en los archivos grandes el
resultado mejor fue para el esquema de almacenamiento
, con excepción del
k
d
i
s
d
archivo más grande.
Prueba 4: Esquemas de almacenamiento:
u
f
,
s
a
u
f
s
y
k
d
i
s
d
, con los siete archivos de
prueba. Tamaño del caché: 1000MB, tamaño máximo de un objeto para ser almacenado en caché: 54MB.
Para esta prueba todos los archivos pueden ser almacenados en caché y el tamaño del caché es de 1000MB. En este caso, el esquema de almacenamiento resultado, con tiempos muy cercanos con
a
u
f
s
, mientras que
k
d
i
s
d
u
f
tuvo el mejor
s
presentó tiempos
demasiado altos, es decir, que para un caché muy grande diskd no es un esquema de almacenamiento apropiado en las condiciones en las que se configuró
S
q
u
i
d
.
El siguiente grupo de pruebas (5 a 7), corresponden a los dos tamaños de caché y dos tamaños máximos de objetos que pueden ser almacenados en el caché con un esquema de almacenamiento al descargar un objeto de 5MB.
86
PRUEBAS REALIZADAS
Prueba 5: Esquema de almacenamiento
u
f
87
, con un archivos de 5MB. Tamaño del
s
caché: 100MB y 1000MB vs Tamaño máximo de un objeto para ser almacenado en caché: 4MB y 54MB.
En este caso, se presentan mejores tiempos cuando el tamaño del caché es más grande y también hay un mejor desempeño si los objetos pueden ser almacenados en el caché, si el esquema de almacenamiento es
u
f
s
.
Prueba 6: Esquema de almacenamiento
a
u
f
s
, con un archivos de 5MB. Tamaño del
caché: 100MB y 1000MB vs Tamaño máximo de un objeto para ser almacenado en caché: 4MB y 54MB.
Análisis de configuraciones de servidores proxy caché
Se presentan mejores tiempos cuando el tamaño del caché es más pequeño y esquema de almacenamiento es
a
u
f
s
.
Prueba 7: Esquema de almacenamiento
, con un archivos de 5MB. Tamaño del
k
d
i
s
d
caché: 100MB y 1000MB vs Tamaño máximo de un objeto para ser almacenado en caché: 4MB y 54MB.
Cuando el esquema de almacenamiento es
k
d
i
s
d
, hay una ligera disminución en el
tiempo cuando el tamaño del caché es de 1000MB. Además, si el objeto de 5MB puede ser almacenado en caché el tiempo es significativamente mayor, independiente del tamaño del caché.
88
CONCLUSIONES, APORTE Y TRABAJO FUTURO
89
CONCLUSIONES, APORTE Y TRABAJO FUTURO El servidor proxy caché
S
q
u
i
es una herramienta ampliamente flexible para
d
ambientes de producción, debido a que ofrece el acceso al código fuente y puede ser recompilado para adaptarlo a las necesidades del usuario; a diferencia de otros productos que prestan servicios similares a través de herramientas propietarias precompiladas que no se pueden modificar.
La configuración por defecto de
S
q
u
i
d
, no es apropiada para todos los ambientes de
producción. Es necesario estudiar las necesidades de la organización y con base en ellas, realizar los ajustes respectivos, los cuales pueden ser tan sencillos como modificar un parámetro de configuración, o tan complejos como recompilar el software y/o el kernel del sistema operativo (si éste lo permite); utilizar varias estructuras de archivos para alojar los cachés y tal vez ajustar una variedad de parámetros en el archivo de configuración, sin dejar de lado la adecuada selección del hardware para la instalación del servicio.
Los resultados de las pruebas son dependientes de los ambientes de ejecución particulares y lo que puede ser conveniente en un escenario puede ser inconveniente en otro. Determinar los valores de los parámetros de configuración adecuados para un ambiente específico es una tarea no trivial, por lo tanto, las pruebas realizadas en este proyecto de investigación sirven de referencia para que los administradores de servidores
S
q
u
i
d
realicen ajustes a sus archivos de configuración.
Dentro de los principales aportes de este trabajo se encuentra el robot que automatiza el desarrollo de las pruebas. Este robot puede ser adaptado al estudio de otros servicios cliente/servidor basados en archivos de configuración como son la mayoría de los servicios en sistemas tipo Unix.
Análisis de configuraciones de servidores proxy caché
La infraestructura para virtualización empresarial fue probada y funciona eficientemente lo que permite aprovechar este recurso en futuros proyectos de investigación.
El lenguaje Shell Script, a pesar de tener limitaciones técnicas con respecto a lenguajes de alto nivel, es muy versátil para la manipulación de procesos propios de sistemas operativos tipo Unix.
Como trabajo futuro, quedan muchas ideas para profundizar, entre las que se destacan la automatización de la asignación de los valores de los parámetros de configuración mediante la aplicación de inteligencia artificial; el uso de cachés cooperativos (distribuidos y jerárquicos); el uso de servidores proxy caché sobre plataformas de red basadas en IPv6; implementar un robot multihilo que simule ambientes con acceso concurrente 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é.
90
REFERENCIAS BIBLIOGRÁFICAS
91
REFERENCIAS BIBLIOGRÁFICAS
N
v
A
r
w
n
c
e
. (s.f.). Obtenido de http://www.cs.usask.ca/
N
a
d
d
e
t
a
k
o
i
n
g
A
p
p
l
i
c
t
i
o
n
s
A
-
A
faculty/carey/projects/finalreport.html Apache. (2010).
. Obtenido de http://www.wireshark.org/
a
A
p
c
h
e
a
A
.
r
p
c
h
M
e
o
d
u
l
m
e
o
d
p
_
o
x
y
(2010).
Obtenido
de
http://httpd.apache.org/docs/2.2/mod/mod_proxy.html Ayani, R. y. (2002). Cost-based Proxy Caching. r
m
y
S
c
S
p
i
e
o
n
s
c
i
m
u
o
D
n
i
s
a
t
b
i
u
t
e
C
d
m
o
p
u
t
i
n
r
r
P
o
c
e
e
d
i
n
g
s
o
f
t
h
e
n
I
t
a
e
a
g
n
d
A
p
p
l
i
a
n
t
i
o
r
c
t
i
o
n
s
t
B
o
u
s
i
n
e
s
s
E
,
n
g
i
n
e
n
l
a
e
i
n
g
n
d
, (págs. 218-222). Wuxi.
e
Barrios,
J.
(s.f.).
a
L
i
n
u
x
r
.
a
p
t
o
d
o
s
Obtenido
de
http://www.linuxparatodos.net/portal/staticpages/index.php?page=19-0-comosquid-general Berners-Lee, T. y. (1996).
/
r
r
a
r
1
r
.
H
y
p
e
t
e
x
T
t
n
s
f
P
e
o
t
o
c
o
l
-
H
-
T
T
.
0
P
Caceres, R. y. (1998). Web Proxy Caching: The devil is in the details. r
r
v
r
r
r
t
e
n
e
t
e
S
P
e
e
f
m
o
Davison, B. (1999).
n
r
c
e
k
s
o
p
o
n
s
v
r
u
e
y
o
f
a
p
o
x
y
v
c
c
h
e
a
a
e
l
u
t
i
o
n
t
e
c
h
n
q
i
u
e
s
N
r
r
5
E
I
E
E
n
I
t
e
n
e
C
t
m
o
p
u
t
i
n
g
o
V
,
l
m
u
e
m
u
,
b
e
, 38-45.
4
. (2010). Obtenido de http://www.delegate.org/delegate/
G
a
D
e
l
a
e
t
H
e
m
o
P
e
g
e
D'Orazio, L. J. (2005). Building adaptable cache services. W
r
a
r
r
P
o
c
e
e
d
i
n
t
e
a
n
t
i
o
r
n
l
k
a
w
o
s
Fielding, R. (1999).
h
o
p
o
M
n
i
d
d
l
r
r
r
r
r
y
p
r
e
t
e
x
p
u
t
i
n
g
h
i
l
e
C
u
t
t
Gómez, C. E. (2007). r
a
r
T
t
n
i
n
C
g
s
f
a
B
i
C
d
m
o
p
u
t
i
n
g
1
d
e
o
s
t
v
T
c
a
h
P
e
s
s
o
f
t
n
f
i
g
u
é
H
-
a
c
i
ó
n
d
e
u
n
s
i
s
t
o
c
o
l
-
H
-
T
r
s
n
r
d
T
d
t
s
.
a
u
l
i
r
t
z
a
m
i
e
n
a
t
d
i
o
n
a
a
e
p
o
y
a
r
T
:
n
a
o
s
f
r
m
o
i
n
E
g
n
t
e
c
c
h
é
e
t
p
l
i
d
e
d
e
c
i
s
i
o
n
e
a
c
c
i
.
T
T
P
:
T
h
r
p
a
m
o
a
n
v
H
e
a
l
o
n
e
s
D
H
D.C.: Universidad de Los Andes. Gourley, D. y. (2002).
d
3
P
a
i
V
a
e
a
m
e
e
1
s
r
.
o
h
i
s
e
Wiley Publishing, Inc.
s
r
C
t
a
e
a
H
D
o
r
e
S
M
C
A
g
r
P
e
r
l
.
m
o
.
H
W
o
F
e
/
Goldworm, B. y. (2007). C
e
n
.
G
.
c
h
.
A
Davison, B. (2001). A Web Caching Primer.
i
r
o
Madison, Wisconsin USA.
a
.
n
I
W
e
d
e
f
i
n
i
t
i
e
g
u
i
d
e
O’Reilly.
T
-
T
e
s
i
s
d
e
M
g
í
s
t
e
p
r
a
a
l
Bogotá,
Análisis de configuraciones de servidores proxy caché
Hewllet-Packard. (2009). c
h
i
n
P
g
o
l
i
c
i
e
s
G
v
p
r
o
i
n
.
a
C
W
r
m
I
g
b
e
v
r
e
S
a
e
r
s
n
Obtenido
r
P
d
o
x
i
e
P
s
r
e
de
f
a
w
m
o
n
c
e
i
t
D
h
F
S
Disponible
en:
http://www.hpl.hp.com/personal/Lucy_Cherkasova/projects/gdfs.html. Hofmann, M. y. (2005).
The
N
r
w
r
k
r
r
a
r
a
.
C
o
n
t
e
n
t
e
t
o
i
n
.
g
A
c
h
i
t
e
c
t
u
e
P
,
o
t
o
c
o
l
s
n
,
P
d
c
t
i
c
e
Morgan Kaufmann Series in Networking. Kurose, J. y. (2010).
N
r
r
w
k
a
w
r
a
5
C
m
o
p
u
t
e
e
t
o
i
n
g
A
:
t
o
p
d
-
o
n
p
p
o
c
h
.
t
,
E
h
d
i
t
i
o
n
Departamento Administrativo Nacional de Estadística. Massachussets: Addison Wesley. Logisense.
(2010).
L
o
g
i
s
e
n
s
.
e
Obtenido
de
http://www.logisense.com/cache_home.html Microsoft.
(2010).
r
n
I
t
r
e
n
e
E
t
x
p
l
.
r
o
e
Obtenido
de
http://www.microsoft.com/spain/windows/internet-explorer/default.aspx Microsoft. (2010). Internet Information Server. Microsoft.
(2004).
r
n
I
r
n
I
t
r
e
n
e
t
n
I
f
a
a
t
o
d
u
c
c
i
t
r
n
ó
A
S
I
r
m
o
v
o
n
e
v
.
r
e
S
e
.
r
e
S
i
Obtenido
de
http://www.microsoft.com/spain/isaserver/2004/info/overview.aspx Microsoft. (2010).
. Obtenido de
G
r
v
r
r
0
A
S
I
e
S
r
a
k
r
6
0
2
e
E
n
t
e
p
i
s
E
e
d
i
t
i
o
n
u
Q
i
c
t
S
t
u
i
d
e
http://technet.microsoft.com/es-co/library/bb838660(en-us).aspx Mozilla. (2010). r
t
a
c
f
i
e
f
o
x
.
N
e
. Obtenido de http://www.mozilla-europe.org/es/firefox/
r
F
t
(2010).
Obtenido
de
http://news.netcraft.com/archives/2010/03/17/march_2010_web_server_survey.ht ml. Opera. (2010). Provost,
. Obtenido de http://www.opera.com/
O
r
p
a
e
G.
(2010).
.
W
a
w
H
r
C
o
c
h
i
n
g
k
o
s
Obtenido
de
http://computer.howstuffworks.com/cache.htm Rodríguez,
M.
(2010).
U
G
r
Q
S
D
I
E
:
P
l
N
.
U
a
o
x
y
C
-
c
h
e
Obtenido
de
http://www.marisabel.com.ar/pdfs/SquidProxy-NexIT-Edicion15.pdf Sun
Microsystems.
(2010).
.
W
a
v
a
r
J
y
S
s
t
m
e
r
P
b
e
o
x
y
v
e
S
r
e
Obtenido
de
http://www.sun.com/download/products.xml?id=4701e042. Tanenbaum, A. (2003).
N
México: Pearson, Educación.
4
r
r
w
k
.
C
m
o
p
u
t
e
e
t
o
s
t
,
E
h
d
i
t
i
o
n
Vakali, A. I. (2001). A study on Web caching architectures and performance. . W
r
r
r
r
a
r
a
5
P
o
c
e
e
d
i
n
g
s
o
f
.
t
h
o
l
d
M
u
l
t
i
-
C
o
n
f
e
e
n
c
e
o
n
S
y
s
t
e
m
i
c
s
,
C
y
b
e
n
e
t
i
c
s
n
d
I
n
f
o
m
t
i
c
s
.
92
REFERENCIAS BIBLIOGRÁFICAS
VMware. (s.f.).
a
w
. Obtenido de http://www.vmware.com/products/esxi/
r
M
V
E
e
Web-polygraph. (s.f.). Wesseles, D. (2004).
X
S
i
. Obtenido de http://www.web-polygraph.org/
W
r
b
e
p
-
o
l
y
a
g
p
h
v
.
q
S
u
i
d
T
:
93
h
e
d
e
f
i
n
i
t
i
e
g
u
i
d
e
O’Reilly & Associates, Inc.
Zeng, D. y. (2004). Efficient Web Content Delivery Using Proxy Caching Techniques. O
N
I
E
E
T
E
R
A
W
N
A
C
A
S
D
R
E
V
I
E
S
T
.
I
O
N
S
N
N
S
Y
S
T
E
M
S
,
M
A
N
,
A
O
N
D
C
Y
B
E
R
E
T
I
C
S
—
P
A
R
T
C
:
A
P
P
L
I
C
A
T
I
N
S