本篇文章我們去**下chrome的內部工作機制，分析下不同的程序和執行緒是如何處理瀏覽器的各部分功能。同時深入研究下每個程序和執行緒在展現**時是如何溝通的。
首先我們先來看乙個簡單的例子，在瀏覽器位址列輸入url，按下回車建，瀏覽器會向伺服器請求資料然後展現介面。
從瀏覽器程序開始
從第一篇文章中，我們知道了在tab網頁之外的所有功能，都是由瀏覽器程序控制的，瀏覽器程序中有繪製瀏覽器的按鈕和輸入框的ui執行緒，網路執行緒來處理網路堆疊從網路中獲取資料，儲存執行緒控制檔案的許可權等。當輸入url按下enter鍵後，ui執行緒會處理我們的輸入。
處理位址列中的輸入
使用者在位址列輸入之後，ui執行緒回去判斷使用者的輸入是url還是乙個搜尋項，因為chrome的位址列也可以作為乙個搜尋輸入框來使用。所以ui執行緒需要判斷使用者的的輸入然後決定把使用者的輸入傳送給搜尋引擎還是發起網路請求。
開始導航
當使用者敲擊enter鍵, ui執行緒為了得到網頁內容初始化乙個網路請求，即ui執行緒通知網路執行緒去載入某個網頁，這時候瀏覽器位址列左邊的載入圖示會顯示出來，同時網路執行緒會去建立網路鏈結，這個過程中有著例如dns解析或者tls鏈結建立等過程。
在這個節點，服務端有可能給網路執行緒返回乙個重定向的狀態例如http301，這時網路執行緒會告訴ui執行緒說：「你的請求被重定向了」，然後ui執行緒就會初始化另外乙個網路請求。
同時這個過程也會發生瀏覽器的安全檢查，如果響應域和返回資料與已知的惡意站點所匹配，網路執行緒會告訴渲染程序展示乙個警告介面，同時為了確保不會把危險的跨域資料傳送給渲染程序也會進行corb檢測。
找尋渲染程序
當所有的檢查都完成後，網路執行緒確定瀏覽器應該導航到對應的請求站點，網路執行緒告訴ui執行緒資料已經準備完畢，然後ui執行緒找到渲染程序繼續去渲染介面。
由於網路請求需要幾百毫秒才能得到響應返回，瀏覽器應用了一種用來加速這個過程的優化策略，當ui執行緒傳送乙個網路請求給網路執行緒的同時， ui執行緒會主動嘗試去查詢或啟動乙個渲染程序，這個過程是並行執行的。使用這種方法，如果一切進展順利的話，當網路執行緒接收到資料時，渲染程序已經處於待機狀態了，當然如果請求被重定向的話則不會用到這個準備好的渲染程序。
提交導航
當返回資料和渲染程序準備好時，瀏覽器程序會通過ipc通道向渲染程序提交導航，同時傳遞資料流給渲染程序，一旦瀏覽器程序確認提交導航已在渲染器程序中發生，導航過程就完成了，文件載入階段就開始了。
此時，位址列的狀態已經更新，同時tab欄的路由歷史記錄也被更新，點選前進和後退按鈕會進行響應的介面跳轉。為了方便在tab頁或瀏覽器視窗關閉後還原瀏覽器介面，tab頁的導航歷史記錄資訊是儲存在硬碟上的。
初始載入完成
導航欄的工作完成後，渲染程序會繼續載入資源渲染介面，當渲染程序完成介面渲染後，它會通過ipc通道向瀏覽器程序（這是當頁面中包括frame中的onload事件觸發後才執行的）。在這時，瀏覽器程序中的ui執行緒會停止loading圖示的顯示。
跳轉至另乙個頁面
簡單的導航完成了！ 但是如果使用者再次將不同的url放到位址列會發生什麼？ 好吧，瀏覽器程序會執行相同的步驟來導航到不同的站點。 但在它可以做之前，如果他們關心beforeunload事件，它需要檢查當前渲染的站點。
當你準備離開或者關閉當前介面時，beforeunload事件會觸發乙個 「是否離開當前介面？」的彈框，當然，彈框的是有由渲染程序控制的，瀏覽器程序會向渲染程序詢問是否需要觸發beforeunload事件。
如果跳轉是由渲染程序中發起的，例如使用者點選了link跳轉按鈕或者在js中執行window.location=「渲染程序會首先去檢測beforeunload處理事件，然後，它經歷與瀏覽器程序啟動導航的相同過程。 唯一的區別是導航請求從渲染程序啟動然後到瀏覽器程序。
當導航到乙個與當前介面不同的新站點時，乙個新的渲染程序會被建立用來處理新的導航，老的渲染程序會去處理類似於unload這種事件。對於介面的生命週期，我們可以檢視這篇文章。
service woker帶來的不同
由於瀏覽器新引入的service worker特性，介面的導航過程發生了一些變化。service worker是在應用**中編寫網路**的方式，允許web開發者更好的控制本地快取內容，同時也可以控制介面什麼時候向服務請求資料。當service worker **資源請求從快取中獲取，就不會向伺服器傳送請求。
其中最重要的一點是servicer worker是一段執行在渲染程序中的js **，所以問題就是，當乙個網路請求打進來，瀏覽器程序是怎麼知道這個站點存在service worker 執行緒呢？
當乙個service worker被註冊時，將保留service worker的scope作為參考 ,當請求發生時，網路執行緒根據註冊的service worker 的scope 檢查該url，如果為該url註冊了service worker，則ui執行緒找到渲染程序以執行service worker**。service worker可以從快取載入資料，無需從網路請求資料，當然不符合規則時也可以從網路請求新資源。
且看瀏覽器跟伺服器間的互動
每天我們都在上網，每天我們都在瀏覽無數多的網頁，每天我們都在用瀏覽器跟伺服器打著交道，當我們在位址列中輸入位址，瀏覽器立即會呈現給我們想要的內容，那麼到底瀏覽器跟服務期間發生了什麼呢？如上圖所示 1 瀏覽器跟伺服器之間是通過套接字來通訊的，在伺服器端會有乙個監聽套接字，專門用來監聽瀏覽器端的請求，當...
瀏覽器與web伺服器間的互動
在瀏覽器訪問 瀏覽器與web伺服器之間的互動 1 瀏覽器查詢本地的hosts檔案看是否有與所輸入主機名相匹配的ip位址，如果有則根據ip連線上web伺服器 如果沒有則訪問dns伺服器獲得與主機名對應的ip然後跟據ip連線上web伺服器 2 向伺服器傳送http請求 3 web伺服器從請求中檢索出瀏覽...
瀏覽器與web伺服器間的互動
在瀏覽器訪問 瀏覽器與web伺服器之間的互動 1 瀏覽器查詢本地的hosts檔案看是否有與所輸入主機名相匹配的ip位址，如果有則根據ip連線上web伺服器 如果沒有則訪問dns伺服器獲得與主機名對應的ip然後跟據ip連線上web伺服器 2 向伺服器傳送http請求 3 web伺服器從請求中檢索出瀏覽...