摘要：這個(gè)系列的文章的第二篇，繼續(xù)總結(jié)這是從一個(gè)問題上衍生出的知識體系，這個(gè)問題是從輸入到頁面加載的過程。先梳理下這個(gè)流程第一步從瀏覽器接收到開啟網(wǎng)絡(luò)請求線程瀏覽器的進(jìn)程線程模型，的運(yùn)行機(jī)制瀏覽器的進(jìn)程瀏覽器是多進(jìn)程的。

這個(gè)系列的文章的第二篇，繼續(xù)總結(jié)~~

這是從一個(gè)問題上衍生出的知識體系，這個(gè)問題是
從輸入U(xiǎn)RL到頁面加載的過程。
先梳理下這個(gè)流程

從瀏覽器接收url到開啟網(wǎng)絡(luò)請求線程（瀏覽器的進(jìn)程/線程模型，js的運(yùn)行機(jī)制）

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

brower進(jìn)程

主進(jìn)程，負(fù)責(zé)協(xié)調(diào)，主控等

第三方插件進(jìn)程

每種類型的插件都會有一個(gè)進(jìn)程，僅當(dāng)使用插件時(shí)才會創(chuàng)建。

GPU進(jìn)程

只有一個(gè)，用于3d繪制

瀏覽器默認(rèn)進(jìn)程(內(nèi)核)

每個(gè)tab頁對應(yīng)一個(gè)進(jìn)程，負(fù)責(zé)頁面渲染，腳本執(zhí)行，互不影響，有時(shí)候會優(yōu)化（多個(gè)空白tab會合并成一個(gè)）

每個(gè)tab頁可以看作瀏覽器的內(nèi)核的進(jìn)程，這個(gè)進(jìn)程是多線程的，它有以下幾大線程:

GUI渲染線程

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

事件觸發(fā)線程

定時(shí)器觸發(fā)線程

網(wǎng)絡(luò)請求線程

每次網(wǎng)絡(luò)請求都需要開辟多帶帶線程進(jìn)行，如果url解析到http請求，就會新開線程去處理資源下載。（http2.0可以實(shí)現(xiàn)tcp連接復(fù)用）

參考我的另一篇文章
js執(zhí)行機(jī)制 事件循環(huán)

開啟網(wǎng)絡(luò)線程到發(fā)出一個(gè)完整的http請求（dns查詢，tcp/IP請求，五層因特網(wǎng)協(xié)議棧等知識）

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

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

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

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

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

tcp將http的長報(bào)文分為短報(bào)文，通過三次握手建立連接，進(jìn)行傳輸數(shù)據(jù)。

客戶端：hi，我是客戶端,你是服務(wù)器嗎

服務(wù)器: hi，我是服務(wù)器,你是客戶端嗎

客戶端: 對，我是客戶端

建立連接成功后，就可以開始傳輸數(shù)據(jù)啦~~

主動(dòng)方: hi，我要斷開連接啦，我只能被動(dòng)接收數(shù)據(jù)了

被動(dòng)方: hi, 我收到啦

被動(dòng)方: hi，我也要斷開連接啦

主動(dòng)方：好的，我被動(dòng)接收數(shù)據(jù)的連接也關(guān)掉了。

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

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

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

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

從服務(wù)器接收到請求到對應(yīng)后臺接收到請求（負(fù)載均衡，安全攔截以及后臺內(nèi)部的處理）

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

后臺一般都會加攔截器，安全攔截驗(yàn)證，跨域驗(yàn)證等等

前臺和后臺的交互（http頭部，響應(yīng)碼，報(bào)文結(jié)構(gòu)，cookie等 ,gzip壓縮等）

這部分包括三個(gè)部分

Request Url: 請求的服務(wù)器的地址

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: 請求返回的狀態(tài)碼

Remote Address: 請求的遠(yuǎn)程服務(wù)器的地址(會轉(zhuǎn)成IP)

Accept: 接收類型，表示瀏覽器支持的MIME((Multipurpose Internet Mail Extensions) 是描述消息內(nèi)容類型的因特網(wǎng)標(biāo)準(zhǔn))類型,對應(yīng)服務(wù)端返回的的content-type

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

Content-Type: 瀏覽器發(fā)出去的實(shí)體內(nèi)容的類型

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

If-Modify-Since: 對應(yīng)服務(wù)端的Last-Modified,用來匹配文件是否變動(dòng)，是否使用緩存，只能精確到1s內(nèi)，是http1.0的

Expires: 在這個(gè)時(shí)間內(nèi)使用緩存，http1.0

Max-age: 代表資源在本地緩存多少秒，有效時(shí)間內(nèi)使用緩存

If-none-Match： 對應(yīng)服務(wù)端的Etag,用來匹配文件內(nèi)容是否改變

Cookie：有cookie并且同域訪問時(shí)會帶上

Connection: 服務(wù)端和客戶端通信連接方式，keep-alive，表示使用長連接（數(shù)據(jù)傳輸完成了保持TCP連接不斷開（不發(fā)RST包、不四次揮手），客戶端的長連接不可能無限期的拿著，會有一個(gè)超時(shí)時(shí)間，服務(wù)器有時(shí)候會告訴客戶端超時(shí)時(shí)間，如果服務(wù)器沒有告訴客戶端超時(shí)時(shí)間也沒關(guān)系，服務(wù)端可能主動(dòng)發(fā)起四次揮手?jǐn)嚅_TCP連接，客戶端能夠知道該TCP連接已經(jīng)無效；另外TCP還有心跳包來檢測當(dāng)前連接是否還活著）

Host：請求的服務(wù)器URL

Origin: 最初的請求是哪里發(fā)起的，只會精確到端口

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

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

Access-Control-Allow-Headers: 服務(wù)器允許的請求的headers

Access-Control-Allow-Methods: 服務(wù)器允許請求的方法

Access-Control-Allow-Origin: 服務(wù)器允許的請求的origin

Content-Type：服務(wù)器返回的實(shí)體內(nèi)容的類型

date：數(shù)據(jù)從服務(wù)端發(fā)起的時(shí)間

cache-control：告訴客戶端緩存機(jī)制

Last-modified: 請求資源的最后修改時(shí)間

Expires：告知客戶端在這個(gè)時(shí)間內(nèi)使用緩存

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

Etag：請求資源的標(biāo)識，表示資源是否改變

Set-cookie:設(shè)置和頁面相關(guān)聯(lián)的cookie，服務(wù)器通過這個(gè)頭部把cookie傳給客戶端

keep-alive:如果客戶端設(shè)置了keep-alive，服務(wù)端會有相應(yīng)的響應(yīng)，比如timeout=20

Server：服務(wù)器的信息。比如Apache

不同范圍的狀態(tài)的意義

1xx---請求已被接收，繼續(xù)處理

2xx---請求已被接受，理解

3xx---重定向，完成操作需要進(jìn)一步的處理

4xx---客戶端錯(cuò)誤（參數(shù)錯(cuò)誤，語法錯(cuò)誤或者請求無法實(shí)現(xiàn)）

5xx---服務(wù)端錯(cuò)誤

常見的狀態(tài)碼

200---請求已被接收并成功返回客戶端

302---重定向

304---用瀏覽器的緩存

400---客戶端請求有誤，請求參數(shù)有誤等

401---請求沒有權(quán)限

403---禁止訪問(比如未登錄時(shí)禁止)

404---找不到資源

500---服務(wù)器內(nèi)部錯(cuò)誤

503---服務(wù)不可用

cookie是瀏覽器本地存儲的一種方式，一般幫助客戶端和服務(wù)端通信，用來檢驗(yàn)身份，結(jié)合服務(wù)端的session使用。

簡單說下使用場景：

用戶登錄

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

生成一個(gè)sessionid

服務(wù)端在登錄頁面寫入cookie

瀏覽器就有這個(gè)cookie了，訪問同域名的時(shí)候都會自動(dòng)帶上這個(gè)cookie

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

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

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

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

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

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

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

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

JS執(zhí)行機(jī)制部分可參考這篇文章
js執(zhí)行機(jī)制

總的來說，知識要點(diǎn)就是以下這些~~

瀏覽器的進(jìn)程和線程

構(gòu)建dom樹，css樹，render樹，reflow，repaint，復(fù)合層和簡單層，GPU渲染

字節(jié)-> 分詞 -> 語法樹 -> 解析成機(jī)器碼

變量提升，函數(shù)提升，VO, AO, this

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

多路復(fù)用（一個(gè)tcp/ip連接可以請求多個(gè)資源）

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

二進(jìn)制分幀（在應(yīng)用層和傳輸層多了一層二進(jìn)制分幀層，改進(jìn)了傳輸性能，實(shí)現(xiàn)低延遲和高吞吐量）

服務(wù)端推送(服務(wù)端對客戶端的一個(gè)請求可以發(fā)出多個(gè)響應(yīng)，可以主動(dòng)通知客戶端)

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

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

瀏覽器請求建立ssl連接，并向服務(wù)端發(fā)送一個(gè)隨機(jī)數(shù)client random和客戶端支持的加密方法，比如RSA加密，此時(shí)是明文傳輸

服務(wù)端從中選出一組加密算法與hash算法，回復(fù)一個(gè)隨機(jī)數(shù)server random，并將自己的身份信息以證書的形式發(fā)給瀏覽器（包括網(wǎng)站地址，非對稱加密的公鑰，證書的頒發(fā)機(jī)構(gòu)等）

瀏覽器收到服務(wù)端發(fā)的證書后

驗(yàn)證證書的合法性（頒發(fā)機(jī)構(gòu)是否合法，證書中的網(wǎng)址是否和所在的網(wǎng)址相同），如果證書信任，瀏覽器前面會出現(xiàn)一個(gè)小鎖的圖標(biāo)

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

利用client random，server random和premaster-key通過一定的算法可以生成一個(gè)http連接傳輸?shù)膶ΨQ加密session key

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

服務(wù)端接收到瀏覽器的回復(fù)

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

和瀏覽器相同的規(guī)則生成session key

使用session key解密瀏覽器發(fā)來的握手信息，并驗(yàn)證hash是否與瀏覽器發(fā)來的一致

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

瀏覽器解密服務(wù)端發(fā)來的握手信息的hash，如果與服務(wù)端發(fā)來的hash一致，則此次握手結(jié)束。

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

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