摘要：對于傳輸內(nèi)容的完整性沒有確認(rèn)的辦法，往往容易在傳輸過程中被劫持篡改。目前的做法是使用由數(shù)字證書認(rèn)證機構(gòu)頒發(fā)的公開秘鑰證書。

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

了解哪些響應(yīng)狀態(tài)碼？

get 和 post 的區(qū)別？

HTTP 和 HTTPS 的區(qū)別);

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

首先看一張圖

如果對網(wǎng)絡(luò)協(xié)議還不太熟悉的同學(xué)，建議看一下上一篇文章 Android 網(wǎng)絡(luò)基礎(chǔ)之網(wǎng)絡(luò)協(xié)議篇

請求報文

請求行     
請求頭   
請求體   

響應(yīng)報文

響應(yīng)狀態(tài)行   
響應(yīng)頭     
響應(yīng)體     

解釋一下各個標(biāo)簽：

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

 指協(xié)議版本，現(xiàn)在通常都是Http/1.1了

 請求地址

 指響應(yīng)狀態(tài)碼， 我們熟悉的200、404等等

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

請求方法（method）

列舉幾個比較常用的

Post 和 Get 的區(qū)別

Post 一般用于數(shù)據(jù)傳遞，Get 一般用于數(shù)據(jù)查詢

Post 相對 Get 安全一點點，因為 Get 請求都包含在 URL 里

Post 支持更多的編碼類型且不對數(shù)據(jù)類型限制

常見狀態(tài)碼

2XX 成功

200 OK，表示從客戶端發(fā)來的請求在服務(wù)器端被正確處理

204 No content，表示請求成功，但響應(yīng)報文不含實體的主體部分

206 Partial Content，進(jìn)行范圍請求

3XX 重定向

301 moved permanently，永久性重定向，表示資源已被分配了新的 URL

302 found，臨時性重定向，表示資源臨時被分配了新的 URL

303 see other，表示資源存在著另一個 URL，應(yīng)使用 GET 方法丁香獲取資源

304 not modified，表示服務(wù)器允許訪問資源，但因發(fā)生請求未滿足條件的情況

307 temporary redirect，臨時重定向，和302含義相同

4XX 客戶端錯誤

400 bad request，請求報文存在語法錯誤

401 unauthorized，表示發(fā)送的請求需要有通過 HTTP 認(rèn)證的認(rèn)證信息

403 forbidden，表示對請求資源的訪問被服務(wù)器拒絕

404 not found，表示在服務(wù)器上沒有找到請求的資源

5XX 服務(wù)器錯誤

500 internal sever error，表示服務(wù)器端在執(zhí)行請求時發(fā)生了錯誤

503 service unavailable，表明服務(wù)器暫時處于超負(fù)載或正在停機維護(hù)，無法處理請求

請求和響應(yīng)常見通用的 Header

指請求報文和響應(yīng)報文都可以使用的字段

Cache-Control

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

no-store 指不進(jìn)行緩存

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

Connection

指控制不再轉(zhuǎn)發(fā)給代理的首部字段（Hop-by-hop），管理持久連接

close 指服務(wù)器像明確斷開連接

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

Upgrade
可以用來指定一個完全不同的通信協(xié)議，對于這個字段，服務(wù)器可以返回101狀態(tài)碼

常見的請求 Header

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

Accept-Encoding 指用來告知服務(wù)器用戶代理支持的內(nèi)容編碼及內(nèi)容編碼的優(yōu)先級順序

Authorization 指用來告知服務(wù)器，用戶代理的認(rèn)證信息

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

User-Agent 會講創(chuàng)建請求的瀏覽器和用戶代理名稱等信息傳達(dá)給服務(wù)器

Http 與 Https 的區(qū)別

Http + 加密 + 認(rèn)證 + 完整性保護(hù) = Https

傳統(tǒng)的 Http 協(xié)議是一種應(yīng)用層的傳輸協(xié)議，Http 直接與 TCP 協(xié)議通信。其本身存在一些缺點：

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

Http 對于通信雙方都沒有進(jìn)行身份驗證，通信的雙方無法確認(rèn)對方是否是偽裝的客戶端或者服務(wù)端。

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

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

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

Https 的加密

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

對稱秘鑰加密

非對稱秘鑰加密

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

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

SSLTLS 的加密方式則是結(jié)合了兩種加密方式的優(yōu)點。首先采用非對稱秘鑰加密，將一個對稱秘鑰使用公開秘鑰加密后傳輸?shù)綄Ψ?。對方使用私有秘鑰解密，得到傳輸?shù)膶ΨQ秘鑰。之后雙方再使用對稱秘鑰進(jìn)行通信。這樣即解決了對稱秘鑰加密的秘鑰傳輸問題，又利用了對稱秘鑰的高效率來進(jìn)行通信內(nèi)容的加密與解密。

Https的認(rèn)證

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

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