ssl和tls

 

HTTP 是一個網絡協議，是專門用來幫你傳輸 Web 內容

SSL 是Secure Sockets Layer 爲啥要發明 SSL 這個協議捏？由於原先互聯網上使用的 HTTP 協議是明文的，存在不少缺點——好比傳輸內容會被偷窺（嗅探）和篡改。發明 SSL 協議，就是爲了解決這些問題。到了1999年，SSL 由於應用普遍，已經成爲互聯網上的事實標準。IETF 就在那年把 SSL 標準化標準化以後的名稱改成 TLS（是「Transport Layer Security」的縮寫），中文叫作「傳輸層安全協議」。

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

HTTPS 協議，說白了就是「HTTP 協議」和「SSL/TLS 協議」的組合。你能夠把 HTTPS 大體理解爲——「HTTP over SSL」或「HTTP over TLS」（反正 SSL 和 TLS 差很少）。

TCP 協議是 HTTP 協議的基石——HTTP 協議須要依靠 TCP 協議來傳輸數據。

有不少常見的應用層協議是以 TCP 爲基礎的，好比「FTP、SMTP、POP、IMAP」等。
TCP 被稱爲「面向鏈接」的傳輸層協議。傳輸層主要有兩個協議，分別是 TCP 和 UDP。TCP 比 UDP 更可靠。你能夠把 TCP 協議想象成某個水管，發送端這頭進水，接收端那頭就出水。而且 TCP 協議可以確保，先發送的數據先到達（與之相反，UDP 不保證這點）。

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 協議的設計

由於是先有 HTTP 再有 HTTPS。因此，HTTPS 的設計者確定要考慮到對原有 HTTP 的兼容性。這裏所說的兼容性包括不少方面。好比已有的 Web 應用要儘量無縫地遷移到 HTTPS；好比對瀏覽器廠商而言，改動要儘量小；……基於「兼容性」方面的考慮，很容易得出以下幾個結論：1. HTTPS 仍是要基於 TCP 來傳輸（若是改成 UDP 做傳輸層，不管是 Web 服務端仍是瀏覽器客戶端，都要大改，動靜太大了）2. 單獨使用一個新的協議，把 HTTP 協議包裹起來（所謂的「HTTP over SSL」，其實是在原有的 HTTP 數據外面加了一層 SSL 的封裝。HTTP 協議原有的 GET、POST 之類的機制，基本上原封不動）