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的程序
後記：
我這篇文章只是對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程序員的首選讀物
轉自http://www.cnblogs.com/gpcuster/archive/2009/05/25/1488749.html