從輸入URL到頁面加載的過程

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. 引用計數
複製代碼