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 aconditional 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代理

原理

分類

1. 透明代理
2. 非透明代理
3. 反向代理

2 多執行緒下載

1.  
   1. 下載工具開啟多個發出HTTP請求的執行緒
   2. 每個http請求只請求資原始檔的一部分：Content-Range: bytes 20000-40000/47000
   3. 合併每個執行緒下載的檔案

3 HTTPS傳輸協議原理

兩種基本的加解密演算法型別

對稱加密：金鑰只有一個，加密解密為同一個密碼，且加解密速度快，典型的對稱加密演算法有DES、AES等

非對稱加密：金鑰成對出現（且根據公鑰無法推知私鑰，根據私鑰也無法推知公鑰），加密解密使用不同金鑰（公鑰加密需要私鑰解密，私鑰加密需要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密演算法有RSA、DSA等

HTTPS通訊過程

優點

1.  
   1. 客戶端產生的金鑰只有客戶端和伺服器端能得到
   2. 加密的資料只有客戶端和伺服器端才能得到明文
   3. 客戶端到服務端的通訊是安全的

 

4 開發web程式時常用的Request Methods

HEAD

（Head方法）要求響應與相應的GET請求的響應一樣，但是沒有的響應體（response body）。這用來獲得響應頭（response header）中的後設資料資訊（meta-infomation）有（很）幫助，（因為）它不需要傳輸所有的內容。

TRACE

（Trace方法告訴伺服器端）返回收到的請求。客戶端可以（通過此方法）察看在請求過程中中間伺服器新增或者改變哪些內容。

OPTIONS

返回伺服器（在指定URL上）支援的HTTP方法。通過請求“*”而不是指定的資源，這個方法可以用來檢查網路伺服器的功能。

CONNECT

將請求的連線轉換成透明的TCP/IP通道，通常用來簡化通過非加密的HTTP代理的SSL-加密通訊（HTTPS）。

5 使用者與伺服器的互動

1.  
   1. 身份認證
   2. cookie
   3. 帶條件的GET

6 基於Socket程式設計編寫遵循HTTP的程式

 

 

後記：

我只是對HTTP協議做了一個大概介紹，很多細節都有遺漏，請有興趣的朋友閱讀RFC 2616。

學習HTTP協議的好書：

1.O'Reilly - HTTP Pocket Reference：這是一本比較簡短的介紹HTTP協議的書，可以作為入門讀物

2.O'Reilly - HTTP The Definitive Guide：這是一本寶典級別的書，因為它包含的內容實在多，可以作為全面學習的HTTP協議的首選讀物

3.Sams - HTTP Developers Handbook：這是比HTTP The Definitive Guide稍微比HTTP The Definitive Guide簡單。不過從我的感覺，這本書比HTTP The Definitive Guide要好，因為它篇幅比較少，介紹的是HTTP精髓，我認為這本書應該是web程式設計師的首選讀物