Android 網路程式設計（1）：HTTP協議原理

這篇文章是這個系列的開篇，作為移動開發者，開發的應用不免會對網路進行訪問，雖然現在已經有很多的開源庫幫助我們可以輕而易舉的訪問網路，但是我們仍要去了解網路訪問的原理，這也是一個優秀開發人員所必備的知識點。這篇文章我們就先來了解一下HTTP協議原理。

1.HTTP簡介

HTTP是一個屬於應用層的物件導向的協議，由於其簡捷、快速的方式，適用於分散式超媒體資訊系統。它於1990年提出，經過幾年的使用與發展，得到不斷地完善和擴充套件。

HTTP協議的主要特點

1. 支援C/S（客戶/伺服器）模式。
2. 簡單快速：客戶向伺服器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST，每種方法規定了客戶與伺服器聯絡的型別不同。由於HTTP協議簡單，使得HTTP伺服器的程式規模小，因而通訊速度很快。
3. 靈活：HTTP允許傳輸任意型別的資料物件。正在傳輸的型別由Content-Type加以標記。
4. 無連線：無連線的含義是限制每次連線只處理一個請求。伺服器處理完客戶的請求，並收到客戶的應答後，即斷開連線。採用這種方式可以節省傳輸時間。
5. 無狀態：HTTP協議是無狀態協議，無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的資訊，則它必須重傳，這樣可能導致每次連線傳送的資料量增大。另一方面，在伺服器不需要先前資訊時它的應答就較快。

HTTP URL 的格式如下

http表示要通過HTTP協議來定位網路資源；host表示合法的Internet主機域名或者IP地址；port指定一個埠號，為空則使用預設埠80；abs_path指定請求資源的URI（Web上任意的可用資源）。
HTTP有兩種報文分別是請求報文和響應報文，讓我們先來看看請求報文。

2.HTTP的請求報文

先來看看請求報文的一般格式：

通常來說一個HTTP請求報文由請求行、請求報頭、空行、和請求資料4個部分組成。

請求行

請求行由請求方法，URL欄位和HTTP協議的版本組成，格式如下：

其中 Method表示請求方法；Request-URI是一個統一資源識別符號；HTTP-Version表示請求的HTTP協議版本；CRLF表示回車和換行（除了作為結尾的CRLF外，不允許出現單獨的CR或LF字元）。

HTTP請求方法有8種，分別是GET、POST、DELETE、PUT、HEAD、TRACE、CONNECT 、OPTIONS。其中PUT、DELETE、POST、GET分別對應著增刪改查，對於移動開發最常用的就是POST和GET了。

1. GET：請求獲取Request-URI所標識的資源
2. POST：在Request-URI所標識的資源後附加新的資料
3. HEAD 請求獲取由Request-URI所標識的資源的響應訊息報頭
4. PUT 請求伺服器儲存一個資源，並用Request-URI作為其標識
5. DELETE 請求伺服器刪除Request-URI所標識的資源
6. TRACE 請求伺服器回送收到的請求資訊，主要用於測試或診斷
7. CONNECT 保留將來使用
8. OPTIONS 請求查詢伺服器的效能，或者查詢與資源相關的選項和需求

例如我去訪問我的CSDN部落格地址請求行是：

請求報頭

在請求行之後會有0個或者多個請求報頭，每個請求報頭都包含一個名字和一個值，它們之間用“：”分割。請求頭部會以一個空行，傳送回車符和換行符，通知伺服器以下不會有請求頭。關於請求報頭，會在後面的訊息報頭一節做統一的解釋。

請求資料

請求資料不在GET方法中使用，而是在POST方法中使用。POST方法適用於需要客戶填寫表單的場合，與請求資料相關的最常用的請求頭是Content-Type和Content-Length。

3.HTTP的響應報文

先來看看響應報文的一般格式：

HTTP的響應報文由狀態行、訊息報頭、空行、響應正文組成。響應報頭後面會講到，響應正文是伺服器返回的資源的內容，先來看看狀態行。

狀態行

1、狀態行格式如下：

其中，HTTP-Version表示伺服器HTTP協議的版本；Status-Code表示伺服器發回的響應狀態程式碼；Reason-Phrase表示狀態程式碼的文字描述。
狀態程式碼有三位數字組成，第一個數字定義了響應的類別，且有五種可能取值：

• 100~199：指示資訊，表示請求已接收，繼續處理
• 200~299：請求成功，表示請求已被成功接收、理解、接受
• 300~399：重定向，要完成請求必須進行更進一步的操作
• 400~499：客戶端錯誤，請求有語法錯誤或請求無法實現
• 500~599：伺服器端錯誤，伺服器未能實現合法的請求

常見的狀態碼如下：

• 200 OK：客戶端請求成功
• 400 Bad Request：客戶端請求有語法錯誤，不能被伺服器所理解
• 401 Unauthorized：請求未經授權，這個狀態程式碼必須和WWW-Authenticate報頭域一起使用
• 403 Forbidden：伺服器收到請求，但是拒絕提供服務
• 500 Internal Server Error：伺服器發生不可預期的錯誤
• 503 Server Unavailable：伺服器當前不能處理客戶端的請求，一段時間後可能恢復正常

例如訪問我的CSDN部落格地址響應的狀態行是：

4.HTTP的訊息報頭

訊息報頭分為通用報頭、請求報頭、響應報頭、實體報頭等。訊息頭由鍵值對組成，每行一對，關鍵字和值用英文冒號“:”分隔。

通用報頭

既可以出現在請求報頭，也可以出現在響應報頭中

• Date：表示訊息產生的日期和時間
• Connection：允許傳送指定連線的選項，例如指定連線是連續的，或者指定“close”選項，通知伺服器，在響應完成後，關閉連線
• Cache-Control：用於指定快取指令，快取指令是單向的（響應中出現的快取指令在請求中未必會出現），且是獨立的（一個訊息的快取指令不會影響另一個訊息處理的快取機制）

請求報頭

請求報頭通知伺服器關於客戶端求求的資訊，典型的請求頭有：

• Host：請求的主機名，允許多個域名同處一個IP地址，即虛擬主機
• User-Agent：傳送請求的瀏覽器型別、作業系統等資訊
• Accept：客戶端可識別的內容型別列表，用於指定客戶端接收那些型別的資訊
• Accept-Encoding：客戶端可識別的資料編碼
• Accept-Language：表示瀏覽器所支援的語言型別
• Connection：允許客戶端和伺服器指定與請求/響應連線有關的選項，例如這是為Keep-Alive則表示保持連線。
• Transfer-Encoding：告知接收端為了保證報文的可靠傳輸，對報文采用了什麼編碼方式。

響應報頭

用於伺服器傳遞自身資訊的響應，常見的響應報頭：

• Location：用於重定向接受者到一個新的位置，常用在更換域名的時候
• Server：包含可伺服器用來處理請求的系統資訊，與User-Agent請求報頭是相對應的

實體報頭

實體報頭用來定於被傳送資源的資訊，既可以用於請求也可用於響應。請求和響應訊息都可以傳送一個實體，常見的實體報頭為：

• Content-Type：傳送給接收者的實體正文的媒體型別
• Content-Lenght：實體正文的長度
• Content-Language：描述資源所用的自然語言，沒有設定則該選項則認為實體內容將提供給所有的語言閱讀
• Content-Encoding：實體報頭被用作媒體型別的修飾符，它的值指示了已經被應用到實體正文的附加內容的編碼，因而要獲得Content-Type報頭域中所引用的媒體型別，必須採用相應的解碼機制。
• Last-Modified：實體報頭用於指示資源的最後修改日期和時間
• Expires：實體報頭給出響應過期的日期和時間

5.應用舉例

要想檢視網頁或者手機請求網路的請求報文和響應報文有很多種方法，這裡推薦採用Fiddler，在Android利用Fiddler進行網路資料抓包這篇文章中詳盡介紹瞭如何使用Fiddler，在這裡就不贅述了。
開啟Fiddler，然後用瀏覽器訪問我的CSDN部落格網站：

點選紅色畫筆的區域就可以看到請求報文和響應報文了

請求報文：

很容易看出訪問的是我的部落格地址http://blog.csdn.net/itachi85，請求的方法是GET，因為是GET方法所以並沒有請求資料。

響應報文：

響應報文沒什麼可說的，接下來我們配置好手機網路代理，訪問一個應用的介面

請求報文：

從請求報文的請求行來看，請求的方法是POST，請求地址為http://patientapi.shoujikanbing.com/api/common/getVersion，很顯然是獲取版本資訊的介面。

響應報文：

響應報文的實體採用的編碼格式為為gzip，所以在Fiddler軟體中顯示的是亂碼。