網(wǎng)絡(luò)模型

目前公認(rèn)的網(wǎng)絡(luò)模型有兩種，一種是OSI七層模型回季，另一種則是TCP/IP四層模型

image.png

OSI七層模型：OSI（Open System Interconnection）開放系統(tǒng)互連參考模型是國際標(biāo)準(zhǔn)化組織（ISO）制定的一個(gè)用于計(jì)算機(jī)或通信系統(tǒng)間互聯(lián)的標(biāo)準(zhǔn)體系瘩燥。

TCP/IP四層模型：TCP/IP參考模型是計(jì)算機(jī)網(wǎng)絡(luò)的祖父ARPANET和其后繼的因特網(wǎng)使用的參考模型秕重。
分層作用：方便管理

OSI七層模型和TCP/IP四層模型存在一個(gè)對應(yīng)關(guān)系，并且傳輸層以下的完全一致(TCP模型中的網(wǎng)絡(luò)接口層就是數(shù)據(jù)鏈路層和物理層的集合)厉膀，因此可以說將OSI模型中的會話層溶耘、表示層與應(yīng)用層合并為TCP/IP模型中的應(yīng)用層后套鹅，二者基本一致。

兩個(gè)網(wǎng)絡(luò)模型都屬于通用網(wǎng)絡(luò)模型汰具，相對來說，TCP/IP模型更為普遍一些菱魔，所以我們也主要以TCP/IP模型為網(wǎng)絡(luò)模型開展論述

image.png

我們熟知的一些協(xié)議留荔，IP協(xié)議位于網(wǎng)絡(luò)層，TCP協(xié)議位于傳輸層澜倦，而HTTP協(xié)議則位于應(yīng)用層聚蝶，其余還有比較熟悉的DNS協(xié)議，F(xiàn)TP協(xié)議等等藻治，都有其所屬的層級碘勉。

image.png

各層主要功能：

• 應(yīng)用層：負(fù)責(zé)向用戶提供應(yīng)用程序，比如HTTP桩卵、FTP验靡、Telnet、DNS雏节、SMTP等胜嗓。

• 傳輸層：負(fù)責(zé)對報(bào)文進(jìn)行分組和重組，并以TCP或UDP協(xié)議格式封裝報(bào)文钩乍。（提供可靠或不可靠的傳輸辞州，在重傳前執(zhí)行糾錯(cuò) 防火墻）

• 網(wǎng)絡(luò)層：負(fù)責(zé)路由以及把分組報(bào)文發(fā)送給目標(biāo)網(wǎng)絡(luò)或主機(jī)。（提供邏輯地址寥粹，路由器使用它們來選擇路徑 三層交換機(jī)变过、路由器）

• 鏈路層：負(fù)責(zé)封裝和解封裝IP報(bào)文，發(fā)送和接受ARP/RARP報(bào)文等涝涤。（使用MAC地址提供介質(zhì)訪問媚狰，在設(shè)備之間傳輸）

TCP UDP區(qū)別

（1）TCP協(xié)議：TCP（Transmission Control Protocol，傳輸控制協(xié)議）是面向連接的協(xié)議阔拳，在收發(fā)數(shù)據(jù)前哈雏，必須和對方建立可靠的連接。

（2）UDP協(xié)議：UDP 是User Datagram Protocol的簡稱衫生， 中文名是用戶數(shù)據(jù)報(bào)協(xié)議裳瘪，是一種無連接的傳輸層協(xié)議，提供面向事務(wù)的簡單不可靠信息傳送服務(wù)

總結(jié)：TCP與UDP的區(qū)別：

• 1.基于連接與無連接罪针；
• 2.對系統(tǒng)資源的要求（TCP較多彭羹，UDP少）；
• 3.UDP程序結(jié)構(gòu)較簡單泪酱；UDP信息包的標(biāo)題很短派殷，只有8個(gè)字節(jié)还最，相對于TCP的20個(gè)字節(jié)信息包的額外開銷很小。所以傳輸速度可更快
• 4.TCP保證數(shù)據(jù)正確性毡惜，UDP可能丟包拓轻；TCP保證數(shù)據(jù)順序，UDP不保證经伙。

場景：
udp： 視頻扶叉，語音通訊使用udp，或網(wǎng)絡(luò)環(huán)境很好帕膜，比如局域網(wǎng)中通訊可以使用udp枣氧。 udp數(shù)據(jù)傳輸完整性，可以通過應(yīng)用層的軟件來校對就可以了垮刹。
tcp： 傳文件达吞，數(shù)據(jù)完整性要求高。

三次握手和四次揮手

http://www.reibang.com/p/3a40ff77d8d3

HTTP協(xié)議簡介

超文本傳輸協(xié)議（英文：HyperText Transfer Protocol荒典，縮寫：HTTP）是一種用于分布式酪劫、協(xié)作式和超媒體信息系統(tǒng)的應(yīng)用層協(xié)議。HTTP是萬維網(wǎng)的數(shù)據(jù)通信的基礎(chǔ)寺董。

HTTP是一個(gè)客戶端終端（用戶）和服務(wù)器端（網(wǎng)站）請求和應(yīng)答的標(biāo)準(zhǔn)（TCP）契耿。通過使用網(wǎng)頁瀏覽器、網(wǎng)絡(luò)爬蟲或者其它的工具螃征，客戶端發(fā)起一個(gè)HTTP請求到服務(wù)器上指定端口（默認(rèn)端口為80）

HTTP工作原理

HTTP協(xié)議采用了請求/響應(yīng)模型搪桂。客戶端向服務(wù)器發(fā)送一個(gè)請求報(bào)文盯滚，請求報(bào)文包含請求的方法踢械、URL、協(xié)議版本魄藕、請求頭部和請求數(shù)據(jù)内列。服務(wù)器以一個(gè)狀態(tài)行作為響應(yīng)，響應(yīng)的內(nèi)容包括協(xié)議的版本背率、成功或者錯(cuò)誤代碼话瞧、服務(wù)器信息、響應(yīng)頭部和響應(yīng)數(shù)據(jù)

HTTP 請求/響應(yīng)的步驟：

• 1. 客戶端連接到Web服務(wù)器
     一個(gè)HTTP客戶端寝姿，通常是瀏覽器交排，與Web服務(wù)器的HTTP端口（默認(rèn)為80）建立一個(gè)TCP套接字連接。例如饵筑，http://www.baidu.com埃篓。
• 2. 發(fā)送HTTP請求
     通過TCP套接字，客戶端向Web服務(wù)器發(fā)送一個(gè)文本的請求報(bào)文根资，一個(gè)請求報(bào)文由請求行架专、請求頭部同窘、空行和請求數(shù)據(jù)4部分組成。
• 3. 服務(wù)器接受請求并返回HTTP響應(yīng)
     Web服務(wù)器解析請求部脚，定位請求資源想邦。服務(wù)器將資源復(fù)本寫到TCP套接字，由客戶端讀取委刘。一個(gè)響應(yīng)由狀態(tài)行丧没、響應(yīng)頭部、空行和響應(yīng)數(shù)據(jù)4部分組成钱雷。
• 4. 釋放連接TCP連接
     若connection 模式為close，則服務(wù)器主動關(guān)閉TCP連接吹零，客戶端被動關(guān)閉連接罩抗，釋放TCP連接;若connection 模式為keepalive，則該連接會保持一段時(shí)間灿椅，在該時(shí)間內(nèi)可以繼續(xù)接收請求;
• 5. 客戶端瀏覽器解析HTML內(nèi)容
     客戶端瀏覽器首先解析狀態(tài)行套蒂，查看表明請求是否成功的狀態(tài)代碼。然后解析每一個(gè)響應(yīng)頭茫蛹，響應(yīng)頭告知以下為若干字節(jié)的HTML文檔和文檔的字符集操刀。客戶端瀏覽器讀取響應(yīng)數(shù)據(jù)HTML婴洼，根據(jù)HTML的語法對其進(jìn)行格式化骨坑，并在瀏覽器窗口中顯示。

http協(xié)議是基于TCP/IP協(xié)議之上的應(yīng)用層協(xié)議

基于 請求-響應(yīng) 的模式: HTTP協(xié)議規(guī)定,請求從客戶端發(fā)出,最后服務(wù)器端響應(yīng)該請求并 返回柬采。換句話說,肯定是先從客戶端開始建立通信的,服務(wù)器端在沒有 接收到請求之前不會發(fā)送響應(yīng)

無狀態(tài)保存:HTTP是一種不保存狀態(tài),即無狀態(tài)(stateless)協(xié)議欢唾。HTTP協(xié)議 自身不對請求和響應(yīng)之間的通信狀態(tài)進(jìn)行保存。也就是說在HTTP這個(gè) 級別,協(xié)議對于發(fā)送過的請求或響應(yīng)都不做持久化處理粉捻。

無連接:無連接的含義是限制每次連接只處理一個(gè)請求礁遣。服務(wù)器處理完客戶的請求，并收到客戶的應(yīng)答后肩刃，即斷開連接祟霍。
(但是無連接有兩種方式，早期的http協(xié)議是一個(gè)請求一個(gè)響應(yīng)之后盈包，直接就斷開了沸呐，但是現(xiàn)在的http協(xié)議1.1版本不是直接就斷開了，而是等幾秒鐘呢燥，這幾秒鐘是等什么呢垂谢，等著用戶有后續(xù)的操作，如果用戶在這幾秒鐘之內(nèi)有新的請求疮茄，那么還是通過之前的連接通道來收發(fā)消息滥朱，如果過了這幾秒鐘用戶沒有發(fā)送新的請求根暑，那么就會斷開連接，這樣可以提高效率徙邻，減少短時(shí)間內(nèi)建立連接的次數(shù)排嫌，因?yàn)榻⑦B接也是耗時(shí)的，默認(rèn)的好像是3秒中現(xiàn)在缰犁，但是這個(gè)時(shí)間是可以通過咱們后端的代碼來調(diào)整的淳地，自己網(wǎng)站根據(jù)自己網(wǎng)站用戶的行為來分析統(tǒng)計(jì)出一個(gè)最優(yōu)的等待時(shí)間。)

HTTP報(bào)文結(jié)構(gòu)

HTTP請求報(bào)文： 請求行(request line)帅容、請求頭部(header)颇象、空行和請求數(shù)據(jù)(request data)
客戶端發(fā)送一個(gè)HTTP請求到服務(wù)器的請求報(bào)文如下

image.png

GET /admin_ui/rdx/core/images/close.png HTTP/1.1
Accept: */*
Referer: http://xxx.xxx.xxx.xxx/menu/neo
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E)
Accept-Encoding: gzip, deflate
Host: xxx.xxx.xxx.xxx
Connection: Keep-Alive
Cookie: startupapp=neo; is_cisco_platform=0; rdx_pagination_size=250%20Per%20Page; SESSID=deb31b8eb9ca68a514cf55777744e339

1. 請求行數(shù)據(jù)格式由三個(gè)部分組成：請求方法、URI并徘、HTTP協(xié)議版本遣钳，他們之間用空格分隔

GET /index.html HTTP/1.1

該部分的請求方法字段給出了請求類型，URI給出請求的資源位置(/index.html)麦乞。HTTP中的請求類型包括:GET蕴茴、POST、HEAD姐直、PUT倦淀、DELETE。一般常用的為GET和POST方式声畏。最后HTTP協(xié)議版本給出HTTP的版本號撞叽。

2. 請求頭部緊跟著請求行，該部分主要是用于描述請求正文.
   主要是用于說明請求源插龄、連接類型能扒、以及一些Cookie信息等。 (由多個(gè)key-value值組成)

3.空行：請求報(bào)文使用空行將請求頭部和請求數(shù)據(jù)分隔

4. 請求數(shù)據(jù)：GET方法沒有攜帶數(shù)據(jù)辫狼，POST方法會攜帶一個(gè)body

HTTP響應(yīng)報(bào)文： 狀態(tài)行初斑、響應(yīng)頭、空行膨处、響應(yīng)體(數(shù)據(jù))

HTTP/1.1 200 OK
Bdpagetype: 1
Bdqid: 0xacbbb9d800005133
Cache-Control: private
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html
Cxy_all: baidu+f8b5e5b521b3644ef7f3455ea441c5d0
Date: Fri, 12 Oct 2018 06:36:28 GMT
Expires: Fri, 12 Oct 2018 06:36:26 GMT
Server: BWS/1.1
Set-Cookie: delPer=0; path=/; domain=.baidu.com
Set-Cookie: BDSVRTM=0; path=/
Set-Cookie: BD_HOME=0; path=/
Set-Cookie: H_PS_PSSID=1433_21112_18560_26350_27245_22158; path=/; domain=.baidu.com
Vary: Accept-Encoding
X-Ua-Compatible: IE=Edge,chrome=1
Transfer-Encoding: chunked

<!DOCTYPE html>
<!--STATUS OK-->

1. 狀態(tài)行：狀態(tài)行主要給出響應(yīng)HTTP協(xié)議的版本號见秤、響應(yīng)返回狀態(tài)碼、響應(yīng)描述真椿，同樣是單行顯示

HTTP/1.1 200 OK

狀態(tài)碼

• 1XX 請求正在處理
• 2XX 請求成功 200 OK 正常處理 204 no content 請求處理成功但沒有資源可返回 206 Partial Content 對資源的某一部分請求
• 3XX 重定向 301 Moved Permanenly請求資源的URI已經(jīng)更新（永久移動）鹃答，客戶端會同步更新URI。 302 Found 資源的URI已臨時(shí)定位到其他位置突硝，客戶端不會更新URI测摔。
• 4XX 客戶端錯(cuò)誤 400 Bad Request 請求報(bào)文中存在語法錯(cuò)誤，一般為參數(shù)異常。401 Unauthorized 發(fā)送的請求需要HTTP認(rèn)證锋八。403 Forbiddden 不允許訪問浙于，對請求資源的訪問被服務(wù)器拒絕 404 Not Found 無法找到請求的資源，請求資源不存在挟纱。
• 5XX 服務(wù)器錯(cuò)誤 500 Internal Server Error 服務(wù)器的內(nèi)部資源出故障羞酗，服務(wù)器在執(zhí)行請求時(shí)發(fā)生了錯(cuò)誤。

2. 響應(yīng)頭部: 主要是返回一些服務(wù)器的基本信息紊服，以及一些Cookie值等(由多個(gè)key-value值組成)

3. 空行：響應(yīng)報(bào)文使用空行將響應(yīng)頭和響應(yīng)體分隔

4. 響應(yīng)體：請求需要得到的具體數(shù)據(jù)檀轨，可以為任何類型數(shù)據(jù)，一般網(wǎng)頁瀏覽返回的為html文件內(nèi)容

在瀏覽器地址欄輸入url到按下回車發(fā)生了什么欺嗤？

1.解析url
瀏覽器通過地址欄捕獲到url地址之后参萄，首先對url地址進(jìn)行解析.

image.png

該ip地址的作用就是在互聯(lián)網(wǎng)中確定服務(wù)器的位置淤袜，緊接著是端口后痒谴，端口號確定的是在服務(wù)器中運(yùn)行的具體的程序衰伯。路徑部分表示的是在該程序中資源的具體標(biāo)識，查詢參數(shù)作用主要是為了發(fā)送數(shù)據(jù)积蔚。

2. DNS解析
一般域名都需要從運(yùn)營商購買意鲸，因?yàn)閕p地址不方便記憶，域名比較好記尽爆。域名都會和ip地址綁定怎顾，那么，在這里就需要做DNS解析漱贱，所謂DNS解析其實(shí)就是槐雾，根據(jù)域名找到其綁定的 ip地址

查找的順序如下圖

image.png

DNS的查找過程解析：

• 瀏覽器會先檢查是否存在緩存，因?yàn)槿绻L問過一次該域名的話幅狮，會把結(jié)果緩存在瀏覽器中募强。

• 操作系統(tǒng)也會有自己的DNS緩存，但在這之前崇摄，會檢查域名是否存在于本地的Hosts文件中擎值。

• 路由器中也會有自己的緩存。

• IPS DNS緩存 就是在客戶端電腦上設(shè)置的首選DNS服務(wù)器逐抑。

• 在前邊所有的情況下都沒有找到緩存的情況下鸠儿，會連接互聯(lián)網(wǎng)，把請求轉(zhuǎn)發(fā)到互聯(lián)網(wǎng)的根域。

  
  
  image.png

3. TCP連接
確定好目標(biāo)服務(wù)器的ip地址和端口號后进每，就開始和遠(yuǎn)程服務(wù)器建立TCP鏈接http://www.reibang.com/p/3a40ff77d8d3

image.png

TCP三次握手的好處在于的好處在于汹粤，發(fā)送方可以確認(rèn)接收方仍然在線

4. 發(fā)送http請求
http協(xié)議是建立在tcp/ip協(xié)議之上的，tcp保證連接通暢品追，http就可以正常的進(jìn)行請求和響應(yīng)了玄括。首先http請求是一個(gè)無狀態(tài)的請求，且只能由瀏覽器主動發(fā)起肉瓦，服務(wù)器進(jìn)行響應(yīng)遭京。(請求報(bào)文)

5.服務(wù)器接收請求
在服務(wù)端會監(jiān)聽瀏覽器端發(fā)送的http請求，當(dāng)瀏覽器的請求發(fā)出后泞莉，服務(wù)端就會接受該請求哪雕，并解析出相應(yīng)的信息，選擇對應(yīng)的邏輯進(jìn)行處理（比如：查找對應(yīng)的靜態(tài)頁面鲫趁，保存文件斯嚎，操作數(shù)據(jù)庫，轉(zhuǎn)發(fā)....）,并將處理的結(jié)果響應(yīng)給瀏覽器端挨厚。

6.服務(wù)器響應(yīng)
服務(wù)器執(zhí)行完邏輯之后堡僻，需要給瀏覽器響應(yīng)內(nèi)容（無論是要從服務(wù)器獲取數(shù)據(jù)，還是在服務(wù)器做了什么操作疫剃，都需要給瀏覽器一個(gè)響應(yīng)）（響應(yīng)報(bào)文）
服務(wù)器響應(yīng)的同時(shí)肯定會伴隨著瀏覽器端接收钉疫，等瀏覽器端徹底接收完畢之后，TCP就要進(jìn)行4次揮手巢价，并斷開連接了牲阁。

7.TCP鏈接斷開
TCP鏈接的斷開需要經(jīng)過"四次揮手"，那么就需要一方主動的釋放另外一方被動的釋放壤躲。大體的過程如下：

• 瀏覽器端發(fā)消息通知服務(wù)器現(xiàn)在需要斷開（第一次揮手）

• 服務(wù)器接到要斷開的請求之后城菊，給瀏覽器返回消息，告訴瀏覽器我正在準(zhǔn)備釋放（第二次揮手）

• 此時(shí)瀏覽器接到消息后正在等待服務(wù)器釋放完成碉克，而服務(wù)器正在準(zhǔn)備釋放的過程

• 當(dāng)服務(wù)器釋放完成后凌唬，再通知瀏覽器我已經(jīng)釋放完成了。（第三次揮手）

• 瀏覽器接收到服務(wù)器釋放完成的消息后漏麦，再給服務(wù)器發(fā)送消息告訴服務(wù)器我已經(jīng)知道你釋放完成了客税，服務(wù)器收到消息后，就能確認(rèn)自己釋放完成的消息已經(jīng)通知到了（第四次揮手）

8. 瀏覽器解析資源
當(dāng)瀏覽器接收到服務(wù)器響應(yīng)的資源后唁奢，會對資源進(jìn)行解析霎挟。

• 首先，查看Response Header,根據(jù)響應(yīng)頭的指示做不同的事情麻掸，比如重定向酥夭，存儲cookie，解壓gzip，緩存資源等等熬北。

• 接下來獲取MIME類型（查看響應(yīng)頭的 Content-Type的值）疙描，根據(jù)不同的資源類型采用不同的解析方式

9.渲染頁面
一般來說從地址欄輸入地址后，絕大多是情況下響應(yīng)的都是 html文件讶隐，那么就說以說頁面是如何渲染html頁面的起胰，html頁面中一般也會嵌入css，js巫延，圖片等資源效五。

因此如果解析到這些資源的時(shí)候，會再次向目標(biāo)服務(wù)器發(fā)起請求炉峰，那么又會經(jīng)歷從解析url地址開始的各個(gè)步驟畏妖。

html解析.png

10.html頁面的加載
首先要知道瀏覽器解析是從上往下一行一行地解析的。

• 解碼：傳輸回來的其實(shí)都是一些二進(jìn)制字節(jié)數(shù)據(jù)疼阔，瀏覽器需要根據(jù)文件指定編碼（例如UTF-8）轉(zhuǎn)換成字符串戒劫，也就是HTML 代碼

• 預(yù)解析：預(yù)解析做的事情是提前加載資源，減少處理時(shí)間婆廊，它會識別一些會請求資源的屬性迅细，比如img標(biāo)簽的src屬性，并將這個(gè)請求加到請求隊(duì)列中淘邻。

• 符號化：符號化是詞法分析的過程茵典，將輸入解析成符號，HTML 符號包括列荔，開始標(biāo)簽敬尺、結(jié)束標(biāo)簽枚尼、屬性名和屬性值贴浙。它通過一個(gè)狀態(tài)機(jī)去識別符號的狀態(tài)，比如遇到<署恍，>狀態(tài)都會產(chǎn)生變化崎溃。

• 構(gòu)建樹：在上一步符號化中，解析器獲得這些標(biāo)記盯质，然后以合適的方法創(chuàng)建DOM對象并把這些符號插入到DOM對象中袁串。

瀏覽器的容錯(cuò)機(jī)制：你從來沒有在瀏覽器看過類似”語法無效”的錯(cuò)誤，這是因?yàn)闉g覽器去糾正錯(cuò)誤的語法呼巷，然后繼續(xù)工作囱修。

11.CSS解析
一旦瀏覽器下載了 CSS，CSS 解析器就會處理它遇到的任何 CSS王悍，根據(jù)語法規(guī)范解析出所有的 CSS 并進(jìn)行標(biāo)記化破镰，然后我們得到一個(gè)規(guī)則表。

在匹配一個(gè)節(jié)點(diǎn)對應(yīng)的 CSS 規(guī)則時(shí)，是按照從右到左的順序的鲜漩，例如：div p { font-size :14px }會先尋找所有的p標(biāo)簽然后判斷它的父元素是否為div源譬。

所以我們寫 CSS 時(shí)，盡量用 id 和 class孕似，千萬不要過度層疊踩娘。

12.javaScript編譯執(zhí)行

javascript解析.png

主要是三個(gè)階段

• 詞法分析：js腳本加載完畢后，會首先進(jìn)入語法分析階段喉祭，它首先會分析代碼塊的語法是否正確养渴，不正確則拋出“語法錯(cuò)誤”，停止執(zhí)行泛烙。

• 預(yù)編譯：js有三種運(yùn)行環(huán)境分別是 全局環(huán)境厚脉，函數(shù)環(huán)境，eval胶惰。每進(jìn)入一個(gè)不同的運(yùn)行環(huán)境都會創(chuàng)建一個(gè)對應(yīng)的執(zhí)行上下文傻工，根據(jù)不同的上下文環(huán)境，形成一個(gè)函數(shù)調(diào)用棧孵滞，棧底永遠(yuǎn)是全局執(zhí)行上下文中捆，棧頂則永遠(yuǎn)是當(dāng)前執(zhí)行上下文。

• 執(zhí)行：js雖然是單線程的坊饶，但是實(shí)際參與工作的線程一共有四個(gè)：JS引擎線程（主）泄伪，事件觸發(fā)線程，定時(shí)器觸發(fā)線程匿级，HTTP異步請求線程

總結(jié)

從瀏覽地地址欄輸入地址按下回車蟋滴，可以看做是一次請求的發(fā)起，那么必然會經(jīng)歷以下幾個(gè)步驟：

解析url地址
DNS解析
TCP鏈接
發(fā)送http請求
服務(wù)器接收請求
服務(wù)器響應(yīng)
TCP鏈接斷開
瀏覽器解析資源

事件循環(huán)

瀏覽器執(zhí)行線程

在解釋事件循環(huán)之前首先先解釋一下瀏覽器的執(zhí)行線程：
瀏覽器是多進(jìn)程的痘绎，瀏覽器每一個(gè) tab 標(biāo)簽都代表一個(gè)獨(dú)立的進(jìn)程津函，其中瀏覽器渲染進(jìn)程（瀏覽器內(nèi)核）屬于瀏覽器多進(jìn)程中的一種，主要負(fù)責(zé)頁面渲染孤页，腳本執(zhí)行尔苦，事件處理等
其包含的線程有：GUI 渲染線程（負(fù)責(zé)渲染頁面，解析 HTML行施，CSS 構(gòu)成 DOM 樹）允坚、JS 引擎線程、事件觸發(fā)線程蛾号、定時(shí)器觸發(fā)線程稠项、http 請求線程等主要線程

關(guān)于執(zhí)行中的線程：

主線程：也就是 js 引擎執(zhí)行的線程，這個(gè)線程只有一個(gè)鲜结，頁面渲染展运、函數(shù)處理都在這個(gè)主線程上執(zhí)行斩芭。
工作線程：也稱幕后線程，這個(gè)線程可能存在于瀏覽器或js引擎內(nèi)乐疆，與主線程是分開的悍抑，處理文件讀取芍秆、網(wǎng)絡(luò)請求等異步事件。

任務(wù)隊(duì)列( Event Queue )
所有的任務(wù)可以分為同步任務(wù)和異步任務(wù)，同步任務(wù)浑劳，顧名思義蛤织，就是立即執(zhí)行的任務(wù)妻率，同步任務(wù)一般會直接進(jìn)入到主線程中執(zhí)行蔚晨；而異步任務(wù)，就是異步執(zhí)行的任務(wù)咖杂，比如ajax網(wǎng)絡(luò)請求庆寺，setTimeout 定時(shí)函數(shù)等都屬于異步任務(wù)，異步任務(wù)會通過任務(wù)隊(duì)列的機(jī)制(先進(jìn)先出的機(jī)制)來進(jìn)行協(xié)調(diào)

同步任務(wù)與異步任務(wù).jpg

在事件循環(huán)中，每進(jìn)行一次循環(huán)操作稱為tick冲杀，通過閱讀規(guī)范可知效床，每一次 tick 的任務(wù)處理模型是比較復(fù)雜的，其關(guān)鍵的步驟可以總結(jié)如下

1. 在此次 tick 中選擇最先進(jìn)入隊(duì)列的任務(wù)( oldest task )权谁，如果有則執(zhí)行(一次)
2. 檢查是否存在 Microtasks 剩檀，如果存在則不停地執(zhí)行，直至清空Microtask Queue
3. 更新 render

4. 主線程重復(fù)執(zhí)行上述步驟

   
   
   image.png

規(guī)范中規(guī)定闯传，task分為兩大類, 分別是 Macro Task （宏任務(wù)）和 Micro Task（微任務(wù)）, 并且每個(gè)宏任務(wù)結(jié)束后, 都要清空所有的微任務(wù),這里的 Macro Task也是我們常說的 task

宏任務(wù)主要包含：script( 整體代碼)谨朝、setTimeout卤妒、setInterval甥绿、I/O、UI 交互事件则披、setImmediate(Node.js 環(huán)境)

微任務(wù)主要包含：Promise共缕、MutaionObserver、process.nextTick(Node.js 環(huán)境) （process.nextTick的優(yōu)先級要高于Promise.then, 在事件循環(huán)中士复，如果process.nextTick執(zhí)行后又是process.nextTick图谷，會繼續(xù)執(zhí)行翩活，知道沒有process.nextTick任務(wù)后才會去執(zhí)行 Promise.then中的任務(wù)）

JavaScript 是一門單線程語言，異步操作都是放到事件循環(huán)隊(duì)列里面便贵，等待主執(zhí)行棧來執(zhí)行的菠镇，并沒有專門的異步執(zhí)行線程。

參考：
https://www.iteye.com/news/32765
https://www.cnblogs.com/itzhao/p/11242322.html
https://www.cnblogs.com/an-wen/p/11180076.html
https://blog.csdn.net/weixin_42716620/article/details/82888576
https://blog.csdn.net/snsHL9db69ccu1aIKl9r/article/details/110015266
https://blog.csdn.net/kongmin_123/article/details/82154780
https://zhuanlan.zhihu.com/p/87684858