當你在瀏覽器輸入時發生了什麼

Created: 2024/12/2
Updated: 2025/8/12
browser

簡單記錄了關於瀏覽器輸入時發生了什麼

當我們想要打開一個連結，我們會把它貼到chrome上並透過瀏覽器來觀看該網站連結的網站是什麼。這件事是我們常做的，但有沒有思考過背後的原理，為什麼貼上網址，瀏覽器就能將網頁顯示出來呢。

當我們在瀏覽器輸入URL並按下Enter鍵時，背後發生了一系列複雜且高度協調的過程，這些過程涉及到瀏覽器、網絡協議、伺服器以及許多其他技術。這裡會簡單的介紹。

1. 瀏覽器接收URL並開啟一個新Process

瀏覽器是一個複雜的應用程式，本身由多個process和thread組成，並且透過這些process和thread協同工作以確保網頁的順利加載和顯示。當輸入URL並按下Enter鍵時，瀏覽器會啟動一個新的process來處理這次請求。這個新process專門負責網頁的載入和渲染，從而保證即使有一個process崩潰，其他網頁仍然可以正常運行。

瀏覽器的多Process架構

現代瀏覽器採用多進程架構，主要包含以下幾種進程：

  • 瀏覽器進程（Browser Process）：負責處理標籤頁以外的所有內容，包括界面線程（繪製按鈕和輸入欄位）、網絡線程（處理網絡請求）、存儲線程（控制檔案存取權限）等。
  • 渲染進程（Renderer Process）：每個標籤頁通常對應一個渲染進程，負責網頁的解析、渲染和JavaScript執行。
  • 插件進程（Plugin Process）：負責處理各種瀏覽器插件。
  • GPU進程（GPU Process）：處理GPU相關的任務，如硬體加速渲染。

當您在地址欄輸入URL時，瀏覽器進程的界面線程(UI Thread)會首先處理您的輸入。

2. 瀏覽器解析URL

當用戶開始在地址欄輸入內容時，瀏覽器進程的界面線程（UI Thread）首先會判斷"這是搜尋查詢還是網址？"在Chrome中，地址欄同時也是搜尋輸入欄位，因此界面線程需要解析並決定是將您導向搜尋引擎，還是導向您請求的網站。

當確認是URL後，該process將我們輸入的URL開始被解析為協定、網域名稱和路徑等資訊。以https://www.example.com/path為例：

  • 協定：https
  • 網域名稱：www.example.com
  • 路徑：/path

瀏覽器會根據這些資訊決定接下來的行動。協定決定了瀏覽器將使用哪種網絡協議（如HTTP或HTTPS），而網域名稱和路徑則幫助瀏覽器找到具體的資源。

輸入處理與判斷

界面線程需要判斷用戶輸入的是搜尋查詢還是網址。在Chrome中，地址欄同時也是搜尋輸入欄位，因此界面線程需要進行解析，決定是將您導向搜尋引擎，還是導向您請求的網站。

URL的組成

URL（統一資源定位符）是一種標識網絡資源的方法，通常由以下部分組成：

  • 協定（protocol）：如HTTP、HTTPS、FTP等，指定了如何訪問資源。
  • 網域名稱（domain name）：如www.example.com，用於標識伺服器的地址。
  • 路徑（path）：如/path，用於標識資源在伺服器上的位置。
  • 查詢參數（query parameters）：如?key=value，用於傳遞附加資訊。
  • 片段識別符（fragment identifier）：如#section，用於標識頁面內的某個部分。

3. DNS查詢

接下來，瀏覽器需要將網域名稱解析為對應的IP地址。這一過程稱為DNS查詢，主要分為以下幾步：

  • 瀏覽器首先查詢本地(Browser)的DNS緩存，看看是否有對應的IP地址。
  • 如果本地緩存中沒有，瀏覽器會請求作業系統(OS)進行DNS查詢。
  • 操作系統查詢本地的hosts文件，看是否有對應的IP地址。
  • 如果hosts文件中沒有，作業系統會向配置的DNS伺服器發送查詢請求。通常這些DNS伺服器是ISP（網際網路服務提供商）的伺服器。
  • DNS伺服器如果本身沒有記錄，會進行遞歸查詢，逐層向上查詢直至獲得結果。

DNS查詢的結果是一個IP地址，瀏覽器將使用這個IP地址與伺服器建立連線。

4. 建立TCP連線

有了IP地址後，瀏覽器需要與伺服器建立一個TCP連線。這一步包括TCP的三次握手過程：

  1. 瀏覽器向伺服器發送一個SYN（同步）包，請求建立連線。
  2. 伺服器收到SYN包後，回覆一個SYN-ACK（同步-確認）包，表示同意建立連線。
  3. 瀏覽器收到SYN-ACK包後，再回覆一個ACK（確認）包，完成連線建立。

這個過程確保了瀏覽器和伺服器之間的連線是可靠且雙向的。

4.1 TLS安全握手

如果使用的是HTTPS協議，TCP連線建立後還需要進行TLS（Transport Layer Security）握手來建立安全的加密通道。TLS握手的主要步驟包括：

  1. 客戶端Hello：瀏覽器向伺服器發送支援的TLS版本、加密套件列表和隨機數
  2. 伺服器Hello：伺服器選擇TLS版本和加密套件，並回傳伺服器隨機數
  3. 證書驗證：伺服器發送數位證書，瀏覽器驗證證書的有效性和網域匹配
  4. 金鑰交換：雙方協商並生成用於加密通信的對稱金鑰
  5. 握手完成：雙方確認加密參數，開始使用加密通道進行通信
TLS握手流程：
瀏覽器 → 伺服器：Client Hello（支援的加密方法）
瀏覽器 ← 伺服器：Server Hello + 數位證書
瀏覽器驗證證書（檢查CA簽名、網域匹配、有效期）
瀏覽器 ↔ 伺服器：金鑰交換（生成加密金鑰）
瀏覽器 ↔ 伺服器：確認握手完成，啟用加密通信

這個過程確保了後續的HTTP通信是加密且安全的，防止資料被竊聽或篡改。

5. 發送HTTPS請求

TLS握手完成後，瀏覽器會透過加密的安全通道向伺服器發送HTTP請求。這個請求包括請求頭和請求體：

  • 請求頭：包含請求的基本資訊，如方法（GET、POST等）、目標URL、瀏覽器類型（User-Agent）、接受的內容類型等
  • 請求體：通常只在POST請求中包含，用於傳送表單數據或其他內容

HTTP協議結構

HTTP（超文本傳輸協議）是用於傳輸超文本的應用層協議，主要包括請求和回應兩部分：

HTTP請求結構

  • 請求行（Request Line）：包含HTTP方法（如GET、POST）、請求的URL路徑和HTTP協議版本
  • 請求頭（Request Header）：包含元數據，如：
    • Host: 目標伺服器的網域名稱
    • User-Agent: 瀏覽器和作業系統資訊
    • Accept: 可接受的回應內容類型
    • Cookie: 存儲的用戶會話資訊
  • 請求體（Request Body）：包含實際要傳送的數據，主要用於POST、PUT等方法

HTTP回應結構

  • 狀態行（Status Line）：包含HTTP協議版本、狀態碼和狀態描述
  • 回應頭（Response Header）：包含回應的元數據，如：
    • Content-Type: 回應內容的類型（HTML、JSON等）
    • Content-Length: 回應內容的長度
    • Set-Cookie: 要設置的Cookie資訊
    • Cache-Control: 快取控制指令
  • 回應體（Response Body）：包含實際的內容數據，如HTML、CSS、JavaScript、圖片等

HTTPS請求範例

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-TW,zh;q=0.9,en;q=0.8
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Upgrade-Insecure-Requests: 1

6. 伺服器處理請求並回應

伺服器接收到加密的HTTP請求後，會進行以下處理：

  1. 解密請求：使用TLS協商的金鑰解密收到的請求
  2. 解析請求：分析HTTP請求的方法、路徑、標頭和內容
  3. 處理業務邏輯：根據請求執行相應的業務邏輯（如查詢資料庫、處理表單等）
  4. 生成回應：準備要返回的內容和相應的HTTP標頭
  5. 加密回應：使用TLS加密回應內容
  6. 發送回應：透過已建立的加密通道發送回應

HTTP回應的組成

伺服器的回應包括：

  • 狀態碼：表示請求處理的結果

    • 200 OK：請求成功
    • 301/302：重定向到其他URL
    • 404 Not Found：請求的資源不存在
    • 500 Internal Server Error：伺服器內部錯誤

  • 回應頭：包含回應的基本資訊

    • Content-Type：內容類型（如text/html、application/json）
    • Content-Length：內容長度
    • Cache-Control：快取策略
    • Set-Cookie：設置Cookie

  • 回應體：包含實際的數據，如HTML文檔、CSS樣式表、JavaScript腳本、圖片或API數據等

HTTP回應範例

HTTP/1.1 200 OK
Date: Tue, 12 Aug 2025 10:30:00 GMT
Server: nginx/1.18.0
Content-Type: text/html; charset=UTF-8
Content-Length: 2048
Cache-Control: max-age=3600
Connection: keep-alive
 
<!DOCTYPE html>
<html lang="zh-TW">
<head>
    <title>範例網頁</title>
    <meta charset="UTF-8">
</head>
<body>
    <h1>歡迎來到範例網站</h1>
    <!-- HTML內容 -->
</body>
</html>

此時，安全的HTTPS通信已經完成，瀏覽器收到加密的回應後會進行解密，然後開始解析和渲染網頁內容。

7. 瀏覽器解析回應與安全檢查

瀏覽器接收到伺服器的回應後，會進行解析。這包括解析回應頭和回應體，並根據狀態碼判斷請求是否成功。

MIME類型檢測

當回應正文開始傳入時，網絡線程會檢查數據流的前幾個位元組。雖然回應的Content-Type標頭應該指明數據類型，但由於該標頭可能缺失或錯誤，瀏覽器會執行MIME類型嗅探來確定實際的檔案類型。

安全檢查

此時也會執行多項安全檢查：

  • SafeBrowsing檢查：如果網域和回應數據與已知的惡意網站匹配，網絡線程會發出警告。
  • 跨源讀取鎖定（CORB）檢查：確保敏感的跨網站數據不會進入渲染程序。

8. 查找和準備渲染程序

完成所有檢查後，如果網絡線程確認瀏覽器應該導航到請求的網站，就會通知界面線程數據已準備就緒。界面線程隨後會查找渲染程序來繼續渲染網頁。

性能優化策略

由於網絡請求可能需要數百毫秒才能收到回應，瀏覽器採用了重要的優化策略：當界面線程向網絡線程發送URL請求時，它會並行地主動查找或啟動渲染程序。這樣，當網絡線程收到數據時，渲染程序已經處於待機狀態。

跨網站導航處理

如果導航會跨網站重定向，可能不會使用這個待機進程，在這種情況下，需要使用其他進程來確保網站隔離的安全性。

9. 提交導航

現在數據和渲染程序都準備就緒，系統會從瀏覽器進程向渲染進程發送IPC（進程間通信）來提交導航。同時會傳遞數據流，讓渲染程序可以繼續接收HTML數據。

當瀏覽器進程收到渲染程序中已完成提交的確認後，導航就完成了，文檔加載階段隨即開始。此時：

  • 地址欄會更新
  • 安全信號和網站設定界面會反映新頁面的資訊
  • 標籤頁的會話歷史記錄會更新，讓返回/前進按鈕正常工作
  • 會話記錄會儲存到磁碟，方便關閉標籤頁後恢復

10. 解析、渲染和交互頁面

瀏覽器解析HTML文檔並生成DOM樹，解析CSS並生成CSSOM樹，然後將兩者合併生成渲染樹。接著，瀏覽器進行布局計算每個元素的位置和大小，然後進行繪製將元素顯示在屏幕上。這一過程包括以下步驟：

  1. 解析HTML：將HTML字符串分割成標記，然後生成DOM樹。
  2. 解析CSS：將CSS字符串分割成標記，然後生成CSSOM樹。
  3. 生成渲染樹：將DOM樹和CSSOM樹合併，生成渲染樹。
  4. 布局：計算每個元素的位置和大小。
  5. 繪製：將元素繪製到屏幕上。

10-1.解析

當瀏覽器接收到第一個數據片段，就會開始解析收到的訊息。解析（Parse）是指瀏覽器將接收到的數據轉換成DOM和CSSOM的過程。

瀏覽器接收到HTML文件後，會進行解析並生成DOM（Document Object Model）樹。解析過程如下：

  • 詞法分析：將HTML字符串分割成標記（tokens）。
  • 解析：將標記轉換為DOM樹中的節點。

接著，瀏覽器會解析CSS，生成CSSOM（CSS Object Model）樹。然後，瀏覽器將DOM樹和CSSOM樹合併，生成渲染樹(Render Tree)。渲染樹包含了顯示元素所需的所有資訊。

10-2.渲染

布局 Layout

也就是Reflow，瀏覽器將渲染樹做為輸入並計算各節點的大小、顏色、位置、形狀等資訊。負責篩選出顯示於畫面的元素，並將元素安排在畫面中的對應位置與大小。

觸發點:

  • DOM 元素改變
  • 布局相關樣式改變

影響成本高，涉及 DOM tree 的結構變化。

影響樣式:

  • 尺寸相關: width/height、padding/margin/border等
  • 位置相關: position、top/left/right/bottom、vertical-align等
  • 字體相關: font-size、font-family、text-align、line-height等
  • 其他: display、float、overflow等

繪製 Paint

也就是Repaint，針對各圖層擬定繪製指令列表，將元素的每個克見部分繪製到屏幕上。

這包括分層（Layer）、分塊（Tiling）、柵格化（Rasterization）。

  • 分層：瀏覽器會將DOM元素分配到不同的圖層，因為畫面上的元素可能會互相交疊，並且某些元素會有共同的CSS設置，或是變化時機相同的CSS樣式設置。
  • 分塊：每個圖層進一步分割成更小的塊，這樣可以更有效地管理內存和提高渲染效率。
  • 柵格化：將這些分塊轉換成像素，這個過程是由GPU加速完成的，能夠迅速生成最終的圖像。

觸發點:

  • Paint 相關樣式改變 影響樣式:
  • 顏色相關: color、background-color、outline-color等
  • 背景相關: background-image、background-position、background-size等
  • 輪廓相關: outline、outline-width、outline-style等
  • 邊界相關: border-radius、border-style等
  • 其他: visibility、box-shadow、text-decoration等

組合 Composition

當圖層都被柵格化後，組合執行緒（Compositor Thread）將柵格化後的圖層集結成一個組合幀（Compositor Frame），提交給GPU來繪製畫面。

觸發點:

  • 僅透明度和變形樣式改變 影響樣式:
  • opacity
  • transform

10-3.交互 Interactivity

一旦主thread繪製頁面完成，你會認為頁面已經"準備好了"，但事實並非如此。如果頁面包括延遲加載的JavaScript，並且僅在onload事件觸發後執行，那麼主thread可能會忙於執行腳本，無法用於滾動、觸摸和其他交互操作。

可交互時間（TTI）是測量從第一個請求到頁面可交互所用的時間——可交互是在首次內容繪製之後頁面在50毫秒內響應用戶的交互。如果主thread正在解析、編譯和執行JavaScript，則無法及時（小於50毫秒）響應用戶交互。

10-4.初始加載完成

導航提交後，渲染程序會繼續加載資源並渲染頁面。渲染程序"完成"渲染後，會將IPC發送回瀏覽器進程（這發生在網頁中所有frame上的onload事件都觸發並完成執行之後）。此時，界面線程會停止標籤頁上的加載旋轉圖示。

需要注意的是，之所以說"完成"是因為客戶端JavaScript在此之後仍可以加載其他資源並渲染新視圖。

11. 導航到不同網站

我們在導航完成並將網站渲染到瀏覽器後，用戶可能會在地址欄輸入不同的網址，或點擊頁面上的連結。此時瀏覽器會按照相同的步驟導航到其他網站，但在執行此操作前，需要處理一些特殊情況以確保用戶體驗和安全性。

11.1 beforeunload事件處理

當瀏覽器準備離開當前頁面時，必須先與目前渲染的網站確認是否需要處理beforeunload事件。這個機制可以讓網站在用戶離開前執行必要的清理工作或確認操作。

beforeunload事件的作用：

  • 讓網站有機會詢問用戶是否真的要離開（如"您確定要離開此頁面嗎？"）
  • 常用於未保存的表單數據、正在進行的上傳操作等情況
  • 防止用戶意外關閉包含重要操作的頁面

處理流程：

  1. 瀏覽器進程接收到新的導航請求
  2. 通知當前渲染程序即將發生導航
  3. 渲染程序檢查是否有註冊的beforeunload事件處理器
  4. 如果有，執行事件處理器並可能顯示確認對話框
  5. 根據用戶選擇決定是否繼續導航
// beforeunload事件範例
window.addEventListener('beforeunload', function(event) {
    // 如果有未保存的更改
    if (hasUnsavedChanges) {
        event.preventDefault();
        event.returnValue = ''; // 某些瀏覽器需要設置此屬性
        return '您有未保存的更改，確定要離開嗎？';
    }
});

11.2 渲染程序發起的導航

並非所有導航都是由用戶在地址欄輸入觸發的。很多時候，導航是由網頁內容本身發起的：

常見的渲染程序導航情況：

  • 用戶點擊連結：點擊<a>標籤
  • JavaScript導航：執行window.location = "https://newsite.com"或window.location.href
  • 表單提交：提交表單到不同的URL
  • 歷史導航：使用history.pushState()或history.replaceState()

處理機制：

  1. 渲染程序首先檢查beforeunload事件處理器
  2. 如果允許導航，渲染程序通知瀏覽器進程
  3. 瀏覽器進程執行與用戶輸入URL相同的導航流程
  4. 唯一的區別是導航請求的來源（渲染程序 vs 瀏覽器進程）

11.3 跨網站導航的進程管理

當導航的目標網站與當前網站不同時，瀏覽器會採用特殊的進程管理策略來確保安全性和性能：

同源導航 vs 跨源導航：

  • 同源導航：相同協議、網域和端口，通常在同一個渲染進程中處理
  • 跨源導航：不同網域或協議，需要使用不同的渲染進程

跨網站導航流程：

  1. 準備新的渲染進程：瀏覽器為新網站啟動獨立的渲染進程
  2. 保留舊進程：原渲染進程暫時保留，處理unload事件和清理工作
  3. 切換顯示：新頁面載入完成後，切換顯示到新的渲染進程
  4. 清理舊進程：確認舊頁面完全卸載後，終止舊的渲染進程

安全隔離的好處：

  • 記憶體隔離：不同網站無法存取彼此的記憶體空間
  • 崩潰隔離：一個網站崩潰不會影響其他網站
  • 權限隔離：每個網站都有獨立的權限控制
  • 快取隔離：防止跨網站的快取攻擊

11.4 頁面生命週期管理

瀏覽器對頁面有完整的生命週期管理，包括以下狀態：

  • Active：頁面可見且有焦點
  • Passive：頁面可見但無焦點
  • Hidden：頁面不可見（如切換到其他標籤頁）
  • Frozen：頁面暫停執行（節省資源）
  • Terminated：頁面完全終止

可以參考頁面生命週期狀態概覽以及Page Lifecycle API來了解更多詳細資訊。

11.5 Service Worker的特殊處理

Service Worker作為一種特殊的網絡代理，會影響導航過程的處理方式。

Service Worker的基本概念： Service Worker是運行在瀏覽器背景的腳本，可以攔截和處理網絡請求，提供離線功能和快取管理。它獨立於網頁運行，即使關閉網頁，Service Worker仍可繼續運行。

在導航過程中的作用：

  1. 範圍檢查：導航時，網絡線程會檢查目標URL是否在已註冊的Service Worker範圍內
  2. 攔截請求：如果有匹配的Service Worker，它可以攔截導航請求
  3. 快取優先：Service Worker可以選擇從快取返回頁面，無需網絡請求
  4. 網絡回退：如果快取中沒有，再從網絡獲取資源

導航預載入優化： 為了減少Service Worker可能造成的延遲，瀏覽器提供了導航預載入機制：

  • 在Service Worker啟動的同時，並行發起網絡請求
  • 使用特殊標頭標記這些請求
  • Service Worker可以選擇使用預載入的資源或自己的快取

11.6 導航預載入（Navigation Preload）

當使用Service Worker時，可能會遇到一個效能問題：如果Service Worker最終決定從網絡請求數據，瀏覽器進程和渲染程序之間的往返過程可能會導致延遲。為了解決這個問題，瀏覽器引入了導航預載入機制。

問題背景：

  1. 瀏覽器發起導航請求
  2. 檢查到有Service Worker需要處理此請求
  3. 啟動或喚醒Service Worker（這需要時間）
  4. Service Worker決定從網絡獲取資源
  5. 實際發起網絡請求（產生額外延遲）

導航預載入解決方案：

導航預載入是一種聰明的優化機制，它允許瀏覽器在Service Worker啟動的同時並行載入資源，從而避免序列化的延遲。

工作原理：

  1. 並行處理：瀏覽器在喚醒Service Worker的同時，就開始預先發起網絡請求
  2. 特殊標頭：預載入請求會使用Service-Worker-Navigation-Preload: true標頭標記
  3. 伺服器識別：伺服器可以識別這些預載入請求，並決定發送不同的內容
  4. 選擇性使用：Service Worker可以選擇使用預載入的回應或忽略它

伺服器端優化： 伺服器看到導航預載入標頭時，可以採取不同的策略：

  • 完整文檔：對一般請求返回完整的HTML文檔
  • 輕量版本：對預載入請求只返回關鍵數據或更新內容
  • 快取友好：返回更容易快取的資源版本

Service Worker中的使用：

// 啟用導航預載入
self.addEventListener('activate', event => {
    event.waitUntil(
        self.registration.navigationPreload.enable()
    );
});
 
// 在fetch事件中使用預載入的回應
self.addEventListener('fetch', event => {
    if (event.request.mode === 'navigate') {
        event.respondWith(
            Promise.all([
                caches.match(event.request),
                event.preloadResponse  // 這是預載入的回應
            ]).then(([cachedResponse, preloadResponse]) => {
                // 優先使用快取，如果沒有則使用預載入回應
                return cachedResponse || preloadResponse || fetch(event.request);
            })
        );
    }
});
 
// 自定義預載入標頭
self.addEventListener('activate', event => {
    event.waitUntil(
        self.registration.navigationPreload.setHeaderValue('fast-load')
    );
});

效能提升：

  • 減少延遲：消除Service Worker啟動和網絡請求之間的等待時間
  • 更快的首屏：特別對首次訪問或Service Worker重啟後的導航有幫助
  • 彈性選擇：Service Worker可以靈活選擇使用預載入資源或快取

使用場景：

  • 新聞網站：預載入最新文章列表，Service Worker可以合併快取的樣式和預載入的內容
  • 電商平台：預載入產品價格更新，同時使用快取的產品圖片和描述
  • 社交媒體：預載入最新動態，結合快取的界面元素
導航預載入流程示意：

時間線：
t0: 用戶點擊連結
t1: 瀏覽器同時啟動 Service Worker 和 網絡預載入請求
t2: 預載入請求完成 (Service Worker 可能仍在啟動)
t3: Service Worker 啟動完成，可以立即使用預載入的回應
t4: 最終回應返回給用戶

vs 無預載入：
t0: 用戶點擊連結  
t1: 瀏覽器啟動 Service Worker
t2: Service Worker 啟動完成
t3: Service Worker 發起網絡請求
t4: 網絡請求完成
t5: 最終回應返回給用戶 (明顯延遲)

導航預載入是現代瀏覽器優化Service Worker效能的重要技術，它巧妙地平衡了離線能力和載入速度，讓Web應用既能享受Service Worker的強大功能，又不會犧牲使用者體驗。

12. 連線結束

當整個請求-回應週期完成，或用戶關閉頁面後，瀏覽器和伺服器會優雅地終止TCP連線。這個過程稱為TCP四次揮手：

TCP四次揮手過程

  1. 第一次揮手：瀏覽器發送FIN（Finish）包，表示「我沒有更多數據要傳送了」
  2. 第二次揮手：伺服器收到FIN包，回覆ACK包確認收到，表示「我知道你要關閉了」
  3. 第三次揮手：伺服器處理完剩餘數據後，發送FIN包，表示「我也準備關閉了」
  4. 第四次揮手：瀏覽器收到伺服器的FIN包，回覆ACK包，表示「確認關閉」

連線管理優化

現代瀏覽器採用多種技術來優化連線管理：

持久連線（Keep-Alive）：

  • HTTP/1.1默認開啟持久連線
  • 同一個TCP連線可以處理多個HTTP請求
  • 減少建立和關閉連線的開銷

連線池管理：

  • 瀏覽器維護到每個網域的連線池
  • 重用現有連線處理新請求
  • 限制同時連線數量以避免資源耗盡

HTTP/2多路復用：

  • 單一TCP連線可以並行處理多個請求
  • 避免隊頭阻塞問題
  • 提高網絡利用效率
TCP四次揮手示意：
瀏覽器 → 伺服器：FIN（我要關閉了）
瀏覽器 ← 伺服器：ACK（我知道了）
瀏覽器 ← 伺服器：FIN（我也要關閉了）
瀏覽器 → 伺服器：ACK（確認關閉）

這樣的設計確保了雙方都能優雅地關閉連線，避免數據丟失或資源洩漏。

總結

當我們在瀏覽器輸入URL並按下Enter鍵時，瀏覽器會啟動一個複雜但高效的多進程協作流程。從界面線程處理輸入、網絡線程進行DNS查詢和建立連線，到安全檢查、渲染程序準備、導航提交，再到最終的頁面解析和渲染，每個步驟都經過精心設計和優化。

現代瀏覽器還整合了Service Worker、導航預加載等先進技術，並通過多進程架構確保了安全性和穩定性。這一過程涉及多種網絡協議和技術，如DNS、TCP、HTTP，以及瀏覽器內部複雜的解析和渲染機制。理解這些原理有助於我們更好地開發和優化Web應用程式。