1 引言（2005-9-16）
1．1目的
HTTP是一個為分布式的協(xié)作的超媒體的信息系統(tǒng)而建立的應用層上的協(xié)議。自從1990年就被www采用。第一個版本，HTTP/0。9，是一個簡單的跨INTERNET傳輸原始數據的協(xié)議。HTTP/1.0（在RFC1945[6]描述），允許信息以類似MIME形式存在（包含關于傳輸數據的描述元數據和一些關于REQUEST/RESPONSE語義描述符）。但是，HTTP/1。0并沒有考慮到多級代理，緩存，持久連接的需要，或著虛擬主機。另外，越來越多的HTTP/1。0的不兼容實現(xiàn)也使得一個新版本的出現(xiàn)變的必要（需要一個統(tǒng)一版本來使協(xié)議雙方確定彼此實現(xiàn)了哪些功能）。
這份規(guī)范定義了HTTP/1。1協(xié)議。這份協(xié)議比HTTP/1。0包含了更嚴格的限制，以此來保證實現(xiàn)的可靠性，兼容性。
實際的信息系統(tǒng)要求更多功能而不僅僅是簡單的取數據，將包括查詢，前臺更新，注解。HTTP允許一個開放的方法和頭的集合來表示REQUEST的確切要求（對基于URI,URL,URN指定的資源的要求）。而傳遞的信息則采用類似MIME信息格式。
HTTP也被用來做客戶端和處理其他信息系統(tǒng)（SMTP，NNTP，F(xiàn)TP，GOPHTER，WAIS）。的代理/網關的交流。這樣，HTTP允許各種各樣的應用訪問基本的多媒體資源。
1.? 2要求
在這個文檔里出現(xiàn)的關鍵詞“MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL”按RFC2119[34]描述的那樣解釋。
如果有1個或多個MUST，REQUIRED水平的要求未滿足，那么這個實現(xiàn)就是不兼容的。如果滿足所有的MUST，REQUIRED，SHOULD水平的要求，那么這個實現(xiàn)就“unconditionallycompliant”;
滿足所有MUST但是不是所有SHOULD是“conditionally compliant”。
1．3術語
這個規(guī)范用了許多術語來描述在HTTP交流中的參與者和對象。
Connection
在2個要交流的程序間建立的虛擬傳輸層信路。
Message
基本的HTTP交流單元。由結構化的字節(jié)流構成，其結構符合SECTION4的詞法定義；通過CONNECTION傳遞。
Request
一個HTTP request message，SECTION 5 DES。
Response
一個HTTP response message，SECTION 6 DES。
Resource
一個能夠被URI標識的網絡數據對象或服務，SECTION3。2 DES。資源可以有多種表示，并且可以在其他方面有所變化。
Entity
被一個request或response作為有效負荷傳輸的信息。由頭區(qū)的元數據信息和體區(qū)的數據區(qū)組成，SECTION7 des。
Representation
在一個response里的屬于content negotiation的entity，SECTION12 des。在1個response中可以存在多個representation。
Content negotiation
一種機制，用來選擇合適的representation來服務一個request，SECTION12 des。
Variant
一個資源可以在任何給定時刻擁有多個representation。每一個被命名為variant。
Client
一個用來建立連接發(fā)送request的程序。
User agent
發(fā)送一個request的client。最常見的是瀏覽器
Server
接受連接用來為request服務并且發(fā)送回response的應用程序。任何一個程序都可以既做server，又做client,這里的概念指的就是在一次connection中的角色，而不是一般意義下的程序的能力。同樣，任何server可以作為一個origin server，proxy,gateway,或者tunnel，基于請求的性質做出不同的行為。
Orgin server
一個指定的資源的所在地或被創(chuàng)建地的server。
Proxy
一個中間程序，既做server又做client(做client是為了其他的的clients)。請求被內部服務或者被傳遞（有可能做下翻譯）到其他server。一個proxy必須實現(xiàn)規(guī)范關于client和server的雙重要求。一個“transparent proxy“是一個不對request和response做超越代理鑒定要求處理的proxy，相反就是做。除了“transparent proxy”或者“non-transparent proxy”被明確指定的特殊行為外，HTTP proxy 的要求也適用于這兩種proxy。
Gateway
一個用來為其他server服務的server。不象一個proxy，一個gateway接受請求就好象他是請求resource的origin server一樣；而請求client可能根本就不知道經過了一個gateway。
Tunnel
一個中間程序，在兩個conncetion之間做一個透明傳遞。一旦激活，它將不被認為是HTTP交流的一部分，雖然它可能是被HTTP請求初始化的。當兩個connection都關閉后它也消失了。
Cache
程序對reponse message的局部存儲，包括控制，查詢，刪除存儲的子系統(tǒng)。一個cache存儲cache response用來應對未來的同樣的請求，達到降低reponse時間和帶寬消耗的目的。任何client和server都可以包括一個cache，但是一個cache不能被一個tunnel使用。
Cacheable
如果一個cache可以存儲response message的備份來應對以后的請求，那么這個response就是cacheable。SECTION13 des。即使一個response是Cacheable，也有另外的限制來決定是否一個cache可以用一個cache拷貝來應對請求。
First-hand
一個response是從origin server或經過了幾個proxy過來的那么就是first-hand。如果它的有效性被origin server校驗過那它也是first-hand。
Explicit expiration time
Origin server確定的關于一個entity不應再由一個cache未經進一步校驗就返回的時間。
Herristic expiration time
如果一個Explicit expiration time不可用，那么這個時間被緩存使用
age
一個response的age是自從它被發(fā)送或成功地被origin server校驗后的時間段
freshness lifetime
一個response自從產生到expiration time之間的時間長度
fresh
一個response是fresh的，如果它的age還沒有超過它的freshness lifetime。
Stale
一個response是stale的，如果它的age超過了它的freshness lifetime。
Semantically transparent
一個cache一一種Semantically transparent的方式工作，對于特定的一個response，這時它的使用既沒有影響request client也沒有影響origin server（和沒經過cache一樣），但是卻提高了性能。
Validator
一個協(xié)議元素被用來找出一個cache entity 是不是等同于一個entity。
Upstream/downstream
描述了一個message的流動：所有的message從upstream流向downstream。
Inbound/outbound
是指message的request和response路徑。前者只流向origin server，后者指流向user agent。
1.4整體運行框架
HTTP協(xié)議是一個request/response協(xié)議。一個client發(fā)送一個request給一個server，由一個request method,uri,協(xié)議版本，緊跟著mime類似的信息（包含request描述符，client的信息，和與一個server傳遞數據可能的容量）。Server回以一個狀態(tài)行（包括message的協(xié)議版本，一個成功或失敗的代碼），緊跟一個MIME類似的message（包括server信息，entity的元數據，可能的entity-body容量。HTTP和MIME的關系appendix19.4。
大多數的HTTP連接被一個user agent發(fā)起，請求某些origin server上的資源。在簡單情況，可以如圖所示：
request chain ------------------------>
UA -------------------v------------------- O
<----------------------- response chain
一個更加復雜點的情況：有多個中間體介于request/response chain。有3個普遍的中間體形式：proxy，gateway，tunnel。一個proxy是一個轉送站，接受一個request,更改全部或部分message，根據uri重新發(fā)request。一個gateway是一個接受站，就象居于其他一些server之上的server一樣，如果必要，會把requeset傳給它下面的server。一個tunnel是一個接力點，連接2個連接而不改變任何message；可以被用來處理防火墻。
request chain -------------------------------------->
UA -----v----- A -----v----- B -----v----- C -----v----- O
<------------------------------------- response chain
上面的圖展示了3個中間體abc在user agent和origin server之間。一個request或response message穿越整個鏈需要通過4個獨立的連接。這個區(qū)別是很重要的，因為一些 HTTP通訊選項只能加到最近的，非tunnel鄰居，只能到chain的末端或所有連接。雖然圖是畫地直線，但是每一個參與者可能同時處理多個通訊。比如，B在處理A的request 的同時可能正在接受其他clients發(fā)過來的request，而把它們轉向非c的server。
任何參與通訊的只要不是tunnel都可以用一個內部cache來處理request。這會縮短通訊鏈如果有一方有對該request的cached reponse。下面展示了結果鏈如果B有一個從O的cache copy，而UA，或A沒有。
request chain ---------->
UA -----v----- A -----v----- B - - - - - - C - - - - - - O
<--------- response chain
并不是所有的response的緩存都是有用的，一些request可能會包含關于緩存要求的描述符。HTTP對于緩存的方式控制和response，des13。
事實上，緩存和代理的構架現(xiàn)在正在被整個WWW實驗和部署。這些系統(tǒng)包括國家級的代理緩存來存儲越洋的帶寬，系統(tǒng)廣播或多點播送cached entries，組織那些零散的緩存到CD-ROM等等。HTTP系統(tǒng)也在公司內網的寬帶連接和PDA的低能耗無線斷續(xù)連接系統(tǒng)中被使用。HTTP1。1的目標是支持在協(xié)議誕生期間已經部署的各種配置，使得WEB應用能夠達到高可靠性，至少是在失敗后有可靠的提示。
HTTP通訊通常是跨TCP/IP連接地發(fā)生。默認端口是TCP80[19]，但是其他的端口也可以被使用。這就使HTTP可以作為INTERNET上其他協(xié)議的上層協(xié)議，或其他網絡的協(xié)議。HTTP只要求一個可靠連接，任何能提供這樣的保證的協(xié)議都可以被使用；把HTTP/1。1的request和response的結構轉化成正在被討論的協(xié)議的數據單位超出了本規(guī)范的范圍。
在HTTP/1。0，大多數實現(xiàn)使用一個新的連接應對request/response交換。在HTTP/1。1中，一個連接可以被多個request/response交流使用，雖然連接可以因為多個原因被關閉。
?
?