摘要：是如何工作的深入網絡層如何優化性能和安全這是專門探索及其所構建的組件的系列文章的第篇。為了使網絡層高效，它需要扮演的角色不僅僅是一個簡單的套接字管理器。套接字組織在按源分組的池中，每個池執行自己的連接限制和安全約束。

JavaScript 是如何工作的：深入網絡層 + 如何優化性能和安全

這是專門探索 JavaScript 及其所構建的組件的系列文章的第 12 篇。

如果你錯過了前面的章節，可以在這里找到它們：

JavaScript 是如何工作的：引擎，運行時和調用堆棧的概述！

JavaScript 是如何工作的：深入V8引擎&編寫優化代碼的5個技巧！

JavaScript 是如何工作的：內存管理+如何處理4個常見的內存泄漏 !

JavaScript 是如何工作的：事件循環和異步編程的崛起+ 5種使用 async/await 更好地編碼方式！

JavaScript 是如何工作的：深入探索 websocket 和HTTP/2與SSE +如何選擇正確的路徑！

JavaScript 是如何工作的：與 WebAssembly比較 及其使用場景 !

JavaScript 是如何工作的：Web Workers的構建塊+ 5個使用他們的場景!

JavaScript 是如何工作的：Service Worker 的生命周期及使用場景!

JavaScript 是如何工作的：Web 推送通知的機制!

JavaScript是如何工作的:使用 MutationObserver 跟蹤 DOM 的變化

JavaScript是如何工作的:渲染引擎和優化其性能的技巧

正如在上一篇關于 渲染引擎 的博客文章中提到的，我們認為優秀的 JavaScript 開發人員和杰出的 JavaScript 開發人員之間的區別在于，后者不僅理解語言的具體細節，而且理解其內部結構和周遭環境。

想閱讀更多優質文章請猛戳GitHub博客,一年百來篇優質文章等著你！

49年前，一種叫做 ARPAnet 的網誕生了。它是一個早期的 分組交換網絡，也是第一個 實現TCP/IP套件的網絡。20年后，蒂姆·伯納斯-李提出了一種“網狀結構”的建議，這種結構后來被稱為“萬維網”。在這 49 年里，互聯網走過了漫長的道路，從僅僅兩臺計算機交換數據包，到超過 7500 萬臺服務器、38 億互聯網用戶和 13 億個網站。

"阿帕"（ARPA），是美國高級研究計劃署（Advanced Research ProjectAgency）的簡稱。他的核心機構之一是信息處理（IPTO Information Processing Techniques Office），一直在關注電腦圖形、網絡通訊、超級計算機等研究課題。
阿帕網為美國國防部高級研究計劃署開發的世界上第一個運營的封包交換網絡，它是全球互聯網的始祖。

在這篇文章中，我們將嘗試分析現代瀏覽器使用什么技術來自動提高性能(甚至在你不知道的情況下)，接著深入瀏覽器網絡層。最后，我們將提供一些關于如何幫助瀏覽器提高 Web 應用程序性能的建議。

現代 Web 瀏覽器專為快速，高效，安全地提供網絡應用/網站而設計。 數百個組件在不同的層上運行，從流程管理和安全沙箱到 GPU 管道，音頻和視頻等等，Web 瀏覽器看起來更像是一個操作系統，而不僅僅是一個軟件應用程序。

瀏覽器的總體性能由許多大型組件決定:解析、布局、樣式計算、JavaScript 和 WebAssembly 執行、渲染，當然還有網絡堆棧。

工程師經常認為網絡堆棧是一個瓶頸。這種情況經常發生，因為所有資源都需要從網上獲取，然后才能解除其余步驟的阻塞。為了使網絡層高效，它需要扮演的角色不僅僅是一個簡單的套接字管理器。它提供給我們的是一種非常簡單的資源獲取機制，但實際上它是一個具有自己的優化標準、API 和服務的完整平臺。

作為 Web 開發人員，我們不必擔心多帶帶的 TCP 或 UDP 數據包、請求格式化、緩存和其他一切問題。整個復雜性由瀏覽器負責，因此我們可以將精力集中在我們正在開發的應用程序上。然而，了解底層的情況可以幫助我們創建更快、更安全的應用程序。

本質上，當用戶開始與瀏覽器交互時會發生以下情況:

用戶在瀏覽器地址欄中輸入一個 URL

給定 Web 上資源的 URL，瀏覽器首先檢查其本地緩存和應用程序緩存，并嘗試使用本地副本來完成請求

如果緩存不能使用，瀏覽器從 URL 獲取域名，并從 DNS 請求服務器的 IP 地址。如果域被緩存，則不需要 DNS 查詢

瀏覽器創建一個 HTTP 包，表示它請求位于遠程服務器上的 Web 頁面

數據包被發送到 TCP 層，TCP 層在 HTTP 數據包上添加自己的信息，維護已啟動的會話需要此信息

然后數據包被傳遞給 IP 層，IP 層的主要任務是找出一種將數據包從用戶發送到遠程服務器的方法，這些信息也存儲在包的頂部

數據包被發送到遠程服務器

一遠程服務器一旦接收到數據包，就會以類似的方式發回響應。

W3C的瀏覽時序規范（Navigation Timing specification）提供了一個瀏覽器API，讓我們可以看到瀏覽器中每項請求的生命周期背后的時序和性能數據。讓我們看看這些組成部分，每一塊都是影響最佳用戶體驗的關鍵點：

整個網絡過程非常復雜，有許多不同的層，這可能成為瓶頸。這就是為什么瀏覽器努力通過使用各種技術來提高自己的性能，從而使整個網絡通信的影響最小。

先了解一些術語:

源(Origin) - 由應用程序協議，域名和端口號組成（例如https，www.example.com，443）

套接字池(Socket pool) - 屬于同一源的一組套接字（所有主要瀏覽器將最大池大小限制為6個套接字）

JavaScript 和 WebAssembly 不允許我們管理單個網絡套接字的生命周期，這是一件好事!這不僅使我們的省去較多麻煩，而且還可以讓瀏覽器自動進行許多性能優化，其中包括套接字重用、請求優先級和后期綁定、協議協商、強制連接限制等。

實際上，現代瀏覽器在將請求管理周期與套接字管理分離方面做了更多的工作。套接字組織在按源分組的池中，每個池執行自己的連接限制和安全約束。掛起的請求被排隊、排序，然后綁定到池中的各個套接字。除非服務器有意關閉連接，否則同一個套接字可以跨多個請求自動重用!

由于打開新的 TCP 連接需要額外的成本，因此連接的重用本身就帶來了巨大的性能優勢。默認情況下，瀏覽器使用所謂的 “keepalive” 機制，它可以在發出請求時節省打開到服務器的新連接的時間。打開新 TCP 連接的平均時間為:

當地的請求 ?—?23ms

橫貫大陸的請求?——?120ms

洲際請求?——? 225ms

這種架構為其他一些優化提供了可能， 請求可以根據其優先級以不同的順序執行。 瀏覽器可以優化所有套接字的帶寬分配，也可以在預期請求時打開套接字。

正如之前提到的，這一切都由瀏覽器管理，不需要我們做任何工作，但這并不意味著我們什么都做不了。 選擇正確的網絡通信模式，類型和傳輸頻率，協議選擇以及服務器堆棧的調優/優化可以在提高應用程序的整體性能方面發揮重要作用。

有些瀏覽器甚至更進了一步。 例如，Chrome 可以學習用戶的操作習慣來使自己變得更快。 它根據訪問的站點和典型的瀏覽模式進行學習，以便預測可能的用戶行為并在用戶執行任何操作之前采取措施。 最簡單的例子是當用戶在鏈接上懸停時，Chrome 會預先渲染頁面， 如果有興趣了解有關 Chrome 優化的更多信息，可以查看這篇文章 https://www.igvita.com/posa/h...

允許瀏覽器管理單個套接字還有另一個非常重要的目的:通過這種方式，瀏覽器能夠對不受信任的應用程序資源執行一致的安全和策略約束。例如，瀏覽器不允許 API 直接訪問原始網絡套接字，因為這將使任何惡意應用程序能夠任意連接到任何主機。瀏覽器還強制執行連接限制，以保護服務器和客戶端免于資源耗盡。

瀏覽器格式化所有傳出請求，以強制執行一致且格式良好的協議語義，以保護服務器。類似地，響應解碼是自動完成的，以保護用戶免受惡意服務器的攻擊。

傳輸層安全性協議 (Transport Layer Security, TLS)是一種通過計算機網絡提供通信安全性的加密協議。它在許多應用程序中得到了廣泛的應用，其中之一就是 Web 瀏覽器。網站可以使用 TLS 保護服務器和Web 瀏覽器之間的所有通信。該協議由兩層組成： TLS 記錄協議（TLS Record）和 TLS 握手協議（TLS Handshake）。較低的層為 TLS 記錄協議，位于某個可靠的傳輸協議（例如 TCP）上面。

整個TLS握手包括以下步驟:

客戶端向服務器發送 “Client hello” 消息，與之一同發送的還有客戶端產生的隨機值和支持的密碼套件。

服務器通過向客戶端發送 “Server hello” 消息及服務器產生的隨機值進行響應。

服務器將其證書發送給客戶端，并可以從客戶端請求類似的證書。 服務器發送 “Server hello done” 消息。

如果服務器向客戶機請求了證書，客戶機將發送證書。

客戶端創建一個隨機的 Pre-Master Secret，并使用服務器證書中的公鑰對其進行加密，將加密的 Pre-Master Secret 發送到服務器。

服務器接收 Pre-Master Secret。 服務器和客戶端均基于預主密鑰生成主密鑰和會話密鑰。

客戶端向服務器發送 “Change cipher spec” 通知，以指示客戶端將開始使用新的會話密鑰進行散列和加密消息。 客戶端還發送 “Server finished” 消息。

服務器接收 “Change cipher spec”，并使用會話密鑰將其記錄層安全狀態切換為對稱加密。 服務器向客戶端發送 “Server finished” 消息。

客戶端和服務器現在可以通過他們已建立的安全通道交換應用程序數據。 從客戶端發送到服務器并返回的所有消息都使用會話密鑰加密。

如果任何驗證失敗，則警告用戶 - 例如，服務器正在使用自簽名證書。

同源是指文檔的來源相同，主要包括三個方面

協議

主機

載入文檔的 URL 端口

以下是一些可能嵌入跨源資源的一些例子：

帶有