阿里面試官的」說一下從url輸入到返回請求的過程「問的難度就是不同！

前言

年前準備換工做，總結了一波面試最頻繁的面試問題跟你們交流。此文章是關於瀏覽器的常見問題，大概面試10家遇到6家提問相似問題（主要是大廠和中廠）。（面試的部份內容已經忘了，爲了串聯成一個完整的故事，增長可讀性，20%的內容爲虛構），目前入職滴滴出行成都團隊。css

推薦計算機基礎精品文章：juejin.cn/post/684490…html

問題: 從瀏覽器地址欄輸入url到請求返回發生了什麼

你一看這種爛掉牙的問題，小case，但996面試大佬由此延展的問題已經遠遠超越了這個問題自己了，不信你就接着看。前端

我回答了首先會進行 url 解析，根據 dns 系統進行 ip 查找。java

話音剛落，此時一位喜歡修福報的公司的大佬打斷了我，說url爲啥要解析，dns查詢規則是什麼？我一聽就內心想，不按套路出牌啊，網上通常都沒問這兩個問題，內心再一想，俗話說，萬事開頭難，扛過這一波，答出來，就是陽光明媚，萬物騷動的春天！node

先說爲何url要解析（也就是編碼)面試

我回答大概內容是：由於網絡標準規定了URL只能是字母和數字，還有一些其它特殊符號（-_.~ ! * ' ( ) ; : @ & = + $ , / ? # [ ]，特殊符號是我下來查的資料，實在背不住這麼多，比較常見的就是不包括百分號和雙引號），並且若是不轉義會出現歧義，好比http:www.baidu.com?key=value,假如個人key自己就包括等於=符號，好比ke=y=value，就會出現歧義，你不知道=究竟是鏈接key和value的符號，仍是說自己key裏面就有=。
大佬接着毒打我說，那url編碼的規則是什麼呢，我說utf-8
大佬接着窮追不捨，爲啥是utf-8呢，全部瀏覽器都是這樣嗎？中文的話用gb2312編碼嗎，還有就是萬一瀏覽器不是你說的這樣統一用utf-8，你怎麼保證都是utf-8的編碼?
我支支吾吾的說，我瞭解的大概是這樣，不太清楚, 應該和html自己的編碼格式有關，而後怎麼保證utf-8的編碼，我以爲能夠用encodeURIComponent
大佬說encodeURIComponent比encodeURI有什麼區別?
區別就是encodeURIComponent編碼範圍更廣，適合給參數編碼，encodeURI適合給URL自己（locaion.origin）編碼,固然項目裏通常都是用qs庫去處理

而後說說dns解析流程，而且html如何作dns優化chrome

首先dns這個屬於好久之前在計算機網絡謝希仁版看到過了，有一些細節忘了，可是大體流程是記得的。好比說查詢一個網址爲：www.baidu.com後端

一、器中輸入www.baidu.com 域名，操做系統會先查hosts件是否有記錄，有的話就會把相對應映射的IP返回。瀏覽器

二、hosts文件沒有就去查本地dns解析器有沒有緩存。（這個我沒答上來）緩存

三、而後就去找咱們計算機上配置的dns服務器上有或者有緩存，就返回

四、尚未的話就去找根DNS服務器(全球13臺，固定ip地址)，而後判斷.com域名是哪一個服務器管理，若是沒法解析，就查找.baidu.com服務器是否能解析，直到查到www.baidu.com的IP地址

注:後面查資料才發現dns查詢有兩種模式，一種是轉發模式，一種是非轉發模式，我上面說的4是非轉發模式。

前端的dns優化，能夠在html頁面頭部寫入dns緩存地址，好比

<meta http-equiv="x-dns-prefetch-control" content="on" />
<link rel="dns-prefetch" href="http://bdimg.share.baidu.com" />
複製代碼

終於抗過了第一輪的猛問，接着我繼續說從瀏覽器地址欄輸入url到請求返回發生了什麼

查找到IP以後，就是http協議的三次握手（以及後面會涉及到四次分手）

我剛恢復節奏，準備侃侃而談，修福報的大佬再次打斷了我，說三次握手，爲啥兩次不行，順便說一下3次握手發生了什麼。

我去，大意了，沒有閃，這是否是說我每說一句都要夾雜着各類問題，太難了啊！！！

沒有辦法，繼續回答大佬，我說我先回答三次握手發生的事情吧，簡答來講：

第一次握手：主機A發送位碼爲SYN＝1的TCP包給服務器，而且隨機產生一個做爲確認號（這是tcp包的一部分），主機B收到SYN碼後直到A要求創建鏈接;
第二次握手：主機B收到請求後，向A發送確認號（主機A的seq+1），syn=1，seq = 隨機數的TCP包；
主機A收到後檢查確認號是否正確，即第一次A發送的確認號是否+1了，以及位碼ack是否爲1，若正確，主機A會再發送確認號(主機B的seq+1)，ack=1，主機B收到後確認seq值與ack=1則鏈接創建成功。

接着補上小問題爲何兩次握手不行，由於第二次握手，主機B還不能確認主機A已經收到確認請求，也是說B認爲創建好鏈接，開始發數據了，結果發出去的包一直A都沒收到，那攻擊B就很容易了，我專門發包不接收，服務器很容易就掛了。

接着，大佬說出個加分題，我看你不是科班出身，能答多少是多少。問題是,從網卡把數據包傳輸出去到服務器發生了什麼，提示我OSI參考模型

我一聽，好嘛，這不是計算機網絡的知識嗎，幸好以前看過書，但也是很久之前看過了，只能憑藉本身的理解解答了。

我說，先從局域網把數據發送到公司的交換機（若是交換機沒有緩存本地mac地址和IP地址的映射，此時會經過ARP協議來得到），交換機的好處是能夠隔離衝突域（由於以太網用的是CSMA/CD協議,這個協議規定網線上同一時刻只能有一臺機器發送數據），這樣就能夠不只僅同一時刻只有一臺機器發送網絡包了
而後交換機再將數據發送到路由器，路由器至關於公司網關（咱們公司小），路由器具備轉發和分組數據包的功能（路由器經過選定的路由協議會構造出路由表，同時不按期的跟相鄰路由器交換路由信息），而後這算是通過了物理層，數據鏈路層（以太網）,開始到網絡層進行數據轉發了
而後路由器轉發IP數據報，通常公司的IP地址都會通過NAT轉換，讓內網的ip也可以訪問外網，咱們公司我注意了一下是192.168打頭的內網ip地址。經過路由器的分組傳輸，全部數據到達服務器。
而後服務器的上層協議傳輸層協議開始發揮做用，根據tcp包裏的端口號，讓服務器特定的服務來處理到來的數據包，而且tcp是面向字節流的(tcp有四大特性，可靠傳輸、流量控制、擁塞控制、鏈接管理)，因此咱們node的request對象，它的監聽事件data事件爲何要用字符串一塊兒拼接起來呢（buffer），就是由於tcp自己就是字節流，request對象使用的data（http層面）是tcp傳來的數據塊。
最後數據由傳輸層轉交給應用層，也就是http服務（或者https），後端通過一系列邏輯處理，返回給前端數據。

答完這裏，我說大佬我只知道大概的流程，具體細節我不是很清楚，但本身後面會補上。。。

大佬讓我繼續，我就接着3次握手以後接着說道，創建完連接，就該請求html文件了，若是html文件在緩存裏面瀏覽器直接返回，若是沒有，就去後臺拿

剛說到緩存，立馬就有一種不詳的預感，果不其然大佬先讓把緩存解釋一下。緩存這種問爛的問題，本覺得能輕鬆應對，結果仍是被問了個滿頭包。。。。

我說的大概意思是:

瀏覽器首次加載資源成功時，服務器返回200，此時瀏覽器不只將資源下載下來，並且把response的header(裏面的date屬性很是重要，用來計算第二次相同資源時當前時間和date的時間差)一併緩存;
下一次加載資源時，首先要通過強緩存的處理，cache-control的優先級最高，好比cache-control：no-cache,就直接進入到協商緩存的步驟了，若是cache-control：max-age=xxx,就會先比較當前時間和上一次返回200時的時間差，若是沒有超過max-age，命中強緩存，不發請求直接從本地緩存讀取該文件（這裏須要注意，若是沒有cache-control，會取expires的值，來對比是否過時），過時的話會進入下一個階段，協商緩存
協商緩存階段，則向服務器發送header帶有If-None-Match和If-Modified-Since的請求，服務器會比較Etag，若是相同，命中協商緩存，返回304；若是不一致則有改動，直接返回新的資源文件帶上新的Etag值並返回200;
協商緩存第二個重要的字段是，If-Modified-Since，若是客戶端發送的If-Modified-Since的值跟服務器端獲取的文件最近改動的時間，一致則命中協商緩存，返回304；不一致則返回新的last-modified和文件並返回200;

果不其然，大佬問了一些緩存不常問的，首先就是問我知道什麼是from disk cache和from memory cache嗎，何時會觸發？

我說強緩存會觸發，這兩種，具體什麼行爲不知道,大概內容以下：

一、先查找內存，若是內存中存在，從內存中加載；
二、若是內存中未查找到，選擇硬盤獲取，若是硬盤中有，從硬盤中加載；
三、若是硬盤中未查找到，那就進行網絡請求；
四、加載到的資源緩存到硬盤和內存；
複製代碼

接着大佬又問知道什麼是啓發式緩存嗎，在什麼條件下觸發？

這個問題給個人感受就兩個字，懵逼！而後如實回答不知道。（查了下資料大概以下）

啓發式緩存:

若是響應中未顯示Expires，Cache-Control：max-age或Cache-Control：s-maxage，而且響應中不包含其餘有關緩存的限制，緩存可使用啓發式方法計算新鮮度壽命。一般會根據響應頭中的2個時間字段 Date 減去 Last-Modified 值的 10% 做爲緩存時間。

// Date 減去 Last-Modified 值的 10% 做爲緩存時間。
// Date：建立報文的日期時間, Last-Modified 服務器聲明文檔最後被修改時間
  response_is_fresh =  max(0,（Date -  Last-Modified)) % 10
複製代碼

接着回答，我說返回html以後，會解析html,這部分知識我提早準備過，可是答的不是很詳細，大概意思就是cssom + domTree = html,而後佈局和繪製

構建DOM樹(DOM tree)：從上到下解析HTML文檔生成DOM節點樹（DOM tree），也叫內容樹（content tree）；
構建CSSOM(CSS Object Model)樹：加載解析樣式生成CSSOM樹；
執行JavaScript：加載並執行JavaScript代碼（包括內聯代碼或外聯JavaScript文件）；
構建渲染樹(render tree)：根據DOM樹和CSSOM樹,生成渲染樹(render tree)；
渲染樹：按順序展現在屏幕上的一系列矩形，這些矩形帶有字體，顏色和尺寸等視覺屬性。
佈局（layout）：根據渲染樹將節點樹的每個節點佈局在屏幕上的正確位置；
繪製（painting）：遍歷渲染樹繪製全部節點，爲每個節點適用對應的樣式，這一過程是經過UI後端模塊完成；

接着面試官問我一些頁面渲染層的一些優化手段，大概以下：

頁面渲染優化

HTML文檔結構層次儘可能少，最好不深於六層；
腳本儘可能後放，放在前便可；
少許首屏樣式內聯放在標籤內；
樣式結構層次儘可能簡單；
在腳本中儘可能減小DOM操做，儘可能緩存訪問DOM的樣式信息，避免過分觸發迴流；
減小經過JavaScript代碼修改元素樣式，儘可能使用修改class名方式操做樣式或動畫；
動畫儘可能使用在絕對定位或固定定位的元素上；
隱藏在屏幕外，或在頁面滾動時，儘可能中止動畫；
儘可能緩存DOM查找，查找器儘可能簡潔；
涉及多域名的網站，能夠開啓域名預解析

最後面試官問我，如何診斷頁面渲染時各個性能指標，我大概說了，經過chrome瀏覽器的工具，好比看網絡請求狀況的network，還有看頁面渲染狀況的perfermance，面試下來本身查了一些資料，好比知乎的這篇文章，我以爲寫的很詳細，如下是摘抄部分，我打算之後有機會本身總結一篇。

zhuanlan.zhihu.com/p/105561186

順便成都這邊成都滴滴招聘前端，java和測試。我這邊直接推到內推系統裏，歡迎你們投遞，簡歷投放郵箱爲2298613245@qq.com