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