ICAP协议分析原理

  一.    ICAP协议简介
ICAP是Internet Content Adaptation Protocol的缩写.它在本质上是在HTTP message上执
行RPC远程过程调用的一种轻量级的 协议, 也就是说, 它让ICAP Client可以把HTTP Message传给ICAP Server,  然后ICAP Server可以对其进行某种变换或者其他处理(“匹配”).被变换的message可以是HTTP请求也可以是HTTP应答. 
    ICAP是和HTTP 协议在结构和用法上都相似的请求/应答式的 协议.虽然和HTTP 协议类似,但它并不是HTTP,也并不是以HTTP 协议为底层 协议在其上实现的应用层 协议, 也就是说, ICAP的message不能够被HTTP代理所处理和转发. 实际上, 在ICAP 协议刚被提出的时侯, 出于HTTP 协议已被业界广泛采用和利用在HTTP上的已有的大量投资, 是曾经把它设计成HTTP上层的应用层 协议的.  但是, 以HTTP为底层而实现的方案后来被证明是不可行的, 因为一些对于ICAP相当重要的特性无法在HTTP上面实现.例如,  ICAP Client可以在传输一个消息体的中间暂停并且等待一个”100 Continue”消息, 而HTTP Client只能在消息头和消息体之间暂停等待, 另外, HTTP代理程序对Http message的一些变换是合法的和无害的, 而对于ICAP, 由于ICAP的”消息头中又内嵌有消息头”的封装机制和其他其他一些特性就将会引起问题.
    Origin Server
用户所要获得的资源所存储在或者所被生成的Server, 例如xxxmail的box server就是一种Origin Server.
    ICAP资源
    和HTTP资源相似, 但是其URI指定的是某个负责执行HTTP message的变换的ICAP服务.
ICAP server:
   和一个HTTP server类似,但可通过ICAP请求应用程序服务.
ICAP client:
   建立和ICAP servers的连接并发送请求给它的程序.ICAP client经常是(但不总是)为用户服务的代理程序.
    ICAP的两种工作模式: 
1)    请求修改模式
在”请求修改”(reqmod) 模式中, ICAP Client把HTTP request发送给ICAP Server, 然后ICAP SERVER可以做以下处理之一: 
a.    送回http request的一个修改后的版本, 然后ICAP Client把修改后的http request交给一个Origin Server去处理, 或者把修改后的request排队送到另一个ICAP Server做进一步的修改;
b.    送回一个http response. 在错误发生需要给用户有用的提示信息的时侯. 例如”你请求访问一个你没有权限访问的网页”. 
c.    返回一个错误.
ICAP Client 必须能够处理以上所有这3种ICAP SERVER的response. 但是ICAP Client的实现在处理错误的时侯仍可具有灵活性, 对于 ICAP Server返回的错误, 可以直接把错误返回给用户, 或者再重新尝试匹配变换过程(把http request交给ICAP Server 修改的过程).
在请求修改模式下的ICAP的典型的数据流程如下图所示: 
    origin-server
        | /|/ 
        |  |
     5  |  |  4
        |  |
       /|/ |              2
    ICAP-client    -------------->   ICAP-resource  
    (surrogate)    <--------------   on ICAP-server
        | /|/             3
        |  |
     6  |  |  1 
        |  |
       /|/ |
       client
1. 用户client向支持ICAP的代理程序 (ICAP client)发送请求, 请求获得在一个Origin Server上的一个对象(网页,文件等等).
2. 代理程序向ICAP server发送请求.
3. ICAP server在收到的request 上面执行ICAP 资源的服务程序,然后送回很可能修改过的 request, 或者是对该request的response给ICAP client.

如果步骤3 送回了request的话:

   4. 代理程序把ICAP Server送回的request(很可能和用户client的原来的request不同了的)送给Origin Server.
   5. Origin Server对request作处理并把应答给代理程序.

6. 代理程序把应答 (从ICAP server回送的或者是Origin Server回送的) 回送给用户client.
2)    应答修改模式
在”应答修改”(respmod)模式中,ICAP client把HTTP response(Origin Server所生成的)发送给ICAP server, 然后ICAP server可以做以下之一: 
a.    回送response的一个修改后的版本.
b.    返回错误
在应答修改模式下的ICAP的典型的数据流程如下图所示: 
   origin-server
        | /|/
        |  |
     3  |  |  2
        |  |
       /|/ |            4
    ICAP-client    -------------->   ICAP-resource  
    (surrogate)    <--------------   on ICAP-server
        | /|/            5
        |  |
     6  |  |  1 
        |  |
       /|/ |
       client
1. 用户client向支持ICAP的代理程序 (ICAP client)发送请求,请求获得一个在Origin Server上的对象.
2. 代理程序把request送给Origin Server.
3. Origin Server对request作出应答.
4. 支持ICAP的代理程序把Origin Server的应答发送ICAP server.
5. ICAP server在Origin Server的应答的上面执行ICAP资源的服务程序,然后把很可能修改过的应答送回给ICAP client.
6. 代理程序把应答(很可能把Origin Server的应答修改过的)回送给用户client.

ICAP URI:
ICAP Client可以在ICAP URI里面传递参数给ICAP服务程序.ICAP URI的格式例子: 
icap://icap.example.net:2000/services/antivirus
icap://icap.net/service?mode=translate&lang=french
二.    ICAP的请求/应答的例子
1.    请求修改模式
ICAP Request如下所示: 
REQMOD icap://icap-server.net/server?arg=87 ICAP/1.0
Host: icap-server.net
Encapsulated: req-hdr=0, null-body=170

GET / HTTP/1.1
Host: www.origin-server.com
Accept: text/html, text/plain
Accept-Encoding: compress
Cookie: ff39fk3jur@4ii0e02i
If-None-Match: "xyzzy", "r2d2xxxx"

ICAP Response如下所示:
ICAP/1.0 200 OK
Date: Mon, 10 Jan 2000  09:55:21 GMT
Server: ICAP-Server-Software/1.0
Connection: close
ISTag: "W3E4R7U9-L2E4-2"
Encapsulated: req-hdr=0, null-body=231

GET /modified-path HTTP/1.1
Host: www.origin-server.com
Via: 1.0 icap-server.net (ICAP Example ReqMod Service 1.1)
Accept: text/html, text/plain, image/gif
Accept-Encoding: gzip, compress
If-None-Match: "xyzzy", "r2d2xxxx"

第2个例子和上面相似, 但request是以”POST”方式提交而不是以”GET”方式提交: 
ICAP Request:
REQMOD icap://icap-server.net/server?arg=87 ICAP/1.0
Host: icap-server.net
Encapsulated: req-hdr=0, req-body=147

POST /origin-resource/form.pl HTTP/1.1
Host: www.origin-server.com
Accept: text/html, text/plain
Accept-Encoding: compress
Pragma: no-cache

1e
I am posting this information.
0

ICAP Response:
ICAP/1.0 200 OK
Date: Mon, 10 Jan 2000  09:55:21 GMT
Server: ICAP-Server-Software/1.0
Connection: close
ISTag: "W3E4R7U9-L2E4-2"
Encapsulated: req-hdr=0, req-body=244

POST /origin-resource/form.pl HTTP/1.1
Host: www.origin-server.com
Via: 1.0 icap-server.net (ICAP Example ReqMod Service 1.1)
Accept: text/html, text/plain, image/gif
Accept-Encoding: gzip, compress
Pragma: no-cache
Content-Length: 45

2d
I am posting this information.  ICAP powered!
0
2.    应答修改模式

RESPMOD icap://icap.example.org/satisf ICAP/1.0
Host: icap.example.org
Encapsulated: req-hdr=0, res-hdr=137, res-body=296

GET /origin-resource HTTP/1.1
Host: www.origin-server.com
Accept: text/html, text/plain, image/gif
Accept-Encoding: gzip, compress

HTTP/1.1 200 OK
Date: Mon, 10 Jan 2000 09:52:22 GMT
Server: Apache/1.3.6 (Unix)
ETag: "63840-1ab7-378d415b"
Content-Type: text/html
Content-Length: 51

33
This is data that was returned by an origin server.
0

ICAP Response:
ICAP/1.0 200 OK
Date: Mon, 10 Jan 2000  09:55:21 GMT
Server: ICAP-Server-Software/1.0
Connection: close
ISTag: "W3E4R7U9-L2E4-2"
Encapsulated: res-hdr=0, res-body=222

HTTP/1.1 200 OK
Date: Mon, 10 Jan 2000  09:55:21 GMT
Via: 1.0 icap.example.org (ICAP Example RespMod Service 1.1)
Server: Apache/1.3.6 (Unix)
ETag: "63840-1ab7-378d415b"
Content-Type: text/html
Content-Length: 92

5c
This is data that was returned by an origin server, but with
value added by an ICAP server.
0

三.    ICAP协议的应用
由上面的介绍可看出, ICAP 协议的实现(ICAP client和ICAP server)的作用就好像是在原
来的client和Origin Server之间, 插入了一层透明的网关, 在原来的client和Origin Server之间传输数据的时侯可以调用Content Filter, 病毒扫描, 广告插入,数据压缩,语言翻译等增值服务修改所传输的数据,  从而可达到在系统上实现这些增值服务,  并且对于原有的client和Origin Server是透明的, 即原有的client和Origin Server不用知道这些增值服务的存在,  好像仍然是client和Origin Server直接打交道一样. 
    ICAP 协议还有以下好处: 
1)    它是一个开放的 协议并且较易实现,  所以采用它来实现增值服务的提供会有较好的可扩展性, 也可以比较快地实现.
2)    ICAP client可以与多个ICAP server一起工作, 所以可以比较容易地将增值服务的软件程序(例如杀毒引擎)分布到多个server上, 实现负载平衡, 提高增值服务的可靠性和性能.
3)    可以把增值服务的实现完全outsource出去.
4)    提高Origin Server的数据内容的可 管理性,  安全和可控制性. 
下表是实现各种增值服务所可以采用的ICAP的工作模式: 
增值服务    请求修改模式    应答修改模式
Content Filtering         Yes         Yes
Gateway Translation         Yes         Yes
Language Translation         Yes         Yes
Virus Scanning             Yes
Ad Insertion         Yes         Yes
Data Compression             Yes

ICAP 协议没有专门为某种增值服务所定义的部分,  也就是说比如对于antivirus, 在协
议中是找不到file is clean/ file affected and been cleaned/ file affected and been deleted 等所有和antivirus有关的具体细节的. 它只是在通讯 协议和系统结构方面定义了一个便于在系统中透明地增加增值服务的 协议结构. 所以我们的xxxmail系统除了antivirus, 在anti-spam等其他增值服务也可以采用ICAP来实现的. 
对于我们的xxxmail系统来说, 以现在的antivirus的实现方式(把文件解到磁盘目录里,
然后用daemon程序自动扫描磁盘目录并调用杀毒引擎)并不方便改用ICAP 协议, 如果要改用ICAP 协议则有可能是把box server当作Origin Server,  把 webmail cgi/pop/imap程序当作client,  实现 ICAP client和ICAP server插在box server和webmail cgi/pop/imap中间, 由ICAP server 去调用杀毒引擎.  这种实现体系结构方面的改变是需要一定的工作量的. 

四.    采用ICAP协议时可采用的ICAP Server和ICAP Client Library
对于自己没有ICAP支持能力的增值服务程序, 如果我们要采用ICAP来实现把增值服务
程序加入xxxmail系统架构中, 可采用Bell Labs Internet Service Engine (ISE):  http: //www.bell-labs.com/project/ISE/  作为ICAP Server,    它提供和Apache API相似的 service module API可用其来实现调用增值服务程序.   至于ICAP Client可采用 Bell Labs ICAP Client Library:  http://www.bell-labs.com/project/ICAP/   作为开发类库来实现.   不过Bell Labs Internet Service Engine和 Bell Labs ICAP Client Library都只有linux平台的binary且不提供源码,  无法在solaris上用.   至于Open Source的我只找到一个:  http://sourceforge.net/projects/icap-server  ,  是用 python开发的.