http系列--從輸入 URL 到頁面加載完成的過程

時間 2019-11-06

標籤 http 系列輸入 url 頁面加載完成過程欄目 HTTP/TCP 简体版

原文原文鏈接

1、前言javascript

這道題的覆蓋面能夠很是廣，很適合做爲一道承載知識體系的題目。每個前端人員，若是要往更高階發展，必然會將本身的知識體系梳理一遍，沒有牢固的知識體系，沒法往更高處走！css

2、主幹流程html

在將瀏覽器渲染原理、JS運行機制、JS引擎解析流程梳理一遍後，感受就跟打通了任督二脈同樣，有了一個總體的架構，之前的知識點都連貫起來了。前端

一、從瀏覽器接收url到開啓網絡請求線程（涉及到：瀏覽器機制，線程和進程之間的關係等）java

二、開啓網絡線程到發出一個完整的http請求（涉及到：dns查詢，tcp/ip請求，5層網絡協議棧等）node

三、從服務器接收到請求到對應後臺接收到請求（涉及到：均衡負載，安全攔截，後臺內部的處理等）nginx

四、後臺和前臺的http交互（涉及到：http頭，響應碼，報文結構，cookie等，能夠提下靜態資源的cookie優化，以及編碼解碼如gzip壓縮等）web

五、緩存問題：http緩存（涉及到：涉及到http緩存頭部，etag，expired，cache-control等）算法

六、瀏覽器接收到http數據包後的解析流程（涉及到：html的詞法分析，而後解析成dom樹，同時解析css生成css規則樹，合併生成render樹。而後layout佈局、painting渲染、複合圖層的合成、GPU繪製、外連接處理、loaded和documentloaded等）數據庫

七、css可視化格式模型（涉及到：元素渲染規則，如：包含塊，控制框，BFC，IFC等概念）

八、js引擎解析過程（涉及到：js解釋階段，預處理階段，執行階段生成執行上下文，VO（全局對象），做用域鏈，回收機制等）

九、其餘（擴展其餘模塊：跨域，web安全等）

3、從瀏覽器接收到url到開啓網絡請求線程

涉及到：瀏覽器的進程和線程模型，js的運行機制。

一、瀏覽器是多進程的

（1）瀏覽器是多進程的；

（2）不一樣類型的標籤頁會開啓一個新的進程；

（3）相同類型的標籤頁會合併到一個進程中。

瀏覽器中各個進程以及做用：

一、瀏覽器進程：只有1個進程，（1）負責管理各個標籤的建立和銷燬；（2）負責瀏覽器頁面顯示；（3）負責資源的管理和下載；

二、第三方插件進程：能夠是多個進程，負責每個第三方插件的使用，每個第三方插件使用時候會建立一個對應的進程；

三、GPU進程：最多1個進程，負責3D繪製和硬件加速；

四、瀏覽器渲染進程：能夠是多個進程，瀏覽器的內核，每一個tab頁一個進程，主要負責HTML、，css，js等文件的解析，執行和渲染，以及事件處理等。

二、瀏覽器渲染進程（內核進程）

每個tab頁面是瀏覽器內核進程，而後這個每個進程是多線程的，它有幾大類子線程：

（1）GUI線程；（2）JS引擎線程；（3）事件觸發線程；（4）定時器線程；（5）異步的http網絡請求線程

能夠看出來JS引擎是內核進程中的一個線程，因此常說JS引擎時單線程的。

三、解析URL

輸入url後，會進行解析（URL是統一資源定位符）。

URL包括幾個部分：（1）protocol，協議頭，好比http，https，ftp等；（2）host，主機域名或者IP地址；（3）port，端口號；（4）path，目錄路徑；（5）query，查詢的參數；（6）fragment，#後邊的hash值，用來定位某一個位置。

四、網絡請求時單獨的線程

每一次網絡請求都是須要單獨開闢單獨的線程進行，好比URL解析到http協議，就會新建一個網絡線程去處理資源下載。

所以瀏覽器會根據解析出得協議，開闢一個網絡線程，前往請求資源。

4、開啓網絡線程到發出一個完整的http請求

包括：DNS查詢，tcp/ip請求構建，五層互聯網協議等等。

一、DNS查詢獲得IP

若是輸入的域名，須要DNS解析成IP，流程以下：

（1）瀏覽器有緩存，直接用瀏覽器緩存，沒有就去本機緩存，沒有就看是否是host。

（2）若是尚未，就向DNS域名服務器查詢（這個過程通過路由，路由也有緩存），查詢到對應的IP。

注意：一、域名查詢的時候有可能通過CDN調度器（若是CDN有存儲功能）；

二、DNS解析是很耗時的，所以若是解析域名過多，首屏加載會變慢，能夠考慮使用dns-prefetch優化。

二、tcp/ip請求構建

http的本質就是tcp/ip請求構建。須要3次握手規則簡歷鏈接，以及斷開鏈接時候的4次揮手。

tcp將http長報文劃分爲短報文，經過3次握手與服務端創建鏈接，進行可靠的傳輸。

3次握手步驟：

客戶端：hello，你是server麼？
服務端：hello，我是server，你是client麼
客戶端：yes，我是client

創建成功以後，接下來就是正式傳輸數據。

而後，等到斷開鏈接時，須要進行4次揮手（由於是全雙工的，因此須要4次握手）。

4次揮手步驟：

主動方：我已經關閉了向你那邊的主動通道了，只能被動接收了
被動方：收到通道關閉的信息
被動方：那我也告訴你，我這邊向你的主動通道也關閉了
主動方：最後收到數據，以後雙方沒法通訊

tcp/ip的併發限制

瀏覽器對同一域名下併發的tcp鏈接是有限制的（2-10個不等）。並且在http1.0中每每一個資源下載就須要對應一個tcp/ip請求。因此針對這個瓶頸，又出現了不少的資源優化方案。

get和post區別

get和post本質都是tcp/ip，可是除了http外層外，在tcp/ip層面也有區別。get會產生1個tcp數據包，post產生2個tcp數據包。

具體就是：

（1）get請求時，瀏覽器會把header和data一塊兒發送出去，服務器響應200（返回數據）。

（2）post請求時，瀏覽器首先發送headers，服務器響應100 continue，瀏覽器再發送data，服務器響應200（返回數據）。

三、五層網絡協議棧

客戶端發出http請求到服務器接收，中間會通過一系列的流程。

客戶端發送請求具體：從應用層發動http請求，到傳輸層經過三次握手簡歷tcp/ip鏈接，再到網絡層的ip尋址，再到數據鏈路層的封裝成幀，最後在物理層經過物理介質傳輸。

服務端接收請求具體：反過來。

五層網絡協議：

一、應用層（DNS，HTTP）：DNS解析成IP併發送http請求；

二、傳輸層（TCP，UDP）：創建TCP鏈接（3次握手）；

三、網絡層（IP，ARP）：IP尋址；

四、數據鏈路層（PPP）：封裝成幀；

五、物理層（利用物理介質傳輸比特流）：物理傳輸（經過雙絞線，電磁波等各類介質）。

其實也有一個完整的OSI七層框架，與之相比，多了會話層、表示層。

OSI七層框架：物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層、應用層

表示層：主要處理兩個通訊系統中交互信息的表示方式，包括數據格式交換，數據加密和解密，數據壓縮和終端類型轉換等。

會話層：具體管理不一樣用戶和進程之間的對話，如控制登陸和註銷過程。

5、從服務器接收請求到對應後臺接收到請求

服務端接收到請求時，內部會有不少處理。

包括：均衡負載，

一、負載均衡

對於大型項目，併發訪問很大，一臺服務器吃不消，通常會有若干臺服務器組成一個集羣，而後配合反向代理實現均衡負載。均衡負載不止一種實現方式。

歸納的說：用戶發送的請求指向調度服務器（反向代理服務器，好比nginx的均衡負載），而後調度服務器根據實際的調度算法，分配不一樣的請求給對應的集羣中的服務器執行，而後調度服務器等待實際服務器的HTTP響應，而且反饋給用戶。

二、後臺處理

通常後臺都部署到容器中。過程以下：

（1）先是容器接收到請求（好比tomcat容器）；

（2）而後對應容器中的後臺程序接收到請求（好比java程序）；

（3）而後就是後臺本身的統一處理，處理完畢後響應結果。

具體歸納一下：

（1）通常有的後端有統一的驗證，好比安全攔截，跨域驗證；

（2）若是不符合驗證規則，就直接返回相應的http報文（拒絕請求等）；

（3）若是驗證經過了，纔會進入到實際的後臺代碼，此時程序接收到請求，而後執行查詢數據庫，大量計算等等；

（4）等程序執行完畢後，會返回一個http響應包（通常這一步會通過多層封裝）；

（5）而後將這個數據包從後端返回到前端，完成交互。

6、後臺和前臺的http交互

先後端的交互，http報文做爲信息的載體。

一、http報文結構

報文通常包括：通用頭部，請求/響應頭部，請求/響應體

1.1 通用頭部

Request Url: 請求的web服務器地址

Request Method: 請求方式
（Get、POST、OPTIONS、PUT、HEAD、DELETE、CONNECT、TRACE）

Status Code: 請求的返回狀態碼，如200表明成功 Remote Address: 請求的遠程服務器地址（會轉爲IP）

好比跨區拒絕時，methord爲option，狀態碼404/405。

其中method分爲兩批次：

HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。 以及幾種Additional Request Methods：PUT、DELETE、LINK、UNLINK HTTP1.1定義了八種請求方法：GET、POST、HEAD、OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

好比有些狀態碼來判斷：

200——代表該請求被成功地完成，所請求的資源發送回客戶端 304——自從上次請求後，請求的網頁未修改過，請客戶端使用本地緩存 400——客戶端請求有錯（譬如能夠是安全模塊攔截） 401——請求未經受權 403——禁止訪問（譬如能夠是未登陸時禁止） 404——資源未找到 500——服務器內部錯誤 503——服務不可用

大體範圍

1xx——指示信息，表示請求已接收，繼續處理 2xx——成功，表示請求已被成功接收、理解、接受 3xx——重定向，要完成請求必須進行更進一步的操做 4xx——客戶端錯誤，請求有語法錯誤或請求沒法實現 5xx——服務器端錯誤，服務器未能實現合法的請求

1.2 請求頭/響應頭

經常使用的請求頭（部分）

Accept: 接收類型，表示瀏覽器支持的MIME類型
（對標服務端返回的Content-Type）
Accept-Encoding：瀏覽器支持的壓縮類型,如gzip等,超出類型不能接收
Content-Type：客戶端發送出去實體內容的類型
Cache-Control: 指定請求和響應遵循的緩存機制，如no-cache
If-Modified-Since：對應服務端的Last-Modified，用來匹配看文件是否變更，只能精確到1s以內，http1.0中 Expires：緩存控制，在這個時間內不會請求，直接使用緩存，http1.0，並且是服務端時間 Max-age：表明資源在本地緩存多少秒，有效時間內不會請求，而是使用緩存，http1.1中 If-None-Match：對應服務端的ETag，用來匹配文件內容是否改變（很是精確），http1.1中 Cookie: 有cookie而且同域訪問時會自動帶上 Connection: 當瀏覽器與服務器通訊時對於長鏈接如何進行處理,如keep-alive Host：請求的服務器URL Origin：最初的請求是從哪裏發起的（只會精確到端口）,Origin比Referer更尊重隱私 Referer：該頁面的來源URL(適用於全部類型的請求，會精確到詳細頁面地址，csrf攔截經常使用到這個字段) User-Agent：用戶客戶端的一些必要信息，如UA頭部等

經常使用的響應頭（部分）

Access-Control-Allow-Headers: 服務器端容許的請求Headers
Access-Control-Allow-Methods: 服務器端容許的請求方法
Access-Control-Allow-Origin: 服務器端容許的請求Origin頭部（譬如爲*）
Content-Type：服務端返回的實體內容的類型
Date：數據從服務器發送的時間 Cache-Control：告訴瀏覽器或其餘客戶，什麼環境能夠安全的緩存文檔 Last-Modified：請求資源的最後修改時間 Expires：應該在何時認爲文檔已通過期,從而再也不緩存它 Max-age：客戶端的本地資源應該緩存多少秒，開啓了Cache-Control後有效 ETag：請求變量的實體標籤的當前值 Set-Cookie：設置和頁面關聯的cookie，服務器經過這個頭部把cookie傳給客戶端 Keep-Alive：若是客戶端有keep-alive，服務端也會有響應（如timeout=38） Server：服務器的一些相關信息

通常來講，請求頭部和響應頭部是匹配分析的。

好比：

（1）請求頭部的Accept要和響應頭部的Content-Type匹配，不然會報錯；

（2）跨域請求中，請求頭部的Origin要匹配響應頭的Access-Control-Allow-Origin，不然會報跨域錯誤；

（3）使用緩存，請求頭部的if-modified-since，if-none-match分別和響應頭的Last-modified，etag對應。

1.3 請求/響應實體

http請求時，除了頭部，還有消息實體。

請求實體中會將一些須要的參數都放入進入（用於post請求）。

好比：（1）實體中能夠放參數的序列化形式（a=1&b=2這種），或者直接放表單（Form Data對象，上傳時能夠夾雜其餘以及文件）等等。

響應實體中，就是服務端須要傳給客戶端的內容。

通常如今的接口請求時，實體中就是對應信息的json格式，而像頁面請求這種，裏面就是直接放一個html的字符串，而後瀏覽器本身解析並渲染。

1.4 CRLF

CRLF（Carriage-Return Line-Feed），意思是回車換行，通常做爲分隔符存在。

請求頭和實體消息之間有一個CRLF分隔，響應頭部和響應實體之間用一個CRLF分隔。

下圖是對某請求的http報文結構的簡要分析：

二、 cookie以及優化

cookie是瀏覽器的一種本地存儲方式，通常用來幫助客戶端和服務端通訊的，經常使用來進行身份校驗，結合服務端的session使用。

在登錄頁面，用戶登錄了

此時，服務端會生成一個session，session中有對於用戶的信息（如用戶名、密碼等）

而後會有一個sessionid（至關因而服務端的這個session對應的key）

而後服務端在登陸頁面中寫入cookie，值就是:jsessionid=xxx

而後瀏覽器本地就有這個cookie了，之後訪問同域名下的頁面時，自動帶上cookie，自動檢驗，在有效時間內無需二次登錄。

通常來講，cookie是不容許存放敏感信息的（千萬不要明文存儲用戶名、密碼），由於很是不安全，若是必定要強行存儲，首先，必定要在cookie中設置httponly（這樣就沒法經過js操做了），另外能夠考慮rsa等非對稱加密（由於實際上，瀏覽器本地也是容易被攻克的，並不安全）

好比這樣的場景：

客戶端在域名A下有cookie（這個能夠是登錄時由服務端寫入的）

而後在域名A下有一個頁面，頁面中有不少依賴的靜態資源（都是域名A的，譬若有20個靜態資源） 此時就有一個問題，頁面加載，請求這些靜態資源時，瀏覽器會默認帶上cookie 也就是說，這20個靜態資源的http請求，每個都得帶上cookie，而實際上靜態資源並不須要cookie驗證 此時就形成了較爲嚴重的浪費，並且也下降了訪問速度（由於內容更多了）

固然了，針對這種場景，是有優化方案的（多域名拆分）。具體作法就是：

（1）將靜態資源分組，分別放到不一樣的域名下（如static.base.com）

（2）而page.base.com（頁面所在域名）下請求時，是不會帶上static.base.com域名的cookie的，因此就避免了浪費

說到多域名拆分，還有一個問題？

（1）在移動端，若是請求的域名數過多，會下降請求速度（由於域名整套解析流程很浪費時間，並且移動端通常帶寬比不上PC）。

（2）這時候有個優化方案：dns-prefetch（這個是幹嗎的？就是讓瀏覽器空閒時提早解析dns域名，不過請合理使用）

關於cookie的交互，能夠看下圖總結

三、gzip壓縮

首先，gzip是請求頭裏的Accept-Encoding：瀏覽器支持的壓縮類型之一。gzip是一種壓縮格式，須要瀏覽器支持纔有效（通常瀏覽器都支持），並且gzip的壓縮率很好（高達70%）；

而後gzip通常是apach，nginx，tomcat等web服務器開啓。

除了gzip的壓縮格式，還有deflate，沒有gzip高效，不流行。

因此通常只須要在服務器上開啓gzip壓縮，而後以後的請求都是基於gzip壓縮格式的，很是方便。

四、長鏈接和短鏈接

首先咱們看一下tcp/ip的定義：

（1）長鏈接：一個tcp/ip鏈接上能夠連續發送多個數據包，tcp鏈接保持期間，若是乜有數據包發送，須要雙方發檢測包以維持此鏈接，通常須要本身作在線維持（相似於心跳包）。

（2）短鏈接：通訊雙方有數據交互是，簡歷一個tcp鏈接，數據發送完成後，則斷開此tcp鏈接。

咱們再看一下http層面上：

（1）http1.0中，默認是使用的短鏈接，瀏覽器每進行一次http操做，就創建一次鏈接，任務結束就中斷鏈接，好比每個靜態資源請求都是一個單獨的鏈接

（2）http1.1開始，默認是使用長鏈接，長鏈接會設置connection: keep-alive，在長鏈接的狀況下，當一個網頁打開後，客戶端和服務端之間用於傳輸http的tcp鏈接不會關閉，若是客戶端再次訪問服務器這個頁面，會繼續使用這一條已經創建起來的鏈接。

注意：kee-alive不會永遠保持，他有一個持續時間，通常服務中進行配置，另外長鏈接是須要客戶端和服務器端都支持纔有效。

五、http2.0

http2.0不是https，它至關於http的下一代規範（https也多是http2.0規範）

比較一下http1.1和http2.0顯著不一樣地方：

（1）http1.1中，每請求一個資源，都是須要開啓一個tcp/ip鏈接的，因此對應的結果是：每個資源對應一個tcp/ip請求，因爲tcp/ip自己有個併發數的限制，資源一旦多了，速度會降低慢下來。

（2）http2.0中，一個tcp/ip請求能夠請求多個資源，也就說，只要一次tcp/ip請求，就能夠請求多個資源，分隔成更小的幀請求，速度明顯提高。

因此，若是http2.0全面應用的，不少http1.1中的優化方案無需用到（好比：精靈圖，靜態組員多域名拆分等）。

如今介紹一下http2.0的一些特性：

（1）多路複用（一個tcp/ip能夠請求多個資源）；

（2）首部壓縮（http頭部壓縮，減小體積）；

（3）二進制分幀（在應用層跟傳輸層之間增長一個二進制分幀層，改進傳輸性能，實現低延遲和高吞吐）；

（4）服務器端推送（服務端能夠對客戶端的一個請求發出多個響應能夠主動通知客戶端）；

（5）請求優先級（若是流被賦予了優先級，就會基於這個優先級來處理，有服務器決定須要多少資源來處理該請求）

六、https

https就是安全版本的http，好比一些支付操做服務基本上都是基於https的，由於http請求的安全係數過低了。

簡單來看，https和http區別是：在請求前，會創建ssl連接，確保接下來的通訊都是加密的，沒法輕易截取分析。

通常來講，須要將網站升級到https，須要後端支持（後端須要申請證書等），而後https的開銷比http大（由於要額外的簡歷安全連接和加密等），因此通常來講http2.0配合https的體驗更佳（http2.0更快）。

主要關注的就是SSL/TLS的握手流程，以下（簡述）：

（1）瀏覽器請求創建SSL連接，並向服務端發送一個隨機數（client random）和客戶端支持的加密方法，好比是RSA加密，此時是明文傳輸。

（2）服務端從中選出一組加密算法和hash算法，回覆一個隨機數（server random），並將本身的身份信息以證書的形式發回給瀏覽器（證書中包含了網站地址，非對稱加密的公鑰，以及證書頒發機構等信息）。

（3）瀏覽器收到服務端證書後：

一、首先驗證證書的合法性（頒發機構是否合法，證書包含的網站是否和正在訪問的同樣），若是證書信任，瀏覽器會顯示一個小頭鎖，不然會有提示。

二、用戶接受到證書後（無論信任不信任），瀏覽器會產生一個新的隨機數（Premaster secret），而後證書中的公鑰以及制定的加密方法加密`Premaster secret`（預主密碼），發送給服務器。

三、利用client random，server random 和 premaster secret 經過必定的算法生成HTTP連接數據傳輸的對稱加密key-‘sessionkey’

四、使用約定好的hash算法計算握手消息，並使用生成的session key 對消息進行加密，最後將以前生成的全部信息發送給服務端。

（4）服務端收到瀏覽器的回覆

一、利用已知的加密方式與本身的私鑰進行解密，獲取Premaster secret，

二、和瀏覽器相同規則生成session key，

三、使用session key 解密瀏覽器發來的握手消息，並驗證hash是否與瀏覽器發來的一致，

四、使用session key 加密一段握手消息，發送給瀏覽器

（5）瀏覽器解密並計算握手消息的hash值，若是與服務端發來的hash一致，此時握手結束。

以後全部的https通訊數據將由以前瀏覽器生成的session key並利用對稱加密算法進行加密

7、緩存問題：http緩存

http交互中，緩存很大程度上提高效率。

一、強緩存與弱緩存

緩存能夠簡單劃分爲兩種類型：強緩存（200 from cache）與協商緩存（304）；

區別簡介一下：

（1）強緩存（200 from cache）時，瀏覽器若是判斷本地緩存未過時，就直接使用，無需發起http請求。

（2）協商緩存（304）時，瀏覽器會向服務器發起http請求，而後服務端告訴瀏覽器文件未改變，讓瀏覽器使用戶本地緩存。

對於協商緩存，可使用ctrl + F5強制刷新，使得協商緩存無效。

對於強制緩存，在未過時，必須更新資源路徑才能發送新的請求。

二、緩存頭部簡述

怎麼在代碼中區分強緩存和協商緩存？

經過不一樣的http的頭部控制。

屬於強制緩存的：

（http1.1）Cache-Control/Max-Age （http1.0）Pragma/Expires

注意：cache_control的值：public，private，no-store，no-cache，max-age

屬於協商緩存的：

（http1.1）If-None-Match/E-tag （http1.0）If-Modified-Since/Last-Modified

再提一點，其實HTML頁面中也有一個meta標籤能夠控制緩存方案-Pragma

<META HTTP-EQUIV="Pragma" CONTENT="no-cache">

不過，這種方案仍是比較少用到，由於支持狀況不佳，譬如緩存代理服務器確定不支持，因此不推薦。

三、緩存頭部區別

在http1.1中，出現了一些新內容，彌補http1.0不足。

http1.0中的緩存控制:

（1）Pragma：嚴格來講不算緩存控制的頭部，設置了no-cache會讓本地緩存失效（屬於編譯控制，來實現特定的指令）。

（2）Expires：服務端配置，屬於強緩存，用來控制在規定的時間以前，瀏覽器不會發送大量請求，而直接使用本地緩存，注意：Expires通常對應服務器端時間，好比：Expires：Fri, 30 Oct 1998 14:19:41

（3）If-Modified-Since/Last-modified：這兩個是成對出現的，屬於協商緩存。其中瀏覽器頭部是If-Modified-Since，而服務端是Last-Modified，發送請求時，若是這兩個匹配成功，表明服務器資源並無改變，服務端不會返回資源實體，而是返回頭部，告知瀏覽器使用本地緩存。Last-modifed指文件最後的修改時間，只能精確到1S之內。

http1.1中緩存的控制：

（1）cache-control ：緩存的控制頭部，有nocache，max-age等多個取值。

（2）Max-Age：服務端配置的，用來控制強緩存的，在規定的時間內，瀏覽器不用發出請求，直接使用本地的緩存。Max-Age是cache-control的值，好比：cache-control: max-age=60*1000，值是絕對時間，瀏覽器本身計算。

（3）If-None-Match/E-tag：這兩個是成對的出現的，屬於協商緩存，其中瀏覽器頭部是If-None-Match，而服務端是E-tag，一樣，發出請求後，若是If-None-Match和E-tag匹配，表明內容沒有變化，告訴瀏覽器使用本地緩存，和Last-modified不一樣，E-tag更精確，它相似於指紋同樣，基於FileEtag INode Mtime Size生成的，就是說文件變，指紋就會變，沒有精確度的限制。

Cache-Control相比Expires？

一、都是強制緩存。

二、Expires使用服務端時間，由於存在時區，和瀏覽器本地時間能夠修改問題，在http1.1不推薦使用Expires；Cache-Control的Max-Age是瀏覽器端本地的絕對時間。

三、同時使用Cache-Control和Expires，Cache_control優先級高。

E-tag相比Last-Modified？

一、都是協商緩存。

二、Last-modified指的是服務端文件最後改變時間，缺陷是精確只能到1s，文件週期性的改變，致使緩存失效；E-tag是一種指紋機制，文件指紋，只要文件改變，E-tag馬上變，沒有精度限制。

三、帶有E-tag和Last-modified時候，E-tag優先級高。

各大緩存頭部的總體關係以下圖

8、解析頁面流程

前面提到是http交互，接下來是瀏覽器獲取到html，而後解析，渲染。

一、流程簡述

瀏覽器內核拿到內容後，渲染大體分爲如下幾步：

（1）解析html，構建DOM樹；同時解析CSS，生成CSS規則樹。

（2）合併DOM樹和CSS規則樹，生成Render樹。

（3）佈局Render樹（layout/reflow）,負責各元素的尺寸，位置計算。

（4）繪製render樹（paint），繪製頁面像素信息。

（5）瀏覽器會將各層的信息發給GPU。GPU會將各層合成（composite），顯示在屏幕上。

以下圖：

二、html解析，構建DOM

這一步的流程是這樣的：瀏覽器解析HTML，構建DOM樹。實際上，稍微展開一下。

解析html到構建dom過程簡述以下：

Bytes -> characters -> tokens -> nodes ->DOM

好比，有這樣一個html頁面：

<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <link href="style.css" rel="stylesheet">
    <title>Critical Path</title>
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg"></div>
  </body>
</html>

瀏覽器的處理以下：

列舉一下其中一些重點過程：

1. Conversion轉換：瀏覽器將得到的HTML內容（Bytes）基於他的編碼轉換爲單個字符 2. Tokenizing分詞：瀏覽器按照HTML規範標準將這些字符轉換爲不一樣的標記token。每一個token都有本身獨特的含義以及規則集 3. Lexing詞法分析：分詞的結果是獲得一堆的token，此時把他們轉換爲對象，這些對象分別定義他們的屬性和規則 4. DOM構建：由於HTML標記定義的就是不一樣標籤之間的關係，這個關係就像是一個樹形結構同樣 例如：body對象的父節點就是HTML對象，而後段略p對象的父節點就是body對象

最後的DOM樹：

三、css解析，構建css規則樹

CSS規則樹的生成也是相似

Bytes → characters → tokens → nodes → CSSOM

好比：style.css內容以下：

body { font-size: 16px } p { font-weight: bold } span { color: red } p span { display: none } img { float: right }

最終的CSSOM樹就是

四、構建渲染樹

當DOM樹和CSSOM都有了後，就要開始構建渲染樹了。通常來講，渲染樹和DOM樹相對應的，但不是嚴格意義上的一一對應。

由於有一些不可見的DOM元素不會插入到渲染樹中，如head這種不可見的標籤或者display: none等

五、渲染

有了render樹，接下來就是開始渲染，基本流程以下：

圖中重要的四個步驟就是：

（1）計算CSS樣式；

（2）構建渲染樹；

（3）佈局，主要定位座標和大小，是否換行，各類position overflow z-index屬性；

（4）繪製，將圖像繪製出來。

而後，圖中的線與箭頭表明經過js動態修改了DOM或CSS，致使了從新佈局（Layout）或渲染（Repaint）

這裏Layout和Repaint的概念是有區別的：

（1）Layout，也稱爲Reflow，即迴流。通常意味着元素的內容、結構、位置或尺寸發生了變化，須要從新計算樣式和渲染樹。

（2）Repaint，即重繪。意味着元素髮生的改變只是影響了元素的一些外觀之類的時候（例如，背景色，邊框顏色，文字顏色等），此時只須要應用新樣式繪製這個元素就能夠了。

迴流的成本開銷要高於重繪，並且一個節點的迴流每每回致使子節點以及同級節點的迴流，因此優化方案中通常都包括，儘可能避免迴流。

六、什麼引發迴流

1.頁面渲染初始化 2.DOM結構改變，好比刪除了某個節點 3.render樹變化，好比減小了padding 4.窗口resize 5.最複雜的一種：獲取某些屬性，引起迴流， 不少瀏覽器會對迴流作優化，會等到數量足夠時作一次批處理迴流， 可是除了render樹的直接變化，當獲取一些屬性時，瀏覽器爲了得到正確的值也會觸發迴流，這樣使得瀏覽器優化無效，包括 （1）offset(Top/Left/Width/Height) (2) scroll(Top/Left/Width/Height) (3) cilent(Top/Left/Width/Height) (4) width,height (5) 調用了getComputedStyle()或者IE的currentStyle

迴流必定伴隨着重繪，重繪卻能夠單獨出現。

優化方案：

（1）減小逐項更改樣式，作好一次性更改樣式。或者將樣式定義爲class，並一次性更新。

（2）避免循環操做dom，建立一個documentFragment或div，在他上面進行全部的dom操做，最後添加到window.document中。

（3）避免屢次讀取offset等屬性，沒法避免就將他們緩存到變量中。

（4）將複雜的元素絕對定位或者固定定位，使他們脫離文檔流，不然迴流代價很高。

注意：改變字體大小會引發迴流。

再看一個例子：

var s = document.body.style; s.padding = "2px"; // 迴流+重繪 s.border = "1px solid red"; // 再一次 迴流+重繪 s.color = "blue"; // 再一次重繪 s.backgroundColor = "#ccc"; // 再一次 重繪 s.fontSize = "14px"; // 再一次 迴流+重繪 // 添加node，再一次 迴流+重繪 document.body.appendChild(document.createTextNode('abc!'));