從前端小白到中高級前端須要掌握的技能總結（2）

這個系列的文章的第二篇，繼續總結~~

這是從一個問題上衍生出的知識體系，這個問題是
從輸入URL到頁面加載的過程。
先梳理下這個流程

第一步

從瀏覽器接收url到開啓網絡請求線程（瀏覽器的進程/線程模型，js的運行機制）

瀏覽器的進程

瀏覽器是多進程的。有一個主進程，以及每個tab頁都會新開一個進程（某些狀況下（好比空白tab）多個tab會合併成一個進程）
進程可能包括主進程，插件進程，GPU，tab頁等等。

• brower進程

主進程，負責協調，主控等

• 第三方插件進程

每種類型的插件都會有一個進程，僅當使用插件時纔會建立。

• GPU進程

只有一個，用於3d繪製

• 瀏覽器默認進程(內核)

每一個tab頁對應一個進程，負責頁面渲染，腳本執行，互不影響，有時候會優化（多個空白tab會合併成一個）

瀏覽器的多線程內核

每一個tab頁能夠看做瀏覽器的內核的進程，這個進程是多線程的，它有如下幾大線程:

• GUI渲染線程
• JavaScript線程(這就是爲何一直說JS是單線程的緣由)
• 事件觸發線程
• 定時器觸發線程
• 網絡請求線程

每次網絡請求都須要開闢單獨線程進行，若是url解析到http請求，就會新開線程去處理資源下載。（http2.0能夠實現tcp鏈接複用）

JS的運行機制

參考個人另外一篇文章
js執行機制 事件循環

第二步

開啓網絡線程到發出一個完整的http請求（dns查詢，tcp/IP請求，五層因特網協議棧等知識）

DNS查詢IP

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

• 若是瀏覽器有緩存，就直接使用瀏覽器的緩存，若是沒有，就使用本地的緩存
• 若是本地也沒有緩存，就用host，再沒有的話就向DNS服務器查詢（中間路由有緩存的話，能夠用路由緩存等）IP

dns查詢是很耗時的，若是解析域名過多，會讓首屏加載變慢，能夠用dns-prefetch優化

tcp/IP請求

http的本質就是tcp/ip請求
這部分須要瞭解三次握手和斷開鏈接時的四次揮手。

三次握手

tcp將http的長報文分爲短報文，經過三次握手創建鏈接，進行傳輸數據。

1. 客戶端：hi，我是客戶端,你是服務器嗎
2. 服務器: hi，我是服務器,你是客戶端嗎
3. 客戶端: 對，我是客戶端

創建鏈接成功後，就能夠開始傳輸數據啦~~

四次揮手

1. 主動方: hi，我要斷開鏈接啦，我只能被動接收數據了
2. 被動方: hi, 我收到啦
3. 被動方: hi，我也要斷開鏈接啦
4. 主動方：好的，我被動接收數據的鏈接也關掉了。

以後就斷開了鏈接，沒法通訊。

tcp/ip的併發限制

瀏覽器對同一域名下的併發的tcp鏈接是有限制的（2-10個不等），並且在http2.0以前，一個資源下載就須要一個tcp/ip請求。

get/post的區別

get和post本質上雖然都是tcp/ip，可是除了在http層面外，在tcp/ip層面也有區別的，get只會產生一個數據包（把headers和data一塊兒發出去）,post請求會發送兩個數據包(先發送headers,收到100以後會再發data)

五層因特網協議棧

從客戶端發出http請求到服務器接收，中間會通過一系列的流程.簡單歸納就是：
從應用層發送http請求，到傳輸層經過三次握手創建tcp/ip鏈接，再到網絡層ip尋址，再到數據鏈路層的封裝成幀，最後到物理層的利用物理介質傳輸.
還有一個完整的OSI七層框架，多了會話層和表示層
會話層：管理不一樣用戶和進程之間的對話，好比控制登陸和登出
表示層: 處理兩個通訊系統中交換信息的表示方式，包括數據格式的交換，數據加密與解密，數據壓縮等。

第三步

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

負載均衡

對於大型項目來講，併發訪問量是很大的，這種狀況下一臺服務器確定是不夠的，因此通常會有若干個服務器組成一個集羣，配合反向代理實現負載均衡。
用戶發起請求都指向調度服務器，而後調度服務器根據實際的調度算法，分配不一樣的請求給對應的集羣中的服務器執行，而後調度器等待實際服務器的http響應，再返回給瀏覽器

安全攔截

後臺通常都會加攔截器，安全攔截驗證，跨域驗證等等

第四步

1. 前臺和後臺的交互（http頭部，響應碼，報文結構，cookie等 ,gzip壓縮等）

http頭部

這部分包括三個部分

通用頭部

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

Request Method: 請求方式(GET,POST,HEAD,OPTIONS,PUT,DELETE,CONNECT,TRACE)
(http1.0定義了三種請求方法，GET,POST,HEAD，http1.1新增了5種方法，OPTIONS,PUT,DELETE,CONNECT,TRACE)

Status Code: 請求返回的狀態碼

Remote Address: 請求的遠程服務器的地址(會轉成IP)

請求頭部

Accept: 接收類型，表示瀏覽器支持的MIME((Multipurpose Internet Mail Extensions) 是描述消息內容類型的因特網標準)類型,對應服務端返回的的content-type

Accept-Encoding:瀏覽器支持的壓縮格式，如gzip

Content-Type: 瀏覽器發出去的實體內容的類型

Cache-Control: 指定請求和返回的緩存機制，如no-cache

If-Modify-Since: 對應服務端的Last-Modified,用來匹配文件是否變更，是否使用緩存，只能精確到1s內，是http1.0的

Expires: 在這個時間內使用緩存，http1.0

Max-age: 表明資源在本地緩存多少秒，有效時間內使用緩存

If-none-Match： 對應服務端的Etag,用來匹配文件內容是否改變

Cookie：有cookie而且同域訪問時會帶上

Connection: 服務端和客戶端通訊鏈接方式，keep-alive，表示使用長鏈接（數據傳輸完成了保持TCP鏈接不斷開（不發RST包、不四次揮手），客戶端的長鏈接不可能無限期的拿着，會有一個超時時間，服務器有時候會告訴客戶端超時時間，若是服務器沒有告訴客戶端超時時間也不要緊，服務端可能主動發起四次揮手斷開TCP鏈接，客戶端可以知道該TCP鏈接已經無效；另外TCP還有心跳包來檢測當前鏈接是否還活着）

Host：請求的服務器URL

Origin: 最初的請求是哪裏發起的，只會精確到端口

Referer: 該頁面的來源，會精確到頁面地址，csrf攔截經常使用到這個字段

User-Agent:用戶客戶端的一些信息，如瀏覽器信息

響應頭部

Access-Control-Allow-Headers: 服務器容許的請求的headers

Access-Control-Allow-Methods: 服務器容許請求的方法

Access-Control-Allow-Origin: 服務器容許的請求的origin

Content-Type：服務器返回的實體內容的類型

date：數據從服務端發起的時間

cache-control：告訴客戶端緩存機制

Last-modified: 請求資源的最後修改時間

Expires：告知客戶端在這個時間內使用緩存

Max-age：告知客戶端在本地緩存多少秒

Etag：請求資源的標識，表示資源是否改變

Set-cookie:設置和頁面相關聯的cookie，服務器經過這個頭部把cookie傳給客戶端

keep-alive:若是客戶端設置了keep-alive，服務端會有相應的響應，好比timeout=20

Server：服務器的信息。好比Apache

響應碼

不一樣範圍的狀態的意義

• 1xx---請求已被接收，繼續處理
• 2xx---請求已被接受，理解
• 3xx---重定向，完成操做須要進一步的處理
• 4xx---客戶端錯誤（參數錯誤，語法錯誤或者請求沒法實現）
• 5xx---服務端錯誤

常見的狀態碼

• 200---請求已被接收併成功返回客戶端
• 302---重定向
• 304---用瀏覽器的緩存
• 400---客戶端請求有誤，請求參數有誤等
• 401---請求沒有權限
• 403---禁止訪問(好比未登陸時禁止)
• 404---找不到資源
• 500---服務器內部錯誤
• 503---服務不可用

cookie

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

簡單說下使用場景：

1. 用戶登陸
2. 服務端收到請求，生成session,會有用戶的信息
3. 生成一個sessionid
4. 服務端在登陸頁面寫入cookie
5. 瀏覽器就有這個cookie了，訪問同域名的時候都會自動帶上這個cookie

gzip

gzip的壓縮效率很高，高達70%以上，具體能夠參考我另外一篇文章前端性能優化之gzip

第五步

1. 緩存問題（http緩存，緩存頭部，etag，cache-control等）

緩存這部分能夠參考我另外一篇文章
瀏覽器緩存機制分析

1. 瀏覽器接收到http數據包後的解析過程（解析html，詞法分析解析成dom樹，解析css生成css規則樹，合併成render樹，而後佈局，繪製渲染，複合圖層的合成，GPU繪製，外鏈資源的處理，loaded和domcontentloaded等）

複合層，合成層，GPU，硬件提速請參考這篇文章 https://juejin.im/entry/59dc9...

1. css的可視化模型（元素的渲染規則，如包含塊，控制框，BFC,IFC等概念）

BFC部分能夠參考這篇筆記
BFC

1. JS引擎解析過程（JS的解釋階段，預處理階段，執行階段生成上下文，VO，做用域鏈，回收機制等）

JS執行機制部分可參考這篇文章
js執行機制

總的來講，知識要點就是如下這些~~

核心知識

瀏覽器模型

瀏覽器的進程和線程

渲染原理

構建dom樹，css樹，render樹，reflow，repaint，複合層和簡單層，GPU渲染

JS解析過程

字節-> 分詞 -> 語法樹 -> 解析成機器碼

JS運行機制

變量提高，函數提高，VO, AO, this

重點知識

http相關

http1.0 http1.1 http2.0，https
http2.0的主要新特性

1. 多路複用（一個tcp/ip鏈接能夠請求多個資源）
2. 首部壓縮(http頭部壓縮，減小體積)
3. 二進制分幀（在應用層和傳輸層多了一層二進制分幀層，改進了傳輸性能，實現低延遲和高吞吐量）
4. 服務端推送(服務端對客戶端的一個請求能夠發出多個響應，能夠主動通知客戶端)

https就是創建在http基礎上，在請求前先創建ssl鏈接，確保接下來的通訊都是加密的，沒法被竊取。

下面簡單說下SSL/TLS握手流程:

1. 瀏覽器請求創建ssl鏈接，並向服務端發送一個隨機數client random和客戶端支持的加密方法，好比RSA加密，此時是明文傳輸
2. 服務端從中選出一組加密算法與hash算法，回覆一個隨機數server random，並將本身的身份信息以證書的形式發給瀏覽器（包括網站地址，非對稱加密的公鑰，證書的頒發機構等）

3. 瀏覽器收到服務端發的證書後

   • 驗證證書的合法性（頒發機構是否合法，證書中的網址是否和所在的網址相同），若是證書信任，瀏覽器前面會出現一個小鎖的圖標
   • 用戶接收證書後（無論信不信任），瀏覽器會生成一個新的隨機數premaster-key，而後用證書中的公鑰和指定的加密方式加密premaster-key，發送給服務端

• 利用client random，server random和premaster-key經過必定的算法能夠生成一個http鏈接傳輸的對稱加密session key
• 使用約定好的hash算法計算握手消息，並使用生成的session key加密，將以前生成的全部信息發送給服務端

1. 服務端接收到瀏覽器的回覆

• 利用已知的加解密方式和本身的私鑰解密客戶端發來的信息，獲取premaster-key
• 和瀏覽器相同的規則生成session key
• 使用session key解密瀏覽器發來的握手信息，並驗證hash是否與瀏覽器發來的一致
• 使用session key加密一段握手信息，發送給瀏覽器

1. 瀏覽器解密服務端發來的握手信息的hash，若是與服務端發來的hash一致，則這次握手結束。

web安全相關（xss，csrf）

xss 跨站腳本攻擊
csrf 跨站請求僞造

跨域及處理

跨域處理參考這個系列的前一篇文章~~
從前端小白到中高級前端須要掌握的技能總結（1）