摘要：對于傳輸內容的完整性沒有確認的辦法，往往容易在傳輸過程中被劫持篡改。目前的做法是使用由數字證書認證機構頒發的公開秘鑰證書。

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

了解哪些響應狀態碼？

get 和 post 的區別？

HTTP 和 HTTPS 的區別);

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

首先看一張圖

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

請求報文

請求行     
請求頭   
請求體   

響應報文

響應狀態行   
響應頭     
響應體     

解釋一下各個標簽：

 指請求方法，常用的主要是 Get、 Post、Head 還有其他一些我們這里就不說了，有興趣的可以自己查閱一下

 指協議版本，現在通常都是Http/1.1了

 請求地址

 指響應狀態碼， 我們熟悉的200、404等等

 原因短語，200 OK 、404 Not Found 這種后面的描述就是原因短語，通常不必太關注。

請求方法（method）

列舉幾個比較常用的

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

no-cache 指客戶端不緩存過期資源

no-store 指不進行緩存

max-age 指緩存資源的緩存時間比指定的值小，那么客戶端就接受緩存資源，且緩存服務器不對資源有效性進行再次確認

Connection

指控制不再轉發給代理的首部字段（Hop-by-hop），管理持久連接

close 指服務器像明確斷開連接

Keep-Alive 指保存持久連接，HTTP/1.1前默認連接是非持久性的，如需要保存持久連接，需要增加此字段

Upgrade
可以用來指定一個完全不同的通信協議，對于這個字段，服務器可以返回101狀態碼

常見的請求 Header

Accept 指用戶代理能夠處理的媒體類型及媒體類型的相對優先級

Accept-Encoding 指用來告知服務器用戶代理支持的內容編碼及內容編碼的優先級順序

Authorization 指用來告知服務器，用戶代理的認證信息

Host 當一個 IP 下存在多個域名時，幫助服務器知道要請求的具體主機

User-Agent 會講創建請求的瀏覽器和用戶代理名稱等信息傳達給服務器

Http 與 Https 的區別

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

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

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

Http 對于通信雙方都沒有進行身份驗證，通信的雙方無法確認對方是否是偽裝的客戶端或者服務端。

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

因此，在一些需要保證安全性的場景下，比如涉及到銀行賬戶的請求時，Http 無法抵御這些攻擊。

Https 則可以通過增加的 SSLTLS，支持對于通信內容的加密，以及對通信雙方的身份進行驗證。

Https 的加密

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

對稱秘鑰加密

非對稱秘鑰加密

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

非對稱秘鑰加密是指加密與解密使用兩把不同的秘鑰。這兩把秘鑰，一把叫公開秘鑰，可以隨意對外公開。一把叫私有秘鑰，只用于本身持有。得到公開秘鑰的客戶端可以使用公開秘鑰對傳輸內容進行加密，而只有私有秘鑰持有者本身可以對公開秘鑰加密的內容進行解密。這種方式克服了秘鑰交換的問題，但是相對于對稱秘鑰加密的方式，處理速度較慢。

SSLTLS 的加密方式則是結合了兩種加密方式的優點。首先采用非對稱秘鑰加密，將一個對稱秘鑰使用公開秘鑰加密后傳輸到對方。對方使用私有秘鑰解密，得到傳輸的對稱秘鑰。之后雙方再使用對稱秘鑰進行通信。這樣即解決了對稱秘鑰加密的秘鑰傳輸問題，又利用了對稱秘鑰的高效率來進行通信內容的加密與解密。

Https的認證

SSLTLS 采用的混合加密的方式還是存在一個問題，即怎么樣確保用于加密的公開秘鑰確實是所期望的服務器所分發的呢？也許在收到公開秘鑰時，這個公開秘鑰已經被別人篡改了。因此，我們還需要對這個秘鑰進行認證的能力，以確保我們通信的對方是我們所期望的對象。

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