簡介
它是一個用來發現HTTP緩衝區並儲存數據、治理整套的HTTP緩衝區和監測緩衝區活動的協定。這是一個試驗性協定，用來完成這些功能的幾個建議中其中的一個。
基本原理
1．1．HTTP/1.1
（參見 [RFC2616]）支持從“原始伺服器”到“客戶端”的網路對象的傳輸，或許是經由“代理伺服器”（在某些情況下，這樣做答應“快取”這些對象以備以後重用）。“客戶端”將得到的對象以某種方式消費，通常就將它作為“網頁”的一部分顯示出來。HTTP/1.0以及後來的版本答應在請求或者回響中包含有“headers”，這就擴充了HTTP/0.9（以及更早的版本）的在請求中僅指定一個URI（Uniform Resource Identifiers）和在回響中僅僅提供一個實體行為。
1．2． ICP
（參見[RFC2186]）支持象查詢其內容一樣的方式來查詢緩衝區，通常是通過其它緩衝區， 這是希望能避免從一台遠程源伺服器上高代價地索取資源。 ICP是用HTTP/0.9的思想設計的，因此呢，僅僅使用了URI（不包括任何的標題）來描述緩衝區的內容，而且，針對（for）同一個URI的多路可兼容的實體至今仍沒有好的方案。
1．3．
此文檔具體描述了一個超文本緩衝協定（HTCP），此超文本緩衝協定（HTCP）完全支持在緩衝區治理中使用請求和回響標題，並擴展了緩衝區治理的範圍――包括了一個遠程緩衝區添加和刪除的監控，以及傳送有關網路對象的提示信息，比如說象可緩衝對象的第三方的地址，或者是網路對象被測的不可緩衝性或不可用性。
協定
2.1.
所有多位元組的HTCP協定元素都是以網路位元組順序傳送的。所有的保留欄位都應當由傳送端設定為二進制0（zero）並接受端沒有檢查。同HTTP一樣，標題必須置於CRLF行的末尾。
2.2.
任何指定的主機名都應當在傳送端和接受端之間互相兼容，這樣假如正在使用一私有命名方案（比如HOSTS.TXT 或者NIS），依此方案命名的名稱將僅傳送給那些已知的參與此方案的HTCP鄰居。原始地址（由點號連線的四個小於255的數字代表ip地址的IPv4，或格式的IPv6）是通用的，就如同公用DNS名稱。使用私有名稱或者地址非凡需要一些操作上的注重事項。
2.3.
HTCP訊息可以已數據報的形式傳送，或者通過TCP連線傳送。必須支持UDP協定。HTCP代理商決不能對網路故障和網路延遲袖手旁觀。HTCP代理商應當時刻預備著，一旦出現沒有得到回響，或者回響延遲了或者被重新安排了或者被破壞了的情況，就要採取有效的措施。TCP協定是可選的，只是在協定除錯的時候才可能擁到它。IANA已經為HTCP指定了標準TCP和UDP連線埠號4827。
2.4.
應當為每一個代理商維護一套關於傳輸特性的配置變數，這些變數能夠初始化HTCP交易，或許是一套每代理商全局預設值。這些變數是：
――認為是“失敗” 交易的最大未回復交易數。
――對於某些交易認為是“失敗”交易的最大無回響間隔時間。
――交易“失敗”後嘗試開始一個新交易的最小間隔時間。
應當為每一個代理維護一組關於傳輸特性的配置變數。代理能夠初始化HTCP交易，或許它還帶有一組每代理全局預設值。
2.5.
一般來說HTCP訊息的格式如下所示：
+---------------------+
HEADER 說明訊息的長度和協定的版本
+---------------------+
DATA HTCP訊息體 (每一個主版本號都會有所不同)
+---------------------+
AUTH 可選的交易認證
+---------------------+
2.6.
HTCP/*.* 的HEADER 的具體格式如下：
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: LENGTH
+ + + + + + + + + + + + + + + + +
2: LENGTH
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: MAJOR MINOR
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
LENGTH 訊息的長度，其中包括了所有的HEADER以及八位元組數據，還包括LENGTH欄位自身所占長度。假如在使用數據報協定的話，此欄位與商務流量的大小（“記錄的長度”）是一致的，並且還包括多餘的空白，也就是說在DATA和AUTH部分並不是所有的八位元組的訊息都會有用。
MAJOR 是主版本號（0代表規格）。HTCP訊息的DATA部分需要向上或者向下兼容不同的主版本號。
MINOR 是次版本號（0代表規格）。不同的特性標準和翻譯規則依此欄位而定，非凡地，預留（RESERVED）欄位（雖然是可選的）在同一主版本號中的後續次版本號可能會有有新的含義。
2.6.1. 我們希望HTCP的發出者知道即將到來的HTCP回響者的版本號，或者HTCP的發出者通過使用數值降序法探測MINOR和MAJOR版本號（以本地可支持的最大數值開始）並在本地快取探測到的HTCP回響者的版本號。
2.6.2. 較高的主版本號優先權更高，因為較高的次版本號也是被在特定的主版本號中的。
2.7.
HTCP/0.* 的DATA 的具體格式如下：
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: LENGTH
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: OPCODE RESPONSE RESERVED F1 RR
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: TRANS-ID
+ + + + + + + + + + + + + + + + +
6: TRANS-ID
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
8:
/ OP-DATA /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
LENGTH 是HTCP訊息用來存放DATA部分的位元組數，其中包括LENGTH欄位本身所占的長度。此數還包括多餘的空白，也就是說LENGTH所預留的位元組數並不是所有的都用於OP-DATA欄位。
OPCODE 是HTCP交易的操作編碼欄位。一個HTCP交易可以包括多個HTCP訊息，比如說，一個請求訊息（由發出者傳送），或者一個回響訊息（由回響者傳送）。
RESPONSE 此為一個數值型編碼，用來指示交易成功或者失敗的。此欄位應該由請求者置為零（zero），而回響者不去管它。每一操作都有自己的一套回響編碼，這套編碼將在後邊才被確定下來。整個訊息的回響編碼如下所示：
0 必須使用認證但是還沒有使用
1 已經使用了認證，可是並不符合要求
2 操作編碼未被執行
3 不被支持的主版本號
4 不被支持的次版本號（主版本號符合要求）
5 不適當的、不答應的或者是不受歡迎的操作編碼
上面的回響編碼都是錯誤提示，它們的能見性完全取決於MO=1（接下來會有說明）是否成立。
RR 是一個標誌位，指示一條訊息是否請求(0)還是回響(1)。
F1 此位被重載，因此它對於請求者和回響者有著不同的用法。假如RR=0，那么F1被定義為RD。假如RR=1，則F1定義為MO。
RD 是一個標誌位，當它是1時，意味著要求回響。某些操作編碼（OPCODE）需要將RD置為1才有意義。
MO (em-oh) 是一個標誌位，它指示是把回響編碼解釋為對整個訊息的一個回響（ DATA中確定的欄位或者是AUTH中的任一個欄位）[ MO = 1時 ]，還是在 OP－DATA中的欄位的一個回響[ MO = 0 時]。
TRANS-ID 是一個32位位元組的值，當它與發出者的網路地址加起來，就可以唯一確定此次HTCP交易。需要謹慎的是，在UDP數據報的生命周期內不要重用此交易代號TRANS－ID。
OP-DATA 它依靠於操作編碼（opcode-dependent），其對每一操作代碼的定義見下邊。
2.8.
HTCP/0.0 的AUTH的具體格式如下:
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: LENGTH
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: SIG-TIME
+ + + + + + + + + + + + + + + + +
4: SIG-TIME
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
6: SIG-EXPIRE
+ + + + + + + + + + + + + + + + +
8: SIG-EXPIRE
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
10:
/ KEY-NAME /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
n:
/ SIGNATURE /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
LENGTH 是用來存放AUTH部分的位元組數，其中包括LENGTH欄位本身所占的長度。假如可選項AUTH不被傳送的話，此欄位應該置為2（two）。LENGTH還可以包括多餘的空白，也就是說LENGTH所預留的位元組數並不是所有的都用於SIGNATURE欄位。
SIG-TIME 是一個無符號二進制計數器，它指示著從1970年11月1號的00:00:00，（UTC，Coordinated Universal Time）開始計數，到SIGNATURE產生的所經歷的時間（以秒計）。
SIG-EXPIRE 是一個無符號二進制計數器，它指示著從1970年11月1號的00:00:00，（UTC，Coordinated Universal Time）開始計數，到SIGNATURE被認為過期所經歷的時間（以秒計）。
KEY-NAME 是一 COUNTSTR 結構[ 參見3.1 ]，它具體指定了共享密鑰的名稱。（每一個HTCP的實現都容許有幾個共享密鑰的配置，而且每一密鑰都有一個名稱）。
SIGNATURE 是一帶有一個值為64的B 的COUNTSTR 結構[ 參見3.1 ]， 它包含 HMAC-md5下邊所示的各個要素的摘要（請見[RFC2104]），其中每一個摘要都是以其“on the wire”格式整理的，假如有被與欄位相關的LENGTH覆蓋的話還包括傳送的多餘空白：
IP SRC ADDR [4 位元組]
IP SRC PORT [2位元組]
IP DST ADDR [4位元組]
IP DST PORT [2位元組]
HTCP MAJOR 版本號 [1位元組]
HTCP MINOR 版本號 [1位元組]
SIG-TIME [4位元組]
SIG-EXPIRE [4位元組]
HTCP DATA [長度可變]
KEY-NAME (全部的 COUNTSTR [3.1]) [長度可變]
2.8.1. 共享的密鑰應當隨機且秘密地生成，而且密鑰的長度至少應該有幾百個位元組。
數據類型
HTCP/0.* 的數據類型定義如下：
3.1. COUNTSTR 是一個記長度（counted）的字元串，其格式為：
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: LENGTH
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2:
/ TEXT /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
LENGTH 為後面TEXT欄位中的位元組數。此欄位與上邊講到的其它的HTCP協定中的LENGTH欄位一樣的是，它不包括自身所占的位元組數。
TEXT 是一段未被解釋的位元組流，通常為ISO8859-1標準的字元。
3.2. SPECIFIER（說明符）用於TST 和CLR請求訊息。下面有它的定義。它其格式是：
+---------------------+
METHOD : COUNTSTR
+---------------------+
URI : COUNTSTR
+---------------------+
VERSION : COUNTSTR
+---------------------+
REQ-HDRS : COUNTSTR
+---------------------+
METHOD （因為HTCP僅返回標題，所以GET和HEAD方法是等價的。）
URI （假如URI是一個URL，它通常應當還包括一個“：”說明符。若是沒有的話，接收器會使用連線埠80。）
VERSION 是一個完整的HTTP版本字元串，比如說“HTTP/1.1”。不是以“HTTP/”版本字元串打頭的以及版本號小於“1.1” 的版本字元串均不在此規格之內。
REQ-HDRS 這些標題是由HTTP發起者提供的。它們應包括端對端標題（end-to-end），而不是hop-by-hop標題，並且可以將它們標準化（例如：答應有“Accept:”集成。）
3.3. DETAIL域用於TST回響訊息，定義如下。它的格式：
+---------------------+
RESP-HDRS : COUNTSTR
+---------------------+
ENTITY-HDRS : COUNTSTR
+---------------------+
CACHE-HDRS : COUNTSTR
+---------------------+
3.4. IDENTITY 用於MON請求訊息和SET回響訊息，其定義如下。格式為：
+---------------------+
SPECIFIER
+---------------------+
DETAIL
+---------------------+
緩衝標題
HTCP/0.0的 CACHE-HDRS欄位是由零個或者多個下面列出來的標題組合而成的：
Cache-Vary: < header-name> ...
標題的傳送端知道其內容會隨著一組不同於在對象的Vary: header標題中給定的那一組的標題而變化。假如有Cache-Vary:的話，對象的Vary: header就會失效。
Cache-Location::...
標題的傳送端知道有一個以上的代理緩衝區保留了一份兒此對象的拷貝。使用HTCP探測這些緩衝區，可能會發現新的、距離近的（亦即當前更好的選擇）HTCP“鄰居”。
Cache-Policy: [no-cache] [no-share] [no-cache-cookie]
標題的傳送端知道此對象的快取策略中有比在它的回響標題中所給出的更多的具體資料。
no-cache 意思為它不可以緩衝(未給出原因)，但是在同一時間裡發生的請求間可共享。
no-share 意思為它不可以緩衝(未給出原因)，且通常需要每請求隧道。
no-cache-cookie 意思為一個不同的、被遺漏的或者甚至是隨機的cookies被包含在請求標題中的效果是其內容會變化，並且那個緩衝是不可取的。
Cache-Flags: [incomplete]
標題的傳送端修改了本地對象的緩衝策略，因此請求者可能需要非凡地處理這個回響，也就是說，並非必須要與對象的策略完全一致。
incomplete e 意思是不知道在此回響中的回響標題和/或實體標題是否是完整的，而且可能不適合用作緩衝要害字。
Cache-Expiry:
標題的傳送端知道假如時間與此對象的回響標題中指示的時間不同的話，就應認為它已經過期了。其格式與HTTP/1.1 Expires完全相同。
Cache-MD5:
標題的傳送端已為此對象計算了MD5檢驗和，它若與在對象的Content-MD5: header給定不一樣，就會被提供的，因為此對象沒有Content-MD5標題。其格式與HTTP/1.1 Content-MD5: 完全相同。
Cache-to-Origin:
標題的傳送端已經估算了到源伺服器（當作一主機名或者是文字地址）往返所需的時間。是平均所需的秒數，用一個十進制的任意精度的、且沒有指數的ASCII碼錶示。是緩衝區與源數據兩者之間的路由器數，用一個十進制的任意精度的、且沒有指數的ASCII碼錶示，假如緩衝區未知則為0。
操作
HTCP/0.* 的操作編碼（OPCODES）和它們的各自OP-DATA 數據定義如下：
5.1. NOP (OPCODE 0):
這是HTCP標準的“ping”。回響者被激發，在最短的延遲時間內執行NOP指令，相應地，請求者會用NOP RTT（一個NOP回合的時間，round trip time）來配置或者映象之用。 NOP的 RESPONSE （回響）代碼通常都是零（0），而且它沒有 OP-DATA 數據。 若RD=0，NOP請求根本就不引起任何處理。
5.2. TST (OPCODE 1):
測試在代理緩衝區中是否有特定內容的實體存在。若RD=0，NOP請求根本就不引起任何處理。
TST請求的OP-DATA數據如下：
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0:
/ SPECIFIER /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
TST的RESPONSE（回響）編碼如下：
0 實體在回響者的緩衝區內
1 實體不在回響者的緩衝區內
假如RESPONSE（回響）為零（0）TST回響有如下所示的OP-DATA數據：
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0:
/ DETAIL /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
注重: 由某一確定的TST返回的回響標題可能會是一個過期的對象。請求者對這一情況應有足夠的應付預備，可以採用將回響者當作此對象的資料來源（這會引起回響者完全地刷新此對象），或者選擇另外一個不同回響者的方法。
假如RESPONSE（回響）為一（1）TST回響有如下所示的OP-DATA數據：
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0:
/ CACHE-HDRS /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
5.3. MON (OPCODE 2):
在代理存儲器的本地對象倉庫內監視器的活動（添加，刪除，替換，等等）。因為不支持在一對UDP端點間插入HTCP交易，所以建議由請求者為每一個與其同時發出的MON請求分配一個特定的UDP端點。RD=0的MON請求與那些RD=1且TIME=0的MON請求是等價的，也就是說，它們將會取消所有未完成的MON交易。
MON請求有如下OP-DATA數據結構：
+0 (MSB)
+---+---+---+---+---+---+---+---+
0: TIME
+---+---+---+---+---+---+---+---+
TIME 為發起者所期望的監視輸出的秒數。隨後的由同一個發出者發出的帶有相同的TRANS-ID 標識的MON請求應當更新正在進行著的MON交易的時間，這稱為“部分重疊更新（overlapping renew）”。
MON的RESPONSE編碼如下所示：
0 接受，OP-DATA 已有並且合法
1 拒絕(配額錯誤 - 激活的MON太多了)
假如RESPONSE 為零（0），MON回響有如下OP-DATA 數據結構：
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: TIME ACTION REASON
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2:
/ IDENTITY /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
TIME 為此MON交易所剩餘的秒數
ACTION 為一指示一個儲存區的對象操作的數值編碼。
編碼如下：
0 存儲區中添加了一個實體
1 存儲區中將一個實體刷新
2 存儲區中一個實體被替換
3 存儲區中刪除了一個實體
REASON 為一指示一個操作的原因的數值編碼
編碼如下:
0 下邊的編碼沒有涉及的其它原因碼
1 代理客戶拿來此實體
2 代理客戶拿來此實體而存儲區不答應
3 代理伺服器預先提供了此實體
4 實體已過期，經由起標題
5 由於編碼如下存儲限制而實體被清除(purged)
5.4. SET (OPCODE 3):
通知緩衝區對象標識。 這是一個“push”交易，通過共用的緩衝區可以共享信息，比如所更新年/日期/期限標題（這可能是由於原有的“304未被修改（304 Not modified）”回響導致的）或者是更新存儲區標題（這可能是由於發現非官方的“修改（vary）”情況發生或者得到此實體的第二方或第三方存儲區所在位置導致的）。RD 為真。
SET請求有如下OP-DATA 數據結構：
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0:
/ IDENTITY /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
RESPONSE 編碼如下：
0 標識被接受，謝謝
1 標識被忽略，未給出原因，謝謝
SET 回響沒有 OP-DATA。
5.5. CLR (OPCODE 4):
告訴存儲區完全清除掉一個實體。
CLR 請求有如下OP-DATA 數據結構：
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: RESERVED REASON
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2:
/ SPECIFIER /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
REASON 為一指示請求者詢問的實體被移除的原因的數值編碼。其編碼如下：
0 其它的原因
1 原伺服器告訴我此實體並不存在
RESPONSE 編碼如下：
0 我曾經有過，現在沒有了
1 我有，且一直保留著，為提供原因
2 我沒有
CLR 回響沒有OP-DATA。
沒有具體指明回響、實體、或者存儲區標題就清除一URI意味著清除所有的使用此URI的實體。RD 為真。
安全考慮
If the optional AUTH element is not used, it is possible for unauthorized third parties to both view and modify a cache using the HTCPPRotocol.
