arquitectura de aplic web

8/9/2019 Arquitectura de Aplic Web

1/40

Arquitectura de

aplicaciones webLeandro Navarro Moldes

P07/M2106/02842


2/40


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


4/40


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.


6/40


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.


7/40


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/40


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).


9/40


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.


10/40


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-


11/40


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


12/40


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).


13/40


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.


14/40


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.


15/40


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.


16/40


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/


17/40


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.


18/40


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.


19/40


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


20/40


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.


21/40


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!);

}

}


22/40


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.


23/40


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).


24/40


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?


25/40


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)


26/40


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?


27/40


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.


28/40


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.


29/40


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.


30/40


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.


31/40


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


32/40


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).


33/40


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.


34/40


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.


35/40


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-


36/40


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.


37/40


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


38/40


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.


39/40


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

arquitectura de aplic web

Documents