Http請求過程分解

 

轉載自：https://www.jianshu.com/p/116ebf3034d9

 

溫習下以下知識點：

1、TCP 
2、TCP的3次握手和4次揮手 
3、HTTP 
4、HTTPS 
5、SPDY
6、HTTP2.0
7、隧道
8、代理
9、InetAddress和InetSocketAddress

 

一.TCP

　　首先看下OSI七層協議（網絡體系下的關系）

　　

　　我們必須熟記着七層協議，發送時從應用層往下封裝，每層都加上各自層的頭部信息，然后通過最后一層物理層進行發送，在接收端進行解封裝。

　　然后看下七層每層所代表的意義：

　　

　　鏈路層：就是設備驅動程序和計算機的網卡，他們一起處理與電纜的物理操作細節

　　網絡層：處理數據在網絡中的路由（IPV4、IPV6）。舉例IP協議，就是一種不可靠的服務，只保證盡快的將數據從發送端傳到接收端，

　　　　　　不提供可靠性保證。

　　傳輸層：為兩台主機上的應用提供端對端的傳輸。

　　　　　　TCP：提供了安全可靠的端對端傳輸協議，面向連接，有着超時重傳、發送和接收端對端的確認機制，因此在應用層放心

　　　　　　UDP：提供了極簡的傳輸，不面向連接，只保證發出，不確保是否收到，因此可靠性必須在應用層保證

　　應用層：傳輸與應用程序邏輯相關的數據

　　　　　　HTTP：無狀態連接，

　　

 

 

 

　　我們來開始了解TCP，TCP是一個協議（Transfer Control Protocal），我們需要熟記TCP協議的數據結構：

　　

　　　各自字段的含義：

　　　

Source Port和Destination Port:分別占用16位，表示源端口號和目的端口號；用於區別主機中的不同進程，IP地址用來區分不同主機的，源端口號和目的端口號配合上IP首部中的源IP地址就能確定為一個TCP連接

Sequenece Number:用來標識從TCP發送端向TCP接收端的數據字節流，他表示在這個報文中的第一個數據字節流在數據流中的序號；主要用來解決網絡亂序的問題。

Acknowledgment Number：32位確認序號包發送確認的一端所期望收到的下一個序號，因此，確認需要應該是上次已成功收到數據字節序號+1，不過只有當標志位中的ACK標志(下面介紹)為1時該確認序列號的字段才有效。主要用來解決不丟包的問題。

Offset:給出首部中32bit字的數目，需要這個值是因為任選字段的長度是可變的。這個字段占4bit(最多能表示15個32bit的字，即4*15=60個字節的首部長度)，因此TCP最多有60個字節的首部。然而，沒有任選字段，正常的長度是20字節。

TCP Flags:TCP首部中有6個比特，它們總的多個可同時被設置為1，主要是用於操控TCP的狀態機，依次為URG，ACK，PSH，RST，SYN，FIN。

Window:窗口大小，也就是有名的滑動窗口，用來進行流量控制；這是一個復雜的問題

　　　針對TCP Flags：在Tcp通過三次握手建立連接后，通過Flags即可標示傳輸的意義。

　　　位碼即tcp標志位,有6種標示:SYN(synchronous建立聯機) ACK(acknowledgement 確認) PSH(push傳送) FIN(finish結束) RST(reset重置) URG(urgent緊急)Sequence number(順序號碼) Acknowledge number(確認號碼)

　　　現在來介紹一下這些的標志位

　　　　

URG:次標志表示TCP包的緊急指針域(后面馬上就要說到)有效，用來保證TCP連接不被中斷，並督促中間層設備要盡快處理這些數據。

ACK:此標志表示應答域有效，就是說前面所說的TCP的應答將會包含在TCP數據包中；有兩個取值：0和1，為1的時候表示應答域有效，反之為0。

PSH:這個標志位表示Push操作。所謂Push操作就是是在數據包到達接受端以后，立即傳送給應用程序，而不是在緩沖區排隊。

RST:這個標志位表示連接復位請求。用來復位哪些產生錯誤的鏈接，也被用來拒絕錯誤和非法的數據包。

SYN:表示同步序號，用來建立連接。SYN標志位和ACK標志位搭配使用，當連接請求的時候，

SYN=1，ACK=0；連接被響應的時候，SYN=1，ACK=1。這個標志的數據包常常被用來進行端口掃描。掃描者發送一個只有SYN的數據包，如果對方主機響應了一個數據包回來，就表明這台主機存在這個端口，但是由於這種掃描只是進行TCP三次握手的第一次握手，因此這種掃描的成功表明被掃描的機器很不安全，一台安全的主機將會強制要求一個連接嚴格的進行TCP的三次握手。

FIN:表示發送端已經達到數據末尾，也就是說雙方數據傳送完成，沒有數據可以傳送了，發送

FIN標志位的TCP數據包后，連接將斷開。這個表示的數據包也經常被用於進行端口掃描。

　　

二.TCP3次握手和4次揮手

　　因為TCP是面向連接的。所以需要建立連接之后才可以進行數據傳輸

　　

 　　握手說明：第一次，客戶端發送SYN報文，置發送序號為X，發送后狀態至為SYN_SNET

　　　　　　　　第二次，服務端接收到SYN報文后，向客戶端發送ACK+SYN報文，置ACK序號為x+1，發送序號為Y，發送后狀態置為SYN_Received

　　　　　　　　第三次，客戶端接收到服務端的報文后，發送ACK報文，並置ACK序號為Y+1，發送序號為Z

 

　　揮手說明：1:客戶端請求關閉連接，2:服務端收到后同意關閉連接，3：服務端請求關閉連接，4:客戶端確認服務端想關閉了連接，發送ack，並進入等待狀態，服務端收到ack后就關閉自己，而客戶端如果接下來再沒有收到服務端的請求包，也關閉自己的連接。

　　

　　（1）為何握手要三次：

　　　　因為防止發送端認為的失效的數據包又莫名其妙發送到了接收端。

　　（2）為何揮手要四次：　

　　　　TCP是面向連接的，可靠的，基於字節流的傳輸層協議。傳輸是雙工模型，即傳輸和發送兩個通道都是互不影響的，當發送端發送FIN包，僅僅代表不再發送數據包了，

　　　　但是可以接受，當接收端發送ACK代表他知道了發送端不再發送數據包了，因此他也發送FIN包告訴接收端他也不發送數據包了，因此隨着發送端發送一個ACK代表一次TCP

　　　　連接正常結束了。

 

三.HTTP

　　說明：計算機通過網絡通信的協議，是一種基於請求與響應、無狀態的、應用層的協議，常基於TCP／IP協議傳輸數據。

　　進一步說明：

　　　　請求與響應：客戶端發送數據，服務端響應數據

　　　　無狀態的：協議對通訊事務處理沒有記憶能力，因此連接之后，服務端返回數據之后，雙方斷開連接，不保存連接狀態。

　　　　針對無狀態的一些解決策略：引入了cookie技術保存信息

　　　　　　　　　　　　　　　　　HTTP1.1提出了持久連接（HTTP keep-alive）

　　　　　　　　　　　　　　　　　請求頭和響應頭中的控制緩存字符

　　（1）協議請求格式為

　　　　<請求方式> 空格 <url>空格<協議版本>空格,換行　　（請求行）

　　　　<請求頭，鍵：值>空格,換行

　　　　<請求頭，鍵：值>空格,換行

　　　　空格，換行

　　　　<請求體>

 

　　（2）協議響應格式：

　　　　<協議版本> 空格 <url>狀態碼<狀態原因>空格,換行　　（響應行）

　　　　<響應頭，鍵：值>空格,換行

　　　　<響應頭，鍵：值>空格,換行

　　　　空格，換行

　　　　<響應體>

 

　　　　端口號：

　　　　　　默認端口為80 

　　　　狀態碼：

　　　　　　1xx：指示信息--表示請求已接收，繼續處理。
　　　　　　2xx：成功--表示請求已被成功接收、理解、接受。
　　　　　　3xx：重定向--要完成請求必須進行更進一步的操作。
　　　　　　4xx：客戶端錯誤--請求有語法錯誤或請求無法實現。
　　　　　　5xx：服務器端錯誤--服務器未能實現合法的請求。

　　（3）緩存控制

　　　　

 

　　　　強制緩存：Expries(http1.0使用，http1.1被淘汰，因為返回服務器認為過期的時間戳，可能兩端時間戳不一致)、Cache-Control

　　　　對比緩存：Last-Modify/If-Modify-Since、ETag/If-none-Matched

　　　　在對比緩存生效時，狀態碼為304，並且報文大小和請求時間大大減少。原因是，服務端在進行標識比較后，只返回header部分，通過狀態碼通知客戶端使用緩存，不再需要將報文主體部分返回給客戶端。

 

　　　　體現在數據頭（請求頭或者響應頭），cache-control字段控制，值有

　　　　public、緩存被公共緩存（客戶端和服務器都可緩存）

　　　　private、緩存被私有緩存（只能被客戶端緩存），

　　　　no-cache、不緩存

　　　　no-store、不緩存

　　　　Only-If-cached、表示只接受被緩存的數據，這樣就在網絡請求的時候直接返回本身的緩存，如果沒有就報504.

　　　　max-age=60,60秒之后緩存過期

　　　　Transfer-Encoding:chunked,表示響應體或者請求體的長度不固定

　　　　Content-Length，代表請求體或者響應體的具體長度，與Transfer-Encoding互斥，即只能存在一個字段

　　　　

　　　　為方便大家理解，我們認為瀏覽器存在一個緩存數據庫,用於存儲緩存信息。
　　　　在客戶端第一次請求數據時，此時緩存數據庫中沒有對應的緩存數據，需要請求服務器，服務器返回后，將數據存儲至緩存數據庫中。

            

 

　　強制緩存：　　

　　已存在緩存數據時，僅基於強制緩存，請求數據的流程如下

 

 

　　　　對比緩存：

　　　　已存在緩存數據時，僅基於對比緩存，請求數據的流程如下

 

 

 

　　　　Last-Modify／If-Modify-Since，對比緩存策略　　　　　

　　　

　　　　第一次請求數據后返回有Last-Modified，服務器告訴瀏覽器數據最后的修改時間

　　　　　　　　

　　　　在其請求時請求報文就可以具備If-Modified-Since字段了，服務器就收到該請求報文，發現有If-Modified-Since字段，則將該字段與請求資源的最后修改時間進行對比，如果比較后發現后來又修改了，則返回響應碼200，如果發現沒有修改，則返回響應碼304，告訴瀏覽器上次的緩存可以繼續使用。

 

　　　　ETag/If-none-Matched(優先級比Last-Modified／If-Modified-Since高)

　　　　

　　　　第一次請求時返回的響應報文中又ETag字段，該字段由服務器按照一定規則生成，唯一標示該資源

　　　　

　　　　第二次請求服務器時，請求報文中就帶着In-None-Match字段，與最新資源比較，如果資源后來已經更改過那么就不匹配，返回200，重新返回新的數據；如果沒有更改過，就返回304，告訴瀏覽器，緩存可以用

 　　

　　格式也可以多個拼接，例如

　　　　Cache-Control：public, only-if-cached, max-stale=2419200

 

　　（4）長連接、短鏈接

　　　　　　Http的長連接、短鏈接其實就是TCP層面上的實現

　　　　　　短鏈接：（傳輸數據完了就進行TCP四次揮手）

　　　　　　　　建立連接->傳輸數據->斷開鏈接

　　　　　　長連接：（傳輸數據完了不進行TCP四次揮手）

　　　　　　　　建立連接->傳輸數據->保持鏈接->斷開連接

 

　　　　　　　　最初在http1.1上，connection：keep-alive。默認也是長連接。

　　　　　　　　長連接不代表永久連接，會設置超時時間。keep-alive：timeout=20

　　　　　　

　　（5）對比HTTP的get／post

　　　　緩存：get可緩存，post不行

　　　　編碼類型：get只有一種applicaiton／x-form-urlencoding，post至少有四種，上文有提到

　　　　對數據長度限制：由於get方式數據在url上，URL長度最長為2048個字符。post無限制

　　　　可見性：由於get方式數據在url上，可見，post不可見

　　　　安全性：post較get安全一點，但是如果被抓了包就沒辦法了，只有https了

　　

 

四.HTTPS

　　(1)什么是HTTPS

1. HTTPS（Hyprotext Tranfer Protocal Over Secure Socket Layer）基於安全套接字層的超文本傳輸協議。顧名思義，和HTTP相比多了SSL。
2. HTTPS並不是一個新的協議，而是在HTTP的基礎上，通訊結構上使用了SSL或者TLS（Transport Layer Socket）,HTTP直接與TCP進行通訊，而HTTPS使得HTTP與SSL通訊，而TCP與SSL通訊

　　　　

　（2）HTTPS與HTTP對比

1. HTTPS需要用到CA申請證書。
2. HTTP是超文本傳輸協議，信息是明文的；HTTPS則是具有安全性的SSL加密傳輸協議。
3. HTTPS和HTTP使用的是完全不同的連接方式，用的端口也不一樣，HTTP是80,HTTPS是443。
4. HTTP的連接很簡單，是無狀態的，HTTPS是HTTP+SSL協議構建的，可進行加密傳輸、身份認證的網絡協議，比HTTP協議安全。

　　(3)相對於HTTP而言，HTTPS的好處

1. 內容加密（不加密的話內容可能被竊取）
2. 身份驗證（不驗證對方身份的話，誰都可以請求你發送數據），雙方都可要求對方的證書，進行雙向認證，一般情況下只有單項認證
3. 數據完整（防止篡改）

 　（4）HTTPS的缺點

1. 因為要數據加解密、身份驗證，因此傳輸速度比HTTP慢一些。
2. 雖然理論上基於安全，瀏覽器不緩存HTTPS的數據，但是HTTP的頭部信息Cache-Control控制了緩存與否。FireFox默認緩存在內存。Cache-Control：Public使得瀏覽器緩存在磁盤。因此緩存策略與HTTPS協議無關。

　（5）加密與證書

• 加密算法

1. 對稱加密：AES、DES、RC4、IDEA
2. 非對稱加密：RSA（能使用到的場景：加密（DH／RSA），身份驗證（只有RSA），數字簽名：（只有RSA））

　　　　能不能又做加密算法又做身份驗證算法的判斷依據是：能不能公鑰加密，私鑰解密；同時可以私鑰加密，公鑰來解密。

 　　3.專門的密鑰交換算法： DH

• RSA算法原理:
  • 　　特點：需要提前生成對外的參數（公鑰）
主要就是根據兩個質數的乘積很難拆分確定具體兩個質數的值。算法有三個參數n、e1、e2，其中n為兩個大質數p、q的乘積，e1、e2是一對相關的值，為公鑰、私鑰，e1隨便取，但要求e1與（p-1）*（q-1）互質，又要求（e2*e1）mod（p-1)*(q-1）=1,   (n,e1)為公鑰，（n,e2）為私鑰，
• 設A為明文，B為密文，則A=B^e2 mod n; B=A^e1 mod n       【mod為求余符號】

　　當RSA作為加密操作時，公鑰作為加密，私鑰所謂解密(一般情況)

　　當RSA作為身份驗證時，私鑰作為加密，公鑰作為解密

• DH算法原理:
  • 　特點1：不需要提前生成對外的參數
  •    特點2：即使存在中間人攻擊，也就是全程被偷窺，也無法直到協商出來的秘鑰是什么。

　　　　主要是依賴於計算離散對數的難度

　　　　通信前兩邊A、B都約定好兩個大整數n、g，其中1<g<n,都公開

　　　　1.A隨機產生一個大整數a，計算Ka=g^a mod n【a需要保密】

　　　　2.B也隨機產生一個大整數b，計算Kb = g^b mod n【b需要保密】

　　　　3.A把Ka發送給B，B把Kb發送給A

　　　　4.由於公式，兩邊都能得到相同的K，作為秘鑰

• 數字摘要：就是使用Hash函數將需要加密的明文加密稱128位的密文，密文稱之為數字摘要或者數字指紋，明文與數字摘要一一對應。常見的摘要有MD5、SHA1、SHA256
  • 　　MAC算法（Hash Message Authentication Code）或稱為HMAC（Hash Hash Message Authentication Code）
    • 　　背景：結合了MD5和SHA的優勢，並加入了秘鑰的支持
    • • 場景步驟1，客戶端向服務器發起請求，服務器在session中放一個服務器生成的秘鑰，把session發給客戶端
      • 場景步驟2，客戶端提交表單，進行登陸驗證，提交的密碼為明文通過MAC算法得到數字摘要，然后通過秘鑰對數字摘要進行加密
      • 場景步驟3，服務器獲取到通過服務器數據庫的密碼明文，通過MAC算法得到數字摘要，然后通過私鑰對數字摘要進行加密得到A，將A與從客戶端發送過來的A‘進行比較，相同則成功
• 數字簽名：服務器向CA機構申請CA證書，除了公鑰，還要有數字簽名

　　　　作用：身份認證。就是在CA證書中的重要一內容，保證該CA證書是未被篡改的

　　　　1.服務端用RSA算法生成一對公鑰、私鑰

　　　　2.生成數字簽名：CA機構也是有兩個秘鑰的，一個CA公鑰，一個CA私鑰，數字簽名=服務器公鑰+CA私鑰加密（一定HASH算法（服務器公鑰））

　　　　3.發送：服務端將包含服務器公鑰和數字簽名的CA證書發送給客戶端

　　　　4.證書驗證過程：每個客戶端都會預裝着CA公鑰，客戶端使用CA公鑰對CA私鑰加密后的數據進行解密，然后與服務器公鑰HASH處理的數據進行對比。確定唯一性

• 　驗證之后的數據傳輸

　　　　明文->Hash算法->摘要->私鑰加密（明文+摘要）->密文

　　　　過程：發送者用發送者的私鑰對摘要進行加密然后發送給接收者，接收者收到后只能用發送者公開的公鑰才能解密得到摘要1，然后接受者通過對除了摘要以外的其他數據進行Hash算法簽名操作的到摘要2，通過摘要1和摘要2的對比，可以確保數據的完整性和安全性

 

　（6）數字證書

　　對於接收者，如何確定它所得到的公鑰就是從發送者那里發送的，怎么確保該公鑰沒有進行過篡改處理。這就需要認證中心確定數字證書。

　　數字證書的內容：

1. 證書頒發機構的名稱
2. 證書本身的數字簽名！
3. 證書持有者的公鑰
4. 證書簽名用到的Hash算法

　　(7)SSL、TLS

　　　　用途：運用非對稱加密來確定（如何確定視算法而定）用於認證之后對稱加密的密鑰

1. 　　SSL：socket secuet layer 利用數據加密方法，保證數據在網絡傳輸中不會被截取，當前版本為3.0，分為兩層
   1. 　　SSL記錄協議：建立在可靠的傳輸層協議上（TCP），為高層協議提供數據封裝、壓縮、加密方法
   2.       SSL握手協議：建立在SSL記錄協議之上，用於在真實數據傳輸之前，身份的驗證、協商加密算法和交換秘鑰等
2. 　　TLS：transport layer securiety，為SSL3.0的后續，同樣分為兩層TLS Record和TLS HandShake，同樣較低層的為TLS Record，建立在安全傳輸層協議（TCP）之上
3. SSL/TLS協議的作用：
   1. 　　認證用戶和服務器，保證數據發送到正確的客戶端和服務器
   2.       內容加密，防竊取
   3.       數據完整性，防篡改

 　（8）秘鑰協商算法：秘鑰交換算法 + 身份認證

　　　　TLS-RSA：使用RSA算法的私鑰、公鑰的這種關系，用於安全傳輸的構建

　　　　基本協商過程（協商出來的就是密鑰）：

1. 1. 　　1. 客戶端連上服務端
   2. 　　2. 服務端發送 CA 證書給客戶端
   3. 　　3. 客戶端驗證該證書的可靠性
   4. 　　4. 客戶端從 CA 證書中取出公鑰
   5. 　　5. 客戶端生成一個隨機密鑰 k，並用這個公鑰加密得到 k'
   6. 　　6. 客戶端把 k' 發送給服務端
   7. 　　7. 服務端收到 k' 后用自己的私鑰解密得到 k
   8. 　　8. 此時雙方都得到了密鑰 k，協商完成。

　　　　Https的密鑰協商過程（協商出來的要經過二次加工才是會話密鑰）：

　　　　　　實際上是協商出一個參數，叫做密鑰，用於ssl認證（就是當前密鑰協商的身份認證要求）之后的對稱加密的密鑰

　　　　　　就是服務端將自己的證書傳給客戶端，客戶端將證書進行驗證后，客戶端將秘鑰A通過服務端CA證書上的公鑰進行加密成ClientKeyExchange，然后傳輸給服務端，服務端通過自己的私鑰解秘得到A。A就是premaster secret，該值為客戶端指定。會話秘鑰是通過RandomA+RandomB+Premaster secret三個值再進行一次算法計算得到的。

　　　　

　　　　TLS-DH：只能做到秘鑰交換，不能做到身份認證，存在中間人攻擊（），因此必須和一些能做到身份認證的算法一起協同，例如和RSA一起，就是TLS|-DH-RSA，

　　　　　　出現的背景：由於RSA的安全性完全取決於第三個參數，盡管值很大很難破解，但是為了萬無一失，制造出了DH算法。　　

　　　　　　具體使用：客戶端：DHCalMethod（KeyA,共同算法參數（證書上的指數））=公鑰a，服務端DHCalMethodDH（keyB，公共算法參數（證書上的指數））=公鑰b，然后通過相互換公鑰a、b，兩邊就可以知道彼此的的keyA和keyB了。

　　　　TLS-DH-RSA: 使用過程中，keyA、keyB就是同一個； 公共的算法參數（即證書上的指數）就是permaster secret，會話秘鑰就是keyA／keyB,在傳輸的過程中，服務端用自己的秘鑰對進行穿出的字段進行加密，然后客戶端接收到后對服務端證書上的公鑰解密，保證安全認證，雙向認證的話就是兩端都有這樣的認證過程。

　　　　TLS-DHE: 具備前向安全性，在原有的DH算法的基礎上多一個serverkeyexchange的握手

　　　　TLS-ECDHE：具備前向安全性，在原有的ECDH算法的基礎上多一個serverkeyexchange的握手

　　　　

 

 

　　

　　

　（9）HTTPS五次握手

 

　　DH算法：

 

 

　　RSA算法：

　　　　

 

 

 

　　

　　針對銀行等私密性強的單位，要求私鑰存儲在自家服務器

　　CloudFlare提供服務（分公鑰私鑰一起提供，可以不提供私鑰（keyless SSL）），把網站放到它們的CDN上，能使用SSL加密鏈接。

 

　　握手為非對稱加密，握手后通信為對稱加密

　　具體：如圖

　　參考：http://blog.csdn.net/misslong/article/details/9698657

1. 客戶端首次發出請求
   1. 加密協議的版本號，比如TLS1.0
   2. 一個隨機數
   3. 支持的加密算法（我這里的對稱加密算法有DES,RC5,密鑰交換算法（因為非對稱加密算法速度慢，因此用在了秘鑰交換上）有RSA和DH，摘要算法有MD5和SHA）java封裝在CipherSuite類中
2. 服務器生成數據並發送
   1. 加密協議的版本，比如TLS1.0
   2. 一個隨機數
   3. 加密的算法（我們用DES－RSA－SHA這對組合好了）
   4. 服務器證書
3. 客戶端通過已有的CA證書驗證證書的可靠性，並發送經過證書的公鑰加密的第三個隨機數premaster secret（premaster secret在處理后將用作加密密鑰，加密初始化向量和hmac的密鑰）
4. 服務器通過證書的私鑰解密得到premaster secret（通過處理得到加密秘鑰、加密初始化向量和hmac的密鑰，這樣雙方就已經安全得協商出了一套加密辦法）
5. 服務器和客戶端通過三個隨機數得到會話秘鑰，進行對稱加密算法通訊
   1. 加密通訊步驟1，借助hmac的密鑰，對明文的消息做安全的摘要處理，然后和明文放到一起
   2. 加密通訊步驟2，借助加密秘鑰，加密初始化向量加密上面的消息

　　　　

　注意：

　　　　SSL協議在握手階段使用的是非對稱加密，在傳輸階段使用的是對稱加密,也就是在說在SSL上傳送數據是使用對稱加密加密的!因為非對稱加密的速度緩慢，耗費資源。其實當客戶端和服務器使用非對稱加密方式建立連接后，客戶端和主機已經決定好了在傳輸過程使用的對稱加密算法和關鍵的對稱加密密鑰，由於這個過程本身是安全可靠的，也即對稱加密密鑰是不可能被竊取盜用的，因此，保證了在傳輸過程中對數據進行對稱加密也是安全可靠的！如果有人竊聽通信，他可以知道雙方選擇的加密方法，以及三個隨機數中的兩個。整個通話的安全，只取決於第三個隨機數(pre master secret)能不能被破解。

　　

 

五.SPDY

　　2012年google如一聲驚雷提出了SPDY的方案，大家猜開始從正面看待和解決老版本HTTP協議本身的問題，SPDY可以說是綜合了HTTPS和HTTP兩者有點於一體的傳輸協議，

　　主要解決

• 1、降低延遲:：針對HTTP高延遲的問題，SPDY優雅的采取了多路復用(multiplexing)。多路復用通過多個請求stream共享一個TCP連接的方式，解決了HOL blocking的問題，降低了延遲同事提高了帶寬的利用率。
• 2、請求優先級：多路復用帶來的一個新的問題是，在連接共享的基礎上有可能會導致關鍵請求被阻塞。SPDY允許給每個request設置優先級，這樣重要的請求就會優先得到相應。比如瀏覽器加載首頁，首頁的html內容應該優先展示，之后才是各種靜態資源文件，腳本文件等加載，這樣保證用戶第一時間看到網頁的內容。
• 3、header壓縮：HTTP1.x的header很多時候都是重復多余的。選擇和是的壓縮算法可以減少包的大小和數量。
• 4、基於HTTPS的加密協議傳輸，大大提高了傳輸數據的可靠性。
• 5、服務端推送(server push)，采用SPDY的網頁，例如一個網頁有一個style.css請求，客戶端在收到style.css數據的同事，服務端會將style.js文件推送給客戶端，當客戶端再次嘗試獲取style.js時就可以直接從緩存中獲取到，不用再次發送請求了。

　　SPDY構成圖：

　　

 

六.HTTP2.0

 

• 前世今生：

　　在HTTP/1.x中，如果客戶端想發起多個並行請求必須建立多個TCP連接，這無疑增大了網絡開銷。

　　另外HTTP/1.x不會壓縮請求和響應頭，導致了不必要的網絡流量，HTTP/1.x不支持資源優先級導致底層TCP連接利用率低下。

　　HTTP2.0可以說是SPDY的升級版(其實也是基於SPDY設計的)，但是HTTP2.0跟SPDY仍有不同的地方，

 

• 最大的特色：幀傳輸

　　HTTP2.0把HTTP協議通信的基本單位縮小為一個一個的幀，這些幀對應着邏輯流中的消息。相應地，很多流可以並行地在同一個TCP連接上交換消息。

　　在HTTP/1.1中，如果客戶端想發送多個平行的請求以及改進性能，必須使用多個TCP連接。

　　HTTP2.0的二進制分幀層突破了限制；客戶端和服務器可以把HTTP消息分解為互不依賴的幀，然后亂序發送，最后再把另一端把它們重新組合起來

　　　

 

 

　

 

• HTTP1.1與HTTP2.0的區別

　　

 

 

七.隧道

　　定義

　　Web tunnel（Web 隧道）是http的另一種用法，使用Http應用程序訪問非Http協議的應用程序。Web隧道允許用戶允許用戶通過HTTP連接發送非HTTP流量，這樣就可以在HTTP上捎帶其他協議數據了。使用Web隧道最常見的原因就是要在HTTP連接中嵌入非HTTP流量。這樣這類流量就可以穿過只允許Web流量通過的防火牆了