讀《圖解HTTP》記錄
上一篇 讀書筆記_圖解HTTP(三) Web服務(wù)器以及http首部
HTTPS
在Http協(xié)議中有可能存在信息被竊聽或身份偽裝等安全問題。使用Https通信機(jī)制可以有效地防止這些問題簇秒。
1趁窃、Http的缺點
- 通信使用明文(不加密),內(nèi)容可能會被竊聽
- 不驗證通信方的身份凤巨，因此有可能遭遇偽裝
- 無法證明報文的完整性肿男，所以可能已遭篡改
這些問題在其他未加密的協(xié)議中也會存在。除此之外骂铁，Http本身還有很多缺點票从。而且漫雕，還有像某些特定的Web服務(wù)器和特定的Web瀏覽器在實際應(yīng)用中存在不足，另外峰鄙，Java和PHP等編程語言開發(fā)的Web應(yīng)用也可能存在安全漏洞浸间。
1、通信使用明文可能會被竊聽
由于Http本身不具備加密的功能吟榴，所以也無法做到對通信整體（使用Http協(xié)議通信的請求和響應(yīng)的內(nèi)容）進(jìn)行加密魁蒜。即，Http報文使用明文(未經(jīng)過加密的報文)方式發(fā)送吩翻。
- TCP/IP 可能會被竊聽的網(wǎng)絡(luò)
因為TCP/IP協(xié)議族的工作機(jī)制兜看，通信內(nèi)容在所有的通信線路上都有可能會遭到窺視∠料梗互聯(lián)網(wǎng)细移，是由能連通到全世界的網(wǎng)絡(luò)組成。無論在世界哪個角落的服務(wù)器在和客戶端通信時熊锭，在此通信線路上的某些網(wǎng)絡(luò)設(shè)備弧轧、光纖、計算機(jī)等都不可能是個人的私有物碗殷，所以不排除某個環(huán)節(jié)中會遭到惡意窺視行為劣针。
即使已經(jīng)經(jīng)過加密處理的通信，也會被窺視到通信內(nèi)容亿扁，這點和未加密的通信是相同的。只是經(jīng)過加密之后鸟廓，就有可能會讓人無法破解報文的含義从祝，但是加密后的報文本身還是會被看到襟己。
-
加密處理防止被竊聽
1、通信的加密
Http協(xié)議中沒有加密機(jī)制牍陌，但可以通過和SSL(Secure Socket Layer,安全套接層)或TLS(Transport Layer Security,安全層傳輸協(xié)議)的組合使用擎浴，加密Http的通信內(nèi)容。
使用SSL建立安全通信線路之后毒涧，就可以在這條線路上進(jìn)行Http通信了贮预。與SSL組合使用Http被稱為HTTPS(HTTP Secure,超文本傳輸安全協(xié)議)或HTTP over SSL。
通信的加密
2契讲、內(nèi)容的加密
內(nèi)容的加密是將參與通信的內(nèi)容本身加密仿吞。由于HTTP協(xié)議中沒有加密機(jī)制，那么就對HTTP協(xié)議傳輸?shù)膬?nèi)容本身加密捡偏。即把HTTP報文里所包含的內(nèi)容進(jìn)行加密處理唤冈。在這種情況下，需要客戶端對HTTP報文進(jìn)行加密處理后再發(fā)送請求银伟。但是這種方式不同于SSL或TLS將整個通信線路加密處理你虹，所以內(nèi)容仍然可能被篡改。
2彤避、不驗證通信方身份就可能遭遇偽裝
HTTP協(xié)議中的請求和響應(yīng)不會對通信方進(jìn)行確認(rèn)傅物。也就是說存在“服務(wù)器是否就是發(fā)送請求中URI真正指定的主機(jī)，返回的響應(yīng)是否真的返回到實際提出問題的客戶端”等類似的問題琉预《危客戶端不能確認(rèn)請求的服務(wù)器是不是真的目標(biāo)服務(wù)器；服務(wù)器收到的請求是不是真的目標(biāo)范圍內(nèi)的客戶端模孩。
- 任何人都能發(fā)起請求
在HTTP協(xié)議通信時尖阔，由于不存在確認(rèn)通信方的處理步驟，任何人都可以發(fā)起請求榨咐。另外介却，服務(wù)器只要接收到請求，不管對方是誰否會返回一個響應(yīng)块茁。所以會存在各種隱患齿坷。
1、不能確定請求的是不是目標(biāo)服務(wù)器（無法確認(rèn)請求發(fā)送至目標(biāo)的Web服務(wù)器是否是按真實意圖返回響應(yīng)的那臺服務(wù)器数焊。有可能是已偽裝的Web服務(wù)器）永淌。
2、不知道發(fā)起請求的是不是目標(biāo)客戶端（無法確定響應(yīng)返回到的客戶端是否是按真是意圖街道的那個客戶端佩耳∷熘可能是已偽裝的客戶端）。
3干厚、無法確認(rèn)正在通信的對方是否具備訪問權(quán)限李滴。（某些數(shù)據(jù)只想給特殊的用戶）
4螃宙、即使是無意義的請求也會照單全收。無法阻止海量請求下的DOS攻擊(Denial of Service,拒絕服務(wù)攻擊)所坯。
- 查明對手的證書
Http協(xié)議無法確認(rèn)通信方谆扎，但如果使用SSL則可以。SSL不僅提供加密處理芹助，而且還使用了一種被稱為證書的手段堂湖，可用于確認(rèn)方。
證書由值得信任的第三方機(jī)構(gòu)頒發(fā)状土，用以證明服務(wù)器和客戶端是實際存在的无蜂。在技術(shù)角度來說，偽造證書非常困難声诸。所以只要能確認(rèn)通信方(服務(wù)器或客戶端)持有證書酱讶，即可判斷通信方的真實意圖。
通過使用證書彼乌，以證明通信方是意料中的服務(wù)器泻肯。這對使用者個人來說，減少了個人信息泄漏的危險性慰照。
客戶端持有證書即可完成個人身份的確認(rèn)灶挟，也可用于對Web網(wǎng)站的認(rèn)證環(huán)節(jié)。
3毒租、無法證明報文完整性稚铣，可能已遭篡改
所謂完整性是指信息的準(zhǔn)確度。若無法證明完整性墅垮，通常也就意味著無法判斷信息是否準(zhǔn)確惕医。
- 接收到的內(nèi)容可能有誤
由于HTTP協(xié)議無法證明通信的報文的完整性，因此算色，在請求或響應(yīng)送出之后直到對方接收到之前的這斷時間內(nèi)抬伺，即使請求或響應(yīng)的內(nèi)容遭到篡改，也沒辦法知道灾梦。
換句話說峡钓，沒有人格辦法確認(rèn)，發(fā)出的請求/響應(yīng)和接收到的請求/響應(yīng)是相同的若河。內(nèi)容在傳輸途中可能已經(jīng)被篡改為其他內(nèi)容能岩。
像在請求或響應(yīng)的傳輸中，早攻擊者攔截并篡改內(nèi)容的攻擊被稱為中間人攻擊(Man-in-the-Middle attack,MITM)萧福。
- 防止篡改
雖然有使用Http協(xié)議確定報文完整性的方法拉鹃，但事實上并不便捷、可靠。其中常用的是MD5和SHA-1等離散列值校驗的方法膏燕，以及用來確認(rèn)文件的數(shù)字簽名方法炭庙。
提供文件下載服務(wù)的Web網(wǎng)站也會提供相應(yīng)的以PGP(Pretty Good Privacy，完美隱私)創(chuàng)建的數(shù)字簽名及MD5算法生成的散列值煌寇。PGP是用來證明創(chuàng)建文件的數(shù)字簽名，MD5是由單向函數(shù)生成的散列值逾雄。不論使用哪種方法阀溶，都需要操縱客戶端的用戶本人親自檢查驗證下載的文件是否就是原來服務(wù)器上的文件。瀏覽器無法自動幫用戶檢查鸦泳。
可是银锻，用這些方法也依然無法百分百保證確認(rèn)結(jié)果正確。因為PGP和MD5本山被改寫的話做鹰，用戶就沒辦法意識到了击纬。
為了有效防止這些弊端，有必要使用HTTPS钾麸。SSL提供認(rèn)證和加密處理及摘要功能更振。僅靠HTTP確保完整性是非常困難的，因此通過和其他協(xié)議組合使用來實現(xiàn)這個目標(biāo)饭尝。
2肯腕、HTTP+加密+認(rèn)證+完整性保護(hù)=HTTPS
為了解決上述問題，需要在HTTP上加入加密處理和認(rèn)證等機(jī)制钥平。我們吧添加了加密以及認(rèn)證機(jī)制的HTTP稱為HTTPS(HTTP Secure)实撒。
2.1、HTTPS是身披SSL外殼的HTTP
HTTPS并非是應(yīng)用層的一種新協(xié)議涉瘾。只是HTTP通信接口部分用SSL和TLS協(xié)議代替而已知态。
通常，HTTP直接和TCP通信立叛。當(dāng)使用SSL時负敏，則演變成先和SSL通信，再由SSL和TCP通信囚巴。
在采用SSL后原在，HTTP就擁有了HTTPS的加密、證書和完整性保護(hù)這些功能彤叉。SSL是獨立于HTTP的協(xié)議庶柿，所以不光是HTTP協(xié)議，其他運行在應(yīng)用層的SMTP和Telnet等協(xié)議均可配合SSL協(xié)議使用秽浇「÷可以說SSL是當(dāng)今世界上應(yīng)用最為廣泛的網(wǎng)絡(luò)安全技術(shù)。
2.2、互換密鑰的公開密鑰加密技術(shù)
SSL采用一種叫做公開密鑰加密的加密技術(shù)审残。近代的而機(jī)密方法中加密算法是公開的梭域，而密鑰是保密的。通過這種方式得以保持加密方法的安全性搅轿。
加密和解密都會用到密鑰病涨。沒有密鑰就無法對密碼解密。就是說璧坟，任何人只要持有密鑰就能解密既穆。如果攻擊者獲得了密鑰，那加密就沒有意義了雀鹃。
2.2.1 共享密鑰加密的困境
加密和解密使用同一個密鑰的方式稱為共享密鑰加密(Common key cryto system)幻工，也被稱為對稱密鑰加密。
以共享密鑰方式加密時必須將密鑰也發(fā)給對方黎茎。但是在互聯(lián)網(wǎng)上轉(zhuǎn)發(fā)密鑰囊颅，如果通信被監(jiān)聽密鑰就可能會落入攻擊者的手中，同時就失去了加密的意義傅瞻。另外還得設(shè)法安全的保管接收到的密鑰踢代。
2.2.2 使用兩把密鑰的公開密鑰加密
公開密鑰加密方式很好的解決了共享密鑰加密的困難。
公開密鑰加密使用一對非對稱的密鑰俭正。一把叫做私有密鑰(private key) 另一把叫做公開密鑰(public key)奸鬓。私有密鑰不能讓其他任何人知道，公開密鑰可以隨意發(fā)布掸读，任何人都可以獲得串远。
使用公開密鑰加密方式，發(fā)送秘聞的一方使用對方的公開密鑰加密儿惫，對方收到加密信息后澡罚，再使用自己的私有密鑰解密。這樣就不需要發(fā)送用來解密的私有密鑰肾请，也不必?fù)?dān)心密鑰被攻擊者監(jiān)聽而盜走留搔。
另外，要想根據(jù)密文和公開密鑰恢復(fù)到信息原文異常困難铛铁。就目前技術(shù)來看是不太現(xiàn)實的隔显。
2.2.3 HTTPS采用混合加密機(jī)制
HTTPS采用共享加密和公開密鑰加密兩者并用的混合加密機(jī)制。若密鑰能實現(xiàn)安全交換饵逐，那么就有可能會考慮僅使用公開密鑰加密來通信括眠。但是公開密鑰加密比共享密鑰加密處理速度要慢。
所以應(yīng)該充分利用兩者自己的優(yōu)勢倍权，將多種加密方法組合起來用于通信掷豺。在交換密鑰環(huán)節(jié)使用公開密鑰加密方式，之后的建立通信交換報文階段使用共享密鑰加密方式。
2.3当船、證明公開密鑰正確性的證書
公開密鑰加密方式還是存在一些問題的题画。那就是無法證明公開密鑰本身就是貨真價實的公開密鑰。比如德频，正準(zhǔn)備和某臺服務(wù)器建立公開密鑰加密方式下的通信時苍息，如何證明收到的公開密鑰就是原本預(yù)想的那臺服務(wù)器發(fā)行的公開密鑰∫贾茫或許在公開密鑰傳輸中档叔，真正的公開密鑰已經(jīng)被攻擊者替換掉了。
為了解決上述問題蒸绩，可以使用由數(shù)字證書認(rèn)證機(jī)構(gòu)和相關(guān)機(jī)關(guān)辦法的公開密鑰證書。
數(shù)字證書認(rèn)證機(jī)構(gòu)處于客戶端與服務(wù)器雙方都可醒來的第三方機(jī)構(gòu)的立場上铃肯。其業(yè)務(wù)流程如下患亿。
- 首先，服務(wù)器的運營人員向數(shù)字證書認(rèn)證機(jī)構(gòu)提出公開密鑰的申請押逼；
- 數(shù)字證書認(rèn)證機(jī)構(gòu)在判斷提出申請的身份之后步藕，會對已申請的公開密鑰做數(shù)字簽名；
- 然后分配這個已經(jīng)簽名的公開密鑰挑格，并將該公開密鑰放入公鑰證書后綁定在一起咙冗。
這時，服務(wù)器會將這份由數(shù)字證書認(rèn)證機(jī)構(gòu)辦法的公鑰證書發(fā)送給客戶端漂彤，以進(jìn)行公開密鑰加密方式通信雾消。公鑰證書也可以叫做數(shù)字證書或者直接稱為證書。
接到證書的客戶端可使用數(shù)字證書認(rèn)證機(jī)構(gòu)的公開密鑰挫望，對那張證書上的數(shù)字簽名驗證立润，一旦驗證通過了，客戶端就可以明確兩件事媳板；
- 認(rèn)證服務(wù)器的公開密鑰的是真實有效的數(shù)字證書認(rèn)證機(jī)構(gòu)桑腮；
- 服務(wù)器的公開密鑰是值得信賴的
此處認(rèn)真機(jī)關(guān)的公開密鑰必須安全的轉(zhuǎn)交給客戶端。使用通信方式時蛉幸，如何安全轉(zhuǎn)交是一件很困難的事破讨，因此，多數(shù)瀏覽器開發(fā)商發(fā)布版本時奕纫，會事先在內(nèi)部植入常用認(rèn)真機(jī)關(guān)的公開密鑰提陶。
2.3.1可證明組織真實性的EV SSL證書
證書的作用是用來證明作為通信以放的服務(wù)器是否規(guī)范，另一個作用是可確認(rèn)對方服務(wù)器背后運營的企業(yè)是否真是存在若锁。擁有該特性的證書就是EV SSL證書(Extended Validation SSL Certificate).
EV SSL證書是基于國際標(biāo)準(zhǔn)的認(rèn)證指導(dǎo)方針辦法的證書搁骑。其嚴(yán)格規(guī)定了對運營組織是否真是的確認(rèn)方針，因此，通過認(rèn)證的Web網(wǎng)站能夠獲得更高的認(rèn)可度仲器。
擁有EV SSL證書的Web網(wǎng)站的瀏覽器地址欄的背景色是綠色的煤率，一眼就能看出來。而且在地址欄的左側(cè)顯示了SSL證書中記錄的組織名稱以及頒發(fā)證書的認(rèn)證機(jī)構(gòu)的名稱乏冀。
上述機(jī)制的原意圖是為了防止用戶被釣魚攻擊蝶糯，但是就效果上來講，還得打一個問號辆沦。
2.3.2 用以確認(rèn)客戶端的客戶端證書
Https中還可以使用客戶端證書昼捍。一客戶端證書進(jìn)行客戶端認(rèn)證，證明服務(wù)器正在通信的對方始終是預(yù)料之內(nèi)的客戶端肢扯，其作用更服務(wù)器證書一樣妒茬。
但客戶端證書仍存在幾處問題。其中一個就是證書的獲取及發(fā)布蔚晨。
想獲取證書時乍钻，用戶得自行安裝客戶端證書。但由于客戶端證書要付費铭腕，且每張證書對應(yīng)到每位用戶也就意味著需支付和用戶數(shù)對等的費用银择。另外，要讓知識層次不同的用戶自行安裝證書累舷，這件事也不太現(xiàn)實浩考。
現(xiàn)狀是，安全性極高的認(rèn)證機(jī)構(gòu)可辦法客戶端證書但僅用于特殊用途的業(yè)務(wù)被盈。比如那些可支撐客戶端證書支出費用的業(yè)務(wù)析孽。例如，銀行的晚上銀行就采用了客戶端證書只怎。在登錄網(wǎng)銀時绿淋，不僅要求用戶確認(rèn)ID和密碼，還會要求用戶的客戶端證書尝盼，以確認(rèn)用戶是否從特定的終端訪問網(wǎng)銀吞滞。
客戶端證書存在的另一個問題是，客戶端證書畢竟只是用來證明客戶端實際存在盾沫，而不能用來證明用戶本人的真實有效性裁赠。也就是說，只要獲得了安裝客戶端證書的計算機(jī)的使用權(quán)限赴精，也就意味著同時擁有了客戶端證書的使用權(quán)限佩捞。
2.3.3 認(rèn)證機(jī)構(gòu)信譽第一
SSL機(jī)制中介入認(rèn)證機(jī)構(gòu)之所以可行，是因為建立在其信用絕對可靠這一大前提下蕾哟。然而一忱，2011年7月莲蜘，荷蘭一家認(rèn)證機(jī)構(gòu)曾遭黑客不法入侵，頒布了google.com和teitter.com等網(wǎng)站的偽造證書事件帘营。這一事件從根本上撼動了SSL的可信度票渠。
因為偽造證書上有正規(guī)認(rèn)證機(jī)構(gòu)的數(shù)字簽名，所以瀏覽器會判斷該證書是正當(dāng)?shù)姆移５珎卧斓淖C書被用作服務(wù)器偽裝時问顷，用戶根本無法察覺到。
雖然存在可將證書無效化的證書吊銷列表機(jī)制禀梳，以及從客戶端刪除根證書頒發(fā)機(jī)構(gòu)的對策杜窄，但距離生效還需要一段時間，而這段時間內(nèi)算途，到底有多少用戶的利益蒙受損失就不知道了塞耕。
2.3.4由自認(rèn)證機(jī)構(gòu)辦法的證書稱為自簽名證書
如果使用OpenSSL這套開源程序，每個人都可以建立一套屬于自己的認(rèn)證機(jī)構(gòu)嘴瓤，從而自己給自己辦法服務(wù)器證書荷科。但該服務(wù)器證書在互聯(lián)網(wǎng)上不可做為證書使用，似乎沒什么幫助纱注。
獨立構(gòu)建的認(rèn)證機(jī)構(gòu)叫做自認(rèn)證機(jī)構(gòu)，由自認(rèn)證機(jī)構(gòu)辦法的“無用”證書也被稱為自簽名證書胆胰。
瀏覽器訪問該服務(wù)器時狞贱，會顯示“無法確認(rèn)鏈接安全性”或“該網(wǎng)站的安全證書存在問題”等警告消息。
由自認(rèn)證機(jī)構(gòu)辦法的服務(wù)器證書之所以不起作用蜀涨，是因為它無法消除偽裝的可能性瞎嬉。自認(rèn)證機(jī)構(gòu)能產(chǎn)生的作用頂多就是自己對外宣稱“我是xx”的這種態(tài)度。即使采用自簽名證書厚柳，通過SSL加密之后氧枣，可能偶爾還會看到通信處在安全狀態(tài)的提示，可那也是有問題的别垮。因為就算加密通信，也不能排除正在和已經(jīng)偽裝過的假服務(wù)器保持通信。
值得信賴的第三方機(jī)構(gòu)介入認(rèn)證抢埋，才能讓已植入在瀏覽器內(nèi)的認(rèn)證機(jī)構(gòu)頒布的公開密鑰發(fā)揮作用川陆，并借此證明服務(wù)器的真實性。
中級認(rèn)證機(jī)構(gòu)的證書可能會變成自認(rèn)證證書
多數(shù)瀏覽器內(nèi)預(yù)先已植入備受新浪的認(rèn)證機(jī)構(gòu)的證書胧奔，但也有一小部分瀏覽器會植入中級認(rèn)證機(jī)構(gòu)的證書逊移。
對于中級認(rèn)證機(jī)構(gòu)辦法的服務(wù)器證書，某些瀏覽器會議正規(guī)的證書來對待龙填，有可能的瀏覽器會當(dāng)作自簽名證書胳泉。
2.3拐叉、HTTPS的安全通信機(jī)制
先來觀察一下https的通信步驟
- 1、客戶端通過發(fā)送Client Hello報文開始SSL通信扇商。報文中包含客戶端支持的SSL的指定版本凤瘦、加密組件(Cipher Suite) 列表(所使用的加密算法以及密鑰長度等)。
- 2钳吟、服務(wù)器可進(jìn)行SSL通信時廷粒，會以Server Hello報文作為應(yīng)答。和客戶端一樣红且，在報文中包含了SSL版本以及加密組件坝茎。服務(wù)器的加密組件內(nèi)容是從接收到的客戶端加密組件內(nèi)篩選出來的。
- 3暇番、之后服務(wù)器發(fā)送Certificate報文嗤放。報文中包含公開密鑰證書。
- 4壁酬、最后服務(wù)器發(fā)送Server Hello Done 報文通知客戶端次酌，最初階段的SSL握手協(xié)商部分結(jié)束。
- 5舆乔、SSL第一次握手結(jié)束之后岳服，客戶端以Client Key Exchange 報文作為回應(yīng)。報文中包含通信加密中使用的一種被稱為Pre-master secret的隨機(jī)密碼串希俩。該報文已用步驟3里邊公開密鑰進(jìn)行加密吊宋。
- 6、接著客戶端繼續(xù)發(fā)送 Change Cipher Spec 報文颜武。該報文會提示服務(wù)器璃搜，在此報文之后的通信會采用Pre-master secret密鑰加密。
- 7鳞上、客戶端發(fā)送Finished報文这吻。該報文包含連接至今全部保溫的整體校驗值。這次握手協(xié)商能否成功篙议，要以服務(wù)器是否能夠正確解密該報文作為判定標(biāo)準(zhǔn)唾糯。
- 8、服務(wù)器同樣發(fā)送 Change Cipher Spec 報文鬼贱。
- 9趾断、服務(wù)器同樣發(fā)送Finished報文。
- 10吩愧、服務(wù)器和客戶端的Finished報文芋酌。
- 11、應(yīng)用層協(xié)議通信雁佳，即發(fā)送HTTP響應(yīng)脐帝。
- 12同云、最后由客戶端斷開連接。斷開連接時堵腹，發(fā)送close_notify 報文炸站。上圖做了一些省略，這步之后再發(fā)送TCP FIN報文來關(guān)閉TCP的通信疚顷。
在以上流程中旱易，引用陳發(fā)送數(shù)據(jù)時會附帶一種叫做MAC(Message Authentication Code)的報文摘要。MAC能夠查知報文是否遭遇篡改腿堤，從而保護(hù)報文的完整性阀坏。
下面是對整個流程的圖解。圖中說明了從僅使用服務(wù)器端的公開密鑰證書(服務(wù)器證書)建立HTTPS通信的整個過程笆檀。
CAC模式(Cipher Block Chaining)又名密碼分組鏈接模式忌堂。再次模式下，將前一個明文塊加密處理后和下一個明文塊做XOR算法酗洒，使之重疊士修，然后在對運算結(jié)果做加密處理。對第一個明文塊加密時樱衷，要么使用前一段秘聞的最后一塊棋嘲，要么利用外部生成的初始向量。
2.3.1矩桂、SSL和TLS
HTTP使用SSL(Secure Socket Layer) 和TLS(Transport Layer Security) 這兩個協(xié)議沸移。
SSL技術(shù)最初是有瀏覽器開發(fā)商網(wǎng)景通信公司率先倡導(dǎo)的，開發(fā)鍋SSL3.0之前的版本耍鬓。目前主導(dǎo)權(quán)已經(jīng)轉(zhuǎn)移到了IETF(Internet Engineering Task Force,Internet 工程任務(wù)組)的手中。
IETF 以SSL3.0為基準(zhǔn)流妻，后又制定了TLS1.0牲蜀、TLS1.1和TLS1.2。TLS是以SSL為原型開發(fā)的協(xié)議绅这，有時會統(tǒng)一成該協(xié)議為SSL涣达。當(dāng)前主流的版本是SSL3.0和TLS1.0。
由于SSL1.0協(xié)議在設(shè)計之初被發(fā)現(xiàn)出了問題证薇，就沒有實際投入使用度苔。SSL2.0也被發(fā)現(xiàn)存在問題，所以很多瀏覽器直接廢除了該版本協(xié)議浑度。
2.3.2寇窑、SSL速度慢嗎？
HTTPS也存在一些問題箩张，那就是當(dāng)使用SSL時甩骏，它的處理速度會變慢窗市。
SSL的慢分兩種。一種是指通信慢饮笛。另一種是指由于更大消耗CPU以及內(nèi)存等資源咨察，導(dǎo)致處理速度變慢。
和HTTP相比福青，網(wǎng)絡(luò)負(fù)載可能會變慢2~100倍摄狱。除去和TCP鏈接、發(fā)送HTTP請求和響應(yīng)以外无午，還必須進(jìn)行SSL通信媒役，因此基本上處理通信量不可避免會增加。
另一點是SSL必須進(jìn)行加密處理指厌。在服務(wù)器和客戶端都需要進(jìn)行加密和解密運算刊愚。因此從結(jié)果上來講，比起HTTP會更多的消耗服務(wù)器和客戶端的硬件資源踩验，導(dǎo)致負(fù)載增強鸥诽。
針對速度變慢這一問題，并沒有根本性的解決方案箕憾，我們會使用SSL加速器這種硬件來改善問題牡借。該應(yīng)該為SSL通信專用硬件，相對軟件來講袭异，能夠提高數(shù)倍SSL的計算速度钠龙。僅在SSL處理時發(fā)匯SSL處理器的功效，以分擔(dān)負(fù)載御铃。
2.3.3碴里、為什么不一直使用HTTPS
既然HTTPS那么安全可靠，為啥不是所有的Web網(wǎng)站都一直使用HTTPS上真？
一個原因是咬腋，與純文本通信相比，加密通信會消耗更多的CPU以及內(nèi)存資源睡互。如果每次通信都加密根竿，會消耗相當(dāng)多的資源，平攤到一臺計算機(jī)上時就珠，能夠處理的請求數(shù)量必定也會隨之減少寇壳。
因此，如果是非敏感信息則使用http通信妻怎，只有在包含個人信息等敏感數(shù)據(jù)時壳炎，才利用HTTPS加密通信。
特別是每當(dāng)那些訪問量較多的Web網(wǎng)站在進(jìn)行加密處理時逼侦，他們所能承擔(dān)著的負(fù)載不容小覷冕广。在進(jìn)行加密處理時疏日，并非對所有內(nèi)容都進(jìn)行加密處理，而是僅在那些需要信息隱藏時才會加密撒汉，以節(jié)約資源沟优。
另一個原因就是想要節(jié)約購買證書的開銷。
要進(jìn)行HTTPS通信睬辐，證書是必不可少的挠阁。而使用的證書必須向認(rèn)證機(jī)構(gòu)買。證書的價格不便宜溯饵。那些購買證書并不合算的服務(wù)以及一些個人網(wǎng)站侵俗，可能只會采用HTTP的通信方式。
下一篇 讀書筆記_圖解HTTP(五) 確認(rèn)訪問用戶身份的認(rèn)證以及基于HTTP的功能追加協(xié)議
