茫茫網海中的冷日
         
茫茫網海中的冷日
發生過的事,不可能遺忘,只是想不起來而已!
 恭喜您是本站第 1664549 位訪客!  登入  | 註冊
主選單

Google 自訂搜尋

Goole 廣告

隨機相片
HoneyMoon_Day2_00109.jpg

授權條款

使用者登入
使用者名稱:

密碼:


忘了密碼?

現在就註冊!

一網情深 : [轉貼]圖解 ICAP(Internet Content Adaptation Protocol)

發表者 討論內容
冷日
(冷日)
Webmaster
  • 註冊日: 2008/2/19
  • 來自:
  • 發表數: 15766
[轉貼]圖解 ICAP(Internet Content Adaptation Protocol)

圖解 ICAP(Internet Content Adaptation Protocol)

ICAP(Internet Content Adaptation Protocol) 是一種被代理伺服器(Proxy)所使用的協定,目前最常見的用途為做為代理伺服器的病毒掃描或是內容過濾, SquidClamav 就是透過實作 ICAP,來達成 Proxy 病毒掃描功能的最好例子。ICAP 詳細的內容被定義在 RFC 3507 之中,其中最為重要的是 ICAP 具有兩種模式-「Request Modification(Reqmod)」與「Response Modification(Respmod)

以下以代理伺服器及網頁伺服器做為例子,解說 ICAP 運作的方式。兩種模式的運作方式,分別陳述如下。


Request Modification

  1. 使用者對代理伺服器送出要求,希望取得網頁伺服器上的網頁以進行瀏覽
  2. 代理伺服器將使用者送出的要求轉送至 ICAP 伺服器。

  3. ICAP 在收到要求之後,會對使用者所送出的要求進行檢查,若檢查不通過,ICAP 伺服器可以更改使用者所送出來的要求,再回送給代理伺服器;或是檢查通過時,則不更改使用者所送出的要求,直接原封不動的回傳至代理伺服器。
    例如假設使用者送出的要求為色情網站的網址,而 ICAP 伺服器檢查之後,發現是色情網站的網址,便將使用者所要求的網址更改為 www.google.com 。 
  4. 代理伺服器執行 ICAP 伺服器所回傳的要求。
    延續上一步的話,就變成為使用者至 www.google.com 取得網頁。
  5. www.google.com 則將網頁回傳至代理伺服器。
  6. 代理伺服器將 www.google.com 網頁回傳給使用者。(使用者怒而發現無法瀏覽色情網站)

簡而言之,對使用者所送出的 Request header 做檢查或更改,就是 Request Modification!




Response Modification

與 Request Modification 相似,但是代理伺服器會先執行使用者所送出的要求,例如第2步會直接至色情網站取得網頁之後,再將網頁內容交給 ICAP 伺服器檢查(第4步),結果 ICAP 伺服器發現網頁裡面含有色情圖片連結,便將所有的色情圖片連結更改為包子圖連結之後,再回傳給代理伺服器(第5步),代理伺服器則將 ICAP 伺服器更改過的網頁傳給使用者(第6步,使用者可能又怒而發現看不到圖片...)

簡而言之,對 Response content 做檢查或更改,就是 Response Modification!


參考資料:
http://www.rfc-editor.org/rfc/rfc3507.txt
http://wiki.squid-cache.org/Features/ICAP

http://squidclamav.darold.net/install.html

原文出處:Jedi Linuxer: 圖解 ICAP(Internet Content Adaptation Protocol)
冷日
(冷日)
Webmaster
  • 註冊日: 2008/2/19
  • 來自:
  • 發表數: 15766
[轉貼]Internet Content Adaptation Protocol
Symantec 的說法:
ICAP (Internet Content Adaptation Protocol,Internet 內容調適通訊協定)
一種輕量型通訊協定,用於對 HTTP 訊息執行遠端程序呼叫。Symantec Scan Engine 支援版本 1.0 的 ICAP,如 RFC 3507 (2003 年 4 月) 中所述。
ICAP (Internet Content Adaptation Protocol,Internet 內容調適通訊協定)


Wiki 的說明:
Internet Content Adaptation Protocol
From Wikipedia, the free encyclopedia
This article includes a list of references, related reading or external links, but its sources remain unclear because it lacks inline citations. Please help to improve this article by introducing more precise citations. (October 2015) (Learn how and when to remove this template message)

The Internet Content Adaptation Protocol (ICAP) is a lightweight HTTP-like protocol specified in RFC 3507 which is used to extend transparent proxy servers, thereby freeing up resources and standardizing the way in which new features are implemented. ICAP is generally used to implement virus scanning and content filters in transparent HTTP proxy caches. Content adaptation refers to performing the particular value added service (content manipulation) for the associated client request/response.

ICAP concentrates on leveraging edge-based devices (caching proxies) to help deliver value-added services. At the core of this process is a cache that will proxy all client transactions and will process them through ICAP web servers. These ICAP servers are focused on a specific function, for example, ad insertion, virus scanning, content translation, language translation, or content filtering. Off-loading value-added services from web servers to ICAP servers allows those same web servers to be scaled according to raw HTTP throughput versus having to handle these extra tasks.
History

ICAP was proposed in late 1999 by Peter Danzig and John Schuster[1] from Network Appliance.[2] Don Gillies took over the project in the spring of 2000 and enhanced the protocol in three main ways:

To allow pipelined ICAP servers. One web page could be streamed through virus-scan, content-filtering, and language translation servers, quickly.
To support all 3 content encodings (content-length, chunked, and TCP-close) in HTTP 1.1. This replaced original store-and-forward protocol with continuous streaming of content through many servers at once.
To provide a feature called "content preview" that allowed the ICAP server to look at the first few hundred bytes of content before deciding to process the content or not. This was implemented by embedding the preview argument size in the ICAP webserver URL when configured on the ICAP client.

Gillies prototyped the first ICAP client and server for the NetCache series of internet caches in mid-2000 (known as ICAP 0.9 protocol) and produced training materials for vendors. The client was written in C++ in the core of the NetCache server, and the demonstration ICAP Server was written in Perl and employed the Debian word-replacement filters to rewrite web pages, skipping over the HTML tags, and translating web pages into Swedish Chef or Jive in real time.[3] With knowledge learned from the prototyping experience, Gillies revised the IETF draft standard to make RPCs using only chunked encoding, greatly simplifying the ICAP protocol.[1]

References
J. Elson; A. Cerpa (2003). Internet Content Adaptation Protocol (ICAP). IETF. RFC 3507.
"Internet Content Adaptation Protocol (ICAP)" (PDF). NetApp. 2001-07-30.
Gillies, Donald. "ICAP Installation Instructions". UBC ECE Dept. Retrieved 2016-01-04.

External links
RFC 3507
ICAP Forum
A page from ICAP Beta Testing translated from Yahoo News into Jive! (Sept 20, 2000)
前一個主題 | 下一個主題 | 頁首 | | |



Powered by XOOPS 2.0 © 2001-2008 The XOOPS Project|