El Protocolo de Adaptación de Contenido de Internet ( ICAP ) es un protocolo ligero similar a HTTP especificado en RFC 3507 que se utiliza para extender servidores proxy transparentes , liberando así recursos y estandarizando la forma en que se implementan las nuevas funciones. ICAP se utiliza generalmente para implementar análisis de virus y filtros de contenido en cachés de proxy HTTP transparentes. La adaptación de contenido se refiere a realizar el servicio de valor agregado particular (manipulación de contenido) para la solicitud / respuesta del cliente asociada.
ICAP se concentra en aprovechar los dispositivos basados en el borde ( proxies de almacenamiento en caché ) para ayudar a brindar servicios de valor agregado . En el núcleo de este proceso hay una caché que representará todas las transacciones del cliente y las procesará a través de servidores web . Estos servidores ICAP se centran en una función específica, por ejemplo, inserción de anuncios, escaneo de virus , escaneo multi-AV, traducción de contenido, traducción de idioma o filtrado de contenido . La descarga de servicios de valor agregado de los servidores web a los servidores ICAP permite escalar esos mismos servidores web de acuerdo con el rendimiento HTTP sin procesar en lugar de tener que manejar estas tareas adicionales.
Historia
El ICAP fue propuesto a finales de 1999 por Peter Danzig y John Schuster [1] de Network Appliance . [2] Don Gillies se hizo cargo del proyecto en la primavera de 2000 y mejoró el protocolo de tres formas principales:
- Permitir servidores ICAP interconectados. Una página web se puede transmitir rápidamente a través de servidores de análisis de virus, filtrado de contenido y traducción de idiomas.
- Para admitir las 3 codificaciones de contenido (longitud de contenido, fragmentado y cierre de TCP) en HTTP 1.1. Esto reemplazó el protocolo original de almacenamiento y reenvío con transmisión continua de contenido a través de muchos servidores a la vez.
- Proporcionar una función llamada "vista previa del contenido" que permitía al servidor ICAP mirar los primeros cientos de bytes de contenido antes de decidir si procesar el contenido o no. Esto se implementó incorporando el tamaño del argumento de vista previa en la URL del servidor web ICAP cuando se configuró en el cliente ICAP.
Gillies creó el prototipo del primer cliente y servidor ICAP para la serie NetCache de cachés de Internet a mediados de 2000 (conocido como protocolo ICAP 0.9) y produjo materiales de capacitación para proveedores. El cliente se escribió en C ++ en el núcleo del servidor NetCache, y el servidor ICAP de demostración se escribió en Perl y empleó los filtros de reemplazo de palabras de Debian para reescribir las páginas web, omitir las etiquetas HTML y traducir las páginas web a Swedish Chef o Jive en tiempo real. [3] Con el conocimiento aprendido de la experiencia de creación de prototipos, Gillies revisó el borrador del estándar IETF para hacer RPC usando solo codificación fragmentada, simplificando enormemente el protocolo ICAP. [1]
Referencias
- ^ a b J. Elson; A. Cerpa (2003). Protocolo de adaptación de contenido de Internet (ICAP) . IETF . doi : 10.17487 / RFC3507 . RFC 3507 .
- ^ "Protocolo de adaptación de contenido de Internet (ICAP)" (PDF) . NetApp . 2001-07-30.
- ^ Gillies, Donald. "Instrucciones de instalación de ICAP" . UBC ECE Dpto . Consultado el 4 de enero de 2016 .
enlaces externos
- RFC 3507
- Foro ICAP
- Una página de ICAP Beta Testing traducida de Yahoo News a Jive! (20 de septiembre de 2000)