HTTP详解-工作原理
http://blog.csdn.net/hguisu/article/details/8680808
1. HTTP簡介
???????? HTTP協(xié)議（HyperText Transfer Protocol，超文本傳輸協(xié)議）是用于從WWW服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。它可以使瀏覽器更加高效，使網(wǎng)絡(luò)傳輸減少。它不僅保證計算機(jī)正確快速地傳輸超文本文檔，還確定傳輸文檔中的哪一部分，以及哪部分內(nèi)容首先顯示(如文本先于圖形)等。
?????????在了解HTTP如何工作之前，我們先了解計算機(jī)之間的通信。
2. 計算機(jī)相互之間的通信
??????? 互聯(lián)網(wǎng)的關(guān)鍵技術(shù)就是TCP/IP協(xié)議。兩臺計算機(jī)之間的通信是通過TCP/IP協(xié)議在因特網(wǎng)上進(jìn)行的。實際上這個是兩個協(xié)議：
??????? TCP : Transmission Control Protocol 傳輸控制協(xié)議和IP： Internet Protocol? 網(wǎng)際協(xié)議。
????? ? IP：計算機(jī)之間的通信
?????? ?IP協(xié)議是計算機(jī)用來相互識別的通信的一種機(jī)制，每臺計算機(jī)都有一個IP.用來在internet上標(biāo)識這臺計算機(jī)。? IP 負(fù)責(zé)在因特網(wǎng)上發(fā)送和接收數(shù)據(jù)包。通過 IP，消息（或者其他數(shù)據(jù)）被分割為小的獨立的包，并通過因特網(wǎng)在計算機(jī)之間傳送。IP 負(fù)責(zé)將每個包路由至它的目的地。
??????? IP協(xié)議僅僅是允許計算機(jī)相互發(fā)消息，但它并不檢查消息是否以發(fā)送的次序到達(dá)而且沒有損壞（只檢查關(guān)鍵的頭數(shù)據(jù)）。為了提供消息檢驗功能，直接在IP協(xié)議上設(shè)計了傳輸控制協(xié)議TCP.
????????
?????? TCP : 應(yīng)用程序之間的通信
?????? TCP確保數(shù)據(jù)包以正確的次序到達(dá)，并且嘗試確認(rèn)數(shù)據(jù)包的內(nèi)容沒有改變。TCP在IP地址之上引端口（port），它允許計算機(jī)通過網(wǎng)絡(luò)提供各種服務(wù)。一些端口號為不同的服務(wù)保留，而且這些端口號是眾所周知。
?????? 服務(wù)或者守護(hù)進(jìn)程：在提供服務(wù)的機(jī)器上，有程序監(jiān)聽特定端口上的通信流。例如大多數(shù)電子郵件通信流出現(xiàn)在端口25上，用于wwww的HTTP通信流出現(xiàn)在80端口上。
???????當(dāng)應(yīng)用程序希望通過 TCP 與另一個應(yīng)用程序通信時，它會發(fā)送一個通信請求。這個請求必須被送到一個確切的地址。在雙方“握手”之后，TCP 將在兩個應(yīng)用程序之間建立一個全雙工 (full-duplex) 的通信，占用兩個計算機(jī)之間整個的通信線路。TCP 用于從應(yīng)用程序到網(wǎng)絡(luò)的數(shù)據(jù)傳輸控制。TCP 負(fù)責(zé)在數(shù)據(jù)傳送之前將它們分割為 IP 包，然后在它們到達(dá)的時候?qū)⑺鼈冎亟M。
?????? TCP/IP 就是TCP 和 IP 兩個協(xié)議在一起協(xié)同工作，有上下層次的關(guān)系。
?????? TCP 負(fù)責(zé)應(yīng)用軟件（比如你的瀏覽器）和網(wǎng)絡(luò)軟件之間的通信。IP 負(fù)責(zé)計算機(jī)之間的通信。TCP 負(fù)責(zé)將數(shù)據(jù)分割并裝入 IP 包，IP 負(fù)責(zé)將包發(fā)送至接受者，傳輸過程要經(jīng)IP路由器負(fù)責(zé)根據(jù)通信量、網(wǎng)絡(luò)中的錯誤或者其他參數(shù)來進(jìn)行正確地尋址，然后在它們到達(dá)的時候重新組合它們。
?
3. HTTP協(xié)議所在的協(xié)議層
????? HTTP是基于TCP協(xié)議之上的。在TCP/IP協(xié)議參考模型的各層對應(yīng)的協(xié)議如下圖,其中HTTP是應(yīng)用層的協(xié)議。
?????
?
4. HTTP請求響應(yīng)模型???
?????? HTTP由請求和響應(yīng)構(gòu)成，是一個標(biāo)準(zhǔn)的客戶端服務(wù)器模型（B/S）。HTTP協(xié)議永遠(yuǎn)都是客戶端發(fā)起請求，服務(wù)器回送響應(yīng)。見下圖:
???
?
?????? HTTP是一個無狀態(tài)的協(xié)議。無狀態(tài)是指客戶機(jī)（Web瀏覽器）和服務(wù)器之間不需要建立持久的連接，這意味著當(dāng)一個客戶端向服務(wù)器端發(fā)出請求，然后服務(wù)器返回響應(yīng)(response)，連接就被關(guān)閉了，在服務(wù)器端不保留連接的有關(guān)信息.HTTP遵循請求(Request)/應(yīng)答(Response)模型。客戶機(jī)（瀏覽器）向服務(wù)器發(fā)送請求，服務(wù)器處理請求并返回適當(dāng)?shù)膽?yīng)答。所有HTTP連接都被構(gòu)造成一套請求和應(yīng)答。
?
?
5. HTTP工作過程??????
???? 一次HTTP操作稱為一個事務(wù)，其工作整個過程如下：
???? 1 ) 、地址解析，
???? 如用客戶端瀏覽器請求這個頁面：http://localhost.com:8080/index.htm
???? 從中分解出協(xié)議名、主機(jī)名、端口、對象路徑等部分，對于我們的這個地址，解析得到的結(jié)果如下：
???? 協(xié)議名：http
???? 主機(jī)名：localhost.com
???? 端口：8080
???? 對象路徑：/index.htm
????? 在這一步，需要域名系統(tǒng)DNS解析域名localhost.com,得主機(jī)的IP地址。
?
??? 2）、封裝HTTP請求數(shù)據(jù)包
???? 把以上部分結(jié)合本機(jī)自己的信息，封裝成一個HTTP請求數(shù)據(jù)包
?
?????3）封裝成TCP包，建立TCP連接（TCP的三次握手）
???????在HTTP工作開始之前，客戶機(jī)（Web瀏覽器）首先要通過網(wǎng)絡(luò)與服務(wù)器建立連接，該連接是通過TCP來完成的，該協(xié)議與IP協(xié)議共同構(gòu)建Internet，即著名的TCP/IP協(xié)議族，因此Internet又被稱作是TCP/IP網(wǎng)絡(luò)。HTTP是比TCP更高層次的應(yīng)用層協(xié)議，根據(jù)規(guī)則，只有低層協(xié)議建立之后才能，才能進(jìn)行更層協(xié)議的連接，因此，首先要建立TCP連接，一般TCP連接的端口號是80。這里是8080端口
?????4）客戶機(jī)發(fā)送請求命令
?????? 建立連接后，客戶機(jī)發(fā)送一個請求給服務(wù)器，請求方式的格式為：統(tǒng)一資源標(biāo)識符（URL）、協(xié)議版本號，后邊是MIME信息包括請求修飾符、客戶機(jī)信息和可內(nèi)容。
???? 5）服務(wù)器響應(yīng)
?????服務(wù)器接到請求后，給予相應(yīng)的響應(yīng)信息，其格式為一個狀態(tài)行，包括信息的協(xié)議版本號、一個成功或錯誤的代碼，后邊是MIME信息包括服務(wù)器信息、實體信息和可能的內(nèi)容。
??????? 實體消息是服務(wù)器向瀏覽器發(fā)送頭信息后，它會發(fā)送一個空白行來表示頭信息的發(fā)送到此為結(jié)束，接著，它就以Content-Type應(yīng)答頭信息所描述的格式發(fā)送用戶所請求的實際數(shù)據(jù)
???? 6）服務(wù)器關(guān)閉TCP連接
?????一般情況下，一旦Web服務(wù)器向瀏覽器發(fā)送了請求數(shù)據(jù)，它就要關(guān)閉TCP連接，然后如果瀏覽器或者服務(wù)器在其頭信息加入了這行代碼
????Connection:keep-alive
?? TCP連接在發(fā)送后將仍然保持打開狀態(tài)，于是，瀏覽器可以繼續(xù)通過相同的連接發(fā)送請求。保持連接節(jié)省了為每個請求建立新連接所需的時間，還節(jié)約了網(wǎng)絡(luò)帶寬。
?
?
6. HTTP協(xié)議棧中各層數(shù)據(jù)流??????
?????????????首先我們看看客戶端請求的時候，數(shù)據(jù)在各層協(xié)議的數(shù)據(jù)組織如下圖：
????????
??????????? 而服務(wù)器解析客戶機(jī)請求就是反向操作的過程，如下圖：
??????????
???????
?????? 客戶機(jī)發(fā)起一次請求的時候：
?????? 客戶機(jī)會將請求封裝成http數(shù)據(jù)包-->封裝成Tcp數(shù)據(jù)包-->封裝成Ip數(shù)據(jù)包--->封裝成數(shù)據(jù)幀--->硬件將幀數(shù)據(jù)轉(zhuǎn)換成bit流（二進(jìn)制數(shù)據(jù)）-->最后通過物理硬件（網(wǎng)卡芯片）發(fā)送到指定地點。
????? ?服務(wù)器硬件首先收到bit流....... 然后轉(zhuǎn)換成ip數(shù)據(jù)包。于是通過ip協(xié)議解析Ip數(shù)據(jù)包，然后又發(fā)現(xiàn)里面是tcp數(shù)據(jù)包，就通過tcp協(xié)議解析Tcp數(shù)據(jù)包，接著發(fā)現(xiàn)是http數(shù)據(jù)包通過http協(xié)議再解析http數(shù)據(jù)包得到數(shù)據(jù)。
6. HTTPS實現(xiàn)原理? ??
?????????????HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目標(biāo)的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL。其所用的端口號是443。
SSL：安全套接層，是netscape公司設(shè)計的主要用于web的安全傳輸協(xié)議。這種協(xié)議在WEB上獲得了廣泛的應(yīng)用。通過證書認(rèn)證來確保客戶端和網(wǎng)站服務(wù)器之間的通信數(shù)據(jù)是加密安全的。
? ? ? 有兩種基本的加解密算法類型：
? ? ? 1）對稱加密（symmetrcic encryption）：密鑰只有一個，加密解密為同一個密碼，且加解密速度快，典型的對稱加密算法有DES、AES，RC5，3DES等；
? ? ? ?對稱加密主要問題是共享秘鑰，除你的計算機(jī)（客戶端）知道另外一臺計算機(jī)（服務(wù)器）的私鑰秘鑰，否則無法對通信流進(jìn)行加密解密。解決這個問題的方案非對稱秘鑰。
? ? ? 2）非對稱加密：使用兩個秘鑰：公共秘鑰和私有秘鑰。私有秘鑰由一方密碼保存（一般是服務(wù)器保存），另一方任何人都可以獲得公共秘鑰。
? ? ? 這種密鑰成對出現(xiàn)（且根據(jù)公鑰無法推知私鑰，根據(jù)私鑰也無法推知公鑰），加密解密使用不同密鑰（公鑰加密需要私鑰解密，私鑰加密需要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密算法有RSA、DSA等。
? ?下面看一下https的通信過程：
???
過程大致如下： 1） SSL客戶端通過TCP和服務(wù)器建立連接之后（443端口），并且在一般的tcp連接協(xié)商（握手）過程中請求證書。 即客戶端發(fā)出一個消息給服務(wù)器，這個消息里面包含了自己可實現(xiàn)的算法列表和其它一些需要的消息，SSL的服務(wù)器端會回應(yīng)一個數(shù)據(jù)包，這里面確定了這次通信所需要的算法，然后服務(wù)器向客戶端返回證書。（證書里面包含了服務(wù)器信息：域名。申請證書的公司，公共秘鑰）。 ? ? ? ? ? ? ? ?? 2）Client在收到服務(wù)器返回的證書后，判斷簽發(fā)這個證書的公共簽發(fā)機(jī)構(gòu)，并使用這個機(jī)構(gòu)的公共秘鑰確認(rèn)簽名是否有效，客戶端還會確保證書中列出的域名就是它正在連接的域名。 3） ?如果確認(rèn)證書有效，那么生成對稱秘鑰并使用服務(wù)器的公共秘鑰進(jìn)行加密。然后發(fā)送給服務(wù)器，服務(wù)器使用它的私鑰對它進(jìn)行解密，這樣兩臺計算機(jī)可以開始進(jìn)行對稱加密進(jìn)行通信。
https通信的優(yōu)點：
1）客戶端產(chǎn)生的密鑰只有客戶端和服務(wù)器端能得到；
2）加密的數(shù)據(jù)只有客戶端和服務(wù)器端才能得到明文；
3）客戶端到服務(wù)端的通信是安全的。
?
http://blog.csdn.net/hguisu/article/details/8683290
1. HTTP請求格式??????
?????? 做過Socket編程的人都知道，當(dāng)我們設(shè)計一個通信協(xié)議時，“消息頭/消息體”的分割方式是很常用的，消息頭告訴對方這個消息是干什么的，消息體告訴對方怎么干。HTTP協(xié)議傳輸?shù)南⒁彩沁@樣規(guī)定的，每一個HTTP包都分為HTTP頭和HTTP體兩部分，消息體是可選的，而消息頭是必須的。每當(dāng)我們打開一個網(wǎng)頁，在上面點擊右鍵，選擇“查看源文件”，這時看到的HTML代碼就是HTTP的消息體，那么消息頭可以通過瀏覽器的開發(fā)工具或者插件可以看到，如果火狐的Firebug，IE的Httpwatch。
????? 客戶端通過發(fā)送 HTTP 請求向服務(wù)器請求對資源的訪問。它向服務(wù)器傳遞了一個數(shù)據(jù)塊，也就是請求信息，HTTP 請求由三部分組成：請求行、??請求頭和請求正文。
?請求行：請求方法 URI 協(xié)議/版本
??請求頭(Request Header)
?
?請求正文
下面是一個HTTP請求的數(shù)據(jù)：
POST /index.php HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-cn,zh;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://localhost/
Content-Length：25
Content-Type：application/x-www-form-urlencoded
?
username=aa&password=1234
?
1、請求行：請求方法URI協(xié)議/版本
?請求的第一行是“方法 URL? 協(xié)議/版本”，并以回車換行作為結(jié)尾。請求行以空格分隔。格式如下：
POST /index.php HTTP/1.1
以上代碼中“GET”代表請求方法，“//ndex.php”表示URI，“HTTP/1.1代表協(xié)議和協(xié)議的版本。
??????? 根據(jù)HTTP標(biāo)準(zhǔn)，HTTP請求可以使用多種請求方法。例如：HTTP1.1支持7種請求方法：GET、POST、HEAD、OPTIONS、PUT、DELETE和TARCE。在Internet應(yīng)用中，最常用的方法是GET和POST。
???????? URL完整地指定了要訪問的網(wǎng)絡(luò)資源，通常只要給出相對于服務(wù)器的根目錄的相對目錄即可，因此總是以“/”開頭，最后，協(xié)議版本聲明了通信過程中使用HTTP的版本。???
請求方法
在 HTTP 協(xié)議中，HTTP 請求可以使用多種請求方法，這些方法指明了要以何種方式來訪問 Request-URI 所標(biāo)識的資源。HTTP1.1 支持的請求方法如下表所示：
HTTP1.1 中的請求方式：
| 方法 | 作用 |
| GET | 請求獲取由 Request-URI 所標(biāo)識的資源 |
| POST | 請求服務(wù)器接收在請求中封裝的實體，并將其作為由 Request-Line 中的 Request-URI 所標(biāo)識的資源的一部分 |
| HEAD | 請求獲取由 Request-URI 所標(biāo)識的資源的響應(yīng)消息報頭 |
| PUT | 請求服務(wù)器存儲一個資源，并用 Request-URI 作為其標(biāo)識符 |
| DELETE | 請求服務(wù)器刪除由 Request-URI 所標(biāo)識的資源 |
| TRACE | 請求服務(wù)器回送到的請求信息，主要用于測試或診斷 |
| CONNECT | 保留將來使用 |
| OPTIONS | 請求查詢服務(wù)器的性能，或者查詢與資源相關(guān)的選項和需求 |
?
重點介紹?GET、POST 和 HEAD 三個方法：
（1）GET
??????? GET 方法用于獲取由 Request-URI 所標(biāo)識的資源的信息，常見的形式是：
??????? GET Request-URI HTTP/1.1
??????? GET方法是默認(rèn)的HTTP請求方法，例如當(dāng)我們通過在瀏覽器的地址欄中直接輸入網(wǎng)址的方式去訪問網(wǎng)頁的時候，瀏覽器采用的就是 GET 方法向服務(wù)器獲取資源。
??????? 我們可以使用GET方法來提交表單數(shù)據(jù)，用GET方法提交的表單數(shù)據(jù)只經(jīng)過了簡單的編碼，同時它將作為URL的一部分向服務(wù)器發(fā)送，因此，如果使用GET方法來提交表單數(shù)據(jù)就存在著安全隱患上。例如：
???????? Http://localhost/login.php?username=aa&password=1234
??????? 從上面的URL請求中，很容易就可以辯認(rèn)出表單提交的內(nèi)容。（？之后的內(nèi)容）另外由于GET方法提交的數(shù)據(jù)是作為URL請求的一部分所以提交的數(shù)據(jù)量不能太大。這是因為瀏覽器對url的長度有限制
?????? 各種瀏覽器也會對url的長度有所限制，下面是幾種常見瀏覽器的url長度限制:(單位:字符)
IE : 2803
Firefox:65536
Chrome:8182
Safari:80000
Opera:190000
（2）POST
????????? POST方法是GET方法的一個替代方法，它主要是向Web服務(wù)器提交表單數(shù)據(jù)，尤其是大批量的數(shù)據(jù)。?在請求頭信息結(jié)束之后的兩個回車換行之后（實際是空一行），就是表單提交的數(shù)據(jù)。如上面提到的post表單數(shù)據(jù)：
??????? username=aa&password=1234
??????? POST方法克服了GET方法的一些缺點。通過POST方法提交表單數(shù)據(jù)時，數(shù)據(jù)不是作為URL請求的一部分而是作為標(biāo)準(zhǔn)數(shù)據(jù)傳送給Web服務(wù)器，這就克服了GET方法中的信息無法保密和數(shù)據(jù)量太小的缺點。因此，出于安全的考慮以及對用戶隱私的尊重，通常表單提交時采用POST方法。
從編程的角度來講，如果用戶通過GET方法提交數(shù)據(jù)，則數(shù)據(jù)存放在QUERY＿STRING環(huán)境變量中，而POST方法提交的數(shù)據(jù)則可以從標(biāo)準(zhǔn)輸入流中獲取。
?
?GET與POST方法有以下區(qū)別：
??????1、? 在客戶端，Get方式在通過URL提交數(shù)據(jù)，數(shù)據(jù)在URL中可以看到；POST方式，數(shù)據(jù)放在HTTP包的body中。
??????2、 GET方式提交的數(shù)據(jù)大小有限制（因為瀏覽器對URL的長度有限制），而POST則沒有此限制。
????? 3、安全性問題。正如在（1）中提到，使用 Get 的時候，參數(shù)會顯示在地址欄上，而 Post 不會。所以，如果這些數(shù)據(jù)是中文數(shù)據(jù)而且是非敏感數(shù)據(jù)，那么使用 get；如果用戶輸入的數(shù)據(jù)不是中文字符而且包含敏感數(shù)據(jù)，那么還是使用 post為好。
????? 4.、服務(wù)器取值方式不一樣。GET方式取值，如php可以使用$_GET來取得變量的值，而POST方式通過$_POST來獲取變量的值。
?
（3）HEAD
???? HEAD 方法與 GET 方法幾乎是相同的，它們的區(qū)別在于 HEAD 方法只是請求消息報頭，而不是完整的內(nèi)容。對于 HEAD 請求的回應(yīng)部分來說，它的 HTTP 頭部中包含的信息與通過 GET 請求所得到的信息是相同的。利用這個方法，不必傳輸整個資源內(nèi)容，就可以得到 Request-URI 所標(biāo)識的資源的信息。這個方法通常被用于測試超鏈接的有效性，是否可以訪問，以及最近是否更新。
???要注意的是，在 HTML 文檔中，書寫 get 和 post，大小寫都可以，但在 HTTP 協(xié)議中的 GET 和 POST 只能是大寫形式。
2. 請求頭
每個頭域由一個域名，冒號（:）和域值三部分組成。域名是大小寫無關(guān)的，域值前可以添加任何數(shù)量的空格符，頭域可以被擴(kuò)展為多行，在每行開始處，使用至少一個空格或制表符。
HTTP最常見的請求頭如下：
Transport 頭域
Connection：
作用：表示是否需要持久連接。
如果服務(wù)器看到這里的值為“Keep-Alive”，或者看到請求使用的是HTTP 1.1（HTTP 1.1默認(rèn)進(jìn)行持久連接）,它就可以利用持久連接的優(yōu)點，當(dāng)頁面包含多個元素時（例如Applet，圖片），顯著地減少下載所需要的時間。要實現(xiàn)這一點，服務(wù)器需要在應(yīng)答中發(fā)送一個Content-Length頭，最簡單的實現(xiàn)方法是：先把內(nèi)容寫入 ByteArrayOutputStream，然后在正式寫出內(nèi)容之前計算它的大小；
例如： Connection: keep-alive?? 當(dāng)一個網(wǎng)頁打開完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會關(guān)閉，如果客戶端再次訪問這個服務(wù)器上的??網(wǎng)頁，會繼續(xù)使用這一條已經(jīng)建立的連接
例如：? Connection: close? 代表一個Request完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接會關(guān)閉，??當(dāng)客戶端再次發(fā)送Request，需要重新建立TCP連接。
Host（發(fā)送請求時，該報頭域是必需的）
Host請求報頭域主要用于指定被請求資源的Internet主機(jī)和端口號，它通常從HTTP URL中提取出來的。
eg：http://；localhost/index.html
瀏覽器發(fā)送的請求消息中，就會包含Host請求報頭域，如下：
Host：localhost
此處使用缺省端口號80，若指定了端口號8080，則變成：Host：localhost:8080
Client 頭域
Accept：
作用：瀏覽器可以接受的媒體類型（MIME類型）,
例如：? Accept: text/html ?代表瀏覽器可以接受服務(wù)器回發(fā)的類型為 text/html ?也就是我們常說的html文檔, 如果服務(wù)器無法返回text/html類型的數(shù)據(jù)，服務(wù)器應(yīng)該返回一個406錯誤(non acceptable)。
通配符 * 代表任意類型。例如?Accept: */* ?代表瀏覽器可以處理所有類型，(一般瀏覽器發(fā)給服務(wù)器都是發(fā)這個)
Accept-Encoding：
作用：瀏覽器申明自己接收的編碼方法，通常指定壓縮方法，是否支持壓縮，支持什么壓縮方法（gzip，deflate），（注意：這不是只字符編碼）;
例如： Accept-Encoding: gzip, deflate。Server能夠向支持gzip/deflate的瀏覽器返回經(jīng)gzip或者deflate編碼的HTML頁面。?許多情形下這可以減少5到10倍的下載時間，也節(jié)省帶寬。
Accept-Language：
作用：瀏覽器申明自己接收的語言。?
語言跟字符集的區(qū)別：中文是語言，中文有多種字符集，比如big5，gb2312，gbk等等；
例如： Accept-Language:zh-cn?。如果請求消息中沒有設(shè)置這個報頭域，服務(wù)器假定客戶端對各種語言都可以接受。
User-Agent：
作用：告訴HTTP服務(wù)器，客戶端使用的操作系統(tǒng)和瀏覽器的名稱和版本.
我們上網(wǎng)登陸論壇的時候，往往會看到一些歡迎信息，其中列出了你的操作系統(tǒng)的名稱和版本，你所使用的瀏覽器的名稱和版本，這往往讓很多人感到很神奇，實際上，?服務(wù)器應(yīng)用程序就是從User-Agent這個請求報頭域中獲取到這些信息User-Agent請求報頭域允許客戶端將它的操作系統(tǒng)、瀏覽器和其它屬性告訴服務(wù)器。
例如： User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; CIBA; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; InfoPath.2; .NET4.0E)
Accept-Charset：
作用：瀏覽器申明自己接收的字符集，這就是本文前面介紹的各種字符集和字符編碼，如gb2312，utf-8（通常我們說Charset包括了相應(yīng)的字符編碼方案）；
例如：Accept-Charset:iso-8859-1,gb2312.如果在請求消息中沒有設(shè)置這個域，缺省是任何字符集都可以接受。
Authorization：授權(quán)信息，通常出現(xiàn)在對服務(wù)器發(fā)送的WWW-Authenticate頭的應(yīng)答中；
Authorization請求報頭域主要用于證明客戶端有權(quán)查看某個資源。當(dāng)瀏覽器訪問一個頁面時，如果收到服務(wù)器的響應(yīng)代碼為401（未授權(quán)），可以發(fā)送一個包含Authorization請求報頭域的請求，要求服務(wù)器對其進(jìn)行驗證。
Cookie/Login 頭域
Cookie:
作用：最重要的header, 將cookie的值發(fā)送給HTTP 服務(wù)器
Entity頭域
Content-Length
作用：發(fā)送給HTTP服務(wù)器數(shù)據(jù)的長度。即請求消息正文的長度；
例如： Content-Length: 38
Content-Type：
作用：
例如：Content-Type: application/x-www-form-urlencoded
Miscellaneous 頭域
Referer:
作用：提供了Request的上下文信息的服務(wù)器，告訴服務(wù)器我是從哪個鏈接過來的，比如從我主頁上鏈接到一個朋友那里，?他的服務(wù)器就能夠從HTTP Referer中統(tǒng)計出每天有多少用戶點擊我主頁上的鏈接訪問??? 他的網(wǎng)站。
例如: Referer:http://translate.google.cn/?hl=zh-cn&tab=wT
Cache 頭域
If-Modified-Since：
作用：把瀏覽器端緩存頁面的最后修改時間發(fā)送到服務(wù)器去，服務(wù)器會把這個時間與服務(wù)器上實際文件的最后修改時間進(jìn)行對比。如果時間一致，那么返回304，客戶端就直接使用本地緩存文件。如果時間不一致，就會返回200和新的文件內(nèi)容。客戶端接到之后，會丟棄舊文件，把新文件緩存起來，并顯示在瀏覽器中。
例如：If-Modified-Since: Thu, 09 Feb 2012 09:07:57 GMT。
If-None-Match：
作用: If-None-Match和ETag一起工作，工作原理是在HTTP Response中添加ETag信息。當(dāng)用戶再次請求該資源時，將在HTTP Request 中加入If-None-Match信息(ETag的值)。如果服務(wù)器驗證資源的ETag沒有改變（該資源沒有更新），將返回一個304狀態(tài)告訴客戶端使用本地緩存文件。否則將返回200狀態(tài)和新的資源和Etag.? 使用這樣的機(jī)制將提高網(wǎng)站的性能
例如: If-None-Match: "03f2b33c0bfcc1:0"
Pragma：
作用：防止頁面被緩存，在HTTP/1.1版本中，它和Cache-Control:no-cache作用一模一樣
Pargma只有一個用法，例如： Pragma: no-cache
注意: 在HTTP/1.0版本中，只實現(xiàn)了Pragema:no-cache, 沒有實現(xiàn)Cache-Control
Cache-Control：
作用: 這個是非常重要的規(guī)則。這個用來指定Response-Request遵循的緩存機(jī)制。各個指令含義如下
Cache-Control:Public?? 可以被任何緩存所緩存（）
Cache-Control:Private???? 內(nèi)容只緩存到私有緩存中
Cache-Control:no-cache? 所有內(nèi)容都不會被緩存
2. HTTP響應(yīng)格式??????
????? 在接收和解釋請求消息后，服務(wù)器會返回一個 HTTP 響應(yīng)消息。與 HTTP 請求類似，HTTP 響應(yīng)也是由三個部分組成，分別是：狀態(tài)行、消息報頭和響應(yīng)正文。如：
HTTP/1.1 200 OK
Date: Sun, 17 Mar 2013 08:12:54 GMT
Server: Apache/2.2.8 (Win32) PHP/5.2.5
X-Powered-By: PHP/5.2.5
Set-Cookie: PHPSESSID=c0huq7pdkmm5gg6osoe3mgjmm3; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 4393
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8
?
<html>
<head>
<title>HTTP響應(yīng)示例<title>
</head>
<body>
Hello HTTP!
</body>
</html>
?
1、狀態(tài)行
?????? 狀態(tài)行由協(xié)議版本、數(shù)字形式的狀態(tài)代碼，及相應(yīng)的狀態(tài)描述組成，各元素之間以空格分隔，結(jié)尾時回車換行符，格式如下：
HTTP-Version Status-Code Reason-Phrase CRLF
HTTP-Version 表示服務(wù)器 HTTP 協(xié)議的版本，Status-Code 表示服務(wù)器發(fā)回的響應(yīng)代碼，Reason-Phrase 表示狀態(tài)代碼的文本描述，CRLF 表示回車換行。例如：
HTTP/1.1 200 OK (CRLF)
????? 狀態(tài)代碼與狀態(tài)描述
????? 狀態(tài)代碼由 3 位數(shù)字組成，表示請求是否被理解或被滿足，狀態(tài)描述給出了關(guān)于狀態(tài)碼的簡短的文字描述。狀態(tài)碼的第一個數(shù)字定義了響應(yīng)類別，后面兩位數(shù)字沒有具體分類。第一個數(shù)字有 5 種取值，如下所示。
·???????? 1xx：指示信息——表示請求已經(jīng)接受，繼續(xù)處理
·???????? 2xx：成功——表示請求已經(jīng)被成功接收、理解、接受。
·???????? 3xx：重定向——要完成請求必須進(jìn)行更進(jìn)一步的操作
·???????? 4xx：客戶端錯誤——請求有語法錯誤或請求無法實現(xiàn)
·???????? 5xx：服務(wù)器端錯誤——服務(wù)器未能實現(xiàn)合法的請求。
常見狀態(tài)代碼、狀態(tài)描述、說明：
200 OK????? //客戶端請求成功
400 Bad Request? //客戶端請求有語法錯誤，不能被服務(wù)器所理解
401 Unauthorized //請求未經(jīng)授權(quán)，這個狀態(tài)代碼必須和WWW-Authenticate報頭域一起使用?
403 Forbidden? //服務(wù)器收到請求，但是拒絕提供服務(wù)
404 Not Found? //請求資源不存在，eg：輸入了錯誤的URL
500 Internal Server Error //服務(wù)器發(fā)生不可預(yù)期的錯誤
503 Server Unavailable? //服務(wù)器當(dāng)前不能處理客戶端的請求，一段時間后可能恢復(fù)正常
2、響應(yīng)正文
響應(yīng)正文就是服務(wù)器返回的資源的內(nèi)容，響應(yīng)頭和正文之間也必須用空行分隔。如：
[html] view plaincopyprint?
1.? <html>??
2.? <head>??
3.? <title>HTTP響應(yīng)示例<title>??
4.? </head>??
5.? <body>??
6.? Hello?HTTP!??
7.? </body>??
8.? </html>??
<html>
<head>
<title>HTTP響應(yīng)示例<title>
</head>
<body>
Hello HTTP!
</body>
</html>
3?、響應(yīng)頭信息
HTTP最常見的響應(yīng)頭如下所示：
Cache頭域
Date：
作用：生成消息的具體時間和日期，即當(dāng)前的GMT時間。
例如： Date: Sun, 17 Mar 2013 08:12:54 GMT
Expires：
作用: 瀏覽器會在指定過期時間內(nèi)使用本地緩存，指明應(yīng)該在什么時候認(rèn)為文檔已經(jīng)過期，從而不再緩存它。
例如: Expires: Thu, 19 Nov 1981 08:52:00 GMT
Vary
作用：
例如: Vary: Accept-Encoding
Cookie/Login 頭域
P3P
作用: 用于跨域設(shè)置Cookie, 這樣可以解決iframe跨域訪問cookie的問題
例如: P3P: CP=CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR
Set-Cookie
作用：非常重要的header, 用于把cookie 發(fā)送到客戶端瀏覽器，每一個寫入cookie都會生成一個Set-Cookie.
例如: Set-Cookie: PHPSESSID=c0huq7pdkmm5gg6osoe3mgjmm3; path=/
Entity實體頭域：
??????????? 實體內(nèi)容的屬性，包括實體信息類型，長度，壓縮方法，最后一次修改時間，數(shù)據(jù)有效性等。
ETag：
作用:? 和If-None-Match 配合使用。（實例請看上節(jié)中If-None-Match的實例）
例如: ETag: "03f2b33c0bfcc1:0"
Last-Modified：
作用：用于指示資源的最后修改日期和時間。（實例請看上節(jié)的If-Modified-Since的實例）
例如: Last-Modified: Wed, 21 Dec 2011 09:09:10 GMT
Content-Type：
作用：WEB服務(wù)器告訴瀏覽器自己響應(yīng)的對象的類型和字符集,
例如:
????????Content-Type: text/html; charset=utf-8
Content-Type:text/html;charset=GB2312
Content-Type: image/jpeg
Content-Length：
指明實體正文的長度，以字節(jié)方式存儲的十進(jìn)制數(shù)字來表示。在數(shù)據(jù)下行的過程中，Content-Length的方式要預(yù)先在服務(wù)器中緩存所有數(shù)據(jù)，然后所有數(shù)據(jù)再一股腦兒地發(fā)給客戶端。
例如: Content-Length: 19847
Content-Encoding：
作用：文檔的編碼（Encode）方法。一般是壓縮方式。
WEB服務(wù)器表明自己使用了什么壓縮方法（gzip，deflate）壓縮響應(yīng)中的對象。利用gzip壓縮文檔能夠顯著地減少HTML文檔的下載時間。
例如：Content-Encoding：gzip
Content-Language：
作用： WEB服務(wù)器告訴瀏覽器自己響應(yīng)的對象的語言者
例如： Content-Language:da
Miscellaneous 頭域
Server：
作用：指明HTTP服務(wù)器的軟件信息
例如:Apache/2.2.8 (Win32) PHP/5.2.5
X-Powered-By：
作用：表示網(wǎng)站是用什么技術(shù)開發(fā)的
例如： X-Powered-By: PHP/5.2.5
Transport頭域
Connection：
例如： Connection: keep-alive?? 當(dāng)一個網(wǎng)頁打開完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會關(guān)閉，如果客戶端再次訪問這個服務(wù)器上的網(wǎng)頁，會繼續(xù)使用這一條已經(jīng)建立的連接
例如：? Connection: close? 代表一個Request完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接會關(guān)閉，當(dāng)客戶端再次發(fā)送Request，需要重新建立TCP連接。
Location頭域
Location：
作用：用于重定向一個新的位置，包含新的URL地址
實例請看304狀態(tài)實例
HTTP協(xié)議是無狀態(tài)的和Connection: keep-alive的區(qū)別
無狀態(tài)是指協(xié)議對于事務(wù)處理沒有記憶能力，服務(wù)器不知道客戶端是什么狀態(tài)。從另一方面講，打開一個服務(wù)器上的網(wǎng)頁和你之前打開這個服務(wù)器上的網(wǎng)頁之間沒有任何聯(lián)系。
HTTP是一個無狀態(tài)的面向連接的協(xié)議，無狀態(tài)不代表HTTP不能保持TCP連接，更不能代表HTTP使用的是UDP協(xié)議（無連接）。
從HTTP/1.1起，默認(rèn)都開啟了Keep-Alive，保持連接特性，簡單地說，當(dāng)一個網(wǎng)頁打開完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會關(guān)閉，如果客戶端再次訪問這個服務(wù)器上的網(wǎng)頁，會繼續(xù)使用這一條已經(jīng)建立的連接。
Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務(wù)器軟件（如Apache）中設(shè)定這個時間。
3.?瀏覽器緩存??????
??????????
?????? 瀏覽器緩存：包括頁面html緩存和圖片js，css等資源的緩存。如下圖，瀏覽器緩存是基于把頁面信息保存到用戶本地電腦硬盤里。
???????
?
1、緩存的優(yōu)點：
? ? ?1）服務(wù)器響應(yīng)更快：因為請求從緩存服務(wù)器（離客戶端更近）而不是源服務(wù)器被相應(yīng)，這個過程耗時更少，讓服務(wù)器看上去響應(yīng)更快。
? ? ?2）減少網(wǎng)絡(luò)帶寬消耗：當(dāng)副本被重用時會減低客戶端的帶寬消耗；客戶可以節(jié)省帶寬費用，控制帶寬的需求的增長并更易于管理。
1、緩存工作原理
????? ?頁面緩存狀態(tài)是由http header決定的，一個瀏覽器請求信息，一個是服務(wù)器響應(yīng)信息。主要包括Pragma: no-cache、Cache-Control、 Expires、 Last-Modified、If-Modified-Since。其中Pragma: no-cache由HTTP/1.0規(guī)定，Cache-Control由HTTP/1.1規(guī)定。
?????? 工作原理圖：
?
從圖中我們可以看到原理主要分三步：
1.??? 第一次請求：瀏覽器通過http的header報頭，附帶Expires，Cache-Control，Last-Modified/Etag向服務(wù)器請求，此時服務(wù)器記錄第一次請求的Last-Modified/Etag ? ? ? ? ? ? ? ? ?
2.??? 再次請求：當(dāng)瀏覽器再次請求的時候，請求頭附帶Expires，Cache-Control，If-Modified-Since/Etag向服務(wù)器請求
3.??? 服務(wù)器根據(jù)第一次記錄的Last-Modified/Etag和再次請求的If-Modified-Since/Etag做對比，判斷是否需要更新，服務(wù)器通過這兩個頭判斷本地資源未發(fā)生變化，客戶端不需要重新下載，返回304響應(yīng)。常見流程如下圖所示：
?
?
與緩存相關(guān)的HTTP擴(kuò)展消息頭
? ??Expires：設(shè)置頁面過期時間，格林威治時間GMT
? ? Cache-Control：更細(xì)致的控制緩存的內(nèi)容
? ??Last-Modified：請求對象最后一次的修改時間用來判斷緩存是否過期通常由文件的時間信息產(chǎn)生?
? ? ETag：響應(yīng)中資源的校驗值，在服務(wù)器上某個時段是唯一標(biāo)識的。ETag是一個可以與Web資源關(guān)聯(lián)的記號（token），和Last-Modified功能才不多，也是一個標(biāo)識符，一般和Last-Modified一起使用，加強服務(wù)器判斷的準(zhǔn)確度。
? ? Date：服務(wù)器的時間
? ? If-Modified-Since：客戶端存取的該資源最后一次修改的時間，用來和服務(wù)器端的Last-Modified做比較
? ? If-None-Match：客戶端存取的該資源的檢驗值，同ETag。
Cache-Control的主要參數(shù)
? ? ? Cache-Control: private/public Public 響應(yīng)會被緩存，并且在多用戶間共享。 Private 響應(yīng)只能夠作為私有的緩存，不能再用戶間共享。
? ? ? Cache-Control: no-cache：不進(jìn)行緩存
? ? ? Cache-Control: max-age=x：緩存時間以秒為單位
? ? ? Cache-Control: must-revalidate：如果頁面是過期的則去服務(wù)器進(jìn)行獲取。
?
2、關(guān)于圖片，css，js，flash的緩存
這個主要通過服務(wù)器的配置來實現(xiàn)這個技術(shù)，如果使用apache服務(wù)器的話，可以使用mod_expires模塊來實現(xiàn)：
編譯mod_expires模塊：
Cd? /root/httpd-2.2.3/modules/metadata
/usr/local/apache/bin/apxs -i -a -c mod_expires.c //編譯
編輯httpd.conf配置：添加下面內(nèi)容
<IfModule mod_expires.c>
ExpiresActive on
ExpiresDefault "access plus 1 month"
ExpiresByType text/html "access plus 1 months"
ExpiresByType text/css "access plus 1 months"
ExpiresByType image/gif "access plus 1 months"
ExpiresByType image/jpeg "access plus 1 months"
ExpiresByType image/jpg "access plus 1 months"
ExpiresByType image/png "access plus 1 months"
EXpiresByType application/x-shockwave-flash "access plus 1 months"
EXpiresByType application/x-javascript????? "access plus 1 months"
#ExpiresByType video/x-flv "access plus 1 months"
</IfModule>
解釋：第一句--開啟服務(wù)
第二句--默認(rèn)時間是一個月
在下面是關(guān)于各種類型的資源的緩存時間設(shè)置
?
（緩存的部分修改自http://www.cnblogs.com/phphuaibei/archive/2011/09/27/2192817.html）
?
http://blog.csdn.net/hguisu/article/details/8608888
?
?
翻了下HTTP1.1的協(xié)議標(biāo)準(zhǔn)RFC2616，下面是看到的一些它跟HTTP1.0的差別。
1. Persistent Connection持久連接
?????? 在HTTP1.0中，每對Request/Response都使用一個新的連接。
??????? HTTP 1.1則支持持久連接Persistent Connection, 并且默認(rèn)使用persistent? connection. 在同一個tcp的連接中可以傳送多個HTTP請求和響應(yīng). 多個請求和響應(yīng)可以重疊，多個請求和響應(yīng)可以同時進(jìn)行. 更加多的請求頭和響應(yīng)頭(比如HTTP1.0沒有host的字段).
??????? HTTP 1.1的持續(xù)連接，也需要增加新的請求頭來幫助實現(xiàn)，例如，Connection請求頭的值為Keep-Alive時，客戶端通知服務(wù)器返回本次請求結(jié)果后保持連接；Connection請求頭的值為close時，客戶端通知服務(wù)器返回本次請求結(jié)果后關(guān)閉連接。HTTP 1.1還提供了與身份認(rèn)證、狀態(tài)管理和Cache緩存等機(jī)制相關(guān)的請求頭和響應(yīng)頭。
??????? HTTP 1.0規(guī)定瀏覽器與服務(wù)器只保持短暫的連接，瀏覽器的每次請求都需要與服務(wù)器建立一個TCP連接，服務(wù)器完成請求處理后立即斷開TCP連接，服務(wù)器不跟蹤每個客戶也不記錄過去的請求。此外，由于大多數(shù)網(wǎng)頁的流量都比較小，一次TCP連接很少能通過slow-start區(qū)，不利于提高帶寬利用率。
??????? 在1.0時的會話方式：
?????? 1. 建立連接
?????? 2. 發(fā)出請求信息
?????? 3. 回送響應(yīng)信息
?????? 4. 關(guān)掉連接
?????? 小結(jié):瀏覽器和web服務(wù)器連接很短，每次連接只處理一個請求和響應(yīng)。對每一個頁的請求,瀏覽器與web服務(wù)器都要建立一次單獨的連接.瀏覽器沒有 關(guān)掉前,連接就斷開了.瀏覽器和服務(wù)器之間的通信是完全獨立分開的請求和響應(yīng)對.因為這樣沒法斷點瀏覽器是否斷開,沒法做連接狀態(tài)控制。建立和關(guān)掉連接會很占用連接時間.
????? 在一個網(wǎng)頁中,在http頭中的Connection中有多少個close的頭,就相當(dāng)有多少個http的連接.
?
????? HTTP 1.1支持長連接（PersistentConnection）和請求的流水線（Pipelining）處理，在一個TCP連接上可以傳送多個HTTP請求和響應(yīng)，減少了建立和關(guān)閉連接的消耗和延遲。例如：一個包含有許多圖像的網(wǎng)頁文件的多個請求和應(yīng)答可以在一個連接中傳輸，但每個單獨的網(wǎng)頁文件的請求和應(yīng)答仍然需要使用各自的連接。
?????? HTTP 1.1還允許客戶端不用等待上一次請求結(jié)果返回，就可以發(fā)出下一次請求，但服務(wù)器端必須按照接收到客戶端請求的先后順序依次回送響應(yīng)結(jié)果，以保證客戶端能夠區(qū)分出每次請求的響應(yīng)內(nèi)容，這樣也顯著地減少了整個下載過程所需要的時間。
?????? 在HTTP/1.0中，要建立長連接，可以在請求消息中包含Connection: Keep-Alive頭域，如果服務(wù)器愿意維持這條連接，在響應(yīng)消息中也會包含一個Connection: Keep-Alive的頭域。同時，可以加入一些指令描述該長連接的屬性，如max，timeout等。
?????? 事實上，Connection頭域可以攜帶三種不同類型的符號：
?????? 1、一個包含若干個頭域名的列表，聲明僅限于一次hop連接的頭域信息；
?????? 2、任意值，本次連接的非標(biāo)準(zhǔn)選項，如Keep-Alive等；
??????? 3、close值，表示消息傳送完成之后關(guān)閉長連接；
?
??????? 客戶端和源服務(wù)器之間的消息傳遞可能要經(jīng)過很多中間節(jié)點的轉(zhuǎn)發(fā)，這是一種逐跳傳遞（hop-by-hop）。HTTP/1.1相應(yīng)地引入了hop-by-hop頭域，這種頭域僅作用于一次hop，而非整個傳遞路徑。每一個中間節(jié)點（如Proxy，Gateway）接收到的消息中如果包含Connection頭域，會查找Connection頭域中的一個頭域名列表，并在將消息轉(zhuǎn)發(fā)給下一個節(jié)點之前先刪除消息中這些頭域。
??????? 通常，HTTP/1.0的Proxy不支持Connection頭域，為了不讓它們轉(zhuǎn)發(fā)可能誤導(dǎo)接收者的頭域，協(xié)議規(guī)定所有出現(xiàn)在Connection頭域中的頭域名都將被忽略。
2. Host域
?????? 在HTTP1.0中認(rèn)為每臺服務(wù)器都綁定一個唯一的IP地址，因此，請求消息中的URL并沒有傳遞主機(jī)名（hostname）。但隨著虛擬主機(jī)技術(shù)的發(fā)展，在一臺物理服務(wù)器上可以存在多個虛擬主機(jī)（Multi-homed Web Servers），并且它們共享一個IP地址。
??????? HTTP1.1的請求消息和響應(yīng)消息都應(yīng)支持Host頭域，且請求消息中如果沒有Host頭域會報告一個錯誤（400 Bad Request）。此外，服務(wù)器應(yīng)該接受以絕對路徑標(biāo)記的資源請求。
??????? HTTP1.1在Request消息頭里頭多了一個Host域，比如：
????? ?GET /pub/WWW/TheProject.html HTTP/1.1
?????? Host: www.w3.org
?? ?? ?HTTP1.0則沒有這個域。
?? ??? 可能HTTP1.0的時候認(rèn)為，建立TCP連接的時候已經(jīng)指定了IP地址，這個IP地址上只有一個host。
? ???? 由于HTTP 1.0不支持Host請求頭字段，WEB瀏覽器無法使用主機(jī)頭名來明確表示要訪問服務(wù)器上的哪個WEB站點，這樣就無法使用WEB服務(wù)器在同一個IP地址和端口號上配置多個虛擬WEB站點。在HTTP 1.1中增加Host請求頭字段后，WEB瀏覽器可以使用主機(jī)頭名來明確表示要訪問服務(wù)器上的哪個WEB站點，這才實現(xiàn)了在一臺WEB服務(wù)器上可以在同一個IP地址和端口號上使用不同的主機(jī)名來創(chuàng)建多個虛擬WEB站點。
?
3. date/timestamp (日期時間戳)
(接收方向)
無論是HTTP1.0還是HTTP1.1，都要能解析下面三種date/time stamp：
????? Sun, 06 Nov 1994 08:49:37GMT? ; RFC 822, updated by RFC 1123
????? Sunday, 06-Nov-94 08:49:37GMT ; RFC 850, obsoleted by RFC 1036
????? Sun Nov? 6 08:49:371994?????? ; ANSI C's asctime() format
(發(fā)送方向)
???HTTP1.0要求不能生成第三種asctime格式的date/time stamp；
??? HTTP1.1則要求只生成RFC 1123(第一種)格式的date/time stamp。
4. Transfer Codings
HTTP1.1支持chunked transfer，所以可以有Transfer-Encoding頭部域:
Transfer-Encoding:chunked
?HTTP1.0則沒有。
HTTP消息中可以包含任意長度的實體，通常它們使用Content-Length來給出消息結(jié)束標(biāo)志。但是，對于很多動態(tài)產(chǎn)生的響應(yīng)，只能通過緩沖完整的消息來判斷消息的大小，但這樣做會加大延遲。如果不使用長連接，還可以通過連接關(guān)閉的信號來判定一個消息的結(jié)束。
HTTP/1.1中引入了Chunked transfer-coding來解決上面這個問題，發(fā)送方將消息分割成若干個任意大小的數(shù)據(jù)塊，每個數(shù)據(jù)塊在發(fā)送時都會附上塊的長度，最后用一個零長度的塊作為消息結(jié)束的標(biāo)志。這種方法允許發(fā)送方只緩沖消息的一個片段，避免緩沖整個消息帶來的過載。
在HTTP/1.0中，有一個Content-MD5的頭域，要計算這個頭域需要發(fā)送方緩沖完整個消息后才能進(jìn)行。而HTTP/1.1中，采用chunked分塊傳遞的消息在最后一個塊（零長度）結(jié)束之后會再傳遞一個拖尾（trailer），它包含一個或多個頭域，這些頭域是發(fā)送方在傳遞完所有塊之后再計算出值的。發(fā)送方會在消息中包含一個Trailer頭域告訴接收方這個拖尾的存在。
5. Quality Values
?HTTP1.1多了個qvalue域：
??????qvalue???????? = ( "0" ["." 0*3DIGIT ] )
?????????????????????| ( "1" [ "." 0*3("0") ] )
?
6. Entity Tags
用于Cache。
?
7. Range 和 Content-Range(節(jié)約優(yōu)化)
?????? HTTP1.1支持傳送內(nèi)容的一部分。比方說，當(dāng)客戶端已經(jīng)有內(nèi)容的一部分，為了節(jié)省帶寬，可以只向服務(wù)器請求一部分。
??????? HTTP/1.0中，存在一些浪費帶寬的現(xiàn)象，例如客戶端只是需要某個對象的一部分，而服務(wù)器卻將整個對象送過來了。例如，客戶端只需要顯示一個文檔的部分內(nèi)容，又比如下載大文件時需要支持?jǐn)帱c續(xù)傳功能，而不是在發(fā)生斷連后不得不重新下載完整的包。
??????? HTTP/1.1中在請求消息中引入了range頭域，它允許只請求資源的某個部分。在響應(yīng)消息中Content-Range頭域聲明了返回的這部分對象的偏移值和長度。如果服務(wù)器相應(yīng)地返回了對象所請求范圍的內(nèi)容，則響應(yīng)碼為206（Partial Content），它可以防止Cache將響應(yīng)誤以為是完整的一個對象。
??????
?????? 節(jié)省帶寬資源的一個非常有效的做法就是壓縮要傳送的數(shù)據(jù)。Content-Encoding是對消息進(jìn)行端到端（end-to-end）的編碼，它可能是資源在服務(wù)器上保存的固有格式（如jpeg圖片格式）；在請求消息中加入Accept-Encoding頭域，它可以告訴服務(wù)器客戶端能夠解碼的編碼方式。
?????? 而Transfer-Encoding是逐段式（hop-by-hop）的編碼，如Chunked編碼。在請求消息中加入TE頭域用來告訴服務(wù)器能夠接收的transfer-coding方式，
8. 100(Continue) Status(節(jié)約帶寬)
?????? 另外一種浪費帶寬的情況是請求消息中如果包含比較大的實體內(nèi)容，但不確定服務(wù)器是否能夠接收該請求（如是否有權(quán)限），此時若貿(mào)然發(fā)出帶實體的請求，如果被拒絕也會浪費帶寬。
??????? HTTP/1.1加入了一個新的狀態(tài)碼100（Continue）。客戶端事先發(fā)送一個只帶頭域的請求，如果服務(wù)器因為權(quán)限拒絕了請求，就回送響應(yīng)碼401（Unauthorized）；如果服務(wù)器接收此請求就回送響應(yīng)碼100，客戶端就可以繼續(xù)發(fā)送帶實體的完整請求了。注意，HTTP/1.0的客戶端不支持100響應(yīng)碼。但可以讓客戶端在請求消息中加入Expect頭域，并將它的值設(shè)置為100-continue。
????? 100 (Continue) 狀態(tài)代碼的使用，允許客戶端在發(fā)request消息body之前先用request header試探一下server，看server要不要接收request body，再決定要不要發(fā)request body。
客戶端在Request頭部中包含
Expect: 100-continue
Server看到之后呢如果回100 (Continue) 這個狀態(tài)代碼，客戶端就繼續(xù)發(fā)requestbody。
這個是HTTP1.1才有的。
9. Request method
???? HTTP1.1增加了OPTIONS,PUT, DELETE, TRACE, CONNECT這些Request方法.
??????Method???="OPTIONS"???????????????;Section 9.2
?????????????????????|"GET"???????????????????; Section 9.3
?????????????????????|"HEAD"??????????????????; Section 9.4
?????????????????????|"POST"??????????????????; Section 9.5
?????????????????????| "PUT"???????????????????;Section 9.6
?????????????????????| "DELETE"????????????????;Section 9.7
?????????????????????|"TRACE"?????????????????; Section 9.8
?????????????????????| "CONNECT"???????????????;Section 9.9
?????????????????????| extension-method
?????? extension-method =token
10. Status code
? HTTP1.1 增加的新的status code：
?
(HTTP1.0沒有定義任何具體的1xx status code, HTTP1.1有2個)
100 Continue
101 Switching Protocols
?
203 Non-Authoritative Information
205 Reset Content
206 Partial Content
?
302 Found (在HTTP1.0中有個 302 Moved Temporarily)
303 See Other
305 Use Proxy
307 Temporary Redirect
?
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
409 Conflict
410 Gone
411 Length Required
412 Precondition Failed
413 Request Entity Too Large
414 Request-URI Too Long
415 Unsupported Media Type
416 Requested Range Not Satisfiable
417 Expectation Failed
?
504 Gateway Timeout
505 HTTP Version Not Supported
11. Cache (緩存)
?????? 在HTTP/1.0中，使用Expire頭域來判斷資源的fresh或stale，并使用條件請求（conditional request）來判斷資源是否仍有效。例如，cache服務(wù)器通過If-Modified-Since頭域向服務(wù)器驗證資源的Last-Modefied頭域是否有更新，源服務(wù)器可能返回304（Not Modified），則表明該對象仍有效；也可能返回200（OK）替換請求的Cache對象。
此外，HTTP/1.0中還定義了Pragma:no-cache頭域，客戶端使用該頭域說明請求資源不能從cache中獲取，而必須回源獲取。
HTTP/1.1在1.0的基礎(chǔ)上加入了一些cache的新特性，當(dāng)緩存對象的Age超過Expire時變?yōu)閟tale對象，cache不需要直接拋棄stale對象，而是與源服務(wù)器進(jìn)行重新激活（revalidation）。
HTTP/1.0中，If-Modified-Since頭域使用的是絕對時間戳，精確到秒，但使用絕對時間會帶來不同機(jī)器上的時鐘同步問題。而HTTP/1.1中引入了一個ETag頭域用于重激活機(jī)制，它的值entity tag可以用來唯一的描述一個資源。請求消息中可以使用If-None-Match頭域來匹配資源的entitytag是否有變化。
為了使caching機(jī)制更加靈活，HTTP/1.1增加了Cache-Control頭域（請求消息和響應(yīng)消息都可使用），它支持一個可擴(kuò)展的指令子集：例如max-age指令支持相對時間戳；private和no-store指令禁止對象被緩存；no-transform阻止Proxy進(jìn)行任何改變響應(yīng)的行為。
Cache使用關(guān)鍵字索引在磁盤中緩存的對象，在HTTP/1.0中使用資源的URL作為關(guān)鍵字。但可能存在不同的資源基于同一個URL的情況，要區(qū)別它們還需要客戶端提供更多的信息，如Accept-Language和Accept-Charset頭域。為了支持這種內(nèi)容協(xié)商機(jī)制(content negotiation mechanism)，HTTP/1.1在響應(yīng)消息中引入了Vary頭域，該頭域列出了請求消息中需要包含哪些頭域用于內(nèi)容協(xié)商。
依據(jù)：
rfc2616Hypertext Transfer Protocol -- HTTP-1.1.txt
rfc1945Hypertext Transfer Protocol -- HTTP 1.0.txt
求消息中需要包含哪些頭域用于內(nèi)容協(xié)商。
HTTP 1.1持久連接的好處
??????? 一個WEB站點每天可能要接收到上百萬的用戶請求，為了提高系統(tǒng)的效率，HTTP 1.0規(guī)定瀏覽器與服務(wù)器只保持短暫的連接，瀏覽器的每次請求都需要與服務(wù)器建立一個TCP連接，服務(wù)器完成請求處理后立即斷開TCP連接，服務(wù)器不跟蹤每個客戶也不記錄過去的請求。但是，這也造成了一些性能上的缺陷，例如，一個包含有許多圖像的網(wǎng)頁文件中并沒有包含真正的圖像數(shù)據(jù)內(nèi)容，而只是指明了這些圖像的URL地址，當(dāng)WEB瀏覽器訪問這個網(wǎng)頁文件時，瀏覽器首先要發(fā)出針對該網(wǎng)頁文件的請求，當(dāng)瀏覽器解析WEB服務(wù)器返回的該網(wǎng)頁文檔中的HTML內(nèi)容時，發(fā)現(xiàn)其中的<img>圖像標(biāo)簽后，瀏覽器將根據(jù)<img>標(biāo)簽中的src屬性所指定的URL地址再次向服務(wù)器發(fā)出下載圖像數(shù)據(jù)的請求，如圖3.3所示。
?????????????????
?
圖3.3
????? 顯然，訪問一個包含有許多圖像的網(wǎng)頁文件的整個過程包含了多次請求和響應(yīng)，每次請求和響應(yīng)都需要建立一個單獨的連接，每次連接只是傳輸一個文檔和圖像，上一 次和下一次請求完全分離。即使圖像文件都很小，但是客戶端和服務(wù)器端每次建立和關(guān)閉連接卻是一個相對比較費時的過程，并且會嚴(yán)重影響客戶機(jī)和服務(wù)器的性 能。當(dāng)一個網(wǎng)頁文件中包含Applet，JavaScript文件，CSS文件等內(nèi)容時，也會出現(xiàn)類似上述的情況。
??????? 為了克服HTTP 1.0的這個缺陷，HTTP1.1支持持久連接，在一個TCP連接上可以傳送多個HTTP請求和響應(yīng)，減少了建立和關(guān)閉連接的消耗和延遲。一個包含有許多圖像的網(wǎng)頁文件的多個請求和應(yīng)答可以在一個連接中傳輸，但每個單獨的網(wǎng)頁文件的請求和應(yīng)答仍然需要使用各自的連接。HTTP 1.1還允許客戶端不用等待上一次請求結(jié)果返回，就可以發(fā)出下一次請求，但服務(wù)器端必須按照接收到客戶端請求的先后順序依次回送響應(yīng)結(jié)果，以保證客戶端能夠區(qū)分出每次請求的響應(yīng)內(nèi)容，這樣也顯著地減少了整個下載過程所需要的時間。基于HTTP 1.1協(xié)議的客戶機(jī)與服務(wù)器的信息交換過程，如圖3.4所示。
?????????
圖3.4
??????? 可見，HTTP 1.1在繼承了HTTP 1.0優(yōu)點的基礎(chǔ)上，也克服了HTTP 1.0的性能問題。不僅如此，HTTP 1.1還通過增加更多的請求頭和響應(yīng)頭來改進(jìn)和擴(kuò)充HTTP1.0的功能。例如，由于HTTP 1.0不支持Host請求頭字段，WEB瀏覽器無法使用主機(jī)頭名來明確表示要訪問服務(wù)器上的哪個WEB站點，這樣就無法使用WEB服務(wù)器在同一個IP地址和端口號上配置多個虛擬WEB站點。在HTTP 1.1中增加Host請求頭字段后，WEB瀏覽器可以使用主機(jī)頭名來明確表示要訪問服務(wù)器上的哪個WEB站點，這才實現(xiàn)了在一臺WEB服務(wù)器上可以在同一個IP地址和端口號上使用不同的主機(jī)名來創(chuàng)建多個虛擬WEB站點。HTTP 1.1的持續(xù)連接，也需要增加新的請求頭來幫助實現(xiàn)，例如，Connection請求頭的值為Keep-Alive時，客戶端通知服務(wù)器返回本次請求結(jié)果后保持連接；Connection請求頭的值為close時，客戶端通知服務(wù)器返回本次請求結(jié)果后關(guān)閉連接。HTTP 1.1還提供了與身份認(rèn)證、狀態(tài)管理和Cache緩存等機(jī)制相關(guān)的請求頭和響應(yīng)頭。
?
?
?
?
?
?
總結(jié)
以上是生活随笔為你收集整理的HTTP详解-工作原理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Facade与Mediator模式的区别
- 下一篇： 安全套接层Secure Sockets