前言

不得不說(shuō)現(xiàn)在無(wú)論在前端和后端領(lǐng)域的技術(shù)迭代十分迅速嘱么，比如前段時(shí)間SpringBoot2.0的更新采用了Http2.0技術(shù)狮含；這些基礎(chǔ)協(xié)議的更新往往帶來(lái)了實(shí)質(zhì)的更新。一些名詞:"HTTP 管線化"拱撵、"會(huì)話跟蹤"辉川、"跨站攻擊"等等，那些你耳熟能詳拴测，但是無(wú)法細(xì)究的東西決定了這個(gè)總結(jié)誕生搔预，或許文章會(huì)很長(zhǎng)沉噩，但是也請(qǐng)靜下心來(lái)閱讀鸠儿，而這個(gè)文章自己打算一段時(shí)間來(lái)持續(xù)更新。

基礎(chǔ)知識(shí)

HTTP介紹

基礎(chǔ)概念

HTTP協(xié)議（HyperText Transfer Protocol携茂，超文本傳輸協(xié)議）是用于從WWW服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。
它的發(fā)展是萬(wàn)維網(wǎng)協(xié)會(huì)（World Wide Web Consortium）和Internet工作小組IETF（Internet Engineering Task Force）合作的結(jié)果虑乖。
它可以使瀏覽器更加高效校坑，使網(wǎng)絡(luò)傳輸減少。它不僅保證計(jì)算機(jī)正確快速地傳輸超文本文檔函匕，還確定傳輸文檔中的哪一部分娱据，以及哪部分內(nèi)容首先顯示(如文本先于圖形)等。

版本

最常用的是HTTP1.0/1.1
最新版本是HTTP2.0盅惜，與1.0/1.1相比中剩，有了更高的性能、安全性和靈活性
以前的版本0.9等

HTTP協(xié)議

URL與資源

在TCP/IP模型中抒寂，所有的網(wǎng)絡(luò)連接都要使用方案结啼，方案定義使用什么協(xié)議，比如http屈芜、ftp郊愧、telnet

一個(gè)標(biāo)準(zhǔn)的網(wǎng)絡(luò)請(qǐng)求包括:

<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>

但在實(shí)際使用過(guò)程中，對(duì)于不同協(xié)議可以缺少某些信息井佑，比如

ftp://192.168.169.121
http://www.baidu.com/index.html

URI属铁、URL和URN

URI:統(tǒng)一資源標(biāo)識(shí)符，包括URL和URN
URL:統(tǒng)一資源標(biāo)識(shí)符躬翁，比如http://www.baidu.com/index.html就是一個(gè)URL
URN:統(tǒng)一資源名焦蘑，它是無(wú)關(guān)物理位置的資源名定義，例子urn:ieft:rfc:2141

目前URN處于試驗(yàn)階段姆另，實(shí)際應(yīng)用還很困難喇肋，在沒(méi)有特別說(shuō)明時(shí)，一般我們說(shuō)的URI就代表URL

媒體類型

在HTTP中迹辐，不管是word文件蝶防、js文件或者圖片都是資源，通可以通過(guò)URL進(jìn)行請(qǐng)求明吩，但每種不同的文件都要進(jìn)行區(qū)分间学，以便服務(wù)端和客戶端進(jìn)行正確處理，比如播放聲音印荔、顯示文字低葫。

因此，HTTP仔細(xì)地給每種要通過(guò)http請(qǐng)求響應(yīng)傳輸?shù)膶?duì)象都打上名為MIME類型的數(shù)據(jù)格式標(biāo)簽仍律。

MIME: Multipurpose Internet Mail Extension 多用途因特網(wǎng)郵件擴(kuò)展

最開(kāi)始是為了解決電子郵件系統(tǒng)之間的問(wèn)題嘿悬，后來(lái)用于定義更多類型的多謀體內(nèi)容。常見(jiàn)的MIME：

html：text/html
Ascii: text/plain
Json:text/json
Jpg:image/jpeg
Gif:image/gif
Ppt: application/vnd.ms-powerpoint
Quicktime:video/quicktime

協(xié)議介紹

協(xié)議棧

HTTP在TCP/IP協(xié)議棧中的位置

image

HTTP是基于TCP/IP的應(yīng)用水泉，因此HTTP無(wú)須關(guān)心網(wǎng)絡(luò)尋址善涨、數(shù)據(jù)傳輸和拓?fù)浣Y(jié)構(gòu)

協(xié)議工作流程

協(xié)議圖

在HTTP1.0/1.1中窒盐，HTTP采用請(qǐng)求響應(yīng)模型來(lái)處理HTTP事務(wù) HTTP事務(wù)有一條請(qǐng)求命令和一個(gè)響應(yīng)結(jié)果組成，它們通過(guò)HTTP報(bào)文進(jìn)行數(shù)據(jù)傳輸

注意：請(qǐng)求是從客戶端發(fā)往服務(wù)端钢拧，而響應(yīng)是從服務(wù)端發(fā)回客戶端

HTTP的工作過(guò)程

HTTP的工作過(guò)程

• （1）客戶端連接到Web服務(wù)器
• （2）發(fā)送HTTP請(qǐng)求
• （3）服務(wù)器接受請(qǐng)求并返回HTTP響應(yīng)
• （4）釋放連接TCP連接
• （5）客戶端瀏覽器解析HTML內(nèi)容

HTTP報(bào)文

報(bào)文

HTTP1.0/1.1報(bào)文由三部分組成：起始行蟹漓、首部以及可選、包含數(shù)據(jù)的主體

image

其中起始行和首部是由行分隔的ASCII文本

主體是一個(gè)可選的數(shù)據(jù)塊源内，主體中可以包含文本也可以包含二進(jìn)制數(shù)據(jù)葡粒，也可以為空，與首部通過(guò)空一行進(jìn)行區(qū)分

請(qǐng)求報(bào)文的格式：

<method> <request-url> <version>
<headers>

<entity-body>

響應(yīng)報(bào)文的格式：

<version> <status> <reason-phrase>
<headers>

<entity-body>

具體例子：

瀏覽器報(bào)文

注：部分文章也將HTTP請(qǐng)求報(bào)文分為兩部分請(qǐng)求頭和請(qǐng)求體膜钓，請(qǐng)求頭的第一行為請(qǐng)求行嗽交。

首部字段

HTTP首部字段向請(qǐng)求和響應(yīng)報(bào)文中添加了一些附加信息，是一系列 key-value的列表,比如Content-Type:image/jpeg 表示類型是jpeg圖片

首部的分類包括

通用首部：在請(qǐng)求和響應(yīng)中都出現(xiàn)的信息
請(qǐng)求首部：只在請(qǐng)求報(bào)文中出現(xiàn)的信息
響應(yīng)首部：只在響應(yīng)報(bào)文中出現(xiàn)的信息

實(shí)體首部：描述主題的長(zhǎng)度呻此、內(nèi)容等的信息
擴(kuò)展首部：在HTTP規(guī)范中沒(méi)有定義的其他信息

實(shí)體

HTTP實(shí)體是HTTP報(bào)文的負(fù)荷轮纫，是HTTP要傳輸?shù)臄?shù)據(jù)內(nèi)容。

方法

HTTP基本的方法包括：GET/POST/HEAD/PUT/TRACE/OPTIONS焚鲜，用來(lái)告訴服務(wù)端要做什么操作

GET

GET是最常用的方法掌唾，通常用于請(qǐng)求服務(wù)器發(fā)送某個(gè)資源

GET

POST

POST是常用的方法之一，用于向服務(wù)端提交數(shù)據(jù)忿磅，有主體

POST

HEAD

與GET類似糯彬，但在響應(yīng)中只有首部，不返回具體數(shù)據(jù)葱她，可以用來(lái)查看資源是否存在

PUT/TRACE/OPTIONS/DELETE

PUT:用于向服務(wù)端寫(xiě)入文檔
TRACE:用于跟蹤某個(gè)請(qǐng)求
OPTIONS:用于查詢服務(wù)端支持的方法
DELETE:用于刪除服務(wù)端某個(gè)資源

其他擴(kuò)展方法

HTTP在設(shè)計(jì)之初就被設(shè)計(jì)成可擴(kuò)展的撩扒，這樣就可以適應(yīng)新的特性。
擴(kuò)展方法是在HTTP規(guī)范中沒(méi)有定義的方法吨些，它們有特別的用處搓谆，但需要服務(wù)端進(jìn)行實(shí)現(xiàn)：
LOCK：鎖定某個(gè)資源
COPY：拷貝某個(gè)資源
MOVE：移動(dòng)某個(gè)資源

狀態(tài)碼

狀態(tài)碼是響應(yīng)報(bào)文中對(duì)請(qǐng)求所做事情的處理結(jié)果，以方便客戶端處理響應(yīng)數(shù)據(jù)

狀態(tài)碼分為五大類：

信息性狀態(tài)碼：100~199
成功狀態(tài)碼：200~299
重定向狀態(tài)碼：300~399
客戶端錯(cuò)誤狀態(tài)碼：400~499

服務(wù)端錯(cuò)誤狀態(tài)碼：500~599

常見(jiàn)的狀態(tài)碼有如下幾種

 - 200 OK 客戶端請(qǐng)求成功   
 - 301 Moved Permanently 請(qǐng)求永久重定向    
 - 302 Moved Temporarily 請(qǐng)求臨時(shí)重定向    
 - 304 Not Modified 文件未修改豪墅，可以直接使用緩存的文件泉手。  
 - 400 Bad Request 由于客戶端請(qǐng)求有語(yǔ)法錯(cuò)誤，不能被服務(wù)器所理解偶器。  
 - 401 Unauthorized 請(qǐng)求未經(jīng)授權(quán)斩萌。這個(gè)狀態(tài)代碼必須和WWW-Authenticate報(bào)頭域一起使用 
 - 403 Forbidden 服務(wù)器收到請(qǐng)求，但是拒絕提供服務(wù)屏轰。服務(wù)器通常會(huì)在響應(yīng)正文中給出不提供服務(wù)的原因    
 - 404 Not Found 請(qǐng)求的資源不存在颊郎，例如，輸入了錯(cuò)誤的URL  
 - 500 Internal Server Error 服務(wù)器發(fā)生不可預(yù)期的錯(cuò)誤霎苗，導(dǎo)致無(wú)法完成客戶端的請(qǐng)求姆吭。 
 - 503 Service Unavailable 服務(wù)器當(dāng)前不能夠處理客戶端的請(qǐng)求，在一段時(shí)間之后唁盏，服務(wù)器可能會(huì)恢復(fù)正常猾编。 

Https的基礎(chǔ)知識(shí)

超文本傳輸安全協(xié)議（英語(yǔ)：Hypertext Transfer Protocol Secure瘤睹，縮寫(xiě)：HTTPS升敲，常稱為HTTP over TLS答倡，HTTP over SSL或HTTP Secure）是一種通過(guò)計(jì)算機(jī)網(wǎng)絡(luò)進(jìn)行安全通信的傳輸協(xié)議。HTTPS經(jīng)由HTTP進(jìn)行通信驴党，但利用SSL/TLS來(lái)加密數(shù)據(jù)包瘪撇。

Http與Https

SSL（Secure Socket Layer，安全套接字層）：1994年為 Netscape 所研發(fā)港庄，SSL 協(xié)議位于 TCP/IP 協(xié)議與各種應(yīng)用層協(xié)議之間倔既，為數(shù)據(jù)通訊提供安全支持。

TLS（Transport Layer Security鹏氧，傳輸層安全）：其前身是 SSL渤涌，它最初的幾個(gè)版本（SSL 1.0、SSL 2.0把还、SSL 3.0）由網(wǎng)景公司開(kāi)發(fā)实蓬，1999年從 3.1 開(kāi)始被 IETF 標(biāo)準(zhǔn)化并改名，發(fā)展至今已經(jīng)有 TLS 1.0吊履、TLS 1.1安皱、TLS 1.2 三個(gè)版本。SSL3.0和TLS1.0由于存在安全漏洞艇炎，已經(jīng)很少被使用到酌伊。TLS 1.3 改動(dòng)會(huì)比較大，目前還在草案階段缀踪，目前使用最廣泛的是TLS 1.1居砖、TLS 1.2。

Https

HTTP 傳輸面臨的巨大的安全問(wèn)題如下：

1. 隱私泄露
2. 頁(yè)面劫持
3. 劫持路徑及分類

HTTP 向 HTTPS 演化的過(guò)程

第一步：為了防止上述現(xiàn)象的發(fā)生驴娃，人們想到一個(gè)辦法：對(duì)傳輸?shù)男畔⒓用埽词购诳徒孬@奏候，也無(wú)法破解）

image

1. 不同的客戶端厚棵、服務(wù)器數(shù)量龐大蕉世，所以雙方都需要維護(hù)大量的密鑰，維護(hù)成本很高
2. 因每個(gè)客戶端婆硬、服務(wù)器的安全級(jí)別不同狠轻，密鑰極易泄露
   第二步：既然使用對(duì)稱加密時(shí)，密鑰維護(hù)這么繁瑣彬犯，那我們就用非對(duì)稱加密試試

image

如上圖所示向楼，客戶端用公鑰對(duì)請(qǐng)求內(nèi)容加密查吊，服務(wù)器使用私鑰對(duì)內(nèi)容解密，反之亦然湖蜕，但上述過(guò)程也存在缺點(diǎn)：

1. 公鑰是公開(kāi)的（也就是黑客也會(huì)有公鑰）逻卖，所以第 ④ 步私鑰加密的信息，如果被黑客截獲昭抒，其可以使用公鑰進(jìn)行解密评也，獲取其中的內(nèi)容
   第三步：非對(duì)稱加密既然也有缺陷，那我們就將對(duì)稱加密灭返，非對(duì)稱加密兩者結(jié)合起來(lái)盗迟，取其精華、去其糟粕熙含，發(fā)揮兩者的各自的優(yōu)勢(shì)
   
   image
   
   如上圖所示
2. 第 ③ 步時(shí)罚缕，客戶端說(shuō)：（咱們后續(xù)回話采用對(duì)稱加密吧，這是對(duì)稱加密的算法和對(duì)稱密鑰）這段話用公鑰進(jìn)行加密怎静，然后傳給服務(wù)器
3. 服務(wù)器收到信息后邮弹，用私鑰解密，提取出對(duì)稱加密算法和對(duì)稱密鑰后消约，服務(wù)器說(shuō)：（好的）對(duì)稱密鑰加密
4. 后續(xù)兩者之間信息的傳輸就可以使用對(duì)稱加密的方式了

遇到的問(wèn)題：

1. 客戶端如何獲得公鑰
   如何確認(rèn)服務(wù)器是真實(shí)的而不是黑客

第四步：獲取公鑰與確認(rèn)服務(wù)器身份

image

1. 獲取公鑰
   提供一個(gè)下載公鑰的地址肠鲫，回話前讓客戶端去下載。（缺點(diǎn)：下載地址有可能是假的或粮；客戶端每次在回話前都先去下載公鑰也很麻煩）
   回話開(kāi)始時(shí)导饲，服務(wù)器把公鑰發(fā)給客戶端（缺點(diǎn)：黑客冒充服務(wù)器，發(fā)送給客戶端假的公鑰）

2. 那有木有一種方式既可以安全的獲取公鑰氯材，又能防止黑客冒充呢渣锦？ 那就需要用到終極武器了：SSL 證書(shū)（申購(gòu))
   

   image
   
   如上圖所示，在第 ② 步時(shí)服務(wù)器發(fā)送了一個(gè)SSL證書(shū)給客戶端氢哮，SSL 證書(shū)中包含的具體內(nèi)容有：

   證書(shū)的發(fā)布機(jī)構(gòu)CA
   證書(shū)的有效期
   公鑰
   證書(shū)所有者
   簽名
   ………

3. 客戶端在接受到服務(wù)端發(fā)來(lái)的SSL證書(shū)時(shí)袋毙，會(huì)對(duì)證書(shū)的真?zhèn)芜M(jìn)行校驗(yàn)，以瀏覽器為例說(shuō)明如下：

   1. 首先瀏覽器讀取證書(shū)中的證書(shū)所有者冗尤、有效期等信息進(jìn)行一一校驗(yàn)
   2. 瀏覽器開(kāi)始查找操作系統(tǒng)中已內(nèi)置的受信任的證書(shū)發(fā)布機(jī)構(gòu)CA听盖，與服務(wù)器發(fā)來(lái)的證書(shū)中的頒發(fā)者CA比對(duì)，用于校驗(yàn)證書(shū)是否為合法機(jī)構(gòu)頒發(fā)
   3. 如果找不到裂七，瀏覽器就會(huì)報(bào)錯(cuò)皆看，說(shuō)明服務(wù)器發(fā)來(lái)的證書(shū)是不可信任的。
   4. 如果找到背零，那么瀏覽器就會(huì)從操作系統(tǒng)中取出 頒發(fā)者CA 的公鑰腰吟，然后對(duì)服務(wù)器發(fā)來(lái)的證書(shū)里面的簽名進(jìn)行解密
   5. 瀏覽器使用相同的hash算法計(jì)算出服務(wù)器發(fā)來(lái)的證書(shū)的hash值，將這個(gè)計(jì)算的hash值與證書(shū)中簽名做對(duì)比
   6. 對(duì)比結(jié)果一致徙瓶，則證明服務(wù)器發(fā)來(lái)的證書(shū)合法毛雇，沒(méi)有被冒充
   7. 此時(shí)瀏覽器就可以讀取證書(shū)中的公鑰嫉称，用于后續(xù)加密了

4. 所以通過(guò)發(fā)送SSL證書(shū)的形式，既解決了公鑰獲取問(wèn)題灵疮，又解決了黑客冒充問(wèn)題织阅，一箭雙雕，HTTPS加密過(guò)程也就此形成

Htttp2.0

HTTP/2 （原名HTTP/2.0）即超文本傳輸協(xié)議 2.0始藕，是下一代HTTP協(xié)議蒲稳。是由互聯(lián)網(wǎng)工程任務(wù)組（IETF）的Hypertext Transfer Protocol Bis (httpbis)工作小組進(jìn)行開(kāi)發(fā)。是自1999年http1.1發(fā)布后的首個(gè)更新伍派。HTTP 2.0在2013年8月進(jìn)行首次合作共事性測(cè)試。在開(kāi)放互聯(lián)網(wǎng)上HTTP 2.0將只用于 https:// 網(wǎng)址剩胁，而 http:// 網(wǎng)址將繼續(xù)使用HTTP/1诉植，目的是在開(kāi)放互聯(lián)網(wǎng)上增加使用加密技術(shù)，以提供強(qiáng)有力的保護(hù)去遏制主動(dòng)攻擊昵观。DANE RFC6698允許域名管理員不通過(guò)第三方CA自行發(fā)行證書(shū)晾腔。

Http2.0的優(yōu)勢(shì)；

• 提升web的性能啊犬，在與 HTTP/1.1 完全語(yǔ)義兼容的基礎(chǔ)上灼擂，進(jìn)一步減少了網(wǎng)絡(luò)延遲
  

  web性能對(duì)比
  
  HTTP/2: the Future of the Internet 這是 Akamai 公司建立的一個(gè)官方的演示，用以說(shuō)明 HTTP/2 相比于之前的 HTTP/1.1 在性能上的大幅度提升觉至。 同時(shí)請(qǐng)求 379 張圖片剔应，從Load time 的對(duì)比可以看出 HTTP/2 在速度上的優(yōu)勢(shì)。
  
  延時(shí)問(wèn)題
  
  使用chrome的開(kāi)發(fā)工具的操作時(shí)语御，可以明顯發(fā)現(xiàn)Http1.0的延時(shí)問(wèn)題比較峻贮。

• 多路復(fù)用 (Multiplexing)

  多路復(fù)用允許同時(shí)通過(guò)單一的 HTTP/2 連接發(fā)起多重的請(qǐng)求-響應(yīng)消息。

  眾所周知 应闯，在 HTTP/1.1 協(xié)議中 「瀏覽器客戶端在同一時(shí)間纤控，針對(duì)同一域名下的請(qǐng)求有一定數(shù)量限制。超過(guò)限制數(shù)目的請(qǐng)求會(huì)被阻塞」碉纺。
  

  image
  
  HTTP/2 的多路復(fù)用(Multiplexing) 則允許同時(shí)通過(guò)單一的 HTTP/2 連接發(fā)起多重的請(qǐng)求-響應(yīng);因此 HTTP/2 可以很容易的去實(shí)現(xiàn)多流并行而不用依賴建立多個(gè) TCP 連接船万，HTTP/2 把 HTTP 協(xié)議通信的基本單位縮小為一個(gè)一個(gè)的幀，這些幀對(duì)應(yīng)著邏輯流中的消息骨田。并行地在同一個(gè) TCP 連接上;往往有效的解決了統(tǒng)一域名請(qǐng)求限制阻塞問(wèn)題耿导。

• **二進(jìn)制分幀 **
  在二進(jìn)制分幀層中， HTTP/2 會(huì)將所有傳輸?shù)男畔⒎指顬楦〉南⒑蛶╢rame）,并對(duì)它們采用二進(jìn)制格式的編碼 盛撑，其中 HTTP1.x 的首部信息會(huì)被封裝到 HEADER frame碎节，而相應(yīng)的 Request Body 則封裝到 DATA frame 里面。
  ++HTTP/2 通信都在一個(gè)連接上完成抵卫，這個(gè)連接可以承載任意數(shù)量的雙向數(shù)據(jù)流++狮荔。
  在過(guò)去胎撇， HTTP 性能優(yōu)化的關(guān)鍵并不在于高帶寬，而是低延遲殖氏。TCP 連接會(huì)隨著時(shí)間進(jìn)行自我「調(diào)諧」晚树，起初會(huì)限制連接的最大速度，如果數(shù)據(jù)成功傳輸雅采，會(huì)隨著時(shí)間的推移提高傳輸?shù)乃俣染粼鳌＿@種調(diào)諧則被稱為 TCP 慢啟動(dòng)。由于這種原因婚瓜，讓原本就具有突發(fā)性和短時(shí)性的 HTTP 連接變的十分低效宝鼓。
  

  image
  
  總結(jié)：
  • 單連接多資源的方式，減少服務(wù)端的鏈接壓力,內(nèi)存占用更少,連接吞吐量更大
  • 由于 TCP 連接的減少而使網(wǎng)絡(luò)擁塞狀況得以改善巴刻，同時(shí)慢啟動(dòng)時(shí)間的減少,使擁塞和丟包恢復(fù)速度更快

• 首部壓縮（Header Compression）
  HTTP/1.1并不支持 HTTP 首部壓縮愚铡，為此 SPDY 和 HTTP/2 應(yīng)運(yùn)而生， SPDY 使用的是通用的DEFLATE 算法胡陪，而 HTTP/2 則使用了專門(mén)為首部壓縮而設(shè)計(jì)的 HPACK 算法沥寥。
  

  image

• 服務(wù)端推送
  服務(wù)端推送是一種在客戶端請(qǐng)求之前發(fā)送數(shù)據(jù)的機(jī)制。在 HTTP/2 中柠座，服務(wù)器可以對(duì)客戶端的一個(gè)請(qǐng)求發(fā)送多個(gè)響應(yīng)邑雅。Server Push 讓 HTTP1.x 時(shí)代使用內(nèi)嵌資源的優(yōu)化手段變得沒(méi)有意義；如果一個(gè)請(qǐng)求是由你的主頁(yè)發(fā)起的妈经，服務(wù)器很可能會(huì)響應(yīng)主頁(yè)內(nèi)容淮野、logo 以及樣式表，因?yàn)樗揽蛻舳藭?huì)用到這些東西狂塘。這相當(dāng)于在一個(gè) HTML 文檔內(nèi)集合了所有的資源录煤，不過(guò)與之相比，服務(wù)器推送還有一個(gè)很大的優(yōu)勢(shì)：可以緩存荞胡！也讓在遵循同源的情況下妈踊，不同頁(yè)面之間可以共享緩存資源成為可能。
  

  image

HTTPS泪漂、SPDY和HTTP/2的性能比較

• 請(qǐng)參見(jiàn)博文《HTTPS廊营、SPDY和HTTP/2的性能比較》

文章到此，基本介紹個(gè)人同樣推薦文章《HTTP,HTTP2.0,SPDY,HTTPS看這篇就夠了》萝勤；并非推薦但是感覺(jué)總結(jié)也不錯(cuò)露筒。個(gè)人的文章感覺(jué)搬磚感覺(jué)更多（加油！）

參考內(nèi)容：

• 圖解http敌卓，http基礎(chǔ)知識(shí)
• HTTP學(xué)習(xí)一：HTTP基礎(chǔ)知識(shí)
• HTTP的特性(筆試)
• HTTPS系列干貨（一）：HTTPS 原理詳解 知乎
• 超文本傳輸安全協(xié)議 wiki
• HTTP,HTTP2.0,SPDY,HTTPS看這篇就夠了 博文
• HTTP/2.0 相比1.0有哪些重大改進(jìn)慎式？ 知乎
• HTTPS、SPDY和HTTP/2的性能比較 文摘