摘要：這個系列的文章的第二篇，繼續總結這是從一個問題上衍生出的知識體系，這個問題是從輸入到頁面加載的過程。先梳理下這個流程第一步從瀏覽器接收到開啟網絡請求線程瀏覽器的進程線程模型，的運行機制瀏覽器的進程瀏覽器是多進程的。

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

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

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

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

brower進程

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

第三方插件進程

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

GPU進程

只有一個，用于3d繪制

瀏覽器默認進程(內核)

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

每個tab頁可以看作瀏覽器的內核的進程，這個進程是多線程的，它有以下幾大線程:

GUI渲染線程

JavaScript線程(這就是為什么一直說JS是單線程的原因)

事件觸發線程

定時器觸發線程

網絡請求線程

每次網絡請求都需要開辟多帶帶線程進行，如果url解析到http請求，就會新開線程去處理資源下載。（http2.0可以實現tcp連接復用）

參考我的另一篇文章
js執行機制 事件循環

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

如果輸入的是域名，需要DNS解析成IP，過程如下：

如果瀏覽器有緩存，就直接使用瀏覽器的緩存，如果沒有，就使用本地的緩存

如果本地也沒有緩存，就用host，再沒有的話就向DNS服務器查詢（中間路由有緩存的話，可以用路由緩存等）IP

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

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

tcp將http的長報文分為短報文，通過三次握手建立連接，進行傳輸數據。

客戶端：hi，我是客戶端,你是服務器嗎

服務器: hi，我是服務器,你是客戶端嗎

客戶端: 對，我是客戶端

建立連接成功后，就可以開始傳輸數據啦~~

主動方: hi，我要斷開連接啦，我只能被動接收數據了

被動方: hi, 我收到啦

被動方: hi，我也要斷開連接啦

主動方：好的，我被動接收數據的連接也關掉了。

之后就斷開了連接，無法通信。

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

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

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

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

對于大型項目來說，并發訪問量是很大的，這種情況下一臺服務器肯定是不夠的，所以一般會有若干個服務器組成一個集群，配合反向代理實現負載均衡。
用戶發起請求都指向調度服務器，然后調度服務器根據實際的調度算法，分配不同的請求給對應的集群中的服務器執行，然后調度器等待實際服務器的http響應，再返回給瀏覽器

后臺一般都會加攔截器，安全攔截驗證，跨域驗證等等

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

這部分包括三個部分

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是瀏覽器本地存儲的一種方式，一般幫助客戶端和服務端通信，用來檢驗身份，結合服務端的session使用。

簡單說下使用場景：

用戶登錄

服務端收到請求，生成session,會有用戶的信息

生成一個sessionid

服務端在登錄頁面寫入cookie

瀏覽器就有這個cookie了，訪問同域名的時候都會自動帶上這個cookie

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

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

緩存這部分可以參考我另一篇文章
瀏覽器緩存機制分析

瀏覽器接收到http數據包后的解析過程（解析html，詞法分析解析成dom樹，解析css生成css規則樹，合并成render樹，然后布局，繪制渲染，復合圖層的合成，GPU繪制，外鏈資源的處理，loaded和domcontentloaded等）

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

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

BFC部分可以參考這篇筆記
BFC

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

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

總的來說，知識要點就是以下這些~~

瀏覽器的進程和線程

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

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

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

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

多路復用（一個tcp/ip連接可以請求多個資源）

首部壓縮(http頭部壓縮，減少體積)

二進制分幀（在應用層和傳輸層多了一層二進制分幀層，改進了傳輸性能，實現低延遲和高吞吐量）

服務端推送(服務端對客戶端的一個請求可以發出多個響應，可以主動通知客戶端)

https就是建立在http基礎上，在請求前先建立ssl連接，確保接下來的通信都是加密的，無法被竊取。

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

瀏覽器請求建立ssl連接，并向服務端發送一個隨機數client random和客戶端支持的加密方法，比如RSA加密，此時是明文傳輸

服務端從中選出一組加密算法與hash算法，回復一個隨機數server random，并將自己的身份信息以證書的形式發給瀏覽器（包括網站地址，非對稱加密的公鑰，證書的頒發機構等）

瀏覽器收到服務端發的證書后

驗證證書的合法性（頒發機構是否合法，證書中的網址是否和所在的網址相同），如果證書信任，瀏覽器前面會出現一個小鎖的圖標

用戶接收證書后（不管信不信任），瀏覽器會生成一個新的隨機數premaster-key，然后用證書中的公鑰和指定的加密方式加密premaster-key，發送給服務端

利用client random，server random和premaster-key通過一定的算法可以生成一個http連接傳輸的對稱加密session key

使用約定好的hash算法計算握手消息，并使用生成的session key加密，將之前生成的所有信息發送給服務端

服務端接收到瀏覽器的回復

利用已知的加解密方式和自己的私鑰解密客戶端發來的信息，獲取premaster-key

和瀏覽器相同的規則生成session key

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

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

瀏覽器解密服務端發來的握手信息的hash，如果與服務端發來的hash一致，則此次握手結束。

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

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