一区二区三区欧美日韩-一区二区三区欧美-一区二区三区免费在线视频-一区二区三区免费在线观看-久久精品店-久久精品第一页

歡迎您光臨深圳塔燈網絡科技有限公司！
電話圖標 余先生：13699882642

網站百科

為您解碼網站建設的點點滴滴

《圖解HTTP》讀書筆記（三）

發表日期：2017-09 文章編輯：小燈 瀏覽次數：2721

前面兩篇文章中關于 HTTP 相關知識基本上介紹的差不多了，這篇文章是對 HTTP 協議的補充，主要介紹以下三點內容：

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

1.確保 Web 安全的 HTTPS

1.1 HTTP 的缺點

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

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

這些問題不僅在 HTTP 上出現，其他未加密的協議中也會存在這類問題。

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

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

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

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

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

竊聽相同段上的通信并非難事。只需要收集在互聯網上流動的數據包（幀）就行了。對于收集來的數據包的解析工作，可交給那些抓包或嗅探器工具。

http-defect.png
  1. 加密處理防止被竊聽

  • 通信的加密

    一種方式是將通信加密。HTTP 協議中沒有加密機制，但可以通過和 SSL（Secure Socket Layer，安全套接層）或 TLS（Transport Layer Security，安全傳輸層協議）的組合使用，加密 HTTP 的通信內容。

http_encrypt.png

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

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

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

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

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

  • 任何人都可發起請求

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

http_request_all.png

HTTP 協議的實現本身非常簡單，不論是誰發送過來的請求都會返回響應，因此不確認通信方，會存在以下各種隱患：

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

  • 查明對手的證書

    雖然使用 HTTP 協議無法確定通信方，但如果使用 SSL 則可以。SSL 不僅提供加密處理，而且還使用一種被稱為證書的手段，可用于確定方。

    證書由值得信任的第三方機構頒發，用以證明服務器和客戶端是實際存在的。

http_request.png

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

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

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

  • 接收到的內容可能有誤
    由于 HTTP 協議無法證明通信的報文的完整性，因此，沒有任何辦法確認，發出的請求/響應和接收到的請求/響應是前后相同的。
http_revise.png

像這樣，請求或響應在傳輸途中，遭攻擊者攔截并篡改內容的攻擊稱為中間人攻擊。

http_revise1.png

  • 如何防止篡改

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

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

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

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

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

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

如果在 HTTP 協議通信過程中使用未經加密的明文，比如在 Web 頁面中輸入信用卡號，如果這條通信線路遭到竊聽，那么信用卡號就暴露了。

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

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

https.png

1.2.2 HTTPS 是身披 SSL 外殼的 HTTP

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

通常，HTTP 直接和 TCP 通信。當使用 SSL 時，則演變成先和 SSL 通信，再由 SSL 和 TCP 通信了。簡言之，所謂 HTTPS，其實就是身披 SSL 外殼的 HTTP。

https1.png

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

SSL 是獨立于 HTTP 的協議，所以不光是 HTTP 協議，其他運行在應用層的 SMTP 和 Telnet 等協議均可配合 SSL 協議使用。可以說 SSL 是當今世界上應用最為廣泛的網絡安全技術。

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

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

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

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

  • 共享密鑰加密的困境
    加密和解密同用一個密鑰的方式叫做共享密鑰加密，也被稱為對稱密鑰加密。
https2.png

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

https3.png

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

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

    公開密鑰加密使用一對非對稱的密鑰。一把叫做私有密鑰，另一把叫做公開密鑰。私有密鑰不能讓其他任何人知道，而公有密鑰則可以隨意發布，任何人都可以獲得。

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

    另外，要想根據密文和公開密鑰，恢復到信息原文是異常困難的，因為解密過程就是在對離散對數進行求值，這并非輕而易舉就能辦到。

https4.png

  • HTTPS 采用混合加密機制
    HTTPS 采用共享密鑰加密和公開密鑰加密兩者并用的混合加密機制。若密鑰能夠實現安全交換，那么有可能會考慮僅使用公開密鑰加密來通信。但是公開密鑰加密和共享密鑰加密相比，其處理速度要慢。

    所以應充分利用兩者各自的優勢，將多種方法組合起來用于通信。在交換密鑰環節使用公開密鑰加密方式，之后的建立通信交換報文階段則使用共享密鑰加密方式。

https5.png

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

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

為了解決上述問題，可以使用由數字證書認證機構（CA，Certificate Authority）和其他相關頒發的公開密鑰證書。

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

服務器會將這份由數字證書認證機構頒發的公鑰證書發送給客戶端，以進行公開密鑰加密方式通信。公鑰證書也可叫做數字證書或直接稱為證書。

接到證書的客戶端可使用數字證書認證機構的公開密鑰，對那張證書上的數字簽名進行驗證，一旦驗證通過，客戶端便可明確兩件事：一，認證服務器的公開密鑰的是真實有效的數字證書認證機構。二，服務器的公開密鑰是值得信賴的。

https6.png

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

    EV SSL 證書是基于國際標準的認證指導方針頒發的證書。其嚴格規定了對運營組織是否真實的確認方針，因此，通過認證的 Web 網站能夠獲得更高的認可度。

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

    HTTPS 中還可以使用客戶端證書。以客戶端證書進行客戶端認證，證明服務器正在通信的對方始終是預料之內的客戶端，其作用跟服務器證書如出一轍。

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

  • 由自認證機構頒發的證書稱為自簽名證書
    如果使用 OpenSSL 這套開源程序，每個人都可以構建一套屬于自己的認證機構，從而給自己頒發服務器證書。但該服務器證書在互聯網上不可作為證書使用，似乎沒什么幫助的。

    獨立機構的認證機構叫做自認證機構，由自認證機構頒發的“無用”證書也被戲稱為自簽名證書。

1.2.5 HTTPS 的安全通信機制

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

https7.png
  • 步驟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 報文。

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

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

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

SSL 的慢是分兩種。一種是指通信慢。另一種是指由于大量消耗 CPU 及內存等資源，導致處理速度變慢。

和使用 HTTP 相比，網絡負載可能會變慢 2 到 100 倍。除去和 TCP 連接、發送 HTTP 請求/響應外，還必須進行 SSL 通信，因此整體上處理通信量不可避免會增加。

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

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

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

因此，如果是非敏感信息則使用 HTTP 通信，只有在包含個人信息等敏感數據時，才利用 HTTPS 加密通信。
2. 除此之外，想要節約購買證書的開銷也是原因之一。

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

2.1 何為認證

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

  • 密碼：只有本人才會知道的字符串信息。
  • 動態令牌：僅限本人持有的設備內顯示的一次性密碼。
  • 數字證書：僅限本人（終端）持有的信息。
  • 生物認證：指紋和虹膜等本人的生理信息
  • IC 卡等：僅限本人持有的信息。

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

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

2.2 BASIC 認證

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

  • BASIC 認證的認證步驟
basic.png

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

步驟2：接收到狀態碼 401 的客戶端為了通過 BASIC 認證，需要將用戶 ID 及密碼發送給服務器。發送的字符串內容是由用戶 ID 和密碼構成，兩者中間以冒號（：）連接后，再經過 Base64 編碼處理。將編碼后的字符串寫入首部字段 Authorization 后，發送請求。

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

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

另外，除此之外想再進行一次 BASIC 認證時，一般的瀏覽器卻無法實現認證注銷操作，這也是問題之一。

BASIC 認證使用上不夠靈活，且達不到多數 Web 網站期望的安全性等級，因此它并不常用。

2.3 DIGEST 認證

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

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

digest.png

因為發送給對方的只是響應摘要及由知訊碼產生的計算結果，所以比起 BASIC 認證，密碼泄露的可能性就降低了。

  • DIGEST 認證的認證步驟
digest1.png

步驟1：請求需認證的資源時，服務器會隨著狀態碼 401 Authorication Required，返回帶WWW-Authenticate 首部字段的響應。該字段內包含質問響應方式認證所需要的臨時咨詢碼（隨機數，nonce）。

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

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

步驟2：接收到401 狀態碼的客戶端，返回的響應中包含 DIGEST 認證必須的首部字段 Authorization 信息。首部字段 Authorization 內必須包含 username、realm、nonce、uri 和 response 的字段信息，其中，realm 和 nonce 就是之前從服務器接收到的響應中的字段。

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

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

2.4 SSL 客戶端認證

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

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

為達到 SSL 客戶端認證的目的，需要事先將客戶端證書分發給客戶端，且客戶端必須安裝此證書。

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

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

步驟3：服務器驗證客戶端證書驗證通過后方可領取證書內客戶端的公開密鑰，然后開始 HTTPS 加密通信。

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

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

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

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

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

2.5 基于表單認證

基于表單的認證方法并不是在 HTTP 協議中定義的。客戶端會向服務器上的 Web 應用程序發送登錄信息，按登錄信息的驗證結果認證。

多數情況下，輸入已事先登錄的用戶 ID 和密碼等登錄信息后，發送給 Web 應用程序，基于認證結果來決定認證是否成功。

2.5.1 Session 管理及 Cookie 應用

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

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

但鑒于 HTTP 是無狀態協議，之前已認證成功的用戶狀態無法通過協議層面保存下來。即，無法實現狀態管理，因此即使該用戶下一次繼續訪問，也無法區分他與其他的用戶。于是我們會使用 Cookie 來管理 Session，以彌補 HTTP 協議中不存在的狀態管理功能。

cookie_session.png

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

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

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

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

3. 基于 HTTP 的功能追加協議

3.1 基于 HTTP 的協議

HTTP 功能上的不足可通過創建一套全新的協議來彌補。可是目前基于 HTTP 的 Web 瀏覽器的使用環境已遍布全球，因此無法完全拋棄 HTTP。有一些新協議的規則是基于 HTTP 的，并在此基礎上添加了新的功能。

3.2 消除 HTTP 瓶頸的 SPDY

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

3.2.1 HTTP 的瓶頸

HTTP 存在以下缺點和不足：

  • 一條連接上只可發送一個請求
  • 請求只能從客戶端開始，客戶端不可以接收除響應以外的指令
  • 請求/響應首部未經壓縮就發送，首部信息越多延遲越大
  • 發送冗長的首部，每次互相發送相同的首部造成的浪費較多
  • 可任意選擇數據壓縮格式，非強制壓縮發送
http_weakness.png
  1. Ajax 的解決辦法

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

而利用 Ajax 實時地從服務器獲取內容，有可能會導致大量請求產生。

http_ajax.png
  1. Comet 的解決辦法
    一旦服務器有內容更新了，Comet 不會讓請求等待，而是直接給客戶端返回響應。這是一種通過延時應答，模擬實現服務器向客戶端推送的功能。

內容上雖然可以做到實時更新，但為了保留響應，一次連接的持續時間也變長了。期間，為了維持連接會消耗更多的資源。

http_comet.png

3.2.2 SPDY 的設計與功能

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

SPDY 以會話層的形式加入，控制對數據的流動，但還是采用 HTTP 建立通信連接。因此，可照常使用 HTTP 的 GET 和 POST 等方法，Cookie 以及 HTTP 報文等。

spdy.png

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

  • 多路復用流：通過單一的 TCP 連接，可以無限制處理多個 HTTP 請求。所有請求的處理都在一條 TCP 連接上完成，因此 TCP 的處理效率得到提高。
  • 賦予請求優先級：SPDY 不僅可以無限制地并發處理請求，還可以給請求逐個分配優先級順序。這樣主要是為了在發送多個請求時，解決因帶寬低而導致響應變慢的問題。
  • 壓縮 HTTP 首部：壓縮 HTTP 請求和響應的首部。這樣一來，通信產生的數據包數量和發送的字節數就更少了
  • 推送功能：支持服務器主動向客戶端推送數據的功能。這樣，服務器可直接發送數據，而不必等待客戶端的請求。
  • 服務器提示功能：服務器可以主動提示客戶端請求所需的資源。

3.2.3 SPDY 消除 Web 瓶頸了嗎

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

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

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

3.3.1 WebSocket 的設計與功能

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

3.3.2 WebSocket 協議

一旦 Web 服務器與客戶端之間建立起 WebSocket 協議的通信連接，之后所有的通信都依靠這個專用協議進行。通信過程中可相互發送 JSON、XML、HTML 或圖片等任意格式的數據。

由于是建立在 HTTP 基礎上的協議，因此連接的發起方仍是客戶端，而一旦確立 WebSocket 通信連接，不論服務器還是客戶端，任意一方都可直接向對方發送報文。

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

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

為了實現 WebSocket 通信，在 HTTP 連接建立之后，需要完成一次 “握手” 的步驟。

  1. 握手·請求
    為了實現 WebSocket 通信，需要用到 HTTP 的 Upgrade 首部字段，告知服務器通信協議發送改變，已達到握手的目的。
“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 字段內記錄著握手過程中必不可少的鍵值，Sec-WebSocket-Protocol 字段內記錄使用的子協議。

子協議按 WebSocket 協議標準在連接分開使用時，定義那些連接的名稱。

  1. 握手·響應
    對于之前的請求，返回狀態碼 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 的數據幀，而采用 WebSocket 獨立的數據幀。

websocket.png

3.4 期盼已久的 HTTP/2.0

HTTP/2.0 在 2014 年 11 月實現標準化。

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

HTTP/2.0 圍繞著主要的 7 項技術進行討論。

壓縮 SPDY、Friendly
多路復用 SPDY
TLS 義務化 Speed + Mobility
協商 Speed + Mobility
客戶端拉拽 Speed + Mobility
流量控制 SPDY
WebSocket Speed + Mobility

本頁內容由塔燈網絡科技有限公司通過網絡收集編輯所得，所有資料僅供用戶學習參考，本站不擁有所有權，如您認為本網頁中由涉嫌抄襲的內容，請及時與我們聯系，并提供相關證據，工作人員會在5工作日內聯系您，一經查實，本站立刻刪除侵權內容。本文鏈接:http://www.junxiaosheng.cn/20442.html
相關開發語言
 八年  行業經驗

多一份參考，總有益處

聯系深圳網站公司塔燈網絡，免費獲得網站建設方案及報價

咨詢相關問題或預約面談，可以通過以下方式與我們聯系

業務熱線：余經理：13699882642

Copyright ? 2013-2018 Tadeng NetWork Technology Co., LTD. All Rights Reserved.    

  • QQ咨詢
  • 在線咨詢
  • 官方微信
  • 聯系電話
    座機0755-29185426
    手機13699882642
  • 預約上門
  • 返回頂部
主站蜘蛛池模板： 久久综合亚洲色hezyo| 99国内偷揿国产精品人妻| 精品国产在线观看福利| 亚洲精品国产拍在线观看| 国内精品偷拍在线观看| 亚洲男同tv| 久久国产36精品色熟妇| 在线观看免费av网| 沦为公交两奶头春药高潮迭起| 51精品国产AV无码久久久| 免费视频精品38| 9久高清在线不卡免费无吗视频| 免费毛片在线视频| 99久久人妻无码精品系列性欧美| 欧式午夜理伦三级在线观看| 东莞桑拿美女| 性色无码AV久久蜜臀| 护士被老头边摸边吃奶的视频| 一个人在线观看免费高清视频在线观看 | 中文字幕日本一区| 美女被打开了屁股进去的视频 | 亚洲国产成人精品无码区5566| 黑人 尺寸 强行害怕 痛哭| 一本久道视频无线视频| 麻豆文化传媒一区二区| free俄罗斯性xxxxhd派对| 日韩综合网| 国模孕妇模特季玥之粉红| 在线看无码的免费网站| 嫩小幼处在线| 高H纯肉NP 弄潮NP男男| 我和妽妽在厨房里的激情区二区| 国产亚洲欧美高清在线| 伊人影院亚洲| 欧美最猛12teevideos欧美| 国产精品成人不卡在线观看| 亚洲免费黄色片| 毛片无码免费无码播放| 朝鲜女人性猛交| 亚洲成人免费在线| 久久婷婷久久一区二区三区 |