轉載自：http://www.cnblogs.com/GumpYan/p/5821193.html
1.HTTP簡介
web浏覽器和伺服器之類的互動過程必須遵守的協定.他是tcp/ip中的一個應用協定。用來協定資料交換過程和資料本身的格式.主要的有HTTP/1.0和HTTP1.1.
HTTP/1.0和HTTP/1.1都把TCP作為底層的傳輸協定。
HTTP客戶首先發起建立與伺服器TCP連接配接。一旦建立連接配接，浏覽器程序和伺服器程序就可以通過各自的套接字來通路TCP。如前所述，用戶端套接字是客戶程序和TCP連接配接之間的“門”，伺服器端套接字是伺服器程序和同一TCP連接配接之間的 “門”。客戶往自己的套接字發送HTTP請求消息，也從自己的套接字接收HTTP響應消息。類似地，伺服器從自己的套接字接收HTTP請求消息，也往自己 的套接字發送HTTP響應消息。客戶或伺服器一旦把某個消息送入各自的套接字，這個消息就完全落入TCP的控制之中。
TCP給HTTP提供一個可靠的資料傳輸服務;這意味着由客戶發出的每個HTTP請求消息最終将無損地到達伺服器，由伺服器發出的每個HTTP響應消息最終也将無損地到達客戶。我們可從中看到分層網絡體系結構的一個明顯優勢——HTTP不必擔心資料會丢失，也無需關心TCP如何從資料的丢失和錯序中恢複出來的細節。這些是TCP和協定棧中更低協定層的任務。
TCP還使用一個擁塞控制機制。該機制迫使每個新的TCP連接配接一開始以相對緩慢的速率傳輸資料，然而隻要網絡不擁塞，每個連接配接可以迅速上升到相對較高的速率。這個慢速傳輸的初始階段稱為緩啟動(slow start)。
需要注意的是，在向客戶發送所請求檔案的同時，伺服器并沒有存儲關于該客戶的任何狀态資訊。即便某個客戶在幾秒鐘内再次請求同一個對象，伺服器也不會響應說:自己剛剛給它發送了這個對象。相反，伺服器重新發送這個對象，因為它已經徹底忘記早先做過什麼。既然HTTP伺服器不維護客戶的狀态資訊，我們于是 說HTTP是一個無狀态的協定(stateless protocol)。
2.一個完整的HTTP請求過程
HTTP事務=請求指令+響應結果
一次完整的請求過程：
（1）域名解析
（2）建立TCP連接配接，三次握手
（3）Web浏覽器向Web服務端發送HTTP請求封包
（4）伺服器響應HTTP請求
（5）浏覽器解析HTML代碼，并請求HTML代碼中的資源（JS，CSS，圖檔）（這是自動向伺服器請求下載下傳的）
（6）浏覽器對頁面進行渲染呈現給客戶
（7）斷開TCP連接配接
如何解析對應的IP位址？域名解析過程（注意了先走本地再走DNS）
3.HTTP/1.0和HTTP/1.1的差別
HTTP 協定老的标準是HTTP/1.0，目前最通用的标準是HTTP/1.1。
在同一個tcp的連接配接中可以傳送多個HTTP請求和響應.
多個請求和響應可以重疊，多個請求和響應可以同時進行.
更加多的請求頭和響應頭(比如HTTP1.0沒有host的字段).
它們最大的差別：
在 HTTP/1.0 中,大多實作為每個請求/響應交換使用新的連接配接。HTTP 1.0規定浏覽器與伺服器隻保持短暫的連接配接，浏覽器的每次請求都需要與伺服器建立一個TCP連接配接，伺服器完成請求處理後立即斷開TCP連接配接，伺服器不跟蹤每個客戶也不記錄過去的請求。
在 HTTP/1.1 中,一個連接配接可用于一次或多次請求/響應交換,盡管連接配接可能由于各種原因被關閉。HTTP 1.1支援持久連接配接，在一個TCP連接配接上可以傳送多個HTTP請求和響應，減少了建立和關閉連接配接的消耗和延遲。一個包含有許多圖像的網頁檔案的多個請求和應答可以在一個連接配接中傳輸，但每個單獨的網頁檔案的請求和應答仍然需要使用各自的連接配接。HTTP 1.1還允許用戶端不用等待上一次請求結果傳回，就可以發出下一次請求，但伺服器端必須按照接收到用戶端請求的先後順序依次回送響應結果，以保證用戶端能夠區分出每次請求的響應内容，這樣也顯著地減少了整個下載下傳過程所需要的時間。
舉例說明：
一個包含有許多圖像的網頁檔案中并沒有包含真正的圖像資料内容，而隻是指明了這些圖像的URL位址，當WEB浏覽器通路這個網頁檔案時，浏覽器首先要發出針對該網頁檔案的請求，當浏覽器解析WEB伺服器傳回的該網頁文檔中的HTML内容時，發現其中的<img>圖像标簽後，浏覽器将根據<img>标簽中的src屬性所指定的URL位址再次向伺服器發出下載下傳圖像資料的請求。
顯然，通路一個包含有許多圖像的網頁檔案的整個過程包含了多次請求和響應，每次請求和響應都需要建立一個單獨的連接配接，每次連接配接隻是傳輸一個文檔和圖像，上一次和下一次請求完全分離。即使圖像檔案都很小，但是用戶端和伺服器端每次建立和關閉連接配接卻是一個相對比較費時的過程，并且會嚴重影響客戶機和伺服器的性能。當一個網頁檔案中包含Applet，JavaScript檔案，CSS檔案等内容時，也會出現類似上述的情況。
為了克服HTTP 1.0的這個缺陷，HTTP 1.1支援持久連接配接，在一個TCP連接配接上可以傳送多個HTTP請求和響應，減少了建立和關閉連接配接的消耗和延遲。一個包含有許多圖像的網頁檔案的多個請求和應答可以在一個連接配接中傳輸，但每個單獨的網頁檔案的請求和應答仍然需要使用各自的連接配接。
HTTP 1.1還允許用戶端不用等待上一次請求結果傳回，就可以發出下一次請求，但伺服器端必須按照接收到用戶端請求的先後順序依次回送響應結果，以保證用戶端能夠區分出每次請求的響應内容，這樣也顯著地減少了整個下載下傳過程所需要的時間。
基于HTTP 1.1協定的客戶機與伺服器的資訊交換過程，如下圖所示
可見，HTTP 1.1在繼承了HTTP 1.0優點的基礎上，也克服了HTTP 1.0的性能問題。
還有哪些小的差別呢？
HTTP 1.1還通過增加更多的請求頭和響應頭來改進和擴充HTTP 1.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緩存等機制相關的請求頭和響應頭。
4.Http怎麼處理長連接配接
基于http協定的長連接配接
在HTTP1.0和HTTP1.1協定中都有對長連接配接的支援。其中HTTP1.0需要在request中增加”Connection： keep-alive“ header才能夠支援，而HTTP1.1預設支援.
http1.0請求與服務端的互動過程:
（1）用戶端發出帶有包含一個header：”Connection： keep-alive“的請求
（2）服務端接收到這個請求後,根據http1.0和”Connection： keep-alive“判斷出這是一個長連接配接,就會在response的header中也增加”Connection： keep-alive“，同時不會關閉已建立的tcp連接配接.
（3）用戶端收到服務端的response後,發現其中包含”Connection： keep-alive“，就認為是一個長連接配接，不關閉這個連接配接。并用該連接配接再發送request.轉到（1）
http1.1請求與服務端的互動過程:
（1）用戶端發出http1.1的請求
（2）服務端收到http1.1後就認為這是一個長連接配接,會在傳回的response設定Connection： keep-alive,同時不會關閉已建立的連接配接.
（3）用戶端收到服務端的response後,發現其中包含”Connection： keep-alive“，就認為是一個長連接配接，不關閉這個連接配接。并用該連接配接再發送request.轉到（1）
基于http協定的長連接配接減少了請求,減少了建立連接配接的時間,但是每次互動都是由用戶端發起的,用戶端發送消息,服務端才能傳回用戶端消息。因為用戶端也不知道服務端什麼時候會把結果準備好，是以用戶端的很多請求是多餘的,僅是維持一個心跳,浪費了帶寬。
栗子：下列哪些http方法對于服務端和使用者端一定是安全的？（C）
A.GET
B.HEAD
C.TRACE
D.OPTIONS
E.POST
TRACE: 這個方法用于傳回到達最後伺服器的請求的封包，這個方法對伺服器和用戶端都沒有什麼危險。
參考文檔：
http://www.xuebuyuan.com/683882.html
http://blog.csdn.net/elifefly/article/details/3964766