Unidad 2:

Capa de Aplicación. Servicio web

Administración de redes
2019-I
Modelo OSI vs TCP/IP
Capa de Aplicación
Capa de presentación
 Capa de sesión

Como su nombre lo indica, las funciones

de la capa de sesión crean y mantienen
diálogos entre las aplicaciones de origen
y destino.

La capa de sesión maneja el intercambio

de información para iniciar los diálogos
y mantenerlos activos y para reiniciar
sesiones que se interrumpieron o que
estuvieron inactivas durante un período
prolongado.
 Capa de Aplicación en TCP/IP

Los protocolos de capa de aplicación son utilizados tanto por

los dispositivos de origen como de destino durante una sesión
de comunicación. Para que las comunicaciones se lleven a
cabo correctamente, los protocolos de capa de aplicación que
se implementaron en los hosts de origen y de destino deben ser
compatibles.
Tipo de redes
Según la relación entre hosts
Modelo cliente-servidor
Modelo cliente-servidor
 Clientes, Servidores y Servicios

DNS (resolución de nombres de dominio)

HTTP (WWW)

FTP (transferencia de archivos)

SMTP (e-mail)
Telnet (conexión remota)
 El modelo Cliente / Servidor

Servidor: dispositivo
que responde a la
solicitud.
Cliente: dispositivo
que solicita
información.

• El cliente comienza el intercambio solicitando los datos al servidor.

• El servidor responde enviando uno o más streams de datos al cliente.

• Además de la transferencia real de datos, este intercambio puede

requerir de información adicional, como la autenticación del usuario y
la identificación de un archivo de datos a transferir.
• Un servidor
Servidores
generalmente es una
computadora que
contiene información
para ser compartida con
muchos sistemas de
cliente.
• Servidor de Web.
• Servidor de e-mail.
• Servidor de archivos y/o base de datos.
• Servidor de aplicaciones.

• Algunos pueden requerir autenticación de usuario para

verificar permisos para realizar una operación en particular.
• Ejemplo, si se solicita subir datos al servidor FTP, se puede dar
permiso para escribir la carpeta personal pero no para leer otros
archivos del sitio.
 Servidores
• En una red cliente-servidor, el servidor ejecuta un servicio o
proceso, a veces denominado daemon de servidor.

• Al igual que la mayoría de los servicios, los daemons

generalmente se ejecutan en segundo plano y no se encuentran
bajo control directo del usuario.
• Cuando un daemon "escucha" una solicitud de un cliente,
➢ intercambia los mensajes adecuados con el cliente,
según lo requerido por su protocolo.

➢ procede a enviar los datos solicitados al cliente en el

formato correspondiente.
Aplicaciones punto a punto
Redes punto a punto
 Redes Punto a Punto

• Durante el intercambio de archivos

las dos computadoras solo están
“conectadas” entre si
Aplicaciones P2P

•eDonkey
•eMule
•Shareaza
•BitTorrent
•Bitcoin
•LionShare
•Ares
 Software de la capa de Aplicación
• Existen dos formas de
procesos o programas de
software que proporcionan
acceso a la red: aplicaciones y
servicios

• Aplicaciones de red:
programas de software que
utiliza la gente para
comunicarse a través de la
red. (Ej. mensajeros, exploradores)

• Servicios de red: programas

que se comunican con la red y
preparan los datos para la
transferencia.
✓ Aplicaciones de usuario
✓ Servicios
✓ Operación del sistema
• La capa de aplicación utiliza protocolos que son
implementados con aplicaciones y servicios.
• Las aplicaciones proveen a la gente el medio para la creación
del mensaje.

• Los servicios ofrecen una interfaz hacia la red.

• Los protocolos determinan las reglas y formatos que rigen la

transferencia de los datos.

Nota: cuando nos referimos a

“Telnet” podemos llamarlo
aplicación, servicio o protocolo.
PROTOCOLOS DE CAPA DE APLICACIÓN
Evolución de Internet y el WWW
Evolución del Internet

Infografía: “La web en 47

años” por Ana Siles
 Evolución de la WWW

4 Web 4.0
Web inteligente y móvil
2018 ->
Web 3.0
Aplicaciones web
3
conectándose a aplicaciones
web.
2006 -> 2 Web 2.0
Personas conectándose a
personas
Web 1.0
Personas conectándose a la
1 2004->

web
1980-2004
 Evolución de la WWW
Web 1.0
Personas conectándose a la
1
web
1980-2004
Web estática – no interacción
250.000 sitios web estáticos
Primeros navegadores: Netscape e Internet Explorer
HTML, GIF, JavaScript 1.0
 Evolución de la WWW
Web dinámica 2 Web 2.0
• Interacción Personas conectándose a
personas
• Comunidades de usuarios – web social 2004->
• Redes sociales, blogs, wikis, podcasts, etc.
• Web: plataforma de inteligencia colectiva y
participativa
 Evolución de la WWW

Web 3.0
Aplicaciones web
3
conectándose a aplicaciones
web.
2006 ->

Web semántica
• Enriquecimiento de la comunicación por medio de metadatos
(semánticos)
• Respuesta rápida debido a la información más definida.
• Inteligencia artificial: chatbots, personalización basada en la identidad,
automatización del marketing, algoritmos de relación entre noticias,
temas de tendencias o personas
• Mejor procesamiento de contenidos.
 Evolución de la WWW

4 Web 4.0
Web inteligente y móvil
2018 ->

Web ubicua
• Comprensión de lenguaje natural (speech to text)
• Sistemas de comunicación máquina a máquina (M2M)
• Uso de información de contexto (Ej: ritmo cardiaco al smartwatch)
• Tendencia a la precognición (Ej: Minority Report)
 16.94
billones
de páginas indexadas
Protocolo HTTP
Hyper Text Transfer Protocol
Protocolo de Transferencia de HiperTexto - HTTP

• Hypertext Transfer Protocol es un protocolo cliente-

servidor que articula los intercambios de
información entre los clientes Web y los servidores
HTTP.
• La especificación completa del protocolo HTTP 1/0
está recogida en el RFC 1945. Fue propuesto por
Tim Berners-Lee, atendiendo a las necesidades de
un sistema global de distribución de información
como el World Wide Web.
Protocolo de Transferencia de HiperTexto - HTTP

• HTTP se basa en sencillas operaciones de

solicitud/respuesta. Un cliente establece una conexión con
un servidor y envía un mensaje con los datos de la solicitud.
• El servidor responde con un mensaje similar, que contiene el
estado de la operación y su posible resultado.
• Todas las operaciones pueden adjuntar un objeto o recurso
sobre el que actúan; cada objeto Web (documento HTML,
archivos multimedia o aplicación CGI) es conocido por su
URL.
 Protocolo HTTP
Cada vez que un cliente realiza una
petición a un servidor, se ejecutan los
siguientes pasos:

Fuente: netacad.com

Un usuario accede a una URL,

1 seleccionando un enlace de un documento
HTML o introduciéndola directamente en el
campo Location del cliente Web.
 Protocolo HTTP
Cada vez que un cliente realiza una
petición a un servidor, se ejecutan los
siguientes pasos:

Fuente: netacad.com

El navegador interpreta las tres partes del

URL:
1 1. http (el protocolo o esquema)
2. www.cisco.com (el nombre del servidor)
3. index.html (el nombre de archivo específico
solicitado)
 Protocolo HTTP

Servidor DNS

www.cisco.com.co 23.32.205.19

A continuación, el navegador se comunica

con un servidor de nombres para convertir
2 www.cisco.com en una dirección IP
numérica que utiliza para conectarse al
servidor,
 Protocolo HTTP

Mediante los requisitos de HTTP, el

navegador envía una solicitud GET al
3 servidor y solicita el archivo index.html .
El servidor envía el código HTML para esta
página web al navegador.
 Protocolo HTTP

Finalmente, el navegador descifra el

código HTML y da formato a la página para
4 que se pueda visualizar en la ventana del
navegador,
 Tipos de peticiones HTTP más comunes
• Cuando un cliente, por lo general un navegador web, envía una
solicitud a un servidor web, HTTP especifica los tipos de mensaje que
se utilizan para esa comunicación. Los tres tipos de peticiones
comunes son GET, POST y PUT:

• GET: solicitud de datos por parte del cliente. Un cliente (navegador

web) envía el mensaje GET al servidor web para solicitar las páginas
HTML.
• POST: carga archivos de datos, como los datos de formulario, al
servidor web.
• PUT: carga los recursos o el contenido, como por ejemplo una
imagen, en el servidor web.
 HTTP y HTTPS
• HTTP es sumamente flexible, no es un protocolo seguro. Los
mensajes de solicitud envían información al servidor en un texto sin
formato que puede ser interceptado y leído. Las respuestas del
servidor, generalmente páginas HTML, también están sin cifrar.

• Para una comunicación segura a través de Internet, se utiliza el

protocolo HTTP seguro (HTTPS). HTTPS utiliza autenticación y cifrado
para proteger los datos mientras viajan entre el cliente y el servidor.
• HTTPS utiliza el mismo proceso de solicitud del cliente-respuesta del
servidor que HTTP, pero el flujo de datos se cifra con capa de sockets
seguros (SSL) antes de transportarse a través de la red.
 Mensajes HTTP

En una comunicación HTTP sólo existen dos tipos de mensajes, los de

petición (request) y los de respuesta (reply).
Incluye:

• Una línea de solicitud

• Los campos del encabezado de

solicitud

• El cuerpo de la solicitud
 Mensajes HTTP

• Una línea de solicitud: es una línea que especifica el tipo de documento

solicitado, el método que se aplicará y la versión del protocolo utilizada.
La línea está formada por tres elementos que deben estar separados por
un espacio:
oel método
ola dirección URL
oLa versión del protocolo utilizada por el cliente (por
lo general, HTTP/1.0).
 Mensajes HTTP

• Los campos del encabezado de solicitud:

Es un conjunto de líneas opcionales que permiten aportar información
adicional sobre la solicitud y/o el cliente (navegador, sistema operativo,
etc.). Cada una de estas líneas está formada por un nombre que describe
el tipo de encabezado, seguido de dos puntos (:) y el valor del
encabezado.
 Mensajes HTTP

• El cuerpo de la solicitud:
Es un conjunto de líneas opcionales que deben estar separadas de las
líneas precedentes por una línea en blanco y, por ejemplo, permiten que
se envíen datos por un comando POST durante la transmisión de datos al
servidor utilizando un formulario.
Petición del cliente
Respuesta del servidor
 Métodos de petición: GET, POST, HEAD, PUT,
DELETE y TRACE

Método Significado
GET Solicita el recurso ubicado en la URL especificada
HEAD Funciona como el GET, pero sin que el servidor devuelva el cuerpo del mensaje.
Es decir, sólo se devuelve la información de cabecera.
POST Indica al servidor que se prepare para recibir información del cliente. Suele
usarse para enviar información desde formularios.
PUT Envía el recurso identificado en la URL desde el cliente hacia el servidor.
OPTIONS Pide información sobre las características de comunicación proporcionadas por
el servidor. Le permite al cliente negociar los parámetros de comunicación.

TRACE Inicia un ciclo de mensajes de petición. Se usa para depuración y permite al

cliente ver lo que el servidor recibe en el otro lado.
DELETE Solicita al servidor que borre el recurso identificado con el URL.
CONNECT Este método se reserva para uso con proxys. Permitirá que un proxy pueda
dinámicamente convertirse en un túnel. Por ejemplo para comunicaciones con
SSL.
 Cabeceras
Las Cabeceras HTTP son los parámetros que se envían en una petición o
respuesta HTTP al cliente o al servidor para proporcionar información
esencial sobre la transacción en curso. Estas cabeceras proporcionan
información mediante la sintaxis 'Cabecera: Valor' y son enviadas
automáticamente por el navegador o el servidor Web.
Las cabeceras del protocolo http están compuestas por los siguientes
componentes:
• Connection (conexión)
Permite especificar diferentes opciones para la conexión. Por ejemplo:
Connection: close indica que la conexión debe cerrarse una vez
transmitido el mensaje completo
• Content-Language (idioma del contenido)
Esta cabecera indica el idioma de los destinatarios del recurso. Si no
existe, se entiende que el recurso está orientado a todos los usuarios,
independientemente del idioma. Esta cabecera permite listar varios
idiomas.
 Cabeceras
• Content-Length (longitud del contenido)
Indica la longitud del cuerpo del recurso, expresada en número de octetos.
• Content-Location (localización del contenido)
Dirección complementaria que ofrece el servidor en su respuesta. Esta
nueva dirección (una URI absoluta o relativa) no corrige la dirección
original del recurso solicitado por el cliente, sino que ofrece una ruta a un
recurso que complementa al solicitado originalmente.
• Content-Type (tipo de contenido)
Indica, como su nombre indica, el tipo de contenido del recurso. Así, la
cabecera Content-Type: text/html; charset=ISO-8859-l indica que el recurso
es de tipo texto, concretamente código HTML, y codificado según la
especificación ISO-8859-1.
 Cabeceras
• Date (fecha) :
Indica la fecha de creación del recurso. Tiene la forma: Date: Tue, 12 Jul
2017 09:32:25 GMT
• Expect (espera)
Mediante esta cabecera, el cliente indica qué tipo de respuesta espera del
servidor. Si el servidor no está preparado para responder como el cliente
espera, debe indicarlo mediante el envío de un código de estatus 417
(Expectation Failed).
• Expires (expiración)
Indica la fecha a partir de la cual el recurso debe considerarse obsoleto. Un
ejemplo: Date: Tue, 12 Jul 2005 09:32:25 GMT.
 Cabeceras
• From ("desde")
Dirección de correo electrónico del usuario (humano) autor de la solicitud.
• If-Match ["sf cuodfa")
Se usa junto con la cabecera de método para hacerlo condicional. Esto permite actualizaciones
eficientes de la caché. Si el cliente guarda en su caché alguna entidad (algún elemento
distinguible! del recurso solicitado puede verificar gracias a esta cabecera si esta entidad sigue
estando en vigor, es decir, si la copia guardada en la caché sigue siendo válida.
• If-Modified-Since ("sise ha modificado desde")
Igual que la cabecera If-Match, If-Modified-Since se usa con la cabecera que indica el método
para expresar una condición. Si el recurso no ha variado desde la fecha indicada por el cliente,
el servidor no debe enviarlo. Enviará, en cambio, un código de estatus 304, confirmándole al
cliente (navegador, por ejemplo, o robot de un buscador) que la copia que tiene en caché sigue
siendo una copia fiel del recurso guardado en el servidor.
• If-None-Match ("sino cuadra")
Igual que las cabecera If-Match e If-Modified-Since, se usa junto con la cabecera de método
para someterlo a una condición. Funciona de forma inversa a if-Match. El servidor no debe
ejecutar la solicitud (expresada mediante la cabecera de método| si la entidad expresada por
la condición de If-None-Match se cumple.
 Cabeceras
• IP (remóte adress)
No es estrictamente una cabecera del protocolo HTTP, sino del protocolo TCP/IP.
Expresa la identificación numérica de una máquina.
• Host (servidor)
Nombre del servidor.
• Last-Modified (última modificación)
Mediante esta cabecera el servidor informa de la fecha y hora en que el recurso
fue modificado por última vez.
• Location (localización)
Mediante este campo el servidor indica la dirección (la URL) de un recurso
cuando no se encuentra en la dirección en que se ha solicitado. De esta forma,
el servidor invita al navegador (o al software del cliente en general) a que se
redlrija a la nueva localización.
• Referer (remitente)
Documento desde el cual se ha realizado la solicitud actual. Si desde la URL
www.cibernetia.com/index.php cucamos el enlace que lleva a
www.cibernetia.com/headers_manual/index.php, la primera URL figurará como
referer en la solicitud de la segunda URL.
 Cabeceras

• Request (solicitud)
Indica el fichero (el documento) solicitada y el método y versión del protocolo
que se van a emplear para realizar la conexión.
• Status Code (código de estado)
Mediante el código de estado el servidor informa al navegador sobre cómo ha
resuelto la solicitud de un documento. Esta cabecera nos indicará, por ejemplo,
si se ha servido el documento con éxito o se ha producido algún problema,
como un error interno del servidor, o alguna incidencia, como una redirección
hacia otra URL diferente.
• User-Agent (agente de usuario)
El user-agent identifica el software de la máquina cliente fes decir, se refiere al
software instalado en el ordenador que solicita una página web). La
identificación se realiza, normalmente, mediante una combinación de sistema
operativo y navegador. Un par de ejemplos:
• Mozílla/4.0 (compatible; MSIE 6.0; Windows 98) Esta cabecera indica que el cliente
está navegando con la versión 6.0 de Internet Explorer corriendo en un Windows 98.
• Googlebot/2.1 (+http://www.google.com/bot.html) En este caso es un robot el que
está solicitando la página, concretamente Googlebot, la araña de Google.
 Códigos de estado y error

Las 5 clases definidas son las siguientes:

• 1xx. Informacional. Se recibe la petición y se continúa con el proceso. Los
códigos en este rango indican respuestas provisionales. Los servidores web no
deben enviar mensajes 1xx al cliente HTTP excepto bajo condiciones
experimentales.
• 2xx. Éxito. Esta clase de códigos indican que la petición del cliente fue recibida,
entendida, aceptada y procesada exitosamente.
• 3xx. Redireccionamiento. Para estos códigos el cliente debe realizar acciones
adicionales para completar la petición. La acción requerida debe ser portada por
el user agent sin la interacción del usuario si y solo si el método usado en la
segunda petición es de tipo GET o HEAD. El user agent no debería redireccionar
automáticamente más de 5 veces, sino se considera un bucle infinito.
• 4xx. Error en el Cliente. Estos códigos son arrojados cuando el cliente parece
tener un error. Estos tipos de errores son los más comunes que se pueden
encontrar.
• 5xx. Errores de Servidor. El servidor falla cuando aparentemente se está ante
una petición válida. El Servidor responde con este tipo de errores cuando es
incapaz de realizar la petición.
 Códigos de estado y error
Cuando se solicita al servidor una página de su sitio (por ejemplo, cuando
un usuario accede a su página a través de un navegador o cuando
Googlebot rastrea la página), se muestra un código de estado de HTTP en
respuesta a la solicitud.
Este código, que proporciona información acerca del estado de la
solicitud, ofrece a Googlebot datos acerca del sitio y de la página
solicitada. A continuación se muestran algunos de los códigos de estado
más frecuentes:
• 200 - El servidor ha mostrado la página correctamente.
• 404 - La página solicitada no existe.
• 503 - El servidor está temporalmente fuera de servicio.
A continuación se muestra una lista completa de códigos de estado de
HTTP, lxx (Respuesta provisional) Códigos de estado que indican una
respuesta provisional y requieren que el solicitante realice una acción
para poder continuar.
Caché web
 Almacenamiento en cache

Se llama caché web a la caché que almacena documentos web

(es decir, páginas, imágenes, etcétera) para reducir el ancho de
banda consumido, la carga de los servidores y el retardo en la
descarga. Un caché web almacena copias de los documentos
que pasan por él, de forma que subsiguientes peticiones
pueden ser respondidas por el propio caché, si se cumplen
ciertas condiciones.
 Almacenamiento en cache
Tipos de cachés web
Las cachés web pueden utilizarse de diversas formas.

Las cachés de agente de usuario (User-Agent), como las presentes en los navegadores
web, son cachés privados, que funcionan solo para un único usuario.

También existen paquetes específicos que se instalan como proxy local y actúan como
caché además de realizar otras tareas:
• Los intermediarios en la comunicación cliente-servidor también pueden implementar
cachés compartidos (también llamadas proxy-cachés directos) que sirvan páginas a
varios usuarios. Los proxy-cachés suelen ser usados por los proveedores de servicios
de Internet (ISP), universidades y empresas para ahorrar ancho de banda..
• Las cachés pasarela (llamadas también proxy-cachés inversos o aceleradores web)
funcionan a cargo del propio servidor original, de forma que los clientes no distinguen
unos de otros.
 Almacenamiento en cache

Control de los cachés web

El protocolo HTTP define tres mecanismos básicos para controlar las cachés:
• Frescura, que permite que una respuesta sea usada sin comprobar de
nuevo el servidor origen, y puede ser controlada tanto por el servidor
como el cliente.
• Validación, que puede usarse para comprobar si una respuesta cacheada
sigue siendo buena tras caducar.
• Invalidación, que normalmente es un efecto secundario de otra petición
que pasa por la caché. Por ejemplo, si la URL asociada con una respuesta
cacheada es solicitada posteriormente mediante una petición POST, PUT o
DELETE, la respuesta cacheada quedará invalidada.
 Redirecciones
Una redirección sirve para llevar al navegador del usuario a una
página distinta. Redirigir al navegador nos puede servir para enviarlo
a otra dirección URL distinta donde están los contenidos que desea
ver.
Existen dos tipos de redirecciones, la 301 que quiere decir
"Redirección permanente" y la 302 que significa "Redirección
temporal". El usuario que nos visita no percibe si estamos haciendo
una redirección de un tipo
u otro por PHP, pero el tipo de redi-
rección utilizada si resulta una inf.
interesante para buscadores, porque
entenderán que una dirección ha
cambiado temporal o permanente-
mente y eso les servirá para tener
actualizadas sus bases de datos.
 Redirecciones
Funcionamiento de una redirección web
• Se necesita que el encabezamiento enviado por la página consultada
corresponda a su estatus. Por ejemplo, si una página ha cambiado de
lugar en nuestro portal, es de vital importancia que la antigua URL
haga un redireccionamiento hacia la nueva, utilizando un
encabezamiento HTTP que precise que esta página ha cambiado de
manera definitiva de dirección (código 301)
• Esto permitirá al robot el no volver a indexar nunca la antigua URL,
poniendo al día su base de datos aplicando la nueva URL a la página
en cuestión.
• Si no aplicamos la redirección desde la antigua URL, el robot y los
visitantes obtendrán un error 404, lo cual no será una buena señal, ya
que de este modo el encontrar la nueva dirección se convertiría en
una misión complicada.
 Comprensión

Para reducir el tamaño de las páginas enviadas con HTTP, cuando nace el
protocolo HTTP1.1, se le añade una opción de compresión de página, de
esta manera, cuando el navegador hace una llamada al servidor, le indica
que puede recibir contenido comprimido. Se trata de comprimir la
información enviada por el servidor del sitio web, dejando al navegador
del visitante el trabajo de descomprimirlo. Esto se realiza
automáticamente, sin que el visitante lo perciba ni de deba intervenir.
• Ventajas: Al estar comprimida la Información esta se envía mucho más
deprisa desde el servidor al cliente, produciendo así una mejor
experiencia en la visita del sitio y recortando la cantidad de ancho de
banda utilizado por el sitio. Esto resulta generalmente en una
transferencia de entre 3 y 6 veces más rápido.
• Desventajas: Como la compresión se realiza dinámicamente, esta
requiere algo de procesamiento. Sin embargo, en nuestra experiencia
esto no tiene un impacto significativo en la performance del servidor.
 Cookies
Una cookie es información enviada desde un servidor de
páginas web y almacenada en el disco duro del visitante a
través del navegador. Esta información será reenviada de nuevo
al servidor en cada petición, de forma que el servidor puede
identificar o recuperar información sobre el usuario que está
accediendo.
 Cookies
¿Por qué se han creado las cookies?
Las cookies fueron implementadas por primera vez por Netscape
Communications para la creación del típico cesto de comprar en una
tienda online. El problema hasta entonces era que el protocolo HTTP
carecía de la posibilidad de mantener información por sí mismo. Los
métodos usados antes eran:
• Identificación por IP: un método muy poco fiable, pues bajo una misma
IP podían estar accediendo distintos usuarios (por ejemplo desde un
cíber), además que la dirección IP de un usuario puede cambiar.
• Por URL: Consiste en añadir la información en la URL, después del
interrogante ?. Esta es una técnica más precisa en lo que se refiere a
identificación, pero tiene problemas de seguridad.
Gracias a las cookies, un servidor web puede identificar un conjunto pc-
navegador-usuario y mostrar la información adecuada a ese conjunto, por
ejemplo un carrito de compra que haya creado.
 Autenticación
La autenticación es el proceso de identificar si un cliente es elegible
para tener acceso a un recurso. El protocolo HTTP soporta la
autenticación como un medio de negociar el acceso a un recurso
seguro.
La solicitud inicial de un cliente es normalmente una solicitud
anónima, que no contiene ninguna información de autenticación. Las
aplicaciones de servidor HTTP pueden denegar la solicitud anónima
indicando que se requiere la autenticación. La aplicación de servidor
envía encabezados de la autenticación de WWW para indicar los
esquemas de autenticación soportados.
 Autenticación

Tipos de autenticación:
• Autenticación básica: soportados por todos los servidores web y navegadores, así
como terminales móviles. Cuando el usuario accede a un recurso del servidor web
protegido mediante autenticación básica, tiene lugar el siguiente proceso:
1. El navegador presenta al usuario la ventana de autenticación,
para que introduzca su nombre y contraseña.
2. El navegador intenta establecer una conexión con el servidor
utilizando esta información.
3. Si el servidor rechaza la información de autenticación, el
navegador le presenta nuevamente la ventana al usuario hasta
que éste introduce por fin una contraseña válida o cierra la
ventana.
4. Cuando el servidor web verifica con éxito los datos de
autenticación, se establece la conexión de acceso al recurso
protegido.
 Autenticación

Tipos de autenticación:
• Autenticación mediante resúmenes ó digest: soportada por todos los servidores y en algunos navegadores.
Para paliar este inconveniente, además de cifrar el canal con SSL, otra alternativa consiste en enviar un
resumen criptográfico de la contraseña (un hash) en vez de la propia contraseña, de la siguiente forma:
1. El servidor envía al navegador cierta información que será utilizado en el proceso
de autenticación.
2. El navegador añade esta información a su nombre de usuario y contraseña, junto
con otra información adicional, y crea un resumen del conjunto. Esta información
adicional persigue el cometido de impedir ataques de reactuación, en los que un
atacante intercepta y copia el resumen, volviéndolo a utilizar para autenticarse él
mismo ante el servidor.
3. Se envía en claro tanto el resumen como la información adicional al servidor a
través de la red.
4. El servidor añade esta información adicional a una copia en claro de la contraseña
del cliente y crea el resumen del conjunto.
5. El servidor compara el resumen que ha creado con el que le ha llegado del
navegador.
6. SI ambos números coinciden, se le concede acceso al usuario. La autenticación
mediante resúmenes ha sido incorporada al estándar HTTP 1.1, pero
desgraciadamente la mayoría de navegadores no la soportan. Se puede encontrar
una descripción sobre su funcionamiento y consideraciones sobre su seguridad en
un borrador de Internet.
 Autenticación

Tipos de autenticación:
• Autenticación https: es una combinación del protocolo HTTP y protocolos
criptográficos.
El uso del formato HTTPS para enviar mensajes garantiza la autenticación de los
usuarios que necesitan acceso a los recursos de Message Queue Server por
medio de un servidor Web estableciendo una conexión de nivel de sockets seguro
(SSL) para conseguir una comunicación segura entre un remitente y un
destinatario. El emisor es siempre considerado como cliente SSL y el destinatario
como servidor SSL independientemente de si el equipo está ejecutando Message
Queue Servero software de cliente. Tenga en cuenta que la autenticación para
establecer una sesión de SSL no es la misma que la autenticación de mensajes,
que confirma que un mensaje no se ha manipulado y se puede utilizar para
comprobar la identidad del remitente. Para obtener información acerca dé la
autenticación de mensajes, consulte Administrar la autenticación de mensajes. En
la autenticación HTTPS se utilizan dos tipos de certificados:
1. Certificados de servidor. Este certificado contiene información sobre el servidor
que permite a un cliente identificar el servidor antes de compartir información
confidencial.
2. Certificados de cliente. Este certificado contiene información personal sobre el
usuario e identifica el servidor al cliente de SSL (el remitente).
 Conexiones persistentes

Las conexiones persistentes del HTTP son la idea de usar la misma

conexión del TCP para enviar y para recibir múltiples peticiones del
HTTP/responses, en comparación con abrir una nueva conexión para cada
solo par de la petición/response.
Si el navegador es compatible con mantenimiento de conexión, se añade
una cabecera adicional a la solicitud:
• Cuando el servidor recibe la solicitud y genera una respuesta, sino que
también agrega un encabezado a la respuesta: Después de esto, la
conexión no se cae, sino que se mantiene abierta.
• Cuando el cliente envía una nueva solicitud, que utiliza la misma
conexión. Esto continuará hasta que el cliente o el servidor decide que la
conversación ha terminado, y uno de ellos cae la conexión.
 Conexiones persistentes
Ventajas
• Menos CPU y uso de la memoria (porque pocas conexiones
están abiertas simultáneamente)
• Permite pipes del HTTP de peticiones y de respuestas
• Reducido congestión de red (menos Conexiones del TCP)
• Reducido estado latente en las peticiones subsecuentes (no
apretón de manos)
• Los errores se pueden divulgar sin la pena de cerrar la
conexión del TCP
Servicios web y organizaciones
 Servidores web en la organización

Cuando se habla de administrar una web, se

habla de ser responsable del funcionamiento de
un servidor web.

Un servidor web se puede ver desde dos

vertientes:

• como interfaz de una aplicación o

• como servidor de páginas.
 Servidor web y aplicaciones

Normalmente, cuando un servidor web se utiliza formando parte de

una aplicación, simplemente hace de interfaz para la aplicación, de
manera que es un elemento más.

Esta aplicación utiliza un navegador como enlace para presentar

las pantallas de salida y como mecanismo para pedir información al
usuario.

Los datos se guardan en una base de datos. Genéricamente, el

esquema es el siguiente:
 Servidor web y aplicaciones

La distribución de estos elementos en servidores físicos depende

de muchos
factores como, por ejemplo, el tamaño y la complejidad de la
aplicación, que
seguramente estará dividida en módulos. Muy posiblemente, la
estructuración
estará condicionada por el servidor web que se utilice.

En esta situación, pues, el servidor web es un medio, aunque muy flexible,

para hacer funcionar la aplicación, que es el centro principal de
todo.
 Servidor web de páginas

Si hace de servidor web con

entidad como tal, lo puede
hacer dentro de la intranet, en
Internet o, incluso, una parte
en la intranet y la otra en
Internet.

La web muestra la imagen

corporativa de la organización a
la comunidad
Internet.
 Servidor web y servidor de aplicaciones

Con la llegada de los servidores de aplicaciones se inicia una auténtica

revolución en el tratamiento de los servicios web. Aunque el punto de
entrada y primer tratamiento de las peticiones se realiza en el servidor
web, los sistemas complejos de generación de páginas que utilizan
procesamiento y acceso a datos necesitan los recursos que ofrecen los
servidores de aplicaciones.

Existen dos posibles vías de servicio según los niveles de acceso

necesarios:

• En dos niveles (servicios estáticos)

• En tres niveles (servicios dinámicos)
 Servicios estáticos y servicios dinámicos

Servicios estáticos.

• Servidos desde un servidor web.

• En el primer nivel situaríamos las estaciones de trabajo, ya sean locales o
remotas, y en el segundo nivel el servidor web. Estaríamos hablando de una
estructura cliente/servidor aplicada a un entorno web.

Servicios dinámicos

• Servidos desde un servidor web y un servidor de aplicaciones.

• En el primer nivel encontraremos las estaciones de trabajo y los usuarios
(locales o remotos).
• En el segundo nivel encontraremos el servidor web (puerta de entrada) y el
servidor de aplicaciones (proporciona capacidad de procesamiento y gestión
de datos). Finalmente, en el tercer nivel encontraríamos el servidor de base
de datos (datos centralizados del servicio web).
 Estructura de un servidor web
Núcleo. Es el servidor como tal, y es el centro del servidor web. Siempre
está cargado y funcionando cuando el servidor está puesto en marcha.

Módulos. Actualmente los servidores web pueden ser bastante complejos.

Esto es posible porque se ofrecen módulos para aumentar la funcionalidad
del servidor. También se les llama extensiones del servidor. Se instalan
cuando se configuran los servidores web, entonces se informa de qué
módulos se tienen que hacer funcionar. En general, un servidor puede hacer
muchas más funciones que dedicarse exclusivamente a entregar páginas
HTML que estén guardadas en el disco duro.

Páginas. Las páginas son el lugar

donde está guardada la
información que
presenta el servidor. Están
estructuradas en forma de árbol
de directorios,
aunque en algunos casos hay
módulos que modifican esta
información.
 Puertos

El puerto estándar de petición de documentos u otros recursos web es el 80.

En principio, un servidor web puede escuchar peticiones por cualquier
puerto.
Los servidores CAU, en cambio, pueden estar escuchando por el mismo
puerto 80 o por el 8080, y en los dos casos se trata de una configuración
estándar.

Un servidor CAU actúa como intermediario entre una red interna

y una conexión externa en Internet. Así se puede compartir
la misma conexión para recibir información desde servidores
web. Se usa también para filtrar contenidos.
 Tareas del administrador

Instalar y
Administrar los Conocer el Administrar las
administrar el
directorios. software. páginas
servidor web.

Ejemplo, podría dar servicio Hay dos clases de software Como las páginas no suelen
Cuando se tiene que diseñar que el administrador dela web ser desarrolladas por el
sólo a usuarios de una red
una nueva web, también se tiene que utilizar: administrador, es importante
local, o quizás de una intranet,
tiene que tener en cuenta el ser consciente de la
o puerta de acceso libre para •el que se utiliza para
modo en que se organizan los importancia de llegar con
cualquier usuario conectado a configurar el servidor
diferentes recursos. “pocos pasos” a donde sea
la red Internet. •el que proporciona las necesario:
herramientas de
preparación, modificación y • organiza la información, archivos
organización de las páginas y directorios
que forman la web. • apoya al creador de páginas y
aconsejarle cómo disponer los
Dependiendo del servicio al enlaces para acceder de una
que esté destinado este Lo más habitual, es tenerlos manera más rápida a toda la web
servidor web, las clasificados en carpetas o desde cualquier sitio.
configuraciones y políticas de directorios según el tipo.
diseño variarán.

La estructura en directorios
también permite, si es
necesario, una migración
mucho menos costosa.
 Responsabilidades del administrador
• Responsabilidad del servidor.
• Con UPS para garantizar disponibilidad del servicio.
• Anchos de banda acordes al tráfico, teniendo en cuenta picos de alto tráfico.
• Conexión de red redundante
 Responsabilidades del administrador

• Responsabilidad de los contenidos. Es importante

darse cuenta de los dos aspectos del contenido en
un servicio web:
• Tiene que haber un control de qué datos se proporcionan
en cada instante,de manera que no haya contenidos
anticuados, repetidos, sensibles o que no sean
coherentes entre ellos.
• En relación con el acceso a estos datos, tiene que haber
un control de cómo se gestiona, consulta y modifica la
base de datos a la cual puede estar accediendo el servidor
web.
 Responsabilidades del administrador

• Responsabilidad de la homogeneidad. Un aspecto

más de diseño que de administración es el control
de la imagen que refleja la web. Como se trata de
una puerta abierta a muchos usuarios potenciales,
que pueden no ser conocidos, se tiene que tener
mucho cuidado al presentar los recursos.
• Así, es importante tener en cuenta que en todas las
páginas tiene que haber un estilo constante.
 Responsabilidades del administrador
• Generación de estadísticas. Según las necesidades de cada
organización, esta tarea puede ser más o menos
importante.
• En general hay que tener un registro de los que han visitado
la web; tanto de lo que han visto como de cuándo y desde
dónde lo han hecho. Aparte, hay otros tipos de estadísticas
muy interesantes como, por ejemplo, a qué velocidad se
ofrecen los documentos o la cantidad de peticiones que hay
sobre las diferentes páginas, y el tiempo total que un cliente
se pasa navegando por toda la web.
Ejemplo de aplicaciones web 2.0
 Ejemplos de aplicaciones web 2.0

CMS

• Un sistema de gestión de contenidos (CMS) es un programa

que permite crear una estructura de apoyo para la creación
y administración de contenidos por parte de los
participantes.
• Es una aplicación de base de datos que automatiza el
proceso de administrar y mantener la publicación de
contenido.
• Un buen sistema de administración de contenido separa el
contenido de la presentación.
 Ejemplos de aplicaciones web 2.0

WIKIS

• La tecnología wiki permite que las páginas wiki sean

escritas de forma colaborativa a través de un
navegador web, conservando un historial de
cambios que permite recuperar fácilmente cualquier
estado anterior de la página.
• Es decir, que están diseñadas con la filosofía de que
sea fácil corregir los errores, en vez de que sea difícil
cometerlos
 Ejemplos de aplicaciones web 2.0

RSS

• El archivo RSS es una especificación de formato de

archivo, basada en XML 1.0, utilizada en Internet
para difusión de noticias y titulares.
• Es muy habitual en sitios web de prensa, blogs y de
contenidos técnicos.
• Al igual que el XML, es independiente de la
plataforma y se utiliza en las arquitecturas y
sistemas operativos más populares.
 Bibliografía
• http://cprzara2.educa.aragon.es/ficheros/recursosxp/Otras%20tarea
s%20administrativas
• Cisco CCNA1 V 6.0 Introducción a las redes. Capítulo 10
• Capítulo 26 de http://profesores.elo.utfsm.cl/~agv/icd327/
• Protocolo HTTP . Francisco Prieto Donate
MUCHAS GRACIAS
¿ Preguntas, comentarios o sugerencias ?