輸入 URL 後到頁面渲染
在瀏覽器中輸入 URL 到頁面渲染的整個過程可以分為多個步驟。這個過程涉及瀏覽器、作業系統、網路以及伺服器的協作。我們可以把這個過程概括為以下幾個主要階段：
1. DNS 解析
當你在瀏覽器中輸入一個 URL 並按下回車時，瀏覽器首先會解析這個 URL。URL 通常包括協議（如 http 或 https）、域名（如 example.com）或 IP 地址、埠和路徑。
如果 URL 包含的是域名而不是IP地址，瀏覽器需要透過DNS（域名系統）解析來獲取該域名對應的伺服器IP地址。
本地域名伺服器查詢：瀏覽器首先會查詢本地快取中是否有該域名對應的 IP 地址。如果快取中找不到，它會向本地域名伺服器發起請求。
根域名伺服器查詢：如果本地域名伺服器沒有找到結果，它會請求根域名伺服器。根域名伺服器會返回與該域名相關的頂級域名伺服器（如
.com、.net等）的地址。頂級域名伺服器查詢：接下來，本地域名伺服器向返回的頂級域名伺服器發起查詢，頂級域名伺服器會返回具體管理該域名的伺服器地址。
目標域名伺服器查詢：本地域名伺服器向目標域名伺服器發起查詢，目標伺服器返回具體的 IP 地址。
DNS 快取：本地伺服器將查詢到的 IP 地址返回給使用者，並且會將該 IP 地址快取起來，供未來快速訪問。
2. TCP 協議 —— 三次握手（建立連線）
獲取了伺服器的 IP 地址後，瀏覽器會與伺服器建立 TCP 連線。這時會涉及三次握手的過程：
三次握手步驟：
客戶端傳送連線請求（SYN） ：客戶端向伺服器傳送一個帶有 SYN 標誌位的請求，表示希望建立連線。此時客戶端處於 SYN-SENT 狀態。
伺服器確認請求並回復（SYN + ACK） ：伺服器收到連線請求後，會回覆一個帶有 SYN 和 ACK 標誌的報文，表示接受連線請求並確認。此時伺服器進入 SYN-RECEIVED 狀態。
客戶端確認收到回覆（ACK） ：客戶端接收到伺服器的確認後，再次傳送一個帶有 ACK 標誌的確認資訊，表明連線建立完成。此時雙方都進入 ESTABLISHED 狀態，連線成功建立。
為什麼一定要三次握手，兩次行不行？
這時，面試官就會問，一定要三次握手嗎？兩次握手不行嗎？答案當然是不行；
如果只使用兩次握手，有可能會出現以下情況：
客戶端傳送了一個連線請求SYN報文後，由於網路擁塞等原因，這個報文丟失了， 客戶端超時後重新發送了一個新的SYN報文，建立了連線並進行了數據傳輸。但是在連線關閉之後， 第一次傳送的那個SYN報文突然又到達了服務端，按照兩次握手的方式，服務端會誤以為這是一個新的連線請求， 併發送SYN+ACK進行確認，進而建立一個無效的連線，浪費效能。而三次握手就能避免這種情況， 因為服務端在收到第一個SYN報文時會回覆SYN+ACK，但如果沒有收到客戶端的確認ACK，就不會建立連線。
3. HTTP 數據傳輸
TCP 連線建立之後，瀏覽器會向伺服器傳送 HTTP 請求進行數據傳輸。關於 HTTP 協議有以下幾個版本：
HTTP 0.9 —— 超文字傳輸協議的起源
HTTP 0.9 是最初版本的 HTTP 協議，專為實驗室設計，用於傳輸簡單的 HTML 文字。這個版本極為簡化，只有請求行，格式為 GET /index.html。伺服器接收請求後，只返回 HTML 文字內容，且使用 ASCII 編碼。雖然 HTTP 0.9 能夠基本傳輸超文字檔案，但它無法傳輸其他型別的資原始檔，且沒有請求頭或響應頭，導致伺服器與客戶端之間的通訊能力非常有限。
HTTP 1.0 —— 支援更多資源的傳輸
隨著網際網路的發展，不僅僅是 HTML 檔案，還有圖片、音訊、影片等多種型別的資源需要傳輸，HTTP 0.9 已無法滿足需求。因此，HTTP 1.0 增加了請求頭和響應頭，允許客戶端和伺服器之間的更多交流，傳輸不同型別的資源。
請求頭：客戶端可以透過請求頭來告知伺服器所期望的資料型別和格式，如：
accept：text/html—— 表示期望返回 HTML 檔案。accept-encoding: gzip, deflate, br—— 指定支援的壓縮格式。accept-language: zh-CN,zh;q=0.9,en;q=0.8—— 指定優先的語言。accept-charset: utf-8—— 指定使用的字元編碼。響應頭：伺服器透過響應頭告知客戶端返回的資料型別、編碼方式等，如：
content-type: text/html—— 返回 HTML 檔案。content-encoding: gzip—— 指定內容已使用 gzip 壓縮。
此外，HTTP 1.0 還引入了 HTTP 狀態碼，如 200（成功）、404（未找到）、500（伺服器錯誤），用於指示請求的處理結果。
HTTP 1.1 —— 持久連線與虛擬主機支援
HTTP 1.0 的一個主要問題是短連線。每次請求都會建立一次 TCP 連線，響應結束後就關閉連線，這樣對伺服器資源消耗較大。爲了解決這個問題，HTTP 1.1 引入了長連線，即 TCP 連線在一次請求結束後不會立即關閉，多個請求可以複用同一個連線。這提高了效能，減少了連線建立和斷開的開銷。
HTTP 1.1 版本有以下一些特性：
HTTP 隊頭阻塞：HTTP 1.1 雖然支援長連線，但多個請求在同一條 TCP 連線中傳送時，如果前一個請求未完成，後面的請求會被阻塞，導致效率降低。
虛擬主機支援：HTTP 1.1 增加了
HOST頭欄位，允許一臺伺服器透過一個 IP 地址託管多個域名。Cookie 支援：HTTP 1.1 透過 Cookie 實現了使用者狀態管理，使得網站可以記住使用者的登入狀態等資訊。
HTTP 2.0 —— 多路複用與頭部壓縮
雖然 HTTP 1.1 的長連線改善了效能，但仍存在頻寬利用率低的等問題。主要體現在以下方面：
TCP的慢啟動：TCP的慢啟動演算法是用來控制新建立的連線初期的流量，避免突然大量的資料涌入網路造成擁塞。在慢啟動階段，傳送方最初只會傳送少量的數據段（通常是一個MSS，最大報文段長度），然後根據收到的確認逐步增加發送速率。
同時開啟的多條TCP連線相互競爭頻寬：當一個客戶端同時與伺服器建立了多個TCP連線時，這些連線可能會相互競爭有限的頻寬資源。
http隊頭阻塞：HTTP/1.1中的隊頭阻塞是指在一個TCP連線中，後續請求的處理必須等待前面請求的響應才能開始的問題。即使伺服器已經準備好傳送多個響應，但如果前面的響應沒有完全傳送完畢，後面的響應也無法開始傳輸。
對此 HTTP 2.0 引入了多項最佳化措施，提升了協議效率：
多路複用：HTTP 2.0 在單一 TCP 連線上支援同時傳送多個請求和響應，避免了 HTTP 1.1 中的隊頭阻塞。它透過一個二進制分幀層將請求和響應分解為多個幀，每個幀帶有唯一的 ID，瀏覽器和伺服器透過 ID 來區分和組合資料。這大大提高了傳輸效率，且避免了多個 TCP 連線之間的頻寬競爭。
優先順序控制：在多路複用中，重要的資源可以被打上高優先順序標記，伺服器會優先傳輸這些資源（例如頁面的 CSS 和 JavaScript 檔案）。
頭部壓縮：HTTP 2.0 引入了頭部壓縮，減少了請求和響應中頭部欄位的冗餘資料，提升了頻寬利用率。
HTTPS VS HTTP
HTTPS 是在 HTTP 基礎上增加了 TLS（Transport Layer Security）協議 的加密層，用來確保數據傳輸的安全性。它的主要工作機制包括：
對稱加密：傳輸的資料會使用雙方共享的金鑰進行加密和解密，保證數據傳輸的機密性。
非對稱加密：在通訊開始時，客戶端生成金鑰，伺服器生成公鑰和私鑰。客戶端使用伺服器的公鑰加密其生成的金鑰，併發送給伺服器，伺服器用私鑰解密，確保雙方可以安全地共享一個金鑰用於後續的對稱加密。
透過 HTTPS，傳輸的資料在網路中是加密的，避免了敏感資訊被竊取或篡改。
TCP 和 UDP 的區別
TCP（Transmission Control Protocol）—— 可靠的傳輸協議
TCP 是一種面向連接的傳輸層協議，它提供可靠、順序的數據傳輸，廣泛應用於對數據傳輸質量要求較高的場景。
特點：
可靠性：
建立連線：TCP 透過三次握手機制確保客戶端和伺服器成功建立連線後，纔開始傳輸資料。透過四次揮手來安全斷開連線，保證傳輸完整性。
流量擁塞控制：TCP 內建了流量控制和擁塞控制機制，透過檢測網路的負載情況，自動調節數據傳輸速度，避免網路過載。
超時重傳機制：如果資料包在傳輸中丟失或沒有被及時確認，TCP 會自動觸發重傳，確保所有資料都能準確無誤地到達目的地。
有序性：
TCP 將傳輸的資料分成多個包，使用序列號來確保資料包的順序傳遞。如果資料包到達順序有誤，TCP 會根據序列號進行重新排序，確保資料按照正確順序到達接收方。
應用場景：
網頁瀏覽：保證網頁內容的完整性。
檔案傳輸：如 FTP 協議，確保檔案不丟失、不損壞。
電子郵件：確保郵件內容的準確性。
TCP 適用於需要高可靠性傳輸的場景，如：
UDP（User Datagram Protocol）—— 高效的傳輸協議
UDP 是一種面向無連線的傳輸層協議，強調傳輸速度和效率，而不保證資料的可靠傳輸和順序。UDP 常用於對實時性要求較高的應用場景。
特點：
不可靠性：
無連線：UDP 在傳送資料前不需要建立連線，直接將資料包傳送給目標地址，不會等待確認。這樣雖然減少了延時，但也帶來了不可靠性。
無流量控制和擁塞控制：UDP 不具備 TCP 的流量控制和擁塞控制功能，資料包的傳送不會受到網路狀況的調節，因此有可能導致資料丟失或過載。
不管丟包：UDP 不會檢測資料包是否丟失，也不會進行重傳。這使得它在傳輸過程中，可能有資料丟失，但這也帶來了高效性。
高效：
由於沒有建立連線的過程，也沒有流量控制和丟包重傳機制，UDP 的傳輸速度快，延遲低，特別適合需要快速傳輸資料的場景。
應用場景：
直播：如影片或音訊直播，允許偶爾的資料丟失而不影響整體體驗。
線上遊戲：遊戲中的實時性要求高，UDP 的低延遲可以提供更流暢的遊戲體驗。
視訊通話：實時影片和音訊需要低延遲傳輸，丟失少量資料不會影響通話質量。
UDP 適用於對傳輸可靠性要求不高，但對實時性要求較高的應用場景，如：
HTTP 3.0 —— 解決隊頭阻塞與連線延遲
雖然 HTTP 2.0 引入了多路複用，但它仍然依賴於 TCP 協議，存在TCP 隊頭阻塞的問題。HTTP 3.0 基於 QUIC（Quick UDP Internet Connections）協議，這是一個整合了 TCP 優勢並基於 UDP 的全新協議，解決了 TCP 的一些固有問題。
隊頭阻塞的解決：在 TCP 中，超時重傳機制導致隊頭阻塞，即一個數據包丟失後，後續所有資料包都必須等待重傳的完成。QUIC 透過多條獨立的數據流，丟失的包不會影響其他包的傳輸。
快速握手：TCP 在建立連線時需要三次握手，而 QUIC 的連線建立速度更快，減少了握手延遲，提升了頁面載入速度。
整合 TLS 加密：QUIC 整合了 TLS 加密層，進一步增強了數據傳輸的安全性。
4. TCP 協議 —— 四次揮手（斷開連線）
在通訊完成後，瀏覽器和伺服器透過四次揮手來斷開 TCP 連線。四次揮手確保雙方都能安全地結束數據傳輸，不會丟失任何未傳送的內容。
四次揮手步驟：
客戶端傳送斷開請求（FIN） ：客戶端發出一個帶有 FIN 標誌位的報文，表示希望斷開連線，進入 FIN-WAIT-1 狀態。
伺服器回覆確認（ACK） ：伺服器接收到斷開請求後，返回一個 ACK 報文，表示確認接收到斷開請求，但它可能還有資料要傳送，進入 CLOSE-WAIT 狀態。
伺服器完成數據傳輸後傳送斷開請求（FIN） ：伺服器傳送完剩餘資料後，向客戶端發出 FIN 請求，表示它準備好斷開連線，進入 LAST-ACK 狀態。
客戶端確認斷開（ACK） ：客戶端接收到伺服器的 FIN 報文後，返回一個 ACK 報文，進入 TIME-WAIT 狀態，並等待 2MSL（最大段生命週期）時間，確保伺服器接收到確認訊息。隨後，客戶端和伺服器都進入 CLOSED 狀態，連線正式斷開。
5. 瀏覽器開始渲染頁面
瀏覽器接收到伺服器的響應後，開始處理響應內容。這個過程包含多個步驟，尤其是在渲染 HTML 頁面時非常複雜：
HTML 解析與 DOM 樹的構建
當瀏覽器開始載入頁面時，首先會解析 HTML 檔案，並將 HTML 轉換為 DOM 樹（Document Object Model）。DOM 樹中的每個節點代表一個 HTML 標籤，它們以樹狀結構表示頁面的層次關係。
CSS 解析與 CSSOM 樹的構建
與此同時，瀏覽器會解析 CSS 檔案或嵌入式樣式，構建 CSSOM（CSS Object Model）樹。CSSOM 樹儲存了每個 DOM 節點的樣式資訊。
合成構建 Render Tree
瀏覽器將 DOM 樹和 CSSOM 樹結合起來，生成一棵新的渲染樹（Render Tree） 。渲染樹的每個節點對應一個可見的元素，它包含了 DOM 元素的視覺資訊（例如尺寸、位置、顏色等）。在這個過程中，某些不參與渲染的元素（如 display: none 的元素）不會被新增到渲染樹中。
迴流（Reflow）
一旦渲染樹建立完畢，瀏覽器開始計算每個元素在頁面中的具體位置和大小，這個過程稱為佈局（Layout） ，也稱為迴流（Reflow） 。它決定了頁面的幾何屬性，包括每個元素的尺寸、位置、邊距等。
首次佈局：在頁面初次渲染時，瀏覽器會遍歷渲染樹，為每個可見元素計算它們在頁面中的確切位置和尺寸。這個過程稱為初次迴流，因為頁面的每個部分都要計算和排列。
後續迴流：當頁面的元素結構或佈局屬性（如
width、height、margin等）發生變化時，瀏覽器需要重新計算這些元素及其相關元素的佈局，這個過程也被稱為迴流。
迴流的觸發原因：
DOM 結構的變化（增加或刪除元素）。
元素的幾何屬性（如寬度、高度、邊距）發生變化。
瀏覽器視窗大小的變化。
讀取某些會導致重新計算佈局的屬性（如
offsetHeight、clientWidth等）。
重繪（Repaint）
佈局完成後，瀏覽器開始為每個元素填充顏色、繪製邊框、應用陰影和文字等，這個過程稱為繪製（Paint） ，如果佈局沒有發生變化但樣式發生了變化（例如顏色、背景、字型等），則會觸發重繪（Repaint） 。
重繪的觸發原因：
元素的視覺屬性（如
color、background-color、border-color等）發生變化。雖然元素的幾何屬性沒有變化，但它的外觀發生了變化，瀏覽器需要將它重新繪製出來。
重繪的代價較迴流小，因為它不涉及重新計算佈局，只需要重新繪製改變了樣式的部分。
總結
從輸入 URL 到頁面的渲染是一個複雜的過程，在數據傳輸時，首先需要進行TCP建立連線，再透過HTTP進行資料得傳輸；然後再到頁面的渲染，重繪不一定會觸發迴流，而回流是一定會導致重繪的，因為迴流之後，需要重新去繪製頁面。
