開啟掘金成長之旅！這是我參與「掘金日新計劃 · 12 月更文挑戰」的第14天

書接上文《圖解 HTTP 》閱讀筆記（二），我們繼續探索總結http的相關知識點。

我們還是先把問題擺到檯面，帶著問題讀文章。

6.第九章&第十章 知識點

6.1 HTTP的瓶頸以及相應解決方案

HTTP優缺點分析的時候，我們是相對於HTTPS來分析的，但是實際上，HTTP儘管簡單、通用、擴充套件性高，但是本身存在很多瓶頸。 - 一條連線上只可傳送一個請求。 - 請求只能從客戶端開始。客戶端不可以接收除響應以外的指令。 - 請求/響應首部未經壓縮就傳送。首部資訊越多延遲越大。 - 傳送冗長的首部。每次互相傳送相同的首部造成的浪費較多。 - 可任意選擇資料壓縮格式。非強制壓縮傳送。

6.1.1 Ajax的解決方法

Ajax（Asynchronous JavaScript and XML，非同步JavaScript與XML技術）是一種有效利用JavaScript和DOM（Document Object Model，文件物件模型）的操作，以達到區域性Web頁面替換載入的非同步通訊手段。和以前的同步通訊相比，由於它只更新一部分頁面，響應中傳輸的資料量會因此而減少，這一優點顯而易見。

6.1.2 Comet的解決方法

區域性資料更新有了解決方法，但是服務端主動通知客戶端的功能，http還是沒有，所以這時有了變相的實現方案Comet

通常，伺服器端接收到請求，在處理完畢後就會立即返回響應，但為了實現推送功能，Comet會先將響應置於掛起狀態，當伺服器端有內容更新時，再返回該響應。因此，伺服器端一旦有更新，就可以立即反饋給客戶端。

6.1.3 SPDY的解決方法

陸續出現的Ajax和Comet等提高易用性的技術，一定程度上使HTTP得到了改善，但HTTP協議本身的限制也令人有些束手無策。為了進行根本性的改善，需要有一些協議層面上的改動。 SPDY以會話層的形式加入，控制對資料的流動，但還是採用HTTP建立通訊連線。因此，可照常使用HTTP的GET和POST等方法、Cookie以及HTTP報文等。

SPDY實現的功能有：多路複用流（一個TCP連線可以處理多個請求）、請求首部壓縮、推送功能（服務端推送客戶端）使用SSL作為傳輸協議提供資料安全。 SPDY的主要目的是減少50%25以上的頁面載入時間，但是不增加部署的複雜性，不影響客戶端和服務端的Web應用，只需要瀏覽器和Web伺服器支援SPDY。

6.1.4 WebSocket的解決方法

WebSocket則提供使用一個TCP連線進行雙向通訊的機制，包括網路協議和API，以取代網頁和伺服器採 用HTTP輪詢進行雙向通訊的機制。 一旦Web伺服器與客戶端之間建立起WebSocket協議的通訊連線，之後所有的通訊都依靠這個專用協議進行。通訊過程中可互相傳送JSON、XML、HTML或圖片等任意格式的資料。 由於是建立在HTTP基礎上的協議，因此連線的發起方仍是客戶端，而一旦確立WebSocket通訊連線，不論伺服器還是客戶端，任意一方都可直接向對方傳送報文。

6.2 WebSocket與SPDY的區別

相同： 兩者都是為了解決HTTP的若干瓶頸而提出的解決方案 不同： 1）兩者的側重點不同，SPDY側重於提高網頁的載入速度，而且總體要求不高，只要客戶端和服務端都支援即可。而WebSocket側重於提供使用一個TCP連線，實現全雙工通訊的一種協議。 2）對應在OSI七層模型中，SPDY屬於會話層協議，WebSocket屬於應用層協議。

6.3 HTTP1.0/1.1/2.0的區別

6.3.1 HTTP1.0/1.1

持久化連線： HTTP1.0一次TCP連線只能進行一次的請求和響應，HTTP1.1可以支援一個TCP連線，多次的請求和響應。 節省資源： HTTP1.1可以支援範圍（Range）資源請求，而不是HTTP1.0，只能請求整個資源。 HOST支援： 由於虛擬主機的出現，一個主機可以有多個域名，所以HTTP1.1請求頭中新增了HOST。 快取處理： 在HTTP1.0中主要使用header裡的If-Modified-Since,Expires來做為快取判斷的標準，HTTP1.1則引入了更多的快取控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的快取頭來控制緩 狀態碼增加： 在HTTP1.1中新增了24個錯誤狀態響應碼

6.3.2 HTTP1.1/2.0

多路複用： HTTP2.0，可以支援一個TCP連線，併發多次請求，而不是HTTP1.1,只支援序列請求。

首部壓縮： HTTP1.1 與 HTTP 2.0 HTTP2.0都支援訊息主體的壓縮，但是HTTP2.0同時也支援首部報文中的請求首部、通用首部、響應首部、實體首部等支援壓縮。 雙方通訊： HTTP1.1不支援服務端到客戶端的主動推送功能，從而有了後面的comet、spdy、websocket解決方案，HTTP2.0預設支援全雙工通訊。

6.4 HTTPS工作原理

合法認證機構的CA證書是內建在瀏覽器，也就是客戶端裡面的。 1.HTTP 請求服務端生成證書，服務端將自己的公鑰，發給認證機構，認證機構使用自己的私鑰進行加密，生成證書，回傳給服務端，然後服務端給到客戶端 2.瀏覽器開始查詢作業系統中已內建的受信任的證書釋出機構CA，與伺服器發來的證書中的頒發者CA比對，用於校驗證書是否為合法機構頒發 3.如果為合法的，則使用客戶端使用內建的認證機構的公鑰進行解密，對證書的有效期、合法性、域名是否與請求的域名一致、證書的公鑰等進行校驗 4.客戶端使用服務端的公鑰，進行共享金鑰（偽隨機數生成器生成加密所使用的對稱金鑰）的加密，然後傳送給服務端 5.服務端拿到加密內容之後，用服務端私鑰進行解密，得到共享金鑰 6.雙方開始使用共享金鑰進行資料的加密通訊

7. 總結

好了，文章寫到這裡，《圖解HTTP》一書的主要內容，以及我們開文所提出的一些問題，都已經總結完成，各位請對照思維導圖，在自己的思維宮殿中，找尋一下這些問題的答案。