深刻淺出經典面試題：從瀏覽器中輸入URL到頁面加載發生了什麼 - Part 3

備註：

由於文章太長，因此將它分爲三部分，本文是第三部分。

第一部分：深刻淺出經典面試題：從瀏覽器中輸入URL到頁面加載發生了什麼 - Part 1

第二部分：深刻淺出經典面試題：從瀏覽器中輸入URL到頁面加載發生了什麼 - Part 2

第三部分：深刻淺出經典面試題：從瀏覽器中輸入URL到頁面加載發生了什麼 - Part 3

HTTP/HTTPS請求和響應

前面TCP鏈接已經創建好了，意味着橋已經搭好了，下一步就該傳輸HTTP消息了。由於HTTP咱們都很熟悉，很常見，也不是那麼底層，理解起來輕鬆很多。

仍是抓包來分析，不過此次不用Wireshark來抓，由於不太直觀，此次直接用Chrome自帶的Developer Tools。

HTTP 請求

下圖展現了HTTP請求Header

Request URL：就是請求的URL

Request Method： GET， POST， PUT，DELETE， OPTIONS， HEAD

接下來就是其餘報文頭，常見的請求報頭有: Accept, Accept-Charset, Accept-Encoding, Accept-Language, Content-Type, Authorization, Cookie, User-Agent等。

 

HTTP 響應

下圖展現了HTTP響應Header

 

最多見的就是Status Code（ 200， 302， 307， 404， 500），server等。

HTTP 10問

HTTP問題簡單，那就直接列舉幾個問題，有些問題我給出詳細答案。

1.  HTTP METHOD有哪幾種，分別是什麼？

常見問題，很少解釋。

 

2. HTTP的PUT/DELETE/等使用時須要注意什麼？

有一點須要特別注意，有的瀏覽器是不支持的，因此在使用和實現時須要仔細評估好本身客戶端的能力。

 

3. HTTP的OPTIONS用來作什麼？

OPTIONS通常用來獲取目標資源的通訊選項，例如確認容許的HTTP Method.下面的這個例子來在Mozilla官網 https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/OPTIONS。

 

請求：

curl -X OPTIONS http://example.org -i

 

響應：

HTTP/1.1 200 OK

Allow: OPTIONS, GET, HEAD, POST

Cache-Control: max-age=604800

Date: Thu, 13 Oct 2016 11:45:00 GMT

Expires: Thu, 20 Oct 2016 11:45:00 GMT

Server: EOS (lax004/2813)

x-ec-custom-error: 1

Content-Length: 0

 

看紅色的返回部分，意思是說該URL容許的HTTP Method 爲OPTIONS、GET、HEAD以及POST。

 

那麼OPTIONS通常用在哪裏呢？是的，CORS。若是您開發過SPA，或者您的前端的邏輯和交互徹底用JavaScript來實現的，確定會碰到此問題。所謂JavaScript實現，目前比交流行的有VueJS，AngularJS，React等流行框架。如何解決這個問題？最經常使用的方法是是前端和後端在同一個域名下。若是不在同一個域名下，須要在後端實現支持CORS的功能，目前Spring/Spring Boot已經有相似功能支持CORS，實現起來蠻簡單的，具體能夠參看 https://spring.io/blog/2015/06/08/cors-support-in-spring-framework，不在贅述。

 

關於CORS，最難的不是這裏，在我遇到的Case裏，比這個更復雜，若是前端是SPA，並且在某種狀況下，訪問任何前端頁面都會進行跳轉，這是需求。可是由於是SPA的架構，會出現OPTIONS（這是瀏覽器關於CORS支持的流程），這會使整個HTTP 流程變得紊亂，也是一個很棘手的問題。

 

無論怎麼說，CORS屬於安全性這一塊，後面在軟件安全（包括Web）方面專門寫吧。在過去幾年裏，由於公司和客戶在產品安全和數據安全放在了一個很高的位置，而我又是去負責這一塊，因此本身在安全方面積累了大量的實戰經驗，很是寶貴。

 

4. 上述訪問qq的HTTP response裏的server哪裏不合適，須要注意什麼？

server的值是squid/3.5.24，不合適之處在哪裏？也許部分人是不清楚的。其實很簡單，不該該把squid的版本信息放在這裏。爲何？

 

若是web server軟件是本身公司開發的，私有的，不開源的，這也罷了，沒人知道你的web server是怎麼實現的，但這並不表明web  server沒有漏洞，不表明別人發現不了漏洞。

 

但若是用的是開源的，例如Apache HTTPd，Apache Tomcat，Ngnix等，就須要注意了，每一個版本都有安全漏洞，並且這些安全漏洞都有專門的記錄，看看隔三差五報告的CVE，就知道漏洞多少了。因此，若是使用開源軟件，很容易將本身的web server處於一個具備潛在風險的位置，因此不要加上版本號。

 

騰訊做爲全球頂級的大公司，這方面不注意，實在是有點說不過去。若是有騰訊的朋友看到這裏，仍是改過來吧。

 

和上面同樣，這也是屬於安全性問題，有時間我再寫吧。

 

5. Status Code 302與307的區別是什麼？

都屬於跳轉，可是區別在哪裏呢？

咱們看看307在協議裏是怎麼定義的？參看rfc2616第10章節

10.3.8 307 Temporary Redirect

The requested resource resides temporarily under a different URI. Since the redirection MAY be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not understand the 307 status. Therefore, the note SHOULD contain the information necessary for a user to repeat the original request on the new URI.

If the 307 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

在 GET、HEAD 這些冪等的請求方式上，30二、307 沒區別，但對於 POST 就不一樣了，大部分瀏覽器 都會 302 會將 POST 請求轉爲 GET，而 307則不同，規範要求瀏覽器繼續向 Location 的地址 POST 內容。

舉個例子解釋一下，假設正在POST一個消息，裏面的Body有1M內容，在307的狀況下，這1M的內容會繼續發過去，但在302的狀況下，則不會。

 

6. 在HTTP Response裏Connection的用法須要注意什麼？

不解釋過多，keep-alive，closed用法不同，根據實際狀況而定，在優化網絡時常常用到。

須要注意的是，Connection在通訊領域會一些場景下會形成一些麻煩，尤爲是在監控某個HTTP Session的flow時。

 

7.  在HTTP Response裏Strict-Transport-Security（HSTS）怎麼用？

HSTS通常大公司都會用，在我實際的項目涉及到HTTPS，爲了實現某個功能，HSTS成了一個跨不過去的坎，遇到過很大問題。你們本身多看看吧。

 

8. 能夠抓HTTPS的包瞭解HTTP請求和響應嗎？有什麼方法？

很少解釋，但提供2個軟件名字，Fiddler，HTTP Analyzer。

 

9. 爲何對性能要求高的場景下不使用HTTP做爲協議？例如在商用裏，RPC開源項目通常不使用HTTP做爲傳輸協議？而在5G下使用HTTP協議呢？

有一點是須要注意的，HTTP的消息頭太多了，會形成消息體特別大，影響性能，並且有些場景下這些消息頭大部分都是無用的。

可是在5G裏，爲何3GPP組織會採用HTTP協議做爲各個reference point的interface的實現呢？你們體會一下。

 

10.  HTTP協議（包括HTTP/2.0）有了解嗎？

很少解釋，可是HTTP/2.0仍是須要了解一下，優點和缺點。

 

瀏覽器解析和渲染頁面

如今瀏覽器接收到了server的返回內容，接下來瀏覽器該把內容呈現給用戶了。

 

Server返回的內容有哪些呢？這裏只以HTML頁面爲例（API返回的JSON數據或XML數據不在討論範圍內）。

 

一個頁面通常包含HTML、CSS、 JS、 圖片等文件，那麼瀏覽器收到這些文件後該如何渲染（render）他們呢？

 

如下部分不少參考下面2篇文章：

• https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/
• https://developers.google.com/web/fundamentals/performance/critical-rendering-path/render-tree-construction

瀏覽器的組成

 

首先咱們先了解一下瀏覽器的組件構成，以及每一個組件的功能，下圖是瀏覽器包括的幾個部分：

1. User Interface: UI組件包括地址欄，前進/後退按鈕，書籤菜單等。
2. Browser Engine: 在UI組件和渲染引擎間採起一些action.
3. Rendering engine : 負責顯示請求的內容。例如，若是是HTML頁面，它將解析HTML，CSS，並將解析的內容顯示在屏幕上。

不一樣的瀏覽器使用不一樣的渲染引擎：

• IE使用Trident
• Firefox使用Gecko
• Safari使用WebKit
• Chrome和Opera（版本15開始）使用Blink。它是基於Webkit開發的。

4.    Networking: 負責網絡調用，例如HTTP請求。在不一樣的平臺有不一樣的實

5.    UI backend: 主要用來繪畫基本的UI元素，例以下拉框，Windows等。這個UI後臺暴露一些通用的接口，並不依賴平臺的。

6.    JavaScript interpreter. 用來解析和運行JavaScript code。

7.    Data storage. 數據持久化的那一層。瀏覽器可能須要存儲各類各樣的數據，例如Cookie。瀏覽器也得支持咱們經常使用的LocalStorage， IndexedDB，WebSQL以及FileSystem。

 

渲染頁面的主要流程

 

下面是瀏覽器的渲染引擎的主要步驟。

 

渲染引擎解析HTML文檔，並將HTML包含的元素轉化爲一個個DOM，並構建爲一個 DOM樹。而後引擎開始解析來自CSS文件或直接嵌在HTML頁面的CSS樣式數據，這些樣式信息又會構建另一個樹： 渲染樹。

 

渲染樹包含了多個矩形，這些矩形包含了顏色，大小，位置等屬性，並且會按照對應的順序顯示在屏幕上。

 

當渲染樹構造完畢後，接下來進入佈局的程序，在這個程序裏，渲染引擎會給每一個DOM元素安排精確的座標，並根據座標在屏幕上顯示。

 

接下來是遍歷渲染樹，UI Backend層會將一個個DOM元素繪畫在屏幕上繪畫出來。

 

須要注意的是，上面是一個漸進的過程，理解這一點很是重要。可是爲了獲得更好的用戶體驗，瀏覽器會邊解析邊渲染，它並不會等到全部HTML解析完了纔開始構造和佈局渲染樹。當部份內容正在解析渲染時，另一部分正從網絡那邊下載下來呢。

 

下面2個圖是WebKit和Gecko的渲染引擎的流程，咱們發現他們大體相同的。

 

下面是DOM樹，渲染樹的樹形結構。

 

渲染引擎是單線程工做的，除了網絡操做，其餘全部的都是單線程的。在Firefox和Safari，它們本身就是主線程，而Chrome就是每一個tab處理主線程。

 

網絡操做則由多個並列線程去執行，但數量也是受限的，通常在2-6個。

 

瀏覽器的主線程是一個無限的事件循環，並且一直保持進程alive，一直等着各類事件（例如繪畫事件，佈局事件），並處理他們。

 

瀏覽器渲染10問

1.   瀏覽器的組成部分是什麼？

2.  各個主流瀏覽器的渲染引發是什麼？

3.  瀏覽器顯示頁面的主要流程是什麼？

4.  您在作開發和測試時，有哪些瀏覽器（包括手機）存在兼容性問題較多？

       碰見最多的是Samsung手機和Huawei手機，有時一個兼容性須要花費大量時間去調研和修復，多是Samsung和Huawei定製的太厲害了，不兼容一些特性吧。

5.  渲染引擎是單線程仍是多線程？

6.  瀏覽器的網絡操做通常由幾個線程去執行？

7.  DOM樹，渲染樹是什麼？

8.  爲了得到更好的用戶體驗，咱們應該在頁面作些什麼改進？

9.  瀏覽器是如何打開PDF，Word等文檔的？

10. 若是讓你開發一個瀏覽器，設計思路有哪些？

Web優化

咱們知道，人的耐心是有限的，一個頁面若是超過8s，人基本上不會等了，這會對業務產生巨大影響。咱們該如何去優化頁面呢？

 

思路很簡單，就是按照咱們前面介紹的幾大步驟去優化。咱們先回顧一下幾大步驟：

1.     DNS查詢

2.    TCP鏈接

3.    發送HTTP請求

4.    Server處理HTTP請求並返回HTTP報文

5.    瀏覽器解析並render頁面

6.    HTTP鏈接斷開

 

當我想總結一下的時候，雅虎在10多年就總結出來一些經驗，參看這裏（ https://developer.yahoo.com/performance/rules.html）。

這是10多年前的經驗，隨着科技的發展，一些新的經驗又出現了，能夠容易想到的是：

1.  儘可能將server離用戶近一些，例如人處在中國訪問Apple，應該是Apple中國站提供服務，GSLB很重要。

2. 不要把layout嵌入一層又一層，簡單說就是嵌套別太深，否則影響解析和渲染性能。

3. 有些數據能夠在後臺處理的，就不要在前端經過JavaScript處理了。

4. 若是請求過大，Load Balance這些手段仍是要上的。

5. 保持HTTP鏈接，合理設置Connection。

6. 後臺事件性能要高，可以及時將結果返回給用戶。

固然涉及到高可用，高性能等那是另一個話題。

總結

這道面試題很是經典，考察的知識很是豐富，跨度較大，若是沒有幾年的經驗，是很難徹底掌握的，因此想答好其實不容易的。對這個問題，基本上能夠根據個人經驗回答，也算是對這些年來在這方面的知識的一個總結。但同時，我也參考了一些資料，感謝他們。在參考的地方，我都把URL列出來了。

 

寫這篇文章耗費了大量時間，我以爲挺有意義，可是也不能保證裏面的內容全都是正確或準確的，若是您有任何問題能夠經過如下方式聯繫我，以便我進一步改正並更新。

 

我的微信：terryisme                                    公衆號：terrymemo

                      

下載

寫到這裏，三部分已經寫完，在這裏放上全文的PDF文檔供你們參考，可能後面會更改，若是有新的文檔，我將保持更新。

下載 2018/12/04版本