Android網絡基礎3——HTTP協定原理

1. HTTP簡介

HTTP協定用于用戶端與伺服器之間的通信，在通信線路兩端，必定一端是用戶端，另一端是伺服器。

注意：用戶端與伺服器的角色不是固定的，一端充當用戶端，也可能在某次請求中充當伺服器，這取決與請求的發起端。HTTP協定屬于應用層，建立在傳輸層協定TCP之上。用戶端通過與伺服器建立TCP連接配接，之後發送HTTP請求與接收HTTP響應都是通過通路Socket接口來調用TCP協定實作。

HTTP協定的主要特點

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

HTTP URL 的格式如下

http://host[":"port][abs_path]

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

2. HTTP的請求封包

先來看看請求封包的一般格式：

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

請求行：

請求行由請求方法，URL字段和HTTP協定的版本組成，格式如下：

Method Request-URI HTTP-Version CRLF

其中 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部落格位址請求行是：

GET http://blog.csdn.net/itachi85 HTTP/1.1

請求報頭：

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

請求資料：

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

3. HTTP的響應封包

先來看看響應封包的一般格式：

HTTP的響應封包由狀态行、消息報頭、空行、響應正文組成。響應報頭後面會講到，響應正文是伺服器傳回的資源的内容，先來看看狀态行。

狀态行：

1、狀态行格式如下：

HTTP-Version Status-Code Reason-Phrase CRLF

其中，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部落格位址響應的狀态行是：

HTTP/1.1 200 OK

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：實體報頭給出響應過期的日期和時間