T3 Protocolos

Cilente WEB Mensaje HTTP M Servidor WEB
Transporte (TCP) Segmento CT M Transporte (TCP)
Red (IP) Datagrama CR CT M Red (IP)
Enlace Trama CE CR CT M Enlace
Físico Bits Físico
Arquitectura y Prestaciones de la Web 2

URL
 Uniform Resource Locator
protocol://user:passwd@host:port/path/file?query#fragment

Client-Server.
1.- Petición
2.- Respuesta

HTTP requiere una conexión TCP
1. TCP SYN
2. TCP SYN, ACK
3. TCP ACK
4. HTTP Request
5. HTTP Response
6. TCP FIN
7. TCP ACK

HTTP 1.1 permite reutilizar la conexión TCP
1. TCP SYN
2. TCP SYN, ACK
3. TCP ACK
4. HTTP Request
5. HTTP Response
6. HTTP Request
7. HTTP Response
8. TCP FIN
9. TCP ACK

No hace falta esperar la respuesta
1. TCP SYN
2. TCP SYN, ACK
3. TCP ACK
4. HTTP Request
5. HTTP Request
6. HTTP Response
7. HTTP Response
8. TCP FIN
9. TCP ACK

Referencia: http://archive.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLatency.html

Estandar
 http://www.w3.org/Protocols/rfc2616/rfc2616
HTTP HTTP
Cliente
Servidor Proxy Servidor Web

Operaciones básicas (métodos)
 GET
o Obtener un objeto desde el servidor
 POST
o Enviar información al servidor
 PUT
o Envío de un objeto al servidor
 DELETE
o Borrado de un objeto en el servidor

Operaciones adicionales (métodos)
 OPTIONS
o Opciones soportadas por el servidor sobre el recurso
 HEAD
o Verificación de que el recurso existe.
 TRACE
o Verificación de la ruta al servidor (proxies intermedios)
 CONNECT
o Conexión a un servidor proxy

Estructura de los mensajes
 Peticiones
Línea de petición
Cabeceras de Cabeceras Generales

mensaje Cabeceras de petición
(opcional) Cabeceras de entidad
Línea en blanco
Cuerpo del
mensaje
(opcional)

 Peticiones
o Línea de petición
• METODO URI VERSION
o Ejemplo:
GET /default.htm HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT
5.0)
Host: www.ft.com
Connection: Keep-Alive

 Respuestas
Línea de estado
Cabeceras de Cabeceras Generales

mensaje Cabeceras respuesta
(opcional) Cabeceras de entidad
Línea en blanco
Cuerpo del
mensaje
(opcional)

 Respuestas
o Línea de estado
• VERSION CODIGO RAZON
o Ejemplo:
HTTP/1.1 200 OK
Date: Sun. 08 Oct 2000 18:46:12 GMT
Server: Apache/1.3.6 (Unix)
Keep-Alive: timeout=5, max=120
Connection: Keep-Alive
Content-Type: text/html
<html>…

Códigos:
 100-199: Información:
o El servidor recibió la petición, pero el resultado no está
disponible.
 200-299: Satisfactorio:
o El servidor procesó la petición.
 300-399: Redirección:
o El recurso se encuentra en otra localización.
 400-499: Error de Cliente:
o La petición contenía un error que impidió un resultado
satisfactorio.
 500-599: Error de Servidor:
o La petición era correcta pero el servidor no pudo servirla.

Mensaje
Código Significado
Asociado
100 Continue Continúa con petición parcial (nuevo en HTTP 1.1)
Switching El servidor cumplirá con la cabecera Upgrade y cambiará a
101
Protocols un protocolo diferente. (Nuevo en HTTP 1.1)

Mensaje
Código Significado
Asociado
200 OK Todo bien
201 Created El servidor creo un documento; la cabecera Location indica la URI.
202 Accepted La petición se está realizando, el proceso no se ha completado.
Non- El documento está siendo devuelto normalmente, pero algunas cabeceras

203 Authoritative de respuesta podrían ser incorrectas porque se está usando una copia del
Information documento (Nuevo en HTTP 1.1)
No hay un documento nuevo; el navegador contínua mostrando el
204 No Content documento anterior. Esto es útil si el usuario recarga periódicamente una
página y podemos determinar que la página anterior ya está actualizada.
No hay documento nuevo, pero el navegador debería resetear el
205 Reset Content documento. Usado para forzar al navegador a borrar los contenidos de los
campos de un formulario (Nuevo en HTTP 1.1)
Partial El cliente envía una petición parcial con una cabecera Range, y el servidor
206 la ha completado. (Nuevo en HTTP 1.1)
Content

Mensaje
Código Significado
Asociado
El documento pedido se puede encontrar en varios sitios; listados en el documento
Multiple
300 devuelto. Si el servidor tiene una opción preferida, debería listarse en la cabecera
Choices Location .
Moved El documento pedido está en la URI que se da en la cabecera de Location. Los

301 navegadores deberían seguir automáticamente el enlace a la nueva URI.
Permanently
Similar a 301, excepto que la nueva URI debería ser interpretada como reemplazada
302 Found temporalmente, no permanentemente.
Igual que 301/302, excepto que si la petición original era POST, el documento redirigido
303 See Other (dado en la cabecera Location) debería ser recuperado mediante GET. (Nuevo en
HTTP 1.1)
El cliente tiene un documento en el caché y realiza una petición condicional. El servidor

304 Not Modified quiere decirle al cliente que el viejo documento del caché todavía está en uso.
El documento pedido debería recuperarse mediante el proxy listado en la cabecera

305 Use Proxy Location. (Nuevo en HTTP 1.1)
Es idéntica a 302 ("Found" o "Temporarily Moved"). Fue añádido a HTTP 1.1 ya que
Temporary
307 muchos navegadores siguen erróneamente la redirección de una respuesta 302 incluso
Redirect si el mensaje original fue un POST. (Nuevo en HTTP 1.1)

Mensaje
Código Significado
Asociado
400 Bad Request Mala Sintaxis de la petición.
El cliente intenta acceder a una página protegida por password sin las
401 Unauthorized autorización apropiada. La respuesta debería incluir una cabecera WWW-
Authenticate que el navegador debería usar para mostrar la caja de diálogo
usuario/password, que viene de vuelta con la cabecera Authorization.
El recurso no está disponible, sin importar la autorización. Normalmente indica

403 Forbidden
la falta permisos de fichero o directorios en el servidor.
No se pudo encontrar el recurso en esa dirección. Esta es la respuesta

404 Not Found
estándard "no such page".
Method Not El método de la petición (GET, POST, HEAD, DELETE, PUT, TRACE, etc.)
405 Allowed no estaba permitido para este recurso particular. (Nuevo en HTTP 1.1)
El recurso indicado genera un tipo MIME incompatible con el especificado
406 Not Acceptable
por el cliente mediante su cabecera Accept. (Nuevo en HTTP 1.1)
Proxy
Similar a 401, pero el servidor proxy debería devolver una cabecera Proxy-
407 Authentication
Authenticate. (Nuevo en HTTP 1.1)
Required

Mensaje
Código Significado
Asociado
Request
408 Timeout
El cliente tarda demasiado en enviar la petición. (Nuevo en HTTP 1.1)
Usualmente asociado con peticiones PUT; usado para situaciones como la

409 Conflict
carga de una versión incorrecta de un fichero. (Nuevo en HTTP 1.1)
El documento se ha ido; no se conoce la dirección de reenvio. Difiere de la

410 Gone 404 en que se sabe que el documento se ha ido permanentemente. (Nuevo
en HTTP 1.1)
El servidor no puede procesar la petición a menos que el cliente envíe una
411 Length Required
cabecera Content-Length. (Nuevo en HTTP 1.1)
Precondition Alguna condición previa especificada en la petición era falsa (Nuevo en
412 Failed HTTP 1.1)
El documento pedido es mayor que lo que el servidor quiere manejar
Request Entity
413 Too Large
ahora. Si el servidor cree que puede manejarlo más tarde, debería incluir
una cabecera Retry-After. (Nuevo en HTTP 1.1)
Request URI
414 Too Long
La URI es demsiado larga. (Nuevo en HTTP 1.1)

Mensaje
Código Significado
Asociado
Unsupported La petición está en un formato desconocido. (Nuevo en HTTP
415 Media Type 1.1)
Requested
El cliente incluyó una cabecera Range no satisfactoria en la
416 Range Not
petición. (Nuevo en HTTP 1.1)
Satisfiable
Expectation No se puede conseguir el valor de la cabecera Expect. (Nuevo en
417 Failed HTTP 1.1)

Mensaje
Código Significado
Asociado
Mensaje genérico "server is confused". Normalmente es el
Internal
500 Server Error
resultado de programas CGI o servlets que se quedan colgados o
retornan cabeceras mal formateadas.
El servidor no soporta la funcionalidad. Usado, por ejemplo,
Not
501 Implemented
cuando el cliente envía comandos como PUT que el cliente no
soporta.
Usado por servidores que actúan como proxies o gateways;
502 Bad Gateway indica que el servidor inicial obtuvo una mala respuesta desde el
servidor remoto.
El servidor no puede responder debido a mentenimiento o
Service
503 Unavailable
sobrecarga. El servidor puede suministrar una cabecera Retry-
After.
Usado por servidores que actúan como proxies o gateways;
Gateway
504 Timeout
indica que el servidor inicial no obtuvo una respuesta a tiempo del
servidor remoto. (Nuevo en HTTP 1.1)
HTTP Version El servidor no soporta la versión de HTTP indicada en la línea de
505 Not Supported petición. (Nuevo en HTTP 1.1)

Se aplican tanto a las peticiones como a las
respuestas, pero no al contenido de los
mensajes.
 Cache-Control, son directivas que se han de tener en
cuenta a la hora de mantener el contenido en una
caché.
 Connection, permite especificar opciones requeridas
para una conexión.
 Date, representa la fecha y la hora a la que se creó el
mensaje.
 Pragma, usado para incluir directivas de
implementación.

 Trailer, conjunto de cabeceras que figuran en la
cola del mensaje
 Transfer-Encoding, indica la codificación aplicada
al contenido.
 Upgrade, permite al cliente especificar protocolos
que soporta.
 Via, usado por pasarelas y proxies para indicar los
pasos seguidos.

Permiten al cliente pasar información adicional
al servidor sobre la petición y el propio cliente
 Accept, indican el tipo de respuesta que acepta.
 Accept-Charset, indica los conjuntos de caracteres
que acepta.
 Accept-Encoding, que tipo de codificación acepta.
 Accept-Language, tipo de lenguaje de la respuesta
que se prefiere.
 Authorization, el agente de usuario quiere
autentificarse con el servidor.

 From, contiene la dirección de correo que
controla el agente de usuario.
 Host, especifica la máquina y el puerto del recurso
pedido.
 If-Modified-Since, para el GET condicional.
 If-Match, para el GET condicional.
 If-None-Match, para el GET condicional.
 If-Range, para el GET condicional.
 If-Unmodified-Since, para el GET condicional.
 Max-Forwards, indica el máximo número de
elementos por los que pasa.

 Proxy-Authorization, permite que el cliente se
identifique a un proxy.
 Range, establece un rango de bytes del
contenido.
 Referer, indica la dirección donde obtuvo la URI
de la petición.
 TE, codificaciones de transferencia (transfer
encoding) que el cliente está dispuesto a aceptar
 User-Agent, información sobre el agente que
genera la petición.

Permiten al servidor pasar información
adicional al cliente sobre la respuesta, el
propio servidor y el recurso solicitado
 Accept-Ranges,
 Age, estimación del tiempo transcurrido desde
que se creó la respuesta.
 ETag, define una marca para el contenido
asociado.
 Location, se usa par a redirigir la petición a otra
URI.

 Proxy-Authenticate, ante una respuesta con el
código 407 (autentificación proxy requerida),
indica el esquema de autentificación.
 Retry-After, ante un servicio no disponible da una
fecha para volver a intentarlo.
 Server, información sobre el servidor que maneja
las peticiones.
 Vary, indica que hay varias respuestas y el
servidor ha escogido una.
 WWW-Authenticate, indica el esquema de
autentificación y los parámetros aplicables a la
URI.

Aportan información sobre el contenido del
mensaje o si no hay contenido, sobre el recurso
al que hace referencia la URI de la petición.
 Allow, da los métodos soportados por el recurso
designado por la URI.
 Content-Encoding, indica una codificación adicional
aplicada al contenido (a parte de la aplicada por el
tipo).
 Content-Language, describe el idioma del contenido.
 Content-Length, indica el tamaño del contenido del
mensaje.

 Content-Location, da información sobre la
localización del recurso que da el contenido del
mensaje.
 Content-MD5, es un resumen en formato MD5 (RFC
1864) para chequear la integridad del contenido.
 Content-Range, en un GET parcial, indica la posición
del contenido.
 Content-Type, indica el tipo de contenido que es.
 Expires, indica la fecha a partir de la cual la respuesta
deja de ser válida.
 Last-Modified, indica la fecha de la última
modificación.

Se aplican tanto a las peticiones como
a las respuestas, pero no al contenido
de los mensajes.
Se utiliza en la comunicación Cliente-Servidor
para gestionar las conexiones persistentes.
 Indica una intención por parte del Cliente o del
Servidor
o Ejemplo:
• Connection: close
o Ejemplo:
• Connection: Keep-Alive

Indica la fecha del MENSAJE (no del recurso)
o Ejemplo:
• Date: Tue, 15 Nov 1994 08:12:31 GMT
 Los servidores están obligados a incluirla (excepto
en 100, 101 y 500)
 Los clientes deberían en PUT y POST

Indica la codificación aplicada al cuerpo del
mensaje
 Las actuales implementaciones se limitan a:
o Transfer-Encoding: chunked
 Con esto los servidores pueden comenzar a enviar
la respuesta mientras la están componiendo (sin
haber calculado Content-Length) (chunk = trozo)
 “chunked”
o Los servidores dividen el cuerpo del mensaje en trozos,
precediendo cada trozo con una línea en la que se
indica en exadecimal el tamaño del trozo. Se termina
con una línea con el tamaño 0.

o Ejemplo
HTTP/1.1 200 OK
Date: Fri, 27 Jan 2001 23:00:00 GMT
Content-Type: text/plain
Transfer-Encoding: chunked
1b
abcdefghijklmnopqrstuvwxyz
10
1234567890abcdefg
0

Se utiliza junto a “Transfer-Encoding:
chunked” para indicar qué otras cabeceras
aparecen después del cuerpo del mensaje.
o Ejemplo:
HTTP/1.1 200 OK
Date: Fri, 27 Jan 2001 23:00:00 GMT
Content-Type: text/plain
Transfer-Encoding: chunked
Trailer: Expires
1b
abcdefghijklmnopqrstuvwxyz
0
Expires: Tue, 15 Nov 1994 08:12:31 GMT

Permite la negociación cliente-servidor de un
nuevo protocolo.
o Ejemplo:
• Cliente:
GET http://example.bank.com/acct.html?749394 HTTP/1.1
Host: example.bank.com
Upgrade: TLS/1.0
Connection: Upgrade
• Servidor
HTTP/1.1 101 Switching Protocols
Upgrade: TLS/1.0, HTTP/1.1
Connection: Upgrade

Permiten al cliente pasar información
adicional al servidor sobre la petición y
el propio cliente
Se introduce en HTTP 1.1 para soportar
servidores virtuales
o Ejemplo
Host: www.ft.com
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)

El cliente indica los tipos de contenidos puede
aceptar y su preferencia relativa
o Ejemplo
• Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8
Q ES LA PREFERENCIA, EN CASO DE TENER DOS CUAL DEBERIA COGER
1 ES EL MAXIMO, Y TIENE MAS PRIORIDAD SE PRESENTA *
TODOS LOS ACCEPT PUEDEN TENER LA Q
SI NO PONE NADA EL Q ES 1

El cliente indica su preferencia relativa
respecto de la codificación de caracteres
o Ejemplo
• Accept-Charset: unicode, *; q=0.8

respecto de la codificación del contenido
o Ejemplo
• Accept-Encoding: compress, gzip; q=0.8

respecto del lenguaje
o Ejemplo
• Accept-Languaje: en-us, en-gb; q=0.8, en; q=0.3

El cliente indica la implementación específica
de HTTP que está utilizando
o Ejemplo
• User-Agent: Mozilla/4.x (Macintosh)

Cabecera opcional para identificar al usuario
humano que hace la petición
 Debido al incremento del spam los clientes HTTP
ya no la utilizan
o Ejemplo
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
From: jagil@disca.upv.es
Host: www.ft.com

Utilizada por el cliente para identificarse y
autentificarse ante un servidor.
o Ejemplo
• Cliente
GET /secret/honeypot.htm HTTP/1.1
• Servidor
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm=“/honeypot”
• Cliente
GET /secret/default.htm HTTP/1.1
Authorization: Basic QwhDtvSttS234SddvsaQ==

Utilizada por el cliente para identificarse y
autentificarse ante un Proxy.
o Ejemplo
• Cliente
GET http://server.es/secret/honeypot.htm HTTP/1.1
• Servidor
HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm=“proxy”
• Cliente
Proxy-Authorization: Basic QwhDtvSttS234SddvsaQ==

Permite solicitar parte de un recurso
o Ejemplo
• Para solicitar los octetos 500 al 999 inclusive y los dos últimos
 Range: bytes 500-999, -2
 Si el servidor soporta contenido parcial
contestará con
o 206 Partial Content
 Sino, contestará con el objeto completo
o 200 OK

Con esta cabecera el cliente le indica al
servidor que codificaciones de transferencia
(transfer encoding) está dispuesto a aceptar.
 Es similar a Accept-Encodig, pero se refiere a la
codificación de la transferencia en lugar de la del
contenido.
o Ejemplo
• TE: gzip, deflate; q=0.9

Aparece en las peticiones del cliente para que
el servidor pueda conocer dónde obtuvo la
URI
o Ejemplo
Referer: http://www.host.com/default.htm

Permiten al servidor pasar información
adicional al cliente sobre la respuesta,
el propio servidor y el recurso solicitado
Identifica el software del servidor
o Ejemplo
• Server: Apache/1.3.6 (Unix) (Red Hat/Linux)

Indica si el servidor puede aceptar peticiones
de rangos o no
o Ejemplo
• Accept-Ranges: bytes
o Ejemplo
• Accept-Ranges: none
La cabecera es opcional, se acepten rangos o

no

Se utiliza para redirigir a los clientes a una
nueva URI
 Su utilización más común es con códigos 3xx
(redirección)
 También se puede utilizar con 201 Created como
respuesta a un PUT indicando la URI del recurso
creado.

o Ejemplo
• Cliente
Host: www.host1.es
• Servidor 1
HTTP/1.1 302 Found
Location: http://www.host2.es/honeypot/default.htm
• Cliente
GET /honeypot/default.htm HTTP/1.1
Host: www.host2.es
• Servidor 2
HTTP/1.1 200 OK

Se utiliza para indicar al cliente cuándo
debería reintentar la petición
 Se puede utilizar con 503 Service Unavailable o
con los códigos 3xx (redirección)
o Ejemplo
• Retry-After: Sun. 31 Dec 2000 23:59:59 GMT
o Ejemplo
• Retry-After: 120

Permite autentificar a un cliente
 Normalmente se incluye en una respuesta 401
Unauthorized
o Ejemplo
• Cliente
• Servidor
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm=“/honeypot”
• Cliente
GET /secret/default.htm HTTP/1.1
Authorization: Basic QwhDtvSttS234SddvsaQ==

Permite autentificar a un cliente ante un Proxy
 Normalmente se incluye en una respuesta 407 Proxy
Authentication Required
o Ejemplo
• Cliente
• Proxy
HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm=“proxy”
• Cliente
Proxy-Authorization: Basic QwhDtvSttS234SddvsaQ==

Aportan información sobre el contenido del
mensaje o si no hay contenido, sobre el
recurso al que hace referencia la URI de la
petición
Indica el tipo de objeto que contiene el
mensaje
 Sigue el mismo esquema que Accept
o Ejemplo:
• Content-Type: text/plain; Charset=ISO-8859-4

Identifica qué métodos soporta (o debería
soportar) un determinado recurso
 Es obligatoria en las respuestas 405 Method Not
Allowed
o Ejemplo:
• Allow: GET, HEAD, PUT

Identifica cualquier codificación adicional propia
del recurso
o Ejemplo: mensaje de respuesta a un GET del fichero
manual.ps.gz
HTTP/1.1 200 OK
Content-Type: application/postscript
Content-Encoding: gzip
 La diferencia con Transfer-Encoding es que ésta es
intrínseca al recurso.
 Codificaciones soportadas:
o compress (UNIX)
o deflate (zlib RFC 1950)
o gzip (RFC 1952)
o identity (ninguna)

Indica el idioma del contenido
 Idéntica a Accept-Language

Indica el tamaño del recurso (cuerpo del
mensaje) en bytes
 Reglas para determinar el final de un mensaje HTTP
1. Si es una respuesta que no permite cuerpo de mensaje
(1xx, 204 y 304) termina en la primera línea en blanco.
2. Si Transfer-Encoding: chunked entonces está
determinada por el formato chunked.
3. Si existe Content-Length entonces está determinada por
esa longitud.
4. Si Content-Type: multipart/byteranges entonces el
formato del tipo de medio lo determina.
5. Si el servidor cierra la conexión entonces el último byte
recibido

Se utiliza cuando el contenido es una parte
del recurso (ver Range)
o Ejemplo
HTTP/1.1 206 Partial Content
Content-Length: 734
Content-Range: bytes 500-1233/1234

Contiene la URI correspondiente al cuerpo del
mensaje.
 Si existen distintas versiones del recurso (p.e.
idiomas) y el servidor elige una de ellas (ver
Accept-Languaje) la cabecera Content-Location
identificará el objeto que se suministra en lugar
del solicitado.

Se utiliza para detectar cambios accidentales en
el contenido del mensaje (no detecta ataques
maliciosos)
o Ejemplo: Supóngase la siguiente Pág. HTML
<html>
<body>
<p>Hello World!</p>
</body>
</html>
• Al aplicarle el algoritmo MD5 se obtiene el siguiente valor binario
de 128 bits
B2 B3 59 59 1E 96 1C 6B 0F 46 8F E5 36 BC D9 20
• Para convertir este valor binario en ASCII se utiliza la codificación
base64 resultando:
srNZWR6WHGsPRo/lNrzZIA==

• El mensaje de respuesta será:
HTTP/1.1 200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: Apache/1.3.6 (Unix) (Red Hat/Linux)
Content-Length: 66
Content-MD5: srNZWR6WHGsPRo/lNrzZIA==
<html>
<body>
<p>Hello World!</p>
</body>
</html>

Etiqueta de entidad (Entity Tag) utilizada por
el servidor para identificar únicamente el
recurso.
 Varios recursos pueden tener la misma URL (p.ej.:
versiones con distintos idiomas)
 Las caches las utilizan para identificar de forma
no ambigua el recurso.

Lista de cabeceras HTTP que unidas a la URI
determinan qué recurso envió el servidor en
respuesta a la petición
 Ejemplo:
o Vary: User-Agent

Fecha en la que el servidor origen cree que el
recurso fue modificado.
 Se utiliza por las caches para datar un objeto

Fecha a partir de la cual el recurso ya no es
válido.
 Se puede utilizar para impedir que se cachee un
objeto poniendo la misma fecha que en la
cabecera Date

If-Match pide que el servidor procese la
petición, si el recurso coincide con el ETag.
GET URI
200 OK
ETag: “xxxx”
GET URI
200 OK
ETag: “xxxx”

If-Match pide que el servidor procese la
petición, si el recurso coincide con el ETag.
PUT URI
If-Match: “xxxx”
200 OK
ETag: “yyyy”
PUT URI
412 Precondition Failed

If-Modified-Since pide que el servidor procese la
petición, si el recurso ha sido modificado después de
la fecha indicada.
 Se utiliza por las caches en relación a la cabecera de
entidad Last-Modified. GET URI
GET URI
200 OK
200 OK Last-Modified: …
Last-Modified: …
GET URI
GET URI
If-Modified-Since
200 OK
Last-Modified: …
304 Not Modified

If-None-Match pide que el servidor procese la
petición, si el recurso no coincide con el ETag.
 En GET y HEAD produce el mismo efecto que If-
Modified-Since. GET URI
GET URI
200 OK
200 OK
ETag: “xxxx”
ETag: “xxxx”
GET URI
GET URI
If-None-Match: “xxxx”
200 OK
ETag: “xxxx”
304 Not Modified
If-Unmodified-Since pide que el servidor conteste, si
el recurso no ha sido modificado después de la fecha
indicada.
GET URI
If-Unmodified-Since: …
Range: …
GET URI
200 OK
Last-Modified: …
206 Partial Content

Content-Range: …

If-Range disminuye la latencia en peticiones
parciales.
 Ejemplo: Sin If-Range
GET URI
200 OK
ETag: “xxxx”

parciales.
 Ejemplo: Sin If-Range
GET URI
GET URI
Range: …
412 Precondition Failed
200 OK
ETag: “yyyy”

parciales.
 Ejemplo: Con If-Range
GET URI
If-Range: “xxxx”
Range: …
200 OK
ETag: “yyyy”

Traza el camino que sigue la petición a través
de los proxy por los que pasa.
 Cada proxy puede añadir su propia cabecera Via o
añadirse a una existente.
 Es importante en los mensajes de TRACE

Ejemplo de un TRACE
TRACE URI TRACE URI

TRACE URI Via: 1.1 ProxyA Via: 1.1 ProxyA, 1.1 ProxyB
Cliente ProxyA ProxyB Servidor

200 OK 200 OK 200 OK
Content-Type: message/http Content-Type: message/http Content-Type: message/http
TRACE URI TRACE URI TRACE URI

Via: 1.1 ProxyA, 1.1 ProxyB Via: 1.1 ProxyA, 1.1 ProxyB Via: 1.1 ProxyA, 1.1 ProxyB

Ejemplo de un TRACE con Max-Forwards
TRACE URI TRACE URI

Max-Forwards: 1 Max-Forwards: 0
Via: 1.1 ProxyA
Cliente ProxyA ProxyB Servidor

200 OK 200 OK
Content-Type: message/http Content-Type: message/http
TRACE URI TRACE URI

Max-Forwards: 0 Max-Forwards: 0
Via: 1.1 ProxyA, 1.1 ProxyB Via: 1.1 ProxyA, 1.1 ProxyB

Directiva maestra para varias directivas que
controlan el comportamiento de la cache.
 Ejemplo:
Cache-Control: max-age=3600, no-transform,
no-cache=“Accept-Ranges”

Directiva Cache-Control: Parámetros Petición Respuesta
max-age obligados X X
max-stale opcionales X
min-fresh obligados X
must-revalidate no X
no-cache opcionales X X
no-store no X X
no-transform no X X
only-if-cached no X
Private opcionales X
proxy-revalidate no X
Public no X
s-maxage obligados X

Cabecera que estima el tiempo transcurrido
desde que se generó la respuesta.
Aparece en las respuestas generadas por las
caches
 Una respuesta cacheada es fresca si su edad no
excede su tiempo de vida.

 Parámetros para el cálculo de la frescura
o age_value: valor de la cabecera Age.
o date_value: valor de la cabecera Date.
o now: Tiempo actual en el servidor cache.
o request_time: Tiempo en el que la cache hizo la
petición
o response_time: Tiempo en el que llegó la respuesta.
 Cálculo de la frescura
• edad_aparente = response_time – date_value
• edad = max(edad_aparente, age_value)
• edad += response_time – request_time
• edad += now – response_time

El formato de los mensajes HTTP se diseñó para
su implementación con las herramientas de la
década de los 90’s, pero no es adecuado para el
rendimiento de las aplicaciones web actuales.
HTTP/1.1 con pipeline
 aborda parcialmente la concurrencia de peticiones,
pero se puede producir bloqueo en la cabecera de
línea. Por lo que se suelen utilizar varias conexiones
persistentes sin pipeline.
Algunos campos de las cabeceras son repetitivos
y prolijos lo que da como resultado una latencia
excesiva.

HTTP/2.0 proporciona un transporte
optimizado para la semántica HTTP, soporta
todas las características básicas de HTTP/1.1,
pero pretende ser más eficiente.
 Asigna de una forma más eficiente la semántica
de HTTP sobre una conexión TCP, intercalando
mensajes de petición y respuesta sobre la misma
conexión.
 Utiliza una codificación eficiente de los campos
de cabecera.
 Prioriza las solicitudes para mejorar el
rendimiento.

 La unidad básica del protocolo es una trama
 Cada trama tiene un tipo y propósito distinto
 Las tramas de HEADERS y DATA forman las peticiones y respuestas
básicas HTTP
 Hay otros tipos de tramas como SETTINGS, WINDOW_UPDATE, o
PUSH_PROMISE
 El multiplexado de peticiones se logra a través de los flujos (cada
par petición-respuesta se asigna a un flujo simple). Los flujos son
independientes entre sí (no pueden bloquear unos a otros).
 Se utilizan técnicas de control de flujos (solo se transmiten datos
que serán utilizados por el receptor) y priorización de flujos
(asegura que los recursos se asignan primero a las peticiones más
importantes).
 Se añade un nuevo tipo de interacción de tipo server push.
 Las tramas que contienen cabeceras HTTP están comprimidos.
 Se añade soporte para servicios HTTP alternativos que permiten a
los servidores un mayor control sobre el tráfico.

 Los clientes son los que establecen las conexiones TCP.
 Los clientes que realizan una petición sin conocer si el servidor
soporta HTTP/2.0 incluirán una cabecera “Upgrade” y otra
“HTTP2-Settings”
GET / HTTP/1.1
Host: server.example.com
Connection: Upgrade, HTTP2-Settings
Upgrade: h2c
HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>
 El servidor que no soporte HTTP/2.0 contestará:
HTTP/1.1 200 OK
Content-Length: 243
…
 El servidor que si soporte HTTP/2.0 contestará:
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: h2c
[ HTTP/2 connection ...

 Una vez establecida una conexión TCP y que HTTP/2.0
será utilizado por ambos, cada extremo deberá enviar
un prefacio de conexión y establecer ajustes iniciales
de la conexión.
 El cliente y el servidor enviarán un prefacio de
conexión diferente.
 Prefacio de Cliente:
 secuencia de 24 octetos:
• 0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
• “PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n”
 Seguida de una trama de SETTINGS (puede estar vacía)
 Prefacio de Servidor:
 Trama de SETTINGS (puede estar vacía)

Una vez establecida la conexión, ambos extremos pueden intercambiar
tramas.

Todas las tramas empiezan con una cabecera de
9 octetos seguida de un campo de long. variable
(payload).
 Length (3 octetos): entero sin signo de 24 bits con el
tamaño de la “payload”.
 Type (1 octeto): tipo de trama.
 Flags (1 octeto): banderas booleanas específicas para
cada tipo de trama.
 R (1 bit): reservado, debe enviarse a 0.
 Stream Identifier (31 bits): identificador de flujo. El
identificador 0 se reserva para tramas asociadas a la
conexión intergral.

DATA (0x0)
HEADERS (0x1)
PRIORITY (0x2)
RST_STREAM (0x3)
SETTINGS (0x4)
PUSH_PROMISE (0x5)
PING (0x6)
GOAWAY (0x7)
WINDOW_UPDATE (0x8)
CONTINUATION (0x9)

Un flujo es una secuencia independiente
bidireccional de tramas
 Una misma conexión HTTP/2.0 puede contener
múltiples flujos concurrentes.
 Los flujos se pueden establecer y usar
unilateralmente o de forma compartida entre el
cliente y el servidor.
 Los flujos se pueden cerrar por cualquier parte.
 El orden de las tramas en un flujo es significativo
semánticamente.
 Los flujos se identifican por un entero asignado por el
extremo que inicia el flujo.

PUSH_PROMISE IDLE PUSH_PROMISE
HEADERS
RESERVE RESERVE
D OPEN D
(local) (remote)
END_STREAM END_STREAM
HEADERS HEADERS
RST_STREAM
HALF HALF
CLOSED CLOSED
(remote) (local)
END_STREAM END_STREAM
RST_STREAM RST_STREAM
RST_STREAM RST_STREAM
CLOSED

 Todos los flujos se inician en el estado IDLE.
 Los clientes inician flujos impares, los servidores
inician flujos pares.
 Los identificadores se utilizan de forma incremental.
 El primer uso de un identificador por una parte cerrará
implícitamente todos los flujos en estado IDLE de esa
parte con un identificador menor.
 Los identificadores de flujo no pueden ser reutilizados
una vez se han cerrado.
 Si un cliente ha agotado sus identificadores puede
establecer una nueva conexión.
 Si un servidor ha agotado sus identificadores puede enviar
una trama de GOAWAY para que el cliente abra una nueva
conexión.

Internet Cache Protocol (ICP)
Cache Array Routing Protocol (CARP)
Cache Digest
Hyper Text Caching Protocol (HTCP)
Web Cache Control Protocol (WCCP)
CRISP y Relais

 Consulta entre cachés para saber si un objeto que se
desea extraer del Web se encuentra entre ellas.
 ICP utiliza UDP.
 Se calcula una estimación de la congestión y
disponibilidad de la red por los paquetes ICP que se
pierden. Esta medida, junto con el tiempo de ida y
vuelta de los mensajes permite el balanceo de carga
entre cachés.
 ICP no transporta información acerca de las cabeceras
HTTP asociadas con un objeto.
 Se pueden presentar falsos hits en el caché (p. ej.
objetos que están en una caché pero otra los
interpreta como caducados).

Disponible en
 Harvest[6][7]
 Squid [8]
 Netcache (ICPv3) [9]
 BorderManager FastCache [10]
 Netscape Proxy Server[11]
 DeleGate [12]
 MOWS[13]
 Inktomi Traffic Server [14]
 Cisco CacheEngine [15]
 SkyCache [16]
 Mirror Image [17]

Aparece durante el proyecto Harvest (1994-
95) para incluir jerarquías complejas de cache.
En 1995 el proyecto se paraliza
 Peter Danzing -> Netcache / Network appliances
 Duane Wessels -> Squid / NLANR

Predicción de aciertos
Prueba de la red
Objetos devueltos con aciertos
Medidas de tiempos de retardo de
transmisión

La cabecera de 20 bytes es la misma para
todos los mensajes
0 31
0: Opcode Version Message Length
4: Reqnum
8: Options
12: Option Data
16: Sender Host Address
20:
Payload

Opcode
 Código de la operación (8 bits)
o Determina el tipo de mensaje ICP
• 0 ICP_OP_INVALID
• 1 ICP_OP_QUERY
• 2 ICP_OP_HIT
• 3 ICP_OP_MISS
• 4 ICP_OP_ERR
• 5-9 UNUSED
• 10 ICP_OP_SECHO
• 11 ICP_OP_DECHO
• 12-20 UNUSED
• 21 ICP_OP_MISS_NOFETCH
• 22 ICP_OP_DENIED
• 23 ICP_OP_HIT_OBJ

Version
 Campo de versión del protocolo (8 bits)
o Se utilizan dos números de versión (2 y 3)
o Versión 2
• Harvest
• Squid
o Versión 3
• Netcache / Network Appliances
Message Length
 Longitud del mensaje (16 bits)
o Contiene el tamaño del mensaje ICP completo
o Si el número de bytes que se lee de la red no coincide con
este valor, entonces se descarta el mensaje

Reqnum
 Número de petición (32 bits).
o Identificador usado para relacionar peticiones y
respuestas
• Se incrementa a cada petición ICP
• Las respuestas utilizan el mismo numero que las peticiones
o No se usa en las implementaciones Harvest y Network
Appliances
Options
 Máscara de 32 bits para las opciones
o Se utilizan para soportar opciones de peticiones y
respuestas

Option Data
 Datos opcionales (4 octetos)
o Se utilizan para dar soporte a nuevas características
Sender Host Address
 Dirección IPv4 del Host que envía el mensaje
o No se utiliza, puesto que la dirección ya viene en el paquete
UDP o TCP
Payload
 Campo de tamaño variable que suele contener la URL
o La URL debe terminar en un carácter NULL
o Puede contener datos adicionales

ICP_OP_QUERY
 Pide a una cache vecina si tiene el objeto cuya
URL figura en la Payload.
 Se debe responder con
o ICP_OP_HIT,
o ICP_OP_MISS,
o ICP_OP_ERR,
o ICP_OP_MISS_NOFETCH,
o ICP_OP_DENIED,
o ICP_OP_HIT_OBJ

ICP_OP_HIT
 Esta respuesta indica que se posee una copia
fresca del objeto. Y permanecerá fresca dentro de
30 seg.
 La Payload contiene solo la URL.

ICP_OP_MISS
 Esta respuesta indica que la cache vecina no tiene
una copia fresca del objeto.
 Nótese que la cache vecina utiliza sus propios
parámetros para determinar la frescura.
 En una relación hijo-padre un fallo faculta para
pedir el objeto, mientras que en una relación
entre hermanas no.
 Si en la petición se indicaba ICP_FLAG_SRC_RTT,
y el proxy soporta la funcionalidad, debe
contenstar en la Payload con la medida del RTT al
servidor origen.

ICP_OP_MISS_NOFETCH
 Similar al MISS pero indica que no se debe pedir
este objeto actualmente.
 Permite a la cache que contesta comportarse
como hermana.
 Los motivos de esta respuesta pueden ser:
o La conexión hacia arriba está sobrecargada
o La cache está sobrecargada
o La cache por configuración puede evitar las peticiones
a determinadas horas.

ICP_OP_ERR
 La cache no pudo procesar la petición debido a un
error de protocolo.
ICP_OP_DENIED
 La cache no pudo procesar la petición debido al
control de acceso

ICP_OP_SECHO
 Source Echo
o Se utiliza para mandar un paquete UDP al puerto 7
(echo) del Servidor origen (si el servidor lo tiene
habilitado contestará con el mismo paquete)
 En el campo de Payload figura la URL
 Se utiliza para comprobar la “conectividad”

ICP_OP_DECHO
 Dumb Echo (eco mudo)
o Se utiliza para mandar un paquete UDP al puerto 7
(echo) de una cache proxy que no entiende ICP (si el
servidor lo tiene habilitado contestará con el mismo
paquete)
 Una respuesta ICP_OP_DECHO se tratará como
un fallo (MISS)
 Se utiliza para comprobar la “conectividad”
 En el campo de Payload figura la URL

ICP_OP_HIT_OBJ
 Esta respuesta indica que se posee una copia
fresca del objeto. Y el objeto figura en la Payload
 La Payload contiene la URL seguida del objeto.
 Existe el flag ICP_FLAG_HIT_OBJ que se debe
posicionar para indicar que el objeto figura en la
Payload.

ICP_FLAG_HIT_OBJ (0x80000000)
 Cuando está presente indica que el emisor
soporta el mensaje ICP_OP_HIT_OBJ
ICP_FLAG_SRC_RTT (0x40000000)
 Figura en los mensajes de petición para solicitar la
medida de tiempo de ida y vuelta.
 Figura en los mensajes de respuesta para incluir la
medida de tiempo de ida y vuelta.
 El valor de RTT figura en los 16 bits de menos
peso del campo de Option Data, y es un entero
que indica los milisegundos.

Punteros
 Diseñado por Mirror Image Internet para un
producto que opera en una configuración cluster.
 Cada nodo del cluster sabe o recuerda qué
objetos tiene cada nodo vecino.
 En lugar de contestar con un fallo puede
contestar con “YO NO LO TENGO, PERO SE
QUIEN LO TIENE”
o ICP_OP_MISS_POINTER (18)
o ICP_FLAG_POINTER (0x20000000)

Advertencia de Objetos
 Sistema de directorio centralizado (CRISP)
desarrollado por AT&T
 Se indica a los miembros del grupo cada vez que
entra o sale un objeto en el directorio
o ICP_OP_ADVERTISE (19)
o ICP_OP_UNADVERTISE (20)
o ICP_FLAG_PREADVERTISE (0x10000000)

Notificación de Petición
 Se incluyó para soportar prebúsquedas entre Squid y
Wcol
 Wcol es un proxy que genera prebúsquedas a traves
de un proxy normal.
o ICP_OP_NOTIFY (12)
 Squid genera un mensaje de NOTIFY a Wcol para
cada petición de cliente que recibe.
o ICP_FLAG_NOTIFY_MISS (0x00000008)
o ICP_FLAG_NOTIFY_HIT (0x00000004)
o ICP_FLAG_NOTIFY_REFRESH (0x00000002)
o ICP_FLAG_NOTIFY_IMS (0x00000001)
 Se puede utilizar también para logging remoto.

Borrado e Invalidación de Objetos
 En entornos altamente acoplados puede ser
deseable propagar el borrado o invalidación de
objetos.
o ICP_OP_INVALIDATE (13)
o ICP_OP_PURGE (14)
Eliminación de las URL en las respuestas
 Para reducir el tamaño de las respuestas ICP se
puede eliminar la URL
o ICP_FLAG_DONT_NEED_URL (0x04000000)

 Utiliza una función hash para dividir el espacio de
direcciones URLs entre grupos de proxy-caché.
 CARP tiene incluida la definición de una Tabla de
Miembros participantes en el grupo de proxy-caché
cooperativo, así como las formas de obtener esta
información.
 Un cliente HTTP (proxy o navegador) que implementa
CARP v1.0 puede asignar e inteligentemente dirigir
solicitudes de un URL hacia uno de los miembros.
 Gracias a un clasificación eficiente de los URLs entre
los miembros, las réplicas en la caché son eliminadas,
mejorando aciertos globales.
 CARP no es en sí un protocolo, persigue reducir la
comunicación entre cachés.

Disponible en:
 Microsoft Proxy Server[27]
 Netscape Proxy Server[28]
 Squid (parcialmente) [29]

Proporciona de manera compacta información
del contenido de su caché a los proxys
participantes en su grupo.
Una cache utiliza una especie de compendio
(Digest) para identificar algún compañero que
probablemente pueda tener un objeto del Web
buscado.
Cache Digests emplea 2 protocolos:
 cómo construir e interpretar un Digest y
 el procedimiento para intercambiar Digest (cómo
solicitarlo a otro proxy, quién puede tenerlo, etc).
Disponible en Squid2 [29]

HTCP es un protocolo utilizado para
 descubrir cachés HTTP y
 objetos que estén en alguna caché
Opera manipulando conjuntos de cachés HTTP,
y analizando su actividad.
A diferencia de ICPv2, HTCP incluye las
cabeceras, que contienen información muy útil.
Disponible en
 Mirror Image [21]
 Squid2 (parcialmente)[22]

Propietario de Cisco, redirige tráfico Web desde
un router al motor de caché de Cisco.
WCCP define la comunicación entre los motores
Caché de Cisco y routers.
Con WCCP, un router redirecciona solicitudes de
Web a un motor caché de Cisco (más que
intentar al servidor de Web).
El router también determina la disponibilidad de
las cachés o la presencia de nuevas cachés en el
grupo.
Disponible en Cisco CacheEngine [18][19]

 Permiten que un grupo de cachés cooperativas
compartan un directorio común que lista los
documentos "cacheados" por todo el grupo.
 La principal diferencia está en la representación del
directorio. CRISP lo administra centralizadamente
mientras que Relais lo replica en cada localidad donde
haya una caché.
 En caso de fallo al buscar un objeto, ambos sistemas
revisan el directorio común. Si un compañero lo tiene,
le traspasan la solicitud, si no se consulta al servidor
original.
 Disponible en
 Crispy Squid [CRISP 98]
 Saperlipopette (Simulador) [32]

T3 Protocolos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

T3 Protocolos

Cargado por

Copyright:

Formatos disponibles

Cilente WEB Mensaje HTTP M Servidor WEB

Transporte (TCP) Segmento CT M Transporte (TCP)

Red (IP) Datagrama CR CT M Red (IP)

Enlace Trama CE CR CT M Enlace

Físico Bits Físico

Arquitectura y Prestaciones de la Web 2

Arquitectura y Prestaciones de la Web 3

Arquitectura y Prestaciones de la Web 4

2. TCP SYN, ACK

Arquitectura y Prestaciones de la Web 5

2. TCP SYN, ACK

Arquitectura y Prestaciones de la Web 6

2. TCP SYN, ACK

Arquitectura y Prestaciones de la Web 7

Arquitectura y Prestaciones de la Web 8

Arquitectura y Prestaciones de la Web 9

Arquitectura y Prestaciones de la Web 10

Arquitectura y Prestaciones de la Web 11

Cabeceras de Cabeceras Generales

Arquitectura y Prestaciones de la Web 12

Arquitectura y Prestaciones de la Web 13

Cabeceras de Cabeceras Generales

Arquitectura y Prestaciones de la Web 14

Arquitectura y Prestaciones de la Web 15

Arquitectura y Prestaciones de la Web 16

Arquitectura y Prestaciones de la Web 17

201 Created El servidor creo un documento; la cabecera Location indica la URI.

202 Accepted La petición se está realizando, el proceso no se ha completado.

Non- El documento está siendo devuelto normalmente, pero algunas cabeceras

Arquitectura y Prestaciones de la Web 18

Moved El documento pedido está en la URI que se da en la cabecera de Location. Los

El cliente tiene un documento en el caché y realiza una petición condicional. El servidor

El documento pedido debería recuperarse mediante el proxy listado en la cabecera

Arquitectura y Prestaciones de la Web 19

El recurso no está disponible, sin importar la autorización. Normalmente indica

No se pudo encontrar el recurso en esa dirección. Esta es la respuesta

Arquitectura y Prestaciones de la Web 20

Usualmente asociado con peticiones PUT; usado para situaciones como la

El documento se ha ido; no se conoce la dirección de reenvio. Difiere de la

Arquitectura y Prestaciones de la Web 21

Arquitectura y Prestaciones de la Web 22

Arquitectura y Prestaciones de la Web 23

Arquitectura y Prestaciones de la Web 24

Arquitectura y Prestaciones de la Web 25

Arquitectura y Prestaciones de la Web 26

Arquitectura y Prestaciones de la Web 27

Arquitectura y Prestaciones de la Web 28

Arquitectura y Prestaciones de la Web 29

Arquitectura y Prestaciones de la Web 30

Arquitectura y Prestaciones de la Web 31

Arquitectura y Prestaciones de la Web 32

Arquitectura y Prestaciones de la Web 34

Arquitectura y Prestaciones de la Web 35

Arquitectura y Prestaciones de la Web 36

Arquitectura y Prestaciones de la Web 37

Arquitectura y Prestaciones de la Web 38

Arquitectura y Prestaciones de la Web 39

Arquitectura y Prestaciones de la Web 41

Q ES LA PREFERENCIA, EN CASO DE TENER DOS CUAL DEBERIA COGER

1 ES EL MAXIMO, Y TIENE MAS PRIORIDAD SE PRESENTA *

TODOS LOS ACCEPT PUEDEN TENER LA Q

Arquitectura y Prestaciones de la Web 42

Arquitectura y Prestaciones de la Web 43