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

JavaScript 是如何工作的：深入網(wǎng)絡層 + 如何優(yōu)化性能和安全

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

數(shù)據(jù)包被發(fā)送到遠程服務器

一遠程服務器一旦接收到數(shù)據(jù)包，就會以類似的方式發(fā)回響應。

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

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

先了解一些術語:

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

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

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

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

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

當?shù)氐恼埱??—?23ms

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

洲際請求?——? 225ms

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

協(xié)議

主機

載入文檔的 URL 端口

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

帶有