HTTP,HTTPS,HTTP2筆記

時間 2019-11-10

原文原文鏈接

HTTP

網絡協議分層

應用層      -> HTTP FTP 爲應用軟件提供了不少服務 構建於TCP協議之上 屏蔽網絡傳輸的相關細節 傳輸層 -> TCP UDP 向用戶提供可靠的端對端的服務(end to end) (數據量過大，會分包發送) 網絡層 -> 爲數據節點之間傳輸建立邏輯鏈路 數據鏈路層 -> 物理鏈接完成後，須要經過軟件進行鏈接 物理層 -> 網線，光纖等傳輸硬件設備

TCP/IP協議

計算機與網絡設備相互通訊，雙方就必須基於相同的方法,不管是語言之間的通信，設備，硬件，操做系統的通信，怎麼開始，怎麼發起，怎麼結束，都須要一種規則。我這種規則被稱爲協議。例如：TCP、FTP、HTTP、DNS、ICMP、IP、UDP......javascript

IP協議

IP協議位於網絡層，指的是網際協議。做用是把各類數據包傳送給對方。而要保證確實傳送到對方那裏。(須要兩個重要的條件1:IP地址 2:MAC地址)css

TCP協議

TCP協議位於傳輸層，提供可靠的字節流服務。所謂字節流:指的是把大數據分割成以報文字段爲單位的數據包進行管理。而且將數據準確可靠的傳給對方。html

工做原理: 1.輸入url地址，按回車 2.發生跳轉(redirect)[可能有301的狀況，純客戶端行爲] 3.判斷是否已經緩存過，緩存是否過時等 4.DNS域名解析，把解析完的地址返回給客戶端 5.瀏覽器建立TCP連接，三次握手 6.http生成目標web請求報文 6.1 若是有代理服務器，會先通過代理服務器，也會判斷緩存狀況 7.通過各類路由器[能夠經過抓包工具瞭解通過了哪些路由器] 8.服務器拿到報文信息，並把請求結果，也利用TCP通信協議按照原路返回給客戶端 9.客戶端拿到服務器的http響應報文後，使用了gzip或其餘壓縮算法，拿到指望的HTML代碼 10.在瀏覽器接收完整HTML文件前，瀏覽器就開始渲染頁面了(瀏覽器將HTML字節數據通過一個流程解析爲DOM樹) - 字節->字符->令牌->節點對象->對象模型 11.當HTML代碼遇到<link>標籤時，瀏覽器會發送請求得到該標籤中標記的CSS文件。 使人欣喜的是，這是一個異步請求，不影響其餘操做，瀏覽器得到數據後就會像構建DOM樹同樣構建CSSOM樹。

統一資源標誌

URL Uniform Resource Identifier /統一資源標誌符 用來惟一標識互聯網上的信息資源 包含了URL URN URL Uniform Resource Locator /統一資源定位器 舊版 http://user:pass@host.com:80/path?query=string#hash 默認端口號:80 URN 永久統一資源定位符

三次握手

第一次握手：創建鏈接時，客戶端發送syn包（syn=j）到服務器，並進入SYN_SENT狀態，等待服務器確認；SYN：同步序列編號（Synchronize Sequence Numbers）。前端

第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時本身也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態；java

第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ack=k+1），此包發送完畢，客戶端和服務器進入ESTABLISHED（TCP鏈接成功）狀態，完成三次握手。node

三次握手的目的:爲了防止已失效的鏈接請求報文段忽然又傳送到了服務端，於是產生錯誤

關閉鏈接要四次揮手

第一次揮手：Client發送一個FIN，用來關閉Client到Server的數據傳送，Client進入FIN_WAIT_1狀態。nginx

第二次揮手：Server收到FIN後，發送一個ACK給Client，確認序號爲收到序號+1（與SYN相同，一個FIN佔用一個序號），Server進入CLOSE_WAIT狀態。web

第三次揮手：Server發送一個FIN，用來關閉Server到Client的數據傳送，Server進入LAST_ACK狀態。算法

第四次揮手：Client收到FIN後，Client進入TIME_WAIT狀態，接着發送一個ACK給Server，確認序號爲收到序號+1，Server進入CLOSED狀態，完成四次揮手。apache

P:由於服務端在LISTEN狀態下，收到創建鏈接請求的SYN報文後，把ACK和SYN放在一個報文裏發送給客戶端。而關閉鏈接時，當收到對方的FIN報文時，僅僅表示對方再也不發送數據了可是還能接收數據，己方也未必所有數據都發送給對方了，因此己方能夠當即close，也能夠發送一些數據給對方後，再發送FIN報文給對方來表示贊成如今關閉鏈接，所以，己方ACK和FIN通常都會分開發送。(因此是四次揮手)

DNS域名解析

DNS(Domain Name System)位於應用層

DNS服務是和HTTP協議同樣位於應用層的協議，它提供域名到IP地址之間的解析服務。計算機擅長處理IP地址這樣長數字形式的內容，但卻不符合人類的記憶習慣，因此用戶會藉助域名（www.baidu.com）和端口號等來記憶。

但域名卻難以理解這樣的一串字符串，所以，DNS協議就營運而生，用於解析域名，經過域名查找IP地址，也能夠逆向從IP地址查找域名

同源策略

同源策略(Same origin policy)是一種約定，它是瀏覽器最核心也最基本的安全功能，若是缺乏了同源策略，則瀏覽器的正常功能可能會受到影響，能夠說web是構建在同源策略基礎上的，瀏覽器只是針對同源策略的一種實現。

他的核心在於它認爲自任何站點裝載的信賴內容都不安全的，當被瀏覽器半信半疑的腳本運行的沙箱時，他們應該只被容許訪問來自統一站點的資源，而不是那些來自其餘站點可能不懷好意的資源

所謂同源: 域名相同，協議相同，端口相同

另外，同源策略又分爲如下兩種

1.DOM同源策略：禁止對不一樣源頁面DOM進行操做，這裏主要場景是iframe跨域的狀況，不一樣域名的iframe是限制相互訪問的

2.XMLHttpRequest同源策略：禁止使用XHR對象向不一樣源的服務器發起http請求

若是出現了域名不一樣，協議不一樣，端口不一樣，就會受到同源策略的限制，產生跨域的問題。

同源策略的目的是保證用戶信息安全，防止惡意的網站竊取數據，防止其餘網站在訪問的時候獲取其餘網站留下的cookie信息。

限制範圍：

Cookie ,localStorage 和indexDB 沒法讀取
DOM沒法獲取（iframe 已經廢棄）
AJAX請求不能發送

所謂同源:必需要域名相同,端口相同,域名相同,才能訪問,不然出現跨域問題。限制訪問（什麼事同源策略）
同源的目的是爲了保護用戶的隱私安全，防止黑客的入侵（固然高級黑客仍是會有辦法的）（有什麼用）
同源策略是瀏覽器最基礎，最核心的安全功能。（爲何）
同源策略能限制cookie，localStorage和indexDB的獲取，DOM的獲取，和AJAx發起的http請求（具體做用）
在web開發中，先後端分離，通常是前端一個訪問端口，後臺一個訪問端口，就會產生跨域問題（產生什麼問題）
在html標籤中，img的src，link標籤，a標籤，和scrip標籤無視同源策略。能夠經過標籤進行跨域訪問>。(JSONP方法)(如何解決(其中一個方法))

解決跨域請求

CORS(使用最多)

Cross-Origin Resource Sharing（CORS）跨域資源共享是一份瀏覽器技術的規範，提供了 Web 服務從不一樣域傳來沙盒腳本的方法，以避開瀏覽器的同源策略，確保安全的跨域數據傳輸。現代瀏覽器使用CORS在API容器如XMLHttpRequest來減小HTTP請求的風險來源。與 JSONP 不一樣，CORS 除了 GET 要求方法之外也支持其餘的 HTTP 要求。服務器通常須要增長以下響應頭的一種或幾種： Access-Control-Allow-Origin: *//(不安全)容許跨域的端口(url)，或者是一個接口 Access-Control-Allow-Methods: POST, GET, OPTIONS//容許跨域的方式 Access-Control-Allow-Headers: X-PINGOTHER, Content-Type //容許跨域的請求頭，能夠自定 Access-Control-Max-Age: 86400 //容許在一千秒內發起正式，不用發起預請求

JSONP(相對較多,只適用GET請求)

jsonp的原理就是，在客戶端和服務端定義一個函數，當客戶端發起一個請求時，服務端返回一段javascript代碼，其中調用了在客戶端定義的函數，並將相應的數據做爲參數傳入該函數。須要先後端協商函數。

代理(最熱門)

代理與反向代理 同源策略是針對瀏覽器端進行的限制，能夠經過服務器端來解決該問題 瀏覽器--訪問(發出請求)--->代理服務器---（代請求）---> 服務器 Nginx,node中間件等

跨域技術不只僅是有這幾種，還有圖片ping方法！(一樣利用了標籤的src不受同源策略影響)、websocket(瀏覽器與服務器全雙工通訊，同時容許跨域通信) 、window.postMessage()等等。（自行百度！）

通信轉發代理/網關/隧道

代理

做用：利用緩存技術減小網絡帶寬的流量，組織內部針對特定網站的訪問控制，以獲取訪問日誌爲主要目的。

特色：代理不改變請求的URL，會直接發送給前方持有資源的目標服務器(源服務器)。在HTTP通訊中，可級聯多臺代理服務器(即請求和響應都通過數臺相似鎖鏈同樣鏈接的代理服務器)，轉發時，須要附加Via首部字段以標記出通過的主機信息。

緩存代理：會預先將資源的副本(緩存)保存在代理服務器上，當下次再接受到一樣的請求時，就能夠不須要從源服務器上獲取資源，而是在代理服務器上直接返回資源

透明代理：轉發請求或響應時，不對報文作任何加工的代理類型，叫作透明代理，反之叫非透明代理...

隧道

目的：隧道的目的是爲了確保客戶端能與服務器進行安全的通訊

可按要求創建起來一條與其餘服務器的通信線路,屆時使用SSL等加密手段進行通信.確保安全性.隧道自己不會去解析HTTP請求。也就是說，隧道只是用來中轉HTTP請求，當通信雙方斷開鏈接是結束

網關

網關的工做機制和代理十分類似，而網關能使通信線路上的服務器提供非HTTP協議服務。利用網關能提升通訊的安全性。由於能夠在客戶端與網關之間的通信路上加密以確保連接的安全

HTTP報文

報文首部

報文首部字段是構成HTTP報文的要素之一。

使用首部字段是爲了給瀏覽器和服務器提供報文主體大小，所使用的語言，認證信息等內容。

通用首部字段

請求報文和響應報文雙方都要使用的首部！

通用首部字段名	說明
Cache-Control	控制緩存的行爲
Connection	控制不在轉發給代理的首部字段、管理持久連接
Date	建立報文的日期和時間
Pragma	僅做爲HTTP/1.0的向後兼容被定義
Trailer	報文主體後加的首部字段，可用在分塊編碼時
Transfer-Encoding	指定報文主體的傳輸編碼格式
Upgrade	檢測協議是否可以使用更高版本，（在使用該字段時要額外添加 Connection：Upgrade字段）
Via	追蹤客戶端和服務器以前請求和響應的傳輸路徑，（全部代理服務器的信息）
Warning	各類錯誤警告

響應首部字段(Response Headers)

從服務器端向客戶端返回響應報文時使用的首部，補充了響應的附加內容，也會要求客戶端附加的內容信息

響應首部字段名	說明
Accept-Range	用來告知客戶端服務器是否能處理範圍請求，能夠指定爲betys，反之指定爲none
Age	返回資源建立到此次請求所通過的時間，單位爲s
ETage	服務器將資源以字符串的形式做惟一標識ETage
Location	告知服務器用戶代理可以處理的天然語言以及天然語言的優先級
Authorization	用來告知服務器用戶代理的認證信息（屬客戶端與代理之間的通訊）
Retry-After	告知客戶端多久以後再次訪問
Server	告知客戶端當前服務器安裝的HTTP服務器應用程序的信息
Vary	代理服務器須要緩存的管理信息
WWW-Authenticate	服務器對對客戶端的認證信息

請求首部字段(Request Headers)

從客戶端向服務器發送請求報文時使用的首部！補充了請求的附加內容，客戶端信息，響應內容的相關優先級等信息。

請求首部字段名	說明
Accept	通知服務器用戶代理可處理的媒體類型以及優先級
Accept-Charset	通知服務器用戶代理支持的字符集以及字符集的優先順序
Accept-Encoding	告知服務器用戶代理支持的內容編碼以及內容編碼的優先順序
Accept-Language	告知服務器用戶代理可以處理的天然語言以及天然語言的優先級
Authorization	用來告知服務器用戶代理的認證信息
Expet	期待服務器出現某種待定行爲
From	告知服務器用戶代理的電子郵箱地址
Host	請求資源所處計算機的主機名和端口號
If-Match	告知服務器匹配資源所用的實體標記值
If-Modified-Sincest	告知服務器字段值時間以後有更新資源，則獲取
If-None-Match	和If-Match相反
If-Range	資源未更新時發送實體Bety的範圍請求
If-Unmodified-Since	告知服務器字段之間以後未更新資源，則獲取
Max-Forwards	以十進制的形式指定可通過的服務器的最大數目
Proxy-Authorization	代理服務器要求客戶端的認證信息
Pange	只須要獲取部分資源的請求告知服務器的資源指定範圍
Referer	告知服務器請求的原始資源的URI
TE	告知服務器客戶端能處理的編碼格式以及相對優先級
User-Agent	Http客戶端的信息，若是請求通過代理也可能會添加代理服務器的信息

注:形如If-xxx這樣的請求字段稱爲條件請求，服務器通常接收到附帶條件請求的URL，只有判斷條件成立後纔會執行請求

實體首部字段

針對請求報文和響應報文的實體部分使用的首部。補充了資源內容，更新時間等與實體相關的信息。

實體首部字段名	說明
Allow	通知客戶端能支持的HTTP的全部方法
Content-Encoding	通知客戶端服務器對實體的主體的編碼方式
Content-Language	通知客戶端實體主體的天然語言
Content-Length	實體主體的大小
Content-Location	表示報文返回資源的原始URI
Content-MD5	客戶端對接收到的報文主體執行相同的MD5算法，而後與字段中的值進行比較。（目的檢測傳輸過程實體主體是否保持完整）
Content-Range	實體主體返回的是資源的那部分位置範圍
Content-Type	實體主體的媒體類型
Expires	告知客戶端資源的有效截止日期
Last-Modified	告知客戶端資源的最後修改日期

其餘首部字段

自行擴展的，非標轉的首部字段

其餘首部字段名	說明
X-Frame-Options	控制網站內容在其餘web上用frame標籤內顯示的問題，主要防止點擊劫持攻擊
X-XSS-Protection	針對跨腳本攻擊的一種對策，用於控制瀏覽器XSS防禦機制的開關（0 無效 1 有效）
DNT	拒絕我的信息被收集，表示拒絕被精準廣告追蹤的一種方法，（0 贊成 1 拒絕）
P3P	在線隱私偏好系統

 
1. 處理預請求
 'Access-Control-Allow-Headers':'X-Test-Cors'//容許跨域的請求頭，能夠自定義
 'Access-Control-Allow-Methods': 'POST, PUT, Delete'//容許跨域的方式
 'Access-Control-Max-Age': '1000' //容許在一千秒內發起正式，不用發起預請求
2. CORS帶Cookie的跨域請求
 Access-Control-Allow-Origin:'*'
 //當設置爲*的時候，容許任何地方的跨域請求，但當帶有Cookie的時候，則報錯，並且，也至關不安全。
 //所以，須要設置成指定的要訪問的域。
    1.判斷接口是否帶cookie，若是帶cookie，則獲取請求頭部的origin的值(即訪問的域)
    而且加上「Access-Control-Allow-Credentials":"true"
3. Content-Type //傳輸的數據類型 (很重要)
        text/plain     
        multipart/form-data
        application/x-www-form-urlencoded

4. 可緩存
    public (任何地方)
    private（發起請求的地方）
    no-cache（驗證後是否使用本地緩存才能緩存）

5. 到期時間
    max-age=100 （緩存時間）
    s-maxage=100 (緩存時間[在代理服務器上用])
    max-stale=1000 （即便過去，也還能用，在規定時間範圍內）       

6. 從新驗證
    must-revalidate （在過時後，在服務端發送請求，從新獲取數據驗證是否真的過時）
    proxy-revalidate (在緩存服務器上使用)   

7. 其餘
    no-store (不用驗證，不能緩存，每次都要拿新的內容)
    no-transform (告訴代理服務器 不容許改動內容)

8. 資源驗證
    配合if-Match或者if-Non-Match使用對比資源的簽名判斷是否使用緩存
    //第一個修改信息時，把修改的內容發送到服務器，第二次請求的時候，會返回第一次的數值，而後跟如今的數值對比，若是有不同，證實修改了，須要從後臺拿數據

HTTP狀態碼

狀態碼的職責是當客戶端向服務器發送請求時，描述返回的請求結果，藉助狀態碼，能夠知道服務器端是正常處理了請求，仍是出現錯誤

狀態碼類別

code	類別	緣由短語
1XX	Informational(信息性狀態碼)	接收的請求正在處理
2XX	Success(成功狀態碼)	請求正常處理完畢
3XX	Redirection(重定向狀態碼)	須要進行附加操做以完成請求
4XX	Client Error(客戶端錯誤狀態碼)	服務器沒法處理請求
5XX	Server Error(服務器錯誤狀態碼)	服務器處理請求出錯

http狀態碼多達六十多種，但實際使用大概只有十四種左右

2XX

code	緣由短語
200	請求成功
204	請求成功，但無資源返回
206	請求成功，只是請求部分資源

3XX 重定向

code	緣由短語
301	永久性重定向資源地址更新，須要進行變動，（主要做用在書籤頁）
302	臨時性重定向資源地址更新，須要進行變動，（主要做用在書籤頁）
303	臨時性重定向使用get 方法獲取資源
304	資源找到了，但不符合條件請求，意思是:內容還沒更新，先使用客戶端內緩存的內容(非重定向)
404	服務器沒有找到該資源

4XX

code	緣由短語
400	沒法理解請求的內容(報文語法錯誤)
401	須要經過HTTP認證
403	被服務器拒絕訪問內容
404	資源找到了，但不符合條件請求，意思是:內容還沒更新，先使用客戶端內緩存的內容(非重定向)

5XX

code	緣由短語
500	服務器內部出現故障
503	服務器正忙(處於暫時超負載或者停機維護等，沒法處理請求)

爲Cookie服務的首部字段

是目前使用最普遍的Cookie標準，卻不是RFC中定義的任何一個

首部字段名	說明	首部類型
Set-Cookie	開始狀態管理所使用的Cookie信息	響應首部字段
Cookie	服務器接收到的Cookie信息	請求首部字段

HTTPS

HTTP缺點

通信使用明文(不加密) 內容可能會被竊聽（http自己不具有加密功能）
不驗證通訊方的身份，所以有可能遭遇假裝
沒法證實報文的完成性，因此有可能遭遇篡改

加密處理

通訊加密

HTTP協議中沒有加密機制，但能夠經過SSL(安全套接層)或者TLS(安全傳輸層協議)的組合，加密HTTP通訊內容

與SSL組合適用的HTTP稱爲HTTPS 超文本傳輸安全協議或者HTTP over SSL

內容加密

前提是要求客戶端和服務器同時具有加密和解密的機制

但因爲加密方式不一樣，報文主體被加密處理，但報文首部未被加密處理，因此仍然有被篡改的風險。

SSL

SSL是當今世界上應用最普遍的網絡安全技術

SSL才用一種叫作公開密鑰加密的加密處理方式。 公開密鑰加密使用一對非對稱的密鑰。一把叫作私有密鑰(不能讓任何人知道)，一把叫作公開密鑰(隨意發佈)。

混合加密機制

HTTPS才用共享密鑰加密和公開密鑰加密二者並用的混合加密機制。

認證的過程

證書

數字證書認證機構處於客戶端和服務器雙方均可信賴的第三方機構的立場。例如:威瑞信（VeriSign）
首先，服務器端提出公開密鑰申請，而後分配到已簽名的公開密鑰，並將密鑰放入公鑰證書（證書）
服務器將公鑰證書發送給客戶端，客戶端使用證書認證機構的公開密鑰，對證書的數字簽名進行驗證。

認證的步驟

前提:證書的認證主要在三次握手中完成。 1.瀏覽器實現有數字證書機構的公開密鑰。服務器有公鑰和私鑰

服務器用RSA生成公鑰和私鑰
把公鑰放在證書裏發送給客戶端，私鑰本身保存
客戶端首先向一個權威的服務器檢查證書的合法性，若是證書合法，客戶端產生一段隨機數，這個隨機數就做爲通訊的密鑰，咱們稱之爲對稱密鑰，用公鑰加密這段隨機數，而後發送到服務器
服務器用密鑰解密獲取對稱密鑰，而後，雙方就已對稱密鑰進行加密解密通訊了

PS:非對稱的RSA加密性能是很是低的，緣由在於尋找大素數、大數計算、數據分割須要耗費不少的CPU週期，因此通常的HTTPS鏈接只在第一次握手時使用非對稱加密，經過握手交換對稱加密密鑰，在以後的通訊走對稱加密。

瀏覽器將本身支持的一套加密規則發送給網站。
網站從中選出一組加密算法與HASH算法，並將本身的身份信息以證書的形式發回給瀏覽器。證書裏面包含了網站地址，加密公鑰，以及證書的頒發機構等信息。
瀏覽器得到網站證書以後瀏覽器要作如下工做：

驗證證書的合法性（頒發證書的機構是否合法，證書中包含的網站地址是否與正在訪問的地址一致等），若是證書受信任，則瀏覽器欄裏面會顯示一個小鎖頭，不然會給出證書不受信的提示。

若是證書受信任，或者是用戶接受了不受信的證書，瀏覽器會生成一串隨機數的密碼，並用證書中提供的公鑰加密。

使用約定好的HASH算法計算握手消息，並使用生成的隨機數對消息進行加密，最後將以前生成的全部信息發送給網站。
網站接收瀏覽器發來的數據以後要作如下的操做：

使用本身的私鑰將信息解密取出密碼，使用密碼解密瀏覽器發來的握手消息，並驗證HASH是否與瀏覽器發來的一致。

使用密碼加密一段握手消息，發送給瀏覽器。
瀏覽器解密並計算握手消息的HASH，若是與服務端發來的HASH一致，此時握手過程結束，以後全部的通訊數據將由以前瀏覽器生成的隨機密碼並利用對稱加密算法進行加密。

HTTP2

HTTP/2.0在2014年11月實現標準化，但目前大部分的網絡仍然使用HTTP/1.1協議

優點藉助Nginx

頭部壓縮、多路複用、Server Push(服務器推送)

頭部壓縮

HTTP/2 協議由兩個 RFC 組成：一個是 RFC 7540，描述了 HTTP/2 協議自己；一個是 RFC 7541，描述了 HTTP/2 協議中使用的頭部壓縮技術

多路複用

Keep-Alive 解決了同一域名下屢次請求的重複創建三次握手和四次揮手的問題。只須要創建一次HTTP請求便可。但仍然存在着 "串行傳輸問題"，以及併發問題由於瀏覽器限制，瀏覽器發起的最大請求數爲6。

HTTP/2引入二進制數據幀和流的概念，其中幀對數據進行順序標識

HTTP/2對同一域名下全部請求都是基於流，也就是說同一域名無論訪問多少文件，也只創建一路鏈接。一樣Apache的最大鏈接數爲300，由於有了這個新特性，最大的併發就能夠提高到300，比原來提高了6倍！

Server Push

服務端推送容許咱們向用戶發送一些尚未被訪問的資源

解決的問題:

內聯內容的服務器通訊

若樣式、腳本資源之外鏈及模塊形式引用，會更高效地進行緩存。當用戶訪問後續頁面須要這些資源時，能夠直接從緩存中獲取，從而省去了額外的資源請求

優化緩存行爲

當推送資源時，咱們能得到與內聯相同的性能提高，同時保持資源的外鍊形式，從而有獨立的緩存策略。

如何使用Server push

使用Server Push，一般會如下面的方式使用 Link 這個HTTP首部。

Link: </css/styles.css>; rel=preload; as=style

在進行 HTTP/2 網站性能優化時很重要一點是「使用盡量少的鏈接數」，本文提到的頭部壓縮是其中一個很重要的緣由：同一個鏈接上產生的請求和響應越多，動態字典積累得越全，頭部壓縮效果也就越好。因此，針對 HTTP/2 網站，最佳實踐是不要合併資源，不要散列域名。

之前咱們作的性能優化不適用於HTTP/2了

JS文件的合併。咱們如今優化的一個主要方向就是儘可能的減小HTTP的請求數，對咱們工程中的代碼，研發時分模塊開發，上線時咱們會把全部的代碼進行壓縮合並，合併成一個文件，這樣無論多少模塊，都請求一個文件，減小了HTTP的請求數。可是這樣作有一個很是嚴重的問題：文件的緩存。當咱們有100個模塊時，有一個模塊改了東西，按照以前的方式，整個文件瀏覽器都須要從新下載，不能被緩存。如今咱們有了HTTP/2了，模塊就能夠單獨的壓縮上線，而不影響其餘沒有修改的模塊。
多域名提升瀏覽器的下載速度。以前咱們有一個優化就是把css文件和js文件放到2個域名下面，這樣瀏覽器就能夠對這兩個類型的文件進行同時下載，避免了瀏覽器6個通道的限制，這樣作的缺點也是明顯的，1.DNS的解析時間會變長。2.增長了服務器的壓力。有了HTTP/2以後，根據上面講的原理，咱們就不用這麼搞了，成本會更低。