国产亚洲欧美人成在线,免费视频爱爱太爽了无码,日本免费一区二区三区高清视频 ,国产真实伦对白精彩视频

歡迎您光臨深圳塔燈網(wǎng)絡(luò)科技有限公司！
電話圖標(biāo) 余先生：13699882642

網(wǎng)站百科

為您解碼網(wǎng)站建設(shè)的點點滴滴

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

發(fā)表日期：2017-09 文章編輯：小燈 瀏覽次數(shù)：2740

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

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

1.確保 Web 安全的 HTTPS

1.1 HTTP 的缺點

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

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

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

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

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

  1. TCP/IP 是可能被竊聽的網(wǎng)絡(luò)

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

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

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

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

  • 通信的加密

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

http_encrypt.png

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

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

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

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

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

  • 任何人都可發(fā)起請求

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

http_request_all.png

HTTP 協(xié)議的實現(xiàn)本身非常簡單，不論是誰發(fā)送過來的請求都會返回響應(yīng)，因此不確認(rèn)通信方，會存在以下各種隱患：

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

  • 查明對手的證書

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

    證書由值得信任的第三方機構(gòu)頒發(fā)，用以證明服務(wù)器和客戶端是實際存在的。

http_request.png

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

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

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

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

像這樣，請求或響應(yīng)在傳輸途中，遭攻擊者攔截并篡改內(nèi)容的攻擊稱為中間人攻擊。

http_revise1.png

  • 如何防止篡改

    雖然有使用 HTTP 協(xié)議確認(rèn)報文完整性的方法，但事實上并不便捷、可靠。其中常用的是 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)。

1.2 HTTP + 加密 + 認(rèn)證 + 完整性保護 = HTTPS

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

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

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

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

https.png

1.2.2 HTTPS 是身披 SSL 外殼的 HTTP

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

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

https1.png

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

SSL 是獨立于 HTTP 的協(xié)議，所以不光是 HTTP 協(xié)議，其他運行在應(yīng)用層的 SMTP 和 Telnet 等協(xié)議均可配合 SSL 協(xié)議使用?？梢哉f SSL 是當(dāng)今世界上應(yīng)用最為廣泛的網(wǎng)絡(luò)安全技術(shù)。

1.2.3 相互交換密鑰的公開密鑰加密技術(shù)

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

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

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

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

以共享密鑰方式加密時必須將密鑰也給對方?？删烤乖鯓硬拍馨踩霓D(zhuǎn)交？在互聯(lián)網(wǎng)上轉(zhuǎn)發(fā)密鑰時，如果通信被監(jiān)聽那么密鑰就可會落入攻擊者之手，同時也就失去了加密的意義。另外還得設(shè)法安全地保管接收到的密鑰。

https3.png

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

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

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

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

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

https4.png

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

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

https5.png

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

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

為了解決上述問題，可以使用由數(shù)字證書認(rèn)證機構(gòu)（CA，Certificate Authority）和其他相關(guān)頒發(fā)的公開密鑰證書。

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

服務(wù)器會將這份由數(shù)字證書認(rèn)證機構(gòu)頒發(fā)的公鑰證書發(fā)送給客戶端，以進行公開密鑰加密方式通信。公鑰證書也可叫做數(shù)字證書或直接稱為證書。

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

https6.png

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

    EV SSL 證書是基于國際標(biāo)準(zhǔn)的認(rèn)證指導(dǎo)方針頒發(fā)的證書。其嚴(yán)格規(guī)定了對運營組織是否真實的確認(rèn)方針，因此，通過認(rèn)證的 Web 網(wǎng)站能夠獲得更高的認(rèn)可度。

  • 用以確認(rèn)客戶端的客戶端證書

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

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

  • 由自認(rèn)證機構(gòu)頒發(fā)的證書稱為自簽名證書
    如果使用 OpenSSL 這套開源程序，每個人都可以構(gòu)建一套屬于自己的認(rèn)證機構(gòu)，從而給自己頒發(fā)服務(wù)器證書。但該服務(wù)器證書在互聯(lián)網(wǎng)上不可作為證書使用，似乎沒什么幫助的。

    獨立機構(gòu)的認(rèn)證機構(gòu)叫做自認(rèn)證機構(gòu)，由自認(rèn)證機構(gòu)頒發(fā)的“無用”證書也被戲稱為自簽名證書。

1.2.5 HTTPS 的安全通信機制

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

https7.png
  • 步驟1：客戶端通過發(fā)送 Client Hello 報文開始 SSL 通信。報文中包含客戶端支持的 SSL 的指定版本、加密組件（Cipher Suite）列表（所使用的加密算法及密鑰長度等）。
  • 步驟2：服務(wù)器可進行 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 的隨機密碼串。該報文已用步驟 3 中的公開密鑰進行加密。
  • 步驟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 報文交換完畢之后，SSL 連接就算建立完畢。當(dāng)然，通信會受到 SSL 的保護。從此處開始進行應(yīng)用層協(xié)議的通信，即發(fā)送 HTTP 請求。
  • 步驟11：應(yīng)用協(xié)議通信，即發(fā)送 HTTP 響應(yīng)。
  • 步驟12：最后由客戶端斷開連接。斷開連接時，發(fā)送 close_notify 報文。

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

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

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

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

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

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

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

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

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

2. 確認(rèn)訪問用戶身份的認(rèn)證

2.1 何為認(rèn)證

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

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

HTTP 使用的認(rèn)證方式
HTTP/1.1 使用的認(rèn)證方式如下所示：

  • BASIC認(rèn)證（基本認(rèn)證）
  • DIGEST認(rèn)證（摘要認(rèn)證）
  • SSL 客戶端認(rèn)證
  • FormBase 認(rèn)證（基于表單認(rèn)證）

2.2 BASIC 認(rèn)證

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

  • BASIC 認(rèn)證的認(rèn)證步驟
basic.png

步驟1：當(dāng)請求的資源需要 BASIC 認(rèn)證時，服務(wù)器會隨狀態(tài)碼 401 Authorization Required，返回帶 WWW-Authenticate 首部字段的響應(yīng)。該字段內(nèi)包含認(rèn)證的方式（BASIC）及 Request-URI 安全域字符串（realm）。

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

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

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

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

BASIC 認(rèn)證使用上不夠靈活，且達不到多數(shù) Web 網(wǎng)站期望的安全性等級，因此它并不常用。

2.3 DIGEST 認(rèn)證

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

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

digest.png

因為發(fā)送給對方的只是響應(yīng)摘要及由知訊碼產(chǎn)生的計算結(jié)果，所以比起 BASIC 認(rèn)證，密碼泄露的可能性就降低了。

  • DIGEST 認(rèn)證的認(rèn)證步驟
digest1.png

步驟1：請求需認(rèn)證的資源時，服務(wù)器會隨著狀態(tài)碼 401 Authorication Required，返回帶WWW-Authenticate 首部字段的響應(yīng)。該字段內(nèi)包含質(zhì)問響應(yīng)方式認(rèn)證所需要的臨時咨詢碼（隨機數(shù)，nonce）。

首部字段 WWW-Authenticate 內(nèi)必須包含 realm 和 nonce 這兩個字段的信息?？蛻舳司褪且揽肯蚍?wù)器回送這兩個值進行認(rèn)證的。

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

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

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

并且這時會在首部字段 Authorization-Info 寫入一些認(rèn)證成功的相關(guān)信息。

2.4 SSL 客戶端認(rèn)證

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

2.4.1 SSL 客戶端認(rèn)證的認(rèn)證步驟

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

步驟1：接收到需要認(rèn)證資源的請求，服務(wù)器會發(fā)送 Certificate Request 報文，要求客戶端提供客戶端證書。

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

步驟3：服務(wù)器驗證客戶端證書驗證通過后方可領(lǐng)取證書內(nèi)客戶端的公開密鑰，然后開始 HTTPS 加密通信。

2.4.2 SSL 客戶端認(rèn)證采用雙因素認(rèn)證

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

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

2.4.3 SSL 客戶端認(rèn)證必要的費用

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

2.5 基于表單認(rèn)證

基于表單的認(rèn)證方法并不是在 HTTP 協(xié)議中定義的?？蛻舳藭蚍?wù)器上的 Web 應(yīng)用程序發(fā)送登錄信息，按登錄信息的驗證結(jié)果認(rèn)證。

多數(shù)情況下，輸入已事先登錄的用戶 ID 和密碼等登錄信息后，發(fā)送給 Web 應(yīng)用程序，基于認(rèn)證結(jié)果來決定認(rèn)證是否成功。

2.5.1 Session 管理及 Cookie 應(yīng)用

基于表單認(rèn)證的標(biāo)準(zhǔn)規(guī)范尚未有定論，一般會使用 Cookie 來管理 Session（會話）。

基于表單認(rèn)證本身是通過服務(wù)器端的 Web 應(yīng)用，將客戶端發(fā)送過來的用戶 ID 和密碼與之前登錄過的信息做匹配來進行認(rèn)證的。

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

cookie_session.png

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

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

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

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

3. 基于 HTTP 的功能追加協(xié)議

3.1 基于 HTTP 的協(xié)議

HTTP 功能上的不足可通過創(chuàng)建一套全新的協(xié)議來彌補?？墒悄壳盎?HTTP 的 Web 瀏覽器的使用環(huán)境已遍布全球，因此無法完全拋棄 HTTP。有一些新協(xié)議的規(guī)則是基于 HTTP 的，并在此基礎(chǔ)上添加了新的功能。

3.2 消除 HTTP 瓶頸的 SPDY

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

3.2.1 HTTP 的瓶頸

HTTP 存在以下缺點和不足：

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

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

而利用 Ajax 實時地從服務(wù)器獲取內(nèi)容，有可能會導(dǎo)致大量請求產(chǎn)生。

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

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

http_comet.png

3.2.2 SPDY 的設(shè)計與功能

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

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

spdy.png

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

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

3.2.3 SPDY 消除 Web 瓶頸了嗎

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

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

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

3.3.1 WebSocket 的設(shè)計與功能

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

3.3.2 WebSocket 協(xié)議

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

由于是建立在 HTTP 基礎(chǔ)上的協(xié)議，因此連接的發(fā)起方仍是客戶端，而一旦確立 WebSocket 通信連接，不論服務(wù)器還是客戶端，任意一方都可直接向?qū)Ψ桨l(fā)送報文。

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

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

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

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

子協(xié)議按 WebSocket 協(xié)議標(biāo)準(zhǔn)在連接分開使用時，定義那些連接的名稱。

  1. 握手·響應(yīng)
    對于之前的請求，返回狀態(tài)碼 101 Switching Protocols 的響應(yīng)。
“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 的數(shù)據(jù)幀，而采用 WebSocket 獨立的數(shù)據(jù)幀。

websocket.png

3.4 期盼已久的 HTTP/2.0

HTTP/2.0 在 2014 年 11 月實現(xiàn)標(biāo)準(zhǔn)化。

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

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

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

本頁內(nèi)容由塔燈網(wǎng)絡(luò)科技有限公司通過網(wǎng)絡(luò)收集編輯所得，所有資料僅供用戶學(xué)習(xí)參考，本站不擁有所有權(quán)，如您認(rèn)為本網(wǎng)頁中由涉嫌抄襲的內(nèi)容，請及時與我們聯(lián)系，并提供相關(guān)證據(jù)，工作人員會在5工作日內(nèi)聯(lián)系您，一經(jīng)查實，本站立刻刪除侵權(quán)內(nèi)容。本文鏈接:http://jstctz.cn/20442.html
相關(guān)開發(fā)語言
 八年  行業(yè)經(jīng)驗

多一份參考，總有益處

聯(lián)系深圳網(wǎng)站公司塔燈網(wǎng)絡(luò)，免費獲得網(wǎng)站建設(shè)方案及報價

咨詢相關(guān)問題或預(yù)約面談，可以通過以下方式與我們聯(lián)系

業(yè)務(wù)熱線：余經(jīng)理：13699882642

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

  • QQ咨詢
  • 在線咨詢
  • 官方微信
  • 聯(lián)系電話
    座機0755-29185426
    手機13699882642
  • 預(yù)約上門
  • 返回頂部