我真的是在瞎逼逼，因?yàn)楣馐?HTTP，就足夠講一塊磚頭了。而且，HTTP 只是協(xié)議棧的應(yīng)用層的其中一個(gè)協(xié)議：），不過其他協(xié)議都不在本文討論范圍之內(nèi)。如有疏漏，請(qǐng)指正。

概述：HTTP vs HTTPS vs HTTP/2 vs SSL vs TLS：這些都是啥子跟啥子？

很多縮寫詞被用于描述客戶端與服務(wù)器端交流的過程。這些詞經(jīng)常被不熟悉內(nèi)部原理的人混淆。

HTTP (Hypertext Transfer Protocol) 是客戶端和服務(wù)器端都必須實(shí)現(xiàn)的基本交流協(xié)議。它涉及到請(qǐng)求 (requests)，響應(yīng) (responses)，會(huì)話 (sessions)，緩存 (caching)，認(rèn)證 (* authentication) 以及更多。在這個(gè)協(xié)議以及 HTML (Hypertext Markup Language*) 上的工作，開始于 1989 年，由在 CERN 的 Sir Tim Berners-Lee 和他的團(tuán)隊(duì)主持。這個(gè)協(xié)議的第一個(gè)官方版本 (HTTP 1.0) 發(fā)布于 1996 年，隨后在 1997 年發(fā)布了現(xiàn)在廣泛使用的版本 (HTTP 1.1)。

這個(gè)協(xié)議在瀏覽器和服務(wù)器間傳輸明文 (clear) 信息，允許通過傳輸信息的網(wǎng)絡(luò)查看傳輸?shù)男畔ⅰ＿@會(huì)產(chǎn)生安全的擔(dān)憂，所以 HTTP Secure (HTTPS) 被引入了。HTTPS 允許客戶端和服務(wù)器端先建立一個(gè)加密的通道，然后通過這個(gè)通道傳輸明文信息，有效地防止了信息的竊聽。

加密通道是通過 Transport Layer Security (TLS) 協(xié)議創(chuàng)建的，這個(gè)協(xié)議以前叫 Secure Socket Layer (SSL)。這兩個(gè)術(shù)語(yǔ)經(jīng)常互換著使用。SSL 3.0 正在被 TLS 1.0 替代。SSL 是 Netscape 開發(fā)的協(xié)議，而 TLS 是一個(gè) IETF 標(biāo)準(zhǔn)。在寫這篇文章的時(shí)候，所有版本的 SSL (1.0, 2.0, 3.0) 都由于許多的安全問題而被廢棄，使用它們將會(huì)在現(xiàn)代瀏覽器中產(chǎn)生警告，TLS 版本 (1.0, 1.1, 1.2) 正在使用中，1.3 版本現(xiàn)在還是草案。

所以，在大約 1996 或 1997 的某個(gè)時(shí)間，我們有了互聯(lián)網(wǎng)的當(dāng)前穩(wěn)定版本 (有或者沒有 SSL/TLS 的 HTTP 1.1)，這個(gè) HTTP 版本仍然驅(qū)動(dòng)著現(xiàn)在絕大多數(shù)網(wǎng)站。以前，HTTP 用于非敏感通信，比如閱讀新聞，而 HTTPS 用于敏感通信，比如認(rèn)證和電子商務(wù)。然而，對(duì)隱私權(quán)的關(guān)注不斷增加，一些瀏覽器如 Google Chrome 現(xiàn)在會(huì)標(biāo)記 HTTP 網(wǎng)站 為 “not private”，將在未來針對(duì) HTTP 引入警告。

HTTP 協(xié)議的下一代升級(jí)版 —— HTTP/2，于 2015 年發(fā)布，正在被越來越多的網(wǎng)站所采納。這個(gè)協(xié)議增加了新的特色，如 壓縮 (compression)，多路復(fù)用 (multiplexing)，請(qǐng)求優(yōu)先級(jí) (prioritization of requests)等，用于減少等待時(shí)間、提升性能和安全性。

在 HTTP 1.1 版本，安全連接是可選的，你可以使用 HTTP 或 HTTPS，但在 HTTP/2，安全連接幾乎是強(qiáng)制的，即使標(biāo)準(zhǔn)定義了有 TLS 的 HTTP/2 和沒有 TLS 的 HTTP/2，但大部分瀏覽器提供商已經(jīng)聲明它們將只支持擁有 TLS 的 HTTP/2。

HTTP

HTTP 的基本性質(zhì)

簡(jiǎn)單

HTTP 的消息被設(shè)計(jì)為簡(jiǎn)單可讀。這一點(diǎn)只要你打開瀏覽器控制臺(tái)看看請(qǐng)求和響應(yīng)頭就知道了。

可擴(kuò)展

除了規(guī)范規(guī)定的那些 header，我們會(huì)看到很多非官方規(guī)定的 header，這些擴(kuò)展的 header 可以用來實(shí)現(xiàn)新的功能。

無狀態(tài)

這意味著即使你對(duì)服務(wù)器發(fā)起過一次請(qǐng)求，當(dāng)你再發(fā)起一次請(qǐng)求時(shí)，服務(wù)器也不知道你拜訪過它，基本的 HTTP 請(qǐng)求中是不含狀態(tài)信息的。所幸我們可以增加 cookie 的頭部擴(kuò)展來記錄狀態(tài)信息。

使用可靠連接

HTTP 依賴于運(yùn)輸層的 TCP 協(xié)議進(jìn)行消息傳遞，而 TCP 是可靠的。

狀態(tài)碼

狀態(tài)碼的第一個(gè)數(shù)字代表當(dāng)前響應(yīng)類型

• 1xx - 信息，請(qǐng)求已被服務(wù)器接收，繼續(xù)處理
• 2xx - 成功，請(qǐng)求已成功被服務(wù)器接收、理解、并接受
• 3xx - 重定向，需要后續(xù)操作才能完成這一請(qǐng)求
• 4xx - 客戶端錯(cuò)誤，請(qǐng)求含有詞法錯(cuò)誤或者無法被執(zhí)行
• 5xx - 服務(wù)器端錯(cuò)誤，服務(wù)器在處理某個(gè)正確請(qǐng)求時(shí)發(fā)生錯(cuò)誤

HTTP 的請(qǐng)求方法

較少用的方法

• OPTIONS：請(qǐng)求服務(wù)器告知其支持的各種功能。可以詢問服務(wù)器通常支持哪些方法，或者對(duì)某些特殊資源支持哪些方法
• HEAD：向服務(wù)器發(fā)出指定資源的請(qǐng)求，但服務(wù)器在響應(yīng)中只返回首部，不會(huì)返回實(shí)體的主體即資源的 body 部分
• PUT：向服務(wù)器寫入資源
• DELETE：請(qǐng)服務(wù)器刪除請(qǐng)求 URL 所指定的資源
• TRACE：HTTP 請(qǐng)求在傳輸?shù)倪^程中是可能會(huì)被修改的。這個(gè)方法允許客戶端在最終將請(qǐng)求發(fā)送給服務(wù)器時(shí)，看看它變成了什么樣子。主要用于測(cè)試或診斷
• CONNECT：這個(gè)方法將請(qǐng)求的連接轉(zhuǎn)換為透明的 TCP/IP 隧道，通常用于加快基于 SSL 加密的通信
• PATCH：這個(gè)方法請(qǐng)求對(duì)資源進(jìn)行局部修改

常用方法

GET && POST

GET 是最常用的方法，用于請(qǐng)求服務(wù)器發(fā)送某個(gè)資源。POST 方法用于向服務(wù)器發(fā)送數(shù)據(jù)，注意這和 PUT 的寫入資源是不同的，寫入的資源是存儲(chǔ)在服務(wù)器的，而發(fā)送的數(shù)據(jù)會(huì)發(fā)送到其他地方去處理，這可能會(huì)導(dǎo)致新資源的創(chuàng)建或已存在資源的更新，POST 通常用于支持 HTML 表單。

這兩個(gè)方法有什么區(qū)別？

冪等
在數(shù)學(xué)中，冪等有兩種主要含義：

• 在某二元運(yùn)算下，冪等元素是指被自己重復(fù)運(yùn)算的結(jié)果等于它自己的元素。例如 0 * 0 仍然為 0，所以 0 在乘法下是冪等的。
• 某一元運(yùn)算為冪等的時(shí)，其作用在任一元素兩次后會(huì)和其作用一次的結(jié)果相同，例如 恒等函數(shù) f(x) = x 就是冪等的。

在計(jì)算機(jī)網(wǎng)絡(luò)中，假如在不考慮諸如錯(cuò)誤或者過期等問題的情況下，若干次請(qǐng)求的副作用與單次請(qǐng)求相同或者根本沒有副作用，那么這些請(qǐng)求方法就能夠被視作是“冪等”的。

我們知道，GET 用于表單數(shù)據(jù)提交時(shí)，表單數(shù)據(jù)會(huì)被編碼在請(qǐng)求的 URI 上，這樣極不安全，因?yàn)檎?qǐng)求的地址可能在情趣到達(dá)目的地之前被打印，然后被第三方看到。而 POST 提交的數(shù)據(jù)是放在請(qǐng)求體中的，比 GET 提交數(shù)據(jù)安全，當(dāng)然，沒有 HTTPS，POST 提交的數(shù)據(jù)也能被看到。

但是最主要的區(qū)別，應(yīng)該為如下三點(diǎn)：

• 安全性(safe): GET 請(qǐng)求是安全的，這里的安全是指 GET 方法只獲取信息而不做其他操作。而 POST 請(qǐng)求則是不安全的，因?yàn)樗鼤?huì)更新或創(chuàng)建資源。

• 冪等性(idempotent): GET 請(qǐng)求是冪等的，冪等就是上面所說的若干次請(qǐng)求的副作用與單次請(qǐng)求相同，而 POST 請(qǐng)求則是不冪等的。

• 可緩存性(cacheable): GET 請(qǐng)求的響應(yīng)是可緩存的，POST 請(qǐng)求的響應(yīng)一般是不可緩存的，除非設(shè)置了合適的 Cache-Control 或 Expires 頭部字段。

HTTPS

為什么優(yōu)先要使用 HTTPS？

有三個(gè)主要原因：

• 機(jī)密性 (Confidentiality)

這能保護(hù)通信的雙方在公共媒介中免遭信息竊聽。如果沒有 HTTPS，當(dāng)你通過 WiFi 接入點(diǎn)網(wǎng)上購(gòu)物時(shí)，WiFi 接入點(diǎn)的運(yùn)營(yíng)者就能看到你的信用卡之類的隱私信息。

• 數(shù)據(jù)完整性 (Integrity)

這能保證信息能不受改變地完整到達(dá)目的地。比如，WiFi 可以在我們的網(wǎng)站上增加廣告，降低圖片質(zhì)量或者改變文章的內(nèi)容。HTTPS 能確保網(wǎng)站不被更改。

• 身份驗(yàn)證 (Authentication)

這能保證網(wǎng)站不會(huì)是假冒的，域名是哪個(gè)，站點(diǎn)就是哪個(gè)。比如，一些運(yùn)行 WiFi 接入點(diǎn)的猥瑣之人可以把瀏覽器導(dǎo)向一些假冒的網(wǎng)站。HTTPS 能確保example.com就是真的example.com，有些安全證書甚至要檢查網(wǎng)站的合法身份，讓你知道yourbank.com是YourBank, Inc，即 YourBank 公司。

使用 HTTP 頭部字段保護(hù)你的 web 應(yīng)用

禁用秘密信息的緩存

瀏覽器默認(rèn)緩存 HTTP 的 GET 請(qǐng)求的響應(yīng)，如果使用的是共享個(gè)人電腦 (網(wǎng)吧不就是么？)，那么猥瑣之人就能通過訪問瀏覽器的緩存得到他人的隱私信息。所以我們要在返回隱私信息時(shí)使用三個(gè)響應(yīng)頭字段來禁用客戶端的緩存：

• Cache-Control: no-cache, no-store, max-age=0, must-revalidate
  cache-control 字段用來指定在這次的請(qǐng)求/響應(yīng)鏈中的所有緩存機(jī)制都必須遵守的指令。上面的三個(gè)指令告訴客戶端和代理在使用緩存前必須送請(qǐng)求到服務(wù)器進(jìn)行驗(yàn)證，不要儲(chǔ)存響應(yīng)，在請(qǐng)求發(fā)生之后的 0 秒后緩存即過期，在使用緩存的響應(yīng)前檢查其狀態(tài)并禁止使用過期的響應(yīng)。

• Pragma: no-cache
  這個(gè)字段用于向后兼容 HTTP 1.0，確保老客戶端能不緩存響應(yīng)。

• Expires: -1
  這個(gè)字段用于指定響應(yīng)過期的時(shí)間戳。指定為-1的話，客戶端就會(huì)立即把響應(yīng)當(dāng)做過期的，這就避免了緩存。

請(qǐng)?jiān)谛枰Ｗo(hù)隱私時(shí)才禁用緩存，否則你的應(yīng)用加載速度將大打折扣。

強(qiáng)制 HTTPS

HTTPS 的重要性我在前面已經(jīng)說了，要強(qiáng)制 HTTPS，我們要使用 HTTP Strict Transport Security (HSTS) 頭部字段，具體可以設(shè)置為Strict-Transport-Security: max-age=31536000; includeSubDomains; preload。

max-age是指示瀏覽器為當(dāng)前域名緩存這個(gè)頭部字段指定秒數(shù)，這里是緩存一年。includeSubDomains指示瀏覽器將 HSTS 應(yīng)用于當(dāng)前域名的所有子域名。preload強(qiáng)制瀏覽器總是安全地加載你的 web 應(yīng)用，甚至在你第一次訪問網(wǎng)站且未收到響應(yīng)前，這個(gè)特性是通過將一個(gè)安全預(yù)加載的域名的列表硬編碼到瀏覽器代碼中實(shí)現(xiàn)的，要使用這個(gè)特性你需要在 HSTS Preload List Submission 注冊(cè)你的域名，當(dāng)然啦，使用這個(gè)指令你得確保你的應(yīng)用能只使用 HTTPS。

允許 XSS 過濾

XSS 即跨站腳本攻擊，是很普遍也很簡(jiǎn)單的網(wǎng)絡(luò)攻擊手法。我們會(huì)使用X-XSS-Protection: 1; mode=block，X-XSS-Protection這個(gè)字段指示瀏覽器是否為當(dāng)前頁(yè)面開啟瀏覽器內(nèi)建的 XSS 過濾機(jī)制并覆蓋瀏覽器本身的相關(guān)設(shè)置。1表示允許過濾器，反之為0，mode=block指示瀏覽器在檢測(cè)到 XSS 攻擊后禁止加載整個(gè)頁(yè)面。

控制 Framing

一個(gè) iframe 是一個(gè)可以允許在一個(gè)父 web 應(yīng)用中嵌套一個(gè) web 應(yīng)用的 DOM 元素。這個(gè)元素可以讓點(diǎn)擊劫持 (* clickjacking) 更容易。點(diǎn)擊劫持可以欺騙用戶點(diǎn)擊非用戶本意的東西。為了阻止這種攻擊，我們使用X-Frame-Options: SAMEORIGIN，X-Frame-Options*這個(gè)字段指示瀏覽器是否允許你的 web 應(yīng)用嵌套在另一個(gè) web 應(yīng)用中，SAMEORIGIN 表示你的應(yīng)用可以在同域名頁(yè)面的 frame 中展示。注意當(dāng)在 Content-Security-Policy 字段中指定了 frame-ancestors 時(shí)，則 X-Frame-Options 被忽略，見 這里。

明確白名單

CSP (Content Security Policy) 定義了一個(gè)非常強(qiáng)大的基于瀏覽器的安全機(jī)制，允許對(duì)你的 web 應(yīng)用中的資源加載和腳本執(zhí)行加以控制。有了它，你可以將允許腳本加載、ajax 調(diào)用、圖片和樣式表加載的域列入白名單，可以允許或禁止內(nèi)聯(lián)腳本和動(dòng)態(tài)腳本等。我們可以通過簡(jiǎn)單設(shè)置Content-Security-Policy: script-src 'self'來允許同源的腳本加載以及阻止動(dòng)態(tài)腳本和內(nèi)聯(lián)腳本執(zhí)行。Content-Security-Policy 是個(gè)比較復(fù)雜的頭部字段，詳細(xì)的配置可以在這里看到。

阻止 Content-Type 嗅探

為了使用戶體驗(yàn)更連貫，很多瀏覽器實(shí)現(xiàn)了一個(gè)叫 “Content-Type 嗅探” 或 “MIME 嗅探” 的功能，這個(gè)功能使瀏覽器能通過實(shí)際資源的比特位檢測(cè) HTTP 中響應(yīng)資源的類型而不理會(huì)響應(yīng)頭中的Content-Type字段聲明的資源類型。但這會(huì)導(dǎo)致 MIME 混淆攻擊 (MIME confusion attack)。于是乎，我們要使用X-Content-Type-Options: nosniff，指示瀏覽器在處理獲取的資源時(shí)不要使用嗅探。

HTTP/2

多數(shù)主流瀏覽器已經(jīng)在2015年底支持了該協(xié)議。此外，根據(jù) W3Techs 的數(shù)據(jù)，在2017年5月，在排名前一千萬的網(wǎng)站中，有13.7% 支持了HTTP/2。這真真是極吼滴！有圖有真相。

http2 support

HTTP/2 相比 HTTP 1.x 的主要區(qū)別

是二進(jìn)制的而非文本的

有別于 HTTP/1.1 中的明文請(qǐng)求，HTTP/2 將一個(gè) TCP 連接分為若干個(gè)流 (stream)，每個(gè)流中可以傳輸若干消息 (message)，每個(gè)消息由若干最小的二進(jìn)制幀 (frame) 組成。這樣更利于高效地解析，而且不容易出錯(cuò)，畢竟 HTTP/1.x 的 header 中有空白行、大小寫、換行、空行之類的規(guī)定。

是完全多路復(fù)用而非按順序和阻塞的

HTTP/1.x 有一個(gè) head-of-line blocking 的問題，它會(huì)讓一個(gè)連接一次只能發(fā)送一個(gè)請(qǐng)求。多路復(fù)用允許多個(gè)請(qǐng)求和響應(yīng)消息同時(shí)發(fā)出，甚至可以混合一個(gè)消息的一部分和另一個(gè)消息。

只開一個(gè)連接用于并發(fā)的請(qǐng)求

HTTP/1.x 中為了加載資源會(huì)同時(shí)打開多個(gè) TCP 連接，每個(gè)連接在響應(yīng)時(shí)又都會(huì)發(fā)送大量數(shù)據(jù)，存在中間網(wǎng)絡(luò) (intervening network) 緩沖區(qū)溢出的危險(xiǎn)，導(dǎo)致網(wǎng)絡(luò)阻塞和重發(fā) (* retransmits*)。而且，使用那么多的 TCP 連接也是一種大量占用網(wǎng)絡(luò)資源的行為。

壓縮頭部

在大型網(wǎng)站中，一個(gè)頁(yè)面往往要請(qǐng)求大量資源并得到相應(yīng)，算上那些往返的話，那么頭部就會(huì)占據(jù)相當(dāng)大的開銷，所以壓縮頭部的好處便變得顯而易見了。

允許服務(wù)器主動(dòng)推送資源給客戶端

在 HTTP/1.x 中，當(dāng)瀏覽器請(qǐng)求了一個(gè)頁(yè)面，服務(wù)器發(fā)送了 HTML 頁(yè)面的響應(yīng)，然后服務(wù)器需要等待瀏覽器解析了 HTML 文件后再發(fā)起嵌入在 HTML 頁(yè)面中的多個(gè)資源的請(qǐng)求，想想都覺得慢。而服務(wù)器端推送避免了這種往返的延遲，服務(wù)器會(huì)主動(dòng)推送它認(rèn)為的客戶端會(huì)需要緩存的資源。要小心的是，這個(gè)功能濫用的話，會(huì)損害性能。

如何擁抱 HTTP/2？

HTTP/2 是向后兼容 HTTP/1.1 的，所以完全不需要擔(dān)心現(xiàn)有的網(wǎng)站會(huì)發(fā)生什么問題。然而，很多對(duì)于 HTTP/1.1 來說是最佳實(shí)踐的技巧卻會(huì)在使用 HTTP/2 時(shí)降低性能。再者，從 HTTP/1.1 轉(zhuǎn)向 HTTP/2 勢(shì)必是漫長(zhǎng)的，因?yàn)榉?wù)器端升級(jí)容易，但只要一日絕大多數(shù)人仍然使用著老舊甚至是史前瀏覽器，客戶端就會(huì)是扎心窩的痛。我們需要做些過渡時(shí)期的事。

轉(zhuǎn)向 TLS

第一要?jiǎng)?wù)是讓你的網(wǎng)站運(yùn)行在安全連接上，因?yàn)閺S商大佬們已經(jīng)說過了：我們哥們幾個(gè)只支持有 TLS 的 HTTP/2，那些不支持 TLS 的可以歇菜了。所以國(guó)內(nèi)大片的 HTTP 網(wǎng)站們要好好考慮轉(zhuǎn)向 HTTPS 的事了。

雪碧圖不再總是最佳的選擇

在 HTTP/1.1 中，對(duì)于瀏覽器來說，獲取一個(gè)巨大的圖片文件比請(qǐng)求多個(gè)小圖片文件高效，這是因?yàn)槎鄠€(gè)請(qǐng)求會(huì)互相排隊(duì)，增加加載時(shí)間。通常的做法是把多個(gè)小圖片轉(zhuǎn)成一個(gè)雪碧圖。

轉(zhuǎn)成一個(gè)雪碧圖就只需要一個(gè) HTTP 請(qǐng)求了。但是咧，如果一個(gè)頁(yè)面中只使用到雪碧圖中的一個(gè)圖標(biāo)，仍然下載整個(gè)雪碧圖就顯得不是很好了。HTTP/2 擁有多路復(fù)用的能力，所以多個(gè)請(qǐng)求排隊(duì)的事已經(jīng)不存在了，很多時(shí)候單個(gè)地請(qǐng)求圖片將是更好的選擇。當(dāng)然，需要使用所有圖標(biāo)時(shí)，雪碧圖仍然是需要的。

使用 Data URI 內(nèi)嵌圖片是一種阻礙

在 HTTP/1.1 中，為了減少 HTTP 請(qǐng)求，你可以把圖片直接以 Data URI 的形式嵌入 CSS 或 HTML 文件中。因?yàn)檗D(zhuǎn)成的字符編碼會(huì)很長(zhǎng)，自然增加了 CSS 或 HTML 文件的大小。在 HTTP/2 中，HTTP 請(qǐng)求變得廉價(jià)，這種 “最佳實(shí)踐” 便變成了一種妨礙。

合并 CSS 文件和 JavaScript 文件未必好

我們?cè)趹?yīng)用的構(gòu)建階段，通常會(huì)合并那些小的 CSS 和 JavaScript 文件，本意是減少 HTTP 請(qǐng)求。但是在 HTTP/2 中，HTTP 請(qǐng)求是廉價(jià)的，合并便不再顯得有優(yōu)勢(shì)。可能更糟糕的是，如果你因?yàn)楹喜⒁肓撕芏喾潜卷?yè)面所需的文件，反而拖慢了加載速度，當(dāng)然，你是可以通過 webpack 來配置相應(yīng)頁(yè)面所需的相應(yīng)文件的，可是別忘了，合并文件是要引入大量處理合并的代碼的，在 HTTP/2 廉價(jià)的請(qǐng)求中，這些多余的處理代碼看來有點(diǎn)多余，止增笑耳。

域名分片可能會(huì)坑你

在 HTTP/1.1 中，每個(gè)域名能打開的連接是受到限制的，大概為 6 - 8 個(gè)，具體取決于瀏覽器實(shí)現(xiàn)。如果你實(shí)在要加載大量資源，其中一個(gè)方法就是從多個(gè)域名中獲取資源，這就是域名分片 (domain sharding)。這個(gè)方法能實(shí)現(xiàn)更好的加載時(shí)間，也有能導(dǎo)致問題，當(dāng)然，準(zhǔn)備這種服務(wù)就會(huì)有額外的開支。HTTP/2 則移除了域名分片的需求，在 HTTP/2 下，瀏覽器只為每個(gè)域名打開一個(gè)連接，但是人家有多路復(fù)用嘛，并發(fā)請(qǐng)求的數(shù)量根本不受限制 (當(dāng)然也可以通過 SETTINGS_MAX_CONCURRENT_STREAMS 來限制)。而且，域名分片在 HTTP/2 中還會(huì)損害性能，因?yàn)樗鼊?chuàng)建了額外的 TCP 連接，妨礙 HTTP/2 為資源進(jìn)行優(yōu)先級(jí)排序。

當(dāng)前對(duì)于 HTTP/1.1 的最佳實(shí)踐是限制域名分片為 2 個(gè)域名。好消息是為了減少工作并在 HTTP/1.1 和 HTTP/2 都能達(dá)到很好的效果，有方法可以讓 HTTP/2 合并你的連接，具體方法見 Google 家的 slide 26。

實(shí)現(xiàn)

可喜的是，現(xiàn)在已經(jīng)有大量的 HTTP/2 的服務(wù)器端實(shí)現(xiàn)了，涵蓋了多種語(yǔ)言，參見
Implementations。

Reference

• The Complete Guide To Switching From HTTP To HTTPS
• An overview of HTTP
• Hypertext Transfer Protocol
• Method Definitions
• HTTP協(xié)議中GET和POST方法的區(qū)別
• How To Secure Your Web App With HTTP Headers
• List of HTTP header fields - Wikipedia
• RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)
• HTTP/2 - Wikipedia
• Getting Ready For HTTP2: A Guide For Web Designers And Developers
• HTTP/2 Frequently Asked Questions