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

標籤：運行環境   link   生命週期   列表   ring   example   安全   flow   串連數   

個人總結:閱讀完這篇文章需要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工作原理) (十二) 網路層探秘及如何提高其效能和安全性