2.

1 Principios de las aplicaciones de red

Suponga que tiene una idea para una nueva aplicación de red. Tal vez esta aplicación

será un gran servicio a la humanidad, o complacerá a tu profesor, o te traerá gran riqueza, o

simplemente será divertido de desarrollar. Cualquiera que sea la motivación. Ahora examine cómo
transformar la idea en una aplicación de red del mundo real. El núcleo del desarrollo de
aplicaciones de red es escribir programas que se ejecuten en diferentes sistemas finales y se
comunican entre sí a través de la red. Para ejemplo, en la aplicación Web hay dos programas
distintos que se comunican entre sí entre sí: el programa de navegación que se ejecuta en el host
del usuario (ordenador de sobremesa, portátil, etc.), y el programa de servidor Web que se ejecuta
en la Web servidor host. Como otro ejemplo, en un sistema de compartición de archivos P2P hay
un programa encada host que participe en la comunidad de compartición de archivos. En este
caso, los programas en los distintos hosts pueden ser similares o idénticos.

Por lo tanto, al desarrollar su nueva aplicación, necesita escribir software que se ejecutará
en múltiples sistemas finales. Este software podría estar escrito, por ejemplo, en C, Java, o Python.
Es importante destacar que no es necesario que escriba software que se ejecute en networkcore
tales como enrutadores o conmutadores de capa de enlace. Incluso si quisieras escribir para estos
dispositivos de núcleo de red, no podría hacerlo. Como aprendimos en el Capítulo 1, y como se
muestra anteriormente en la Figura 1.24, el núcleo de la red los dispositivos no funcionan en la
capa de aplicación, sino en las capas inferiores. Específicamente en la capa de red y debajo. Este
diseño básico, es decir, el confinamiento de aplicación hasta los sistemas finales, como se muestra
en la Figura 2.1, ha facilitado el rápido desarrollo y despliegue de una amplia gama de aplicaciones
de red.

Capas: 1Aplicacion, 2Transporte, 3Red, 4Enlace, 5Físico

2.1.1 Arquitecturas de aplicaciones de red

Antes de sumergirse en la codificación de software, debe tener un plan arquitectónico amplio para
su solicitud. Tenga en cuenta que la arquitectura de una aplicación es claramente diferente de la
arquitectura de red (por ejemplo, la arquitectura de Internet de cinco capas que se discutió en el
capítulo 1). Desde la perspectiva del desarrollador de aplicaciones, la arquitectura de red es fijo y
proporciona un conjunto específico de servicios a las aplicaciones. La aplicación arquitectura, por
otro lado, es diseñada por el desarrollador de la aplicación y dicta cómo está estructurada la
aplicación en los distintos sistemas finales. Al seleccionar la una arquitectura de aplicaciones, un
desarrollador de aplicaciones probablemente se basará en una de las dos paradigmas
arquitectónicos predominantes utilizados en las aplicaciones de red modernas: el arquitectura
cliente-servidor o arquitectura peer-to-peer (P2P)

En una arquitectura cliente-servidor, existe un host siempre activo, llamado servidor, que atiende
las peticiones de muchos otros hosts, llamados clientes. Un ejemplo clásico es el Aplicación web
para la que un servidor web siempre activo realiza peticiones desde los navegadores ejecutándose
en hosts de cliente. Cuando un servidor Web recibe una solicitud de un objeto de una responde
enviando el objeto solicitado al host del cliente. Tenga en cuenta que con la arquitectura cliente-
servidor, los clientes no se comunican directamente con cada uno de ellos.

otros; por ejemplo, en la aplicación Web, dos navegadores no se comunican directamente.

Otra característica de la arquitectura cliente-servidor es que el servidor tiene un dirección fija,

conocida, llamada dirección IP (que discutiremos pronto). Porque el servidor tiene una dirección
fija y bien conocida, y como el servidor está siempre encendido, un siempre puede contactar con
el servidor enviando un paquete a la dirección IP del servidor. Algunas de las aplicaciones más
conocidas con una arquitectura cliente-servidor son las siguientes Web, FTP, Telnet y correo
electrónico. La arquitectura cliente-servidor se muestra en la Figura 2.2(a).

A menudo, en una aplicación cliente-servidor, un host de un solo servidor es incapaz de mantener

el ritmo. Con todas las peticiones de los clientes. Por ejemplo, un sitio popular de redes sociales
puede rápidamente se abruma si sólo tiene un servidor que maneja todas sus peticiones. Para esta
razón, un centro de datos, que alberga un gran número de hosts, se utiliza a menudo para crear un
potente servidor virtual. Los servicios de Internet más populares, como los motores de búsqueda
(por ejemplo, Google y Bing), comercio por Internet (por ejemplo, Amazon y e-Bay), comercio
basado en la Web.

correo electrónico (por ejemplo, Gmail y Yahoo Mail), redes sociales (por ejemplo, Facebook y
Twitter) -

emplear uno o más centros de datos. Como se explica en la Sección 1.3.3, Google tiene de 30 a 50
centros de datos distribuidos por todo el mundo, que gestionan colectivamente la búsqueda,
YouTube, Gmail y otros servicios. Un centro de datos puede tener cientos de miles de servidores,
que deben ser alimentados y mantenidos. Además, los proveedores de servicios deben pagar
costes recurrentes de interconexión y ancho de banda para el envío de datos desde sus centros de
datos.

En una arquitectura P2P, la dependencia de los servidores dedicados es mínima (o nula) en centros
de datos. En su lugar, la aplicación explota la comunicación directa entre pares de anfitriones
conectados intermitentemente, llamados pares. Los compañeros no son propiedad del servicio
sino que son ordenadores de sobremesa y portátiles controlados por los usuarios, con la mayoría
de los compañeros que residen en hogares, universidades y oficinas. Porque los compañeros se
comunican sin pasar por un servidor dedicado, la arquitectura se llama peer-to-peer.
Muchas de las aplicaciones más populares e intensivas en tráfico de hoy en día están basadas en
P2P arquitecturas. Estas aplicaciones incluyen el uso compartido de archivos (p. ej., BitTorrent),
aplicaciones asistidas por compañerosaceleración de descargas (por ejemplo, Xunlei), telefonía por
Internet (por ejemplo, Skype) e IPTV (por ejemplo.., Kankan y PPstream). La arquitectura P2P se
ilustra en la Figura 2.2(b). Mencionamos que algunas aplicaciones tienen arquitecturas híbridas,
combinando tanto cliente-servidor y elementos P2P. Por ejemplo, para muchas aplicaciones de
mensajería instantánea, los servidores son

se utiliza para rastrear las direcciones IP de los usuarios, pero los mensajes de usuario a usuario se
envían directamente entre hosts de usuario (sin pasar por servidores intermedios).

Una de las características más convincentes de las arquitecturas P2P es su autoescalabilidad. Por
ejemplo, en una aplicación de compartición de archivos P2P, aunque cada par genera carga de
trabajo mediante la solicitud de archivos, cada par también añade capacidad de servicio al sistema
distribuyendo archivos a otros colegas. Las arquitecturas P2P también son rentables, ya que
normalmente no requieren una infraestructura de servidor significativa y ancho de banda de
servidor (en contraste con los diseños cliente-servidor con centros de datos). Sin embargo, el
futuro P2P las aplicaciones se enfrentan a tres grandes retos:

1. Compatible con ISP. La mayoría de los ISPs residenciales (incluyendo los ISPs DSL y de cable) han
sido de ancho de banda "asimétrico", es decir, para mucho más el tráfico aguas abajo que el
tráfico aguas arriba. Pero el streaming de vídeo P2P y la distribución de archivos las aplicaciones
desplazan el tráfico ascendente de los servidores a los ISPs residenciales, por lo que lo que supone
una carga importante para los proveedores de servicios de Internet. Las futuras aplicaciones P2P
deben ser diseñadas para que sean amigables con los ISPs[Xie 2008].

2. Seguridad. Debido a su naturaleza altamente distribuida y abierta, las aplicaciones P2P puede
ser un desafío para asegurar[Doucer 2002; Yu 2006; Liang 2006; Naoumov 2006; Dhungel 2008;
LeBlond 2011].

3. Incentivos. El éxito de las futuras aplicaciones P2P también depende de la convicción de que a
los usuarios para que ofrezcan voluntariamente recursos de ancho de banda, almacenamiento y
computación a las aplicaciones, que es el reto del diseño de incentivos[Feldman 2005; Piatek 2008;
Aperjis 2008; Liu 2010].

2.1.2 Procesos de comunicación

Antes de construir su aplicación de red, también necesita un conocimiento básico de

cómo se comunican entre sí los programas que se ejecutan en múltiples sistemas finales.

En la jerga de los sistemas operativos, en realidad no son los programas sino los procesos los que

comunicarse. Un proceso puede ser considerado como un programa que se está ejecutando
dentro de un programa

sistema final. Cuando los procesos se ejecutan en el mismo sistema final, pueden comunicarse

entre sí con la comunicación interprocesal, utilizando reglas que son

gobernado por el sistema operativo del sistema final. Pero en este libro no somos particularmente

interesados en cómo se comunican los procesos en el mismo host, sino en

cómo se ejecutan los procesos en diferentes hosts (con sistemas operativos potencialmente
diferentes)

comunicarse.

Los procesos en dos sistemas finales diferentes se comunican entre sí intercambiando

mensajes a través de la red de computadoras. Un proceso de envío crea y envía mensajes

en la red; un proceso de recepción recibe estos mensajes y posiblemente

responde enviando mensajes de vuelta. La figura 2.1 ilustra que los procesos de comunicación

entre sí residen en la capa de aplicación de la pila de protocolos de cinco capas.

Procesos de Cliente y Servidor

Una aplicación de red consiste en pares de procesos que envían mensajes a cada uno de ellos.

a través de una red. Por ejemplo, en la aplicación Web un navegador cliente

intercambia mensajes con un proceso de servidor web. En un sistema de intercambio de archivos
P2P,

un archivo se transfiere de un proceso en un par a un proceso en otro par.

Para cada par de procesos de comunicación, normalmente etiquetamos uno de los dos

procesos como el cliente y el otro proceso como el servidor. Con la Web, un

es un proceso cliente y un servidor Web es un proceso servidor. Con archivo P2P

el par que está descargando el archivo está etiquetado como el cliente, y el par

que está subiendo el archivo está etiquetado como el servidor.

Puede que haya observado que en algunas aplicaciones, como en el uso compartido de archivos
P2P, una

puede ser tanto un cliente como un servidor. De hecho, un proceso en un sistema de intercambio
de archivos P2P

puede cargar y descargar archivos. Sin embargo, en el contexto de cualquier sesión de

comunicación entre un par de procesos, todavía podemos etiquetar un proceso

como el cliente y el otro proceso como el servidor. Definimos el cliente y el servidor

de la siguiente manera:

En el contexto de una sesión de comunicación entre un par de procesos, la

que inicia la comunicación (es decir, inicialmente se pone en contacto con el otro

al principio de la sesión) es etiquetado como el cliente. El proceso

que espera a ser contactado para comenzar la sesión es el servidor.

En la Web, un proceso de navegador inicializa el contacto con un proceso de servidor Web;

por lo tanto el proceso del navegador es el cliente y el proceso del servidor web es el servidor. En

Uso compartido de archivos P2P, cuando el par A pide al par B que envíe un archivo específico, el
par A es el cliente.

y Peer B es el servidor en el contexto de esta sesión de comunicación específica. Cuando

no hay confusión, a veces también usamos la terminología "lado del cliente y

en el lado del servidor de una aplicación." Al final de este capítulo, daremos un paso a través de
los siguientes pasos

para el lado del cliente y del servidor de las aplicaciones de red.

La interfase entre el proceso y la red informática

Como se mencionó anteriormente, la mayoría de las aplicaciones consisten en pares de procesos
de comunicación,

con los dos procesos de cada par enviándose mensajes entre sí. Cualquier mensaje

enviado de un proceso a otro debe pasar por la red subyacente. Un proceso

envía mensajes a la red y recibe mensajes de ella a través de un software

una interfaz llamada socket. Consideremos una analogía que nos ayude a entender los procesos

y enchufes. El proceso es análogo al de una casa y su enchufe es análogo al de su puerta.

Cuando un proceso desea enviar un mensaje a otro proceso en otro host, éste

empuja el mensaje por la puerta (enchufe). Este proceso de envío asume que hay

una infraestructura de transporte al otro lado de su puerta que transportará el

a la puerta del proceso de destino. Una vez que el mensaje llega al destino

el mensaje pasa a través de la puerta (zócalo) del proceso de recepción, y

el proceso de recepción actúa entonces sobre el mensaje

La figura 2.3 ilustra la comunicación de sockets entre dos procesos que se comunican.

a través de Internet. (La figura 2.3 asume que el protocolo de transporte subyacente

utilizado por los procesos es el protocolo TCP de Internet. Como se muestra en este

un zócalo es la interfaz entre la capa de aplicación y el transporte.

dentro de un huésped. También se le conoce como la Interfaz de Programación de Aplicaciones.

(API) entre la aplicación y la red, ya que el socket es la programación

con la que se construyen las aplicaciones de red. La aplicación

tiene el control de todo lo que se encuentra en el lado de la capa de aplicación del zócalo, pero

tiene poco control del lado de la capa de transporte de la toma. El único control que el

el desarrollador de la aplicación tiene en el lado de la capa de transporte es (1) la elección del

transporte

y (2) tal vez la capacidad de fijar algunos parámetros de la capa de transporte, tales como

tamaño máximo del tampón y del segmento (a tratar en el capítulo 3). Una vez

el desarrollador de la aplicación elige un protocolo de transporte (si existe una opción disponible),
la aplicación se construye utilizando los servicios de la capa de transporte proporcionados por
dicho protocolo.

Exploraremos las tomas en detalle en la Sección 2.7.

Abordar los procesos

Para enviar correo postal a un destino en particular, el destino debe tener

una dirección. De forma similar, para que un proceso que se ejecuta en un host pueda enviar
paquetes a un servidor

que se ejecuta en otro host, el proceso de recepción necesita tener una dirección.

Para identificar el proceso de recepción, es necesario especificar dos datos:

(1) la dirección del host y (2) un identificador que especifique el proceso de recepción

en el host de destino.

En Internet, el host se identifica por su dirección IP. Discutiremos la propiedad intelectual

se aborda con gran detalle en el Capítulo 4. Por ahora, todo lo que necesitamos saber es que una
IP

es una cantidad de 32 bits en la que podemos pensar que identifica de forma única al host.

Además de conocer la dirección del host al que está destinado un mensaje, la

el proceso de envío también debe identificar el proceso de recepción (más específicamente, el

) que se ejecuta en el host. Esta información es necesaria porque en general

un host podría estar ejecutando muchas aplicaciones de red. Un número de puerto de destino
sirve para este propósito. A las aplicaciones más populares se les ha asignado un puerto específico

números. Por ejemplo, un servidor Web se identifica por el número de puerto 80. Un correo

(utilizando el protocolo SMTP) se identifica por el número de puerto 25. Una lista

de números de puerto conocidos para todos los protocolos estándar de Internet se pueden
encontrar en

http://www.iana.org. Examinaremos los números de puerto en detalle en el Capítulo 3.

2.1.3 Servicios de transporte disponibles para las aplicaciones

Recuerde que un socket es la interfaz entre el proceso de la aplicación y el

de la capa de transporte. La aplicación en el lado del envío empuja los mensajes

a través del enchufe. Al otro lado del zócalo, el protocolo de capa de transporte

tiene la responsabilidad de llevar los mensajes al enchufe del receptor

proceso.

Muchas redes, incluida Internet, proporcionan más de una capa de transporte

protocolo. Cuando desarrollas una aplicación, debes elegir una de las opciones disponibles

de la capa de transporte. ¿Cómo se hace esta elección? Lo más probable es que usted

estudiar los servicios proporcionados por los protocolos disponibles de la capa de transporte y, a
continuación, elegir

el protocolo con los servicios que mejor se adapten a las necesidades de su aplicación. La situación

es similar a elegir entre el transporte por tren o por avión para viajar entre dos

ciudades. Tiene que elegir uno u otro, y cada modo de transporte ofrece diferentes opciones

servicios. (Por ejemplo, el tren ofrece servicio de recogida y entrega en el centro de la ciudad,

mientras que el avión ofrece un tiempo de viaje más corto.

Cuáles son los servicios que un protocolo de capa de transporte puede ofrecer a las aplicaciones

invocándolo? En términos generales, podemos clasificar los posibles servicios en cuatro

dimensiones:

transferencia de datos, rendimiento, tiempo y seguridad confiables.

Transferencia de datos fiable

Como se discutió en el Capítulo 1, los paquetes pueden perderse dentro de una red de
computadoras. Para
ejemplo, un paquete puede desbordar un búfer en un router, o puede ser descartado por un host

o enrutador después de haber corrompido algunos de sus bits. Para muchas aplicaciones, tales
como

correo electrónico, transferencia de archivos, acceso remoto al host, transferencias de

documentos Web, y

aplicaciones financieras: la pérdida de datos puede tener consecuencias devastadoras (en este
último caso, la pérdida de datos puede tener consecuencias devastadoras).

para el banco o para el cliente!). Por lo tanto, para apoyar estas aplicaciones,

hay que hacer algo para garantizar que los datos enviados por un extremo de la aplicación

se entrega correcta y completamente en el otro extremo de la aplicación. Si

un protocolo proporciona un servicio de entrega de datos tan garantizado, se dice que

proporciona

una transferencia de datos fiable. Un servicio importante que puede ofrecer un protocolo de capa
de transporte

es la transferencia de datos fiable de proceso a proceso.

Cuando un protocolo de transporte proporciona este servicio, el proceso de envío puede

simplemente pasar

sus datos en el zócalo y saber con total confianza que los datos

llegan sin errores al proceso de recepción.

Cuando un protocolo de capa de transporte no proporciona una transferencia de datos fiable,

algunos de los protocolos

los datos enviados por el proceso de envío pueden no llegar nunca al proceso de recepción. Este

pueden ser aceptables para aplicaciones tolerantes a pérdidas, en particular las aplicaciones
multimedia

como audio/vídeo conversacional que puede tolerar cierta cantidad de pérdida de datos.

En estas aplicaciones multimedia, la pérdida de datos puede dar lugar a un pequeño fallo en el

audio/video-no es un impedimento crucial.

Rendimiento

En el Capítulo 1 introdujimos el concepto de rendimiento disponible, que, en el contexto

de una sesión de comunicación entre dos procesos a lo largo de una ruta de red, es

la velocidad a la que el proceso de envío puede entregar bits al proceso de recepción.

Porque otras sesiones compartirán el ancho de banda a lo largo de la ruta de red, y

porque estas otras sesiones irán y vendrán, el rendimiento disponible

puede fluctuar con el tiempo. Estas observaciones conducen a otro servicio natural que un

el protocolo de capa de transporte podría proporcionar, a saber, un rendimiento disponible

garantizado

a una tasa especificada. Con este servicio, la aplicación puede solicitar una garantía de

y el protocolo de transporte aseguraría entonces que

el rendimiento disponible es siempre de al menos r bits/seg. Un rendimiento tan garantizado

sería atractivo para muchas aplicaciones. Por ejemplo, si un servicio de telefonía por Internet

codifica la voz a 32 kbps, necesita enviar datos a la red

y que los datos se envíen a la aplicación receptora a este ritmo. Si el transporte

no puede proporcionar este rendimiento, la aplicación necesitaría codificar en

una velocidad más baja (y recibir suficiente caudal para mantener esta velocidad de codificación
más baja) o

puede tener que renunciar, ya que recibir, digamos, la mitad de la producción necesaria es de
poco.

o no usar esta aplicación de telefonía por Internet. Aplicaciones que tienen rendimiento

se dice que son aplicaciones sensibles al ancho de banda. Muchos de los actuales

las aplicaciones multimedia son sensibles al ancho de banda, aunque algunas aplicaciones
multimedia

las aplicaciones pueden utilizar técnicas de codificación adaptativa para codificar voz digitalizada o

a una velocidad que se ajusta a la producción disponible en la actualidad.

Mientras que las aplicaciones sensibles al ancho de banda tienen requisitos específicos de
rendimiento,

las aplicaciones elásticas pueden utilizar tanto o tan poco rendimiento

como resulta que está disponible. El correo electrónico, la transferencia de archivos y las
transferencias Web son

todas las aplicaciones elásticas. Por supuesto, cuanto mayor sea el rendimiento, mejor. Hay

un refrán que dice que uno no puede ser demasiado rico, demasiado delgado, o tener demasiado

rendimiento!

Calendario
Un protocolo de capa de transporte también puede proporcionar garantías de tiempo. Como en el
caso de la producción

garantías, las garantías de tiempo pueden venir en muchas formas. Un ejemplo

puede ser que cada pedacito que el remitente bombea en el zócalo llega al

del receptor no más de 100 mseg. Un servicio de este tipo sería atractivo para

aplicaciones interactivas en tiempo real, como telefonía por Internet y entornos virtuales,

teleconferencias y juegos multijugador, todos los cuales requieren restricciones de tiempo.

en la entrega de datos para que sea efectiva. (Ver Capítulo 7,[Gauthier 1999;

Ramjee 1994]. Los grandes retrasos en la telefonía por Internet, por ejemplo, tienden a dar lugar a

pausas antinaturales en la conversación; en un juego multijugador o interactivo virtual

medio ambiente, un largo retraso entre la toma de una acción y el momento en que se ve la
respuesta de

el entorno (por ejemplo, de otro reproductor al final de una conexión de extremo a extremo)

hace que la aplicación parezca menos realista. Para aplicaciones no en tiempo real, siempre es
preferible un retardo más bajo a un retardo más alto, pero no se impone ninguna restricción
estricta sobre

los retrasos de principio a fin.

Seguridad

Por último, un protocolo de transporte puede proporcionar una aplicación con una o más
garantías

servicios. Por ejemplo, en el host de envío, un protocolo de transporte puede cifrar todos los datos

transmitido por el proceso de envío, y en el host receptor, la capa de transporte

puede descifrar los datos antes de entregarlos al proceso de recepción.

Este servicio proporcionaría confidencialidad entre los dos procesos, incluso si el

los datos se observan de alguna manera entre los procesos de envío y recepción. Un transporte

también puede proporcionar otros servicios de seguridad además de la confidencialidad,

incluyendo la integridad de los datos y la autenticación de los puntos finales, temas que
trataremos en

en el capítulo 8.

2.1.4 Servicios de transporte prestados por Internet

Hasta este punto, hemos estado considerando los servicios de transporte que un ordenador
la red podría proporcionar en general. Ahora vamos a ser más específicos y examinar el

tipo de servicios de transporte prestados por Internet. Internet (y, más en general,

TCP/IP) pone a disposición de las aplicaciones dos protocolos de transporte,

UDP y TCP. Cuando usted (como desarrollador de aplicaciones) crea una nueva red

para Internet, una de las primeras decisiones que tiene que tomar es

si usar UDP o TCP. Cada uno de estos protocolos ofrece un conjunto diferente de servicios

a las aplicaciones de invocación. La figura 2.4 muestra los requisitos de servicio para

algunas aplicaciones seleccionadas.

Servicios TCP

El modelo de servicio TCP incluye un servicio orientado a la conexión y a la fiabilidad de los datos.

servicio de traslado. Cuando una aplicación invoca TCP como su protocolo de transporte, la
directiva

recibe ambos servicios de TCP.

- Servicio orientado a la conexión. TCP tiene el cliente y el servidor de intercambio de transportista

información de control entre sí antes de los mensajes a nivel de aplicación

empiezan a fluir. Este llamado procedimiento de handshaking alerta al cliente y al servidor,

permitiéndoles prepararse para una avalancha de paquetes. Después de la fase de apretón de

manos,

se dice que existe una conexión TCP entre los sockets de los dos procesos. El
es una conexión full-duplex en la que los dos procesos pueden enviar mensajes

entre ellos a través de la conexión al mismo tiempo. Cuando la aplicación finaliza

enviando mensajes, debe romper la conexión. En el Capítulo 3 discutiremos

el servicio orientado a la conexión en detalle y examinar cómo se implementa.

- Servicio de transferencia de datos fiable. Los procesos de comunicación pueden basarse en TCP

para entregar todos los datos enviados sin errores y en el orden correcto. Cuando un lado de

la aplicación pasa un flujo de bytes a un socket, puede contar con TCP para

entregar el mismo flujo de bytes en el zócalo de recepción, sin que falte o

bytes duplicados.

El TCP también incluye un mecanismo de control de la congestión, un servicio para el control

general de la congestión.

el bienestar de Internet y no para el beneficio directo de los comunicadores.

procesos. El mecanismo de control de congestión TCP estrangula un proceso de envío (cliente

o servidor) cuando la red está congestionada entre el emisor y el receptor. Como lo haremos

ver en el Capítulo 3, Control de congestión TCP también intenta limitar cada conexión TCP

a su cuota justa de ancho de banda de red.

Servicios UDP

UDP es un protocolo de transporte ligero y sin complicaciones, que proporciona servicios mínimos.
UDP

es sin conexión, por lo que no hay apretón de manos antes de que los dos procesos comiencen a

comunicarse. UDP proporciona un servicio de transferencia de datos poco fiable, es decir, cuando
un proceso

envía un mensaje a un zócalo UDP, UDP no ofrece ninguna garantía de que el mensaje

llegará al proceso de recepción. Además, los mensajes que llegan al

el proceso de recepción puede llegar fuera de servicio.

UDP no incluye un mecanismo de control de la congestión, por lo que el lado de envío de

UDP puede bombear datos a la capa inferior (la capa de red) en cualquier momento que desee.

(Tenga en cuenta, sin embargo, que el rendimiento real de extremo a extremo puede ser inferior a
esta tasa debido a que

a la limitada capacidad de transmisión de los enlaces intermedios o debido a la congestión).

Servicios no proporcionados por los protocolos de transporte de Internet

Hemos organizado los servicios de protocolo de transporte en cuatro dimensiones: datos fiables

transferencia, rendimiento, tiempo y seguridad. Cuáles de estos servicios son prestados por

TCP y UDP? Ya hemos observado que TCP proporciona datos fiables de extremo a extremo

transferencia. Y también sabemos que TCP puede ser fácilmente mejorado en la capa de
aplicación

con SSL para proporcionar servicios de seguridad. Pero en nuestra breve descripción de TCP y UDP,

se omitió de forma llamativa cualquier mención a los servicios de garantías de rendimiento o de

tiempo

los protocolos de transporte de Internet de hoy en día. ¿Significa esto que el tiempo es un factor
importante

las aplicaciones como la telefonía por Internet no pueden funcionar en la Internet de hoy en día?
El

la respuesta es claramente que Internet no ha estado albergando aplicaciones sensibles al tiempo

para

muchos años. Estas aplicaciones a menudo funcionan bastante bien porque han sido

que permita hacer frente, en la medida de lo posible, a esta falta de garantía. Vamos a

investigue varios de estos trucos de diseño en el Capítulo 7. Sin embargo, el diseño inteligente

tiene sus limitaciones cuando el retardo es excesivo, o cuando el rendimiento de extremo a

extremo es limitado.

En resumen, la Internet de hoy en día a menudo puede proporcionar un servicio satisfactorio a las
empresas que tienen un tiempo limitado.

pero no puede proporcionar ninguna garantía de tiempo o de rendimiento.

En la Figura 2.5 se indican los protocolos de transporte utilizados por algunas de las redes más
populares de Internet.

aplicaciones. Vemos que el correo electrónico, el acceso a terminales remotas, la Web y la

transferencia de archivos

todos usan TCP. Estas aplicaciones han elegido TCP principalmente porque TCP proporciona

transferencia de datos fiable, garantizando que todos los datos llegarán a su destino final.

destino. Porque las aplicaciones de telefonía por Internet (como Skype) pueden a menudo

toleran algunas pérdidas pero requieren una tasa mínima para ser efectivos, los desarrolladores de
Internet

Las aplicaciones de telefonía suelen preferir ejecutar sus aplicaciones sobre UDP,

eludiendo así el mecanismo de control de congestión de TCP y la sobrecarga de paquetes.

Pero debido a que muchos firewalls están configurados para bloquear (la mayoría de los tipos de)
UDP

tráfico, las aplicaciones de telefonía por Internet a menudo están diseñadas para utilizar TCP como
copia de seguridad.

si la comunicación UDP falla.

2.1.5 Protocolos de capa de aplicación

Acabamos de enterarnos de que los procesos de la red se comunican entre sí enviando

mensajes en los zócalos. Pero, ¿cómo están estructurados estos mensajes? ¿Cuáles son los
los significados de los distintos campos de los mensajes? ¿Cuándo los procesos envían los
mensajes?

Estas preguntas nos llevan al reino de los protocolos de capa de aplicación. Un

el protocolo de capa de aplicación define cómo se procesan las aplicaciones, que se ejecutan en
diferentes

los sistemas finales, se pasan mensajes entre ellos. En particular, una capa de aplicación

define el protocolo:

- Los tipos de mensajes intercambiados, por ejemplo, mensajes de solicitud y respuesta.

mensajes

- La sintaxis de las distintas clases de mensaje, como los campos del mensaje y el

cómo se delinean los campos

- La semántica de los campos, es decir, el significado de la información en los campos.

- Reglas para determinar cuándo y cómo un proceso envía mensajes y responde a

mensajes

Algunos protocolos de la capa de aplicación se especifican en los RFCs y, por lo tanto, son públicos

dominio. Por ejemplo, el protocolo de capa de aplicación de la Web, HTTP (el protocolo HyperText

Transferir protocolo[RFC 2616]), está disponible como RFC. Si un desarrollador de navegadores

sigue

las reglas del HTTP RFC, el navegador podrá recuperar páginas Web de

cualquier servidor Web que también haya seguido las reglas del RFC HTTP. Muchos otros

los protocolos de capa de aplicación son de propiedad exclusiva y no están disponibles al público
intencionadamente

dominio. Por ejemplo, Skype utiliza protocolos de capa de aplicación patentados.

Es importante distinguir entre las aplicaciones de red y la capa de aplicación

protocolos. Un protocolo de capa de aplicación es sólo una parte de una aplicación de red

(¡aunque es una parte muy importante de la aplicación desde nuestro punto de vista!). Echemos
un vistazo a

un par de ejemplos. La Web es una aplicación cliente-servidor que permite a los usuarios

Obtener documentos de los servidores Web bajo demanda. La aplicación Web consiste en
muchos componentes, incluyendo un estándar para formatos de documentos (es decir, HTML),
Web

(por ejemplo, Firefox y Microsoft Internet Explorer), servidores web (para

ejemplo, servidores Apache y Microsoft), y un protocolo de capa de aplicación. El

El protocolo de capa de aplicación de Web, HTTP, define el formato y la secuencia de los mensajes

intercambiado entre el navegador y el servidor web. Por lo tanto, HTTP es sólo una pieza (aunque,
un

pieza importante) de la aplicación Web. Como otro ejemplo, una aplicación de correo electrónico
en Internet

también tiene muchos componentes, incluyendo servidores de correo que alojan buzones de
correo de los usuarios;

clientes de correo (como Microsoft Outlook) que permiten a los usuarios leer y crear mensajes.

estándar para definir la estructura de un mensaje de correo electrónico; y protocolos de capa de

aplicación

que definen cómo se pasan los mensajes entre servidores, cómo se pasan los mensajes

entre servidores y clientes de correo, y cómo deben ser los contenidos de las cabeceras de los
mensajes.

interpretada. El principal protocolo de capa de aplicación para el correo electrónico es SMTP

(Protocolo simple de transferencia de correo)[RFC 5321]. Así, la principal capa de aplicación del
correo electrónico

SMTP, el protocolo SMTP, es sólo una pieza (aunque, una pieza importante) de la aplicación de
correo electrónico.

2.1.6 Aplicaciones de red cubiertas en este libro

Se están desarrollando nuevas aplicaciones de dominio público y de propiedad exclusiva de

Internet cada vez que

día En lugar de cubrir un gran número de aplicaciones de Internet en una enciclopedia

hemos optado por centrarnos en un pequeño número de aplicaciones que son a la vez

penetrante e importante. En este capítulo discutimos cinco aplicaciones importantes: el

Aplicaciones Web, transferencia de archivos, correo electrónico, servicio de directorio y P2P.

Nosotros primero

discutir la Web, no sólo porque es una aplicación enormemente popular, sino también porque

porque su protocolo de capa de aplicación, HTTP, es sencillo y fácil de entender.

Después de cubrir la Web, examinamos brevemente el FTP, ya que proporciona un buen servicio
de

en contraste con el HTTP. Luego hablamos del correo electrónico, la primera aplicación asesina de
Internet.

El correo electrónico es más complejo que la Web en el sentido de que no hace uso de ninguno.

sino varios protocolos de capa de aplicación. Después del correo electrónico, cubrimos el DNS, que
proporciona

un servicio de directorio para Internet. La mayoría de los usuarios no interactúan directamente

con DNS;

en su lugar, los usuarios invocan DNS indirectamente a través de otras aplicaciones (incluyendo la
Web,

y correo electrónico). DNS ilustra muy bien cómo una parte de la red central

se puede implementar la funcionalidad (traducción de nombre de red a dirección de red)

en la capa de aplicación en Internet. Finalmente, discutimos en este capítulo

varias aplicaciones P2P, centradas en aplicaciones de compartición de archivos, y distribuidas

servicios de búsqueda. En el Capítulo 7, trataremos las aplicaciones multimedia, entre las que se
incluyen

transmisión de vídeo y voz sobre IP.

2.2 La Web y HTTP

Hasta principios de la década de los 90, Internet era utilizado principalmente por investigadores,
académicos, y

estudiantes universitarios para iniciar sesión en hosts remotos, para transferir archivos de hosts
locales a remotos

y viceversa, para recibir y enviar noticias, y para recibir y enviar mensajes electrónicos.

correo. Aunque estas aplicaciones fueron (y siguen siendo) extremadamente útiles, la

Internet era esencialmente desconocido fuera de las comunidades académicas y de investigación.

Luego, a principios de la década de 1990, una nueva e importante aplicación apareció en escena:
el sistema World

Wide Web[Berners-Lee 1994]. La Web fue la primera aplicación de Internet que captó

el ojo del público en general. Cambió dramáticamente, y continúa cambiando, la forma en que la
gente

interactuar dentro y fuera de sus entornos de trabajo. Elevó a Internet de

una de las muchas redes de datos a la única y única red de datos.

Tal vez lo que más atrae a los usuarios es que la Web funciona bajo demanda.

Los usuarios reciben lo que quieren, cuando lo desean. Esto es diferente a la transmisión
tradicional

la radio y la televisión, que obligan a los usuarios a sintonizar cuando el proveedor de contenidos

hace que el contenido esté disponible. Además de estar disponible bajo demanda, la Web cuenta
con

muchas otras características maravillosas que la gente ama y aprecia. Es enormemente fácil

para que cualquier persona pueda hacer que la información esté disponible en la Web, todo el
mundo puede

convertirse en un editor a un costo extremadamente bajo. Los hipervínculos y los motores de

búsqueda nos ayudan a

navegar a través de un océano de sitios web. Los gráficos estimulan nuestros sentidos.
Formularios,

JavaScript, applets de Java y muchos otros dispositivos nos permiten interactuar con las páginas.

y sitios. Y la Web sirve como plataforma para muchas aplicaciones asesinas emergentes

después de 2003, incluyendo YouTube, Gmail y Facebook.

2.2.1 Descripción general de HTTP

El Protocolo de Transferencia de Hipertexto (HTTP), el protocolo de capa de aplicación de la Web,

está en el corazón de la Web. Se define en[RFC 1945] y[RFC 2616]. HTTP es

implementado en dos programas: un programa cliente y un programa servidor. El cliente

programa y programa del servidor, ejecutándose en diferentes sistemas finales, hablar entre sí

intercambiando mensajes HTTP. HTTP define la estructura de estos mensajes y

cómo el cliente y el servidor intercambian los mensajes. Antes de explicar HTTP en detalle,

deberíamos revisar la terminología de la web.

como un archivo HTML, una imagen JPEG, un applet de Java o un clip de vídeo, es decir

direccionable a través de una única URL. La mayoría de las páginas Web consisten en un archivo
HTML base y

varios objetos de referencia. Por ejemplo, si una página Web contiene texto HTML y cinco

JPEG, entonces la página Web tiene seis objetos: el archivo HTML base más cinco

imágenes. El fichero HTML base hace referencia a los otros objetos de la página con el icono
URLs de los objetos. Cada URL tiene dos componentes: el nombre de host del servidor que

contiene el objeto y el nombre de la ruta del objeto. Por ejemplo, la URL

http://www.someSchool.edu/someDepartment/picture.gif

tiene www.someSchool.edu para un nombre de host y /someDepartment/

picture.gif para un nombre de ruta. Porque los navegadores web (como Internet Explorer

y Firefox) implementan el lado cliente de HTTP, en el contexto de la Web, utilizaremos

las palabras navegador y cliente son intercambiables. Servidores web, que implementan el

lado servidor de HTTP, alojan objetos Web, cada uno direccionable por una URL. Web popular

incluyen Apache y Microsoft Internet Information Server.

HTTP define cómo los clientes Web solicitan páginas Web desde los servidores Web y cómo

servidores transfieren páginas Web a los clientes. Discutimos la interacción entre el cliente y

en detalle más adelante, pero la idea general se ilustra en la Figura 2.6. Cuando un usuario

solicita una página Web (por ejemplo, hace clic en un hipervínculo), el navegador envía HTTP

solicitar mensajes para los objetos de la página al servidor. El servidor recibe el

y responde con mensajes de respuesta HTTP que contienen los objetos.

HTTP utiliza TCP como su protocolo de transporte subyacente (en lugar de ejecutarse en la parte
superior de

UDP). El cliente HTTP inicia primero una conexión TCP con el servidor. Una vez que la conexión

el navegador y el servidor procesan el acceso a TCP a través de su

interfaces de socket. Como se describe en la Sección 2.1, en el lado del cliente la interfaz de socket
es la puerta entre el proceso del cliente y la conexión TCP; en el lado del servidor es la
entre el proceso del servidor y la conexión TCP. El cliente envía HTTP

solicita mensajes en su interfaz de socket y recibe mensajes de respuesta HTTP de

su interfaz de socket. Del mismo modo, el servidor HTTP recibe mensajes de petición de su

y envía mensajes de respuesta a su interfaz de socket. Una vez que el cliente

envía un mensaje a su interfaz de socket, el mensaje está fuera de las manos del cliente y es

"en manos" de TCP. Recordemos de la sección 2.1 que el TCP proporciona una transferencia de
datos fiable

a HTTP. Esto implica que cada mensaje de petición HTTP enviado por un cliente

eventualmente llega intacto al servidor; de manera similar, cada mensaje de respuesta HTTP

enviado por el proceso de servidor llega finalmente intacto al cliente. Aquí vemos a uno de los

grandes ventajas de una arquitectura en capas - HTTP no tiene por qué preocuparse por la pérdida
de datos o el

detalles de cómo TCP se recupera de la pérdida o reordenación de datos dentro de la red. Eso es

el trabajo de TCP y los protocolos en las capas inferiores de la pila de protocolos.

Es importante tener en cuenta que el servidor envía los archivos solicitados a los clientes sin
almacenar

cualquier información estatal sobre el cliente. Si un cliente en particular pide el mismo objeto

dos veces en un período de pocos segundos, el servidor no responde diciendo que simplemente

sirvió el objeto al cliente; en su lugar, el servidor reenvía el objeto, ya que éste ha sido
completamente

olvidó lo que hizo antes. Porque un servidor HTTP no mantiene ninguna información

sobre los clientes, se dice que HTTP es un protocolo sin estado. También observamos que la

La Web utiliza la arquitectura de la aplicación cliente-servidor, como se describe en la Sección 2.1.

AWeb

está siempre activo, con una dirección IP fija, y sirve a las peticiones de los potenciales

millones de navegadores diferentes.

2.2.2 Conexiones no persistentes y persistentes

En muchas aplicaciones de Internet, el cliente y el servidor se comunican entre sí de forma

ampliada.

de tiempo, con el cliente haciendo una serie de peticiones y el servidor respondiendo a las
mismas.
cada una de las peticiones. Dependiendo de la aplicación y de la forma en que se está realizando la
aplicación

utilizadas, la serie de solicitudes puede realizarse una detrás de otra, periódicamente y a intervalos
regulares,

o intermitentemente. Cuando esta interacción cliente-servidor se produce a través de TCP, la

aplicación

el desarrollador necesita tomar una decisión importante - si cada solicitud/respuesta

se envían a través de una conexión TCP separada, o bien todas las peticiones y sus
correspondientes

las respuestas se envían a través de la misma conexión TCP? En el primer enfoque,

se dice que la aplicación utiliza conexiones no persistentes; y en este último caso,

conexiones persistentes. Para obtener una comprensión profunda de este tema de diseño, vamos
a examinar

las ventajas y desventajas de las conexiones persistentes en el contexto de un sistema de

es decir, HTTP, que puede utilizar tanto conexiones no persistentes como conexiones

conexiones persistentes. Aunque HTTP utiliza conexiones persistentes en su modo

predeterminado,

Los clientes y servidores HTTP pueden configurarse para utilizar conexiones no persistentes.

HTTP con conexiones no persistentes

Vamos a repasar los pasos para transferir una página Web de un servidor a un cliente para el

caso de conexiones no persistentes. Supongamos que la página está formada por un HTML base

y 10 imágenes JPEG, y que los 11 objetos residen en el mismo servidor.

Además, suponga que la URL para el archivo HTML base es

http://www.someSchool.edu/someDepartment/home.index

Esto es lo que sucede:

1. El proceso de cliente HTTP inicia una conexión TCP con el servidor

www.someSchool.edu en el número de puerto 80, que es el número de puerto predeterminado

para HTTP. Asociado a la conexión TCP, habrá un socket en el directorio

y un socket en el servidor.

2. El cliente HTTP envía un mensaje de petición HTTP al servidor a través de su socket. El

incluye el nombre de la ruta /someDepartment/home.index.

(Discutiremos los mensajes HTTP con más detalle a continuación.

3. El proceso del servidor HTTP recibe el mensaje de petición a través de su socket, recupera

el objeto /someDepartment/home.index desde su almacenamiento (RAM o

), encapsula el objeto en un mensaje de respuesta HTTP y envía el archivo

mensaje de respuesta al cliente a través de su socket.

4. El proceso del servidor HTTP le indica a TCP que cierre la conexión TCP. (Pero TCP

no termina realmente la conexión hasta que sabe con seguridad que el cliente

ha recibido el mensaje de respuesta intacto.)

5. El cliente HTTP recibe el mensaje de respuesta. La conexión TCP termina.

El mensaje indica que el objeto encapsulado es un archivo HTML. El

el cliente extrae el archivo del mensaje de respuesta, examina el archivo HTML,

y encuentra referencias a los 10 objetos JPEG.

6. Los primeros cuatro pasos se repiten para cada uno de los objetos JPEG referenciados.

A medida que el navegador recibe la página Web, muestra la página al usuario. Dos diferentes

los navegadores pueden interpretar (es decir, mostrar al usuario) una página Web de una forma
algo diferente.

maneras. HTTP no tiene nada que ver con la forma en que un cliente interpreta una página Web.
El

Las especificaciones HTTP ([RFC 1945] y[RFC 2616]) definen únicamente la comunicación

entre el programa HTTP cliente y el programa HTTP servidor.

Los pasos anteriores ilustran el uso de conexiones no persistentes, donde cada TCP

la conexión se cierra después de que el servidor envía el objeto: la conexión no persiste

para otros objetos. Tenga en cuenta que cada conexión TCP transporta exactamente un mensaje
de solicitud

y un mensaje de respuesta. Así, en este ejemplo, cuando un usuario solicita la Web

se generan 11 conexiones TCP.

En los pasos descritos anteriormente, fuimos intencionalmente vagos acerca de si la

obtiene los 10 JPEGs a través de 10 conexiones TCP serie, o bien si alguna de las

Los JPEGs se obtienen a través de conexiones TCP paralelas. De hecho, los usuarios pueden
configurar
navegadores modernos para controlar el grado de paralelismo. En sus modos predeterminados, la
mayoría de los

abren de 5 a 10 conexiones TCP paralelas, y cada una de estas conexiones maneja

una transacción de solicitud-respuesta. Si el usuario lo prefiere, el número máximo delas

conexiones paralelas se pueden ajustar a una, en cuyo caso se establecen las 10 conexiones

en serie. Como veremos en el siguiente capítulo, el uso de conexiones paralelas acorta

el tiempo de respuesta.

Antes de continuar, hagamos un cálculo de la parte de atrás del sobre para estimar los

cantidad de tiempo que transcurre desde que un cliente solicita el archivo HTML base hasta que

el archivo completo es recibido por el cliente. Para ello, definimos el tiempo de ida y vuelta

(RTT), que es el tiempo que tarda un pequeño paquete en viajar del cliente al servidor.

y luego de vuelta al cliente. El RTT incluye retardos de propagación de paquetes, encolado de

paquetes

retrasos en los enrutadores y conmutadores intermedios y en el procesamiento de paquetes

retrasos. (Estos retrasos fueron discutidos en la Sección 1.4.) Ahora considere lo que sucede

cuando un usuario hace clic en un hipervínculo. Como se muestra en la Figura 2.7, esto provoca
que el navegador

para iniciar una conexión TCP entre el navegador y el servidor Web; esto

implica un "apretón de manos de tres vías": el cliente envía un pequeño segmento TCP al

el servidor reconoce y responde con un pequeño segmento TCP, y,

finalmente, el cliente reconoce de nuevo al servidor. Las primeras dos partes de los tres caminos

un apretón de manos con un RTT. Después de completar las dos primeras partes del apretón de
manos,

el cliente envía el mensaje de petición HTTP combinado con la tercera parte del fichero
el triple apretón de manos (el acuse de recibo) en la conexión TCP. Una vez

el mensaje de petición llega al servidor, el servidor envía el archivo HTML al directorio

Conexión TCP. Esta petición/respuesta HTTP consume otro RTT. Así, más o menos,

el tiempo de respuesta total es de dos RTTs más el tiempo de transmisión en el servidor del

Archivo HTML.

HTTP con conexiones persistentes

Las conexiones no persistentes tienen algunas deficiencias. Primero, una nueva conexión

debe establecerse y actualizarse para cada objeto solicitado. Para cada uno de

estas conexiones, se deben asignar los búferes TCP y mantener las variables TCP

tanto en el cliente como en el servidor. Esto puede suponer una carga importante para el servidor
web,

que puede estar sirviendo peticiones de cientos de clientes diferentes simultáneamente.

En segundo lugar, como acabamos de describir, cada objeto sufre un retraso de entrega de dos
RTTs-

un RTT para establecer la conexión TCP y un RTT para solicitar y recibir un

objeto.
En el caso de las conexiones persistentes, el servidor deja abierta la conexión TCP después de

enviando una respuesta. Solicitudes y respuestas subsiguientes entre el mismo cliente y

puede ser enviado a través de la misma conexión. En particular, una página Web completa (en

el ejemplo anterior, el archivo HTML base y las 10 imágenes) pueden enviarse a través de un solo
archivo

conexión TCP persistente. Además, múltiples páginas Web que residen en la misma

puede ser enviado desde el servidor al mismo cliente a través de un único TCP persistente

conexión. Estas peticiones de objetos se pueden hacer espalda con espalda, sin esperar.

para las respuestas a las solicitudes pendientes (canalización). Normalmente, el servidor HTTP
cierra una conexión

cuando no se utiliza durante un tiempo determinado (un intervalo de tiempo de espera

configurable). Cuando

el servidor recibe las peticiones back-to-back, envía los objetos back-to-back. El

El modo predeterminado de HTTP utiliza conexiones persistentes con pipelining.

Cuantitativamente

comparar el rendimiento de las conexiones no persistentes y persistentes en el

problemas con los deberes de los capítulos 2 y 3. También le animamos a que vea a[Heidemann

1997; Nielsen 1997].

2.2.3 Formato de mensaje HTTP

Las especificaciones HTTP[RFC 1945; RFC 2616] incluyen las definiciones de la directiva

Formatos de mensajes HTTP. Hay dos tipos de mensajes HTTP, mensajes de petición

y mensajes de respuesta, los cuales se discuten a continuación.

Mensaje de solicitud HTTP

A continuación le ofrecemos un mensaje de solicitud HTTP típico:

GET /somedir/page.html HTTP/1.1

Anfitrión: www.someschool.edu

Conexión: cerrar

User-agent: Mozilla/5.0

Aceptar-lenguaje: fr

Podemos aprender mucho si miramos de cerca este sencillo mensaje de solicitud. El primero de
todos, vemos que el mensaje está escrito en texto ASCII ordinario, de modo que su ordinario

un ser humano con conocimientos de computación puede leerlo. En segundo lugar, vemos que el
mensaje consiste en

de cinco líneas, cada una seguida de un retorno de carro y un salto de línea. Se sigue la última
línea

mediante un retorno de carro y un salto de línea adicionales. Aunque esta petición en particular

tiene cinco líneas, un mensaje de petición puede tener muchas más líneas o tan pocas como

una línea. La primera línea de un mensaje de petición HTTP se llama línea de petición; la línea

las líneas siguientes se denominan líneas de encabezado. La línea de petición tiene tres campos: la

el campo de método, el campo URL y el campo de versión HTTP. El campo de método puede
tomar

en varios valores diferentes, incluyendo GET, POST, HEAD, PUT, y DELETE.

La gran mayoría de los mensajes de petición HTTP utilizan el método GET. El GET

se utiliza cuando el navegador solicita un objeto, con el objeto solicitado identificado

en el campo URL. En este ejemplo, el navegador solicita el objeto

/somedir/page.html. La versión es autoexplicativa; en este ejemplo, la versión

el navegador implementa la versión HTTP/1.1.

Ahora veamos las líneas de encabezado en el ejemplo. La línea de encabezado Host:

www.someschool.edu especifica el host en el que reside el objeto. Puede que sí

pensar que esta línea de encabezado es innecesaria, ya que hay una conexión TCP en

lugar al anfitrión. Pero, como veremos en la Sección 2.2.5, la información proporcionada por la
directiva

La línea de encabezado del host es necesaria para las cachés de proxy web. Incluyendo la
Conexión:

cerrar la línea de encabezado, el navegador le dice al servidor que no quiere molestarse

con conexiones persistentes; quiere que el servidor cierre la conexión después del envío

el objeto solicitado. La línea User-agent: header especifica el agente de usuario, que

es, el tipo de navegador que está haciendo la petición al servidor. Aquí el agente de usuario es

Mozilla/5.0, un navegador Firefox. Esta línea de encabezado es útil porque el servidor puede

realmente enviar diferentes versiones del mismo objeto a diferentes tipos de agentes de usuario.

(Cada una de las versiones está dirigida por la misma URL.) Finalmente, el Aceptar Idioma:
indica que el usuario prefiere recibir una versión en francés de

el objeto, si tal objeto existe en el servidor; de lo contrario, el servidor debería enviar

su versión por defecto. El encabezado Aceptar-lenguaje: es sólo uno de los muchos contenidos.

de negociación disponibles en HTTP.

Habiendo visto un ejemplo, veamos ahora el formato general de una solicitud

como se muestra en la figura 2.8. Vemos que el formato general sigue de cerca nuestro

ejemplo anterior. Sin embargo, puede que haya notado que después de las líneas de cabecera (y la

(retorno de carro adicional y avance de línea) hay un "organismo de entidad". El organismo de la

entidad es

empty con el método GET, pero se utiliza con el método POST. Un cliente HTTP

a menudo utiliza el método POST cuando el usuario rellena un formulario, por ejemplo, cuando un

el usuario proporciona palabras de búsqueda a un motor de búsqueda. Con un mensaje POST, el

usuario todavía está

solicitar una página Web al servidor, pero los contenidos específicos de la página Web

depende de lo que el usuario haya introducido en los campos del formulario. Si el valor del campo
método

es POST, entonces el cuerpo de la entidad contiene lo que el usuario introdujo en los campos del
formulario.
Seríamos negligentes si no mencionáramos que una petición generada con un formulario

no utiliza necesariamente el método POST. En su lugar, los formularios HTML suelen usar el
comando GET

e incluya los datos introducidos (en los campos del formulario) en la URL solicitada. Para

ejemplo, si un formulario utiliza el método GET, tiene dos campos y las entradas a los dos

son monos y plátanos, entonces la URL tendrá la estructura

www.somesite.com/animalsearch?monkeys&bananas. En tu día a día

Navegando por la web, probablemente has notado URLs extendidas de este tipo.

El método HEAD es similar al método GET. Cuando un servidor recibe una

con el método HEAD, responde con un mensaje HTTP pero omite

el objeto solicitado. Los desarrolladores de aplicaciones suelen utilizar el método HEAD para
depurar.

El método PUT se utiliza a menudo junto con las herramientas de publicación Web. Se

permite a un usuario subir un objeto a una ruta (directorio) específica en una Web específica

servidor. El método PUT también es utilizado por aplicaciones que necesitan subir objetos a

Servidores web. El método DELETE permite a un usuario, o a una aplicación, borrar un archivo

en un servidor web.

Mensaje de respuesta HTTP

A continuación le ofrecemos un mensaje de respuesta HTTP típico. Este mensaje de respuesta

podría

sea la respuesta al mensaje de solicitud de ejemplo que se acaba de discutir.

HTTP/1.1 200 OK

Conexión: cerrar

Fecha: Mar, 09 Ago 2011 15:44:04 GMT

Servidor: Apache/2.2.3 (CentOS)

Última modificación: Mar, 09 Ago 2011 15:11:03 GMT

Contenido-Longitud: 6821

Tipo de contenido: text/html

(datos datos datos datos datos datos datos datos ....)

Echemos un vistazo a este mensaje de respuesta. Consta de tres secciones: una primera

línea de estado, seis líneas de encabezamiento, y luego el cuerpo de la entidad. El organismo de la

entidad es el

carne del mensaje: contiene el propio objeto solicitado (representado por los datos

datos datos datos datos datos datos ....). La línea de estado tiene tres campos: la versión del
protocolo

un código de estado y un mensaje de estado correspondiente. En este ejemplo, el

La línea de estado indica que el servidor está usando HTTP/1.1 y que todo está bien.

(es decir, el servidor ha encontrado y está enviando el objeto solicitado).

Ahora veamos las líneas del encabezado. El servidor utiliza el comando Conexión: cerrar

línea de encabezado para indicar al cliente que va a cerrar la conexión TCP después del envío

el mensaje. La línea Fecha: encabezado indica la hora y la fecha en que el HTTP

La respuesta fue creada y enviada por el servidor. Tenga en cuenta que este no es el momento en
el que el

fue creado o modificado por última vez; es el momento en que el servidor recupera el archivo

desde su sistema de ficheros, inserta el objeto en el mensaje de respuesta y envía

el mensaje de respuesta. La línea Servidor: encabezado indica que el mensaje fue generado

por un servidor Web Apache; es análogo al User-agent: línea de cabecera

en el mensaje de petición HTTP. La línea de encabezado Última modificación: indica el valor de

hora y fecha en que se creó el objeto o se modificó por última vez. La última modificación:

que pronto trataremos con más detalle, es fundamental para el almacenamiento en caché de
objetos, tanto en

el cliente local y en los servidores de caché de red (también conocidos como servidores proxy). El

Content-Length: la línea de encabezado indica el número de bytes en el objeto que se está

visualizando.

enviado. La línea Content-Type: header indica que el objeto en el cuerpo de la entidad es

Texto HTML. (El tipo de objeto se indica oficialmente con el encabezado Content-Type:).

y no por la extensión del archivo.)

Habiendo mirado un ejemplo, examinemos ahora el formato general de un

mensaje de respuesta, que se muestra en la figura 2.9. Este formato general de la respuesta

coincide con el ejemplo anterior de un mensaje de respuesta. Digamos que unos cuantos más
palabras sobre los códigos de estado y sus frases. El código de estado y el código asociado

indican el resultado de la solicitud. Algunos códigos de estado comunes y asociados

las frases incluyen:

- 200 OK: La solicitud fue aceptada y la información es devuelta en la respuesta.

- 301 Movido Permanentemente: El objeto solicitado ha sido movido permanentemente;

la nueva URL se especifica en Ubicación: cabecera del mensaje de respuesta. El

el software del cliente recuperará automáticamente la nueva URL.

- 400 Bad Request: Este es un código de error genérico que indica que la solicitud

no podía ser entendido por el servidor.

- 404 No encontrado: El documento solicitado no existe en este servidor.

- 505 Versión HTTP no soportada: El protocolo HTTP solicitado

no es soportada por el servidor.

¿Cómo le gustaría ver un mensaje de respuesta HTTP real? Esto es muy recomendable

y muy fácil de hacer! Primero Telnet en su servidor Web favorito. Entonces

escriba un mensaje de solicitud de una línea para algún objeto que esté alojado en el servidor.
Para

por ejemplo, si tiene acceso a una línea de comandos, escriba:

telnet cis.poly.edu 80

GET /~ross/ HTTP/1.1

Anfitrión: cis.poly.edu

(Presione el retorno de carro dos veces después de escribir la última línea).

al puerto 80 del host cis.poly.edu y luego envía el mensaje de solicitud HTTP.

Debería ver un mensaje de respuesta que incluya el archivo HTML base de

La página web de la profesora Ross. Si prefieres ver las líneas de mensajes HTTP y no

recibir el objeto mismo, reemplazar GET por HEAD. Por último, sustituir /~cruzar/ por

y ver qué tipo de mensaje de respuesta recibes.

En esta sección hemos discutido una serie de líneas de encabezado que se pueden usar dentro de

Mensajes de solicitud y respuesta HTTP. La especificación HTTP define muchos, muchos más líneas
de encabezado que pueden ser insertadas por navegadores, servidores Web y caché de red

servidores. Hemos cubierto sólo un pequeño número de la totalidad de las líneas de encabezado.
Vamos a

cubrir algunos más a continuación y otro pequeño número cuando hablamos de la red Web

caching en la Sección 2.2.5. Discusión muy comprensible y completa sobre el HTTP

incluyendo sus encabezados y códigos de estado, se encuentra en[Krishnamurthy 2001].

¿Cómo decide un navegador qué líneas de encabezado incluir en un mensaje de solicitud?

¿Cómo decide un servidor Web qué líneas de encabezado incluir en una respuesta?

mensaje? Un navegador generará líneas de cabecera en función del tipo de navegador

y versión (por ejemplo, un navegador HTTP/1.0 no generará ningún encabezado 1.1).

), la configuración de usuario del navegador (por ejemplo, el idioma preferido), y

si el navegador tiene actualmente una versión almacenada en caché, pero posiblemente

desactualizada, de la directiva

objeto. Los servidores web se comportan de manera similar: Existen diferentes productos,
versiones, y

configuraciones, todas las cuales influyen en las líneas de encabezado que se incluyen en la
respuesta

mensajes.

2.2.4 Interacción usuario-servidor: Cookies

Hemos mencionado anteriormente que un servidor HTTP no tiene estado. Esto simplifica el diseño
del servidor

y ha permitido a los ingenieros desarrollar servidores Web de alto rendimiento que pueden
manejar

miles de conexiones TCP simultáneas. Sin embargo, a menudo es deseable que un

Sitio web para identificar a los usuarios, ya sea porque el servidor desea restringir el acceso de los
usuarios o bien

porque quiere servir de contenido en función de la identidad del usuario. Para estos fines,

HTTP utiliza cookies. Las cookies, definidas en[RFC 6265], permiten a los sitios mantener

seguimiento de usuarios. La mayoría de los principales sitios web comerciales utilizan cookies en la
actualidad.

Como se muestra en la Figura 2.10, la tecnología cookie tiene cuatro componentes: (1) una cookie

en el mensaje de respuesta HTTP; (2) una línea de encabezado de cookie en el mensaje HTTP

(3) un archivo cookie guardado en el sistema final del usuario y administrado por el

(4) una base de datos back-end en el sitio Web. Usando la Figura 2.10, vamos a

repasar un ejemplo de cómo funcionan las cookies. Suponga que Susan, que siempre

accede a la Web usando Internet Explorer desde su ordenador personal, contacta con
Amazon.com

por primera vez. Supongamos que en el pasado ya ha visitado el sitio de eBay.

Cuando la solicitud entra en el servidor web de Amazon, el servidor crea un archivo único

número de identificación y crea una entrada en su base de datos back-end que está indexada

por el número de identificación. El servidor web de Amazon entonces responde a la pregunta de

Susan.

incluyendo en la respuesta HTTP un encabezado Set-cookie: que contiene

el número de identificación. Por ejemplo, la línea de encabezado podría ser:

Un set-cookie: 1678

Cuando el navegador de Susan recibe el mensaje de respuesta HTTP, ve el Setcookie:

en la cabecera. El navegador entonces agrega una línea al archivo de cookie especial que él

se las arregla. Esta línea incluye el nombre de host del servidor y el número de identificación.

en el encabezado Set-cookie: header. Tenga en cuenta que el archivo cookie ya tiene una entrada
para
eBay, ya que Susan ha visitado ese sitio en el pasado. Mientras Susan sigue navegando por el

Amazon, cada vez que solicita una página Web, su navegador consulta su cookie

, extrae su número de identificación para este sitio, y pone una línea de encabezado de cookie

que incluye el número de identificación en la solicitud HTTP. Específicamente, cada uno de los

sus peticiones HTTP al servidor de Amazon incluyen la línea de encabezado:

Cookie: 1678

De esta manera, el servidor de Amazon es capaz de rastrear la actividad de Susan en el Amazon

sitio. Aunque el sitio web de Amazon no conoce necesariamente el nombre de Susan, sí lo hace.

sabe exactamente qué páginas visitó el usuario 1678, en qué orden y a qué horas!

Amazon utiliza cookies para proporcionar su servicio de carrito de compras.

lista de todas las compras previstas de Susan, para que ella pueda pagarlas colectivamente en

al final de la sesión.

Si Susan regresa al sitio de Amazon, digamos, una semana después, su navegador continuará

para poner la línea de encabezado Cookie: 1678 en los mensajes de solicitud. Amazon también
recomienda

productos a Susan basados en las páginas web que ha visitado en Amazon en el

pasado. Si Susan también se registra con Amazon, proporcionando su nombre completo, envíe un
correo electrónico a

dirección, dirección postal e información de la tarjeta de crédito-Amazon puede incluir lo siguiente

información en su base de datos, asociando así el nombre de Susan con su identificación

(y todas las páginas que ha visitado en el sitio en el pasado!). Así es como

Amazon y otros sitios de comercio electrónico ofrecen "compras con un solo clic", cuando Susan

decide comprar un artículo durante una visita posterior, no necesita volver a entrar

su nombre, número de tarjeta de crédito o dirección.

De esta discusión vemos que las cookies pueden ser utilizadas para identificar a un usuario. La
primera

cuando un usuario visita un sitio, el usuario puede proporcionar una identificación de usuario
(posiblemente su

nombre). Durante las siguientes sesiones, el navegador pasa un encabezado de cookie a la sección

identificando así al usuario con el servidor. De este modo, las cookies pueden utilizarse para crear

una capa de sesión de usuario sobre HTTP sin estado. Por ejemplo, cuando un usuario inicia sesión
en un

Aplicación de correo electrónico basada en Web (como Hotmail), el navegador envía información
de cookies

al servidor, permitiendo al servidor identificar al usuario a lo largo de la sesión del usuario

con la solicitud.

Aunque las cookies a menudo simplifican la experiencia de compra en Internet para el usuario,

son polémicos porque también pueden ser considerados como una invasión de la privacidad.

Como acabamos de ver, utilizando una combinación de cookies e información de cuenta

proporcionada por el usuario,

un sitio Web puede aprender mucho sobre un usuario y potencialmente vender esta información a
un

terceros. Cookie Central[Cookie Central 2012] incluye amplia información

en la controversia de las galletas.

2.2.5 Caché web

La caché de una Web, también llamada servidor proxy, es una entidad de red que satisface las
necesidades de HTTP.

en nombre de un servidor Web de origen. La caché Web tiene su propio almacenamiento en disco
y guarda copias de los objetos recientemente solicitados en este almacenamiento. Como se
muestra en la Figura 2.11, un

el navegador del usuario puede configurarse para que todas las peticiones HTTP del usuario sean
dirigidas primero

a la caché web. Una vez que se ha configurado un navegador, cada solicitud de navegador para un
objeto es

primero se dirigió a la caché de la Web. Como ejemplo, supongamos que un navegador está
solicitando el comando

objeto http://www.someschool.edu/campus.gif. Esto es lo que sucede:

1. El navegador establece una conexión TCP con la caché Web y envía un archivo

Petición HTTP del objeto a la caché Web.

2. La caché Web comprueba si tiene una copia del objeto almacenado localmente. Si es

la caché Web devuelve el objeto dentro de un mensaje de respuesta HTTP a

el navegador del cliente.

3. Si la caché Web no tiene el objeto, la caché Web abre una conexión TCP

al servidor de origen, es decir, a www.someschool.edu. La caché de la Web

luego envía una petición HTTP para el objeto a la conexión TCP de caché al servidor.

Después de recibir esta petición, el servidor de origen envía el objeto dentro de

una respuesta HTTP a la caché Web.

4. Cuando la caché Web recibe el objeto, almacena una copia en su almacenamiento local y
envía una copia, dentro de un mensaje de respuesta HTTP, al navegador del cliente (a través de la
directiva

conexión TCP existente entre el navegador del cliente y la caché web).

Tenga en cuenta que una caché es un servidor y un cliente al mismo tiempo. Cuando recibe

y envía respuestas a un navegador, es un servidor. Cuando envía peticiones

y recibe respuestas de un servidor de origen, es un cliente.

Normalmente, un ISP compra e instala una caché Web. Por ejemplo, una universidad

podría instalar una caché en su red de campus y configurar todo el campus

para apuntar a la caché. O un ISP residencial importante (como AOL) podría

instalar una o más cachés en su red y preconfigurar sus navegadores enviados para que

apuntan a las cachés instaladas.

El almacenamiento en caché en la Web se ha implementado en Internet por dos razones. En

primer lugar, una web

puede reducir sustancialmente el tiempo de respuesta de la solicitud de un cliente, en particular si

se utiliza el comando

el ancho de banda de cuello de botella entre el cliente y el servidor de origen es mucho menor que
el cuello de botella

entre el cliente y la caché. Si hay una conexión de alta velocidad

entre el cliente y la caché, como ocurre a menudo, y si la caché tiene la información solicitada

entonces la caché podrá entregar el objeto rápidamente al cliente. Segundo, como

pronto ilustraremos con un ejemplo, las cachés Web pueden reducir sustancialmente el tráfico en

el enlace de acceso de una institución a Internet. Al reducir el tráfico, la institución (por ejemplo,
una empresa o una universidad) no tiene que actualizar el ancho de banda con la misma rapidez,
por lo tanto

reducción de costes. Además, las cachés Web pueden reducir sustancialmente el tráfico Web en el
directorio

Internet en su conjunto, mejorando así el rendimiento de todas las aplicaciones.

Para obtener una comprensión más profunda de los beneficios de las cachés, consideremos un
ejemplo

en el contexto de la figura 2.12. Esta figura muestra dos redes - la institucional

y el resto de la Internet pública. La red institucional es una red de alta velocidad

LAN. Un enrutador en la red institucional y un enrutador en Internet están conectados.

por un enlace de 15 Mbps. Los servidores de origen están conectados a Internet pero se
encuentran todos

en todo el mundo. Supongamos que el tamaño medio del objeto es de 1 Mbits y que el tamaño
medio del objeto es de 1 Mbits.

la tasa de peticiones de los navegadores de la institución a los servidores de origen es de 15

peticiones por

segundo. Supongamos que los mensajes de petición HTTP son insignificantemente pequeños y por
lo tanto crean

no hay tráfico en las redes o en el enlace de acceso (de un router institucional a Internet)

router). También supongamos que la cantidad de tiempo que toma desde que el enrutador en el

El lado de Internet del enlace de acceso en la Figura 2.12 reenvía una petición HTTP (dentro de un
archivo

IP datagrama) hasta que recibe la respuesta (típicamente dentro de muchos datagramas IP) es

dos segundos de media. Informalmente, nos referimos a este último retraso como el "retraso de
Internet".

El tiempo de respuesta total, es decir, el tiempo que tarda el navegador en solicitar un objeto.

hasta que reciba el objeto - es la suma del retardo de la LAN, el retardo de acceso (es decir,

el retardo entre los dos routers), y el retardo de Internet. Hagamos ahora un análisis muy crudo.

para estimar este retraso. La intensidad de tráfico en la LAN (véase el apartado 1.4.2) es la
siguiente

(15 peticiones/seg) (1 Mbits/petición)/(100 Mbps) = 0,15

considerando que la intensidad del tráfico en el enlace de acceso (del enrutador de Internet a la
institución)
) es

(15 peticiones/seg) (1 Mbits/petición)/(15 Mbps) = 1

Una intensidad de tráfico de 0,15 en una LAN suele dar como resultado, como máximo, decenas
de milisegundos.

de retraso; por lo tanto, podemos descuidar el retraso de la LAN. Sin embargo, como se discutió en

Sección 1.4.2, cuando la intensidad del tráfico se aproxima a 1 (como en el caso del enlace de
acceso)

en la Figura 2.12), el retardo en un enlace se hace muy grande y crece sin límites.

Así pues, el tiempo medio de respuesta para satisfacer las solicitudes va a ser del orden de

minutos, si no más, lo que es inaceptable para los usuarios de la institución. Claramente algo

debe hacerse.

Una posible solución es aumentar la velocidad de acceso de 15 Mbps a, digamos, 100

Mbps. Esto reducirá la intensidad del tráfico en el enlace de acceso a 0,15, lo que significa que

a retrasos insignificantes entre los dos routers. En este caso, la respuesta total

tiempo será de aproximadamente dos segundos, es decir, el retraso de Internet. Pero esta
solución también

significa que la institución debe actualizar su enlace de acceso de 15 Mbps a 100 Mbps, lo que
significa que la institución debe actualizar su enlace de acceso de 15 Mbps a 100 Mbps.

una proposición costosa.

Ahora considere la solución alternativa de no actualizar el enlace de acceso pero

en lugar de instalar una caché Web en la red institucional. Esta solución se ilustra

en la figura 2.13. Tasas de aciertos: la fracción de las solicitudes que son satisfechas por un

de 0,2 a 0,7 en la práctica. Para fines ilustrativos, vamos a

supongamos que la caché proporciona una tasa de aciertos de 0,4 para esta institución. Porque el

y la caché están conectados a la misma LAN de alta velocidad, el 40 por ciento de los clientes

las peticiones serán satisfechas casi inmediatamente, digamos, dentro de 10 milisegundos, por el

caché. Sin embargo, el 60 por ciento restante de las solicitudes aún deben ser satisfechas.

por los servidores de origen. Pero con sólo el 60 por ciento de los objetos solicitados pasando

a través del enlace de acceso, la intensidad del tráfico en el enlace de acceso se reduce de 1,0 a
1,0.
0.6. Normalmente, una intensidad de tráfico inferior a 0,8 corresponde a un pequeño retardo,
digamos, de decenas

de milisegundos, en un enlace de 15 Mbps. Este retardo es insignificante en comparación con el de

dos segundos

Retraso de Internet. Teniendo en cuenta estas consideraciones, el retraso medio es, por lo tanto,
de

0,4 (0,01 segundos) + 0,6 (2,01 segundos)

que es ligeramente superior a 1,2 segundos. Por lo tanto, esta segunda solución proporciona un

un tiempo de respuesta aún menor que el de la primera solución, y no requiere que la institución

para actualizar su enlace a Internet. La institución, por supuesto, tiene que comprar

aplicación informática

que se ejecuta en PCs de bajo costo.

A través del uso de Redes de Distribución de Contenido (CDNs), las cachés Web son

que cada vez desempeñan un papel más importante en Internet. Una empresa de CDN instala
muchos
distribuidas geográficamente a través de Internet, localizando así gran parte de

el tráfico. Existen CDNs compartidas (como Akamai y Limelight) y CDNs dedicadas.

(como Google y Microsoft). Discutiremos las CDNs con más detalle en el Capítulo 7.

2.2.6 El GET condicional

Aunque el almacenamiento en caché puede reducir los tiempos de respuesta percibidos por el
usuario, introduce un nuevo problema.

la copia de un objeto que reside en la caché puede estar obsoleta. En otras palabras, el

el objeto alojado en el servidor web puede haber sido modificado desde que la copia fue
almacenada en caché

al cliente. Afortunadamente, HTTP tiene un mecanismo que permite que una caché verifique que
su

los objetos están actualizados. Este mecanismo se llama el GET condicional. Un HTTP es un
mensaje GET condicional si (1) el mensaje de petición

usa el método GET y (2) el mensaje de petición incluye un mensaje If-Modified-

Desde: línea de cabecera.

Para ilustrar cómo funciona el GET condicional, repasemos un ejemplo.

En primer lugar, en nombre de un navegador solicitante, una caché proxy envía un mensaje de
solicitud

a un servidor web:

GET /fruit/kiwi.gif HTTP/1.1

Anfitrión: www.exotiquecuisine.com

En segundo lugar, el servidor web envía un mensaje de respuesta con el objeto solicitado a la
aplicación

caché:

HTTP/1.1 200 OK

Fecha: Sábado, 8 Oct 2011 15:39:29

Servidor: Apache/1.3.0 (Unix)

Última modificación: Mie, 7 Sep 2011 09:23:24

Tipo de contenido: imagen/gif

(datos datos datos datos datos datos datos datos ....)

La caché reenvía el objeto al navegador que lo solicita, pero también lo almacena en caché.
localmente. Es importante destacar que la caché también almacena la fecha de la última
modificación junto con el archivo

objeto. Tercero, una semana más tarde, otro navegador solicita el mismo objeto mediante el
comando

y el objeto sigue en la caché. Ya que este objeto puede haber sido modificado

en el servidor Web en la última semana, la caché realiza una comprobación actualizada emitiendo

un GET condicional. Específicamente, el caché envía:

GET /fruit/kiwi.gif HTTP/1.1

Anfitrión: www.exotiquecuisine.com

Si-modificado-desde: Wed, 7 Sep 2011 09:23:24

Note que el valor de la línea de encabezado If-modified-since: es exactamente igual a

el valor de la línea de encabezado Última modificación: que fue enviada por el servidor

hace una semana. Este GET condicional le dice al servidor que envíe el objeto sólo si el objeto

se ha modificado desde la fecha especificada. Supongamos que el objeto no ha sido

modificado desde 7 sep 2011 09:23:24. Entonces, en cuarto lugar, el servidor web envía una
respuesta

a la caché:

HTTP/1.1 304 No modificado

Fecha: Sábado, 15 Oct 2011 15:39:29

Servidor: Apache/1.3.0 (Unix)

(cuerpo vacío de la entidad)

Vemos que en respuesta al GET condicional, el servidor Web todavía envía una respuesta

pero no incluye el objeto solicitado en el mensaje de respuesta. Incluyendo

el objeto solicitado sólo desperdiciaría ancho de banda y aumentaría la respuesta percibida por el
usuario

tiempo, especialmente si el objeto es grande. Tenga en cuenta que este último mensaje de
respuesta tiene 304

No modificado en la línea de estado, que indica a la caché que puede seguir adelante.

su (de la caché del proxy) copia en caché del objeto al navegador solicitante.

Esto termina nuestra discusión sobre HTTP, el primer protocolo de Internet (una capa de
aplicación
) que hemos estudiado en detalle. Hemos visto el formato de los mensajes HTTP y

las acciones tomadas por el cliente y el servidor Web a medida que se envían y reciben estos
mensajes.

También hemos estudiado un poco de la infraestructura de aplicaciones de la Web, incluyendo

cachés, cookies,

y bases de datos back-end, todas ellas ligadas de alguna manera al protocolo HTTP.