HTTP、SSL/TLS和HTTPS協議的區別與聯繫（轉載）

今天在請求數據的時候，服務器使用的是https請求，相對安全些，可是結果讓我請求圖片和資源的時候也使用https請求，我以前寫的http請求根本用不了！我就感到很是的不爽！最後聽公司的人說了下，最後他們決定重要信息使用https訪問，可是對於資源什麼的就使用http吧！

開始沒什麼認識，只感受到使用https請求數據的時候，要通過安全驗證，安全性很高！仔細查了一些資料，原來使用https是要分場合的，不是何時均可以用的，對此，咱們不妨先來看一下HTTP、SSL/TLS和HTTPS協議之間的區別與聯繫。

一、「HTTP」是什麼？

超文本傳輸協議（HTTP，HyperText Transfer Protocol)是互聯網上應用最爲普遍的一種網絡協議，全部的WWW文件都必須遵照這個標準，設計HTTP最初的目的是爲了提供一種發佈和接收HTML頁面的方法（具體可查看馬海祥博客《深刻解析互聯網協議的原理》的相關介紹）。

1960年美國人Ted Nelson構思了一種經過計算機處理文本信息的方法，並稱之爲超文本（hypertext），這成爲了HTTP超文本傳輸協議標準架構的發展根基。

簡單來講，HTTP就是一個網絡協議，是專門用來幫你傳輸Web內容的，關於這個協議，就算你不瞭解，至少也據說過吧？好比你訪問個人博客的主頁，瀏覽器地址欄會出現的網址：http://www.mahaixiang.cn，大部分網站都是經過HTTP協議來傳輸Web頁面、以及Web頁面上包含的各類東東（圖片、CSS 樣式、JS 腳本）。

二、「SSL/TLS」是什麼？

SSL是「Secure Sockets Layer」的縮寫，中文叫作「安全套接層」，它是在上世紀90年代中期，由網景公司設計的（順便插一句，網景公司不光發明了 SSL，還發明瞭不少 Web 的基礎設施——好比「CSS 樣式表」和「JS 腳本」）。

爲啥要發明SSL這個協議捏？由於原先互聯網上使用的HTTP協議是明文的，存在不少缺點——好比傳輸內容會被偷窺（嗅探）和篡改，發明SSL協議，就是爲了解決這些問題。

到了1999年，SSL由於應用普遍，已經成爲互聯網上的事實標準，IETF就在那年把SSL標準化，標準化以後的名稱改成TLS（是「Transport Layer Security」的縮寫），中文叫作「傳輸層安全協議」。

不少相關的文章都把這二者並列稱呼（SSL/TLS），由於這二者能夠視做同一個東西的不一樣階段。

三、「HTTPS」是什麼意思？

解釋完 HTTP 和 SSL/TLS，如今就能夠來解釋 HTTPS 啦，我們一般所說的 HTTPS 協議，說白了就是「HTTP 協議」和「SSL/TLS 協議」的組合，你能夠把 HTTPS 大體理解爲——「HTTP over SSL」或「HTTP over TLS」（反正 SSL 和 TLS 差很少）。

HTTPS（全稱：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全爲目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，所以加密的詳細內容就須要SSL。

它是一個URI scheme（抽象標識符體系），句法類同http:體系，用於安全的HTTP數據傳輸。

https:URL代表它使用了HTTP，但HTTPS存在不一樣於HTTP的默認端口及一個加密/身份驗證層（在HTTP與TCP之間），這個系統的最初研發由網景公司(Netscape)進行，並內置於其瀏覽器Netscape Navigator中，提供了身份驗證與加密通信方法，如今它被普遍用於萬維網上安全敏感的通信，例如交易支付方面。

四、談談「對稱加密」和「非對稱加密」的概念

若是咱們想搞明白「對稱加密」和「非對稱加密」的概念，首先，咱們就要先知道什麼是「加密」和「解密」？

（1）、什麼是「加密」和「解密」？

通俗而言，你能夠把「加密」和「解密」理解爲某種互逆的數學運算，就比如「加法和減法」互爲逆運算、「乘法和除法」互爲逆運算。

「加密」的過程，就是把「明文」變成「密文」的過程；反之，「解密」的過程，就是把「密文」變爲「明文」，在這兩個過程當中，都須要一個關鍵的東東——叫作「密鑰」——來參與數學運算。

（2）、什麼是「對稱加密」？

所謂的「對稱加密技術」，意思就是說：「加密」和「解密」使用相同的密鑰。這個比較好理解，就比如你用 7zip 或 WinRAR 建立一個帶密碼（口令）的加密壓縮包，當你下次要把這個壓縮文件解開的時候，你須要輸入一樣的密碼，在這個例子中，密碼/口令就如同剛纔說的「密鑰」。

對稱加密是最快速、最簡單的一種加密方式，加密（encryption）與解密（decryption）用的是一樣的密鑰（secret key），這種方法在密碼學中叫作對稱加密算法，對稱加密有不少種算法，因爲它效率很高，因此被普遍使用在不少加密協議的核心當中。

（3）、什麼是「非對稱加密」？

所謂的「非對稱加密技術」，意思就是說：「加密」和「解密」使用不一樣的密鑰，這玩意兒比較難理解，也比較難想到，當年「非對稱加密」的發明，還被譽爲「密碼學」歷史上的一次革命。

非對稱加密爲數據的加密與解密提供了一個很是安全的方法，它使用了一對密鑰，公鑰（public key）和私鑰（private key），私鑰只能由一方安全保管，不能外泄，而公鑰則能夠發給任何請求它的人，非對稱加密使用這對密鑰中的一個進行加密，而解密則須要另外一個密鑰。

因爲篇幅有限，對「非對稱加密」這個話題，我就不展開了，有空的話，我會再單獨寫一篇文章在馬海祥博客上發佈。

（4）、各自有啥優缺點？

看完剛纔的定義，很顯然：（從功能角度而言）「非對稱加密」能幹的事情比「對稱加密」要多，這是「非對稱加密」的優勢，可是「非對稱加密」的實現，一般須要涉及到「複雜數學問題」，因此，「非對稱加密」的性能一般要差不少（相對於「對稱加密」而言）。

這二者的優缺點，也影響到了 SSL 協議的設計。

五、HTTP協議的特色

做爲背景知識介紹，還須要再稍微談一下 HTTP 協議自己的特色，HTTP自己有不少特色，考慮到篇幅有限，馬海祥只談那些和HTTPS相關的特色，想要了解更深刻的HTTP知識，可查看馬海祥博客《HTTP服務的七層架構技術解析及運用》的相關介紹。

（1）、HTTP的版本和歷史

現在我們用的 HTTP 協議，版本號是 1.1（也就是 HTTP 1.1），這個 1.1 版本是1995年末開始起草的（技術文檔是RFC2068），並在1999年正式發佈（技術文檔是RFC2616）。

在 1.1 以前，還有曾經出現過兩個版本「0.9 和 1.0」，其中的 HTTP 0.9 沒有被普遍使用，而 HTTP 1.0 被普遍使用過。

（2）、HTTP 和 TCP 之間的關係

簡單地說，TCP 協議是 HTTP 協議的基石——HTTP 協議須要依靠 TCP 協議來傳輸數據。

在網絡分層模型中，TCP 被稱爲「傳輸層協議」，而 HTTP 被稱爲「應用層協議」。

有不少常見的應用層協議是以 TCP 爲基礎的，好比「FTP、SMTP、POP、IMAP」等。

TCP被稱爲「面向鏈接」的傳輸層協議，關於它的具體細節，俺就不展開了（不然篇幅又失控了），你只需知道：傳輸層主要有兩個協議，分別是TCP和UDP，TCP比UDP更可靠，你能夠把 TCP 協議想象成某個水管，發送端這頭進水，接收端那頭就出水，而且 TCP 協議可以確保，先發送的數據先到達（與之相反，UDP不保證這點）。

（3）、HTTP協議如何使用 TCP 鏈接？

HTTP對 TCP 鏈接的使用，分爲兩種方式：俗稱「短鏈接」和「長鏈接」（「長鏈接」又稱「持久鏈接」，叫作「Keep-Alive」或「Persistent Connection」）

假設有一個網頁，裏面包含好多圖片，還包含好多外部的CSS文件和JS文件，在「短鏈接」的模式下，瀏覽器會先發起一個 TCP 鏈接，拿到該網頁的 HTML 源代碼（拿到 HTML 以後，這個 TCP 鏈接就關閉了）。而後，瀏覽器開始分析這個網頁的源碼，知道這個頁面包含不少外部資源（圖片、CSS、JS）。而後針對每個外部資源，再分別發起一個個 TCP 鏈接，把這些文件獲取到本地（一樣的，每抓取一個外部資源後，相應的 TCP 就斷開）。

相反，若是是「長鏈接」的方式，瀏覽器也會先發起一個 TCP 鏈接去抓取頁面，可是抓取頁面以後，該 TCP 鏈接並不會當即關閉，而是暫時先保持着（所謂的「Keep-Alive」），而後瀏覽器分析 HTML 源碼以後，發現有不少外部資源，就用剛纔那個 TCP 鏈接去抓取此頁面的外部資源。

在 HTTP 1.0 版本，默認使用的是「短鏈接」（那時候是 Web 誕生初期，網頁相對簡單，「短鏈接」的問題不大）。

到了1995年末開始制定 HTTP 1.1 草案的時候，網頁已經開始變得複雜（網頁內的圖片、腳本愈來愈多了），這時候再用短鏈接的方式，效率過低下了（由於創建 TCP 鏈接是有「時間成本」和「CPU成本」），因此，在 HTTP 1.1 中，默認採用的是「Keep-Alive」的方式。

六、SSL/TLS協議的基本運行過程

SSL/TLS協議的基本思路是採用公鑰加密法，也就是說，客戶端先向服務器端索要公鑰，而後用公鑰加密信息，服務器收到密文後，用本身的私鑰解密，可是這裏有兩個問題：

（1）、如何保證公鑰不被篡改？

解決方法：將公鑰放在數字證書中，只要證書是可信的，公鑰就是可信的。

（2）、公鑰加密計算量太大，如何減小耗用的時間？

解決方法：每一次對話（session），客戶端和服務器端都生成一個"對話密鑰"（session key），用它來加密信息。因爲"對話密鑰"是對稱加密，因此運算速度很是快，而服務器公鑰只用於加密"對話密鑰"自己，這樣就減小了加密運算的消耗時間。

所以，SSL/TLS協議的基本過程是這樣的：

（1）、客戶端向服務器端索要並驗證公鑰。

（2）、雙方協商生成「對話密鑰」。

（3）、雙方採用「對話密鑰」進行加密通訊。

上面過程的前兩步，又稱爲「握手階段」（handshake）。

以上圖片就是「握手階段」涉及四次通訊，須要注意的是，「握手階段」的全部通訊都是明文的。

七、SSL、HTTP和HTTPS協議的聯繫

SSL是Netscape公司所提出的安全保密協議，在瀏覽器(如Internet Explorer、Netscape Navigator)和Web服務器(如Netscape的Netscape Enterprise Server、ColdFusion Server等等)之間構造安全通道來進行數據傳輸，SSL運行在TCP/IP層之上、應用層之下，爲應用程序提供加密數據通道，它採用了RC四、MD5 以及RSA等加密算法，使用40位的密鑰，適用於商業信息的加密。

同時，Netscape公司相應開發了HTTPS協議並內置於其瀏覽器中，HTTPS實際上就是SSL over HTTP，它使用默認端口443，而不是像HTTP那樣使用端口80來和TCP/IP進行通訊。HTTPS協議使用SSL在發送方把原始數據進行加密，而後在接受方進行解密，加密和解密須要發送方和接受方經過交換共知的密鑰來實現，所以，所傳送的數據不容易被網絡黑客截獲和解密。

然而，加密和解密過程須要耗費系統大量的開銷，嚴重下降機器的性能，相關測試數據代表使用HTTPS協議傳輸數據的工做效率只有使用HTTP協議傳輸的十分之一。

假如爲了安全保密，將一個網站全部的Web應用都啓用SSL技術來加密，並使用HTTPS協議進行傳輸，那麼該網站的性能和效率將會大大下降，並且沒有這個必要，由於通常來講並非全部數據都要求那麼高的安全保密級別，因此，咱們只需對那些涉及機密數據的交互處理使用HTTPS協議，這樣就作到魚與熊掌兼得（具體可查看馬海祥博客《從SEO的角度來分析網站是否該採用HTTPS協議》的相關介紹）。

總之不須要用https的地方，就儘可能不要用。

八、HTTPS協議的需求是什麼？

花了好多口水，終於把背景知識說完了，下面正式進入正題，先來講說當初設計HTTPS是爲了知足哪些需求？

不少介紹 HTTPS 的文章一上來就給你講實現細節，對此，馬海祥以爲這是很差的作法，一上來就給你講協議細節，你充其量只能知道如何作，沒法理解爲何，我在前一個章節講了「背景知識」，在這個章節講了「需求」，這就有助於你理解了。

爲何要設計成這樣？——這就是 WHY 型的問題。

（1）、兼容性

由於是先有 HTTP 再有 HTTPS，因此，HTTPS 的設計者確定要考慮到對原有 HTTP 的兼容性。

這裏所說的兼容性包括不少方面，好比已有的 Web 應用要儘量無縫地遷移到 HTTPS；好比對瀏覽器廠商而言，改動要儘量小。

基於「兼容性」方面的考慮，很容易得出以下幾個結論：

①、HTTPS仍是要基於 TCP 來傳輸

若是改成 UDP 做傳輸層，不管是 Web 服務端仍是瀏覽器客戶端，都要大改，動靜太大了。

②、單獨使用一個新的協議，把 HTTP 協議包裹起來

所謂的「HTTP over SSL」，其實是在原有的 HTTP 數據外面加了一層 SSL 的封裝，HTTP 協議原有的 GET、POST 之類的機制，基本上原封不動。

打個比方：若是原來的 HTTP 是塑料水管，容易被戳破；那麼現在新設計的 HTTPS 就像是在原有的塑料水管以外，再包一層金屬水管，一來，原有的塑料水管照樣運行；二來，用金屬加固了以後，不容易被戳破。

（2）、可擴展性

前面說了，HTTPS 至關因而「HTTP over SSL」。

若是 SSL 這個協議在「可擴展性」方面的設計足夠牛逼，那麼它除了能跟 HTTP 搭配，還可以跟其它的應用層協議搭配，豈不美哉？

如今看來，當初設計 SSL 的人確實比較牛，現在的 SSL/TLS 能夠跟不少經常使用的應用層協議（好比：FTP、SMTP、POP、Telnet）搭配，來強化這些應用層協議的安全性。

接着剛纔打的比方：若是把 SSL/TLS 視做一根用來加固的金屬管，它不只能夠用來加固輸水的管道，還能夠用來加固輸煤氣的管道。

（3）、保密性（防泄密）

HTTPS須要作到足夠好的保密性。

說到保密性，首先要可以對抗嗅探（行話叫 Sniffer），所謂的「嗅探」，通俗而言就是監視你的網絡傳輸流量，若是你使用明文的 HTTP 上網，那麼監視者經過嗅探，就知道你在訪問哪些網站的哪些頁面。

嗅探是最低級的攻擊手法，除了嗅探，HTTPS 還須要能對抗其它一些稍微高級的攻擊手法——好比「重放攻擊」（後面講協議原理的時候，會再聊）。

（4）、完整性（防篡改）

除了「保密性」，還有一個一樣重要的目標是「確保完整性」。

在發明 HTTPS 以前，因爲 HTTP 是明文的，不但容易被嗅探，還容易被篡改。

舉個例子：好比我們的網絡運營商（ISP）都比較流氓，常常有網友抱怨說訪問某網站（原本是沒有廣告的），居然會跳出不少中國電信的廣告，爲啥會這樣呢？由於你的網絡流量須要通過 ISP 的線路才能到達公網，若是你使用的是明文的 HTTP，ISP 很容易就能夠在你訪問的頁面中植入廣告。

因此，當初設計 HTTPS 的時候，還有一個需求是「確保 HTTP 協議的內容不被篡改」。

（5）、真實性（防假冒）

在談到 HTTPS 的需求時，「真實性」常常被忽略，其實「真實性」的重要程度不亞於前面的「保密性」和「完整性」。

舉個例子：你由於使用網銀，須要訪問該網銀的 Web 站點，那麼，你如何確保你訪問的網站確實是你想訪問的網站？

有些天真的同窗會說：經過看網址裏面的域名，來確保，爲啥說這樣的同窗是「天真的」？由於 DNS 系統自己是不可靠的（尤爲是在設計 SSL 的那個年代，連 DNSSEC 都還沒發明），因爲 DNS 的不可靠（存在「域名欺騙」和「域名劫持」），你看到的網址裏面的域名未必是真實滴！

因此，HTTPS 協議必須有某種機制來確保「真實性」的需求（至於如何確保，後面會細聊）。

九、HTTPS和HTTP的區別

超文本傳輸協議HTTP協議被用於在Web瀏覽器和網站服務器之間傳遞信息，HTTP協議以明文方式發送內容，不提供任何方式的數據加密，若是攻擊者截取了Web瀏覽器和網站服務器之間的傳輸報文，就能夠直接讀懂其中的信息，所以HTTP協議不適合傳輸一些敏感信息，好比信用卡號、密碼等。

爲了解決HTTP協議的這一缺陷，須要使用另外一種協議：安全套接字層超文本傳輸協議HTTPS。

爲了數據傳輸的安全，HTTPS在HTTP的基礎上加入了SSL協議，SSL依靠證書來驗證服務器的身份，併爲瀏覽器和服務器之間的通訊加密。

通常來講，HTTPS和HTTP的區別主要爲如下四點：

（1）、https協議須要到ca申請證書，通常免費證書不多，須要交費。

（2）、http是超文本傳輸協議，信息是明文傳輸，https則是具備安全性的ssl加密傳輸協議。

（3）、http和https使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是80，後者是443。

（4）、http的鏈接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全（具體可查看馬海祥博客《HTTP與HTTPS的區別》的相關介紹）。

十、HTTPS和HTTP的性能比較

再來講最後一個需求——性能。

原本簡單的http協議，一個get一個response，因爲https要還密鑰和確認加密算法的須要，單握手就須要六、7個往返，任何應用中，過多的round trip確定影響性能，接下來纔是具體的http協議，每一次響應或者請求，都要求客戶端和服務端對會話的內容作加密/解密。

儘管對稱加密/解密效率比較高，但是仍然要消耗過多的CPU，爲此有專門的SSL芯片，若是CPU信能比較低的話，確定會下降性能，從而不能serve更多的請求，加密後數據量的影響，因此，纔會出現那麼多的安全認證提示（具體可查看馬海祥博客《HTTPS對網站性能優化的影響》的相關介紹）。

通常來講，引入HTTPS以後，不能致使性能變得太差，不然的話，誰還願意用？

爲了確保性能，SSL 的設計者至少要考慮以下幾點：

（1）、如何選擇加密算法（「對稱」or「非對稱」）？

（2）、如何兼顧 HTTP 採用的「短鏈接」TCP 方式？

SSL 是在1995年以前開始設計的，那時候的 HTTP 版本仍是 1.0，默認使用的是「短鏈接」的 TCP 方式——默認不啓用 Keep-Alive。

HTTPS的關鍵性能影響是CPU和往返，若是CPU很強的話，性能可能就是有人講的80%；若是cpu是瓶頸的話，有人講原來能夠server330-500個請求每秒，如今只有30-50%，所以在使用https請求數據的時候要注意看看你的項目裏面是否真的須要。

馬海祥博客點評：

HTTPS是爲了安全性而設置的，要驗證不少的信息，相對應http請求的速度確定有點慢，若是使用HTTPS的話很麻煩的，無心給服務器和客戶端增長了很大的壓力，因此，平時最好不要使用HTTPS，若是牽扯到我的隱私或者是其餘的什麼重要信息就必定要這麼作了。

不少的時候你感受有點問題，可是若是不去細細發覺的話，暫時沒有什麼問題，可是在你後面的維護，或者出問題的時候會弄的頭痛不已，爲了之後的方便，仍是此刻就好好的把每一件事作好，分析好！
本文爲馬海祥博客原創文章，如想轉載，請註明原文網址摘自於http://www.mahaixiang.cn/inte...，註明出處；不然，禁止轉載；謝謝配合！