就像我們之前文章中提到的襯着引擎一樣，我們以為好的和優異的JavaScript開闢人員之間的區分在於，後者不僅相識言語的基本要素，還要相識其內部道理和周圍環境。

汗青

四十九年前，豎立了一個名為ARPAnet的東西。這是一個初期的分組交流收集，也是完成TCP / IP套件的第一個收集。該收集在加州大學和斯坦福研討院之間豎立了聯絡。 20年後，Tim Berners-Lee宣布了一個名為“Mesh”的提案，該提案厥後更加人稱為萬維網。在那49年裡，互聯網已走過了冗長的途徑，從兩台盤算機交流數據包最先，抵達凌駕7500萬台效勞器，38億人運用互聯網和1.3B網站。

在這篇文章中，我們將嘗試剖析當代閱讀器採納哪些手藝來自動提拔機能，而且我們將迥殊放大閱讀器收集層。末了，我們將供應一些關於怎樣協助閱讀器提拔Web運用機能的主意。

概觀

當代收集閱讀器專為疾速，高效和平安地託付收集運用/網站而設想。數百個組件運行在差別的層上，從流程治理和平安沙箱到GPU流水線，音頻和視頻等等，Web閱讀器看起來更像是一個操縱系統，而不僅僅是一個軟件運用程序。

閱讀器的團體機能取決於很多大型組件：剖析，規劃，款式盤算，JavaScript和WebAssembly實行，襯着，固然另有收集客棧。

工程師常常以為收集客棧是一個瓶頸。這通常是這類狀況，因為在消除其他步驟之前，須要從互聯網獵取一切資本。為了進步收集層的效力，它不僅須要飾演簡樸的套接字治理員的角色。它作為一種異常簡樸的資本獵取機制顯現給我們，但它實際上是一個具有自身的優化範例，API和效勞的悉數平台。

作為Web開闢人員，我們沒必要憂鬱單個TCP或UDP數據包，要求花樣化，緩存和其他一切事變。悉數複雜性由閱讀器處置懲罰，因而我們能夠專註於我們正在開闢的運用程序。然則，相識發作了什麼，能夠協助我們豎立更快，更平安的運用程序。

實質上，用戶最先與閱讀器交互時發作了以下狀況：

• 用戶在閱讀器地點欄中輸入一個URL
• 給定Web上資本的URL，閱讀器起首搜檢當地和運用程序緩存，並嘗試運用當地副原本完成要求。
• 假如緩存沒法運用，閱讀器將從URL中獵取域名，並從DNS要求效勞器的IP地點。假如該域被緩存，則不須要DNS查詢。
• 閱讀器會豎立一個HTTP數據包，申明它要求位於長途效勞器上的網頁。
• 數據包被發送到TCP層，在TCP數據包的頂部增加它自身的信息。此信息是庇護啟動會話所必須的。
• 然後將數據包交給IP層，重要事情是找出將數據包從用戶發送到長途效勞器的體式格局。這些信息也存儲在數據包的頂部。
• 數據包被發送到長途效勞器。
• 一旦收到數據包，就會以相似的體式格局發送回應。

W3C Navigation Timing範例供應閱讀器API以及閱讀器中每一個要求的生命周期背地的時候和機能數據。讓我們來看看這些組件，因為它們在供應最好用戶體驗方面起着至關重要的作用：

悉數聯網歷程異常複雜，有很多差別的條理能夠會成為瓶頸。這就是為何閱讀器勤奮經由過程運用種種手藝來進步機能的緣由，以便悉數收集通訊的影響最小。

套接字治理

讓我們從一些術語最先：

• Origin – 運用協定，域名和端口號（比方https，www.example.com，443）
• 套接字池 – 屬於統一Origin的一組套接字（一切主流閱讀器都將最大池大小限定為6個套接字）

JavaScript和WebAssembly不許可我們治理單個收集套接字的生命周期，這是一件功德！這不僅能夠讓我們的手保持清潔，而且還能夠讓閱讀器自動舉行大批的機能優化，个中一些包含套接字重用，要求優先級和後期綁定，協定協商，強迫銜接限定等等。

實際上，當代閱讀器會消費更多的時候來將要求治理周期與套接字治理離開。套接字按池構造，按原點分組，每一個池強迫實行自身的銜接限定和平安束縛。待處置懲罰的要求列隊，優先，然後綁定到池中的單個套接字。除非效勞器故意封閉銜接，不然能夠在多個要求中自動重用雷同的套接字！

因為新的TCP銜接的開通須要分外的本錢，因而銜接的重複運用對其自身具有很大的機能上風。默許狀況下，閱讀器運用所謂的“keepalive”機制，這能夠節省在發出要求時翻開新銜接到效勞器的時候。翻開一個新的TCP銜接的均勻時候是：

• 當地要求 – 23ms
• 橫貫大陸的要求 – 120毫秒
• 洲際要求 – 225毫秒

這類架構翻開了其他一些優化時機的大門。這些要求能夠依據其優先級以差別的遞次實行。閱讀器能夠優化一切套接字上的帶寬分配，或許能夠在預期要求時翻開套接字。

正如我之前提到的，這一切都是由閱讀器治理的，並不須要我們的任何事情。但這並不一定意味着我們無計可施。挑選準確的收集通訊情勢，傳輸範例和頻次，挑選協定以及調解/優化效勞器客棧能夠在進步運用程序的團體機能方面發揮重要作用。

有些閱讀器以至更進一步。比方，Chrome能夠自我教訓自身在運用它時變得更快。它依據接見的網站和典範的閱讀情勢舉行進修，以便在用戶做任何事變之前展望能夠的用戶行為並採用行為。最簡樸的例子是當用戶在鏈接上懸停時預先顯現頁面。假如您有興緻相識更多關於Chrome優化的信息，請參閱本章的https://www.igvita.com/posa/h…。

收集平安和沙盒

許可閱讀器治理單個套接字具有另一個異常重要的目的：經由過程這類體式格局，閱讀器能夠對不可托的運用程序資本實行一致的平安和戰略束縛。比方，閱讀器不許可直接API接見原始收集套接字，因為這能夠使任何歹意運用程序與任何主機舉行恣意銜接。閱讀器還強迫實行銜接限定，以庇護效勞器以及客戶端免受資本耗盡。

閱讀器花樣化一切傳出要求，以強化一致且花樣優越的協定語義來庇護效勞器。一樣，響應解碼自動完成，以庇護用戶免受歹意效勞器的損害。

TLS商洽

傳輸層平安性（TLS）是一種經由過程盤算機收集供應通訊平安性的加密協定。它在很多運用程序中普遍運用，个中之一是網頁閱讀。網站能夠運用TLS來庇護其效勞器和Web閱讀器之間的一切通訊。

悉數TLS握手由以下步驟構成：

客戶端向客戶端發送“Client hello”音訊，以及客戶端的隨機值和支撐的暗碼套件。
效勞器經由過程向客戶端發送“效勞器問候”音訊以及效勞器的隨機值舉行響應。
效勞器將其證書發送給客戶端，並能夠向客戶端要求相似的證書。效勞器發送“效勞器已完成”音訊。
假如效勞器已從客戶端要求證書，則客戶端發送它。
客戶端豎立一個隨機的預主密鑰，並運用效勞器證書中的公鑰對其舉行加密，並將加密的預主密鑰發送給效勞器。
效勞器收到預主密鑰。效勞器和客戶端依據預主密鑰天生主密鑰和會話密鑰。
客戶端向效勞器發送“變動暗碼規格”關照，指導客戶端將最先運用新的會話密鑰舉行散列和加密音訊。客戶端還發送“客戶端已完成”音訊。
效勞器收到“變動暗碼範例”並運用會話密鑰將其紀錄層平安狀況切換為對稱加密。效勞器向客戶端發送“效勞器已完成”音訊。
客戶端和效勞器如今能夠經由過程他們豎立的平安通道交流運用程序數據。一切從客戶端發送到效勞器並返回的音訊均運用會話密鑰加密。
假如任何考證失利 – 比方效勞器正在運用自署名證書，則正告用戶。

同源政策

假如兩個頁面的協定，端口（假如指定了一個）和主機雷同，則兩個頁面具有雷同的泉源。

以下是能夠嵌入跨源的資本的一些示例：

帶有<script src =“…”> </ script>的JavaScript。語法毛病的毛病音訊僅適用於同源劇本
CSS <link rel =“stylesheet”href =“…”>。因為CSS的寬鬆語法劃定規矩，跨源CSS須要準確的Content-Type標頭。閱讀器的限定因人而異
帶有<img>的圖象
帶有<video>和<audio>的媒體文件
帶有<object>，<embed>和<applet>的插件
帶有@ font-face的字體。有些閱讀器許可運用交織泉源的字體，其他閱讀器則須要雷同泉源的字體。
任何與<frame>和<iframe>的東西。網站能夠運用X-Frame-Options題目來阻撓這類情勢的跨源交互。
以上列表遠非完全;其目的是凸起事情中的“最小特權”準繩。閱讀器只公然運用程序代碼所需的API和資本：運用程序供應數據和URL，閱讀器花樣化要求並處置懲罰每一個銜接的完全生命周期。

值得注意的是，“同源戰略”沒有單一觀點。相反，有一組相干機制強迫限定DOM接見，Cookie和會話狀況治理，收集以及閱讀器的其他組件。

資本和客戶端狀況緩存

最好和最快的要求是未提出的要求。在分配要求之前，閱讀器會自動搜檢其資本緩存，實行必要的考證搜檢，並在滿足指定前提時返回資本的當地副本。假如當地資本在高速緩存中不可用，則會發出收集要求，而且響應會自動放入高速緩存中以供後續接見（假如許可）。

• 閱讀器自動評價每一個資本上的緩存指令
• 假如能夠，閱讀器會自動從新考證逾期資本
• 閱讀器自動治理緩存和資本逐出的大小

治理高效和優化的資本緩存很難題。值得光榮的是，閱讀器代表了我們的悉數複雜性，我們須要做的是確保我們的效勞器返回恰當的緩存指令;要相識更多信息，請參閱客戶端上的緩存資本。您確實為網頁上的一切資本供應了Cache-Control，ETag和Last-Modified響應標頭，對嗎？

末了，閱讀器常常被忽視但癥結的功用是供應身份考證，會話和cookie治理。閱讀器為每一個泉源庇護零丁的“Cookie JAR”，供應必要的運用程序和效勞器API來讀取和寫入新的Cookie，會話和身份考證數據，並自動附加和處置懲罰響應的HTTP頭以代表我們自動實行悉數歷程。

一個例子：
將會話狀況治理推晚到閱讀器的便利性的一個簡樸但申明性示例：能夠在多個選項卡或閱讀器窗口之間同享經由身份考證的會話，反之亦然;單個選項卡中的註銷操縱將使一切其他翻開的窗口中的翻開會話失效。

運用程序API和協定

走上供應收集效勞的門路，我們終究抵達了運用程序API和協定。正如我們所看到的，較低層供應了一系列癥結效勞：套接字和銜接治理，要乞降響應處置懲罰，種種平安戰略的實行，緩存等等。每次我們啟動一個HTTP或一個XMLHttpRequest，一個歷久效勞器發送的事宜或WebSocket會話，或翻開一個WebRTC銜接，我們都與這些底層效勞的一部分或悉數舉行交互。

沒有單一的最好協定或API。每一個非尋常的運用程序都須要依據種種需求夾雜運用差別的傳輸：與閱讀器緩存的交互，協定開支，音訊耽誤，可靠性，數據傳輸範例等等。某些協定能夠供應低耽誤傳輸（比方Server-Sent Events，WebSocket），但能夠不相符其他癥結前提，比方在一切狀況下應用閱讀器緩存或支撐高效二進制傳輸的才能。

進步您的Web運用機能和平安性的技能

• 在要求中一直運用“Connection：Keep-Alive”題目。閱讀器默許如許做。確保效勞器運用雷同的機制。
• 運用恰當的Cache-Control，Etag和Last-Modified題目，以便您能夠保留閱讀器的一些下載時候。
• 花時候調解和優化您的Web效勞器。這就是真正的魔法發作的處所！請記着，該流程是不是針對每一個Web運用程序以及您要傳輸的數據的範例都異常詳細。
• 一直運用TLS！迥殊是假如您在運用程序中有任何範例的身份考證。
• 研討閱讀器在您的運用程序中供應並實行哪些平安戰略。