HTTP協(xié)議是什么？

簡單來說，就是一個基于應(yīng)用層的通信規(guī)范：雙方要進行通信，大家都要遵守一個規(guī)范，這個規(guī)范就是HTTP協(xié)議。

HTTP協(xié)議能做什么？

很多人首先一定會想到：瀏覽網(wǎng)頁。沒錯，瀏覽網(wǎng)頁是HTTP的主要應(yīng)用，但是這并不代表HTTP就只能應(yīng)用于網(wǎng)頁的瀏覽。HTTP是一種協(xié)議，只要通信的雙方都遵守這個協(xié)議，HTTP就能有用武之地。比如咱們常用的QQ，迅雷這些軟件，都會使用HTTP協(xié)議(還包括其他的協(xié)議)。

HTTP協(xié)議如何工作？

大家都知道一般的通信流程：首先客戶端發(fā)送一個請求(request)給服務(wù)器，服務(wù)器在接收到這個請求后將生成一個響應(yīng)(response)返回給客戶端。

在這個通信的過程中HTTP協(xié)議在以下4個方面做了規(guī)定：

1.         Request和Response的格式

Request格式：

HTTP請求行
（請求）頭
空行
可選的消息體

注：請求行和標題必須以<CR><LF> 作為結(jié)尾（也就是，回車然后換行）。空行內(nèi)必須只有<CR><LF>而無其他空格。在HTTP/1.1 協(xié)議中，所有的請求頭，除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狀態(tài)行
（應(yīng)答）頭
空行
可選的消息體

 

實例：

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

 

­消息體的內(nèi)容（略）

 

       詳細的信息請參考：RFC 2616。

       關(guān)于HTTP headers的簡要介紹，請查看：Quick reference to HTTP headers

2.         建立連接的方式

HTTP支持2中建立連接的方式：非持久連接和持久連接(HTTP1.1默認的連接方式為持久連接)。

1)         非持久連接

讓我們查看一下非持久連接情況下從服務(wù)器到客戶傳送一個Web頁面的步驟。假設(shè)該貝面由1個基本HTML文件和10個JPEG圖像構(gòu)成，而且所有這些對象都存放在同一臺服務(wù)器主機中。再假設(shè)該基本HTML文件的URL為：gpcuster.cnblogs.com/index.html。

下面是具體步騾:

1.HTTP客戶初始化一個與服務(wù)器主機gpcuster.cnblogs.com中的HTTP服務(wù)器的TCP連接。HTTP服務(wù)器使用默認端口號80監(jiān)聽來自HTTP客戶的連接建立請求。

2.HTTP客戶經(jīng)由與TCP連接相關(guān)聯(lián)的本地套接字發(fā)出—個HTTP請求消息。這個消息中包含路徑名/somepath/index.html。

3.HTTP服務(wù)器經(jīng)由與TCP連接相關(guān)聯(lián)的本地套接字接收這個請求消息，再從服務(wù)器主機的內(nèi)存或硬盤中取出對象/somepath/index.html，經(jīng)由同一個套接字發(fā)出包含該對象的響應(yīng)消息。

4.HTTP服務(wù)器告知TCP關(guān)閉這個TCP連接(不過TCP要到客戶收到剛才這個響應(yīng)消息之后才會真正終止這個連接)。

5.HTTP客戶經(jīng)由同一個套接字接收這個響應(yīng)消息。TCP連接隨后終止。該消息標明所封裝的對象是一個HTML文件�？蛻魪闹腥〕鲞@個文件，加以分析后發(fā)現(xiàn)其中有10個JPEG對象的引用。

6.給每一個引用到的JPEG對象重復(fù)步騾1-4。

上述步驟之所以稱為使用非持久連接，原因是每次服務(wù)器發(fā)出一個對象后，相應(yīng)的TCP連接就被關(guān)閉，也就是說每個連接都沒有持續(xù)到可用于傳送其他對象。每個TCP連接只用于傳輸一個請求消息和一個響應(yīng)消息。就上述例子而言，用戶每請求一次那個web頁面，就產(chǎn)生11個TCP連接。

2)         持久連接

非持久連接有些缺點。首先，客戶得為每個待請求的對象建立并維護一個新的連接。對于每個這樣的連接，TCP得在客戶端和服務(wù)器端分配TCP緩沖區(qū)，并維持TCP變量。對于有可能同時為來自數(shù)百個不同客戶的請求提供服務(wù)的web服務(wù)器來說，這會嚴重增加其負擔。其次，如前所述，每個對象都有2個RTT的響應(yīng)延長——一個RTT用于建立TCP連接，另—個RTT用于請求和接收對象。最后，每個對象都遭受TCP緩啟動，因為每個TCP連接都起始于緩啟動階段。不過并行TCP連接的使用能夠部分減輕RTT延遲和緩啟動延遲的影響。

在持久連接情況下，服務(wù)器在發(fā)出響應(yīng)后讓TCP連接繼續(xù)打開著。同一對客戶/服務(wù)器之間的后續(xù)請求和響應(yīng)可以通過這個連接發(fā)送。整個Web頁面(上例中為包含一個基本HTMLL文件和10個圖像的頁面)自不用說可以通過單個持久TCP連接發(fā)送:甚至存放在同一個服務(wù)器中的多個web頁面也可以通過單個持久TCP連接發(fā)送。通常，HTTP服務(wù)器在某個連接閑置一段特定時間后關(guān)閉它，而這段時間通常是可以配置的。持久連接分為不帶流水線(without pipelining)和帶流水線(with pipelining)兩個版本。如果是不帶流水線的版本，那么客戶只在收到前一個請求的響應(yīng)后才發(fā)出新的請求。這種情況下，web頁面所引用的每個對象(上例中的10個圖像)都經(jīng)歷1個RTT的延遲，用于請求和接收該對象。與非持久連接2個RTT的延遲相比，不帶流水線的持久連接已有所改善，不過帶流水線的持久連接還能進一步降低響應(yīng)延遲。不帶流水線版本的另一個缺點是，服務(wù)器送出一個對象后開始等待下一個請求，而這個新請求卻不能馬上到達。這段時間服務(wù)器資源便閑置了。

HTTP/1.1的默認模式使用帶流水線的持久連接。這種情況下，HTTP客戶每碰到一個引用就立即發(fā)出一個請求，因而HTTP客戶可以一個接一個緊挨著發(fā)出各個引用對象的請求。服務(wù)器收到這些請求后，也可以一個接一個緊挨著發(fā)出各個對象。如果所有的請求和響應(yīng)都是緊挨著發(fā)送的，那么所有引用到的對象一共只經(jīng)歷1個RTT的延遲(而不是像不帶流水線的版本那樣，每個引用到的對象都各有1個RTT的延遲)。另外，帶流水線的持久連接中服務(wù)器空等請求的時間比較少。與非持久連接相比，持久連接(不論是否帶流水線)除降低了1個RTT的響應(yīng)延遲外，緩啟動延遲也比較小。其原因在于既然各個對象使用同一個TCP連接，服務(wù)器發(fā)出第一個對象后就不必再以一開始的緩慢速率發(fā)送后續(xù)對象。相反，服務(wù)器可以按照第一個對象發(fā)送完畢時的速率開始發(fā)送下一個對象。

3.         緩存的機制

HTTP/1.1中緩存的目的是為了在很多情況下減少發(fā)送請求，同時在許多情況下可以不需要發(fā)送完整響應(yīng)。前者減少了網(wǎng)絡(luò)回路的數(shù)量；HTTP利用一個“過期（expiration）”機制來為此目的。后者減少了網(wǎng)絡(luò)應(yīng)用的帶寬；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.

關(guān)于web緩存方面的內(nèi)容可以參考：Caching Tutorial for Web Authors and Webmasters（英文版）（中文版）

4.         響應(yīng)授權(quán)激發(fā)機制

這些機制能被用于服務(wù)器激發(fā)客戶端請求并且使客戶端授權(quán)。

詳細的信息請參考：RFC 2617: HTTP Authentication: Basic and Digest Access