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

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

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

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

JavaScript 是如何工作的：引擎，運(yùn)行時(shí)和調(diào)用堆棧的概述！

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

JavaScript 是如何工作的：內(nèi)存管理+如何處理4個(gè)常見(jiàn)的內(nèi)存泄漏 !

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

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

JavaScript 是如何工作的：與 WebAssembly比較 及其使用場(chǎng)景 !

JavaScript 是如何工作的：Web Workers的構(gòu)建塊+ 5個(gè)使用他們的場(chǎng)景!

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

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

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

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

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

想閱讀更多優(yōu)質(zhì)文章請(qǐng)猛戳GitHub博客,一年百來(lái)篇優(yōu)質(zhì)文章等著你！

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

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

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

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

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

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

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

本質(zhì)上，當(dāng)用戶開(kāi)始與瀏覽器交互時(shí)會(huì)發(fā)生以下情況:

用戶在瀏覽器地址欄中輸入一個(gè) URL

給定 Web 上資源的 URL，瀏覽器首先檢查其本地緩存和應(yīng)用程序緩存，并嘗試使用本地副本來(lái)完成請(qǐng)求

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

瀏覽器創(chuàng)建一個(gè) HTTP 包，表示它請(qǐng)求位于遠(yuǎn)程服務(wù)器上的 Web 頁(yè)面

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

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

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

一遠(yuǎn)程服務(wù)器一旦接收到數(shù)據(jù)包，就會(huì)以類似的方式發(fā)回響應(yīng)。

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

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

先了解一些術(shù)語(yǔ):

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

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

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

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

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

當(dāng)?shù)氐恼?qǐng)求 ?—?23ms

橫貫大陸的請(qǐng)求?——?120ms

洲際請(qǐng)求?——? 225ms

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

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

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

允許瀏覽器管理單個(gè)套接字還有另一個(gè)非常重要的目的:通過(guò)這種方式，瀏覽器能夠?qū)Σ皇苄湃蔚膽?yīng)用程序資源執(zhí)行一致的安全和策略約束。例如，瀏覽器不允許 API 直接訪問(wèn)原始網(wǎng)絡(luò)套接字，因?yàn)檫@將使任何惡意應(yīng)用程序能夠任意連接到任何主機(jī)。瀏覽器還強(qiáng)制執(zhí)行連接限制，以保護(hù)服務(wù)器和客戶端免于資源耗盡。

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

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

整個(gè)TLS握手包括以下步驟:

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

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

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

如果服務(wù)器向客戶機(jī)請(qǐng)求了證書，客戶機(jī)將發(fā)送證書。

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

服務(wù)器接收 Pre-Master Secret。 服務(wù)器和客戶端均基于預(yù)主密鑰生成主密鑰和會(huì)話密鑰。

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

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

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

如果任何驗(yàn)證失敗，則警告用戶 - 例如，服務(wù)器正在使用自簽名證書。

同源是指文檔的來(lái)源相同，主要包括三個(gè)方面

協(xié)議

主機(jī)

載入文檔的 URL 端口

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

帶有