Está en la página 1de 37

LA WEB Y HTTP

WEB Y HTTP
EMPEZ A PRINCIPIOS DE 1990, EN SUIZA EN EL CENTRO DE INVESTIGACIN CERN (CENTRO DE ESTUDIOS PARA LA INVESTIGACIN NUCLEAR) Y LA IDEA FUE DE TIM BERNERS-LEE.
EL INTERNET ERA SOLO UTILIZADO POR INVESTIGADORES PROFESORES Y ESTUDIANTES ENVIAR Y RECIBIR ARCHIVOS Y MENSAJES DE UN HOST A OTRO . PARA

EL INTERNET ERA PRCTICAMENTE DESCONOCIDA FUERA DE LAS COMUNIDADES ACADMICAS FUE ENTONCES CUANDO UNA NUEVA APLICACIN IMPORTANTE PARECI WORD WIDE WEB ,

WEB Y HTTP

PGINA WEB CONSISTE DE OBJECTOS OBJECTOS PUEDEN SER ARCHIVO HTML, IMAGEN JPEG, APPLETJAVA, ARCHIVO AUDIO, PGINA WEB CONSISTE DE ARCHIVO BASE HTML QUE INCLUYE OBJECTOS
REFERENCIADOS

URL EJEMPLO URL: www.someschool.edu/someDept/pic.gif

nombre host

nombre ruta

WEB Y HTTP

HTTP DEFINE COMO LOS CLIENTES WEB SOLICITAN PAGINAS WEB A LOS
SERVIDORES WEB Y COMO ESTOS SERVIDORES TRANSFIEREN ESAS PAGINAS WEB A LOS CLIENTES.

WEB Y HTTP
HTTP: PROTOCOLO DE
TRANSFERENCIA DE HIPERTEXTO
PC ejecutando Explorer

EL PROTOCOLO DE CAPA DE APLICACIN DE LA WEB MODEL CLIENTE/SERVIDOR


CLIENTE: BROWSER SERVIDOR: SERVIDOR

Server ejecutando Servidor Web Apache

WEB

Mac ejecutando Navigator

WEB Y HTTP
USA TCP:
TCP CONECCION (CREA SOCKET) AL SERVIDOR, PUERTO 80
CLIENTE INICIA SERVIDOR ACEPTA CONECCIONTCP DEL CLIENTE MENSAJES

HTTP ES SIN ESTADO

SERVIDOR NO MANTIENE

INFORMACION SOLICITUDES
PASADAS DE CLIENTES

HTTP WEB HTTP) Y (SERVIDOR HTTP )

PC ejecutando Explorer

INTERCAMBIADOS ENTRE NAVEGADOR (CLIENTE SERVIDOR

CONECCION TCP SE CIERRA


Mac ejecutando Navigator

Server ejecutando Servidor Web Apache

CONEXIONES PERSISTENTES Y NO PERSISTENTES


EL
PROTOCOLO

PERSISTENTES

. COMO EJEMPLO :

HTTP

PUEDE UTILIZAR CONEXIONES PERSISTENTES Y NO

SI PEDIMOS UNA PGINA WEB A UN SERVIDOR Y LA PAGINA CONSTA DE UN HTML Y 5 OBJETOS,

CON EN UNA CONEXIN NO PERSISTENTE SOLO SE HAR UNA CONEXIN TCP.

MIENTRAS QUE EN UNA CONEXIN CONEXIONES PERSISTENTE SE UTILIZARN MLTIPLES

TCP, UNA POR CADA OBJETO SOLICITADO.

HTTP NO PERSISTENTE
WWW.GOOGLE.COM/IMAGENES/CAT.JPG

(contiene texto, referencias a 10 Imgenes jpeg)

1A. CLIENTE HTTP INICIA CONEXION

TCP AL SERVIDOR HTTP (PROCESO) EN WWW.GOOGLE.COM EN PUERTO 80

1b. servidor HTTP en host

2. cliente HTTP enva mensaje


peticin HTTP (URL) en
socket conexion TCP. Mensaje indica que quiere el objecto imagenes/cat.jpg

www.google.com espera por conexionTCP en puerto 80. accepta conexion, notificando al cliente.

3. servidor HTTP recibe


mensaje respuesta

mensaje peticin, construye conteniendo el objecto solitado, y enva mensaje a su socket

tiempo

HTTP NO PERSISTENTE
4. servidor HTTP cierra 5. CLIENTE HTTP RECIBE MENSAJE
RESPUESTA CONTENIENDO ARCHIVO HTML. ANALIZA ARCHIVO HTML,

conexion TCP.

tiempo6. Pasos 1-5 repetidos para cada


uno de 10 objetos jpeg

ENCUENTRA 10 OBJETOS REFERENCIADOS JPEG.

HTTP NO-PERSISTENT: TIEMPO DE RESPUESTA


DEFINICIN DE RTT: TIEMPO PARA
UN PAQUETE VIAJAR DESDE CLIENTE A SERVIDOR Y VOLVER.

TIEMPO DE RESPUESTA: UN RTT PARA INICIAR CONEXIN TCP

inicia conexin TCP

RTT
solicita archivo RTT archivo recibido tiempo

UN RTT PARA PETICIN HTTP Y


PRIMEROS BYTES DE RESPUESTA

HTTP.

tiempo transmisin archivo

TIEMPO TRANSMISIN ARCHIVO


TOTAL = 2RTT+ TIEMPO DE TRANSMISIN

tiempo

HTTP PERSISTENTE
HTTP NO PERSISTENTE:
REQUIERE

2 RTTS POR OBJETO

HTTP NOPERSISTENTE
SERVIDOR DEJA CONEXION ABIERTA DESPUS DE RESPONDER AL CLIENTE POSTERIORES MENSAJES CONEXIN ABIERTA CLIENTE/SERVIDOR ENVIADOS SOBRE CLIENTE ENVA PETICIN TAN PRONTO ENCUENTRA UN OBJETO REFERENCIADO

NAVEGADOR ABRE MULTIPLES CONEXIONES TCP PARA LLEVAR


OBJETOS REFERENCIADOS

HTTP ENTRE

AHORRA RECURSOS EN EL SERVIDOR

UN RTT PARA TODOS LOS OBJETOS


REFERENCIADOS

FORMATO DE LOS MENSAJES HTTP


LAS ESPECIFICACIONES HTTP (RFC 2616) INCLUYEN DEFINICIONES DE LOS FORMATOS DE LOS MENSAJES HTTP.
REQUEST FOR COMMENTS ("PETICIN DE COMENTARIOS"

LAS

EN ESPAOL)

MENSAJE DE PETICIN HTTP


MENSAJE DE SOLICITUD HTTP UN MENSAJE DE SOLICITUD DEL CLIENTE EST FORMADO POR: LNEA DE SOLICITUD: COMANDO URI (GET ....) <CRLF> ESTA COMPUESTA POR TRES PARTES SEPARADAS EL MTODO (GET, PUT, POST, OPTIONS, TRACE, DELETE,...) EL IDENTIFICADOR DEL RECURSO (URI). LA VERSIN DEL PROTOCOLO HTTP EN USO. CABECERA(S) <CRLF> CUERPO DE MENSAJE (EL CLIENTE PUEDE ENVIAR INFORMACIN AL SERVIDOR: DATOS DE CUMPLIMENTACIN DE UN FORMULARIO, DOCUMENTOS PARA QUE EL SERVIDOR LOS HAGA ACCESIBLES) (OPCIONAL).

LNEA DE PETICIN GET /SOMEDIR/PAGE.HTML HTTP/1.1 HOST: WWW.SOMESCHOOL.EDU USER-AGENT: MOZILLA/4.0 LNEA CABECERA CONNECTION: CLOSE ACCEPT-LANGUAGE:FR

(CUERPO DE ENTIDAD)

INDICA FIN DEL MENSAJE

METODO URL VERSION <CRLF>(RETORNO DE CARRO Y AVANCE DE LINEA) ENCABEZADO: VALOR<CRLF> ENCABEZADO: VALOR <CRLF> LINEA EN BLANCO<CRLF> CUERPO DE LA SOLICITUD
EJEMPLO

GET HTTP://ES.KIOSKEA.NET ACCEPT: TXT/HTML

HTTP/1.0

IF-MODIFIED-SINCE: SATURDAY, 15-JANUARY-2000 14:37:11 GMT


USER-AGENT: MOZILLA/4.0

MENSAJE PETICIN HTTP: FORMATO GENERAL

MENSAJE DE RESPUESTA HTTP


Lnea de estado (protocolo cdigo de estado, frase de estado) Encabezado HTTP/1.1 200 OK Connection close Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 ... Content-Length: 6821 Content-Type: text/html data data data data data ...

data, e.g., requested HTML file

EJEMPLO MENSAJE DE RESPUESTA


HTTP/1.1 200 OK CONNECTION: CLOSE

DATE: SAT, 07 JUL 2007 12:00:15 GMT


SERVER: APACHE/1.3.0 (UNIX) LAST-MODIFIED: SUN, 6 MAY 2007 09:23:24 GMT

CONTENT-TYPE: TEXT/HTML

HTTP/1.0 200 OK Date: Sat, 15 Jan 2000 14:37:12 GMT Server : Microsoft-IIS/2.0 Content-Type : text/HTML Content-Length : 1245 Last-Modified : Fri, 14 Jan 2000 08:25:13 GMT

TIPOS DE MTODOS
GET: DEVUELVE EL RECURSO IDENTIFICADO EN LA URL PEDIDA. HEAD: FUNCIONA COMO EL GET, PERO SIN QUE EL SERVIDOR DEVUELVA EL CUERPO DEL MENSAJE. ES DECIR, SLO SE DEVUELVE LA INFORMACIN DE CABECERA. POST: INDICA AL SERVIDOR QUE SE PREPARE PARA RECIBIR INFORMACIN DEL CLIENTE. SUELE USARSE PARA ENVIAR INFORMACIN DESDE FORMULARIOS. PUT: ENVA EL RECURSO IDENTIFICADO EN LA URL DESDE EL CLIENTE HACIA EL SERVIDOR.

OPTIONS: PIDE INFORMACIN

SOBRE LAS CARACTERSTICAS DE COMUNICACIN PROPORCIONADAS POR EL SERVIDOR. LE PERMITE AL CLIENTE NEGOCIAR LOS PARMETROS DE COMUNICACIN. DEPURACIN Y PERMITE AL CLIENTE VER LO QUE EL SERVIDOR RECIBE EN EL OTRO LADO.

TRACE: INICIA UN CICLO DE MENSAJES DE PETICIN. SE USA PARA


DELETE: SOLICITA AL SERVIDOR QUE BORRE EL RECURSO IDENTIFICADO CON EL URL. CONNECT: ESTE MTODO SE RESERVA PARA USO CON PROXYS. PERMITIR QUE UN PROXY PUEDA DINMICAMENTE CONVERTIRSE EN UN TNEL. POR EJEMPLO PARA COMUNICACIONES CON SSL.

HTTP CDIGOS DE ESTADO DE RESPUESTA


En la primera lnea en el servidor> mensaje de respuesta del cliente encontramos los siguientes cdigos de estados:
200 OK SOLICITUD SE REALIZ CORRECTAMENTE 301 MOVED PERMANENTLY OBJETO SOLICITADO SE MOVI 400 BAD REQUEST MENSAJE DE PETICIN NO SE ENTIENDE.

404 NOT FOUND


DOCUMENTO SOLICITADO NO ENCONTRADO EN EL SERVIDOR 505 HTTP VERSION NOT SUPPORTED VERSIN DE HTTP NO SOPORTADA.

INTERACCION USUARIO-SERVIDOR: COOKIES


UN SERVIDOR HTTP NO TIENE MEMORIA DEL ESTADO DE LA CONEXIN. ESTO SIMPLIFICA EL DISEO DEL SERVIDOR Y HA PERMITIDO A LOS INGENIEROS DESARROLLAR SERVIDOR WEB DE ALTO RENDIMIENTO QUE PUEDEN GESTIONAR MILES DE CONEXIONES TCP SIMULTANEAS. SIN EMBARGO, PARA UN SITIO WEB, A MENUDO ES DESEABLE PODER INDENTIFICAR A LOS USUARIOS O PORQUE DESEA SERVIR EL CONTENIDO EN FUNCION DE LA IDENTIDAD DEL USUARIO. PARA LOS PROTOTIPOS, HTTP UTILIZA COOKIES. LAS COOKIES, DEFINIDAS EN EL DOCUMENTO RFC 2965. PERMITEN A LOS SITIOS SEGUIR LA PISTA A LOS USUARIOS. ACTUALMENTE, LA MAYORIA DE LOS SITIOS WEB COMERCIALES MAS IMPORTANTES UTILIZAN COOKIES.

ESTADO DEL USUARIO Y EL SERVIDOR: COOKIES


MUCHOS SITIOS WEB UTILIZAN
COOKIES PRINCIPALES EJEMPLO

CUATRO COMPONENTES :
1) LNEA DE CABECERA DE
COOKIES DE MENSAJE DE RESPUESTA HTTP COOKIE EN MENSAJE DE SOLICITUD HTTP

SUSAN SIEMPRE ACCEDEN A INTERNET DESDE PC


VISITAS ESPECFICA DEL SITIO DE COMERCIO ELECTRNICO PARA LA PRIMERA VEZ

2) LNEA DE CABECERA DE

3) COOKIE MANTIENE EN EL HOST DEL USUARIO,

CUANDO LAS PETICIONES HTTP INICIAL LLEGA AL SITIO, SITIO CREA :


NICO ID

GESTIONADO POR EL NAVEGADOR DEL USUARIO

4) BASE DE DATOS BACK-END EN EL SITIO WEB

ENTRY IN BACKEND DATABASE FOR ID

COOKIES
HTTP ES UN PROTOCOLO SIN ESTADO NO SE GUARDA
INFORMACIN DE LA SESIN/HISTORIA PASADA

(ESTO SIMPLIFICA EL PROTOCOLO)


USO DE COOKIES UN COOKIE ES UN STRING QUE SE PASA EN UNA CABECERA HTTP Y QUE EL NAVEGADOR
DE TEXTO PUEDE GUARDAR EN UN PEQUEO FICHERO

EN ARCHIVOS TEMPORALES DEL NAVEGADOR

CORRESPONDIENTE

EL COOKIE SE REENVA LUEGO AL SERVIDOR HTTP CON CADA PETICIN DEL CLIENTE A ESE SERVIDOR LOS COOKIES NO PUEDEN SLO RECUERDAN
CAPTURAR INFORMACIN DEL CLIENTE

INFORMACIN PROPORCIONADA POR EL USUARIO AL SERVIDOR

(ES EL SERVIDOR QUIEN LOS CREA)

USOS
GUARDAR
LAS PREFERENCIAS DEL USUARIO

RECONOCIMIENTO DE USUARIOS EL COOKIE PUEDE GUARDAR


BASE DE DATOS UN IDENTIFICADOR QUE PERMITE AL SERVIDOR ACCEDER A TODOS LOS DATOS ALMACENADOS EN SU

GESTIN DE SESIONES

FUNCIONAMIENTO DE LAS COOKIES

COOKIES: MANTENER "ESTADO"


cliente
juana 8734
Mensaje de solicitud habitual http

servidor
El servidor facebook crea ID 1678 para el usuario

cookie file
juana 8734 facebook 1678

respuesta habitual HTTP Set-cookie: 1678


Mensaje de solicitud habitual http

Crear la entrada

cookie: 1678

una semana ms tarde :

Respuesta habitual http


Mensaje habitual de solicitud http

cookieAccion especifica

acceso

Base de datos
acceso

juana8734 facebook 1678

cookie: 1678

Respuesta habitual http

cookieAccion especifica

COOKIES (CONTINUED)
LO QUE LAS COOKIES PUEDEN TRAER :
AUTORIZACIN RECOMENDACIONES EL ESTADO DE SESIN DE USUARIO (WEB E-MAIL)
Cmo mantener "estado?

Cookies y privacidad: las cookies permiten a los sitios a aprender mucho de ti puede suministrar el nombre y correo electrnico a los sitios

criterios de valoracin del protocolo:

mantienen el estado en el emisor / receptor a travs de varias transacciones cookies: llevan Estado de mensajes http

WEB CACHE (PROXY SERVER)


Objectivo: satisfacer la peticin del cliente sin la intervencin de origen
USUARIO ESTABLECE NAVEGADOR: WEB ACCEDE
A TRAVS DE LA CACH
origin server

NAVEGADOR ENVA TODAS LAS SOLICITUDES HTTP PARA


ALMACENAR EN CACH

client

Proxy server

OBJETO EN CACH: CACH


DEVUELVE OBJECT

MS CACH PETICIONES
OBJETO DE SERVIDOR DE ORIGEN, LUEGO VUELVE OBJETO DE CLIENTE

client

origin server

MS SOBRE EL ALMACENAMIENTO EN CACH WEB


POR QU EL ALMACENAMIENTO EN CACH WEB? REDUCIR EL TIEMPO DE RESPUESTA
PARA LA SOLICITUD DEL CLIENTE REDUCIR EL TRFICO EN EL ENLACE DE ACCESO DE UNA INSTITUCIN. EL INTERNET CON CACH: PERMITE QUE LOS PROVEEDORES PUEDAN ENTREGAR EFECTIVAMENTE EL CONTENIDO (PERO LO MISMO OCURRE CON EL INTERCAMBIO DE ARCHIVOS P2P)

CACH ACTA COMO CLIENTE Y SERVIDOR

NORMALMENTE CACH SE INSTALA (COMPAA UNIVERSITARIA, RESIDENCIAL ISP) ISP

EJEMPLO DE CACHE
SUPUESTOS

TAMAO MEDIO DE OBJETO BITS

servidores de origen

= 100,000
Internet

AVG. TASA DE SOLICITUD DE LOS NAVEGADORES DE LA INSTITUCIN A LOS SERVIDORES DE ORIGEN = 15/SEC DEMORA DESDE EL ROUTER INSTITUCIONAL A CUALQUIER SERVIDOR DE ORIGEN Y DE VUELTA AL ROUTER =2 SEGUNDOS

1.5 Mbps enlace de acceso


red institucional 10 Mbps LAN

CONSECUENCIAS

LA UTILIZACIN DE

LAN = 15% = 100% ++ = 2 SEG

LA UTILIZACIN DE ENLACE DE ACCESO RETARDO TOTAL = RETRASO INTERNET RETARDO DE ACCESO LAN RETRASO + MINUTOS + MILLISEGUNDOS

Cache institucional

EJEMPLO CACH (CONT)


POSIBLE SOLUCIN

origin servers
public Internet

AUMENTAR EL ANCHO DE BANDA DEL ENLACE DE ACCESO A, POR EJEMPLO, 10 MBPS

CONSECUENCIAS(I LAN AL/RLAN)


LA UTILIZACIN DE LA LAN = 15% UTILIZACIN EN EL ENLACE DE ACCESO = 15% RETRASO TOTAL = RETRASO INTERNET + + RETARDO DE ACCESO LAN RETRASO = 2 SEC + MSECS + MILISEGUNDOS A MENUDO UNA ACTUALIZACIN
COSTOSA

10 Mbps
red institucional

enlace de acceso
10 Mbps LAN

cache institucional

EJEMPLO CACH (CONT)


POSIBLE SOLUCIN: CACHE INSTALACIN

SUPONGAMOS TASA DE XITO ES DE

0,4
public Internet

origin servers

CONSECUENCIA
DE INMEDIATO

40% DE LAS SOLICITUDES SE CUMPLIRN 60% PETICIONES SATISFECHAS POR


SERVIDOR DE ORIGEN

UTILIZACIN DEL ENLACE DE ACCESO REDUCIDO AL 60%, DANDO LUGAR A RETRASOS INSIGNIFICANTES (POR EJEMPLO, 10 MS)

1.5 Mbps enlace de acceso


red institucional 10 Mbps LAN

RETARDO TOTAL = 0.6 * (RETRASO DE LOS SERVIDORES DE ORIGEN) 0.4 * (RETRASO CUANDO SUPERE EN CACH)= 0.6

(2.01) + 0.4 (~MSECS)


= ~ 1.2 SECS

cache institucional

CONDICIONAL GET
OBJETIVO: NO ENVE OBJETO
VERSIN EN CACH SI LA

cache
HTTP solicitud msj
If-modified-since: <date>

server
objeto sin modificar

CACH TIENE HASTA AL DA LA

CACH: FECHA DE COPIA EN

CACH ESPECIFICA EN LA
SOLICITUD

respuesta HTTP
HTTP/1.0 304 Not Modified

HTTP

IF-MODIFIED-SINCE: <DATE>
SERVER: RESPUESTA CONTIENE

HTTP solicitud msj


If-modified-since: <date>

NINGN OBJETO SI LA COPIA EN


CACH EST AL DA:

HTTP/1.0 304 NOT MODIFIED

respuesta HTTP
HTTP/1.0 200 OK

objeto modificado

<data>

FIN

UN SOCKET (ENCHUFE),

ES UN MTODO PARA LA COMUNICACIN ENTRE UN PROGRAMA DEL

CLIENTE Y UN PROGRAMA DEL SERVIDOR EN UNA RED

LA WORLD WIDE WEB ES UN SISTEMA DE DISTRIBUCIN DE


INFORMACIN BASADO EN HIPERTEXTOS ENLAZADOS Y ACCESIBLES A TRAVS DE INTERNET.