8/9/2019 Arquitectura de Aplic Web
1/40
Arquitectura de
aplicaciones webLeandro Navarro Moldes
P07/M2106/02842
8/9/2019 Arquitectura de Aplic Web
2/40
8/9/2019 Arquitectura de Aplic Web
3/40
FUOC P07/M2106/02842 Arquitectura de aplicaciones web
ndice
Introduccin ............................................................................................ 5
Objetivos ................................................................................................... 6
1. Caractersticas de la demanda de pginas web ........................... 7
2. Organizacin de las aplicaciones en servidores web ................. 15
2.1. Organizacin del servidor web ......................................................... 15
2.2. Organizacin de las aplicaciones web .............................................. 17
2.3. Interfaz comn de pasarela (common gateway interface, CGI) ..........17
2.3.1. FastCGI ...................................................................................18
2.4. Servlet Java ........................................................................................ 19
2.4.1. La API de servlets..................................................................... 20
2.5. Resumen y comparacin .................................................................. 22
3. Servidoresproxy-cacheweb ............................................................... 23
4. Contenidos distribuidos ....................................................................28
4.1. Redes de distribucin de contenidos ................................................ 29
5. Computacin orientada a servicios ................................................ 33
5.1. Computacin bajo demanda ............................................................34
Resumen .................................................................................................... 35
Actividades ............................................................................................... 37
Ejercicios de autoevaluacin ............................................................... 37
Solucionario ............................................................................................. 38
Glosario ..................................................................................................... 38
Bibliografa .............................................................................................. 39
8/9/2019 Arquitectura de Aplic Web
4/40
8/9/2019 Arquitectura de Aplic Web
5/40
FUOC P07/M2106/02842 5 Arquitectura de aplicaciones web
Introduccin
En este mdulo didctico se van a tratar las formas de organizar aplicaciones
web y de cmo hacer que puedan funcionar pese a estar sujetas al comporta-
miento catico e imprevisible de Internet.
Primero se caracteriza la demanda de estos servicios y cmo medirla en la prc-
tica. Despus, se describen las formas de construir y la evolucin de los servicios
web (cgi, servlets, servidores de aplicaciones y servidores web), y se analizan los
casos de distintos servidores web; para acabar hablando de formas distribuidas
de servicio: servidores intermediariosproxy-cache, redes de distribucin de con-
tenidos, aplicaciones orientadas a servicios y computacin bajo demanda.
La forma de adquirir los conocimientos pasa por realizar los pequeos experi-
mentos que se ofrecen en el apartado de actividades y en la web de la asignatura,
y que ayudan tanto a concretar las ideas centrales como a tener experiencias pro-
pias y personales de los fenmenos, tcnicas y herramientas que se describen.
8/9/2019 Arquitectura de Aplic Web
6/40
FUOC P07/M2106/02842 6 Arquitectura de aplicaciones web
Objetivos
Los objetivos de este mdulo didctico son los siguientes:
1. Conocer las caractersticas de la demanda que debe satisfacer un servidor
web.
2. Conocer las distintas maneras de organizar una aplicacin web y los mo-
delos que existen, segn los distintos criterios.
3. Conocer las caractersticas y el funcionamiento de cada modelo.
4. Poder elegir la mejor opcin en cada situacin y valorar las implicaciones
del montaje que hay que realizar.
8/9/2019 Arquitectura de Aplic Web
7/40
FUOC P07/M2106/02842 7 Arquitectura de aplicaciones web
1. Caractersticas de la demanda de pginas web
El trfico de web es el responsable de un buen porcentaje del trfico de Inter-net. Esta tendencia ha ido creciendo gradualmente desde que apareci la web
(protocolo HTTP), y hoy da el trfico HTTP predomina respecto del resto de
los protocolos, y hay una gran poblacin de usuarios navegantes que pue-
den generar una cantidad inmensa de peticiones si el contenido es interesan-
te. La organizacin de un servicio web conectado a Internet requiere tener en
cuenta las caractersticas de la demanda que pueda tener que atender.
Figura 1
Volumen de trfico en escala logartmica de flujos, paquetes y bytes intercambiados durante veinticuatro horas en un enlacedel ncleo de la red de MCI/Worlcom (1998), organizado por el protocolo.
Figura 2
Porcentaje de trfico en bytes de cada protocolo respecto al total medido. Puede apreciarse mejor que en la figura 1, en escalalogartimica, que el porcentaje de trfico web domina el resto (73% del total).
Arrecifes de coraly trfico en Internet
La organizacin CAIDA(www.caida.org) se dedica alanlisis del trfico en Internet yha desarrollado una herrami-enta denominada Coral Reefque toma trazas del trfico deun enlace. Con sta, en 1998hicieron un estudio de trficopor protocolos en el ncleo dela red del proveedor MCI.
El artculo que lo describe sepresent en la conferencia Inet98, y se titulaba The nature of
the beast: recent traffic measu-rements from an Internetbackbone.
Las grficas adjuntas se hanobtenido de estas medidas.
8/9/2019 Arquitectura de Aplic Web
8/40
FUOC P07/M2106/02842 8 Arquitectura de aplicaciones web
Por otro lado, la web (HTTP) es un servicio muy reclamado por todo tipo de
organizaciones para publicar informacin, como puede verse en la tendencia
de crecimiento del nmero de servidores web en Internet, que ha sido expo-
nencial, tal y como muestra la figura 3.
Figura 3
Crecimiento del nmero de sitios web durante los ltimos seis aos.
La popularidad de los servidores web tambin es muy variable. Un mismo sitio
web puede recibir muy pocas visitas durante mucho tiempo y, de repente, reci-
bir veces ms peticiones de las que puede servir: es un trfico a rfagas.
Figura 4
Evolucin del trfico entrante y saliente de un sitio web tpico durante una semana. Podisobservar la gran variacin horaria y la reduccin de trfico durante el fin de semana.
Un servidor puede recibir avalanchas repentinas de trfico. Por ejemplo, por
las estadsticas del siguiente servidor web sabemos que, despus de ser anun-
ciado en la pginas de noticias slashdot.org, sufri un exceso de visitas tan alto
que el servidor se bloque:
Figura 5
Peticiones web por hora, servidas por por http://counter.li.org durante tres das. Puede verse quemientras que el nmero habitual de operaciones (peticiones web) estaba por debajo de 500, subirpidamente a unas 2.500, lo cual provoc el fallo del sistema. Despus de reconfigurarlo, estuvosoportando durante unas doce horas en torno a 3.000 peticiones/hora para bajar posteriormente avalores normales. La historia completa est en la direccin: http://counter.li.org/slashdot/
La cronologa de Internet
Un calendario de los eventosrelacionados con Internetdesde 1957 hasta hoy lo podisver en la direccin siguiente:http://www.zakon.org/robert/
internet/timeline/
Flash crowd
Un cuento de ciencia ficcin devarias Larry Niven (1973) pre-dijo que una consecuencia deun mecanismo de teletrans-porte barato sera que grandesmultitudes se materializaraninstantneamente en los luga-res con noticias interesantes.Treinta aos despus, el trmi-no se usa en Internet para des-
cribir los picos de trfico webcuando un determinado sitiose hace popular de repente yse visita de manera masiva.
Tambin se conoce como efec-to slashdot o efecto /., quese da cuando un sitio web re-sulta inaccesible a causa de lasnumerosas visitas que recibecuando aparece en unartculo del sitio web de notici-as slashdot.org (en castellano,barrapunto.com).
8/9/2019 Arquitectura de Aplic Web
9/40
FUOC P07/M2106/02842 9 Arquitectura de aplicaciones web
Un servidor web puede tener miles de documentos y, sin embargo, recibir la
mayora de las peticiones por un nico documento. En muchos casos, la po-
pularidad relativa entre distintos sitios web o entre diferentes pginas de un
cierto sitio se rige por la ley de Zipf (George Kingsley Zipf, 1902-1950) que
dice:
El ejemplo ms famoso es la frecuencia de palabras en ingls. En 423 artculos
de la revista Time (245.412 palabras), the es la que ms aparece (15.861), ofest
en segundo lugar (7.239 veces), to en tercer lugar (6.331 veces), y con el resto
forman una ley potencial con un exponente cercano a 1.
Una distribucin de popularidad Zipf forma una lnea recta cuando se dibuja
en una grfica con dos ejes en escala logartmica, que resulta ms fcil de ver
y comparar que la grfica en escala lineal, tal y como puede verse en la figura
siguiente:
Figura 5
Una distribucin de popularidad (casos ordenados por popularidad en el eje x, valor de popularidad en el eje y) que sigue la ley
de Zipf a escala lineal queda enganchada a los ejes: muy pocos casos tienen mucha popularidad y muchos casos tienen muy
poca. Por este motivo, se suele representar en escalas logartmicas (grfica doble logartmica: los dos ejes en escala logartmica).
Muchos estudios muestran que las visitas de pginas web siguen una distribu-
cin de Zipf. La figura siguiente muestra las visitas en www.sun.com durante
un mes de 1996. La pgina principal recibi prcticamente 1 milln de visitas,
mientras que la pgina de la posicin 10.000 de popularidad slo recibi una
visita aquel mes. La grfica de visitas sigue la curva de Zipf excepto para los
valores menos populares, lo cual seguramente se debe al hecho de que el pe-
riodo de observacin no fue lo bastante largo.
La frecuencia de suceso de un evento concreto (P) como funcin del
rango (i) cuando el rango es determinado por la frecuencia de suceso
es una funcin potencial Pi ~1/ia, con el exponente a cercano a la
unidad.
8/9/2019 Arquitectura de Aplic Web
10/40
FUOC P07/M2106/02842 10 Arquitectura de aplicaciones web
Figura 6
Nmero de visitas de las pginas de www.sun.com ordenadas por popularidad. Puede verse cmo se ajusta
a una distribucin de Zipf.
Como resumen, diferentes estudios del trfico web contribuyen a definir un
perfil tpico o reglas a ojo de la web segn M. Rabinovich y O. Spatscheck
(2002). Web Caching and Replication. Addison Wesley. ISBN: 0201615703:
El tamao medio de un objeto es de 10-15 kbytes, y la media de 2-4 kbytes.
La distribucin se decanta claramente hacia objetos pequeos, aunque se en-
cuentra una cantidad nada despreciable de objetos grandes (del orden de
Mbytes).
La mayora de los accesos a la web son por objetos grficos, seguidos de los
documentos HTML. El 1-10% son por objetos dinmicos.
Una pgina HTML incluye de media diez imgenes y mltiples enlaces a
otras pginas.
Un 40% de todos los accesos son para objetos que se considera que no se
pueden inspeccionar.
La popularidad de objetos web es muy diferente: una pequea fraccin de ob-
jetos es la responsable de la mayora de los accesos, siguiendo la ley de Zipf.
El ritmo de acceso para objetos estticos es muy superior al ritmo de modi-
ficacin.
En una escala de tiempo inferior al minuto el trfico web es a rfagas, por
lo cual valores medidos con medias durante algunas decenas de segundo
son muy poco fiables.
Un 5-10% de accesos a la web se cancelan antes de finalizar.
Prcticamente todos los servidores utilizan el puerto 80.
Cada sitio web es un poco distinto, y puesto que un servidor web es un sistema
complejo y, por lo tanto, difcil de modelar, resulta conveniente hacer experimen-
8/9/2019 Arquitectura de Aplic Web
11/40
FUOC P07/M2106/02842 11 Arquitectura de aplicaciones web
tos tanto para ver cmo los niveles de carga (peticiones de pginas web) crecientes
afectan a nuestro servidor, como para observar peridicamente el comportamien-
to de un servidor web analizando los diarios (logs) que puede generar.
Para probar el rendimiento de un servidor web, normalmente se utiliza algn
programa que, instalado en otro computador, genere un ritmo de peticionesequivalentes para medir el efecto de las visitas simultneas desde distintos
clientes. El ritmo de peticiones puede configurarse de una manera ligeramente
distinta para cada herramienta, pero el objetivo es ser estadsticamente equi-
valente a la demanda real que el servidor pueda experimentar durante su fun-
cionamiento normal. Esto recibe el nombre de carga sinttica.
Hay muchas herramientas. A continuacin se describen brevemente tres he-
rramientas populares y gratuitas.
Microsoft Web Application Stress (WAS) es una herramienta de simulacin
para Windows diseada para medir el rendimiento de un sitio web. Tiene
en cuenta las pginas generadas dinmicamente (ASP) en un servidor web
de Microsoft.
Apache JMeter, una aplicacin Java para medir el rendimiento de documen-
tos y recursos estticos y dinmicos (archivos, servlets, scripts Perl, objetos
Java, consultas de bases de datos, servidores FTP, etc.), que simula distintos
tipos de carga extrema de la red, del servidor o de un objeto concreto.
Surge de la Universidad de Boston: una aplicacin Java que genera peticio-
nes web con caractersticas estadsticas que simulan con mucha precisin
la demanda tpica de un servidor web.
Durante el funcionamiento normal del servidor, es conveniente supervisar la
demanda y el rendimiento del servicio para detectar la degradacin del servi-
cio (responde muy lentamente por exceso de peticiones o trfico) o situacio-
nes crticas (sobrecarga: no responde).
Figura 7
Una de las muchas grficas que genera una herramienta de estadsticas web popular y gratuita denominada webalizer, que puede
encontrarse en la direccin http://www.mrunix.net/webalizer/ y que facilita mucho el anlisis de la actividad de un servidor web.
Visitas web sobregeneradores de carga
Apache JMeter:jakarta.apache.org/jmeter/
Surge:www.cs.bu.edu/faculty/crovella/links.html
8/9/2019 Arquitectura de Aplic Web
12/40
FUOC P07/M2106/02842 12 Arquitectura de aplicaciones web
Las herramientas de visualizacin y anlisis de actividad del servidor se basan
en el hecho de que prcticamente todos los servidores son capaces de generar
archivos histricos de la actividad del servidor (conocidos como diarios, en in-
gls logs) en un formato conocido como common log formato CLF.
En CLF cada lnea (a veces denominada entrada) registra una peticin recibida
por el servidor. La lnea est formada por distintos elementos separados por
espacio:
mquina ident usuarioautorizado fecha peticin estado bytes
Si un dato no tiene valor, se representa por un guin (-). El significado de cada
elemento es el siguiente.
Mquina: el nombre DNS completo o su direccin IP si el nombre no est
disponible.
Ident: si est activado, la identidad del cliente tal y como lo indica el pro-
tocolo identd. Puede no ser fiable.
UsuarioAutorizado: si se pidi un documento protegido por contrasea,
corresponde al nombre del usuario utilizado en la peticin.
Fecha: la fecha y hora de la peticin en el formato siguiente:
date = [da/mes/ao:hora:minuto:segundo zona]
da = 2*digit
mes = 3*letter
ao = 4*digit
hora = 2*digit
minuto = 2*digit
segundo = 2*digit
zona = (+ | -) 4*digit
Peticin: el URL solicitado por el cliente, delimitado por comillas ().
Estado: el cdigo de resultado de tres dgitos devuelto al cliente.
Bytes: el nmero de bytes del objeto servido, sin incluir cabeceras.
Este formato es adecuado para registrar la historia de las peticiones, pero no con-
tiene informacin til para medir el rendimiento del servidor. Por ejemplo, no in-
dica el tiempo transcurrido en servir cada URL.
Para permitir construir un formato de entrada de diario (log) que contenga la
informacin necesaria, puede definirse un formato particular que puede con-
tener otra informacin. A continuacin se muestra una lista de las variables
que el servidor web Apache puede guardar (mod_log).
8/9/2019 Arquitectura de Aplic Web
13/40
FUOC P07/M2106/02842 13 Arquitectura de aplicaciones web
Segn estas variables, el formato CLF sera:
%h %l %u %t \%r\ %>s %b
El formato CLF incluyendo el servidor web virtual solicitado (un servidor web
puede servir a diferentes dominios DNS o servidores virtuales):
%v %h %l %u %t \%r\ %>s %b
Nombre Descripcin de la variable
%a Direccin IP remota.
%A Direccin IP local.
%B Bytes enviados, excluyendo las cabeceras HTTP.
%b Bytes enviados, excluyendo las cabeceras HTTP. En formato CLF: un - enlugar de un 0 cuando no se ha enviado ningn byte.
%c Estado de la conexin cuando la respuesta se acaba:
X = conexin abortada antes de acabar la respuesta.
+ = conexin que puede quedar activa despus de haber enviado larespuesta.
- = conexin que se cerrar despus de haber enviado la respuesta.
%{NOMBRE}e El contenido de la variable de entorno NOMBRE.
%f Nombre del fichero.
%h Nombre de la mquina remota.
%H El protocolo de la peticin.
%{Nombre}i El contenido del encabezado o encabezados Nombre: de la peticinenviada al servidor.
%l Usuario remoto (de identd, si lo proporciona).
%m El mtodo de la peticin.
%{Nombre}n El contenido de la nota Nombre desde otro mdulo.
%{Nombre}o El contenido de la cabecera o cabeceras Nombre: de la respuesta.
%p El puerto del servidor sirviendo la peticin.
%P El identificador del proceso hijo que sirvi la peticin.
%q El texto de una consulta o query string(precedido de ? si la consulta existe, sino un texto vaco).
%r Primera lnea de la peticin.
%s Estado de peticiones que fueron redireccionadas internamente, el estado dela peticin original - %>s para el de la ltima.
%t Tiempo (fecha) en formato de LOG (formato estndar ingls).
%{format}t El tiempo (hora), en el formato especificado, que debe expresarse enformato strftime (posiblemente localizado).
%T El tiempo de servicio de la peticin, en segundos.
%u Usuario remoto (de autentificacin; puede ser incorrecto si el estado de larespuesta %s es 401).
%U La parte de camino (path) del URL, sin incluir el texto de la consulta
(querystring).
%v El nombre original o cannico del servidor dependiente de la peticin.
%V El nombre del servidor segn el valor del orden UseCanonicalName.
8/9/2019 Arquitectura de Aplic Web
14/40
FUOC P07/M2106/02842 14 Arquitectura de aplicaciones web
El formato NCSA extendido/combinado sera:
%h %l %u %t \%r\ %>s %b \%{Referer}i\ \%{User-agent}i\
Analizar la demanda y rendimiento de un servidor es una tarea necesaria, ya
que los servidores web estn sujetos a variaciones de demanda muy extrema.
Despus del anlisis de los ficheros de diario del servidor puede ser necesario
limitar, resituar y ampliar los recursos del servidor y la red de acceso a Internet
para poder atender aceptablemente el extrao y voluble trfico de peticio-
nes que visita los servidores web.
8/9/2019 Arquitectura de Aplic Web
15/40
FUOC P07/M2106/02842 15 Arquitectura de aplicaciones web
2. Organizacin de las aplicaciones en servidores web
Las aplicaciones web aplicaciones que van asociadas o son extensiones de un
servidor web pueden necesitar un diseo y ajuste muy cuidadosos para ofre-
cer un rendimiento adecuado en situaciones de alta demanda, o simplemente
para responder rpidamente o aprovechar de manera adecuada los recursos de
la mquina en la que estn instalados.
En primer lugar, hay que saber cmo est organizado un servidor web para
atender peticiones HTTP de la manera ms eficiente.
En segundo lugar, se debe conocer cmo puede extenderse el servidor webpara ofrecer otros servicios gestionados por un cdigo adicional.
2.1. Organizacin del servidor web
Para caracterizar cmo se organiza un servidor web para atender peticiones de
una manera eficiente y econmica, es necesario definir algunos trminos.
Proceso: la unidad ms pesada de la planificacin de tareas que ofrece elsistema operativo. No comparte espacios de direcciones ni recursos relacio-
nados con ficheros, excepto de manera explcita (heredando referencias a
ficheros o segmentos de memoria compartida), y el cambio de tarea lo fuer-
za el ncleo del sistema operativo (preemptivo).
Flujo o thread: la unidad ms ligera de planificacin de tareas que ofrece
el sistema operativo. Como mnimo, hay un flujo por proceso. Si distintos
flujos coexisten en un proceso, todos comparten la misma memoria y re-
cursos de archivos. El cambio de tarea en los flujos lo fuerza el ncleo del
sistema operativo (preemptivo).
Fibra: flujos gestionados por el usuario de manera cooperativa (nopreemp-
tivo), con cambios de contexto en operaciones de entrada/salida u otros
puntos explcitos: al llamar a ciertas funciones. La acostumbran a imple-
mentar libreras fuera del ncleo, y la ofrecen distintos sistemas operativos.
Para ver qu modelos de proceso interesan en cada situacin, hay que consi-
derar las combinaciones del nmero de procesos, flujo por proceso y fibras por
flujo. En todo caso, cada peticin la sirve un flujo que resulta la unidad de eje-
cucin en el servidor.
Arquitecturadel servidor web
El apartado 4.4 ServerArchitecture del libroKrishnamurthy, Web Protocolsand Practice(pgs. 99-116),describe un estudio sobre elfuncionamiento de Apache 1.3.
8/9/2019 Arquitectura de Aplic Web
16/40
FUOC P07/M2106/02842 16 Arquitectura de aplicaciones web
Los modelos que se pueden construir son (U: nico, M: mltiple):
En general, los modelos con muchos procesos son costosos de memoria (cada
proceso ocupa su parte) y de carga (creacin de procesos). En servidores de alto
rendimiento, los modelos con flujos parecen mejores, aunque tienen el pro-
blema de la portabilidad difcil y la posible necesidad de mecanismos que an-
ticipan el coste de creacin de procesos o flujos y, por lo tanto, son muy
rpidos atendiendo peticiones.
Cuando la red limita el servicio web, lanzar procesos para atender peticiones
puede funcionar razonablemente bien, pero en redes de alta velocidad, com
ATM o Gigabit Ethernet, la latencia en iniciar un proceso al recibir una peti-
cin es excesivo.
En mquinas uniprocesador, los modelos con un solo flujo funcionan bien. En
mquinas multiprocesador, es necesario usar mltiples flujos o procesos para
aprovechar el paralelismo del hardware.
El mayor obstculo para el rendimiento es el sistema de ficheros del servidor,
ya que la funcin principal del servidor web es trasladar ficheros del disco a
la red. Si ste se ajusta, el siguiente obstculo es la gestin de la concurrencia.
Adems, los estudios de trfico web indican que la mayora de las peticiones
son de ficheros pequeos, por lo cual sera conveniente optimizar el servidor
para poder priorizar estas peticiones que son ms frecuentes y mejoran el
Proceso Flujo Fibra Descripcin
U U U Es el caso de los procesos gestionados por inetd. Cada peticin genera un proceso hijo que sirve lapeticin.
M U U El modelo del servidor Apache 1.3 para Unix: distintos procesos preparados que se vanencargando de las peticiones que llegan.
Lo implementa el mdulo Apache: mpm_prefork.
M U M En cada proceso, una librera de fibras cambia de contexto teniendo en cuenta la finalizacin deoperaciones de entrada/salida. En Unix se denomina select-event threadingy lo usan los servidoresZeus y Squid. Ofrece un rendimiento mejor en Unix que en MUU.
Lo implementa el mdulo Apachestate-threaded multi processing.
M M U El modelo MMU cambia fibras por flujos.
Lo implementan los mdulos Apache: perchildy mpm_worker_module. El nmero de peticionessimultneas que puede atender es ThreadsPerChildx MaxClients.
U M U El modelo ms sencillo con diferentes flujos. Se puede montar en Win32, OS2, y con flujos POSIX.
Lo implementa el mdulo Apache: mpm_netware.
U M M Probablemente el que proporciona un rendimiento ms alto. En Win32 se puede conseguir conlos denominados completion ports. Se usan los flujos necesarios para aprovechar el paralelismo delhardware(nmero de procesadores, tarjetas de red), y cada flujo ejecuta las fibras que hancompletado su operacin de entrada/salida.
Es el modelo con un rendimiento ms alto en Windows NT.
Lo implementa el mdulo Apache: mpm_winnt_module.
Muchos servidores como Internet Information Server o IIS 5.0 utilizan este modelo con WindowsNT. El servidor web interno al ncleo de Linux Tux tambin utiliza este modelo.
M M M Puede ser una generalizacin de UMM o MUM, y en general la presencia de distintos procesoshace que el servidor se pueda proteger de fallos como consecuencia de que un proceso tenga quemorir por fallos internos, como por ejemplo el acceso a memoria fuera del espacio del proceso.
TUX: servidor weben el ncleo de Linux
Tux es un servidor web incor-porado al ncleo de Linux queusa un poolcon muy pocosflujos del ncleo (un flujo porprocesador), lee directamentede la memoria del sistema deficheros de dentro del ncleo,usa su propio algoritmo de pla-nificacin de fibras y usa elTCP/IP zero-copy que mini-miza las veces que los datosque vienen de la red se copian
en la memoria (en redes de altavelocidad como Gigabit Ether-net, las copias de bloques dememoria son el factor limitan-te). Puede servir entre dos ycuatro veces ms peticiones/segundo que Apache o IIS.
Para ms informacin:www.redhat.com/docsmanuals/tux/
8/9/2019 Arquitectura de Aplic Web
17/40
FUOC P07/M2106/02842 17 Arquitectura de aplicaciones web
tiempo de respuesta percibido por los usuarios, por ejemplo al cargar pginas
web con muchos grficos pequeos insertados.
Por esta razn, Apache 2.0 es un servidor web modular en el cual la gestin del
proceso est concentrada en un mdulo que puede seleccionarse en la insta-
lacin, segn las caractersticas del sistema operativo, la mquina, los recursos
que tendr que utilizar el servidor, etc.
2.2. Organizacin de las aplicaciones web
Los servidores web se encargan de atender y servir peticiones HTTP de recur-
sos, que en su forma ms simple acostumbran a ser documentos guardados en
el sistema de ficheros. Sin embargo, la otra funcin importante de un servidor
web es la de actuar de mediador entre un cliente y un programa que procesa
datos. Recibe una peticin con algn argumento, la procesa y devuelve un re-
sultado que el servidor web entrega al cliente. La interaccin entre el servidor
web y los procesos que tiene asociados es otro aspecto que hay que considerar.
Existen distintas maneras de organizar una aplicacin web. A continuacin,
por orden cronolgico de complejidad y rendimiento creciente, se presentan
distintos modelos de organizacin.
CGI: es el modelo ms antiguo y simple. Para cada peticin HTTP se invoca
un programa que recibe datos por las variables del entorno y/o de entrada
estndar, y devuelve un resultado por la salida estndar. Consumir un pro-
ceso por cada peticin genera problemas importantes de rendimiento, que
el modelo FastCGI intenta mejorar.
Servlets: es un modelo diseado para Java, ms eficiente y estructurado, que
permite elegir distintos modelos de gestin de flujos o threads, duracin de
procesos del servidor, etc. Partiendo de este modelo, se han construido ser-
vidores de aplicaciones con mltiples funciones adicionales que facilitan el
desarrollo de aplicaciones web complejas.
2.3. Interfaz comn de pasarela (common gateway interface, CGI)
La interfaz comn de pasarela es un estndar para proporcionar una interfaz
web a programas que se ejecutan en cada peticin y que, por lo tanto, pueden
devolver informacin dinmica. Puesto que un programa CGI es ejecutable es
como dejar que todo el mundo ejecute un programa en el servidor, hay que to-
mar muchas precauciones al hacer accesibles programas CGI por va del servidor
web.
8/9/2019 Arquitectura de Aplic Web
18/40
FUOC P07/M2106/02842 18 Arquitectura de aplicaciones web
Un CGI es un programa externo que se ejecuta y responde a cada peticin del
servidor web dirigida al CGI. El modo de funcionamiento es el siguiente:
Figura 8
Un servidor web que utiliza procesos (comandos) CGI.
Cada peticin crea un proceso que recibe los datos de entrada por medio de laentrada estndar y del entorno, y genera una respuesta por la salida estndar.
Por ejemplo, si se quiere conectar una base de datos a la web, para que todo
el mundo la pueda consultar, se debera escribir un CGI. Al pedir al servidor
web un URL dirigido al CGI, el programa consultar la base de datos y devol-
ver un texto, posiblemente HTML, que presente el resultado de la pregunta.
Se puede conectar cualquier programa que siga las reglas sencillas de los CGI
para ser invocado por el servidor web, siempre que el programa no tarde mu-
cho en responder, ya que el usuario o el navegador se pueden cansar de esperar.
Este procedimiento consume muchos recursos del servidor y es lento. Esta
informacin se puede ampliar en: http://www.w3.org/CGI/.
2.3.1. FastCGI
Para solucionar el problema anterior, se cre una mejora de los CGI que hace
que un solo proceso cargado vaya sirviendo peticiones sin descargarse (un pro-
ceso persistente o daemon), pero a veces no basta con un proceso y es necesario
tener distintos procesos al mismo tiempo atendiendo diferentes peticionesque se dan de manera simultnea.
Figura 9
Un servidor que utiliza procesos persistentes FastCGI.
8/9/2019 Arquitectura de Aplic Web
19/40
FUOC P07/M2106/02842 19 Arquitectura de aplicaciones web
Tanto los CGI como los FastCGI no pueden interactuar con el interior del ser-
vidor (por ejemplo, generar una lnea en los ficheros de diario del servidor).
Ms detalles en http://www.fastcgi.com.
Otra alternativa para extender el servidor de una manera ms eficiente consis-
te en utilizar las API de extensin de cada servidor (NSAPI en el servidor de
Netscape/Sun, ISAPI en el servidor de Netscape, o un mdulo en Apache). Las
extensiones forman parte del proceso servidor y estas API ofrecen mucha ms
funcionalidad y control sobre el servidor web, adems de velocidad, al estar
compiladas y formar parte del mismo ejecutable.
Figura 10
Un servidor que incorpora cdigo externo usando la API de extensin.
Sin embargo, tienen tres problemas importantes: son extensiones no porta-bles, especficas para un nico servidor; son ms complejas de desarrollar y
mantener; e introducen riesgo en el proceso servidor peligro en lo que respec-
ta a la seguridad y fiabilidad (un error de la extensin puede detener el proceso
servidor de web).
2.4. Servlet Java
Un servletes una extensin genrica del servidor: una clase Java que se puede
cargar dinmicamente en el servidor para extender la funcionalidad del ser-vidor web. En muchos casos, sustituye con ventajas los CGI.
Es una extensin que se ejecuta en una mquina virtual Java (JVM) dentro del
servidor: es seguro y transportable. Puesto que se ejecuta desde el servidor, el
cliente web lo invocar como si fuese un CGI, y en la respuesta slo ver el
texto HTML, sin que el cliente deba tratar con Java (como s hace en los applets,
que es cdigo Java que se ejecuta en una mquina virtual Java del cliente web).
En general, un servletes un trozo de cdigo que se ejecuta en un servidor: se
puede usar para extender servidores de web, pero tambin sirve para otros
servidores (p. ej., FTP para aadir comandos nuevos, correo para filtar o de-
tectar virus, etc.).
Servlets:
una aportacin de Sun
La especificacin de Servletscontina evolucionando.
Los servletsson una extensinestndar de Java, y las clasesacostumbran a venir con lasdistribuciones de Java SDK(Equipo de Desarrollo Java) oen la direccin siguiente: http://java.sun.com/products/servlet
8/9/2019 Arquitectura de Aplic Web
20/40
FUOC P07/M2106/02842 20 Arquitectura de aplicaciones web
Figura 11
Un servidor con servletsen su JVM.
Para usar los servlets, es necesario un motor en el que probarlos y ponerlos
en servicio. Pueden ser servidores que ya soporten servlets (por ejemplo, Tom-
cat de Apache, Domino Go de Lotus, Website de OReilly, Jigsaw del Consor-
cio Web), o mdulos que se pueden aadir a servidores que inicialmente no
los soportaban (por ejemplo, Jserv para Apache: http://tomcat.apache.org).
Las ventajas principales de los servlets son las siguientes:
Portabilidad. Siempre usan las mismas llamadas (API) y circulan sobre Java.
Esto hace que sean verdaderamente porttiles entre entornos (que soporten
servlets).
Versatilidad. Pueden usar toda la API de Java (excepto AWT), adems de
comunicarse con otros componentes con RMI, CORBA, usar Java Beans,conectar con bases de datos, abrir otros URL, etc.
Eficiencia. Una vez cargado, permanece en la memoria del servidor como una
nica instancia. Distintas peticiones simultneas generan diferentes flujos so-
bre el servlet, que es muy eficiente. Adems, al estar cargado en la memoria
puede mantener su estado y mantener conexiones con recursos externos,
como bases de datos que puedan reclamar un cierto tiempo para conectar.
Seguridad. Adems de la seguridad que introduce el lenguaje Java (gestin
de memoria automtica, ausencia de punteros, tratamiento de expresio-
nes), el gestor de seguridad o security managerpuede evitar que servlets ma-
lintencionados o mal escritos puedan daar el servidor web.
Integracin con el servidor. Pueden cooperar con el servidor de unas ma-
neras en las que los CGI no pueden, como cambiar el camino del URL, po-
ner lneas de diario en el servidor, comprobar la autorizacin, asociar tipos
MIME a los objetos o incluso aadir usuarios y permisos al servidor.
2.4.1. La API de servlets
Los servlets usan clases e interfaces de dos paquetes: javax.servlet que con-
tiene clases para servlets genricos (independientes del protocolo que usen) y
Tomcat
El servidor tomcat es un servi-dor web escrito con Java quesoporta directamente servlets
y es de uso libre: http://jakarta. apache.org/tomcat.
8/9/2019 Arquitectura de Aplic Web
21/40
FUOC P07/M2106/02842 21 Arquitectura de aplicaciones web
javax.servlet.http (que aade funcionalidad particular de HTTP). El nom-
bre javax indica que los servlets son una extensin.
Los servlets no tienen el mtodo main() como los programas Java, sino que se
invocan unos mtodos cuando se reciben peticiones. Cada vez que el servidor
enva una peticin a un servlet, se invoca el mtodo service() que se tendrque reescribir (override). Este mtodo acepta dos parmetros. un objeto peti-
cin (request) y un objeto respuesta.
Los servlets HTTP, que son los que usaremos, ya tienen definido un mtodo
service() que no es necesario redefinir y que llama el doXxx() con Xxx,
el nombre del orden que viene con la peticin del servidor web: doGet(),
doPost(), doHead(), etc.
Figura 12
Un servletHTTP que trata peticiones GET y POST.
A continuacin se puede observar el cdigo de un servletHTTP mnimo que
genera una pgina HTML que dice Hola amigos! cada vez que se invoca en
el cliente web.
El servidor extiende la clase HttpServlet e implementa el mtodo doGet().
Cada vez que el servidor web recibe una peticin GET para este servlet, el servi-
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class hola extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
res.setContentType(text/html);
PrintWriter out = res.getWriter();
out.println(Hola amigos!);
}
}
8/9/2019 Arquitectura de Aplic Web
22/40
FUOC P07/M2106/02842 22 Arquitectura de aplicaciones web
dor invoca su mtodo doGet() y le hace llegar un objeto con datos de la peti-
cin HttpServletRequest y con otro objeto HttpServletResponse para
devolver datos en la respuesta.
El mtodo setContentType() del objeto respuesta (res) establece como tex-
to/HTML el contenido MIME de la respuesta. El mtodo getWriter() obtie-
ne un canal de escritura que convierte los caracteres Unicode que usa Java en
el juego de caracteres de la operacin HTTP (normalmente ISO-8859-1). Aquel
canal se usa para escribir el texto HTML que ver el cliente web.
2.5. Resumen y comparacin
Por lo tanto, es posible extender la funcionalidad de un servidor web incorpo-
rando servlets que atienden peticiones web. Usan los mtodos de HTTP GET,
con los argumentos codificados en el URL (URL encoded), y POST, donde los
argumentos viajan al cuerpo de la peticin. En general, los servlets sirven para
extender la funcionalidad de cualquier servidor aadiendo nuevos servicios o
comandos.
Figura 13
Interaccin del navegador con el formulario y del servidor web con los servlets.
Una ventaja importante de los servlets respecto a los CGI es que se puede se-
leccionar la poltica de servicio (flujos e instancias): una vez instanciado un
servlet en la mquina virtual Java (JVM), puede servir diferentes peticiones
usando un flujo para cada una o, al contrario, un objeto (con un solo flujo)
para cada peticin. Un servlettambin puede guardar informacin que persiste
durante la vida del objeto o conexiones en bases de datos. Adems, la librera de
servlets facilita y abstrae el paso de parmetros y su codificacin, el seguimiento
de sucesivas visitas de un mismo cliente (sesiones), la transformacin de jue-
gos de caracteres entre cliente y servidor, etc.
El modelo cliente web + formulario HTML / servidor web + extensiones (CGI o
servlet) es adecuado para aplicaciones en las cuales el usuario utiliza un cliente web
que invoca una nica operacin al servidor con un conjunto de parmetros tex-
tuales y sin estructura que recoge el cliente web mediante un formulario HTML.
Servidores de aplicaciones
Son servidores que incorporanmuchos servicios y componen-tes reutilizables que permitendesarrollar aplicaciones com-plejas accesibles por HTTP.
Algunos ejemplos de servido-res de aplicaciones muy popu-lares (los dos implementan elmodeloJava 2 Enterprise Edition
o J2EE):www.jboss.org de cdigo li-bre, www.bea.com: WebLogicServer, comercial.
8/9/2019 Arquitectura de Aplic Web
23/40
FUOC P07/M2106/02842 23 Arquitectura de aplicaciones web
3. Servidoresproxy-cacheweb
Para la web, se dise un protocolo simple (HTTP) de acceso a documentos so-
bre un transporte fiable como TCP. Un objetivo de diseo era la interactivi-
dad: el cliente se conecta con el servidor web, solicita el documento (peticin)
e inmediatamente lo recibe del servidor. Este esquema es rpido en situaciones
de trfico en la red y carga de los servidores reducida, pero no es eficiente en
situaciones de congestin.
Para todas aquellas situaciones en las cuales la comunicacin directa cliente-
servidor no es conveniente, se ha introducido un tipo de servidores que hacen
de intermediarios entre los extremos.
La idea delproxyse usa en muchos protocolos adems del HTTP. En general, se
sitan en una discontinuidad para realizar en la misma una funcin. Por ejemplo:
Cambio de red. Una mquina conectada a la red interna de una organizacin que
usa direcciones IPv4 privadas (por ejemplo, 10.*.*.*), y tambin en Internet, puede
hacer de intermediario para traduccin de direcciones IP entre las dos redes (NAT).
Si no se desea usar este mecanismo, que tiene ciertas limitaciones, se puede salvar
la discontinuidad al nivel del HTTP poniendo un intermediario HTTP: una m-
quina conectada a las dos redes que recibira peticiones de pginas web desde
cualquier cliente interno por una direccin interna y volvera a generar la misma
peticin desde el intermediario, pero hacia Internet, con la direccin externa.
Figura 14
Interaccin entre cliente-servidor intermediario-servidor tal y como aparece en la publicacinoriginal (Luotonen, 94) describiendo el servidor intermediario HTTP del CERN (Centro Europeode Investigacin en Fsica), en el que fue inventada la web.
Un servidor intermediario (proxy) es un servidor que acepta peticiones
(HTTP) de clientes u otros intermediarios y genera a su vez peticiones
hacia otros intermediarios o hacia el servidor web destino. Acta como
servidor del cliente y como cliente del servidor.
NAT (network addresstranslation)
En los paquetes IP salientes:sustituir la direccin IP de m-quinas internas (no vlidas enInternet) por la suya propia, enlos paquetes IP entrantes: susti-tuir su propia direccin IP porla de una mquina interna y re-enviar el paquete hacia la redinterna.
Para poder saber a quin entre-garlo, el intermediario debeasociar cada uno de sus puer-tos a mquinas internas, pues
una direccin de transporte esuna pareja (direccin IP,puerto).
8/9/2019 Arquitectura de Aplic Web
24/40
FUOC P07/M2106/02842 24 Arquitectura de aplicaciones web
Como podis suponer, aprovechando que tanto la peticin como el resultado
(la pgina web) pasarn por el intermediario, se puede aprovechar para ofrecer
algunas funciones:
Control de acceso a contenidos. El intermediario consulta si la pgina solici-
tada est o no permitida por la poltica de la organizacin. Puede hacerse con-
sultando una tabla de permisos o usando el mecanismo denominadoPICS.
Control de seguridad. El intermediario genera todas las peticiones que salen
a Internet, lo que oculta informacin y evita ataques directos sobre las mqui-
nas internas de la organizacin. Adems, puede existir un cortafuego que no
permita acceder directamente hacia el exterior, con lo que el uso del interme-
diario es imprescindible.
Aprovechar peticiones reiteradas (funcin cach). El intermediario puede al-
macenar (en memoria o disco) una copia de los objetos que llegan como resultado
de peticiones que han pasado por el intermediario. Estos objetos se pueden usar
para ahorrar peticiones hacia Internet y servir peticiones sucesivas de un mismo
objeto con una copia almacenada en el intermediario, sin tener que salir a buscar-
lo a Internet. Losproxy-cache son el caso ms frecuente de servidor intermedia-
rio, y son los que detallaremos aqu.
Adaptar el contenido. Un intermediario podra tambin adaptar los objetos
que vienen del servidor a las caractersticas de su cliente. Por ejemplo, con-
vertir los grficos al formato que el cliente entiende, o reducir su tamao
para clientes como telfonos mviles con reducida capacidad de proceso, co-
municacin o presentacin.
El intermediario puede ser transparente, invisible para cliente y servidor: se
obtiene el mismo resultado con el mismo o sin el mismo, aunque en los nave-
gadores web habitualmente el usuario debe configurar expresamente su nave-
gador para usarlo, pues el navegador no tiene un mecanismo para detectarlo
y usarlo automticamente.
En algunas instalaciones, se puede instalar unproxytransparente que son routers
extensiones del software del que hacen que ste intercepte las conexiones TCP
salientes hacia el puerto 80 (HTTP) y las redirija a unproxy-cache. Tiene el pe-
ligro de que el usuario no es consciente de esto, y puede llevar a situaciones
equvocas si elproxy-cache falla o trata mal la peticin.
En la figura siguiente podemos ver cmo hay servidores intermediarios para
distintos protocolos adems de HTTP, y que unproxypuede comunicarse con
el servidor origen (el que tiene el documento original que el usuario ha solici-
tado) o pedirlo a otroproxy, formando una jerarqua deproxies.
PICS: Platform forInternet Content Selection
El PICS define mecanismospara que se puedan catalogarsitios y pginas web segnciertos criterios y, de estamanera, controlar el acceso acontenidos no deseados. Estil en escuelas y hogarespara controlar el acceso aInternet de los menores.
Control de contenidos:
ciertos contenidos que seconsideren no apropiadospor la organizacin puedenser bloqueados o redirigidos.
Podis encontrar msinformacin en la direccinsiguiente:http://www.w3.org/PICS/.
El protocolo HTTP 1/1...
... tiene definido un cdigo derespuesta a una peticin:
305 Use proxy
El problema es que no se llega un acuerdo al escribir la espe-cificacin, y la respuesta haceque simplemente en el nave-gador aparezca el mismo men-saje de error, en lugar de tratarde buscar un proxyy reintentarla conexin mediante el mis-mo. Cmo arreglarlo?
8/9/2019 Arquitectura de Aplic Web
25/40
FUOC P07/M2106/02842 25 Arquitectura de aplicaciones web
Figura 15
Un servidor intermediario se suele situar con proximidad a un cliente y puede colaborar con otros servidores intermediarios, perotambin puede estar cerca de un servidor (servidor intermediario inverso).
Se usan tambinproxies en la proximidad de un servidor para reducir la carga de
peticiones sobre el mismo. Son losproxies inversos: puede ser ms sencillo y ba-
rato colocar uno o variosproxy-cache que reciban todas las peticiones: responde-
rn directamente a las peticiones ya cacheadas y al servidor slo le llegarn unas
pocas que no estn an en elproxy-cache, o han expirado o son contenidos di-
nmicos.
Figura 16
a) Peticin HTTP 1.0 cliente servidor intermediario, b) peticin HTTP 1.0 servidorintermediario servidor. Podemos observar cmo el servidor intermediario introduceun campo reenviado (forwarded) para notificar su presencia al servidor.
Debido a la gran difusin del uso de servidoresproxy-cache, sobre todo en en-
tornos acadmicos, la especificacin HTTP/1.1 define una nueva cabecera que
permite controlar el comportamiento de un servidorproxy-cache tanto desde
el cliente en la peticin como desde el servidor en una respuesta.
Cache-control (peticin):
No-cache Clienteorigen (las memorias cach se inhiben).
No-store El proxyno debe almacenar permanentemente peticin/respuesta.
Max-age = sgs La mxima edad aceptable de los objetos en la cach.
a)
b)
8/9/2019 Arquitectura de Aplic Web
26/40
FUOC P07/M2106/02842 26 Arquitectura de aplicaciones web
Cache-control (respuesta):
Los servidoresproxy-cache tienen algoritmos para decidir si, cuando llega una
peticin de un contenido que ya tienen, es o no necesario confirmar que no
haya cambiado en el servidor origen, y el campo cach-control permite influir
en la decisin. Otro problema grave es la prdida de privacidad potencial si se
guardan contenidos en el proxy-cache, ms cuando se almacenan objetos endisco. Para esto tambin sirve el campo cache-control.
Su uso puede producir una reduccin de trfico en la red y en el tiempo de es-
pera si los objetos que se piden estn en la memoria y el contenido se puede
mediar. Estudios en distintas organizaciones muestran con frecuencia tasas de
acierto en la memoria del 15-60% de objetos, aunque esto pueda variar mucho
con los usuarios y el contenido.
Los servidoresproxy-cache son sistemes pasivos que aprovechan para guardar las
respuestas a peticiones de usuarios. Automticamente no intentan guardar con-
tenidos que parecen privados, dinmicos o de pago: los detectan por la pre-
sencia de campos en la cabecera como por ejemplo: WWW-Authenticate,
Cache-Control:private, Pragma:no-cache, Cache-control:no-cache, Set-Cookie.
Max-stale Se aceptan objetos viejos.
Max-stale = sgs Se aceptan objetos sgs segundos viejos.
Min-fresh = sgs Al objeto deben quedarle sgs de vida.
Only-If-Cached Peticin si slo est en el servidorproxy-cache.
Public Se puede cachear porproxiesy cliente.
Private Slo se puede guardar en la memoria cach del cliente.
Private=cabcTodos pueden mediar el objeto, excepto la cabecera cabc: slo en lamemoria cach del cliente.
No-cache No se puede mediar ni en servidores intermediarios ni en el cliente.
No-cache=cabc Combinacin de los dos anteriores.
No-storeNadie puede almacenar permanentemente (slo en la memoria delnavegador).
No-transform Los servidores intermediarios no pueden transformar el contenido.
Must-revalidate Revalidar (con origen) si es necesario.
Max-age Margen de edad en segundos.
Unproxy-cache est formado por un almacn de mensajes de respuesta
(objetos), un algoritmo de control del almacn (entrar, salir, borrar o re-
emplazar) y un algoritmo rpido de consulta (lookup) de un mapa del
contenido; toma la decisin de servirlo del almacn o pedirlo al servidor
origen o a otroproxy-cache.
Cookies(galletas): estadoy privacidad
El protocolo HTTP no tiene es-tado: cada interaccin (peti-cin + respuesta) no tienerelacin con las dems y cadauna puede usar una conexinTCP distinta.
Para poder relacionar variasinteracciones HTTP y pasar in-formacin de estado entre lasmismas, Netscape invent lascookies: un servidor web puedeenviar al cliente un objeto de
hasta 4096 bytes, que contie-ne datos que el navegador de-volver a ese mismo servidoren el futuro (o a otros servido-res que indique la cookie).
Las cookieshan sido muyusadas para cuestiones publici-tarias (qu sitios web visita lagente y en qu orden), paraguardar contraseas, identifi-car usuarios, etc. sin que elusuario sea consciente ni deque est recibiendo estasgalletas, ni de que las estenviando cuando visita la web.
Hay quien dice que son un er-
ror llevado a la perfeccin.Qu opinis? Habis miradoalguna vez qu cookiestenisen vuestro navegador?
8/9/2019 Arquitectura de Aplic Web
27/40
FUOC P07/M2106/02842 27 Arquitectura de aplicaciones web
Se han propuesto mejoras para hacer de los servidores proxy-cache intermedia-
rios activos: acumular documentos de inters en horas de bajo trfico para tener
el contenido preparado y de esta manera ayudar a reducir el trfico en horas de
alta demanda, o mecanismos depre-fetch en los que la memoria cach se adelan-
ta a traer, antes de que se lo pidan, pginas web que con gran probabilidad el
usuario va a solicitar a continuacin. Sin embargo, no son de uso comn pues
no siempre suponen un ahorro o mejora del tiempo de respuesta, sino que pue-
den llevar a malgastar recursos de comunicacin.
Los mecanismos deproxy-cache son tiles para que una comunidad de usuarios
que comparten una conexin a Internet pueda ahorrar ancho de banda, y re-
ducir transferencias repetitivas de objetos. Sin embargo, sta es slo una parte
del problema.
El problema en conjunto se conoce humorsticamente como elWorld-Wide
Wait. Varios agentes participan en el rendimiento de una transferencia web.
Proveedor de contenidos (servidor web): debe planificar su capacidad para
poder dar servicio en horas punta y aguantar posibles avalanchas de peti-
ciones y, de esta manera, tener cierta garanta de que sus clientes dispon-
drn de buen servicio con cierta independencia de la demanda.
Cliente: podra usar un servidorproxy-cache para economizar recursos de
la red. Cuando un contenido est en ms de un lugar, debera elegir el me-
jor servidor en cada momento: el original o una rplica rpida (o traerpor trozos el objeto desde varios a la vez).
Rplica: si un servidor guarda una rplica de algn contenido probable-
mente es porque desea ofrecerlo y reducir la carga del servidor original. Por
tanto, debe ser conocido por sus clientes, pero adems el contenido tiene
que ser consistente con el contenido original.
Proveedor de red: debera elegir el mejor camino para una peticin, va di-
reccionamiento IP, va resolucin DNS (resolver nombres en la direccin IP
ms prxima al cliente que consulte, aunque no es lo ms habitual), va
servidores proxy-cache HTTP y evitar zonas congestionadas (hot spots) o
flash crowd(congestin en el servidor y en la red prxima debida a una ava-
lancha de demandas).
Por tanto, losproxy-cachslo son parte de la solucin. Las redes de distribu-
cin de contenidos son la solucin de otra parte del W-W-Wait.
Una rplica (mirror)?
En enero de 2007, el programaHTTPD de Apache, el servidorweb ms utilizado en Internet,poda bajarse unas 300rplicas del sitio web original.
La lista de rplicas est en la di-reccin siguiente:
http://www.apache.org/mirrors/y la informacin del servidor enla direccin:
http://httpd.apache.org.
8/9/2019 Arquitectura de Aplic Web
28/40
FUOC P07/M2106/02842 28 Arquitectura de aplicaciones web
4. Contenidos distribuidos
Otra mejora que ayuda a combatir el mal del W-W-Wait son los sistemas de dis-
tribucin de documentos: basta un nico servidor para cualquier audiencia?
La respuesta es que no, si se desea ofrecer una calidad adecuada para demandas
tanto muy pequeas como bastante grandes, para contenidos que pueden llegar
a ser muy populares en ciertos momentos, que pueden visitarse desde cualquier
lugar del mundo o que pueden tener una audiencia potencial enorme.
En consecuencia, debe pagar ms quien tiene algo ms interesante que contar o
quiere llegar a ms. La web no funciona como una antena de radio: la potencia
de emisin determina la cobertura, pero el nmero de receptores no la afecta; es
ms similar al telfono: la capacidad se mide en nmero de lneas y esto deter-
mina el nmero de personas que pueden atenderse a la vez.
Por este motivo, puede ser necesario disponer de varios servidores para poder re-
partir la carga entre los mismos.
La primera pgina web pblica, ahora ya fuera de funcionamiento, fue
http://info.cern.ch. Sin embargo, la primera web con una demanda impor-
tante fue http://www.ncsa.uiuc.edu. Esta web tuvo que usar cuatro servidores
replicados para satisfacer la demanda. En la siguiente grfica puede verse la
evolucin del nmero de peticiones entre julio de 1993 (91.000 peticiones/se-
mana) y abril de 1994 (1.500.000 peticiones/semana).
Figura 19
Crecimiento del nmero de peticiones semanales durante dos aos. Cada tono de gris se corresponde con una mquina distinta.A mediados de febrero de 1994, diferentes mquinas empezaron a servir peticiones al mismo tiempo hasta llegar a cuatro.
Las aplicaciones que ofrecen contenidos en Internet se enfrentan al reto
de la escala: un solo servidor ante eventualmente millones de personas
que pueden pedirle sus servicios todos a la vez: el proveedor de infor-
macin debe poner tantos recursos como audiencia pueda tener.
8/9/2019 Arquitectura de Aplic Web
29/40
FUOC P07/M2106/02842 29 Arquitectura de aplicaciones web
Existen varios trucos para repartir peticiones entre diferentes mquinas:
Mirrors con un programa que redirige la peticin HTTP a la mejor rplica
(podis ver el ejemplo siguiente de Apache).
Hacer que el servicio de nombres DNS devuelva diferentes direcciones IP
(el mtodo round robin). De esta manera, los clientes pueden hacer peticio-
nes HTTP cada vez a una direccin IP distinta.
Redireccin en el nivel de transporte (conmutador de nivel 4,L4 switch): un
encaminador mira los paquetes IP de conexiones TCP hacia un servidor web
(puerto80) y las redirige a la mquina interna menos cargada.
Redireccin en el nivel de aplicacin (conmutador de nivel 7,L7 switch):
un encaminador que mira las conexiones HTTP y puede decidir a qu r-plica contactar en funcin del URL solicitado. Muy complejo.
Mandar todas las peticiones a unproxyinverso que responda o con conte-
nido guardado en la memoria o que pase la peticin a uno o varios servi-
dores internos.
Si, adems, las rplicas se sitan cerca de los clientes, el rendimiento ser me-
jor y ms predecible. El inconveniente es que es difcil y caro montar un ser-
vicio web distribuido.
La Fundacin Apache distribuye el servidor HTTPD Apache con la colabo-
racin de ms de doscientas rplicas distribuidas en todo el mundo. Aunque
las pginas web se pueden consultar en el servidor origen, a la hora de bajar
el programa hay un programa que calcula y redirige al visitante al servidor
ms prximo. De esta manera, las rplicas ayudan a repartir la carga a la vez
que ofrecen un mejor servicio al cliente. Aqu el contenido se actualiza pe-
ridicamente.
4.1. Redes de distribucin de contenidos
Han surgido empresas que se han dedicado a instalar mquinas en muchos lu-
gares del mundo y algoritmos para decidir qu mquina es la ms adecuada
para atender peticiones segn la ubicacin del cliente y la carga de la red. Estas
empresas venden este servidor web distribuido a varios clientes que pagan
por poder disponer de un sistema de servicio web de gran capacidad que puede
responder a demandas extraordinarias de contenidos.
Estos sistemas se denominan redes de distribucin de contenidos (content
delivery networks o CDN), y se pueden encontrar varias empresas que ofrecen
este servicio: Akamai es la ms importante.
www.google.com
Si se pregunta al DNS porwww.google.com, la respuestacontiene varias direcciones IP:nslookup www.google.com.
Cmo sermirrorde Apache?
Apache pide que al menos seactualice el contenido dos ve-ces por semana.
Las herramientas para hacerloson las siguientes.
1) rsync: un programa quecompara dos lugares remotos
y transfiere los bloques o fiche-ros que hayan cambiado.
Ver:http://rsync.samba.org.
2) cvs: un programa pensadopara desarrollo de cdigo a dis-tancia, y que permite detectare intercambiar diferencias.
Ver:http://www.cvshome.org.
3)Apache como proxy-cache:configurar un servidor Apachepara pasar y hacercachede laspeticiones. Orden:ProxyPass / http://www.apache.org/CacheDe-faultExpire 24.
8/9/2019 Arquitectura de Aplic Web
30/40
FUOC P07/M2106/02842 30 Arquitectura de aplicaciones web
Es como un servicio de logstica: la CDN se encarga de mantener copias cer-
ca de los clientes en sus propios almacenes (no en un punto central, sino en
los extremos de la red). Para esto, debe disponer de multitud de puntos de ser-
vicio en multitud de proveedores de Internet (servidores surrogate: funcionali-
dad entre servidorproxy-cache y rplica). Por ejemplo, Akamai ofreca en enero
del 2007 unos 20.000 puntos de servicio en todo el mundo.
Algunas CDN, adems, se sirven de enlaces va satlite de alta capacidad (y re-
tardo) para trasladar contenidos de un lugar a otro evitando la posible conges-
tin de Internet. Aunque puedan no ser ideales para objetos pequeos, puede
funcionar bien para objetos grandes (por ejemplo, software, audio, vdeo). Al-
gunos ejemplos son las empresas Amazon 33, Castify y Real Networks.
Mientras que la transferencia de una pgina web normal funciona como sigue:
Figura 20
Fases de una peticin web.
Una peticin de una pgina web (documento HTML + algunos grficos) hace dis-
tintas operaciones: 0.1) resolucin DNS del nombre del servidor, 1.1) conexin
TCP con el servidor, 1.2) solicitud del URL del documento, 2) el servidor de-
vuelve el documento HTML que contiene referencias a grficos incluidos en la
pgina, 3) resolucin DNS del nombre del servidor donde estn los grficos,
que acostumbra a ser el mismo servidor que para la pgina HTML, 3.1) solici-
tud de los grficos necesarios (puede repetirse distintas veces), 4) contenido
servido y pgina visualizada por el cliente (navegador).
Una CDN es un software intermediario (middleware) entre proveedores
de contenidos y clientes web. La CDN sirve contenido desde varios ser-
vidores repartidos por todo planeta. La infraestructura de la CDN est
compartida por varios clientes de la CDN, y las peticiones tienen en cu-
enta la situacin de la red para hacer que cada cliente web obtenga el con-
tenido solicitado del servidor de la CDN ms eficiente (habitualmente,
una combinacin del ms prximo, el menos cargado y el que tiene un
camino de mayor ancho de banda con el cliente).
Una propuesta difcil derechazar
La oferta de una CDN comoAkamai a un proveedor de ac-ceso a Internet (ISP) podra ser:
nos dejas en tu sala de mqui-nas el espacio equivalente paraun frigorfico casero, nosotroste mandamos unas mquinas yt las enchufas a la red elctri-ca y a tu red (Internet). Noso-tros las administramos.
Qu ocurrir? Todas las peticio-nes web a varios miles de em-presas sern servidas pornuestras mquinas.
El ISP ahorra gasto de anchode banda con Internet, puessus usuarios no necesitarnir a Internet para buscar algu-nos contenidos, que sern ser-
vidos por las mquinas deAkamai en el ISP.
Akamai cobra del proveedor decontenidos por servir el conteni-do ms rpido y mejorque nadie.
8/9/2019 Arquitectura de Aplic Web
31/40
FUOC P07/M2106/02842 31 Arquitectura de aplicaciones web
Una peticin a una CDN como Akamai aprovecha para tomar decisiones en
cada paso de la peticin:
Figura 21
Fases de una peticin web usando una CDN.
La CDN puede actuar sobre lo siguiente.
El DNS: cuando se resuelve un nombre, el servidor DNS responde segn la
ubicacin de la direccin IP del cliente.
El servidor web: cuando se pide una pgina web, se reescriben los URL in-
ternos segn la ubicacin de la direccin IP del cliente.
Cuando se pide un objeto a la direccin IP de un servidor de la CDN, el
conmutador (switch) de acceso a un conjunto de distintos servidoresproxy-
cache, o rplicas, puede redirigir la conexin al servidor menos cargado del
grupo (todo el conjunto responde bajo una misma direccin IP).
Los pasos de la peticin de una pgina web con grficos podran ser los si-
guientes:
0. El usuario escribe un URL (por ejemplo, http://www.adobe.com) en su na-
vegador, y su navegador resuelve el nombre en DNS (192.150.14.120).
1. El usuario pide el URL a la direccin IP (192.150.14.120).
1.a El servidor web elige la mejor rplica, segn IP origen, estado de la red y
ubicacin de las rplicas, o al menos clasifica al cliente en una zona geogr-
fica determinada (por ejemplo, con Akamai decide que estamos en la zona
del mundo o regin g).
2. El servidor devuelve el HTML con el URL de los grficos incluidos en la p-
gina (marcas ), que se han redirigido a una rplica. De esta manera, los
grficos que constituyen el mayor nmero de bytes de una pgina web serntransferidos por la CDN. Por ejemplo,
.
Akamai
Es interesante visitar la web deAkamai:
http://www.akamai.com
8/9/2019 Arquitectura de Aplic Web
32/40
FUOC P07/M2106/02842 32 Arquitectura de aplicaciones web
3. El cliente resuelve el nombre y pide grficos u otro contenido a la rplica
ms cercana.
3.a Posible redireccin con el DNS o por redireccin de la conexin TCP (en el ni-
vel del TCP o el HTTP: un conmutador de nivel 4 o 7), reparto de la carga en
un grupo de servidores.
4. Contenido servido ms rpido desde una rplica.
La ventaja de todo este montaje es que el usuario sigue viendo en su navegador un
URL normal (el de la pgina HTML), el servidor de la empresa tiene logs con visitas
a pginas HTML y el departamento de marketing puede hacer estadsticas, pero la
mayora del trfico (los grficos) lo sirve Akamai desde la proximidad del cliente.
Akamai mantiene informacin del estado de la red, de los clusters, de sus ser-
vidores. No siempre elige el mejor posible, pero s uno de los mejores, y en
cambio evita los peores servidores en cada momento.
Figura 22
Distribucin acumulada de tiempo de respuesta (latencia) de distintos servidores Akamai.
La grfica anterior muestra en lneas finas el tiempo que se tarda en obtener desde
un lugar determinado un objeto de 4Kb pedido a muchos servidores de Akamai.
El eje x, en escala logartmica, mide el tiempo (ms). El eje ymide la fraccin acumulada
de casos en los que el tiempo de descarga es inferior a un cierto valor. La lnea gruesa con-
tnua (agregado) mide la media de todos los servidores, y la lnea gruesa discontnua (aka-
mai) muestra el tiempo de respuesta del servidor que selecciona Akamai en cada
momento (prcticamente siempre selecciona el mejor).
La lnea gruesa contnua indica que si se hiciese una eleccin aleatoria, para el 20% (0,2)
de los casos el tiempo de servicio sera inferior a 64 ms, pero para el 80% de los casos el
tiempo sera inferior a 400 ms. Con la eleccin de Akamai, el 80% de las peticiones se
sirven en menos de 50 ms. Si eligiramos uno de los peores servidores, slo podramosdecir que el 80% de las peticiones se sirven en menos de 1.000 ms.
Consecuencia: la decisin de Akamai es casi ideal, mucho mejor que la decisin aleatoria,
y por supuesto que el peor caso (Ley de Murphy).
8/9/2019 Arquitectura de Aplic Web
33/40
FUOC P07/M2106/02842 33 Arquitectura de aplicaciones web
5. Computacin orientada a servicios
Las aplicaciones web devuelven resultados que pueden corresponder al conte-
nido de un archivo (contenidos estticos) o ser el resultado de la ejecucin de
un programa (contenidos dinmicos). Las aplicaciones que generan conteni-
dos dinmicos pueden requerir pequeas o grandes dosis de computacin y
almacenamiento. Algunos ejemplos son los buscadores web, las tiendas en In-
ternet, los sitios de subastas, los servicios de mapas o imgenes de satlite, que
pueden tener que efectuar complejos clculos, bsquedas, o servir enormes
volmenes de informacin.
Dentro de las organizaciones, tambin se utilizan sistemas complejos que pro-
cesan cantidades ingentes de datos y que presentan sus resultados mediante
un navegador. Ejemplos son las aplicaciones financieras, cientficas, de anli-
sis de mercados, que tratan con enormes cantidades de datos que hay que re-
coger, simular, predecir, resumir, estimar, etc., para que unas personas puedan
evaluar una situacin y tomar decisiones.
Figura 23
Ejemplo de una aplicacin de computacin intensiva, en el que, a partir de unas fuentes de datos reales o simulados, se almacenany procesan para la visualizacin de datos, anlisis y toma de decisiones.
En estos sistemas, cada unidad autnoma de procesamiento puede agruparse
en un servicio y la forma de interaccin entre ellos suele estar basada en servi-
ciosgrido servicios web. En cuanto a la interaccin con el usuario, todo ese
conjunto de servicios se puede esconder tras un servidor web y una interfaz de
usuario, que puede ser tradicional (basada en formularios html sencillos) o
bien ser ms interactiva y ms parecida a una aplicacin centralizada utilizan-
do las capacidades avanzadas de los navegadores como AJAX.
En este modelo de aplicaciones o sistemas, el procesamiento est repartido en-
tre el que ocurre en el navegador del usuario (relacionado con la presentacin
e interaccin con el usuario), el servidor web (mediacin entre una aplicacin
en el servidor y el navegador remoto) y otros servidores y servicios localizados
potencialmente en otras mquinas, ubicaciones e incluso otras organizaciones
siguiendo un modelo grid. Estos sistemas pueden tener una estructura fija o
bien dinmica, en la que las herramientas y recursos se incorporan segn la
demanda (un modelo de uso de ungridllamado utility computing).
Sobre el AJAX, podis ver el mdulo3, Mecanismos de invocacin.
8/9/2019 Arquitectura de Aplic Web
34/40
FUOC P07/M2106/02842 34 Arquitectura de aplicaciones web
5.1. Computacin bajo demanda
Utility computing(el servicio pblico de computacin) es un modelo tcnico
y de negocio, en el que los recursos informticos se proporcionan bajo deman-
da y pagando segn uso.
Difiere del modelo de computacin convencional en que, bajo este modelo,
no tienen que invertir en disponer de capacidad para el caso de mxima de-
manda, sino que pagan por el uso real de los recursos. La suma de varios cli-
entes con diferentes demandas que usan ciertos recursos hace que se optimice
su utilizacin. Este modelo degrides comparable al de uso de la electricidad,
gas, correos y muchos otros servicios pblicos, as que se le podra llamar ser-
vicio pblico de computacin. Atendiendo a su dependencia del uso, tambi-
n se le llama computacin bajo demanda.
La bsqueda en Internet
La bsqueda en Internet es una actividad intensiva en computacin. El siguiente artculo
muestra cmo se necesita un sistema masivamente replicado para dedicar a cada peticin
de bsqueda la mxima capacidad de computacin necesaria para encontrar las referen-
cias a cualquier cosa, en cualquier lugar de la web ordenado por relevancia.
Luiz Barroso; Jeffrey Dean; Urs Hoelzle (marzo, 2003). Web Search for a Planet: The Go-
ogle Cluster Architecture.IEEE Micro (vol. 23, nm. 2, pg. 22-28).
Comparando con la red elctrica, este modelo apuesta por no limitar la com-
putacin a la capacidad de una mquina aislada (con capacidad limitada de
clculo del procesador, almacenamiento de su disco duro, aplicaciones insta-
ladas y licenciadas, electricidad de su batera), sino tomar computacin,
almacenamiento, aplicaciones y electricidad de los correspondientes servicios
pblicos.
Estas ideas no son nuevas, y en 1969 uno de los inspiradores de la red Internet
dijo:
As of now, computer networks are still in their infancy, but as they grow up and becomesophisticated, we will probably see the spread of computer utilities which, like present elec-
tric and telephone utilities, will service individual homes and offices across the country.
Leonard Kleinrock(noviembre, 2005). A vision for the Internet.ST Journal of Research(vol.2, nm. 1, pg. 4-5).
En este modelo, las aplicaciones web no quedan limitadas a la interaccin na-
vegador-servidor web, sino que se convierten en aplicaciones completamente
distribuidas en trminos de procesamiento, almacenamiento, donde mltiples
componentes interactan entre s mediante el intercambio de datos, la invoca-
cin de servicios, y que requieren considerar en su diseo todos los conceptos
presentados en esta asignatura: desde la estructura y organizacin de los com-
ponentes, la sincronizacin y los problemas de orden en la concurrencia, la
fiabilidad y tolerancia a fallos, la rplica y el consenso entre las rplicas, el
rendimiento, los mecanismos de invocacin de servicios, etc.
8/9/2019 Arquitectura de Aplic Web
35/40
FUOC P07/M2106/02842 35 Arquitectura de aplicaciones web
Resumen
En este mdulo se han presentado las formas con las que un servicio web o
una aplicacin asociada a un servidor web se puede organizar para atender la
demanda que puede recibir de Internet.
Muchos indicadores de Internet continan creciendo exponencialmente: el
nmero de personas con acceso a Internet y el trfico web, que hoy en da pre-
domina sobre el resto de los protocolos. La popularidad de los contenidos si-
gue la ley de Zipf, la ley de la desigualdad extrema: muchas visitas para muy
pocos lugares. Esto hace que la demanda que pueda recibir en un momento
concreto un servidor web pueda ser exageradamente grande. Conocer las ca-ractersticas principales de esta demanda ayuda a prever situaciones en el di-
seo de un servicio web.
La capacidad para servir peticiones es difcil de prever en un sistema tan com-
plejo en el que influyen, entre muchos factores, la capacidad de la red y su car-
ga, las caractersticas de toda la mquina, el sistema operativo con numerosos
subsistemas o el servidor web. Es conveniente conocer la capacidad de servicio
de nuestro servidor y observar su comportamiento con niveles de carga eleva-
dos usando herramientas de generacin de trfico y medida del comporta-
miento bajo una carga sinttica, y tambin herramientas de visualizacin de
estadsticas de demanda real a partir de diarios (logs), que nos permitan detec-
tar sobrecargas, sintonizar o actualizar el conjunto adecuadamente.
Las aplicaciones en servidores web tienen dos componentes principales: el ser-
vidor web y el cdigo adicional, que extiende el servidor para ofrecer servicios
o contenidos dinmicos.
El servidor web es un sistema que se encarga de servir algunas de las muchas
peticiones simultneamente, por lo cual debe optimizarse la organizacin detoda esta actividad simultnea a partir de procesos, flujos y fibras.
Las aplicaciones web reciben peticiones del servidor y le devuelven un resulta-
do para enviar al cliente. Los CGI son el modelo ms sencillo y antiguo de in-
teraccin servidor-aplicacin, en el que el servidor invoca un comando (ejecuta
un proceso) para cada peticin.FastCGIes una mejora de los CGI para que el
cdigo externo al servidor no deba ejecutarse con cada peticin. Los servlets, la
propuesta ms reciente, proponen para Java un modelo muy completo y efi-
ciente de gestin de concurrencia y duracin de los procesos en el servidor.
Otro componente importante son los servidores intermedios entre navegadores
y servidores web que guardan copias de los objetos que ven pasar desde un ser-
8/9/2019 Arquitectura de Aplic Web
36/40
FUOC P07/M2106/02842 36 Arquitectura de aplicaciones web
vidor hacia un navegador. Principalmente, permiten acortar peticiones sir-
vindolas a medio camino del servidor, en la memoria, con objetos recibidos
recientemente, hecho que reduce la congestin de Internet y la carga de los ser-
vidores.
Mientras que los servidoresproxy-cache se suelen situar cerca de los lectores, la
demanda global de ciertos contenidos o la tolerancia a fallos puede recomen-
dar ofrecer un servicio web desde distintas ubicaciones. Hay diferentes mane-
ras de montar un servicio distribuido: replicacin o mirroring, DNS round-robin,
redireccionamiento en mbito de transporte o HTTP y servidores intermedia-
rios inversos.
Otra alternativa es contratar la provisin de servicio a una red de distribucin
de contenidos o CDN, que es una infraestructura comercial compartida por
distintos clientes, con infinidad de puntos de presencia prximos a la mayora
de los usuarios de Internet, que se encargan de repartir y dirigir las peticiones
web hacia los servidores menos cargados y ms cercanos al origen de la peti-
cin.
La computacin bajo demanda es un modelo ms general que permite distri-
buir un sistema en varios componentes distribuidos, que se comunican a base
de invocaciones a servicios, y el uso de recursos (computacin, almacenami-
ento, servicios de aplicacin), que se asignan dinmicamente segn sea la ne-
cesidad o el volumen de demanda de sus usuarios.
8/9/2019 Arquitectura de Aplic Web
37/40
FUOC P07/M2106/02842 37 Arquitectura de aplicaciones web
Actividades
1. Averiguad si el proveedor de Internet que tiene la conexin a Internet disponible en vues-
tro PC tiene disponible algn servidorproxy-cache y, si es as, configurad vuestro navegador
para utilizarlo. El uso del servidor ahorrar carga en algunos servidores que hayan servido an-
tes el mismo contenido esttico a otro usuario del servidorproxy-cache. Fijos si se produce
algn efecto apreciable con el uso del servidorproxy-cache.
Probad la memoria utilizando el comando telnet en el puerto delproxy. Se puede invocar el
mtodo GET de un objeto remoto:
o el mtodo trace del HTTP:
y ver el resultado de la peticin teniendo en cuenta los campos de cabecera de la respuesta
que indican el camino seguido por la peticin por medio de uno o varios servidoresproxy-
cache. Repetid la operacin para ver si el contenido llega hasta el servidor o nos responde el
servidorproxy-cache en lugar del servidor web.
2. Limpiad la memoria cach de vuestro navegador y configurad una memoria cach pequea
del navegador, visitad sitios con muchos grficos y dejad la ventana abierta sobre la carpeta
que contiene la cach en vuestro ordenador. Observad qu hace cuando est llena, qu obje-
tos reemplaza e inferid una hiptesis sobre qu datos tiene en cuenta para gestionar la cach.
Ejercicios de autoevaluacin
1. Considerando que una aplicacin web eficiente se pueda construir utilizandoFastCGIo
servlets, indicad qu caractersticas podra tener una aplicacin para que fuese preferible ha-
cerla con FastCGI, y otra en la cual la mejor opcin fuese servlets.
2. Qu diferencias pueden encontrarse al acceder por HTTP a un contenido web personaliza-
do (distinto para cada persona, por ejemplo durante la compra de varios libros en una libre-
ra, donde para cada libro se muestra una ficha que incluye una foto y un captulo de muestra
en PDF) en el caso de:a) conexin directa, b) conexin por medio de unproxy-cache, c) mediante una red de distri-
bucin de contenidos como Akamai.
Comentad el efecto sobre el retardo (tiempo en recibir el primer byte), tiempo de servicio (re-cibir el ltimo byte), el gasto de recursos de red y la carga del servidor origen del contenido.
3. HTTP1.1 tiene reservado el cdigo de error 305 (Use proxy) para que los servidores de HTTP
puedan no aceptar conexiones directas (que no hayan pasado antes por un proxy). Indicad
las razones y una situacin en la que este cdigo de error pueda ser de utilidad. Describid los
pasos que seguira un cliente que intentara inicialmente acceder a un servidor que no acepta
conexiones directas.
4. Hay distintas maneras de repartir la carga entre varios servidores de HTTP: a) redireccin
a un servidor HTTP que tiene una rplica del contenido, b) hacer que el servidor de DNS re-
suelva en cada momento a un servidor distinto (redireccin DNS), c) la redireccin a unproxy
de la pregunta anterior. Haced una tabla que compare qu limitaciones tiene cada una, y pro-
poned una situacin ptima para cada caso.
GET http://www.apache.org http/1.1
Host: www.apache.org
TRACE http://www.apache.org http/1.1
Host: www.apache.org
8/9/2019 Arquitectura de Aplic Web
38/40
FUOC P07/M2106/02842 38 Arquitectura de aplicaciones web
Solucionario
1. Una aplicacin conFastCGI: una aplicacin no escrita en Java, o que no necesite interac-
tuar excesivamente con el servidor, o que deba ser extremadamente eficiente o pequea.Una aplicacin con servlets: una aplicacin escrita en Java, o que necesite un modelo de pro-
ceso sofisticado, o que deba interactuar con el servidor web ms estrechamente o que tenga
que ser transportable con facilidad a otros servidores y/o otras mquinas.
2. Efecto sobre el retardo (tiempo en recibir el primer byte): a b aunque similares, excepto
en los casos en los que el objeto se encuentre en algn servidorproxy-cache y se pueda servir
inmediatamente sin verificar con el servidor (objeto esttico, que cambia poco o nada y ob-
tenido recientemente), en d; si el contenido lo sirve la CDN, seguramente ser muy rpido.Tiempo de servicio (recibir el ltimo byte): a, b como mnimo igual, b puede ser mucho ms r-
pido si el contenido se sirve del servidor intermediario. dprobablemente ser mucho ms rpido,
ya que se sirve de un lugar prximo al cliente, salvo que el cliente tenga limitaciones grandes de
velocidad de conexin a Internet.Gasto de recursos de red: b, cahorrar recursos de red, ya que pueden llevar el contenido desde
ms cerca que a.Carga del servidor origen del contenido: b ahorra peticiones repetitivas de contenido esttico
desde el grupo de clientes que usan los servidoresproxy-cache. En del servidor puede haber
delegado prcticamente por completo el servicio de aquel objeto a la CDN.
3. Cuando un servidor est sobrecargado puede devolver este cdigo de error para indicar alcliente que en lugar de conectarse directamente utilice un servidor intermediario. Esto podra
ayudar a agrupar las peticiones y, por lo tanto, a reducir la carga del servidor. El cliente debera
saber qu servidor intermediario tiene cerca que le pueda proporcionar servicio, y debera co-
nectarse con l y repetir la peticin va servidor intermediario. El inconveniente es que el
cliente deba tener un servidor intermediario accesible o que lo tenga que descubrir. Una alter-
nativa til sera que este cdigo de error pudiese orientar al cliente dndole la informacin
de un servidor intermediario que lo pudiese ayudar (un servidor intermediario inverso, por
ejemplo, que aceptara conexiones de cualquier cliente que pidiese pginas de aquel servidor).
4. La respuesta se podra expresar en una tabla como la siguiente:
Glosario
CDNf Vase content delivery/distribution network.
CGIf Vase interfaz comn de pasarela.
common gateway interfacef Vase interfaz comn de pasarela.
computacingridfModelo de computacin distribuida o paralela en el que un sistemapuede repartir sus funciones entre componentes que se comunican en red y utilizan recursos
o servicios pertenecientes a diversas organizaciones.
content delivery/distribution networkfRed de servidores que sirve pginas web segn
la ubicacin de los usuarios, el origen de la pgina web y el estado de carga de la red. Las p-ginas que sirve una CDN estn ubicadas (posiblemente en forma de cach) en distintos ser-
vidores repartidos por varias ubicaciones. Cuando un usuario pide una pgina que est
alojada en una CDN, la CDN redirecciona la peticin desde el sitio web original a un servidor
de la CDN que sea prcticamente ptimo en aquel momento para este cliente, teniendo en
A (a rplica) B (DNS) C (redireccin)
Limitaciones Hay que tener preparada la rplicaantes.
Propagar y actualizar el contenidopara que sea consistente.
Es mayor el retardo, pues hay queredirigir (establecer una nuevaconexin TCP).
Ha de replicarse un dominiocompleto (no slo un conjunto depginas).
Un cliente puede cachear laresolucin y cargar ms un servidorque otro.
Si se reduce el TTL de las respuestas,se genera ms trfico DNS.
Hay que modificar todos losservidores de DNS de este dominio(no si slo se usa round robin).
Implica establecer otra conexin TCP,con el retardo que esto supone.
El cliente puede no saber tratar elcdigo de error o no tenerconocimiento de un proxy, con lo queno se puede obtener la pginasolicitada.
Es necesario, adems, asegurarse deque el contenido est sincronizado.
Situacinptima
Contenido de alta demandaque cambia poco (mirrorde Apache).
Dominio completo replicado envarios servidores.
Situacin extraa. Este cdigo deerror no est bien especificado y, portanto, no est implementadocorrectamente.
Servira para reducir la carga de un
nico servidor sin usar rplicas.
8/9/2019 Arquitectura de Aplic Web
39/40
FUOC P07/M2106/02842 39 Arquitectura de aplicaciones web
cuenta distintos factores: distancia, carga de la red, carga del servidor, presencia del conteni-
do solicitado, etc. Es muy til para sitios web con mucho trfico e inters global. Cuanto ms
prximo geogrficamente est el servidor de la CDN del cliente, ms rpido recibir el con-
tenido y menos influencia tendr la carga de la red. La presencia de la CDN puede ser trans-
parente (invisible) para el usuario.sigla: CDN
interfaz comn de pasarela fInterfaz que especifica cmo transferir informacin entreun servidor web y un programa. El programa recoge datos que le pasa el servidor web y quevienen de un navegador, y devuelve datos en forma de documento. El programa se puede
escribir en cualquier lenguaje que se pueda ejecutar en la mquina del servidor web. Un pro-
blema es que para cada peticin se debe cargar y ejecutar el programa asociado, hecho quesignifica un gran gasto de recursos del servidor.en common gateway interfacesigla: CGI
proxym Vase servidor intermediario.
rplica fCopia de una entidad (documento, conjunto de documentos, servidor) que semantiene actualizada o sincronizada con otras rplicas de un conjunto. Los cambios realiza-
dos en una rplica se aplican y propagan al resto de las rplicas de manera automtica y trans-
parente para el usuario.
servidor intermediariom Servidor situado entre un cliente y un servidor real. Interceptalas peticiones del servidor real para ver si puede satisfacer la respuesta. Si no, reenva la peti-cin al servidor real. Los servidores intermediarios pueden tener dos propsitos: mejorar el
rendimiento (reducir el camino hasta la informacin: servidoresproxy-cache) o filtrar peticio-
nes (prohibir el acceso a ciertos contenidos web, o transformar el formato).en proxy
servletm Miniaplicacin Java (o applet) que se ejecuta en un servidor. El trmino se acostumbra
a aplicar a servidores web. Son una alternativa a los programas CGI. Los servlets son persistentes
y, una vez invocados, pueden quedarse cargados en la memoria y servir distintas peticiones,
mientras que las CGI se cargan, ejecutan y desaparecen para atender una sola peticin.
transparenteadj Invisible en informtica. Una accin es transparente si se produce sinefect