ICAP协议
上一篇 / 下一篇 2018-08-23 16:34:54 / 个人分类:总结
一.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服务.
ICAPserver: 和一个HTTP server类似,但可通过ICAP请求应用程序服务.
ICAPclient:
建立和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.OriginServer对request作出应答.
4.支持ICAP的代理程序把Origin Server的应答发送ICAP server.
5.ICAP server在Origin Server的应答的上面执行ICAP资源的服务程序,然后把很可能修改过的应答送回给ICAP client.
6.代理程序把应答(很可能把Origin Server的应答修改过的)回送给用户client.
ICAPURI:
ICAP Client可以在ICAP URI里面传递参数给ICAP服务程序.ICAP URI的格式例子:
icap://icap.example.net:2000/services/antivirus
icap://icap.net/service?mode=translate&lang=french
二. ICAP的请求/应答的例子
1.请求修改模式
ICAPRequest如下所示:
REQMODicap://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"
ICAPResponse如下所示:
ICAP/1.0200 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”方式提交:
ICAPRequest:
REQMODicap://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
Iam posting this information.
0
ICAPResponse:
ICAP/1.0200 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
Iam posting this information. ICAP powered!
0
2.应答修改模式
RESPMODicap://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.1200 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
Thisis data that was returned by an origin server.
0
ICAPResponse:
ICAP/1.0200 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.1200 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
Thisis data that was returned by an origin server, but with
valueadded by an ICAP server.
0
三. ICAP协议的应用
由上面的介绍可看出, ICAP协议的实现(ICAP client和ICAP server)的作用就好像是在原
来的client和OriginServer之间, 插入了一层透明的网关, 在原来的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的工作模式:
增值服务 请求修改模式 应答修改模式
ContentFiltering Yes Yes
GatewayTranslation Yes Yes
LanguageTranslation Yes Yes
VirusScanning Yes
AdInsertion Yes Yes
DataCompression Yes
ICAP协议没有专门为某种增值服务所定义的部分, 也就是说比如对于antivirus, 在协
议中是找不到fileis clean/ file affected and been cleaned/ file affected and been deleted 等所有和antivirus有关的具体细节的. 它只是在通讯协议和系统结构方面定义了一个便于在系统中透明地增加增值服务的协议结构. 所以我们的xxxmail系统除**tivirus, 在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协议时可采用的ICAPServer和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开发的.
ICAP
ICAP
在请求修改模式下的ICAP的典型的数据流程如下图所示:
3.Origin
ICAP
二. ICAP的请求/应答的例子
1.请求修改模式
ICAP
REQMOD
Host:
Encapsulated:
GET
Host:
Accept:
Accept-Encoding:
Cookie:
If-None-Match:
ICAP
ICAP/1.0
Date:
Server:
Connection:
ISTag:
Encapsulated:
GET
Host:
Via:
Accept:
Accept-Encoding:
If-None-Match:
第2个例子和上面相似,
ICAP
REQMOD
Host:
Encapsulated:
POST
Host:
Accept:
Accept-Encoding:
Pragma:
1e
I
0
ICAP
ICAP/1.0
Date:
Server:
Connection:
ISTag:
Encapsulated:
POST
Host:
Via:
Accept:
Accept-Encoding:
Pragma:
Content-Length:
2d
I
0
2.应答修改模式
RESPMOD
Host:
Encapsulated:
GET
Host:
Accept:
Accept-Encoding:
HTTP/1.1
Date:
Server:
ETag:
Content-Type:
Content-Length:
33
This
0
ICAP
ICAP/1.0
Date:
Server:
Connection:
ISTag:
Encapsulated:
HTTP/1.1
Date:
Via:
Server:
ETag:
Content-Type:
Content-Length:
5c
This
value
0
三. ICAP协议的应用
来的client和Origin
下表是实现各种增值服务所可以采用的ICAP的工作模式:
增值服务
Content
Gateway
Language
Virus
Ad
Data
ICAP协议没有专门为某种增值服务所定义的部分,
议中是找不到file
对于我们的xxxmail系统来说,
然后用daemon程序自动扫描磁盘目录并调用杀毒引擎)并不方便改用ICAP协议,
四. 采用ICAP协议时可采用的ICAP
程序加入xxxmail系统架构中,
TAG: icap
标题搜索
日历
|
|||||||||
日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
1 | 2 | ||||||||
3 | 4 | 5 | 6 | 7 | 8 | 9 | |||
10 | 11 | 12 | 13 | 14 | 15 | 16 | |||
17 | 18 | 19 | 20 | 21 | 22 | 23 | |||
24 | 25 | 26 | 27 | 28 | 29 | 30 | |||
31 |
我的存档
数据统计
- 访问量: 108592
- 日志数: 89
- 图片数: 1
- 文件数: 15
- 建立时间: 2013-03-01
- 更新时间: 2018-08-23