淺析 HTTP 協議
HTTP 協議是什么？
簡單來說，就是一個基于應用層 的通信規范：雙方要進行通信，大家都要遵守一個規范，這個規范就是 HTTP 協議。
HTTP 協議能做什么？
很多人首先一定會想到：瀏覽網頁。沒錯，瀏覽網頁是 HTTP 的主要應用，但是這并不代表 HTTP 就只能應用于網頁的瀏覽。 HTTP 是一種協議，只要通信的雙方都遵守這個協議， HTTP 就能有用武之地。比如咱們常用的 QQ ，迅雷這些軟件，都會使用 HTTP 協議(還包括其他的協議)。
HTTP 協議如何工作？
大家都知道一般的通信流程：首先客戶端發送一個請求 (request) 給服務器，服務器在接收到這個請求后將生成一個響應 (response) 返回給客戶端。
在這個通信的過程中 HTTP 協議在以下 4 個方面做了規定：
1. ???????? Request 和 Response 的格式
Request 格式：
HTTP
請求行
（請求）頭
空行
可選的消息體
注：請求行和標題必須以 <CR><LF> 作為結尾（也就是，回車然后換行）。空行內必須只有 <CR><LF> 而無其他空格。在 HTTP/1.1 協議中，所有的請求頭，除 Host 外，都是可選的。
?
實例：
GET / HTTP/1.1
Host: gpcuster.cnblogs.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
If-Modified-Since: Mon, 25 May 2009 03:19:18 GMT
Response 格式：
HTTP
狀態行
（應答）頭
空行
可選的消息體
?
實例：
HTTP/1.1 200 OK
Cache-Control: private, max-age=30
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Expires: Mon, 25 May 2009 03:20:33 GMT
Last-Modified: Mon, 25 May 2009 03:20:03 GMT
Vary: Accept-Encoding
Server: Microsoft-IIS/7.0
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Date: Mon, 25 May 2009 03:20:02 GMT
Content-Length: 12173
?
- 消息體的內容（略）
?
?????? 詳細的信息請參考： RFC 2616 。
?????? 關于 HTTP headers 的簡要介紹，請查看： Quick reference to HTTP headers
2. ???????? 建立連接的方式
HTTP 支持 2 中建立連接的方式：非持久連接和持久連接 (HTTP1.1 默認的連接方式為持久連接 ) 。
1) ???????? 非持久連接
讓我們查看一下非持久連接情況下從服務器到客戶傳送一個Web頁面的步驟。假設該貝面由1個基本HTML文件和10個JPEG圖像構成，而且所有這些對象都存放在同一臺服務器主機中。再假設該基本HTML文件的URL為：gpcuster.cnblogs.com/index.html。
下面是具體步騾:
1.HTTP 客戶初始化一個與服務器主機 gpcuster.cnblogs.com 中的HTTP服務器的TCP連接。HTTP服務器使用默認端口號80監聽來自HTTP客戶的連接建立請求。
2.HTTP 客戶經由與TCP連接相關聯的本地套接字發出—個HTTP請求消息。這個消息中包含路徑名/somepath/index.html。
3.HTTP 服務器經由與TCP連接相關聯的本地套接字接收這個請求消息，再從服務器主機的內存或硬盤中取出對象/somepath/index.html，經由同一個套接字發出包含該對象的響應消息。
4.HTTP 服務器告知TCP關閉這個TCP連接(不過TCP要到客戶收到剛才這個響應消息之后才會真正終止這個連接)。
5.HTTP 客戶經由同一個套接字接收這個響應消息。TCP連接隨后終止。該消息標明所封裝的對象是一個HTML文件。客戶從中取出這個文件，加以分析后發現其中有10個JPEG對象的引用。
6. 給每一個引用到的JPEG對象重復步騾1-4。
上述步驟之所以稱為使用非持久連接，原因是每次服務器發出一個對象后，相應的TCP連接就被關閉，也就是說每個連接都沒有持續到可用于傳送其他對象。每個TCP連接只用于傳輸一個請求消息和一個響應消息。就上述例子而言，用戶每請求一次那個web頁面，就產生11個TCP連接。
2) ???????? 持久連接
非持久連接有些缺點。首先，客戶得為每個待請求的對象建立并維護一個新的連接。對于每個這樣的連接， TCP 得在客戶端和服務器端分配 TCP 緩沖區，并維持 TCP 變量。對于有可能同時為來自數百個不同客戶的請求提供服務的 web 服務器來說，這會嚴重增加其負擔。其次，如前所述，每個對象都有 2 個 RTT 的響應延長——一個 RTT 用于建立 TCP 連接，另—個 RTT 用于請求和接收對象。最后，每個對象都遭受 TCP 緩啟動，因為每個 TCP 連接都起始于緩啟動階段。不過并行 TCP 連接的使用能夠部分減輕 RTT 延遲和緩啟動延遲的影響。
在持久連接情況下，服務器在發出響應后讓 TCP 連接繼續打開著。同一對客戶 / 服務器之間的后續請求和響應可以通過這個連接發送。整個 Web 頁面 ( 上例中為包含一個基本 HTMLL 文件和 10 個圖像的頁面 ) 自不用說可以通過單個持久 TCP 連接發送 : 甚至存放在同一個服務器中的多個 web 頁面也可以通過單個持久 TCP 連接發送。通常， HTTP 服務器在某個連接閑置一段特定時間后關閉它，而這段時間通常是可以配置的。持久連接分為不帶流水線 (without pipelining) 和帶流水線 (with pipelining) 兩個版本。如果是不帶流水線的版本，那么客戶只在收到前一個請求的響應后才發出新的請求。這種情況下， web 頁面所引用的每個對象 ( 上例中的 10 個圖像 ) 都經歷 1 個 RTT 的延遲，用于請求和接收該對象。與非持久連接 2 個 RTT 的延遲相比，不帶流水線的持久連接已有所改善，不過帶流水線的持久連接還能進一步降低響應延遲。不帶流水線版本的另一個缺點是，服務器送出一個對象后開始等待下一個請求，而這個新請求卻不能馬上到達。這段時間服務器資源便閑置了。
HTTP/1.1 的默認模式使用帶流水線的持久連接。這種情況下， HTTP 客戶每碰到一個引用就立即發出一個請求，因而 HTTP 客戶可以一個接一個緊挨著發出各個引用對象的請求。服務器收到這些請求后，也可以一個接一個緊挨著發出各個對象。如果所有的請求和響應都是緊挨著發送的，那么所有引用到的對象一共只經歷 1 個 RTT 的延遲 ( 而不是像不帶流水線的版本那樣，每個引用到的對象都各有 1 個 RTT 的延遲 ) 。另外，帶流水線的持久連接中服務器空等請求的時間比較少。與非持久連接相比，持久連接 ( 不論是否帶流水線 ) 除降低了 1 個 RTT 的響應延遲外，緩啟動延遲也比較小。其原因在于既然各個對象使用同一個 TCP 連接，服務器發出第一個對象后就不必再以一開始的緩慢速率發送后續對象。相反，服務器可以按照第一個對象發送完畢時的速率開始發送下一個對象。
3. ???????? 緩存的機制
HTTP/1.1 中緩存的目的是為了在很多情況下減少發送請求，同時在許多情況下可以不需要發送完整響應。前者減少了網絡回路的數量； HTTP 利用一個“過期（ expiration ）”機制來為此目的。后者減少了網絡應用的帶寬； HTTP 用“驗證（ validation ）”機制來為此目的。
HTTP 定義了 3 種緩存機制：
l Freshness allows a response to be used without re-checking it on the origin server, and can be controlled by both the server and the client. For example, the Expires response header gives a date when the document becomes stale, and the Cache-Control: max-age directive tells the cache how many seconds the response is fresh for.
l Validation can be used to check whether a cached response is still good after it becomes stale. For example, if the response has a Last-Modified header, a cache can make a conditional request using the If-Modified-Since header to see if it has changed.
l Invalidation is usually a side effect of another request that passes through the cache. For example, if URL associated with a cached response subsequently gets a POST, PUT or DELETE request, the cached response will be invalidated.
關于 web 緩存方面的內容可以參考： Caching Tutorial for Web Authors and Webmasters （ 英文版 ）（ 中文版 ）
4. ???????? 響應授權激發機制
這些機制能被用于服務器激發客戶端請求并且使客戶端授權。
詳細的信息請參考： RFC 2617: HTTP Authentication: Basic and Digest Access
5. ??????? 基于HTTP的應用
1 HTTP代理
3 HTTPS傳輸協議原理
對稱加密：密鑰只有一個，加密解密為同一個密碼，且加解密速度快，典型的對稱加密算法有DES、AES等
非對稱加密：密鑰成對出現（且根據公鑰無法推知私鑰，根據私鑰也無法推知公鑰），加密解密使用不同密鑰（公鑰加密需要私鑰解密，私鑰加密需要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密算法有RSA、DSA等
?
4 開發web程序時常用的Request Methods
（Head方法）要求響應與相應的GET請求的響應一樣，但是沒有的響應體（response body）。這用來獲得響應頭（response header）中的元數據信息（meta-infomation）有（很）幫助，（因為）它不需要傳輸所有的內容。
（Trace方法告訴服務器端）返回收到的請求。客戶端可以（通過此方法）察看在請求過程中中間服務器添加或者改變哪些內容。
6 基于Socket編程編寫遵循HTTP的程序
?
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
