Android 網絡基礎之 HTTP

讀前思考

學習一門技術或者看一篇文章最好的方式就是帶着問題去學習，這樣才能在過程當中有茅塞頓開、燈火闌珊的感受，記憶也會更深入。

1. 瞭解哪些響應狀態碼？
2. get 和 post 的區別？
3. HTTP 和 HTTPS 的區別?

概述

HTTP 全稱是 HyperText Transfer Protocal ，即：超文本傳輸協議，從 1990 年開始就在 WWW 上普遍應用，是現今在 WWW 上應用最多的協議，HTTP 是應用層協議，當你上網瀏覽網頁的時候，瀏覽器和 web 服務器之間就會經過 HTTP 在 Internet 上進行數據的發送和接收。HTTP 是一個基於請求/響應模式的、無狀態的協議。即咱們一般所說的 Request/Response。

HTTP 請求過程

首先看一張圖

若是對網絡協議還不太熟悉的同窗，建議看一下上一篇文章 Android 網絡基礎之網絡協議篇

HTTP 報文

請求報文

請求行   <method> <request-url> <version>
請求頭   <headers>
請求體   <entity-body>
複製代碼

響應報文

響應狀態行 <version> <status> <reason-phrase>
響應頭     <headers>
響應體     <entity-body>
複製代碼

解釋一下各個標籤：

<method> 指請求方法，經常使用的主要是 Get、 Post、Head 還有其餘一些咱們這裏就不說了，有興趣的能夠本身查閱一下

<version> 指協議版本，如今一般都是Http/1.1了

<request-url> 請求地址

<status> 指響應狀態碼， 咱們熟悉的200、404等等

<reason-phrase> 緣由短語，200 OK 、404 Not Found 這種後面的描述就是緣由短語，一般沒必要太關注。
複製代碼

請求方法（method）

列舉幾個比較經常使用的

方法名	功能
GET	向指定的資源發出「顯示」請求，使用 GET 方法應該只用在讀取數據上，而不該該用於產生「反作用」的操做中
POST	指定資源提交數據，請求服務器進行處理（例如提交表單或者上傳文件）。數據被包含在請求文本中。這個請求可能會建立新的資源或者修改現有資源，或二者皆有。
PUT	向指定資源位置上傳其最新內容
DELETE	請求服務器刪除 Request-URI 所標識的資源

Post 和 Get 的區別

• Post 通常用於數據傳遞，Get 通常用於數據查詢
• Post 相對 Get 安全一點點，由於 Get 請求都包含在 URL 裏
• Post 支持更多的編碼類型且不對數據類型限制

常見狀態碼

2XX 成功

• 200 OK，表示從客戶端發來的請求在服務器端被正確處理
• 204 No content，表示請求成功，但響應報文不含實體的主體部分
• 206 Partial Content，進行範圍請求

3XX 重定向

• 301 moved permanently，永久性重定向，表示資源已被分配了新的 URL
• 302 found，臨時性重定向，表示資源臨時被分配了新的 URL
• 303 see other，表示資源存在着另外一個 URL，應使用 GET 方法丁香獲取資源
• 304 not modified，表示服務器容許訪問資源，但因發生請求未知足條件的狀況
• 307 temporary redirect，臨時重定向，和302含義相同

4XX 客戶端錯誤

• 400 bad request，請求報文存在語法錯誤
• 401 unauthorized，表示發送的請求須要有經過 HTTP 認證的認證信息
• 403 forbidden，表示對請求資源的訪問被服務器拒絕
• 404 not found，表示在服務器上沒有找到請求的資源

5XX 服務器錯誤

• 500 internal sever error，表示服務器端在執行請求時發生了錯誤
• 503 service unavailable，代表服務器暫時處於超負載或正在停機維護，沒法處理請求

請求和響應常見通用的 Header

指請求報文和響應報文均可以使用的字段

• Cache-Control

1. no-cache 指客戶端不緩存過時資源
2. no-store 指不進行緩存
3. max-age 指緩存資源的緩存時間比指定的值小，那麼客戶端就接受緩存資源，且緩存服務器不對資源有效性進行再次確認

• Connection

1. 指控制再也不轉發給代理的首部字段（Hop-by-hop），管理持久鏈接
2. close 指服務器像明確斷開鏈接
3. Keep-Alive 指保存持久鏈接，HTTP/1.1前默認鏈接是非持久性的，如須要保存持久鏈接，須要增長此字段

• Upgrade
  能夠用來指定一個徹底不一樣的通訊協議，對於這個字段，服務器能夠返回101狀態碼

常見的請求 Header

• Accept 指用戶代理可以處理的媒體類型及媒體類型的相對優先級
• Accept-Encoding 指用來告知服務器用戶代理支持的內容編碼及內容編碼的優先級順序
• Authorization 指用來告知服務器，用戶代理的認證信息
• Host 當一個 IP 下存在多個域名時，幫助服務器知道要請求的具體主機
• User-Agent 會講建立請求的瀏覽器和用戶代理名稱等信息傳達給服務器

HTTPS

Http 與 Https 的區別

Http + 加密 + 認證 + 完整性保護 = Https

傳統的 Http 協議是一種應用層的傳輸協議，Http 直接與 TCP 協議通訊。其自己存在一些缺點：

Http 協議使用明文傳輸，容易遭到竊聽。

Http 對於通訊雙方都沒有進行身份驗證，通訊的雙方沒法確認對方是不是假裝的客戶端或者服務端。

Http 對於傳輸內容的完整性沒有確認的辦法，每每容易在傳輸過程當中被劫持篡改。

所以，在一些須要保證安全性的場景下，好比涉及到銀行帳戶的請求時，Http 沒法抵禦這些攻擊。

Https 則能夠經過增長的 SSL\TLS，支持對於通訊內容的加密，以及對通訊雙方的身份進行驗證。

Https 的加密

近代密碼學中加密的方式主要有兩類：

• 對稱祕鑰加密
• 非對稱祕鑰加密

對稱祕鑰加密是指加密與解密過程使用同一把祕鑰。這種方式的優勢是處理速度快，可是如何安全的從一方將祕鑰傳遞到通訊的另外一方是一個問題。

非對稱祕鑰加密是指加密與解密使用兩把不一樣的祕鑰。這兩把祕鑰，一把叫公開祕鑰，能夠隨意對外公開。一把叫私有祕鑰，只用於自己持有。獲得公開祕鑰的客戶端可使用公開祕鑰對傳輸內容進行加密，而只有私有祕鑰持有者自己能夠對公開祕鑰加密的內容進行解密。這種方式克服了祕鑰交換的問題，可是相對於對稱祕鑰加密的方式，處理速度較慢。

SSL\TLS 的加密方式則是結合了兩種加密方式的優勢。首先採用非對稱祕鑰加密，將一個對稱祕鑰使用公開祕鑰加密後傳輸到對方。對方使用私有祕鑰解密，獲得傳輸的對稱祕鑰。以後雙方再使用對稱祕鑰進行通訊。這樣即解決了對稱祕鑰加密的祕鑰傳輸問題，又利用了對稱祕鑰的高效率來進行通訊內容的加密與解密。

Https的認證

SSL\TLS 採用的混合加密的方式仍是存在一個問題，即怎麼樣確保用於加密的公開祕鑰確實是所指望的服務器所分發的呢？也許在收到公開祕鑰時，這個公開祕鑰已經被別人篡改了。所以，咱們還須要對這個祕鑰進行認證的能力，以確保咱們通訊的對方是咱們所指望的對象。

目前的作法是使用由數字證書認證機構頒發的公開祕鑰證書。服務器的運營人員能夠向認證機構提出公開祕鑰申請。認證機構在審覈以後，會將公開祕鑰與共鑰證書綁定。服務器就能夠將這個共鑰證書下發給客戶端，客戶端在收到證書後，使用認證機構的公開祕鑰進行驗證。一旦驗證成功，便可知道這個祕鑰是能夠信任的祕鑰。