WWW Y HTTP

1) World Wide Web, WWW

WWW es un sistema de distribucin de informacin basado en hipertexto.
Con un navegador web, un usuario visualiza sitios compuestos de pginas web que
pueden contener texto, imgenes, vdeos u otros contenidos multimedia y navega a travs
de ella usando hiperenlaces.
! La base del hipertexto permite relacionar documentos de manera que es posible
moverse de uno a otro de forma directa.

Arquitectura y componentes
El primer navegador que hizo competencia a Explorer fue Netscape. A finales de los 90
hubo una especie de guerra comercial entre Netscape y Explorer que tuvo como resultado
la quiebra de Netscape. Netscape lleg a ser un puntero navegador por encima incluso
que Explorer. Tuvo ideas que no fueron buenas, extensiones que solo funcionaran con
Netscape ( los desarrolladores tuvieron que desarrollar webs para los dos navegadores ).
Windows lo que hizo fue instalar Explorer en sus SO para que la gente no tuviera que
recurrir a Netscape, aunque posteriormente fueran denunciados por posicin dominante.

Finalmente acab en la quiebra, liberando su cdigo y creando la fundacin Mozilla que

dedic parte de sus esfuerzos en crear un motor desde cero. Hered personal y tcnicas,
pero ni el motor ni la base del navegador tiene nada que ver con Netscape

El sistema se basa en un modelo de cliente-servidor.

Los clientes solicitan las pginas web a los servidores y
estos devuelven el contenido. Dentro de las respuestas
intervienen diversos aspectos, como el lenguaje de
hipertexto, HTML, el protocolo de transferencia, HTTP, el
identificador de recurso nico URL as como toda la
parte web hardware ( servidores y equipos de red ).

HTML: Hypertext Markup Languaje. Especifica el lenguaje de etiquetas que se emplea en

la elaboracin de pginas web.
HTTP: Hypertext Transfer Protocol: Protocolo de aplicacin, que funciona sobre TCP,
usado para realizar las transacciones en la WWW.
URI: Uniform Resources Identifiers. Es una cadena de caracteres que identifica
inequvocamente un recurso.

En las peticiones HTTP el navegador adjunta informacin sobre el

navegador lo que permite al servidor adaptar sus contenidos en
funcin del navegador.

Web server
Es un apartado de poca discusin. El ms usado desde los inicios
ha sido y sigue siendo Apache, aunque tambin se suele usar
Internet Information Server (IIS) de Microsoft.
Servidor proxy
Es un servidor que acta como intermediario para las peticiones de los clientes buscando
los recursos con otros servidores. Lo que se hace es instalar un proxy para que las
peticiones se realicen al proxy y este sea el que se encargue de realizar las peticiones
con el servidor.

Razones del proxy:

1) Por temas de seguridad: Para aislar la parte externa de la interna de la red, y poder
as camuflar la direccin ip. A las empresas no les hace gracia ya que los ingresos de
publicidad se ven reducidos porque todas las peticiones se realizan desde la misma IP.
2) Disponen de una cach que mantiene copias de recursos y los sirve cuando un
Cliente los solicita, reduciendo tiempos de servicio y ahorrando ancho de banda.

Limitaciones:
! Por ejemplo me conecto a una web que va cambiando de forma dinmica. Si el
proxy me devuelve al informacin y no consulta, la informacin devuelta esta desfasada.

2) Uniform resource Identifiers, URI

El primer problema es como llamo al recurso.
URI es cualquier cadena de caracteres que inequvocamente identifica un recurso y son
esenciales para implementar el hipertexto ya que permite realizar los enlaces de los
recursos de la www.

Se dividen en dos tipos, tal y como describen un recurso:

! URL: Uniform Resource Locator. Identifica el recurso como una combinacin del
mecanismo de acceso y localizacin del resource
! ! http://www........
! URN: Uniform Resource Name. Identifica el recurso con un nombre nico sin
aportar informacin sobre la situacin del mismo Por ejemplo, libro con ISBN:....
! ! urn:isbn:44..........093

Sintaxis URL
Los URL estn formado sor dos componentes: localizacin del recurso y mtodo para
acceder a l. Por tanto la sintaxis general contendra dos elementos:
<esquema>: Especifica como acceder al recurso.Normalmente es el protocolo pero no
siempre (Ejemplo file://..... )
El resto del URL vara e nfuncin del esquema. Al leer el URL el equema indicar como ha
de interpretarse el resto de la URL.
<scheme>://<user>:<pass>@<host>:<port>/<url-path>?<query>#<fragment>

Ejemplo para el caso de HTTP

PROTOCOLO HTTP
Hypertext Transfer Protocol o HTTP: Trabaja sobre TCP que se utiliza para realizar
transacciones en la WWW. Est orientado a transacciones y sigue el esquema peticin-
respuesta entre un cliente y un servidor. El problema es sin estado, es decir cuando
realice la transaccin me olvide de ella, no guardo nada sobre ella.

Protocolo sin estado: Me conecto con una pgina web, por ejemplo una tienda, y realizo una compra. Confirmo
comprar con una orden POST. El servidor ejecutar un programa para devolver una pgina dinmica con un flag que
indique que se ha comprado el recurso. Repetimos el mismo proceso solicitando otro recurso/transaccin por ejemplo la
pgina de ayuda, y l me la devuelve, pero esta ltima no lleva ninguna informacin sobre el uno de la compra anterior.
Para solucionarlo inventaron una cosa llamada Cookies

Versiones
HTTP/0.9: Est obsoleta y hoy en da no se puede utilizar.

HTTP/1.0: Apareci en 1996. Diseo casi todo lo que se utiliza en el protocolo que usamos
hoy en da. Explic que podamos usar varios ordenes para comunicarnos con el servidor
(metodos ) y deDini como poder intercambiar algo que no fuera hipertexto porque adapt el
formato MIME del correo electrnico.
No usaron keep-alive porque por aquel entonces las pginas webs eran texto plano, y requeran
de pocas conexiones para obtener la web completa.

HTTP/1.1: Como novedades permiti que la conexin no se cerrase keep-alive. El protocolo

adems dispone de un comando para cerrar la conexin. Se permita la existencia de
servidores asociados a un mismo servidor IP y por ltimo disponan de comandos para
descargarse parte del recurso en lugar del recurso entero.

Modo de operacin
- HTTP trabaja sobre TCP en el puerto 80 y el proceso se realiza en dos pasos, la peticin
del cliente, donde el cliente enva un mensaje formateado de acuerdo al protocolo HTTP
donde se especiDica el recurso deseado, y por otro lado la respuesta del servidor, donde
se indica el resultado de la peticin.

La conexin persistente permite otra mejora: pipelining el cliente puede realizar multiples
peticiones sin esperar respueta.
Mensajes
Cliente y servidor intercambian mensajes, y el formato, basado en texto, es similar al
empleado en SMTP.
Un mensaje genrico tiene los siguiente componentes:
- Linea de Inicio: Indica la naturaleza del mensaje. En Peticiones lleva el mtodo y el URI
del objeto requerido. En las respuestas los cdigos de estado.
- Cabeceras del mensaje: Incluyen detalles que se quieren proporcionr. Existen decenas
de cabeceras deDinidas.
- Linea vaca, para separar la cabecera del cuerpo.
- Cuerpo del mensaje. Slo es necesario en ciertos tipos de mensajes. Puede llevar
detalles de un error en una respuesta o ms comn transportar un recurso ( denominado
en HTTP entidad)
- Cola del mensaje. Similar a las cabeceras utilizando cuando se realiza chunking o
cabeceras de cola.

Formato del mensaje de pe4cin

Connection: close, indica que cuando se descargue el recurso se cierre la conexin.

Mtodos
GET: Solicita que le entregue el recurso especiDicado en el URL. Si el servidor puede encontrar
el recursos se lo enviar en un mensaje de respuesta. Si existe algn problema le enviar un
mensaje con un cdigo de error. En funcin de algunas cabeceras puede darse un GET
condicional ( solo se enva el recurso si se cumplen unos ciertos criterios ) o un GET parcial
( solo se desea parte del recurso especiDicado ).

El GET condicional se basa o bien en las etiquetas, o bien con una fecha grabada en los recursos
obtenidos, y que tambin est estampada en los recursos del servidor

POST: Permite a un cliente enviar una entidad que contenga datos para que sean
procesados por el servidor. Es utilizado normalmente para enviar informacin como
formularios.

HEAD: Es idntico al GET, pero le indica al Servidor que no enve el cuerpo del mensaje.
El servidor responde nicamente con las cadenas que acompaaran a una respuesta a
un comando GET, incluidas las de entidad. El mtodo se utiliza para comprobar la
existencia, estado o tamao de un archivo.
OPTIONS: Permite que un cliente solicite informacin sobre las opciones de
comunicacin. si se escribe URL se solicita informacin del mismo. Si el campo incluye *
se solicita informacin del servidor.
TRACE: Este mtodo solicita al servidor que enve de vuelta un mensaje de respuesta, en
la seccin del cuerpo de entidad, el mensaje de solicitud. Se utiliza con fines de
comprobacin y diagnstico
PUT: Sube un recurso determinado al servidor. ( No suele estar habilitado ).
DELETE: Solicita eliminar un recuso en el servidor. ( No suele estar habilitado ).

Formato del mensaje de respuesta

Cdigos de estado
Campos cabecera general
Despus de chunking, se aaden las cabeceras que van al Dinal ( trailer ). Cuando el cliente
recibe el tamao ( Length ), cuenta y ha llegado al Dinal, entiende que ha terminado de recibir
el mensaje. El problema viene con la generacin de webs dinmicas, de las cuales se
desconoce el campo de longitud, luego la nica forma de que el receptor sepa cuando se acaba
es mediante el troceado ( chunking ). Se empiezan a enviar trozos con su tamao, hasta que
llegue un trozo de tamao 0 que indicar que la entidad se habr acabado. Cuando esto se
hace, se pueden aadir cabeceras al Dinal de la entidad, como por ejemplo la longitud de la
entidad, que esta vez ya se conoce. Para que el protocolo sepa que cabeceras va a tener al Dinal
del mensaje, se especiDica en la cabecera inicial mediante trailer

Campos de la cabecera de pe4cin