本備忘錄的狀態
本備忘錄定義了一種Internet社區的試驗性的協議。它并沒有具體指定任何一種Internet標準。它需要進一步進行討論和建議以得到改進。本備忘錄的發布不受任何限制。
版權聲明
Copyright (C) The Internet Society (2000). All Rights Reserved.
摘要
本文檔描述了超文本緩沖協議（HTCP），它是一個用來發現HTTP緩沖區并儲存數據、治理整套的HTTP緩沖區和監測緩沖區活動的協議。這是一個試驗性協議，用來完成這些功能的幾個建議中其中的一個。
1. 定義、基本原理及其范圍Definitions, Rationale and Scope
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. 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. 共享的密鑰應當隨機且秘密地生成，而且密鑰的長度至少應該有幾百個字節。
3. 數據類型
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，它通常應當還包括一個“：”
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
+---------------------+
4. 緩沖標題
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:
標題的發送端已經估算了到源服務器（當作一主機名或者是文字地址）往返所需的時間。
6. HTCP 操作
HTCP/0.* 的操作編碼（OPCODES）和它們的各自OP-DATA 數據定義如下：
6.1. NOP (OPCODE 0):
這是HTCP標準的“ping”。響應者被激發，在最短的延遲時間內執行NOP指令，相應地，請求者會用NOP RTT（一個NOP回合的時間，round trip time）來配置或者映象之用。 NOP的 RESPONSE （響應）代碼通常都是零（0），而且它沒有 OP-DATA 數據。 若RD＝0，NOP請求根本就不引起任何處理。
6.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 /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
6.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)
6.4. SET (OPCODE 3):
通知緩沖區對象標識。 這是一個“push”交易，通過共用的緩沖區可以共享信息，比如所更新年/日期/期限標題（這可能是由于原有的“304未被修改（304 Not modified）”響應導致的）或者是更新存儲區標題（這可能是由于發現非官方的“修改（vary）”情況發生或者得到此實體的第二方或第三方存儲區所在位置導致的）。RD 為真。
SET請求有如下OP-DATA 數據結構：
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0:
/ IDENTITY /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
RESPONSE 編碼如下：
0 標識被接受，謝謝
1 標識被忽略，未給出原因，謝謝
SET 響應沒有 OP-DATA。
6.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 為真。
7. 安全考慮
If the optional AUTH element is not used, it is possible for unauthorized third parties to both view and modify a cache using the HTCP PRotocol.
8. 感謝
Mattias Wingstedt of Idonex brought key insights to the development
of this protocol. David Hankins helped clarify this document.
9. 參考文獻
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC2396,
August 1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
L., Leach, P. and T. Berners-Lee, "Hypertext Transfer
Protocol -- HTTP/1.1", RFC2616, June 1999.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC2104, February,
1997.
[RFC2186] Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP),
version 2", RFC2186, September 1997.
10. 作者地址
Paul Vixie
Internet Software Consortium
950 Charter Street
Redwood City, CA 94063
Phone: +1 650 779 7001
EMail: vixie@isc.org
Duane Wessels
National Lab for Applied Network Research
USCD, 9500 Gilman Drive
La Jolla, CA 92093
Phone: +1 303 497 1822
EMail: wessels@nlanr.net
11. 完整的版權聲明
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all sUCh copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
新聞熱點
疑難解答
