協議實戰系列:-HTTP協議簡介
題記 ：
在實際開發中，頻繁的接觸網絡請求，通信傳輸等， 而做爲開發者對常用協議的使用，掌握已是每個開發者的必備技能，下面我們一起學習下。常用的一些開發協議，HTTP協議，Samba協議，Webdav 協議，以及DLNA等協議。
一、HTTP協議簡介：
什麼是HTTP？全稱是HyperText Transfer Protocal，即：超文本傳輸協議，從1990年開始就在WWW上廣泛應用，是現今在WWW上應用最多的協議，常用的有1.0 ,1.1 ,目前使用的版本是1.1。Http 協議是Web聯網的基礎，也是手機聯網常用的協議之一，HTTP協議是建立在TCP協議之上的一種應用。
Http是應用層協議，當你上網瀏覽網頁的時候，瀏覽器和Web服務器之間就會通過HTTP在Internet上進行數據的發送和接收。
Http是一個基於請求/響應模式的、無狀態的協議。即我們通常所說的Request/Response。
二、TCP協議基礎知識介紹：
完成三次握手，主機A與主機B開始傳送數據。
由於http處於最上層的應用層，所以其HTTP報文需要經過多次封裝，才能在網絡間傳遞
三、HTTP協議版本區別：
HTTP目前常用的版本有1.0, 1.1；HTTP連接最顯著的特點是客戶端發送的每次請求都需要服務器回送響應，在請求結束後，會主動釋放連接。從建立連接到關閉連接的過程稱爲“一次連接”。
1）在HTTP 1.0中，客戶端的每次請求都要求建立一次單獨的連接，在處理完本次請求後，就自動釋放連接。
2）在HTTP 1.1中則可以在一次連接中處理多個請求，並且多個請求可以重疊進行，不需要等待一個請求結束後再發送下一個請求。
由於HTTP在每次請求結束後都會主動釋放連接，因此HTTP連接是一種“短連接”，要保持客戶端程序的在線狀態，需要不斷地向服務器發起連接請求。通常 的做法是即時不需要獲得任何數據，客戶端也保持每隔一段固定的時間向服務器發送一次“保持連接”的請求，服務器在收到該請求後對客戶端進行回覆，表明知道 客戶端“在線”。若服務器長時間無法收到客戶端的請求，則認爲客戶端“下線”，若客戶端長時間無法收到服務器的回覆，則認爲網絡已經斷開。
四、HTTP URL
HTTP URL格式如下：
http://host[“:”port][abs_path]
其中HTTP表示要通過HTTP協議來定位網絡資源。host表示合法的Internet主機域名或IP地址。port用於指定一個端口號，擁有被請求資源服務器主機監聽該端口的TCP連接，如果port是空的，或者沒有給出，則使用默認的缺省值80.abs_path表示指定請求資源的URI（Uniform Resource Identifier,統一資源標示符），如果URL中沒有給出abs_path,那麼當他作爲請求URI時，必須以”/”的形式給出。
五、HTTP 消息格式
消息頭：用於描述客戶端請求哪臺主機，以及客戶端的一些環境信息等。如上圖所示，我們是通過post方式，使用的HTTP版本號http1.1, 主機是:localhost，即本地主機。實體信息：test。
常用請求消息頭 ：
Accept: text/html,image/* 說明瀏覽器接受的數據類型
Accept-Charset: ISO-8859-1 說明瀏覽器使用的字符編碼
Accept-Encoding: gzip,compress 說明瀏覽器支持的壓縮格式
Accept-Language: en-us,zh-cn 說明瀏覽器的語言環境
Host: www.it315.org:80 說明瀏覽器要訪問的主機名
If-Modified-Since: Tue, 11 Jul 2000 18:23:51 GMT 文件的修改事件，用於做緩存
Referer: http://www.it315.org/index.jsp 說明請求來自哪裏，防盜鏈 (做實驗)
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) 說明瀏覽器內核
Cookie 向服務器發送Cookie
Connection: close/Keep-Alive 說明連接狀態
Date: Tue, 11 Jul 2000 18:23:51 GMT 客戶端計算機時間
HTTP 1.1 新增了五種請求方法：OPTIONS、PUT、DELETE、TRACE和CONNECT方法。
但常用的只有post,get。其它幾種方式基本都用不到，這兩種方式也有很大 的區別以及不同的適用場景。
常用的方法含義：
GET：獲得資源 【不含entity-body】
HEAD：獲得文檔頭部，開發時使用 【不含entity-body】
POST：向服務器發送需要處理的數據 【含entity-body】
PUT：將請求主體放存儲在服務器上，比如上傳一個圖片 【含entity-body】
DELETE：從服務器上刪除一個資源，比如刪除一個圖片 【不含entity-body】
OPTIONS：在服務器上執行哪些方法 【不含entity-body】
TRACE：對可能經過代理服務器傳送到服務器上去的報文進行追蹤 【不含entity-body】
get方式與post 方式區別：
1. GET提交的數據會放在URL之後，以?分割URL和傳輸數據，參數之間以&相連，如EditPosts.aspx?name=test1&id=123456. POST 方法是把提交的數據放在HTTP包的Body中.
2. GET提交的數據大小有限制（因爲瀏覽器對URL的長度有限制），而POST方法提交的數據沒有限制.
3. GET方式需要使用Request.QueryString來取得變量的值，而POST方式通過Request.Form來獲取變量的值。
4. GET方式提交數據，會帶來安全問題，比如一個登錄頁面，通過GET方式提交數據時，用戶名和密碼將出現在URL上，如果頁面可 以被緩存或者其他人可以訪問這臺機器，就可以從歷史記錄獲得該用戶的賬號和密碼.
以被緩存w e爲了比較這兩種方式，我寫了一個web 測試項目，在此工程中有一個1.html。關鍵代碼如下：
<body> <form method="post" action="/1.html"> <input type="text" name="user" /> <input type="submit" value="submit" /> </form> </body>
body中有一個表單，通過form的method指定表單的提交方式分別爲post,get。運行情況如下：
get方式：
post方式：
請大家注意觀察上面兩幅圖的地址欄與httpwatch中的請求頭，實體信息行。
2. HTTP 響應：
在接受和處理消息後，服務器會返回一個HTTP響應消息。與HTTP請求類似，HTTP響應也由三個部分組成，分別是： 狀態行，消息報頭，響應正文。
狀態行：用於描述服務器對請求的處理結果。HTTP-Version Status-Code Reason-Phrase CRLF ，如: HTTP/1.1 200 OK (CRLF)
消息頭 ：用於描述服務器的基本信息，以及數據的描述，服務器通過這些數據的描述信息，可以通知客戶端如何處理等一會兒它回送的數據
實體內容代表服務器向客戶端回送的數據
http常用響應頭
Content-Length: 80 通知瀏覽器發送數據的長度
Content-Language: zh-cn 通知瀏覽器語言環境
Content-Type: text/html; charset=GB2312 通知瀏覽器文件的格式和編碼
Last-Modified: Tue, 11 Jul 2000 18:23:51 GMT 告訴瀏覽器文件的修改時間
Refresh: 1;url=http://www.it315.org 通知瀏覽器自動刷新
Content-Disposition: attachment; filename=aaa.zip 通知瀏覽器以下載的方式打開資源
Set-Cookie:SS=Q0=5Lb_nQ; path=/search 發cookie
Expires: -1//3種禁止緩存的頭字段
Cache-Control: no-cache
Pragma: no-cache
Connection: close/Keep-Alive 連接狀態
Date: Tue, 11 Jul 2000 18:23:51 GMT 系統時間
HTTP狀態碼：
常見HTTP狀態碼：
200——請求成功
301——資源（網頁等）被永久轉移到其他URL
302——跳轉，跳轉地址通過響應頭中的Location屬性指定
400——客戶端請求有語法錯誤，不能被服務器識別
403——服務器收到請求，但是拒絕提供服務（認證失敗）
404——請求的資源（網頁等）不存在
500——內部服務器錯誤
503——服務器當前不能夠處理客戶端的請求，在一段時間之後，服務器可能會恢復正常
HTTP支持兩種建立連接的方式：非持久連接和持久連接(HTTP1.1默認的連接方式爲持久連接)：
非持久連接：
讓我們查看一下非持久連接情況下從服務器到客戶傳送一個Web頁面的步驟。假設該頁面由1個基本HTML文件和10個JPEG圖像構成，而且所有這些對象都存放在同一臺服務器主機中。再假設該基本HTML文件的URL爲：http://www.baidu.com。
下面是具體步騾:
1) HTTP客戶初始化一個與服務器主機http://www.baidu.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連接。
持久連接:
非持久連接的缺點
1) 客戶得爲每個待請求的對象建立並維護一個新的連接。對於每個這樣的連接，TCP得在客戶端和服務器端分配TCP緩衝區，並維持TCP變量。對於有可能同時爲來自數百個不同客戶的請求提供服務的web服務器來說，這會嚴重增加其負擔。
2) 如前所述，每個對象都有2個RTT的響應延長——一個RTT用於建立TCP連接，另—個RTT用於請求和接收對象。
3) 每個對象都遭受TCP緩啓動，因爲每個TCP連接都起始於緩啓動階段。不過並行TCP連接的使用能夠部分減輕RTT延遲和緩啓動延遲的影響。
而在持久連接情況下，服務器在發出響應後讓TCP連接繼續打開着。同一對客戶/服務器之間的後續請求和響應可以通過這個連接發送。整個Web頁面(上例中爲包含一個基本HTMLL文件和10個圖像的頁面)自不用說可以通過單個持久TCP連接發送:甚至存放在同一個服務器中的多個web頁面也可以通過單個持久TCP連接發送。
參考文章：http://www.cnblogs.com/byghui/archive/2013/03/21/2969535.html
http://www.cnblogs.com/rosesmall/archive/2012/04/09/2439726.html
http://z1041950008.iteye.com/blog/2190509
