Network Working Group D. Wessels Request for Comments: 2186 K. Claffy Categoría: Informativo National Laboratory for Applied Network Research/UCSD September 1997 Protocolo de Caché de Internet (ICP), versión 2 Estado de este memorándum: Este documento proporciona información a la comunidad Internet. Este memorándum no especifica ningún tipo de estándar de Internet. La distribución de este memorándum es ilimitada. Resumen Este documento describe la versión 2 del protocolo de caché de Internet (ICPv2) puesto en marcha actualmente en dos paquetes [3,5] de cachés proxy de la World-Wide web. ICP es un formato de mensajes de pequeño tamaño utilizado para la comunicación entre cachés web. ICP se usa para intercambiar pistas sobre la existencia de URLs en las cachés vecinas. Las cachés intercambian mensajes ICP y utilizan la información recopilada para seleccionar la localización más adecuada desde la cual recuperar un objeto Este documento describe sólo el formato y los campos de los mensajes ICP. Otro documento asociado (RFC2187) describe la aplicación de ICP a las cachés web. Varias implementaciones independientes de cachés utilizan actualmente ICP, y consideramos importante codificar la existencia de usos prácticos de ICP para aquellos que intenten implementar, desarrollar y extender su uso para sus propios propósitos. 1. Introducción ICP es un formato de mensaje utilizado para la comunicación entre cachés web. Aunque las cachés web utilizan HTTP[1] para la transferencia de objetos de datos, las cachés se benefician de un protocolo de comunicaciones más ligero y más simple. ICP se utiliza ante todo en una malla de cachés para localizar objetos web específicos en las cachés vecinas. Una caché envía una solicitud ICP a sus vecinos. Los vecinos contestan con respuestas ICP indicando un "acierto" o un "fallo." Actualmente en la práctica, ICP se implementa encima de UDP, pero no hay necesidad de que esté limitado a UDP. Creemos que ICP sobre UDP Wessels & Claffy Informativo [Página 1] RFC 2186 ICP Septiembre 1997 ofrece características importantes a las aplicaciones de cachés web. Un intercambio de solicitud/respuesta ICP necesita realizarse rápidamente, típicamente en un segundo o dos. Una caché no puede esperar más de eso antes de empezar a salvar un objeto. Un fallo al recibir un mensaje de respuesta significará como mucho que el camino de red está congestionado o roto. En ese caso no deberíamos querer seleccionar a ese vecino. Como una indicación de las condiciones inmediatas de red entre cachés vecinas, ICP sobre un protocolo con poca carga como UDP es mejor que uno con la sobrecarga de TCP. Además de su empleo como protocolo de localización de objetos, los mensajes ICP pueden ser utilizados para seleccionar cachés. Un fallo al recibir una respuesta desde una caché, puede indicar un fallo del sistema. La respuesta ICP podría incluir información que podría ayudar a la selección de la fuente más apropiada desde la cual recuperar un objeto. ICP fue inicialmente desarrollado por Peter Danzig, [et. al.] en la Universidad California del Sur como parte central de la jerarquía de caché en el 'Harvest research project' [3]. Formato del mensaje ICP El formato del mensaje ICP consiste en una cabecera fija de 20 octetos más una carga útil de tamaño variable (ver figura 1). NOTA: Todos los campos deben ser representados en el orden de los bytes de la red Opcode Uno de los códigos de operación definidos debajo. Versión El número de versión del protocolo ICP. En el momento de escribir esto, ambas versiones, la dos y la tres están siendo utilizadas. Este documento describe sólo la versión dos. El campo de número de versión permite futuros desarrollos de este protocolo. Wessels & Claffy Informativo [Página 2] RFC 2186 ICP Septiembre 1997 Longitud de mensaje 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opcode | Versión | Longitud mensaje | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Numero de petición | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opciones | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Datos de opciones | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dirección del host emisor | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Carga útil | / / / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FIGURA 1: formato de mensaje ICP. La longitud total (en octetos) del mensaje ICP. Los mensajes ICP NO DEBEN sobrepasar 16,384 octetos de longitud Numero de petición Un identificador opaco. Cuando respondemos a una pregunta, este valor debe ser copiado en el mensaje de respuesta. Opciones Un campo de 32 bits de indicadores de opciones que permite extensiones de esta versión del protocolo de forma limitada. Ver "Indicadores de opciones ICP" abajo. Datos de opciones Un campo de cuatro octetos para soportar las características opcionales. Las siguientes características ICP hacen uso de este campo: La opción ICP_FLAG_SRC_RTT utiliza los 16 bits de menor peso de los datos de opciones para devolver medidas de RTT (Round Trip Time, "tiempo de ida y de vuelta"). La opción ICP_FLAG_SRC_RTT se describe detenidamente más abajo. Dirección del host emisor Es la dirección IPv4 del emisor del mensaje ICP. Este campo Wessels & Claffy Informativo [Página 3] RFC 2186 ICP Septiembre 1997 probablemente no debería ser más creíble que lo que proporciona getpeername(), accept(), y recvfrom(). Hay algunas ambigüedades sobre el propósito original de este campo. En la práctica no se suele utilizar. Carga útil El contenido del campo Carga útil varía dependiendo del campo Opcode, pero la mayoría de las veces contiene una URL en forma de cadena terminada con null [N.del T.: carácter 0 en ASCII]. 2. Códigos de Operación de ICP La siguiente tabla muestra los códigos de operación definidos hasta el momento: Valor Nombre ----- ----------------- 0 ICP_OP_INVALID 1 ICP_OP_QUERY 2 ICP_OP_HIT 3 ICP_OP_MISS 4 ICP_OP_ERR 5-9 Sin usar 10 ICP_OP_SECHO 11 ICP_OP_DECHO 12-20 Sin usar 21 ICP_OP_MISS_NOFETCH 22 ICP_OP_DENIED 23 ICP_OP_HIT_OBJ ICP_OP_INVALID Para detectar mensajes llenos de ceros o mal hechos. Una caché nunca debe enviar intencionadamente un mensaje ICP_OP_INVALID. Debería usarse ICP_OP_ERR. ICP_OP_QUERY Un mensaje de pregunta. Notar que este código de operación tiene un formato de carga útil distinto de la mayoría de los otros. Primero va la dirección IPv4 del solicitante, seguido de una URL. La dirección del host solicitante no es la de la cache generadora del mensaje ICP, más bien es la dirección del cliente de la caché que originó la respuesta. La dirección del host solicitante está la mayoría de las veces llena de ceros. Un mensaje ICP con la dirección del host solicitante a cero debería ser tomada como una donde el solicitante no está especificado; eso no indica una dirección IPv4 válida. Formato de carga útil de ICP_OP_QUERY : Wessels & Claffy Informativo [Página 4] RFC 2186 ICP Septiembre 1997 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dirección del host solicitante | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / URL terminada con null / / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ En respuesta a un ICP_OP_QUERY, el receptor debe devolver uno de estos: ICP_OP_HIT, ICP_OP_MISS, ICP_OP_ERR, ICP_OP_MISS_NOFETCH, ICP_OP_DENIED, o ICP_OP_HIT_OBJ. ICP_OP_SECHO Similar a ICP_OP_QUERY, pero para utilizarse en simular una pregunta al servidor de origen. Cuando ICP se emplea en seleccionar el vecino más cercano, el servidor de origen puede estar incluido en el algoritmo despidiendo un mensaje ICP_OP_SECHO de su puerto de eco. La carga útil es simplemente la URL terminada con null. NOTA: el servidor de echo no interceptará los datos (i.e. podríamos no enviar nada). Este código de operación se usa para indicar la diferencia entre una solicitud o respuesta legítima , basura aleatoria, y una respuesta de echo. ICP_OP_DECHO Similar a ICP_OP_QUERY, pero para utilizarse en simular una pregunta a una caché que no utiliza ICP. Cuando ICP se usa para escoger el vecino más cercano, una caché no-ICP puede estar incluida en el algoritmo despidiendo un mensaje ICP_OP_DECHO de su puerto de eco. La carga útil es simplemente la URL terminada con null. NOTA: un problema con esta aproximación es que mientras un puerto de eco del sistema puede funcionar perfectamente, el software de la caché puede no estar funcionando. Uno de los seis códigos de operación ICP siguientes son enviados en respuesta a un mensaje ICP_OP_QUERY. Mientras que no se diga otra cosa, la carga útil debe ser una cadena con la URL terminada en null. La cadena de la URL y el campo de número de petición deben ser exactamente iguales a los que venían en el mensaje ICP_OP_QUERY. ICP_OP_HIT Una respuesta ICP_OP_HIT indica que la URL pedida existe en esta Wessels & Claffy Informativo [Página 5] RFC 2186 ICP Septiembre 1997 caché y que el solicitante tiene permiso de recuperarla. ICP_OP_MISS Una respuesta ICP_OP_MISS indica que la URL pedida no existe en esta caché. La caché solicitante todavía puede escoger buscar y traer la URL desde la caché que responde. ICP_OP_ERR Una respuesta ICP_OP_ERR indica algún tipo de error en el análisis o el manejo del mensaje de solicitud (e.g. URL inválida). ICP_OP_MISS_NOFETCH Una respuesta ICP_OP_MISS_NOFETCH indica que esta caché está lista, pero se encuentra en un estado en el que no quiere hacerse cargo de fallos de caché. Un ejemplo de tal estado es durante una fase de inicialización, donde una caché estaría reconstruyendo su almacén de objetos. Una caché en tal situación podría desear devolver ICP_OP_HIT para aciertos de caché, pero no ICP_OP_MISS para fallos. ICP_OP_MISS_NOFETCH esencialmente significa "Estoy listo y preparado, pero por favor no busques esta URL desde aquí en este momento." Observar que ICP_OP_MISS_NOFETCH tiene diferente significado que un ICP_OP_MISS. La respuesta ICP_OP_MISS es una invitación a buscar la URL desde la caché que responde (si sus relaciones lo permiten), pero ICP_OP_MISS_NOFETCH es una petición de NO buscar la URL desde la caché que responde. ICP_OP_DENIED Una respuesta ICP_OP_DENIED indica que el sitio solicitante no tiene permiso de recuperar el objeto desde esta caché. Cachés y proxys pueden implementar complejos controles de acceso. Esta respuesta debe ser interpretada como "tu no tienes permiso de recuperar esta URL en particular desde aquí en este momento." Cachés recibiendo un alto porcentaje de respuestas ICP_OP_DENIED estarán probablemente desconfiguradas. Las cachés deberían seguir la evolución del porcentaje de todas las respuestas que son ICP_OP_DENIED y deshabilitar al vecino que exceda un cierto umbral ( 95% de 100 o más solicitudes). Del mismo modo, una caché debería seguir el porcentaje de mensajes ICP_OP_DENIED que son enviados a una dirección dada. Si el porcentaje de mensajes denegados excede un cierto umbral ( 95% de 100 o más), la caché debería escoger ignorar todos los subsiguientes mensajes ICP_OP_QUERY desde esa dirección hasta que ocurra algún tipo de intervención administrativa. Wessels & Claffy Informativo [Página 6] RFC 2186 ICP Septiembre 1997 ICP_OP_HIT_OBJ Parecido a una respuesta ICP_OP_HIT, pero el dato objeto actual ha sido incluido en este mensaje de respuesta. Muchos objetos pedidos son lo suficientemente pequeños que es posible incluirlos en la respuesta y evitar la necesidad de realizar la subsiguiente petición HTTP para el objeto. AVISO: ICP_OP_HIT_OBJ tiene algunos efectos negativos que pueden hacer indeseable su uso. transfiere datos sin utilizar HTTP y por tanto se salta el proceso estándar HTTP, incluyendo autorización y validación de edad. Otro efecto secundario negativo es que los mensajes ICP_OP_HIT_OBJ serán a menudo mucho más largos que la MTU de algún trayecto, causando entonces fragmentación en los paquetes UDP. Por estas razones, no se recomienda el uso de ICP_OP_HIT_OBJ. Una caché no debe enviar un ICP_OP_HIT_OBJ a menos que el indicador ICP_FLAG_HIT_OBJ esté activado en el campo de opciones del mensaje de solicitud. Formato de carga útil de ICP_OP_HIT_OBJ: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / URL terminada con null / / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tamaño del objeto | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Datos del objeto / / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ La aplicación receptora debe comprobar que realmente recibe el tamaño en octetos de los datos del objeto . Si no lo hace, debería tratar la respuesta ICP_OP_HIT_OBJ como si fuera un ICP_OP_HIT normal. NOTA: el campo Tamaño del objeto no empieza necesariamente en la frontera de 32-bit como se muestra en el diagrama de arriba. Empieza inmediatamente después del byte NULL de la cadena de la URL. CÓDIGOS DE OPERACIÓN DESCONOCIDOS Wessels & Claffy Informativo [Página 7] RFC 2186 ICP Septiembre 1997 Mensajes ICP con códigos de operación desconocidos o no utilizados deberían ser ignorados, i.e. no generar respuesta. La aplicación podría elegir registrar el comportamiento anómalo en un archivo de anotaciones. 3. Indicadores de opciones ICP 0x80000000 ICP_FLAG_HIT_OBJ Este indicador se activa en un mensaje ICP_OP_QUERY indicando que se puede responder con un mensaje ICP_OP_HIT_OBJ si los datos del objeto caben en la respuesta. 0x40000000 ICP_FLAG_SRC_RTT Este indicador se activa en un mensaje ICP_OP_QUERY indicando que al solicitante le gustaría que la respuesta ICP incluyese las medidas de RTT del que responde al servidor original. Al recibir un ICP_OP_QUERY con el bit ICP_FLAG_SRC_RTT activo, una caché debería comprobar una base de datos interna de medidas de RTT. Si está disponible, el valor RTT DEBE ser expresado como un entero 16 bit, en unidades de milisegundos. Si no está disponible, el que responde debería poner el valor RTT a cero, o desactivar el bit ICP_FLAG_SRC_RTT en la respuesta ICP. La respuesta ICP NO DEBE ser retrasada mientras se espera que termine una medida RTT. Este indicador se activa en un mensaje de ICP (ICP_OP_HIT, ICP_OP_MISS, ICP_OP_MISS_NOFETCH o ICP_OP_HIT_OBJ) para indicar que los 16 bits de menor peso del campo de Opciones de datos contiene la medida RTT al host dado en la URL pedida. Si ICP_FLAG_SRC_RTT está desactivado en la solicitud, entonces debe estar desactivado en la respuesta. Si ICP_FLAG_SRC_RTT está activo en la solicitud, entonces podría o no estar activado en la respuesta. 4. Consideraciones de seguridad Las cuestiones de seguridad relacionadas con ICP son analizadas en el documento RFC2187. 5. Referencias [1] Fielding, R., et. al, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, UC Irvine, Enero de 1997. [2] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, CERN, Xerox PARC, Univer- sidad de Minnesota, Diciembre de 1994. Wessels & Claffy Informativo [Página 8] RFC 2186 ICP Septiembre 1997 [3] Bowman M., Danzig P., Hardy D., Manber U., Schwartz M., and Wessels D., "The Harvest Information Discovery and Access Sys- tem", Internet Research Task Force - Resource Discovery, http://harvest.transarc.com/. [4] Wessels D., Claffy K., "ICP and the Squid Web Cache", National Laboratory for Applied Network Research, http://www.nlanr.net/~wessels/Papers/icp-squid.ps.gz [5] Wessels D., "The Squid Internet Object Cache", National Labo- ratory for Applied Network Research, http://squid.nlanr.net/Squid/ 6. Agradecimientos Los autores desean dar las gracias a thank Paul A Vixie por su colaboración en este documento. 7. Direcciones de los autores Duane Wessels National Laboratory for Applied Network Research 10100 Hopkins Drive La Jolla, CA 92093 EMail: wessels@nlanr.net K. Claffy National Laboratory for Applied Network Research 10100 Hopkins Drive La Jolla, CA 92093 EMail: kc@nlanr.net Traducción: Pedro Trevilla Vara de Rey Madrid - España EMail: pedrotrev@eresmas.com Wessels & Claffy Informativo [Página 9]