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 --------------%26gt; ICAP-resource (surrogate) ICAP-resource (surrogate)
《ICAP協定介紹》的文章內容來自於 ChinaUnix部落格 。著作權歸原作者（佚名）所有，文章（ICAP協定介紹）的觀點並不代表Linux計算機網立場！本站僅僅是對內容及資源進行整理後發布供網友查閱，若您是此文章作者且認為侵犯了您的著作權請與管理員聯繫，文章發布時間 02-21 17:40:11。
