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

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

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

get 和 post 的區(qū)別？

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

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

首先看一張圖

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

請(qǐng)求報(bào)文

請(qǐng)求行     
請(qǐng)求頭   
請(qǐng)求體   

響應(yīng)報(bào)文

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

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

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

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

 請(qǐng)求地址

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

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

請(qǐng)求方法（method）

列舉幾個(gè)比較常用的

Post 和 Get 的區(qū)別

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

Post 相對(duì) Get 安全一點(diǎn)點(diǎn)，因?yàn)?Get 請(qǐng)求都包含在 URL 里

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

常見(jiàn)狀態(tài)碼

2XX 成功

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

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

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

3XX 重定向

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

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

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

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

307 temporary redirect，臨時(shí)重定向，和302含義相同

4XX 客戶(hù)端錯(cuò)誤

400 bad request，請(qǐng)求報(bào)文存在語(yǔ)法錯(cuò)誤

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

403 forbidden，表示對(duì)請(qǐng)求資源的訪問(wèn)被服務(wù)器拒絕

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

5XX 服務(wù)器錯(cuò)誤

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

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

請(qǐng)求和響應(yīng)常見(jiàn)通用的 Header

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

Cache-Control

no-cache 指客戶(hù)端不緩存過(guò)期資源

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

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

Connection

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

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

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

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

常見(jiàn)的請(qǐng)求 Header

Accept 指用戶(hù)代理能夠處理的媒體類(lèi)型及媒體類(lèi)型的相對(duì)優(yōu)先級(jí)

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

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

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

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

Http 與 Https 的區(qū)別

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

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

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

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

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

因此，在一些需要保證安全性的場(chǎng)景下，比如涉及到銀行賬戶(hù)的請(qǐng)求時(shí)，Http 無(wú)法抵御這些攻擊。

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

Https 的加密

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

對(duì)稱(chēng)秘鑰加密

非對(duì)稱(chēng)秘鑰加密

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

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

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

Https的認(rèn)證

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

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