Http請求過程分解

時間  2019-11-19
標籤 http 請求 過程 分解 欄目 HTTP/TCP 简体版
原文   原文鏈接

 

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

 

溫習下如下知識點：html

一、TCP 
二、TCP的3次握手和4次揮手 
三、HTTP 
四、HTTPS 
五、SPDY
六、HTTP2.0
七、隧道
八、代理
九、InetAddress和InetSocketAddress

 

一.TCP

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

　　

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

　　而後看下七層每層所表明的意義：數據庫

　　

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

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

　　　　　　不提供可靠性保證。安全

　　傳輸層：爲兩臺主機上的應用提供端對端的傳輸。服務器

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

　　　　　　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、RC四、IDEA
  2. 非對稱加密：DH、RSA（能使用到的場景：加密（DH／RSA），身份驗證（只有RSA））

 

  • RSA算法:
    • 主要就是根據兩個質數的乘積很難拆分肯定具體兩個質數的值。算法有三個參數n、e一、e2，其中n爲兩個大質數p、q的乘積，e一、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算法:

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

　　　　通訊前兩邊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位的密文，密文稱之爲數字摘要或者數字指紋，明文與數字摘要一一對應。常見的摘要有MD五、SHA一、SHA256
    • 　　MAC算法（Hash Message Authentication Code）或稱爲HMAC（Hash Hash Message Authentication Code）
      • 　　背景：結合了MD5和SHA的優點，並加入了祕鑰的支持
        • 場景步驟1，客戶端向服務器發起請求，服務器在session中放一個服務器生成的祕鑰，把session發給客戶端
        • 場景步驟2，客戶端提交表單，進行登錄驗證，提交的密碼爲明文經過MAC算法獲得數字摘要，而後經過祕鑰對數字摘要進行加密
        • 場景步驟3，服務器獲取到經過服務器數據庫的密碼明文，經過MAC算法獲得數字摘要，而後經過私鑰對數字摘要進行加密獲得A，將A與從客戶端發送過來的A‘進行比較，相同則成功
  • 數字簽名：（非對稱加密+數字摘要）的應用

　　　　明文->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：就是服務端將本身的證書傳給客戶端，客戶端將證書進行驗證後，客戶端將祕鑰A經過服務端CA證書上的公鑰進行加密成ClientKeyExchange，而後傳輸給服務端，服務端經過本身的私鑰解祕獲得A。A就是premaster secret，該值爲客戶端指定。會話祕鑰是經過RandomA+RandomB+Premaster secret三個值再進行一次算法計算獲得的。

　　　　TLS-DH：只能作到祕鑰交換，不能作到身份認證，所以必須和一些能作到身份認證的算法一塊兒協同，例如和RSA一塊兒，就是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二者有點於一體的傳輸協議，

　　主要解決

  • 一、下降延遲:：針對HTTP高延遲的問題，SPDY優雅的採起了多路複用(multiplexing)。多路複用經過多個請求stream共享一個TCP鏈接的方式，解決了HOL blocking的問題，下降了延遲同事提升了帶寬的利用率。
  • 二、請求優先級：多路複用帶來的一個新的問題是，在鏈接共享的基礎上有可能會致使關鍵請求被阻塞。SPDY容許給每一個request設置優先級，這樣重要的請求就會優先獲得相應。好比瀏覽器加載首頁，首頁的html內容應該優先展現，以後纔是各類靜態資源文件，腳本文件等加載，這樣保證用戶第一時間看到網頁的內容。
  • 三、header壓縮：HTTP1.x的header不少時候都是重複多餘的。選擇和是的壓縮算法能夠減小包的大小和數量。
  • 四、基於HTTPS的加密協議傳輸，大大提升了傳輸數據的可靠性。
  • 五、服務端推送(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流量經過的防火牆了

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程