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給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