企業(yè)建站知識(shí) 推廣知識(shí) 小程序微信營(yíng)銷 APP開發(fā) 前端設(shè)計(jì) MindManager 開發(fā)語(yǔ)言自媒體

《圖解HTTP》讀書筆記（三）

發(fā)表日期：2017-09 文章編輯：小燈瀏覽次數(shù)：2742

前面兩篇文章中關(guān)于 HTTP 相關(guān)知識(shí)基本上介紹的差不多了，這篇文章是對(duì) HTTP 協(xié)議的補(bǔ)充，主要介紹以下三點(diǎn)內(nèi)容：

確保 Web 安全的 HTTPS
確認(rèn)訪問用戶身份的認(rèn)證
基于 HTTP 的功能追加協(xié)議

1.確保 Web 安全的 HTTPS

1.1 HTTP 的缺點(diǎn)

HTTP 的不足主要有以下幾點(diǎn)：

通信使用明文（不加密），內(nèi)容可能會(huì)被竊聽
不驗(yàn)證通信方的身份，因此有可能遭遇偽裝
無法證明報(bào)文的完整性，所以有可能已遭篡改

這些問題不僅在 HTTP 上出現(xiàn)，其他未加密的協(xié)議中也會(huì)存在這類問題。

1.1.1 通信使用明文可能會(huì)被竊聽

由于 HTTP 本身不具備加密的功能，所以也無法做到對(duì)通信整體（使用 HTTP 協(xié)議通信的請(qǐng)求和響應(yīng)的內(nèi)容）進(jìn)行加密。即，HTTP 報(bào)文使用明文（指未經(jīng)加密的報(bào)文）方式發(fā)送。

TCP/IP 是可能被竊聽的網(wǎng)絡(luò)

因?yàn)榘?TCP/IP 協(xié)議族的工作機(jī)制，通信內(nèi)容在所有的通信線路上都有可能遭遇到窺視，所以說通信不加密是一個(gè)缺點(diǎn)。

即使已經(jīng)過加密處理的通信，也會(huì)被窺視到通信內(nèi)容，這點(diǎn)和未加密的通信是相同的。只是說如果通信經(jīng)過加密，就有可能讓人無法破解報(bào)文信息的含義，但加密處理后的報(bào)文信息本身還是會(huì)被看到的。

竊聽相同段上的通信并非難事。只需要收集在互聯(lián)網(wǎng)上流動(dòng)的數(shù)據(jù)包（幀）就行了。對(duì)于收集來的數(shù)據(jù)包的解析工作，可交給那些抓包或嗅探器工具。

http-defect.png

加密處理防止被竊聽

通信的加密

一種方式是將通信加密。HTTP 協(xié)議中沒有加密機(jī)制，但可以通過和 SSL（Secure Socket Layer，安全套接層）或 TLS（Transport Layer Security，安全傳輸層協(xié)議）的組合使用，加密 HTTP 的通信內(nèi)容。

http_encrypt.png

用 SSL 建立安全通信線路之后，就可以在這條線路上進(jìn)行 HTTP 通信了。與 SSL 組合使用的 HTTP 被稱為 HTTPS （HTTP Secure，超文本傳輸安全協(xié)議）或 HTTP over SSL。

內(nèi)容的加密
還有一種將參與通信的內(nèi)容本身加密的方式。由于 HTTP 協(xié)議中沒有加密機(jī)制，那么就對(duì) HTTP 協(xié)議傳輸?shù)膬?nèi)容本身加密。即把 HTTP 報(bào)文里所含的內(nèi)容進(jìn)行加密處理。

http_encrypt1.png

誠(chéng)然，為了做到有效的內(nèi)容加密，前提是要求客戶端和服務(wù)器同時(shí)具備加密和解密機(jī)制。主要應(yīng)用在 Web 服務(wù)中。有一點(diǎn)必須引起注意，由于該方式不同于 SSL 或 TLS 將整個(gè)通信線路加密處理，所以內(nèi)容仍有被篡改的風(fēng)險(xiǎn)。

1.1.2 不驗(yàn)證通信方的身份就可能遭遇篡改

HTTP 協(xié)議中的請(qǐng)求和響應(yīng)不會(huì)對(duì)通信方進(jìn)行確認(rèn)。也就是說存在"服務(wù)器是否就是發(fā)送請(qǐng)求中 URI 真正指定的主機(jī)，返回的響應(yīng)是否真的返回到實(shí)際提出請(qǐng)求的客戶端"等類似問題。

任何人都可發(fā)起請(qǐng)求

在 HTTP 協(xié)議通信時(shí)，由于不存在確認(rèn)通信方的處理步驟，任何人都可以發(fā)起請(qǐng)求。另外，服務(wù)器只要接收到請(qǐng)求，不管對(duì)方是誰都會(huì)返回一個(gè)響應(yīng)（但也僅限于發(fā)送端的 IP 地址和端口號(hào)沒有被 Web 服務(wù)器設(shè)定限制訪問的前提下）。

http_request_all.png

HTTP 協(xié)議的實(shí)現(xiàn)本身非常簡(jiǎn)單，不論是誰發(fā)送過來的請(qǐng)求都會(huì)返回響應(yīng)，因此不確認(rèn)通信方，會(huì)存在以下各種隱患：

無法確定請(qǐng)求發(fā)送至目標(biāo)的 Web 服務(wù)器是否是按真實(shí)意圖返回響應(yīng)的那臺(tái)服務(wù)器。有可能是已偽裝的 Web 服務(wù)器。
無法確定響應(yīng)返回到的客戶端是否是按真實(shí)意圖接收響應(yīng)的那個(gè)客戶端。有可能是已偽裝的客戶端。
無法確定正在通信的對(duì)方是否具備訪問權(quán)限。因?yàn)槟承?Web 服務(wù)器上保存著重要的信息，只想發(fā)給特定用戶通信的權(quán)限。
無法判定請(qǐng)求是來自何方、出自誰手。
即使是無意義的請(qǐng)求也會(huì)照單全收。無法阻止海量請(qǐng)求下的 DoS 攻擊。

查明對(duì)手的證書

雖然使用 HTTP 協(xié)議無法確定通信方，但如果使用 SSL 則可以。SSL 不僅提供加密處理，而且還使用一種被稱為證書的手段，可用于確定方。

證書由值得信任的第三方機(jī)構(gòu)頒發(fā)，用以證明服務(wù)器和客戶端是實(shí)際存在的。

http_request.png

通過使用證書，以證明通信方就是意料中的服務(wù)器。這對(duì)使用者個(gè)人來講，也減少了個(gè)人信息泄露的危險(xiǎn)性。另外，客戶端持有證書即可完成個(gè)人身份的確認(rèn)，也可用于對(duì) Web 網(wǎng)站的認(rèn)證環(huán)節(jié)。

1.1.3 無法證明報(bào)文完整性，可能已遭篡改

所謂完整性是指信息的準(zhǔn)確度。若無法證明其完整性，通常也就意味著無法判斷信息是否準(zhǔn)確。

接收到的內(nèi)容可能有誤
由于 HTTP 協(xié)議無法證明通信的報(bào)文的完整性，因此，沒有任何辦法確認(rèn)，發(fā)出的請(qǐng)求/響應(yīng)和接收到的請(qǐng)求/響應(yīng)是前后相同的。

http_revise.png

像這樣，請(qǐng)求或響應(yīng)在傳輸途中，遭攻擊者攔截并篡改內(nèi)容的攻擊稱為中間人攻擊。

http_revise1.png

如何防止篡改

雖然有使用 HTTP 協(xié)議確認(rèn)報(bào)文完整性的方法，但事實(shí)上并不便捷、可靠。其中常用的是 MD5 和 SHA-1 等散列值校驗(yàn)的方法，以及用來確認(rèn)文件的數(shù)字簽名方法。

提供文件下載服務(wù)的 Web 網(wǎng)站也會(huì)提供相應(yīng)的以 PGP（Pretty Good Privacy，完美隱私）創(chuàng)建的數(shù)字簽名及 MD5 算法生成的散列值。PGP 是用來證明創(chuàng)建文件的數(shù)字簽名，MD5 是由單向函數(shù)生成的散列值。不論使用哪一種方法，都需要操縱客戶端的用戶本人親自檢查驗(yàn)證下載的文件是否就是原來服務(wù)器上的文件。瀏覽器無法自動(dòng)幫用戶檢查。

可惜的是，這些辦法也依然無法百分之百保證確認(rèn)結(jié)果正確。因?yàn)?PGP 和 MD5 本身被改寫的話，用戶是沒有辦法意識(shí)到的。

為了有效防止這些弊端，有必要使用 HTTPS。SSL 提供認(rèn)證和加密處理及摘要功能。僅靠 HTTP 確保完整性是非常困難的，因此通過和其他協(xié)議組合使用來實(shí)現(xiàn)這個(gè)目標(biāo)。

1.2 HTTP + 加密 + 認(rèn)證 + 完整性保護(hù) = HTTPS

1.2.1 HTTP 加上加密處理和認(rèn)證及完整性保護(hù)后即是 HTTPS

如果在 HTTP 協(xié)議通信過程中使用未經(jīng)加密的明文，比如在 Web 頁(yè)面中輸入信用卡號(hào)，如果這條通信線路遭到竊聽，那么信用卡號(hào)就暴露了。

另外，對(duì)于 HTTP 來說，服務(wù)器也好，客戶端也好，都是沒有辦法確認(rèn)通信方的。因?yàn)楹苡锌赡懿⒉皇呛驮瓉眍A(yù)想的通信方在實(shí)際通信。并且還需要考慮到接收到的報(bào)文在通信途中已經(jīng)遭到篡改這一可能性。

為了統(tǒng)一解決上述這些問題，需要在 HTTP 上再加入加密處理和認(rèn)證等機(jī)制。我們把添加了加密及認(rèn)證機(jī)制的 HTTP 稱為 HTTPS（HTTP Secure）。

https.png

1.2.2 HTTPS 是身披 SSL 外殼的 HTTP

HTTPS 并非是應(yīng)用層的一種新協(xié)議。只是 HTTP 通信接口部分用 SSL（Secure Socket Layer）和TLS（Transport Layer Security）協(xié)議代替而已。

通常，HTTP 直接和 TCP 通信。當(dāng)使用 SSL 時(shí)，則演變成先和 SSL 通信，再由 SSL 和 TCP 通信了。簡(jiǎn)言之，所謂 HTTPS，其實(shí)就是身披 SSL 外殼的 HTTP。

https1.png

在采用 SSL 后，HTTP 就擁有了 HTTPS 的加密、證書和完整性保護(hù)這些功能。

SSL 是獨(dú)立于 HTTP 的協(xié)議，所以不光是 HTTP 協(xié)議，其他運(yùn)行在應(yīng)用層的 SMTP 和 Telnet 等協(xié)議均可配合 SSL 協(xié)議使用?？梢哉f SSL 是當(dāng)今世界上應(yīng)用最為廣泛的網(wǎng)絡(luò)安全技術(shù)。

1.2.3 相互交換密鑰的公開密鑰加密技術(shù)

SSL 采用一種叫做公開密鑰加密的加密處理方式。

近代的加密方法中的加密算法是公開的，而密鑰確實(shí)保密的。通過這種方式得以保持加密方法的安全性。

加密和解密都會(huì)用到密鑰。沒有密鑰就無法對(duì)密碼解密，反過來說，任何人只要持有密鑰就能解密了。如果密鑰被攻擊者獲得，那加密也就失去了意義。

共享密鑰加密的困境
加密和解密同用一個(gè)密鑰的方式叫做共享密鑰加密，也被稱為對(duì)稱密鑰加密。

https2.png

以共享密鑰方式加密時(shí)必須將密鑰也給對(duì)方。可究竟怎樣才能安全的轉(zhuǎn)交？在互聯(lián)網(wǎng)上轉(zhuǎn)發(fā)密鑰時(shí)，如果通信被監(jiān)聽那么密鑰就可會(huì)落入攻擊者之手，同時(shí)也就失去了加密的意義。另外還得設(shè)法安全地保管接收到的密鑰。

https3.png

使用兩把密鑰的公開密鑰加密

公開密鑰加密方式很好地解決了共享密鑰加密的困難。

公開密鑰加密使用一對(duì)非對(duì)稱的密鑰。一把叫做私有密鑰，另一把叫做公開密鑰。私有密鑰不能讓其他任何人知道，而公有密鑰則可以隨意發(fā)布，任何人都可以獲得。

使用公開密鑰加密方式，發(fā)送密文的一方使用對(duì)方的公開密鑰進(jìn)行加密處理，對(duì)方收到被加密的信息后，再使用自己的私有密鑰進(jìn)行解密。利用這種方式，不需要發(fā)送用來解密的私有密鑰，也不必?fù)?dān)心密鑰被攻擊者竊聽而盜走。

另外，要想根據(jù)密文和公開密鑰，恢復(fù)到信息原文是異常困難的，因?yàn)榻饷苓^程就是在對(duì)離散對(duì)數(shù)進(jìn)行求值，這并非輕而易舉就能辦到。

https4.png

HTTPS 采用混合加密機(jī)制
HTTPS 采用共享密鑰加密和公開密鑰加密兩者并用的混合加密機(jī)制。若密鑰能夠?qū)崿F(xiàn)安全交換，那么有可能會(huì)考慮僅使用公開密鑰加密來通信。但是公開密鑰加密和共享密鑰加密相比，其處理速度要慢。

所以應(yīng)充分利用兩者各自的優(yōu)勢(shì)，將多種方法組合起來用于通信。在交換密鑰環(huán)節(jié)使用公開密鑰加密方式，之后的建立通信交換報(bào)文階段則使用共享密鑰加密方式。

https5.png

1.2.4 證明公開密鑰正確性的證書

在公開密鑰加密方式中也存在一些問題，那就是無法證明公開密鑰本身就是貨真價(jià)實(shí)的公開密鑰。

為了解決上述問題，可以使用由數(shù)字證書認(rèn)證機(jī)構(gòu)（CA，Certificate Authority）和其他相關(guān)頒發(fā)的公開密鑰證書。

數(shù)字證書認(rèn)證機(jī)構(gòu)處于客戶端和服務(wù)器雙方都可信賴的第三方機(jī)構(gòu)的立場(chǎng)上。數(shù)字證書認(rèn)證機(jī)構(gòu)的流程是：首先，服務(wù)器的運(yùn)營(yíng)人員向數(shù)字證書認(rèn)證機(jī)構(gòu)提供公開密鑰的申請(qǐng)。數(shù)字證書認(rèn)證機(jī)構(gòu)在判明提出申請(qǐng)者的身份之后，會(huì)對(duì)已申請(qǐng)的公開密鑰做數(shù)字簽名，然后分配這個(gè)已簽名的公開密鑰，并將該公開密鑰放入公鑰證書后綁定在一起。

服務(wù)器會(huì)將這份由數(shù)字證書認(rèn)證機(jī)構(gòu)頒發(fā)的公鑰證書發(fā)送給客戶端，以進(jìn)行公開密鑰加密方式通信。公鑰證書也可叫做數(shù)字證書或直接稱為證書。

接到證書的客戶端可使用數(shù)字證書認(rèn)證機(jī)構(gòu)的公開密鑰，對(duì)那張證書上的數(shù)字簽名進(jìn)行驗(yàn)證，一旦驗(yàn)證通過，客戶端便可明確兩件事：一，認(rèn)證服務(wù)器的公開密鑰的是真實(shí)有效的數(shù)字證書認(rèn)證機(jī)構(gòu)。二，服務(wù)器的公開密鑰是值得信賴的。

https6.png

可證明組織真實(shí)性的 EV SSL 證書
證書的一個(gè)作用是用來證明作為通信一方的服務(wù)器是否規(guī)范，另外一個(gè)作用是可確認(rèn)對(duì)方服務(wù)器背后運(yùn)營(yíng)的企業(yè)是否真實(shí)存在。擁有該特性的證書是 EV SSL 證書。

EV SSL 證書是基于國(guó)際標(biāo)準(zhǔn)的認(rèn)證指導(dǎo)方針頒發(fā)的證書。其嚴(yán)格規(guī)定了對(duì)運(yùn)營(yíng)組織是否真實(shí)的確認(rèn)方針，因此，通過認(rèn)證的 Web 網(wǎng)站能夠獲得更高的認(rèn)可度。
用以確認(rèn)客戶端的客戶端證書

HTTPS 中還可以使用客戶端證書。以客戶端證書進(jìn)行客戶端認(rèn)證，證明服務(wù)器正在通信的對(duì)方始終是預(yù)料之內(nèi)的客戶端，其作用跟服務(wù)器證書如出一轍。
認(rèn)證機(jī)構(gòu)信譽(yù)第一
SSL 機(jī)制中介入認(rèn)證機(jī)構(gòu)之所以可行，是因?yàn)榻⒃谄湫庞媒^對(duì)可靠這一大前提下的。
由自認(rèn)證機(jī)構(gòu)頒發(fā)的證書稱為自簽名證書
如果使用 OpenSSL 這套開源程序，每個(gè)人都可以構(gòu)建一套屬于自己的認(rèn)證機(jī)構(gòu)，從而給自己頒發(fā)服務(wù)器證書。但該服務(wù)器證書在互聯(lián)網(wǎng)上不可作為證書使用，似乎沒什么幫助的。

獨(dú)立機(jī)構(gòu)的認(rèn)證機(jī)構(gòu)叫做自認(rèn)證機(jī)構(gòu)，由自認(rèn)證機(jī)構(gòu)頒發(fā)的“無用”證書也被戲稱為自簽名證書。

1.2.5 HTTPS 的安全通信機(jī)制

為了更好的理解 HTTPS，我們來觀察一下 HTTPS 的通信步驟。

https7.png

步驟1：客戶端通過發(fā)送 Client Hello 報(bào)文開始 SSL 通信。報(bào)文中包含客戶端支持的 SSL 的指定版本、加密組件（Cipher Suite）列表（所使用的加密算法及密鑰長(zhǎng)度等）。
步驟2：服務(wù)器可進(jìn)行 SSL 通信時(shí)，會(huì)以 Server Hello 報(bào)文作為應(yīng)答。和客戶端一樣，在報(bào)文中包含 SSL 版本以及加密組件。服務(wù)器的加密組件內(nèi)容是從接收到的客戶端加密組件內(nèi)篩選出來的。
步驟3：之后服務(wù)器發(fā)送 Certificate 報(bào)文。報(bào)文中包含公開密鑰證書。
步驟4：最后服務(wù)器發(fā)送 Server Hello Done 報(bào)文通知客戶端，最初階段的 SSL 握手協(xié)商部分結(jié)束。
步驟5：SSL 第一次握手結(jié)束之后，客戶端以 Client Key Exchange 報(bào)文作為回應(yīng)。報(bào)文中包含通信加密中使用的一種被稱為 Pre-master secret 的隨機(jī)密碼串。該報(bào)文已用步驟 3 中的公開密鑰進(jìn)行加密。
步驟6：接著客戶端繼續(xù)發(fā)送 Change Cipher Spec 報(bào)文。該報(bào)文會(huì)提示服務(wù)器，在此報(bào)文之后的通信會(huì)采用 Pre-master secret密鑰加密。
步驟7：客戶端發(fā)送 Finished 報(bào)文。該報(bào)文包含連接至今全部報(bào)文的整體校驗(yàn)值。這次握手協(xié)商是否能夠成功，要以服務(wù)器是否能夠正確解密該報(bào)文作為判定標(biāo)準(zhǔn)。
步驟8：服務(wù)器同樣發(fā)送 Change Cipher Spec 報(bào)文。
步驟9：服務(wù)器同樣發(fā)送 Finished 報(bào)文。
步驟10：服務(wù)器和客戶端的 Finished 報(bào)文交換完畢之后，SSL 連接就算建立完畢。當(dāng)然，通信會(huì)受到 SSL 的保護(hù)。從此處開始進(jìn)行應(yīng)用層協(xié)議的通信，即發(fā)送 HTTP 請(qǐng)求。
步驟11：應(yīng)用協(xié)議通信，即發(fā)送 HTTP 響應(yīng)。
步驟12：最后由客戶端斷開連接。斷開連接時(shí)，發(fā)送 close_notify 報(bào)文。

在以上流程中，應(yīng)用層發(fā)送數(shù)據(jù)時(shí)會(huì)附加一種叫做 MAC（Message Authentication Code）的報(bào)文摘要。MAC 能夠查知報(bào)文是否遭到篡改，從而保護(hù)報(bào)文的完整性。

下面是對(duì)整個(gè)流程的圖解。圖中說明了從僅適用服務(wù)器端的公開密鑰證書（服務(wù)器證書）建立 HTTPS 通信的整個(gè)過程。

https8.png

SSL 速度慢嗎
HTTPS 也存在一些問題，那就是當(dāng)使用 SSL 時(shí)，它的處理速度會(huì)變慢。

https9.png

SSL 的慢是分兩種。一種是指通信慢。另一種是指由于大量消耗 CPU 及內(nèi)存等資源，導(dǎo)致處理速度變慢。

和使用 HTTP 相比，網(wǎng)絡(luò)負(fù)載可能會(huì)變慢 2 到 100 倍。除去和 TCP 連接、發(fā)送 HTTP 請(qǐng)求/響應(yīng)外，還必須進(jìn)行 SSL 通信，因此整體上處理通信量不可避免會(huì)增加。

另一點(diǎn)是 SSL 必須進(jìn)行加密處理。在服務(wù)器和客戶端都需要進(jìn)行加密和解密的運(yùn)算處理。因此從結(jié)果上講，比起 HTTP 會(huì)更多地消耗服務(wù)器和客戶端的硬件資源，導(dǎo)致負(fù)載增強(qiáng)。

針對(duì)速度變慢這一問題，并沒有根本性的解決方案，我們會(huì)使用 SSL 加速器這種（專用服務(wù)器）硬件來改善該問題。該硬件為 SSL 通信專用硬件，相對(duì)軟件來講，能夠提高數(shù)倍 SSL 的計(jì)算速度。僅在 SSL 處理時(shí)發(fā)揮 SSL 加速器的功效，以分擔(dān)負(fù)載。

為什么不一直使用 HTTPS
1. 因?yàn)榕c純文本通信相比，加密通信會(huì)消耗更多的 CPU 及內(nèi)存資源。如果每次通信都加密，會(huì)消耗相當(dāng)多的資源，平攤到一臺(tái)計(jì)算機(jī)上時(shí)，能夠處理的請(qǐng)求數(shù)量也必然減少。

因此，如果是非敏感信息則使用 HTTP 通信，只有在包含個(gè)人信息等敏感數(shù)據(jù)時(shí)，才利用 HTTPS 加密通信。
2. 除此之外，想要節(jié)約購(gòu)買證書的開銷也是原因之一。

2. 確認(rèn)訪問用戶身份的認(rèn)證

2.1 何為認(rèn)證

計(jì)算機(jī)本身無法判斷坐在顯示器前的使用者的身份，為了確認(rèn)是誰在訪問服務(wù)器，需要核對(duì)“登錄者本人才知道的信息”、“登錄者本人才會(huì)有的信息”。核對(duì)的信息通常是指以下這些：

密碼：只有本人才會(huì)知道的字符串信息。
動(dòng)態(tài)令牌：僅限本人持有的設(shè)備內(nèi)顯示的一次性密碼。
數(shù)字證書：僅限本人（終端）持有的信息。
生物認(rèn)證：指紋和虹膜等本人的生理信息
IC 卡等：僅限本人持有的信息。

HTTP 使用的認(rèn)證方式
HTTP/1.1 使用的認(rèn)證方式如下所示：

BASIC認(rèn)證（基本認(rèn)證）
DIGEST認(rèn)證（摘要認(rèn)證）
SSL 客戶端認(rèn)證
FormBase 認(rèn)證（基于表單認(rèn)證）

2.2 BASIC 認(rèn)證

BASIC 認(rèn)證（基本認(rèn)證）是從 HTTP/1.0 就定義的認(rèn)證方式。即便是現(xiàn)在仍有一部分的網(wǎng)站會(huì)使用這種認(rèn)證方式。是 Web 服務(wù)器與通信客戶端之間進(jìn)行的認(rèn)證方式。

BASIC 認(rèn)證的認(rèn)證步驟

basic.png

步驟1：當(dāng)請(qǐng)求的資源需要 BASIC 認(rèn)證時(shí)，服務(wù)器會(huì)隨狀態(tài)碼 401 Authorization Required，返回帶 WWW-Authenticate 首部字段的響應(yīng)。該字段內(nèi)包含認(rèn)證的方式（BASIC）及 Request-URI 安全域字符串（realm）。

步驟2：接收到狀態(tài)碼 401 的客戶端為了通過 BASIC 認(rèn)證，需要將用戶 ID 及密碼發(fā)送給服務(wù)器。發(fā)送的字符串內(nèi)容是由用戶 ID 和密碼構(gòu)成，兩者中間以冒號(hào)（：）連接后，再經(jīng)過 Base64 編碼處理。將編碼后的字符串寫入首部字段 Authorization 后，發(fā)送請(qǐng)求。

步驟3：接收到包含首部字段 Authorization 請(qǐng)求的服務(wù)器，會(huì)對(duì)認(rèn)證信息的正確性進(jìn)行驗(yàn)證。如驗(yàn)證通過，則返回一條包含 Request-URI 資源的響應(yīng)。

BASIC 認(rèn)證雖然采用 Base64 編碼方式，但這不是加密處理。不需要任何附加信息即可對(duì)其解密。換言之，由于明文解碼后就是用戶 ID 和密碼，在 HTTP 等非加密通信的線路上進(jìn)行 BASIC 認(rèn)證的過程中，如果被人竊聽，被盜的可能性極高。

另外，除此之外想再進(jìn)行一次 BASIC 認(rèn)證時(shí)，一般的瀏覽器卻無法實(shí)現(xiàn)認(rèn)證注銷操作，這也是問題之一。

BASIC 認(rèn)證使用上不夠靈活，且達(dá)不到多數(shù) Web 網(wǎng)站期望的安全性等級(jí)，因此它并不常用。

2.3 DIGEST 認(rèn)證

為彌補(bǔ) BASIC 認(rèn)證存在的弱點(diǎn)，從 HTTP/1.1 起就有了 DIGEST 認(rèn)證。DIGEST 認(rèn)證同樣使用質(zhì)詢/響應(yīng)的方式（challenge/response），但不會(huì)像 BASIC 認(rèn)證那樣直接發(fā)送明文密碼。

所謂質(zhì)詢響應(yīng)方式是指，一開始一方會(huì)先發(fā)送認(rèn)證要求給另一方，接著使用從另一方那接收到的咨詢碼計(jì)算生成響應(yīng)碼。最后將響應(yīng)碼返回給對(duì)方進(jìn)行認(rèn)證的方式。

digest.png

因?yàn)榘l(fā)送給對(duì)方的只是響應(yīng)摘要及由知訊碼產(chǎn)生的計(jì)算結(jié)果，所以比起 BASIC 認(rèn)證，密碼泄露的可能性就降低了。

DIGEST 認(rèn)證的認(rèn)證步驟

digest1.png

步驟1：請(qǐng)求需認(rèn)證的資源時(shí)，服務(wù)器會(huì)隨著狀態(tài)碼 401 Authorication Required，返回帶WWW-Authenticate 首部字段的響應(yīng)。該字段內(nèi)包含質(zhì)問響應(yīng)方式認(rèn)證所需要的臨時(shí)咨詢碼（隨機(jī)數(shù)，nonce）。

首部字段 WWW-Authenticate 內(nèi)必須包含 realm 和 nonce 這兩個(gè)字段的信息?？蛻舳司褪且揽肯蚍?wù)器回送這兩個(gè)值進(jìn)行認(rèn)證的。

nonce 是一種每次隨返回的 401 響應(yīng)生成的任意隨機(jī)字符串。該字符串通常推薦由 Base64 編碼的十六進(jìn)制數(shù)的組成形式，但實(shí)際內(nèi)容依賴服務(wù)器的具體實(shí)現(xiàn)

步驟2：接收到401 狀態(tài)碼的客戶端，返回的響應(yīng)中包含 DIGEST 認(rèn)證必須的首部字段 Authorization 信息。首部字段 Authorization 內(nèi)必須包含 username、realm、nonce、uri 和 response 的字段信息，其中，realm 和 nonce 就是之前從服務(wù)器接收到的響應(yīng)中的字段。

步驟3：接收到包含首部字段 Authorization 請(qǐng)求的服務(wù)器，會(huì)確認(rèn)認(rèn)證信息的正確性。認(rèn)證通過后則會(huì)返回包含 Request-URI 資源的響應(yīng)。

并且這時(shí)會(huì)在首部字段 Authorization-Info 寫入一些認(rèn)證成功的相關(guān)信息。

2.4 SSL 客戶端認(rèn)證

SSL 客戶端認(rèn)證是借由 HTTPS 的客戶端證書完成認(rèn)證的方式。憑借客戶端證書認(rèn)證，服務(wù)器可確認(rèn)訪問是否來自登錄的客戶端。

2.4.1 SSL 客戶端認(rèn)證的認(rèn)證步驟

為達(dá)到 SSL 客戶端認(rèn)證的目的，需要事先將客戶端證書分發(fā)給客戶端，且客戶端必須安裝此證書。

步驟1：接收到需要認(rèn)證資源的請(qǐng)求，服務(wù)器會(huì)發(fā)送 Certificate Request 報(bào)文，要求客戶端提供客戶端證書。

步驟2：用戶選擇將發(fā)送的客戶端證書后，客戶端會(huì)把客戶端證書信息以 Client Certificate 報(bào)文方式發(fā)送給服務(wù)器。

步驟3：服務(wù)器驗(yàn)證客戶端證書驗(yàn)證通過后方可領(lǐng)取證書內(nèi)客戶端的公開密鑰，然后開始 HTTPS 加密通信。

2.4.2 SSL 客戶端認(rèn)證采用雙因素認(rèn)證

在多數(shù)情況下，SSL 客戶端認(rèn)證不會(huì)僅依靠證書完成認(rèn)證，一般會(huì)和基于表單認(rèn)證組合形成一種雙因素認(rèn)證來使用。所謂雙因素認(rèn)證就是指，認(rèn)證過程中不僅需要密碼這一個(gè)因素，還需要申請(qǐng)認(rèn)證者提供其他持有信息，從而作為另一個(gè)因素，與其組合使用的認(rèn)證方式。

換言之，第一個(gè)認(rèn)證因素的 SSL 客戶端證書用來認(rèn)證客戶端計(jì)算機(jī)，另一個(gè)認(rèn)證因素的密碼則用來確定這是用戶本人的行為。

2.4.3 SSL 客戶端認(rèn)證必要的費(fèi)用

使用 SSL 客戶端認(rèn)證需要用到客戶端證書，而客戶端證書需要支付一定費(fèi)用才能使用。

2.5 基于表單認(rèn)證

基于表單的認(rèn)證方法并不是在 HTTP 協(xié)議中定義的?？蛻舳藭?huì)向服務(wù)器上的 Web 應(yīng)用程序發(fā)送登錄信息，按登錄信息的驗(yàn)證結(jié)果認(rèn)證。

多數(shù)情況下，輸入已事先登錄的用戶 ID 和密碼等登錄信息后，發(fā)送給 Web 應(yīng)用程序，基于認(rèn)證結(jié)果來決定認(rèn)證是否成功。

2.5.1 Session 管理及 Cookie 應(yīng)用

基于表單認(rèn)證的標(biāo)準(zhǔn)規(guī)范尚未有定論，一般會(huì)使用 Cookie 來管理 Session（會(huì)話）。

基于表單認(rèn)證本身是通過服務(wù)器端的 Web 應(yīng)用，將客戶端發(fā)送過來的用戶 ID 和密碼與之前登錄過的信息做匹配來進(jìn)行認(rèn)證的。

但鑒于 HTTP 是無狀態(tài)協(xié)議，之前已認(rèn)證成功的用戶狀態(tài)無法通過協(xié)議層面保存下來。即，無法實(shí)現(xiàn)狀態(tài)管理，因此即使該用戶下一次繼續(xù)訪問，也無法區(qū)分他與其他的用戶。于是我們會(huì)使用 Cookie 來管理 Session，以彌補(bǔ) HTTP 協(xié)議中不存在的狀態(tài)管理功能。

cookie_session.png

步驟1：客戶端會(huì)把用戶 ID 和密碼等登錄信息放入報(bào)文的實(shí)體部分，通常是以 POST 方法把請(qǐng)求發(fā)送給服務(wù)器。而這時(shí)，會(huì)使用 HTTPS 通信來進(jìn)行 HTML 表單畫面的顯示和用戶輸入數(shù)據(jù)的發(fā)送。

步驟2：服務(wù)器會(huì)發(fā)放用以識(shí)別用戶的 Session ID。通過驗(yàn)證從客戶端發(fā)送過來的登錄信息進(jìn)行身份認(rèn)證，然后把用戶的認(rèn)證狀態(tài)和 Session ID 綁定后記錄在服務(wù)器端。

向客戶端返回響應(yīng)時(shí)，會(huì)在首部字段 Set-Cookie 內(nèi)寫入 Session ID。另外，為減輕跨站腳本攻擊（XSS）造成的損失，建議事先在 Cookie 內(nèi)加上 httponly 屬性。

步驟3：客戶端接收到從服務(wù)器端發(fā)來的 Session ID 后，會(huì)將其作為 Cookie 保存在本地。下次向服務(wù)器發(fā)送請(qǐng)求時(shí)，瀏覽器會(huì)自動(dòng)發(fā)送 Cookie，所以 Session ID 也隨之發(fā)送到服務(wù)器。服務(wù)器端可通過驗(yàn)證接收到的 Session ID 識(shí)別用戶和其認(rèn)證狀態(tài)。

3. 基于 HTTP 的功能追加協(xié)議

3.1 基于 HTTP 的協(xié)議

HTTP 功能上的不足可通過創(chuàng)建一套全新的協(xié)議來彌補(bǔ)。可是目前基于 HTTP 的 Web 瀏覽器的使用環(huán)境已遍布全球，因此無法完全拋棄 HTTP。有一些新協(xié)議的規(guī)則是基于 HTTP 的，并在此基礎(chǔ)上添加了新的功能。

3.2 消除 HTTP 瓶頸的 SPDY

Google 在 2010 年發(fā)布了 SPDY，其開發(fā)目標(biāo)旨在解決 HTTP 的性能瓶頸，縮短 Web 頁(yè)面的加載時(shí)間（50%）。

3.2.1 HTTP 的瓶頸

HTTP 存在以下缺點(diǎn)和不足：

一條連接上只可發(fā)送一個(gè)請(qǐng)求
請(qǐng)求只能從客戶端開始，客戶端不可以接收除響應(yīng)以外的指令
請(qǐng)求/響應(yīng)首部未經(jīng)壓縮就發(fā)送，首部信息越多延遲越大
發(fā)送冗長(zhǎng)的首部，每次互相發(fā)送相同的首部造成的浪費(fèi)較多
可任意選擇數(shù)據(jù)壓縮格式，非強(qiáng)制壓縮發(fā)送

http_weakness.png

Ajax 的解決辦法

Ajax 是一種有效利用 JavaScript 和 DOM 的操作，以達(dá)到局部 Web 頁(yè)面替換加載的異步通信手段。和以前的同步通信相比，由于它只更新一部分頁(yè)面，響應(yīng)中傳輸?shù)臄?shù)據(jù)量會(huì)因此而減少。

而利用 Ajax 實(shí)時(shí)地從服務(wù)器獲取內(nèi)容，有可能會(huì)導(dǎo)致大量請(qǐng)求產(chǎn)生。

http_ajax.png

Comet 的解決辦法
一旦服務(wù)器有內(nèi)容更新了，Comet 不會(huì)讓請(qǐng)求等待，而是直接給客戶端返回響應(yīng)。這是一種通過延時(shí)應(yīng)答，模擬實(shí)現(xiàn)服務(wù)器向客戶端推送的功能。

內(nèi)容上雖然可以做到實(shí)時(shí)更新，但為了保留響應(yīng)，一次連接的持續(xù)時(shí)間也變長(zhǎng)了。期間，為了維持連接會(huì)消耗更多的資源。

http_comet.png

3.2.2 SPDY 的設(shè)計(jì)與功能

SPDY 沒有完全改寫 HTTP 協(xié)議，而是在 TCP/IP 的應(yīng)用層與運(yùn)輸層之間通過新加會(huì)話層的形式運(yùn)作。同時(shí)，考慮到安全性問題，SPDY 規(guī)定通信中使用 SSL。

SPDY 以會(huì)話層的形式加入，控制對(duì)數(shù)據(jù)的流動(dòng)，但還是采用 HTTP 建立通信連接。因此，可照常使用 HTTP 的 GET 和 POST 等方法，Cookie 以及 HTTP 報(bào)文等。

spdy.png

使用 SPDY 后，HTTP 協(xié)議額外獲得以下功能。

多路復(fù)用流：通過單一的 TCP 連接，可以無限制處理多個(gè) HTTP 請(qǐng)求。所有請(qǐng)求的處理都在一條 TCP 連接上完成，因此 TCP 的處理效率得到提高。
賦予請(qǐng)求優(yōu)先級(jí)：SPDY 不僅可以無限制地并發(fā)處理請(qǐng)求，還可以給請(qǐng)求逐個(gè)分配優(yōu)先級(jí)順序。這樣主要是為了在發(fā)送多個(gè)請(qǐng)求時(shí)，解決因帶寬低而導(dǎo)致響應(yīng)變慢的問題。
壓縮 HTTP 首部：壓縮 HTTP 請(qǐng)求和響應(yīng)的首部。這樣一來，通信產(chǎn)生的數(shù)據(jù)包數(shù)量和發(fā)送的字節(jié)數(shù)就更少了
推送功能：支持服務(wù)器主動(dòng)向客戶端推送數(shù)據(jù)的功能。這樣，服務(wù)器可直接發(fā)送數(shù)據(jù)，而不必等待客戶端的請(qǐng)求。
服務(wù)器提示功能：服務(wù)器可以主動(dòng)提示客戶端請(qǐng)求所需的資源。

3.2.3 SPDY 消除 Web 瓶頸了嗎

因?yàn)?SPDY 基本上只是將多個(gè)域名（IP 地址）的通信多路復(fù)用，所以當(dāng)一個(gè) Web 網(wǎng)站上使用多個(gè)域名下的資源，改善效果就會(huì)收到限制。

3.3 使用瀏覽器進(jìn)行全雙工通信的 WebSocket

WebSocket 是為解決 HTTP 協(xié)議所面臨的困難的一種新的協(xié)議及 API。

3.3.1 WebSocket 的設(shè)計(jì)與功能

WebSocket，即 Web 瀏覽器與 Web 服務(wù)器之間全雙工通信標(biāo)準(zhǔn)。仍在開發(fā)中的 WebSocket 技術(shù)主要是為了解決 Ajax 和 Comet 里 XMLHttpRequest 附帶的缺陷所引起的問題。

3.3.2 WebSocket 協(xié)議

一旦 Web 服務(wù)器與客戶端之間建立起 WebSocket 協(xié)議的通信連接，之后所有的通信都依靠這個(gè)專用協(xié)議進(jìn)行。通信過程中可相互發(fā)送 JSON、XML、HTML 或圖片等任意格式的數(shù)據(jù)。

由于是建立在 HTTP 基礎(chǔ)上的協(xié)議，因此連接的發(fā)起方仍是客戶端，而一旦確立 WebSocket 通信連接，不論服務(wù)器還是客戶端，任意一方都可直接向?qū)Ψ桨l(fā)送報(bào)文。

下面我們列舉一下 WebSocket 協(xié)議的主要特點(diǎn)：

推送功能：支持由服務(wù)器向客戶端推送數(shù)據(jù)的推送功能
減少通信量：只要建立起 WebSocket 連接，就希望一直保持連接狀態(tài)。和 HTTP 相比，不但每次連接時(shí)的總開銷減少，而且由于 WebSocket 的首部信息很小，通信量也相應(yīng)較少了。

為了實(shí)現(xiàn) WebSocket 通信，在 HTTP 連接建立之后，需要完成一次 “握手” 的步驟。

握手·請(qǐng)求
為了實(shí)現(xiàn) WebSocket 通信，需要用到 HTTP 的 Upgrade 首部字段，告知服務(wù)器通信協(xié)議發(fā)送改變，已達(dá)到握手的目的。

“GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Origin: http://example.com Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13”

Sec-WebSocket-Protocol 字段內(nèi)記錄著握手過程中必不可少的鍵值，Sec-WebSocket-Protocol 字段內(nèi)記錄使用的子協(xié)議。

子協(xié)議按 WebSocket 協(xié)議標(biāo)準(zhǔn)在連接分開使用時(shí)，定義那些連接的名稱。

握手·響應(yīng)
對(duì)于之前的請(qǐng)求，返回狀態(tài)碼 101 Switching Protocols 的響應(yīng)。

“HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Protocol: chat”

Sec-WebSocket-Accept 的字段值是由握手請(qǐng)求中的 Sec-WebSocket-Accept 的字段值生成的。

成功握手確立 WebSocket 連接之后，通信時(shí)不再使用 HTTP 的數(shù)據(jù)幀，而采用 WebSocket 獨(dú)立的數(shù)據(jù)幀。

websocket.png

3.4 期盼已久的 HTTP/2.0

HTTP/2.0 在 2014 年 11 月實(shí)現(xiàn)標(biāo)準(zhǔn)化。

HTTP/2.0 的特點(diǎn)
HTTP/2.0 的目標(biāo)是改善用戶在使用 Web 時(shí)的速斷體驗(yàn)。

HTTP/2.0 圍繞著主要的 7 項(xiàng)技術(shù)進(jìn)行討論。

壓縮	SPDY、Friendly
多路復(fù)用	SPDY
TLS 義務(wù)化	Speed + Mobility
協(xié)商	Speed + Mobility
客戶端拉拽	Speed + Mobility
流量控制	SPDY
WebSocket	Speed + Mobility

本頁(yè)內(nèi)容由塔燈網(wǎng)絡(luò)科技有限公司通過網(wǎng)絡(luò)收集編輯所得，所有資料僅供用戶學(xué)習(xí)參考，本站不擁有所有權(quán)，如您認(rèn)為本網(wǎng)頁(yè)中由涉嫌抄襲的內(nèi)容，請(qǐng)及時(shí)與我們聯(lián)系，并提供相關(guān)證據(jù)，工作人員會(huì)在5工作日內(nèi)聯(lián)系您，一經(jīng)查實(shí)，本站立刻刪除侵權(quán)內(nèi)容。本文鏈接:http://caipiao93.cn/20442.html

上一篇：<CA和證書，SSL 下一篇：11、使用和配置更安全的https協(xié)議>