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

1. 瀏覽器接收URL開啟網絡請求線程
2. DNS查詢
3. TCP/IP請求
4. 服務器接收到請求、對應后臺處理請求
5. 后臺和前臺的HTTP交互
6. 瀏覽器接收到HTTP數據包并解析
7. 頁面渲染
8. JS引擎解析

進程和線程

進程是CPU資源分配的最小單位，線程是CPU調度的最小單位

瀏覽器的進程

• Browser進程：瀏覽器的主進程，負責協調、主控，只有一個。負責界面顯示、用戶交互、頁面管理、繪制、下載等
• 第三方插件進程：每個插件對應一個線程，使用時創建
• GPU線程，用于3D繪制
• 瀏覽器渲染進程：默認每個Tab頁一個進程

瀏覽器多進程的優勢

• 避免單個page crash影響整個瀏覽器
• 避免第三方插件crash影響整個瀏覽器
• 多進程充分利用多核優勢

瀏覽器內核進程（tab頁面）的線程

• GUI線程（渲染界面）
• JS引擎線程
• 事件觸發線程（事件循環）
• 定時器線程
• 網絡請求線程

其中GUI渲染線程和JS引擎是無法同時工作的

DNS查詢

1. 瀏覽器緩存
2. hosts
3. 路由器緩存
4. ISP（網絡服務提供商）
5. 遞歸查詢

五層因特網協議棧

1. 應用層（HTTP）
2. 傳輸層（TCP、UDP）
3. 網絡層（IP）
4. 數據鏈路層
5. 物理層

TCP的三次握手

• 第一次握手(SYN=1, seq=x):
  客戶端發送一個 TCP 的 SYN 標志位置1的包，指明客戶端打算連接的服務器的端口，以及初始序號 X,保存在包頭的序列號(Sequence Number)字段里。
  發送完畢后，客戶端進入 SYN_SEND 狀態。
• 第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1):
  服務器發回確認包(ACK)應答。即 SYN 標志位和 ACK 標志位均為1。服務器端選擇自己 ISN 序列號，放到 Seq 域里，同時將確認序號(Acknowledgement Number)設置為客戶的 ISN 加1，即X+1。 發送完畢后，服務器端進入 SYN_RCVD 狀態。
• 第三次握手(ACK=1，ACKnum=y+1)
  客戶端再次發送確認包(ACK)，SYN 標志位為0，ACK 標志位為1，并且把服務器發來 ACK 的序號字段+1，放在確定字段中發送給對方，并且在數據段放寫ISN的+1
  發送完畢后，客戶端進入 ESTABLISHED 狀態，當服務器端接收到這個包時，也進入 ESTABLISHED 狀態，TCP 握手結束。

TCP的四次揮手

• 第一次揮手(FIN=1，seq=x)
  假設客戶端想要關閉連接，客戶端發送一個 FIN 標志位置為1的包，表示自己已經沒有數據可以發送了，但是仍然可以接受數據。
  發送完畢后，客戶端進入 FIN_WAIT_1 狀態。
• 第二次揮手(ACK=1，ACKnum=x+1)
  服務器端確認客戶端的 FIN 包，發送一個確認包，表明自己接受到了客戶端關閉連接的請求，但還沒有準備好關閉連接。
  發送完畢后，服務器端進入 CLOSE_WAIT 狀態，客戶端接收到這個確認包之后，進入 FIN_WAIT_2 狀態，等待服務器端關閉連接。
• 第三次揮手(FIN=1，seq=y)
  服務器端準備好關閉連接時，向客戶端發送結束連接請求，FIN 置為1。
  發送完畢后，服務器端進入 LAST_ACK 狀態，等待來自客戶端的最后一個ACK。
• 第四次揮手(ACK=1，ACKnum=y+1)
  客戶端接收到來自服務器端的關閉請求，發送一個確認包，并進入 TIME_WAIT狀態，等待可能出現的要求重傳的 ACK 包。
  服務器端接收到這個確認包之后，關閉連接，進入 CLOSED 狀態。
  客戶端等待了某個固定時間（兩個最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后，沒有收到服務器端的 ACK ，認為服務器端已經正常關閉連接，于是自己也關閉連接，進入 CLOSED 狀態。

TCP和UDP的區別

TCP和UDP的區別

粘包

默認情況下, TCP 連接會啟用延遲傳送算法 (Nagle 算法), 在數據發送之前緩存他們. 如果短時間有多個數據發送, 會緩沖到一起作一次發送 (緩沖大小見 socket.bufferSize), 這樣可以減少 IO 消耗提高性能.

如果是傳輸文件的話, 那么根本不用處理粘包的問題, 來一個包拼一個包就好了. 但是如果是多條消息, 或者是別的用途的數據那么就需要處理粘包.

可以參見網上流傳比較廣的一個例子, 連續調用兩次 send 分別發送兩段數據 data1 和 data2, 在接收端有以下幾種常見的情況:

A. 先接收到 data1, 然后接收到 data2 .
B. 先接收到 data1 的部分數據, 然后接收到 data1 余下的部分以及 data2 的全部.
C. 先接收到了 data1 的全部數據和 data2 的部分數據, 然后接收到了 data2 的余下的數據.
D. 一次性接收到了 data1 和 data2 的全部數據.
其中的 BCD 就是我們常見的粘包的情況. 而對于處理粘包的問題, 常見的解決方案有:

多次發送之前間隔一個等待時間
關閉 Nagle 算法
進行封包/拆包

TCP流量控制

通過滑動窗口協議（連續ARQ協議）實現，保證了分組無差錯、有序接收、流量控制。接收方返回的ACK中會包含自己的接收窗口的大小，并且利用大小來控制發送方的數據發送。

TCP流量控制中的死鎖

當發送者收到了一個窗口為0的應答，發送者便停止發送，等待接收者的下一個應答。如果這個窗口不為0的應答在傳輸過程中丟失，發送者一直等待，接收者以為發送者收到該應答，等待接收新數據，這樣雙方就相互等待，從而產生死鎖

TCP流量控制中的死鎖的解決

TCP使用了持續計時器。每當發送者收到一個0窗口的應答后就啟動該計時器。計時器到時便主動發送報文詢問接收者的窗口大小。若接收者仍然返回0窗口，則重置該計時器繼續等待；若窗口不為0，則標識應答報文丟失了，此時重置發送窗口開始發送，這樣就避免了死鎖的產生

擁塞控制和流量控制的區別

擁塞控制是作用于網絡的，防止網絡負載過大，常用的方法：1.慢啟動、擁塞避免 2.快重傳、快恢復。流量控制是作用于接收者的，控制發送者的發送速度使接收者來得及接收，防止分組丟失

慢啟動算法

發送方維持一個叫做擁塞窗口CWnd的狀態變量，控制著傳輸速度，TCP開始發送報文時CWnd=1。一個傳輸輪次所經歷的時間就是往返時間RTT，每經過一個RTT并且按時收到確認，就將擁塞窗口CWnd加倍。還有一個叫慢啟動門限ssthresh的狀態變量，當CWnd<ssthresh時，使用慢啟動，當CWnd>=ssthresh改用擁塞避免算法

擁塞避免算法

每經過一個往返時間RTT就把發送方的擁塞窗口cwnd加1而不是加倍。無論在慢啟動階段還是擁塞避免階段，只要發送方沒有按時收到確認，就把慢啟動門限設置為出現擁塞時的擁塞窗口cwnd的一半（但不小于2）。然后把擁塞窗口cwnd重置為1，執行慢啟動算法

快重傳算法

接收方收到一個失序的報文段后就立刻發出重復確認而不是等到自己發送數據時捎帶確認。只要發送方一連收到三個重復確認就立即重傳對方尚未收到的報文段，而不是等待重傳計時器到期

快恢復算法

當發送方連續收到三個重復確認時，把慢啟動門限ssthresh減半，但是并不執行慢開始算法，而是將擁塞窗口cwnd設置為ssthresh減半后的值，直接執行擁塞避免算法。快重傳配合快恢復的TCP Reno版本是目前使用最廣的版本。

HTTP報文結構

• 通用頭部
• 請求/響應頭部
• 請求/響應體

常見請求頭部

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：服務器的一些相關信息

HTTP2.0相對于HTTP1.x有什么優勢和特點

二進制分幀

幀：HTTP/2 數據通信的最小單位消息：指 HTTP/2 中邏輯上的 HTTP 消息。例如請求和響應等，消息由一個或多個幀組成。
流：存在于連接中的一個虛擬通道。流可以承載雙向消息，每個流都有一個唯一的整數ID

頭部壓縮

HTTP/1.x會在請求和響應中中重復地攜帶不常改變的、冗長的頭部數據，給網絡帶來額外的負擔。

• HTTP/2在客戶端和服務器端使用“首部表”來跟蹤和存儲之前發送的鍵－值對，對于相同的數據，不再通過每次請求和響應發送
• 首部表在HTTP/2的連接存續期內始終存在，由客戶端和服務器共同漸進地更新
• 每個新的首部鍵－值對要么被追加到當前表的末尾，要么替換表中之前的值

服務器推送

服務端可以在發送頁面HTML時主動推送其它資源，而不用等到瀏覽器解析到相應位置，發起請求再響應。例如服務端可以主動把JS和CSS文件推送給客戶端，而不需要客戶端解析HTML時再發送這些請求。

服務端可以主動推送，客戶端也有權利選擇是否接收。如果服務端推送的資源已經被瀏覽器緩存過，瀏覽器可以通過發送RST_STREAM幀來拒收。主動推送也遵守同源策略，服務器不會隨便推送第三方資源給客戶端。

多路復用

HTTP 1.x 中，如果想并發多個請求，必須使用多個 TCP 鏈接，且瀏覽器為了控制資源，還會對單個域名有 6-8個的TCP鏈接請求限制。

HTTP2中：

同域名下所有通信都在單個連接上完成。
單個連接可以承載任意數量的雙向數據流。
數據流以消息的形式發送，而消息又由一個或多個幀組成，多個幀之間可以亂序發送，因為根據幀首部的流標識可以重新組裝

HTTP的緩存過程

1. 客戶端向服務器發出請求，請求資源
2. 服務器返回資源，并通過響應頭決定緩存策略
3. 客戶端根據響應頭的策略決定是否緩存資源（這里假設是），并將響應頭與資源緩存下來
4. 在客戶端再次請求且命中資源的時候，此時客戶端去檢查上次緩存的緩存策略，根據策略的不同、是否過期等判斷是直接讀取本地緩存還是與服務器協商緩存

原文章

前端面試與進階指南
從輸入URL到頁面加載的過程？如何由一道題完善自己的前端知識體系！