1.主干流程知識體系？

1. 從瀏覽器接收url到開啟網絡請求線程（這一部分可以展開瀏覽器的機制以及進程與線程之間的關系）2. 開啟網絡線程到發出一個完整的http請求（這一部分涉及到dns查詢，tcp/ip請求，五層因特網協議棧等知識）3. 從服務器接收到請求到對應后臺接收到請求（這一部分可能涉及到負載均衡，安全攔截以及后臺內部的處理等等）4. 后臺和前臺的http交互（這一部分包括http頭部、響應碼、報文結構、cookie等知識，可以提下靜態資源的cookie優化，以及編碼解碼，如gzip壓縮等）5. 單獨拎出來的緩存問題，http的緩存（這部分包括http緩存頭部，etag，catch-control等）6. 瀏覽器接收到http數據包后的解析流程（解析html-詞法分析然后解析成dom樹、解析css生成css規則樹、合并成render樹，然后layout、painting渲染、復合圖層的合成、GPU繪制、外鏈資源的處理、loaded和domcontentloaded等）7. CSS的可視化格式模型（元素的渲染規則，如包含塊，控制框，BFC，IFC等概念）8. JS引擎解析過程（JS的解釋階段，預處理階段，執行階段生成執行上下文，VO，作用域鏈、回收機制等等）9. 其它（可以拓展不同的知識模塊，如跨域，web安全，hybrid模式等等內容） 復制代碼

2.從瀏覽器接收url到開啟網絡請求線程

瀏覽器進程/線程模型，js的運行機制

• 多進程的瀏覽器
• 多線程的瀏覽器內核
• 瀏覽器內核

GUI 線程 JS引擎線程 事件觸發線程 定時器線程 網絡請求線程 復制代碼

3.開啟網絡線程到發出一個完整的http請求

dns查詢， tcp/ip請求構建等

• DNS查詢得到IP

dns解析成IP，大致流程 1. 如果瀏覽器有緩存，直接使用瀏覽器緩存，否則使用本機緩存，再沒有的話就是用host 2. 如果本地沒有，就向dns域名服務器查詢（當然，中間可能還會經過路由，也有緩存等），查詢到對應的IP 3. dns解析是很耗時的，因此如果解析域名過多，會讓首屏加載變得過慢，可以考慮dns-prefetch優化 復制代碼

• tcp/ip請求

三次握手的步驟：（抽象派） 客戶端：hello，你是server么？ 服務端：hello，我是server，你是client么 客戶端：yes，我是client四次揮手的步驟：（抽象派） 主動方：我已經關閉了向你那邊的主動通道了，只能被動接收了 被動方：收到通道關閉的信息 被動方：那我也告訴你，我這邊向你的主動通道也關閉了 主動方：最后收到數據，之后雙方無法通信 復制代碼

• tcp/ip的并發限制

瀏覽器對同一域名下并發的tcp連接是有限制的（2-10個不等） 而且在http1.0中往往一個資源下載就需要對應一個tcp/ip請求 所以針對這個瓶頸，又出現了很多的資源優化方案 復制代碼

4.http報文結構

通用頭部，請求/響應頭部，請求/響應體

• 通用頭部

Request Url: 請求的web服務器地址 Request Method: 請求方式 （Get、POST、OPTIONS、PUT、HEAD、DELETE、CONNECT、TRACE） Status Code: 請求的返回狀態碼，如200代表成功 Remote Address: 請求的遠程服務器地址（會轉為IP）狀態碼 200——表明該請求被成功地完成，所請求的資源發送回客戶端 304——自從上次請求后，請求的網頁未修改過，請客戶端使用本地緩存 400——客戶端請求有錯（譬如可以是安全模塊攔截） 401——請求未經授權 403——禁止訪問（譬如可以是未登錄時禁止） 404——資源未找到 500——服務器內部錯誤 503——服務不可用 復制代碼

• 請求/響應頭部

常用的請求頭部（部分）: 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：服務器的一些相關信息 復制代碼

5.http 2.0

多路復用（即一個tcp/ip連接可以請求多個資源） 首部壓縮（http頭部壓縮，減少體積） 二進制分幀（在應用層跟傳送層之間增加了一個二進制分幀層，改進傳輸性能，實現低延遲和高吞吐量） 服務器端推送（服務端可以對客戶端的一個請求發出多個響應，可以主動通知客戶端） 請求優先級（如果流被賦予了優先級，它就會基于這個優先級來處理，由服務器決定需要多少資源來處理該請求。） 復制代碼

6.https

6.1 https與http的區別就是： 在請求前，會建立ssl鏈接，確保接下來的通信都是加密的，無法被輕易截取分析

1. 瀏覽器請求建立SSL鏈接，并向服務端發送一個隨機數–Client random和客戶端支持的加密方法，比如RSA加密，此時是明文傳輸。 2. 服務端從中選出一組加密算法與Hash算法，回復一個隨機數–Server random，并將自己的身份信息以證書的形式發回給瀏覽器 （證書里包含了網站地址，非對稱加密的公鑰，以及證書頒發機構等信息） 3. 瀏覽器收到服務端的證書后- 驗證證書的合法性（頒發機構是否合法，證書中包含的網址是否和正在訪問的一樣），如果證書信任，則瀏覽器會顯示一個小鎖頭，否則會有提示- 用戶接收證書后（不管信不信任），瀏覽會生產新的隨機數–Premaster secret，然后證書中的公鑰以及指定的加密方法加密`Premaster secret`，發送給服務器。- 利用Client random、Server random和Premaster secret通過一定的算法生成HTTP鏈接數據傳輸的對稱加密key-`session key`- 使用約定好的HASH算法計算握手消息，并使用生成的`session key`對消息進行加密，最后將之前生成的所有信息發送給服務端。 4. 服務端收到瀏覽器的回復- 利用已知的加解密方式與自己的私鑰進行解密，獲取`Premaster secret`- 和瀏覽器相同規則生成`session key`- 使用`session key`解密瀏覽器發來的握手消息，并驗證Hash是否與瀏覽器發來的一致- 使用`session key`加密一段握手消息，發送給瀏覽器 5. 瀏覽器解密并計算握手消息的HASH，如果與服務端發來的HASH一致，此時握手過程結束，復制代碼

6.緩存

6.1 緩存可以簡單的劃分成兩種類型：強緩存（200 from cache）與協商緩存（304）

區別簡述如下： 強緩存（200 from cache）時，瀏覽器如果判斷本地緩存未過期，就直接使用，無需發起http請求 協商緩存（304）時，瀏覽器會向服務端發起http請求，然后服務端告訴瀏覽器文件未改變，讓瀏覽器使用本地緩存 對于協商緩存，使用Ctrl + F5強制刷新可以使得緩存無效 但是對于強緩存，在未過期時，必須更新資源路徑才能發起新的請求（更改了路徑相當于是另一個資源了，這也是前端工程化中常用到的技巧） 復制代碼

7.解析頁面

7.1 流程簡述

1. 解析HTML，構建DOM樹 2. 解析CSS，生成CSS規則樹 3. 合并DOM樹和CSS規則，生成render樹 4. 布局render樹（Layout/reflow），負責各元素尺寸、位置的計算 5. 繪制render樹（paint），繪制頁面像素信息 6. 瀏覽器會將各層的信息發送給GPU，GPU會將各層合成（composite），顯示在屏幕上 復制代碼

8.js引擎解析過程

8.1 流程簡述

1. 讀取代碼，進行詞法分析（Lexical analysis），然后將代碼分解成詞元（token） 2. 對詞元進行語法分析（parsing），然后將代碼整理成語法樹（syntax tree） 3. 使用翻譯器（translator），將代碼轉為字節碼（bytecode） 4. 使用字節碼解釋器（bytecode interpreter），將字節碼轉為機器碼 復制代碼

8.2 執行上下文

JS有執行上下文 瀏覽器首次載入腳本，它將創建全局執行上下文，并壓入執行棧棧頂（不可被彈出） 然后每進入其它作用域就創建對應的執行上下文并把它壓入執行棧的頂部 一旦對應的上下文執行完畢，就從棧頂彈出，并將上下文控制權交給當前的棧。 這樣依次執行（最終都會回到全局執行上下文） 復制代碼

8.3回收機制

1. 標記清除 2. 引用計數 復制代碼

轉載于:https://juejin.im/post/5d0dbbfaf265da1bcf5de4e7

總結

以上是生活随笔為你收集整理的从输入URL到页面加载的过程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。