Https協議詳解

HTTP 的缺點

到現在爲止，我們已瞭解到 HTTP 具有相當優秀和方便的一面，然而 HTTP 並非只有好的一面，事物皆具兩面性，它也是有不足之處的。HTTP 主要有這些不足，例舉如下。
1、通信使用明文（ 不加密） ， 內容可能會被竊聽

2、不驗證通信方的身份， 因此有可能遭遇僞裝
3、無法證明報文的完整性， 所以有可能已遭篡改
這些問題不僅在 HTTP 上出現，其他未加密的協議中也會存在這類問題。
除此之外，HTTP 本身還有很多缺點。而且，還有像某些特定的 Web 服務器和特定的 Web 瀏覽器在實際應用中存在的不足（也可以說成是脆弱性或安全漏洞），另外，用 Java 和 PHP 等編程語言開發的 Web 應用也可能存在安全漏洞。

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

由於 HTTP 本身不具備加密的功能，所以也無法做到對通信整體（使用 HTTP 協議通信的請求和響應的內容）進行加密。即，HTTP 報文使用明文（指未經過加密的報文）方式發送。

TCP/IP 是可能被竊聽的網絡

如果要問爲什麼通信時不加密是一個缺點，這是因爲，按 TCP/IP 協議族的工作機制，通信內容在所有的通信線路上都有可能遭到窺視。

所謂互聯網，是由能連通到全世界的網絡組成的。無論世界哪個角落的服務器在和客戶端通信時，在此通信線路上的某些網絡設備 、光纜、計算機等都不可能是個人的私有物，所以不排除某個環節中會遭到惡意窺視行爲。

即使已經過加密處制理的通信，也會被窺視到通信內容，這點和未加密的通信是相同的。只是說如果通信經過加密，就有可能讓人無法破解報文信息的含義，但加密處理後的報文信息本身還是會被看到的。

圖： 互聯網上的任何角落都存在通信內容被竊聽的風險，竊聽相同段上的通信並非難事。只需要收集在互聯網上流動的數據包（幀）就行了。對於收集來的數據包的解析工作，可交給那些抓包（PacketCapture）或嗅探器（Sniffer）工具。

加密處理防止被竊聽

在目前大家正在研究的如何防止竊聽保護信息的幾種對策中，最爲普及的就是加密技術。加密的對象可以有這麼幾個。
通信的加密
一種方式就是將通信加密。HTTP 協議中沒有加密機制，但可以通過和SSL（Secure Socket Layer，安全套接層）或TLS（Transport LayerSecurity，安全層傳輸協議）的組合使用，加密 HTTP 的通信內容。
用 SSL 建立安全通信線路之後，就可以在這條線路上進行 HTTP 通信了。
與 SSL 組合使用的 HTTP 被稱爲 HTTPS（HTTP Secure，超文本傳輸安全協議）或 HTTP over SSL。

內容的加密
還有一種將參與通信的內容本身加密的方式。由於 HTTP 協議中沒有加密機制，那麼就對 HTTP 協議傳輸的內容本身加密。即把 HTTP 報文裏所含的內容進行加密處理。

在這種情況下，客戶端需要對 HTTP 報文進行加密處理後再發送請求。

誠然，爲了做到有效的內容加密，前提是要求客戶端和服務器同時具備加密和解密機制。主要應用在 Web 服務中。有一點必須引起注意，由於該方式不同於 SSL 或 TLS 將整個通信線路加密處理，所以內容仍有被篡改的風險。稍後我們會加以說明。

不驗證通信方的身份就可能遭遇僞裝

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

任何人都可發起請求

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

HTTP 協議的實現本身非常簡單，不論是誰發送過來的請求都會返回響應，因此不確認通信方，會存在以下各種隱患。
1、無法確定請求發送至目標的 Web 服務器是否是按真實意圖返回響應的那臺服務器。有可能是已僞裝的 Web 服務器。
2、無法確定響應返回到的客戶端是否是按真實意圖接收響應的那個客戶端。有可能是已僞裝的客戶端。
3、無法確定正在通信的對方是否具備訪問權限。因爲某些Web 服務器上保存着重要的信息， 只想發給特定用戶通信的權限。
4、無法判定請求是來自何方、出自誰手。

5、即使是無意義的請求也會照單全收。無法阻止海量請求下的DoS ***（ Denial of Service， 拒絕服務***） 。

查明對手的證書

雖然使用 HTTP 協議無法確定通信方，但如果使用 SSL 則可以。SSL 不僅提供加密處理，而且還使用了一種被稱爲證書的手段，可用於確定方。證書由值得信任的第三方機構頒發，用以證明服務器和客戶端是實際存在的。另外，僞造證書從技術角度來說是異常困難的一件事。所以只要能夠確認通信方（服務器或客戶端）持有的證書，即可判斷通信方的真實意圖。

通過使用證書，以證明通信方就是意料中的服務器。這對使用者個人來講，也減少了個人信息泄露的危險性。
另外，客戶端持有證書即可完成個人身份的確認，也可用於對 Web 網站的認證環節。

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

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

接收到的內容可能有誤

由於 HTTP 協議無法證明通信的報文完整性，因此，在請求或響應送出之後直到對方接收之前的這段時間內，即使請求或響應的內容遭到篡改，也沒有辦法獲悉。
換句話說，沒有任何辦法確認，發出的請求 響應和接收到的請求 響應是前後相同的。

比如，從某個 Web 網站上下載內容，是無法確定客戶端下載的文件和服務器上存放的文件是否前後一致的。文件內容在傳輸途中可能已經被篡改爲其他的內容。即使內容真的已改變，作爲接收方的客戶端也是覺察不到的。像這樣，請求或響應在傳輸途中，遭***者攔截並篡改內容的***稱爲中間人***（Man-in-the-Middle attack，MITM）。

如何防止篡改

雖然有使用 HTTP 協議確定報文完整性的方法，但事實上並不便捷、可靠。其中常用的是 MD5 和 SHA-1 等散列值校驗的方法，以及用來確認文件的數字簽名方法。

提供文件下載服務的 Web 網站也會提供相應的以 PGP（Pretty GoodPrivacy，完美隱私）創建的數字簽名及 MD5 算法生成的散列值。PGP 是用來證明創建文件的數字簽名，MD5 是由單向函數生成的散列值。不論使用哪一種方法，都需要操縱客戶端的用戶本人親自檢查驗證下載的文件是否就是原來服務器上的文件。瀏覽器無法自動幫用戶檢查。
可惜的是，用這些方法也依然無法百分百保證確認結果正確。因爲 PGP 和MD5 本身被改寫的話，用戶是沒有辦法意識到的。

爲了有效防止這些弊端，有必要使用 HTTPS。SSL 提供認證和加密處理及摘要功能。僅靠 HTTP 確保完整性是非常困難的，因此通過和其他協議組合使用來實現這個目標。下節我們介紹 HTTPS 的相關內容。

確保 Web 安全的 HTTPS

在 HTTP 協議中有可能存在信息竊聽或身份僞裝等安全問題。使用 HTTPS 通信機制可以有效地防止這些問題。

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

HTTP 加上加密處理和認證以及完整性保護後即是 HTTPS
如果在 HTTP 協議通信過程中使用未經加密的明文，比如在 Web 頁面中輸入信用卡號，如果這條通信線路遭到竊聽，那麼信用卡號就暴露了。
另外，對於 HTTP 來說，服務器也好，客戶端也好，都是沒有辦法確認通信方的。
因爲很有可能並不是和原本預想的通信方在實際通信。並且還需要考慮到接收到的報文在通信途中已經遭到篡改這一可能性。
爲了統一解決上述這些問題，需要在 HTTP 上再加入加密處理和認證等機制。我們把添加了加密及認證機制的 HTTP 稱爲 HTTPS （HTTP Secure）。

經常會在 Web 的登錄頁面和購物結算界面等使用 HTTPS 通信。使用 HTTPS 通信時，不再用 http://，而是改用 https://。另外，當瀏覽器訪問 HTTPS 通信有效的 Web網站時，瀏覽器的地址欄內會出現一個帶鎖的標記。對 HTTPS 的顯示方式會因瀏覽器的不同而有所改變。

HTTPS 是身披 SSL 外殼的 HTTP

HTTPS 並非是應用層的一種新協議。只是 HTTP 通信接口部分用 SSL（SecureSocket Layer）和 TLS（Transport Layer Security）協議代替而已。
通常，HTTP 直接和 TCP 通信。當使用 SSL 時，則演變成先和 SSL 通信，再由 SSL和 TCP 通信了。簡言之，所謂 HTTPS，其實就是身披 SSL 協議這層外殼的HTTP。

在採用 SSL 後，HTTP 就擁有了 HTTPS 的加密、證書和完整性保護這些功能。SSL 是獨立於 HTTP 的協議，所以不光是 HTTP 協議，其他運行在應用層的 SMTP和 Telnet 等協議均可配合 SSL 協議使用。可以說 SSL 是當今世界上應用最爲廣泛的網絡安全術。

相互交換密鑰的公開密鑰加密技術

在對 SSL 進行講解之前，我們先來了解一下加密方法。SSL 採用一種叫做公開密鑰加密（Public-key cryptography）的加密處理方式。

近代的加密方法中加密算法是公開的，而密鑰卻是保密的。通過這種方式得以保持加密方法的安全性。
加密和解密都會用到密鑰。沒有密鑰就無法對密碼解密，反過來說，任何人只要持有密鑰就能解密了。如果密鑰被***者獲得，那加密也就失去了意義。

共享密鑰加密的困境

加密和解密同用一個密鑰的方式稱爲共享密鑰加密（Common key cryptosystem），也被叫做對稱密鑰加密。

以共享密鑰方式加密時必須將密鑰也發給對方。可究竟怎樣才能安全地轉交？在互聯網上轉發密鑰時，如果通信被監聽那麼密鑰就可會落入***者之手，同時也就失去了加密的意義。另外還得設法安全地保管接收到的密鑰。

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

公開密鑰加密方式很好地解決了共享密鑰加密的困難。
公開密鑰加密使用一對非對稱的密鑰。一把叫做私有密鑰（private key），另一把叫做公開密鑰（public key）。顧名思義，私有密鑰不能讓其他任何人知道，而公開密鑰則可以隨意發佈，任何人都可以獲得。公開密鑰和私有密鑰是配對的一套密鑰。
使用公開密鑰加密方式，發送密文的一方使用對方的公開密鑰進行加密處理，對方收到被加密的信息後，再使用自己的私有密鑰進行解密。利用這種方式，不需要發送用來解密的私有密鑰，也不必擔心密鑰被***者竊聽而盜走。
另外，要想根據密文和公開密鑰，恢復到信息原文是異常困難的，因爲解密過程就是在對離散對數進行求值，這並非輕而易舉就能辦到。退一步講，如果能對一個非常大的整數做到快速地因式分解，那麼密碼破解還是存在希望的。但就目前的技術來看是不太現實的。

HTTPS 採用混合加密機制

HTTPS 採用共享密鑰加密和公開密鑰加密兩者並用的混合加密機制。

但是公開密鑰加密與共享密鑰加密相比，其處理速度要慢。所以應充分利用兩者各自的優勢，將多種方法組合起來用於通信。在交換密鑰環節使用公開密鑰加密方式，之後的建立通信交換報文階段則使用共享密鑰加密方式。

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

遺憾的是，公開密鑰加密方式還是存在一些問題的。那就是無法證明公開密鑰本身就是貨真價實的公開密鑰。比如，正準備和某臺服務器建立公開密鑰加密方式下的通信時，如何證明收到的公開密鑰就是原本預想的那臺服務器發行的公開密鑰。或許在公開密鑰傳輸途中，真正的公開密鑰已經被***者替換掉了。
爲了解決上述問題，可以使用由數字證書認證機構（CA，Certificate Authority）和其相關機關頒發的公開密鑰證書。
數字證書認證機構處於客戶端與服務器雙方都可信賴的第三方機構的立場上。威瑞信（VeriSign）就是其中一家非常有名的數字證書認證機構。我們來介紹一下數字證書認證機構的業務流程。

首先，服務器的運營人員向數字證書認證機構提出公開密鑰的申請。數字證書認證機構在判明提出申請者的身份之後，會對已申請的公開密鑰做數字簽名，然後分配這個已簽名的公開密鑰，並將該公開密鑰放入公鑰證書後綁定在一起。
服務器會將這份由數字證書認證機構頒發的公鑰證書發送給客戶端，以進行公開密鑰加密方式通信。公鑰證書也可叫做數字證書或直接稱爲證書。接到證書的客戶端可使用數字證書認證機構的公開密鑰，對那張證書上的數字簽名進行驗證，一旦驗證通過，客戶端便可明確兩件事：一，認證服務器的公開密鑰的是真實有效的數字證書認證機構。二，服務器的公開密鑰是值得信賴的。
此處認證機關的公開密鑰必須安全地轉交給客戶端。使用通信方式時，如何安全轉交是一件很困難的事，因此，多數瀏覽器開發商發佈版本時，會事先在內部植入常用認證機關的公開密鑰。

HTTPS 的安全通信機制

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

步驟 1： 客戶端通過發送 Client Hello 報文開始 SSL 通信。報文中包含客戶端支持的 SSL 的指定版本、加密組件（Cipher Suite）列表（所使用的加密算法及密鑰長度等）。
步驟 2： 服務器可進行 SSL 通信時，會以 Server Hello 報文作爲應答。和客戶端一樣，在報文中包含 SSL 版本以及加密組件。服務器的加密組件內容是從接收到的客戶端加密組件內篩選出來的。
步驟 3： 之後服務器發送 Certificate 報文。報文中包含公開密鑰證書。
步驟 4： 最後服務器發送 Server Hello Done 報文通知客戶端，最初階段的SSL握手協商部分結束。

步驟 5： SSL 第一次握手結束之後，客戶端以 Client Key Exchange 報文作爲迴應。報文中包含通信加密中使用的一種被稱爲 Pre-master secret 的隨機密碼串。該報文已用步驟 3 中的公開密鑰進行加密。
步驟 6： 接着客戶端繼續發送 Change Cipher Spec 報文。該報文會提示服務器，在此報文之後的通信會採用 Pre-master secret 密鑰加密。
步驟 7： 客戶端發送 Finished 報文。該報文包含連接至今全部報文的整體校驗值。這次握手協商是否能夠成功，要以服務器是否能夠正確解密該報文作爲判定標準。

步驟 8： 服務器同樣發送 Change Cipher Spec 報文。
步驟 9： 服務器同樣發送 Finished 報文。

步驟 10： 服務器和客戶端的 Finished 報文交換完畢之後，SSL 連接就算建立完成。當然，通信會受到 SSL 的保護。從此處開始進行應用層協議的通信，即發送 HTTP請求。
步驟 11： 應用層協議通信，即發送 HTTP 響應。
步驟 12： 最後由客戶端斷開連接。斷開連接時，發送 close_notify 報文。上圖做了一些省略，這步之後再發送 TCP FIN 報文來關閉與 TCP 的通信。在以上流程中，應用層發送數據時會附加一種叫做 MAC（Message Authentication Code）的報文摘要。MAC 能夠查知報文是否遭到篡改，從而保護報文的完整性。
下面是對整個流程的圖解。圖中說明了從僅使用服務器端的公開密鑰證書（服務器證書）建立 HTTPS 通信的整個過程。

SSL 和 TLS

HTTPS 使用 SSL（Secure Socket Layer） 和 TLS（Transport LayerSecurity）這兩個協議。
SSL 技術最初是由瀏覽器開發商網景通信公司率先倡導的，開發過 SSL3.0之前的版本。目前主導權已轉移到 IETF（Internet Engineering Task Force，Internet 工程任務組）的手中。
IETF 以 SSL3.0 爲基準，後又制定了 TLS1.0、TLS1.1 和 TLS1.2。TSL 是以SSL 爲原型開發的協議，有時會統一稱該協議爲 SSL。當前主流的版本是SSL3.0 和 TLS1.0。
由於 SSL1.0 協議在設計之初被發現出了問題，就沒有實際投入使用。SSL2.0 也被發現存在問題，所以很多瀏覽器直接廢除了該協議版本。

SSL 速度慢嗎

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

SSL 的慢分兩種。一種是指通信慢。另一種是指由於大量消耗 CPU 及內存等資源，導致處理速度變慢。
1、和使用 HTTP 相比，網絡負載可能會變慢 2 到 100 倍。除去和 TCP 連接、發送 HTTP 請求 響應以外，還必須進行 SSL 通信，因此整體上處理通信量不可避免會增加。
2、另一點是 SSL 必須進行加密處理。在服務器和客戶端都需要進行加密和解密的運算處理。因此從結果上講，比起 HTTP 會更多地消耗服務器和客戶端的硬件資源，導致負載增強。
針對速度變慢這一問題，並沒有根本性的解決方案，我們會使用 SSL 加速器這種（專用服務器）硬件來改善該問題。該硬件爲 SSL 通信專用硬件，相對軟件來講，能夠提高數倍 SSL 的計算速度。僅在 SSL 處理時發揮 SSL加速器的功效，以分擔負載。

爲什麼不一直使用 HTTPS

既然 HTTPS 那麼安全可靠，那爲何所有的 Web 網站不一直使用 HTTPS？
其中一個原因是，因爲與純文本通信相比，加密通信會消耗更多的 CPU 及內存資源。如果每次通信都加密，會消耗相當多的資源，平攤到一臺計算機上時，能夠處理的請求數量必定也會隨之減少。
因此，如果是非敏感信息則使用 HTTP 通信，只有在包含個人信息等敏感數據時，才利用 HTTPS 加密通信。
特別是每當那些訪問量較多的 Web 網站在進行加密處理時，它們所承擔着的負載不容小覷。在進行加密處理時，並非對所有內容都進行加密處理，而是僅在那些需要信息隱藏時纔會加密，以節約資源。

除此之外，想要節約購買證書的開銷也是原因之一。

要進行 HTTPS 通信，證書是必不可少的。而使用的證書必須向認證機構（CA）購買。證書價格可能會根據不同的認證機構略有不同。通常，一年的授權需要數萬日元（現在一萬日元大約摺合 600 人民幣）。那些購買證書並不合算的服務以及一些個人網站，可能只會選擇採用HTTP 的通信方式。

消除 HTTP 瓶頸的 SPDY

HTTP 的瓶頸

在 Facebook 和 Twitter 等 SNS 網站上，幾乎能夠實時觀察到海量用戶公開發布的內容，這也是一種樂趣。當幾百、幾千萬的用戶發佈內容時，Web 網站爲了保存這些新增內容，在很短的時間內就會發生大量的內容更新。
爲了儘可能實時地顯示這些更新的內容，服務器上一有內容更新，就需要直接把那些內容反饋到客戶端的界面上。雖然看起來挺簡單的，但 HTTP 卻無法妥善地處理好這項任務。
使用 HTTP 協議探知服務器上是否有內容更新，就必須頻繁地從客戶端到服務器端進行確認。如果服務器上沒有內容更新，那麼就會產生徒勞的通信。
若想在現有 Web 實現所需的功能，以下這些 HTTP 標準就會成爲瓶頸。

1、一條連接上只可發送一個請求。

2、請求只能從客戶端開始。客戶端不可以接收除響應以外的指令。
3、請求 / 響應首部未經壓縮就發送。首部信息越多延遲越大。

4、發送冗長的首部。每次互相發送相同的首部造成的浪費較多。
5、可任意選擇數據壓縮格式。非強制壓縮發送。

Ajax 的解決方法

Ajax（Asynchronous JavaScript and XML， 異 步 JavaScript 與 XML 技術）是一種有效利用 JavaScript 和 DOM（Document Object Model，文檔對象模型）的操作，以達到局部 Web 頁面替換加載的異步通信手段。和以前的同步通信相比，由於它只更新一部分頁面，響應中傳輸的數據量會因此而減少，這一優點顯而易見。
Ajax 的核心技術是名爲 XMLHttpRequest 的 API，通過 JavaScript 腳本語言的調用就能和服務器進行 HTTP 通信。藉由這種手段就能從已加載完畢的 Web 頁面上發起請求，只更新局部頁面。
而利用 Ajax 實時地從服務器獲取內容，有可能會導致大量請求產生。另外，Ajax 仍未解決 HTTP 協議本身存在的問題。

Comet 的解決方法

一旦服務器端有內容更新了，Comet 不會讓請求等待，而是直接給客戶端返回響應。這是一種通過延遲應答，模擬實現服務器端向客戶端推送（Server Push）的功能。
通常，服務器端接收到請求，在處理完畢後就會立即返回響應，但爲了實現推送功能，Comet 會先將響應置於掛起狀態，當服務器端有內容更新時，再返回該響應。因此，服務器端一旦有更新，就可以立即反饋給客戶端。
內容上雖然可以做到實時更新，但爲了保留響應，一次連接的持續時間也變長了。期間，爲了維持連接會消耗更多的資源。另外，Comet 也仍未解決 HTTP 協議本身存在的問題。

SPDY 的目標

陸續出現的 Ajax 和 Comet 等提高易用性的技術，一定程度上使 HTTP 得到了改善，但 HTTP 協議本身的限制也令人有些束手無策。爲了進行根本性的改善，需要有一些協議層面上的改動。
處於持續開發狀態中的 SPDY 協議，正是爲了在協議級別消除 HTTP 所遭遇的瓶頸。

SPDY 的設計與功能

SPDY 沒有完全改寫 HTTP 協議，而是在 TCP/IP 的應用層與運輸層之間通過新加會話層的形式運作。同時，考慮到安全性問題， SPDY 規定通信中使用 SSL。SPDY 以會話層的形式加入，控制對數據的流動，但還是採用 HTTP 建立通信連接。因此，可照常使用 HTTP 的 GET 和 POST 等方 法、Cookie 以及 HTTP 報文等。

使用 SPDY 後，HTTP 協議額外獲得以下功能。

多路複用流

通過單一的 TCP 連接，可以無限制處理多個 HTTP 請求。所有請求的處理都在一條TCP 連接上完成，因此 TCP 的處理效率得到提高。

賦予請求優先級

SPDY 不僅可以無限制地併發處理請求，還可以給請求逐個分配優先級順序。這樣主要是爲了在發送多個請求時，解決因帶寬低而導致響應變慢的問題。

壓縮 HTTP 首部

壓縮 HTTP 請求和響應的首部。這樣一來，通信產生的數據包數量和發送的字節數就更少了。

推送功能

支持服務器主動向客戶端推送數據的功能。這樣，服務器可直接發送數據，而不必等待客戶端的請求。

服務器提示功能

服務器可以主動提示客戶端請求所需的資源。由於在客戶端發現資源之前就可以獲知資源的存在，因此在資源已緩存等情況下，可以避免發送不必要的請求。

SPDY 消除 W eb 瓶頸了嗎

希望使用 SPDY 時，Web 的內容端不必做什麼特別改動，而 Web 瀏覽器及 Web 服務器都要爲對應 SPDY 做出一定程度上的改動。有好幾家 Web 瀏覽器已經針對SPDY 做出了相應的調整。另外，Web 服務器也進行了實驗性質的應用，但把該技術導入實際的 Web 網站卻進展不佳。因爲 SPDY 基本上只是將單個域名（ IP 地址）的通信多路複用，所以當一個 Web 網站上使用多個域名下的資源，改善效果就會受到限制。SPDY 的確是一種可有效消除 HTTP 瓶頸的技術，但很多 Web 網站存在的問題並非僅僅是由 HTTP 瓶頸所導致。對 Web 本身的速度提升，還應該從其他可細緻鑽研的地方入手，比如改善 Web 內容的編寫方式等。

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

利用 Ajax 和 Comet 技術進行通信可以提升 Web 的瀏覽速度。但問題在於通信若使用HTTP 協議，就無法徹底解決瓶頸問題。WebSocket 網絡技術正是爲解決這些問題而實現的一套新協議及 API。
當時籌劃將 WebSocket 作爲 HTML5 標準的一部分，而現在它卻逐漸變成了獨立的協議標準。WebSocket 通信協議在 2011 年 12 月 11 日，被 RFC 6455 - The WebSocketProtocol 定爲標準。

W ebSocket 的設計與功能

WebSocket，即 Web 瀏覽器與 Web 服務器之間全雙工通信標準。其中，WebSocket協議由 IETF 定爲標準，WebSocket API 由 W3C 定爲標準。仍在開發中的 WebSocket技術主要是爲了解決 Ajax 和 Comet 裏 XMLHttpRequest 附帶的缺陷所引起的問題。

W ebSocket 協議

一旦 Web 服務器與客戶端之間建立起 WebSocket 協議的通信連接，之後所有的通信都依靠這個專用協議進行。通信過程中可互相發送 JSON、XML、HTML 或圖片等任意格式的數據。
由於是建立在 HTTP 基礎上的協議，因此連接的發起方仍是客戶端，而一旦確立WebSocket 通信連接，不論服務器還是客戶端，任意一方都可直接向對方發送報文。
下面我們列舉一下 WebSocket 協議的主要特點。

推送功能

支持由服務器向客戶端推送數據的推送功能。這樣，服務器可直接發送數據，而不必等待客戶端的請求。

減少通信量

只要建立起 WebSocket 連接，就希望一直保持連接狀態。和 HTTP 相比，不但每次連接時的總開銷減少，而且由於 WebSocket 的首部信息很小，通信量也相應減少了。
爲了實現 WebSocket 通信，在 HTTP 連接建立之後，需要完成一次“握手”（Handshaking）的步驟。
成功握手確立 WebSocket 連接之後，通信時不再使用 HTTP 的數據幀，而採用 WebSocket 獨立的數據幀。

期盼已久的 HTTP/2.0

目前主流的 HTTP/1.1 標準，自 1999 年發佈的 RFC2616 之後再未進行過改訂。
SPDY 和 WebSocket 等技術紛紛出現，很難斷言 HTTP/1.1 仍是適用於當下的 Web的協議。
負責互聯網技術標準的 IETF（Internet Engineering Task Force，互聯網工程任務組）創立 httpbis（Hypertext Transfer Protocol Bis，http://datatracker.ietf.org/wg/httpbis/）工作組，其目標是推進下一代 HTTP——HTTP/2.0 在 2014 年 11 月實現標準化。

HTTP/2.0 的特點

HTTP/2.0 的目標是改善用戶在使用 Web 時的速度體驗。由於基本上都會先通過HTTP/1.1 與 TCP 連接，現在我們以下面的這些協議爲基礎，探討一下它們的實現方法。
SPDY
HTTP Speed ＋ Mobility
Network-Friendly HTTP Upgrade
HTTP Speed ＋ Mobility 由微軟公司起草，是用於改善並提高移動端通信時的通信速度和性能的標準。它建立在 Google 公司提出的 SPDY 與 WebSocket 的基礎之上。
Network-Friendly HTTP Upgrade 主要是在移動端通信時改善 HTTP 性能的標準。

HTTP/2.0 的 7 項技術及討論

HTTP/2.0 圍繞着主要的 7 項技術進行討論，現階段（2012 年 8 月 13 日），大都傾向於採用以下協議的技術。但是，討論仍在持續，所以不能排除會發生重大改變的可能性。

注：HTTP Speed ＋ Mobility 簡寫爲 Speed ＋ Mobility，Network-Friendly HTTP Upgrade 簡寫爲 Friendly。

Web 的***技術

互聯網上的***大都將 Web 站點作爲目標。本章講解具體有哪些*** Web 站點的手段，以及***會造成怎樣的影響。
簡單的 HTTP 協議本身並不存在安全性問題，因此協議本身幾乎不會成爲***的對象。應用 HTTP 協議的服務器和客戶端，以及運行在服務器上的 Web 應用等資源纔是***目標。
目前，來自互聯網的***大多是衝着 Web 站點來的，它們大多把 Web 應用作爲***目標。本章主要針對 Web 應用的***技術進行講解。

HTTP 不具備必要的安全功能

與最初的設計相比，現今的 Web 網站應用的 HTTP 協議的使用方式已發生了翻天覆地的變化。幾乎現今所有的 Web 網站都會使用會話（session）管理、加密處理等安全性方面的功能，而 HTTP 協議內並不具備這些功能。
從整體上看，HTTP 就是一個通用的單純協議機制。因此它具備較多優勢，但是在安全性方面則呈劣勢。

就拿遠程登錄時會用到的 SSH 協議來說，SSH 具備協議級別的認證及會話管理等功能，HTTP 協議則沒有。另外在架設 SSH 服務方面，任何人都可以輕易地創建安全等級高的服務，而 HTTP 即使已架設好服務器，但若想提供服務器基礎上的 Web 應
用，很多情況下都需要重新開發。
因此，開發者需要自行設計並開發認證及會話管理功能來滿足 Web 應用的安全。而自行設計就意味着會出現各種形形色色的實現。結果，安全等級並不完備，可仍在運作的 Web 應用背後卻隱藏着各種容易被***者濫用的安全漏洞的 Bug。

在客戶端即可篡改請求

在 Web 應用中，從瀏覽器那接收到的 HTTP 請求的全部內容，都可以在客戶端自由地變更、篡改。所以 Web 應用可能會接收到與預期 數據不相同的內容。
在 HTTP 請求報文內加載***代碼，就能發起對 Web 應用的***。通過 URL 查詢字段或表單、HTTP 首部、Cookie 等途徑把***代碼傳入，若這時 Web 應用存在安全漏洞，那內部信息就會遭到竊取，或被***者拿到管理權限。

對 Web 應用的***模式有以下兩種。主動***和被動***。

以服務器爲目標的主動***

主動***（active attack）是指***者通過直接訪問 Web 應用，把***代碼傳入的***模式。由於該模式是直接針對服務器上的資源進行***，因此***者需要能夠訪問到那些資源。主動***模式裏具有代表性的***是 SQL 注入***和 OS 命令注入***。

以服務器爲目標的被動***

被動***（passive attack）是指利用圈套策略執行***代碼的***模式。在被動***過程中，***者不直接對目標 Web 應用訪問發起***。
被動***通常的***模式如下所示。
步驟 1： ***者誘使用戶觸發已設置好的陷阱，而陷阱會啓動發送已嵌入***代碼的 HTTP 請求。
步驟 2： 當用戶不知不覺中招之後，用戶的瀏覽器或郵件客戶端就會觸發這個陷阱。
步驟 3： 中招後的用戶瀏覽器會把含有***代碼的 HTTP 請求發送給作爲***目標的 Web 應用，運行***代碼。
步驟 4： 執行完***代碼，存在安全漏洞的 Web 應用會成爲***者的跳板，可能導致用戶所持的 Cookie 等個人信息被竊取，登錄狀態中的用戶權限遭惡意濫用等後果。
被動***模式中具有代表性的***是跨站腳本***和跨站點請求僞造。


利用用戶的身份***企業內部網絡
利用被動***，可發起對原本從互聯網上無法直接訪問的企業內網等網絡的***。只要用戶踏入***者預先設好的陷阱，在用戶能夠訪問到的網絡範圍內，即使是企業內網也同樣會受到***。
很多企業內網依然可以連接到互聯網上，訪問 Web 網站，或接收互聯網發來的郵件。這樣就可能給***者以可乘之機，誘導用戶觸發陷阱後對企業內網發動***。

下面簡單介紹常見的幾種***模式

跨站腳本***

跨站腳本***（Cross-Site Scripting，XSS）是指通過存在安全漏洞的 Web 網站註冊用戶的瀏覽器內運行非法的 HTML 標籤或 JavaScript 進行的一種***。動態創建的 HTML 部分有可能隱藏着安全漏洞。就這樣，***者編寫腳本設下陷阱，用戶在
自己的瀏覽器上運行時，一不小心就會受到被動***。
跨站腳本***有可能造成以下影響。
1、利用虛假輸入表單騙取用戶個人信息。
2、利用腳本竊取用戶的 Cookie 值， 被害者在不知情的情況下， 幫助***者發送惡意請求。
3、顯示僞造的文章或圖片。

HTTP 首部注入***

HTTP 首部注入***（HTTP Header Injection）是指***者通過在響應首部字段內插入換行，添加任意響應首部或主體的一種***。屬於被動***模式。
向首部主體內添加內容的***稱爲 HTTP 響應截斷***（HTTP Response SplittingAttack）。
HTTP 首部注入***有可能會造成以下一些影響。
設置任何 Cookie 信息
重定向至任意 URL
顯示任意的主體（ HTTP 響應截斷***）

SQL 注入***

會執行非法 SQL 的 SQL 注入***
SQL 注入（SQL Injection）是指針對 Web 應用使用的數據庫，通過運行非法的 SQL 而產生的***。該安全隱患有可能引發極大的威脅，有時會直接導致個人信息及機密信息的泄露。
Web 應用通常都會用到數據庫，當需要對數據庫表內的數據進行檢索或添加、刪除等操作時，會使用 SQL 語句連接數據庫進行特定的操作。如果在調用 SQL 語句的方式上存在疏漏，就有可能執行被惡意注入（Injection）非法 SQL 語句。
SQL 注入***有可能會造成以下等影響。
1、非法查看或篡改數據庫內的數據
2、規避認證
執行和數據庫服務器業務關聯的程序等

OS 命令注入***

OS 命令注入***（OS Command Injection）是指通過 Web 應用，執行非法的操作系統命令達到***的目的。只要在能調用 Shell 函數的地方就有存在被***的風險。
可以從 Web 應用中通過 Shell 來調用操作系統命令。倘若調用 Shell 時存在疏漏，就可以執行插入的非法 OS 命令。
OS 命令注入***可以向 Shell 發送命令，讓 Windows 或 Linux 操作系統的命令行啓動程序。也就是說，通過 OS 注入***可執行 OS 上安裝着的各種程序。

不正確的錯誤消息處理

不正確的錯誤消息處理（Error Handling Vulnerability）的安全漏洞是指，Web 應用的錯誤信息內包含對***者有用的信息。與 Web 應用有關的主要錯誤信息如下所示。
1、W eb 應用拋出的錯誤消息
2、數據庫等系統拋出的錯誤消息
Web 應用不必在用戶的瀏覽畫面上展現詳細的錯誤消息。對***者來說，詳細的錯誤消息有可能給他們下一次***以提示。

開放重定向

開放重定向（Open Redirect）是一種對指定的任意 URL 作重定向跳轉的功能。而於此功能相關聯的安全漏洞是指，假如指定的重定向 URL 到某個具有惡意的 Web 網站，那麼用戶就會被誘導至那個 Web 網站。
開放重定向的***案例
我們以下面的 URL 做重定向爲例，講解開放重定向***案例。該功能就是向 URL 指定參數後，使本來的 URL 發生重定向跳轉。
http://example.com/?redirect=http://www.tricorder.jp
***者把重定向指定的參數改寫成已設好陷阱的 Web 網站對應的 連接，如下所示。
http://example.com/?redirect=http://hackr.jp
用戶看到 URL 後原以爲訪問 example.com，不料實際上被誘導至 hackr.jp 這個指定的重定向目標。
可信度高的 Web 網站如果開放重定向功能，則很有可能被***者選中並用來作爲釣魚***的跳板。

點擊劫持

點擊劫持（Clickjacking）是指利用透明的按鈕或鏈接做成陷阱，覆蓋在 Web 頁面之上。然後誘使用戶在不知情的情況下，點擊那個鏈接訪問內容的一種***手段。這種行爲又稱爲界面僞裝（UI Redressing）。
已設置陷阱的 Web 頁面，表面上內容並無不妥，但早已埋入想讓用戶點擊的鏈接。當用戶點擊到透明的按鈕時，實際上是點擊了已指定透明屬性元素的 iframe 頁面。
點擊劫持的***案例
下面以 SNS 網站的註銷功能爲例，講解點擊劫持***。利用該註銷功能，註冊登錄的 SNS 用戶只需點擊註銷按鈕，就可以從 SNS 網站上註銷自己的會員身份。
***者在預料用戶會點擊的 Web 頁面上設下陷阱。上圖中釣魚遊戲頁面上的 PLAY 按鈕就是這類陷阱的實例。
在做過手腳的 Web 頁面上，目標的 SNS 註銷功能頁面將作爲透明層覆蓋在遊戲網頁上。覆蓋時，要保證 PLAY 按鈕與註銷按鈕的頁面所在位置保持一致。
由於 SNS 網站作爲透明層被覆蓋，SNS 網站上處於登錄狀態的用戶訪問這個釣魚網站並點擊頁面上的 PLAY 按鈕之後，等同於點擊了 SNS 網站的註銷按鈕。

DoS ***

DoS ***（Denial of Service attack）是一種讓運行中的服務呈停止狀態的***。有時也叫做服務停止***或拒絕服務***。DoS ***的對象不僅限於 Web 網站，還包括網絡設備及服務器等。
主要有以下兩種 DoS ***方式。
1、集中利用訪問請求造成資源過載， 資源用盡的同時， 實際上服務也就呈停止狀態。
2、通過***安全漏洞使服務停止。
其中，集中利用訪問請求的 DoS ***，單純來講就是發送大量的合法請求。服務器很難分辨何爲正常請求，何爲***請求，因此很難防止 DoS ***。

多臺計算機發起的 DoS ***稱爲 DDoS ***（Distributed Denial of Serviceattack）。DDoS ***通常利用那些感染病毒的計算機作爲***者的***跳板。
內容來自：
《圖解HTTP》