前言

現如今，網路無處不在。對於Android開發者而言，免不了涉及到對網路的訪問。於是挖個坑= = ，介紹一下Android下關於網路程式設計的方方面面，本文將講述HTTP協議的一些必備知識。

HTTP協議簡介

超文字傳輸協議（HTTP，HyperText Transfer Protocol)是網際網路上應用最為廣泛的一種網路協議。它是一個屬於應用層的面向物件的協議，所有的WWW檔案都必須遵守這個標準。

協議特點

• 採用C/S模型：
  –Client：瀏覽器(瀏覽器)請求,接收,顯示“網路物件
  –Server：Web伺服器根據請求傳送物件。
  
• 使用TCP傳輸協議
• 無連線：無連線的含義是限制每次連線只處理一個請求。伺服器處理完客戶的請求，並收到客戶的應答後，即斷開連線。採用這種方式可以節省傳輸時間。
• 無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的資訊，則它必須重傳，這樣可能導致每次連線傳送的資料量增大。另一方面，在伺服器不需要先前資訊時它的應答就較快。

格式

HTTP報文

HTTP報文分為請求報文和響應報文兩種基本分類。一般來說，一個響應對應一個請求。

• 請求報文是客戶端傳送給伺服器的用於請求服務和資源的訊息
• 響應報文是伺服器對請求訊息的應答。

HTTP請求報文

首先，放上上課時PPT中的截圖(我還只是個學生，笑)

請求行

由上圖，顯而易見：

請求行 = 請求方法 + 空格 + URL + 空格 + HTTP協議版本
示例 ：GET /somedir/page.html
HTTP/1.1

其中URL就是一個統一資源識別符號，HTTP協議版本就是字面上的意思，表明請求的HTTP協議版本。

HTTP請求方法有8種，說明如下：

對於Android開發而言，我們最關注的其實也就只有POST和GET。

GET與POST對比

我就不再個人贅述了，直接放上一篇比較系統的分析文章

請求報頭

請求報頭和方法配合工作，決定客戶端能做什麼事情，詳見訊息報頭

請求資料

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

HTTP響應報文

狀態行

每條響應報文都會包含一個3位數字和可讀的狀態，用來告訴客戶端，伺服器發生了什麼事情。數字狀態碼便於程式處理差錯，原因短語更便於人們理解。狀態碼分為5類:

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

常見的狀態碼如下，詳情參見HTTP狀態碼維基百科

• 101 Switching Protocols：伺服器正在根據客戶端的指定，將協議切換成Update首部所示的協議。
• 200 OK：伺服器已成功處理了請求並提供了請求的網頁
• 204 No Content：伺服器成功處理了請求，但沒有返回任何內容
• 301 Moved Permanently：請求的網頁已永久移動到新位置。響應的Location首部應包含資源現在所處的URL。
• 302 Found：與301類似，但這裡的移除是臨時的。將來的請求仍應使用老的URL。
• 304 Not Modified：客戶的快取資源是最新的，要客戶端使用快取。
• 400 Bad Request：告知客戶端傳送了一個錯誤的請求。
• 403 Forbidden：請求被伺服器拒絕了。（可能是沒有訪問伺服器的許可權）
• 404 Not Found：伺服器無法找到所請求的URL。
• 410 Gone：伺服器曾經有這個資源，現在沒有了，與404類似。
• 500 Internal Server Error：伺服器遇到一個錯誤，使其無法為請求提供服務。
• 502 Bad Gateway：作為代理或閘道器使用的伺服器收到了上游的無效響應。
• 503 Service Unavailable：伺服器現在無法為請求提供服務，但過一段時間就可以恢復服務。

響應報頭

見下文HTTP訊息報頭

響應正文

好像沒什麼好說的= =！

HTTP訊息報頭

訊息報頭和方法配合工作，共同決定了客戶端和伺服器能做什麼事情。可以將/訊息報頭分為通用報頭、請求報頭、響應報頭、實體報頭等，以下將分類詳細說明。

通用報頭

客戶端和伺服器都可以使用，提供與報文下相關的最基本的資訊。
* Connection：允許客戶端和伺服器指定與請求/響應連線相關的選項
* Date：日期和時間標誌，說明報文是什麼時刻建立的
* MIME-Version：給出了傳送端使用的MIME版本
* Transfer-Encoding：告知接收端為了保證報文的可靠傳輸，對報文采用了什麼編碼方式
* Via：顯示了報文經過的中間節點（代理、閘道器等等）
* Cache-Control：用於隨報文傳送快取指示
* Pragma：另一種隨報文傳送指示的方式，但並不專用於快取

請求報頭

只在請求報文中有意義，用於說明是誰或什麼在傳送請求、請求源自何處，或客戶端的喜好及能力等。

• Host：請求的主機名，允許多個域名同處一個IP地址，即虛擬主機
• User-Agent：傳送請求的瀏覽器型別、作業系統等資訊
• Accept：客戶端可識別的內容型別列表，用於指定客戶端接收那些型別的資訊
• Accept-Encoding：客戶端可識別的資料編碼
• Accept-Language：表示瀏覽器所支援的語言型別
• Referer：提供了包含當前請求URI的文件的URL

響應報頭

為客戶端提供了一些額外資訊，比如誰在傳送響應、響應者的功能、其它一些特殊指令等

• Location：用於重定向接受者到一個新的位置，常用在更換域名的時候
• Server：包含可伺服器用來處理請求的系統資訊，與User-Agent請求報頭是相對應的
• Age：（從最初建立開始）響應持續時間
• Public：伺服器為其資源支援的請求方法列表
• Retry-After：如果資源不可用，在此時間重試
• Accept-Ranges：（協商首部）對此資源來說，伺服器可接受的範圍型別
• Set-Cookie：（安全首部）類似Cookie，用於設定Cookie

實體報頭

用來描述HTTP報文的負荷，提供了有關實體及其內容的大量資訊，可以告知報文的接收者它在對什麼進行處理
* Allow：列出可以對此實體執行的請求方法
* Content-Type：傳送給接收者的實體正文的媒體型別
* Content-Lenght：實體正文的長度
* Content-Language：描述資源所用的自然語言，沒有設定則該選項則認為實體內容將提供給所有的語言閱讀
* Content-Encoding：實體報頭被用作媒體型別的修飾符，它的值指示了已經被應用到實體正文的附加內容的編碼，因而要獲得Content-Type報頭域中所引用的媒體型別，必須採用相應的解碼機制。

• Last-Modified：實體報頭用於指示資源的最後修改日期和時間
• Expires：實體報頭給出響應過期的日期和時間

總結

• 本文對HTTP協議中的必備知識做出講解。
• 筆者水平有限，如有錯漏，歡迎指正。
• 接下來我將持續推出Android網路相關的一系列文章，包括HttpURLConnection、Volley、OkHttp3、Retrofit2的使用等，有興趣可以關注whd_Alive的Android開發筆記
• 不定期分享Android開發相關的技術乾貨，期待與你的交流，共勉。