前面兩篇文章中關于 HTTP 相關知識基本上介紹的差不多了蝌借，這篇文章是對 HTTP 協(xié)議的補充殿遂，主要介紹以下三點內(nèi)容：

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

1.確保 Web 安全的 HTTPS

1.1 HTTP 的缺點

HTTP 的不足主要有以下幾點：

• 通信使用明文（不加密）澄干，內(nèi)容可能會被竊聽
• 不驗證通信方的身份宫纬，因此有可能遭遇偽裝
• 無法證明報文的完整性训貌，所以有可能已遭篡改

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

1.1.1 通信使用明文可能會被竊聽

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

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

因為按 TCP/IP 協(xié)議族的工作機制，通信內(nèi)容在所有的通信線路上都有可能遭遇到窺視挫以，所以說通信不加密是一個缺點者蠕。

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

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

http-defect.png

2. 加密處理防止被竊聽

• 通信的加密

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

http_encrypt.png

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

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

http_encrypt1.png

誠然趁冈，為了做到有效的內(nèi)容加密，前提是要求客戶端和服務器同時具備加密和解密機制拜马。主要應用在 Web 服務中渗勘。有一點必須引起注意，由于該方式不同于 SSL 或 TLS 將整個通信線路加密處理俩莽，所以內(nèi)容仍有被篡改的風險旺坠。

1.1.2 不驗證通信方的身份就可能遭遇篡改

HTTP 協(xié)議中的請求和響應不會對通信方進行確認。也就是說存在"服務器是否就是發(fā)送請求中 URI 真正指定的主機扮超，返回的響應是否真的返回到實際提出請求的客戶端"等類似問題价淌。

• 任何人都可發(fā)起請求

  在 HTTP 協(xié)議通信時，由于不存在確認通信方的處理步驟瞒津，任何人都可以發(fā)起請求蝉衣。另外，服務器只要接收到請求巷蚪，不管對方是誰都會返回一個響應（但也僅限于發(fā)送端的 IP 地址和端口號沒有被 Web 服務器設定限制訪問的前提下）病毡。

http_request_all.png

HTTP 協(xié)議的實現(xiàn)本身非常簡單，不論是誰發(fā)送過來的請求都會返回響應屁柏，因此不確認通信方啦膜，會存在以下各種隱患：

1. 無法確定請求發(fā)送至目標的 Web 服務器是否是按真實意圖返回響應的那臺服務器。有可能是已偽裝的 Web 服務器淌喻。
2. 無法確定響應返回到的客戶端是否是按真實意圖接收響應的那個客戶端僧家。有可能是已偽裝的客戶端。
3. 無法確定正在通信的對方是否具備訪問權(quán)限裸删。因為某些 Web 服務器上保存著重要的信息八拱，只想發(fā)給特定用戶通信的權(quán)限。
4. 無法判定請求是來自何方涯塔、出自誰手肌稻。
5. 即使是無意義的請求也會照單全收。無法阻止海量請求下的 DoS 攻擊匕荸。

• 查明對手的證書

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

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

http_request.png

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

1.1.3 無法證明報文完整性泵额，可能已遭篡改

所謂完整性是指信息的準確度配深。若無法證明其完整性，通常也就意味著無法判斷信息是否準確嫁盲。

• 接收到的內(nèi)容可能有誤
  由于 HTTP 協(xié)議無法證明通信的報文的完整性篓叶，因此，沒有任何辦法確認羞秤，發(fā)出的請求/響應和接收到的請求/響應是前后相同的缸托。

http_revise.png

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

http_revise1.png

• 如何防止篡改

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

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

  可惜的是，這些辦法也依然無法百分之百保證確認結(jié)果正確画侣。因為 PGP 和 MD5 本身被改寫的話冰悠，用戶是沒有辦法意識到的。

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

1.2 HTTP + 加密 + 認證 + 完整性保護 = HTTPS

1.2.1 HTTP 加上加密處理和認證及完整性保護后即是 HTTPS

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

另外，對于 HTTP 來說沙咏，服務器也好辨图，客戶端也好，都是沒有辦法確認通信方的肢藐。因為很有可能并不是和原來預想的通信方在實際通信故河。并且還需要考慮到接收到的報文在通信途中已經(jīng)遭到篡改這一可能性。

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

https.png

1.2.2 HTTPS 是身披 SSL 外殼的 HTTP

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

通常，HTTP 直接和 TCP 通信衷快。當使用 SSL 時晌砾，則演變成先和 SSL 通信，再由 SSL 和 TCP 通信了烦磁。簡言之养匈，所謂 HTTPS，其實就是身披 SSL 外殼的 HTTP都伪。

https1.png

在采用 SSL 后呕乎，HTTP 就擁有了 HTTPS 的加密、證書和完整性保護這些功能陨晶。

SSL 是獨立于 HTTP 的協(xié)議猬仁，所以不光是 HTTP 協(xié)議，其他運行在應用層的 SMTP 和 Telnet 等協(xié)議均可配合 SSL 協(xié)議使用先誉∈簦可以說 SSL 是當今世界上應用最為廣泛的網(wǎng)絡安全技術(shù)。

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

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

近代的加密方法中的加密算法是公開的诈闺，而密鑰確實保密的。通過這種方式得以保持加密方法的安全性铃芦。

加密和解密都會用到密鑰雅镊。沒有密鑰就無法對密碼解密襟雷，反過來說，任何人只要持有密鑰就能解密了仁烹。如果密鑰被攻擊者獲得耸弄，那加密也就失去了意義。

• 共享密鑰加密的困境
  加密和解密同用一個密鑰的方式叫做共享密鑰加密卓缰，也被稱為對稱密鑰加密计呈。

https2.png

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

https3.png

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

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

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

  使用公開密鑰加密方式，發(fā)送密文的一方使用對方的公開密鑰進行加密處理囱怕，對方收到被加密的信息后霍弹，再使用自己的私有密鑰進行解密。利用這種方式娃弓，不需要發(fā)送用來解密的私有密鑰典格，也不必擔心密鑰被攻擊者竊聽而盜走。

  另外台丛，要想根據(jù)密文和公開密鑰耍缴，恢復到信息原文是異常困難的，因為解密過程就是在對離散對數(shù)進行求值挽霉，這并非輕而易舉就能辦到防嗡。

https4.png

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

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

https5.png

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

在公開密鑰加密方式中也存在一些問題鲤拿，那就是無法證明公開密鑰本身就是貨真價實的公開密鑰。

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

數(shù)字證書認證機構(gòu)處于客戶端和服務器雙方都可信賴的第三方機構(gòu)的立場上宁否。數(shù)字證書認證機構(gòu)的流程是：首先窒升，服務器的運營人員向數(shù)字證書認證機構(gòu)提供公開密鑰的申請。數(shù)字證書認證機構(gòu)在判明提出申請者的身份之后慕匠，會對已申請的公開密鑰做數(shù)字簽名饱须，然后分配這個已簽名的公開密鑰，并將該公開密鑰放入公鑰證書后綁定在一起台谊。

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

接到證書的客戶端可使用數(shù)字證書認證機構(gòu)的公開密鑰酪呻，對那張證書上的數(shù)字簽名進行驗證饲趋，一旦驗證通過揽思，客戶端便可明確兩件事：一，認證服務器的公開密鑰的是真實有效的數(shù)字證書認證機構(gòu)浊猾。二贼邓，服務器的公開密鑰是值得信賴的阶冈。

https6.png

• 可證明組織真實性的 EV SSL 證書
  證書的一個作用是用來證明作為通信一方的服務器是否規(guī)范，另外一個作用是可確認對方服務器背后運營的企業(yè)是否真實存在塑径。擁有該特性的證書是 EV SSL 證書女坑。

  EV SSL 證書是基于國際標準的認證指導方針頒發(fā)的證書。其嚴格規(guī)定了對運營組織是否真實的確認方針晓勇，因此堂飞，通過認證的 Web 網(wǎng)站能夠獲得更高的認可度。

• 用以確認客戶端的客戶端證書

  HTTPS 中還可以使用客戶端證書绑咱。以客戶端證書進行客戶端認證绰筛，證明服務器正在通信的對方始終是預料之內(nèi)的客戶端，其作用跟服務器證書如出一轍描融。

• 認證機構(gòu)信譽第一
  SSL 機制中介入認證機構(gòu)之所以可行铝噩，是因為建立在其信用絕對可靠這一大前提下的。

• 由自認證機構(gòu)頒發(fā)的證書稱為自簽名證書
  如果使用 OpenSSL 這套開源程序窿克，每個人都可以構(gòu)建一套屬于自己的認證機構(gòu)骏庸，從而給自己頒發(fā)服務器證書毛甲。但該服務器證書在互聯(lián)網(wǎng)上不可作為證書使用，似乎沒什么幫助的具被。

  獨立機構(gòu)的認證機構(gòu)叫做自認證機構(gòu)玻募，由自認證機構(gòu)頒發(fā)的“無用”證書也被戲稱為自簽名證書。

1.2.5 HTTPS 的安全通信機制

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

https7.png

• 步驟1：客戶端通過發(fā)送 Client Hello 報文開始 SSL 通信。報文中包含客戶端支持的 SSL 的指定版本叮叹、加密組件（Cipher Suite）列表（所使用的加密算法及密鑰長度等）艾栋。
• 步驟2：服務器可進行 SSL 通信時，會以 Server Hello 報文作為應答蛉顽。和客戶端一樣蝗砾，在報文中包含 SSL 版本以及加密組件。服務器的加密組件內(nèi)容是從接收到的客戶端加密組件內(nèi)篩選出來的携冤。
• 步驟3：之后服務器發(fā)送 Certificate 報文悼粮。報文中包含公開密鑰證書。
• 步驟4：最后服務器發(fā)送 Server Hello Done 報文通知客戶端噪叙，最初階段的 SSL 握手協(xié)商部分結(jié)束矮锈。
• 步驟5：SSL 第一次握手結(jié)束之后霉翔，客戶端以 Client Key Exchange 報文作為回應睁蕾。報文中包含通信加密中使用的一種被稱為 Pre-master secret 的隨機密碼串。該報文已用步驟 3 中的公開密鑰進行加密债朵。
• 步驟6：接著客戶端繼續(xù)發(fā)送 Change Cipher Spec 報文子眶。該報文會提示服務器，在此報文之后的通信會采用 Pre-master secret密鑰加密序芦。
• 步驟7：客戶端發(fā)送 Finished 報文臭杰。該報文包含連接至今全部報文的整體校驗值。這次握手協(xié)商是否能夠成功谚中，要以服務器是否能夠正確解密該報文作為判定標準渴杆。
• 步驟8：服務器同樣發(fā)送 Change Cipher Spec 報文。
• 步驟9：服務器同樣發(fā)送 Finished 報文宪塔。
• 步驟10：服務器和客戶端的 Finished 報文交換完畢之后磁奖，SSL 連接就算建立完畢。當然某筐，通信會受到 SSL 的保護比搭。從此處開始進行應用層協(xié)議的通信，即發(fā)送 HTTP 請求南誊。
• 步驟11：應用協(xié)議通信身诺，即發(fā)送 HTTP 響應蜜托。
• 步驟12：最后由客戶端斷開連接。斷開連接時霉赡，發(fā)送 close_notify 報文橄务。

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

下面是對整個流程的圖解迫肖。圖中說明了從僅適用服務器端的公開密鑰證書（服務器證書）建立 HTTPS 通信的整個過程锅劝。

https8.png

• SSL 速度慢嗎
  HTTPS 也存在一些問題，那就是當使用 SSL 時蟆湖，它的處理速度會變慢故爵。

https9.png

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

和使用 HTTP 相比伦仍，網(wǎng)絡負載可能會變慢 2 到 100 倍结窘。除去和 TCP 連接、發(fā)送 HTTP 請求/響應外充蓝，還必須進行 SSL 通信隧枫，因此整體上處理通信量不可避免會增加。

另一點是 SSL 必須進行加密處理谓苟。在服務器和客戶端都需要進行加密和解密的運算處理官脓。因此從結(jié)果上講，比起 HTTP 會更多地消耗服務器和客戶端的硬件資源涝焙，導致負載增強卑笨。

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

為什么不一直使用 HTTPS
1. 因為與純文本通信相比艺普，加密通信會消耗更多的 CPU 及內(nèi)存資源。如果每次通信都加密，會消耗相當多的資源歧譬，平攤到一臺計算機上時岸浑，能夠處理的請求數(shù)量也必然減少。

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

2. 確認訪問用戶身份的認證

2.1 何為認證

計算機本身無法判斷坐在顯示器前的使用者的身份袁滥，為了確認是誰在訪問服務器盖桥，需要核對“登錄者本人才知道的信息”、“登錄者本人才會有的信息”题翻。核對的信息通常是指以下這些：

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

HTTP 使用的認證方式
HTTP/1.1 使用的認證方式如下所示：

• BASIC認證（基本認證）
• DIGEST認證（摘要認證）
• SSL 客戶端認證
• FormBase 認證（基于表單認證）

2.2 BASIC 認證

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

• BASIC 認證的認證步驟

basic.png

步驟1：當請求的資源需要 BASIC 認證時，服務器會隨狀態(tài)碼 401 Authorization Required炊豪，返回帶 WWW-Authenticate 首部字段的響應凌箕。該字段內(nèi)包含認證的方式（BASIC）及 Request-URI 安全域字符串（realm）。

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

步驟3：接收到包含首部字段 Authorization 請求的服務器，會對認證信息的正確性進行驗證把篓。如驗證通過纫溃，則返回一條包含 Request-URI 資源的響應。

BASIC 認證雖然采用 Base64 編碼方式韧掩，但這不是加密處理紊浩。不需要任何附加信息即可對其解密。換言之，由于明文解碼后就是用戶 ID 和密碼坊谁，在 HTTP 等非加密通信的線路上進行 BASIC 認證的過程中费彼，如果被人竊聽，被盜的可能性極高口芍。

另外箍铲，除此之外想再進行一次 BASIC 認證時，一般的瀏覽器卻無法實現(xiàn)認證注銷操作鬓椭，這也是問題之一颠猴。

BASIC 認證使用上不夠靈活，且達不到多數(shù) Web 網(wǎng)站期望的安全性等級小染，因此它并不常用翘瓮。

2.3 DIGEST 認證

為彌補 BASIC 認證存在的弱點，從 HTTP/1.1 起就有了 DIGEST 認證裤翩。DIGEST 認證同樣使用質(zhì)詢/響應的方式（challenge/response）春畔，但不會像 BASIC 認證那樣直接發(fā)送明文密碼。

所謂質(zhì)詢響應方式是指岛都，一開始一方會先發(fā)送認證要求給另一方律姨，接著使用從另一方那接收到的咨詢碼計算生成響應碼。最后將響應碼返回給對方進行認證的方式臼疫。

digest.png

因為發(fā)送給對方的只是響應摘要及由知訊碼產(chǎn)生的計算結(jié)果择份，所以比起 BASIC 認證，密碼泄露的可能性就降低了烫堤。

• DIGEST 認證的認證步驟

digest1.png

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

首部字段 WWW-Authenticate 內(nèi)必須包含 realm 和 nonce 這兩個字段的信息富蓄∈Ｔ铮客戶端就是依靠向服務器回送這兩個值進行認證的。

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

步驟2：接收到401 狀態(tài)碼的客戶端，返回的響應中包含 DIGEST 認證必須的首部字段 Authorization 信息口注。首部字段 Authorization 內(nèi)必須包含 username变擒、realm、nonce寝志、uri 和 response 的字段信息娇斑，其中策添，realm 和 nonce 就是之前從服務器接收到的響應中的字段。

步驟3：接收到包含首部字段 Authorization 請求的服務器毫缆，會確認認證信息的正確性舰攒。認證通過后則會返回包含 Request-URI 資源的響應。

并且這時會在首部字段 Authorization-Info 寫入一些認證成功的相關信息悔醋。

2.4 SSL 客戶端認證

SSL 客戶端認證是借由 HTTPS 的客戶端證書完成認證的方式摩窃。憑借客戶端證書認證，服務器可確認訪問是否來自登錄的客戶端芬骄。

2.4.1 SSL 客戶端認證的認證步驟

為達到 SSL 客戶端認證的目的猾愿，需要事先將客戶端證書分發(fā)給客戶端，且客戶端必須安裝此證書账阻。

步驟1：接收到需要認證資源的請求蒂秘，服務器會發(fā)送 Certificate Request 報文，要求客戶端提供客戶端證書淘太。

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

步驟3：服務器驗證客戶端證書驗證通過后方可領取證書內(nèi)客戶端的公開密鑰蒲牧，然后開始 HTTPS 加密通信撇贺。

2.4.2 SSL 客戶端認證采用雙因素認證

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

換言之尽超，第一個認證因素的 SSL 客戶端證書用來認證客戶端計算機，另一個認證因素的密碼則用來確定這是用戶本人的行為梧躺。

2.4.3 SSL 客戶端認證必要的費用

使用 SSL 客戶端認證需要用到客戶端證書似谁，而客戶端證書需要支付一定費用才能使用。

2.5 基于表單認證

基于表單的認證方法并不是在 HTTP 協(xié)議中定義的燥狰〖辏客戶端會向服務器上的 Web 應用程序發(fā)送登錄信息，按登錄信息的驗證結(jié)果認證龙致。

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

2.5.1 Session 管理及 Cookie 應用

基于表單認證的標準規(guī)范尚未有定論，一般會使用 Cookie 來管理 Session（會話）榛了。

基于表單認證本身是通過服務器端的 Web 應用在讶，將客戶端發(fā)送過來的用戶 ID 和密碼與之前登錄過的信息做匹配來進行認證的。

但鑒于 HTTP 是無狀態(tài)協(xié)議霜大，之前已認證成功的用戶狀態(tài)無法通過協(xié)議層面保存下來构哺。即，無法實現(xiàn)狀態(tài)管理战坤，因此即使該用戶下一次繼續(xù)訪問曙强，也無法區(qū)分他與其他的用戶。于是我們會使用 Cookie 來管理 Session途茫，以彌補 HTTP 協(xié)議中不存在的狀態(tài)管理功能碟嘴。

cookie_session.png

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

步驟2：服務器會發(fā)放用以識別用戶的 Session ID栅组。通過驗證從客戶端發(fā)送過來的登錄信息進行身份認證雀瓢，然后把用戶的認證狀態(tài)和 Session ID 綁定后記錄在服務器端。

向客戶端返回響應時玉掸，會在首部字段 Set-Cookie 內(nèi)寫入 Session ID致燥。另外，為減輕跨站腳本攻擊（XSS）造成的損失排截，建議事先在 Cookie 內(nèi)加上 httponly 屬性嫌蚤。

步驟3：客戶端接收到從服務器端發(fā)來的 Session ID 后，會將其作為 Cookie 保存在本地断傲。下次向服務器發(fā)送請求時脱吱，瀏覽器會自動發(fā)送 Cookie，所以 Session ID 也隨之發(fā)送到服務器认罩。服務器端可通過驗證接收到的 Session ID 識別用戶和其認證狀態(tài)箱蝠。

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

3.1 基于 HTTP 的協(xié)議

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

3.2 消除 HTTP 瓶頸的 SPDY

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

3.2.1 HTTP 的瓶頸

HTTP 存在以下缺點和不足：

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

http_weakness.png

1. Ajax 的解決辦法

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

而利用 Ajax 實時地從服務器獲取內(nèi)容菇存，有可能會導致大量請求產(chǎn)生。

http_ajax.png

2. Comet 的解決辦法
   一旦服務器有內(nèi)容更新了诚纸，Comet 不會讓請求等待撰筷，而是直接給客戶端返回響應。這是一種通過延時應答畦徘，模擬實現(xiàn)服務器向客戶端推送的功能毕籽。

內(nèi)容上雖然可以做到實時更新，但為了保留響應井辆，一次連接的持續(xù)時間也變長了关筒。期間，為了維持連接會消耗更多的資源杯缺。

http_comet.png

3.2.2 SPDY 的設計與功能

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

SPDY 以會話層的形式加入塘揣，控制對數(shù)據(jù)的流動包雀，但還是采用 HTTP 建立通信連接。因此亲铡，可照常使用 HTTP 的 GET 和 POST 等方法才写，Cookie 以及 HTTP 報文等。

spdy.png

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

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

3.2.3 SPDY 消除 Web 瓶頸了嗎

因為 SPDY 基本上只是將多個域名（IP 地址）的通信多路復用，所以當一個 Web 網(wǎng)站上使用多個域名下的資源雹姊，改善效果就會收到限制股缸。

3.3 使用瀏覽器進行全雙工通信的 WebSocket

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

3.3.1 WebSocket 的設計與功能

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

3.3.2 WebSocket 協(xié)議

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

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

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

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

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

1. 握手·請求
   為了實現(xiàn) WebSocket 通信突照，需要用到 HTTP 的 Upgrade 首部字段，告知服務器通信協(xié)議發(fā)送改變氧吐，已達到握手的目的讹蘑。

“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é)議標準在連接分開使用時座慰，定義那些連接的名稱陨舱。

2. 握手·響應
   對于之前的請求，返回狀態(tài)碼 101 Switching Protocols 的響應版仔。

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

Sec-WebSocket-Accept 的字段值是由握手請求中的 Sec-WebSocket-Accept 的字段值生成的游盲。

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

websocket.png

3.4 期盼已久的 HTTP/2.0

HTTP/2.0 在 2014 年 11 月實現(xiàn)標準化。

• HTTP/2.0 的特點
  HTTP/2.0 的目標是改善用戶在使用 Web 時的速斷體驗然想。

HTTP/2.0 圍繞著主要的 7 項技術(shù)進行討論莺奔。