一. 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開發的.

本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/esinzhong/archive/2007/04/11/1560276.aspx

總結

以上是生活随笔為你收集整理的ICAP 协议的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。