美團(tuán)-前端開發(fā)面經(jīng)（八）

一. 介紹

HTTP/2是HTTP協(xié)議自1999年HTTP1.1發(fā)布后的首個更新，主要基于SPDY協(xié)議。

1.1 什么是SPDY協(xié)議

SPDY是Speedy的昵音，意為“更快”。它是Google開發(fā)的基于TCP協(xié)議的應(yīng)用層協(xié)議。目標(biāo)是優(yōu)化HTTP協(xié)議的性能，通過壓縮、多路復(fù)用和優(yōu)先級等技術(shù)，縮短網(wǎng)頁的加載時間并提高安全性。SPDY協(xié)議的核心思想是盡量減少TCP連接數(shù)。SPDY并不是一種用于替代HTTP的協(xié)議，而是對HTTP協(xié)議的增強(qiáng)。

1.2 HTTP1.X的缺點(diǎn)

任何事物的更新都是為了彌補(bǔ)或修復(fù)上個版本的某些問題，那么我們來看看HTTP1.x都有哪些缺點(diǎn)以至于我們要使用HTTP2.0。

HTTP1.x有以下幾個主要缺點(diǎn)：

HTTP/1.0一次只允許在一個TCP連接上發(fā)起一個請求，HTTP/1.1使用的流水線技術(shù)也只能部分處理請求并發(fā)，仍然會存在隊列頭阻塞問題，因此客戶端在需要發(fā)起多次請求時，通常會采用建立多連接來減少延遲。

單向請求，只能由客戶端發(fā)起。

請求報文與響應(yīng)報文首部信息冗余量大。

數(shù)據(jù)未壓縮，導(dǎo)致數(shù)據(jù)的傳輸量大

我們可以通過一個鏈接來對比一下HTTP2.0到底比HTTP1.x快了多少。鏈接地址

二. 二進(jìn)制分幀

在不改變HTTP1.x的語義、方法、狀態(tài)碼、URL以及首部字段的情況下，HTTP2.0是怎樣突破HTTP1.1的性能限制，改進(jìn)傳輸性能，實(shí)現(xiàn)低延遲高吞吐量的呢？關(guān)鍵之一就是在應(yīng)用層（HTTP）和傳輸層（TCP）之間增加一個二進(jìn)制分幀層。

在整理二進(jìn)制分幀及其作用的時候我們先來鋪墊一點(diǎn)關(guān)于幀的知識：

幀：HTTP2.0通信的最小單位，所有幀都共享一個8字節(jié)的首部，其中包含幀的長度、類型、標(biāo)志、還有一個保留位，并且至少有標(biāo)識出當(dāng)前幀所屬的流的標(biāo)識符，幀承載著特定類型的數(shù)據(jù)，如HTTP首部、負(fù)荷、等等。

消息：比幀大的通訊單位，是指邏輯上的HTTP消息，比如請求、響應(yīng)等。由一個或多個幀組成

流：比消息大的通訊單位。是TCP連接中的一個虛擬通道，可以承載雙向的消息。每個流都有一個唯一的整數(shù)標(biāo)識符

HTTP2.0中所有加強(qiáng)性能的核心是二進(jìn)制傳輸，在HTTP1.x中，我們是通過文本的方式傳輸數(shù)據(jù)?；谖谋镜姆绞絺鬏敂?shù)據(jù)存在很多缺陷，文本的表現(xiàn)形式有多樣性，因此要做到健壯性考慮的場景必然有很多，但是二進(jìn)制則不同，只有0和1的組合，因此選擇了二進(jìn)制傳輸，實(shí)現(xiàn)方便且健壯。

在HTTP2.0中引入了新的編碼機(jī)制，所有傳輸?shù)臄?shù)據(jù)都會被分割，并采用二進(jìn)制格式編碼。

為了保證HTTP不受影響，那就需要在應(yīng)用層（HTTP2.0）和傳輸層（TCP or UDP）之間增加一個二進(jìn)制分幀層。在二進(jìn)制分幀層上，HTTP2.0會將所有傳輸?shù)男畔⒎譃楦〉南⒑蛶?，并采用二進(jìn)制格式編碼，其中HTTP1.x的首部信息會被封裝到Headers幀，而Request Body則封裝到Data幀。

三. 首部壓縮

HTTP1.1并不支持HTTP首部壓縮，為此SPDY和HTTP2.0出現(xiàn)了。SPDY是用的是DEFLATE算法，而HTTP2.0則使用了專門為首部壓縮設(shè)計的HPACK算法。

HTTP每次通訊（請求或響應(yīng)）都會攜帶首部信息用于描述資源屬性。

在HTTP1.0中，我們使用文本的形式傳輸header，在header中攜帶cookie的話，每次都需要重復(fù)傳輸幾百到幾千的字節(jié)，這著實(shí)是一筆不小的開銷。

在HTTP2.0中，我們使用了HPACK（HTTP2頭部壓縮算法）壓縮格式對傳輸?shù)膆eader進(jìn)行編碼，減少了header的大小。并在兩端維護(hù)了索引表，用于記錄出現(xiàn)過的header，后面在傳輸過程中就可以傳輸已經(jīng)記錄過的header的鍵名，對端收到數(shù)據(jù)后就可以通過鍵名找到對應(yīng)的值。

四. 多路復(fù)用

在HTTP1.x中，我們經(jīng)常會使用到雪碧圖、使用多個域名等方式來進(jìn)行優(yōu)化，都是因?yàn)闉g覽器限制了同一個域名下的請求數(shù)量，當(dāng)頁面需要請求很多資源的時候，隊頭阻塞（Head of line blocking）會導(dǎo)致在達(dá)到最大請求時，資源需要等待其他資源請求完成后才能繼續(xù)發(fā)送。

HTTP2.0中,基于二進(jìn)制分幀層，HTTP2.0可以在共享TCP連接的基礎(chǔ)上同時發(fā)送請求和響應(yīng)。HTTP消息被分解為獨(dú)立的幀，而不破壞消息本身的語義，交錯發(fā)出去，在另一端根據(jù)流標(biāo)識符和首部將他們重新組裝起來。通過該技術(shù)，可以避免HTTP舊版本的隊頭阻塞問題，極大提高傳輸性能。

五. 請求優(yōu)先級

把HTTP消息分為很多獨(dú)立幀之后，就可以通過優(yōu)化這些幀的交錯和傳輸順序進(jìn)一步優(yōu)化性能。

六. 服務(wù)器推送

HTTP2.0新增的一個強(qiáng)大的新功能，就是服務(wù)器可以對一個客戶端請求發(fā)送多個響應(yīng)。服務(wù)器向客戶端推送資源無需客戶端明確的請求。

服務(wù)端根據(jù)客戶端的請求，提前返回多個響應(yīng)，推送額外的資源給客戶端。如下圖，客戶端請求stream 1(/page.html)。服務(wù)端在返回stream 1的消息的同時推送了stream 2(/script.js)和stream 4(/style.css)

服務(wù)端推送是一種在客戶端請求之前發(fā)送數(shù)據(jù)的機(jī)制。在HTTP2.0中，服務(wù)器可以對一個客戶端的請求發(fā)送多個響應(yīng)。如果一個請求是由你的主頁發(fā)送的，服務(wù)器可能會響應(yīng)主頁內(nèi)容、logo以及樣式表，因?yàn)樗揽蛻舳藭玫竭@些東西。這樣不但減輕了數(shù)據(jù)傳送冗余步驟，也加快了頁面響應(yīng)的速度，提高了用戶體驗(yàn)。

推送的缺點(diǎn)：所有推送的資源都必須遵守同源策略。換句話說，服務(wù)器不能隨便將第三方資源推送給客戶端，而必須是經(jīng)過雙方的確認(rèn)才行。

Webpack 的運(yùn)行流程是一個串行的過程，從啟動到結(jié)束會依次執(zhí)行以下流程：

初始化參數(shù)：從配置文件和 Shell 語句中讀取與合并參數(shù)，得出最終的參數(shù)；

開始編譯：用上一步得到的參數(shù)初始化 Compiler 對象，加載所有配置的插件，執(zhí)行對象的 run 方法開始執(zhí)行編譯；

確定入口：根據(jù)配置中的 entry 找出所有的入口文件；

編譯模塊：從入口文件出發(fā)，調(diào)用所有配置的 Loader 對模塊進(jìn)行翻譯，再找出該模塊依賴的模塊，再遞歸本步驟直到所有入口依賴的文件都經(jīng)過了本步驟的處理；

完成模塊編譯：在經(jīng)過第4步使用 Loader 翻譯完所有模塊后，得到了每個模塊被翻譯后的最終內(nèi)容以及它們之間的依賴關(guān)系；

輸出資源：根據(jù)入口和模塊之間的依賴關(guān)系，組裝成一個個包含多個模塊的 Chunk，再把每個 Chunk 轉(zhuǎn)換成一個單獨(dú)的文件加入到輸出列表，這步是可以修改輸出內(nèi)容的最后機(jī)會；

輸出完成：在確定好輸出內(nèi)容后，根據(jù)配置確定輸出的路徑和文件名，把文件內(nèi)容寫入到文件系統(tǒng)。

在以上過程中，Webpack 會在特定的時間點(diǎn)廣播出特定的事件，插件在監(jiān)聽到感興趣的事件后會執(zhí)行特定的邏輯，并且插件可以調(diào)用 Webpack 提供的 API 改變 Webpack 的運(yùn)行結(jié)果。

用webpack優(yōu)化前端性能是指優(yōu)化webpack的輸出結(jié)果，讓打包的最終結(jié)果在瀏覽器運(yùn)行快速高效。

壓縮代碼。刪除多余的代碼、注釋、簡化代碼的寫法等等方式。可以利用webpack的UglifyJsPlugin和ParallelUglifyPlugin來壓縮JS文件， 利用cssnano（css-loader?minimize）來壓縮css

利用CDN加速。在構(gòu)建過程中，將引用的靜態(tài)資源路徑修改為CDN上對應(yīng)的路徑?？梢岳脀ebpack對于output參數(shù)和各loader的publicPath參數(shù)來修改資源路徑

刪除死代碼（Tree Shaking）。將代碼中永遠(yuǎn)不會走到的片段刪除掉?？梢酝ㄟ^在啟動webpack時追加參數(shù)--optimize-minimize來實(shí)現(xiàn)

提取公共代碼