個人總結:閱讀完這篇文章需要20分鐘，這篇文章主要講解了現代瀏覽器在網絡層傳輸所用到的一些技術。

這是 JavaScript 工作原理的第十二章。

正如在之前關於渲染引擎的文章中所講的那樣，我們相信好的和偉大的 JavaScript 開發者之間的差別在於後者不僅僅只是理解了語言的具體細節還了解其內部構造和運行環境。

網絡簡史

49 年前，ARPAnet 誕生了。它是早期的報文分組交換網絡及第一個實現 TCP/IP 協議套件的網絡。該網絡連通了加利福亞大堂和斯坦福研究所。20 年後，Tim Berners-Lee 分發了一個後來為人所熟知的萬維網的 『Mesh』草案。在 49 年的時間裏，網絡走過了一段漫長的旅程，從僅僅只是是兩臺電腦間交換數據報文到至少 7500 萬臺服務器，38 億人使用互聯網以及 13 億個網站。

本文將試著分析現代瀏覽器使用哪些技術來自動提升應用性能(有些你甚至不了解)，然後著重介紹瀏覽器網絡層。最後，提供一些讓瀏覽器提升網絡應用程序性能的技巧。

概述

現代瀏覽器專門為快速，高效和安全數據傳輸的網絡應用/網站而設計開發的。擁有數以百計的組件運行於各個不同的層級，從進程管理和安全沙箱到 GPU 管線，音頻和視頻及其它更多等等，網絡瀏覽器更類似於一個操作系統而不僅僅只是一個軟件。

瀏覽器的整體性能是由一些大型的組件所決定的，這些組件包括：解析，布局，樣式計算，JavaScript 和 WebAssembly 執行，渲染，當然還有網絡堆棧。

一般情況下，工程師們會把網絡堆棧看成是一個性能瓶頸。經常會發生這樣的情況因為從網絡抓取所有的資源會堵塞渲染剩下的步驟。為了更加高效的網絡層，它需要不僅僅只是扮演套接字管理員的角色。在我們看來獲取資源是一個非常簡單的機制，但是實際上它集成自身的優化準則，接口和服務的一整套平臺。

網頁開發者不需要擔心單獨的 TCP 或者 UDP 數據包，請求格式化，緩存以及其它正在發生的一切。瀏覽器會處理這些復雜的玩意，這樣就可以專註開發自己的程序。但是，知道其內部的原理可以幫助開發者開發出更加高效和安全的程序。

本質上，當用戶開始和瀏覽器發生交互所產生的情況如下：

• 用戶在瀏覽器地址欄中輸入 URL 地址。
• 在網絡上查找指定 URL 的資源，瀏覽器開始檢查本地和應用程序緩存並試著使用本地副本來響應資源的請求。
• 當緩存不可用，瀏覽器使用 URL 中的域名然後根據域名從 DNS 處獲取服務器的 IP 地址。如果有域名緩存，將不需要進行 DNS 查詢。
• 瀏覽器創建一個 HTTP 報文表明其請求遠程服務器的某個網頁。
• 報文被傳輸到 TCP 層，該層會在 HTTP 報文頭部添加其自身的信息。該信息是保持創建的會話的必要信息。
• 然後在 IP 層處理報文，該層的主要職責即找出從用戶發送報文到遠程服務器的路徑。在 HTTP 報文頭部添加該路徑信息。
• 傳輸報文到遠程服務器。
• 一旦接收到報文，以類似的方式返回響應數據。

W3C Navigation Timing specification 提供了瀏覽器接口及瀏覽器中每個請求背後的可視化計時和性能數據。讓我們瀏覽下這些組件，因為每個組件在獲取最佳用戶體驗方面扮演了重要的角色。

整個網絡請求過程是相當復雜的並且有許多的層次結構，每一層都有可能成為性能瓶頸。這就是為什麽瀏覽器使用各種技術努力提升其性能，以便把整個網絡通信的性能損耗降至最低。

套接字管理

看些新技術吧：

• 源－由應用程序協議，域名和端口號的三個部分組成(比如 https, www.example.com, 443)
• 套接字池－屬於同源的一組套接字(所有的主流瀏覽器都限制套接字池最多只能有 6 個套接字)

JavaScript 和 WebAssembly 禁止開發者操作單獨的網絡套接字的生命周期，這樣是相當的明智的。這樣不僅僅可以讓你頭發少掉點而且可以讓瀏覽器自動優化大量的性能，這些性能包括套接字重用，請求優化和延遲綁定，協議協商，強制連接限制及其它的優化措施。

實際上，現代瀏覽器更一步地將請求管理周期從套接字管理中剝離了出來。用套接字池來組織套接字，以源來分組套接字，每個套接字池強制限制其連接數和安全約束。排隊，優先化等待的請求，然後和套接字池中的單個套接字綁定。如果不是服務器主動關閉這些連接，多個請求可以自動重用相同的套接字。

由於創建一個新的 TCP 連接會帶來額外的性能開銷，重用連接會為其自帶來極大的性能提升。默認情況下，當發起請求的時候，瀏覽器使用所謂的 『keepalive』機制以節省創建到服務器的新連接所耗費的時間。創建一個新的 TCP 連接的平均時間為：

• 本地請求－23 毫秒
• Transcontinental 請求－120 毫秒
• Intercontinental 請求－225 毫秒

這樣的架構衍生出了一些其它的優化方法。請求可以依據優先級來以不同的順序執行。瀏覽器可以優化所有套接字間的帶寬分配或者它可以創建套接字以等待預期的請求。

如上所述，這些都是瀏覽器所控制而不用開發者進行幹預。但這並不意味著我們無所事事了。選擇正確的數據傳輸所用的網絡通信模式，類型和頻率，正確的協議類型以及正確的服務器堆棧隧道/優化對於提升整個程序的性能有著至關重要的作用。

一些瀏覽器甚至更進一步。例如，當你使用 Chrome 的時候，當用戶使用的時候它會進行自我學習從而變得更加快速。它基於訪問過的網頁和典型的瀏覽器模式來進行學習，這樣就可以預期可能的用戶行為且在用戶進行任意操作之前進行操作。最簡單的例子即當用戶懸停在某個鏈接上的時候預渲染頁面。如果你想學習更多關於 Chrome 優化技術的文章，可以查看 High-Performance Browser Networking 這本書的 https://www.igvita.com/posa/high-performance-networking-in-google-chrome/章節。

網絡安全和沙箱

允許瀏覽器操作單獨的套接字有另一個非常重要的目的即：瀏覽器就可以針對不被信任的程序資源強制實施一套一致的安全和政策約束措施。例如，瀏覽器禁止通過 API 直接訪問原始網絡套接字，因為這樣會導致任意可疑的程序隨意連接任意主機。瀏覽器也強制連接數限制以保護服務器免受由於客戶端訪問而耗盡其資源。

瀏覽器格式化所有流出的請求以強制格式正確和一致的協議語義來保護服務器。同樣地，瀏覽器會自動解碼響應內容以保護用戶免受可疑服務器的攻擊。

TLS 協商

Transport Layer Security (TLS) 是一個為計算機網絡提供通信安全的加密協議。它廣泛應用於大量應用程序，其中之一即瀏覽網頁。網站可以使用 TLS 來保證服務器和網頁瀏覽器之間的所有通信安全。

整個 TLS 握手過程包含以下幾個步驟：

1. 客戶端向服務器發送 『Client hello』 信息，附帶著客戶端隨機值和支持的密碼組合。
2. 服務器返回給客戶端 『Server hello』信息，附帶著服務器隨機值。
3. 服務器返回給客戶端認證證書及或許要求客戶端返回一個類似的證書。服務器返回『Server hello done』信息。
4. 如果服務器要求客戶端發送一個證書，客戶端進行發送。
5. 客戶端創建一個隨機的 Pre-Master 密鑰然後使用服務器證書中的公鑰來進行加密，向服務器發送加密過的 Pre-Master 密鑰。
6. 服務器收到 Pre-Master 密鑰。服務器和客戶端各自生成基於 Pre-Master 密鑰的主密鑰和會話密鑰。
7. 客戶端給服務器發送一個 『Change cipher spec』的通知，表明客戶端將會開始使用新的會話密鑰來哈希和加密消息。客戶端也發送了一個 『Client finished』的消息。
8. 服務器接收到『Change cipher spec』的通知然後使用會話鑰匙來切換其記錄層安全狀態為對稱加密狀態。服務器返回客戶端一個 『Server finished』消息。
9. 客戶端和服務器現在可以通過建立的安全通道來交換程序數據。所有客戶端和服務器之間發送的信息都會使用會話密鑰進行加密。

每當發生任何驗證失敗的時候，用戶會收到警告。比如服務器使用自簽名的證書。

同源策略

當兩個頁面的協議，端口(如果有指定)以及主機名都是一樣的則稱為同源。

以下為一些可能包含跨域的資源示例：

• <script src=”…”></script> 裏面的 JavaScript 代碼。語法錯誤的錯誤信息僅適用於同源腳本。
• <link rel=”stylesheet” href=”…”> 的 CSS。由於 CSS 的松散語法規則，跨域 CSS 要求正確的 Content-Type 頭。各個瀏覽器的限制不同。
• <img> 圖片
• <video> 和 <audio> 媒體文件
• <object>, <embed> 和 <applet> 插件
• @font-face 字體。一些瀏覽器允許跨域字體，其它則要求同源字體。
• 和 <iframe> 相關的一切內容。網站可以使用 X-Frame-Options 頭來防止此種跨域交互。

以上的列表還遠遠不夠；該列表旨在強調工作中的『最小特權』原則。瀏覽器只為應用程序代碼暴露出其所必需的接口和資源：應用提供數據和 URL 地址，然後瀏覽器格式化請求及處理每條連接的整個生命周期。

需要註意的是並沒有一個簡單的 『同源策略』概念。

相反，有一系列相關的機制來強制限制瀏覽器的 DOM 訪問，cookie 和 會話狀態管理，網絡連接和其它組件。

資源和客戶端狀態緩存

最好和最快的請求即不創建請求。在分派一個請求前，瀏覽器自動檢查其資源緩存，進行必要的驗證檢查然後當指匹配指定的條件時返回一份本地資源拷貝。如果緩存中沒有可用的本地資源，則發起網絡請求然後把響應內容自動放置於緩存中以備之後的訪問(如果這是被允許的)。

• 瀏覽器自動為每個資源求值緩存指令。
• 當條件允許時，瀏覽器自動重新恢復過期資源
• 瀏覽器自動處理緩存和資源回收的大小

管理一個高效和優化的資源緩存是非常困難的。謝天謝地，瀏覽器為我們處理了整個復雜的玩意，而我們所需要做的即保證服務器返回恰當的緩存指令；想了解更多可以看 客戶端資源緩存 文章。你為網頁上的所有資源添加 Cache-Control，ETag，和 Last-Modified 的響應頭信息。

最後，一個經常被忽略但至關重要的瀏覽器功能即其提供了驗證，會話和 cookie 管理。瀏覽器為每個源維護單獨的『cookie jars』，通過提供必要的程序和服務器接口來讀寫新的 cookie，會話和認證數據，以及自動掛載和處理適當的 HTTP 頭來為我們自動處理整個過程。

例子：

一個簡單但明了的用來展示瀏覽器的延遲會話狀態管理的方便性的例子即：多個選項卡或者瀏覽器窗口可以共享一個認證會話，反之亦然；一個選項卡中的登出操作可以使所有其它打開窗口的會話失效。

應用程序接口和協議

了解了網絡服務之後，最終要講到應用程序接口和協議。眾所周知，更底層的結構提供了一組廣泛的重要服務：套接字和連接管理，請求和響應處理，各種安全策略，緩存及其它更多的強制措施。每當初始化一個 HTTP 請求或者 XMLHttpRequest，一個持久的服務推事件或者 WebSocket 會話抑或打開一個 WebRTC 連接，我們就是在和部分或者所有這些底層服務進行交互。

沒有單一的最佳協議或者接口。每個復雜的程序都會基於不同的要求混合使用不同的傳輸協議：和瀏覽器緩存的交互，協議開銷，消息延遲，可靠性，數據傳輸類型以及其它。一些協議擁有低數據傳輸延遲的特性(比如服務器推事件，WebSocket)，但是可能不符合其它重要的場合，比如利用瀏覽器緩存或者支持任意情況下的二進制數據傳輸的能力。

擴展

關於字體文件的跨域問題可以查看這裏和這裏。

How Javascript works (Javascript工作原理) (十二) 網絡層探秘及如何提高其性能和安全性