記一個面試

時間 2019-11-17

標籤一個面試欄目快樂工作简体版

原文原文鏈接

-先進行了一個簡單的自我介紹，主要介紹了一下本身的工做經歷和一些技術棧css

1. 解釋一下瀏覽器解析HTTP的過程

上來就放大招，這個題可深可淺，我整理了一下答案html

一次完整的HTTP請求過程

當咱們在web瀏覽器的地址欄中輸入： www.baidu.com，而後回車，到底發生了什麼html5

過程概覽

1.對www.baidu.com這個網址進行DNS域名解析，獲得對應的IP地址java

2.根據這個IP，找到對應的服務器，發起TCP的三次握手webpack

3.創建TCP鏈接後發起HTTP請求nginx

4.服務器響應HTTP請求，瀏覽器獲得html代碼web

5.瀏覽器解析html代碼，並請求html代碼中的資源（如js、css圖片等）（先獲得html代碼，才能去找這些資源）瀏覽器

6.瀏覽器對頁面進行渲染呈現給用戶緩存

注：服務器

DNS域名解析採用的是遞歸查詢的方式，過程是，先去找DNS緩存->緩存找不到就去找根域名服務器->根域名又會去找下一級，這樣遞歸查找以後，找到了，給咱們的web瀏覽器
爲何HTTP協議要基於TCP來實現？ TCP是一個端到端的可靠的面相鏈接的協議，HTTP基於傳輸層TCP協議不用擔憂數據傳輸的各類問題（當發生錯誤時，會重傳）
最後一步瀏覽器是如何對頁面進行渲染的？

a: 解析html文件構成 DOM樹，

b: 解析CSS文件構成渲染樹，

c: 邊解析，邊渲染，

d: JS 單線程運行，JS有可能修改DOM結構，意味着JS執行完成前，後續全部資源的下載是沒有必要的，因此JS是單線程，會阻塞後續資源下載

下面咱們來詳細看看這幾個過程的具體細節：

1.域名解析

a）首先會搜索瀏覽器自身的DNS緩存（緩存時間比較短，大概只有1分鐘，且只能容納1000條緩存）

b）若是瀏覽器自身的緩存裏面沒有找到，那麼瀏覽器會搜索系統自身的DNS緩存

c）若是尚未找到，那麼嘗試從 hosts文件裏面去找

d）在前面三個過程都沒獲取到的狀況下，就遞歸地去域名服務器去查找，具體過程以下

2.TCP鏈接（三次握手）

拿到域名對應的IP地址以後，User-Agent（通常指瀏覽器）會以一個隨機端口（1024<端口<65535）向服務器的WEB程序（經常使用的有httpd，nginx）等的80端口。這個鏈接請求（原始的http請求通過TCP/IP4層模型的層層封包）到達服務器端後（這中間有各類路由設備，局域網內除外），進入到網卡，而後是進入到內核的TCP/IP協議棧（用於識別鏈接請求，解封包，一層一層的剝開），還有可能要通過Netfilter防火牆（屬於內核的模塊）的過濾，最終達到WEB程序，最終創建了TCP/IP的鏈接

3.創建TCP鏈接以後，發起HTTP請求

HTTP請求報文由三部分組成：請求行，請求頭和請求正文

請求行：用於描述客戶端的請求方式，請求的資源名稱以及使用的HTTP協議的版本號（例：GET/books/java.html HTTP/1.1）

請求頭：用於描述客戶端請求哪臺主機，以及客戶端的一些環境信息等

注：這裏提一個請求頭 Connection，Connection設置爲 keep-alive用於說明客戶端這邊設置的是，本次HTTP請求以後並不須要關閉TCP鏈接，這樣可使下次HTTP請求使用相同的TCP通道，節省TCP創建鏈接的時間

請求正文：當使用POST, PUT等方法時，一般須要客戶端向服務器傳遞數據。這些數據就儲存在請求正文中（GET方式是保存在url地址後面，不會放到這裏）

4.服務器端響應http請求，瀏覽器獲得html代碼

HTTP響應也由三部分組成：狀態碼，響應頭和實體內容

狀態碼：狀態碼用於表示服務器對請求的處理結果

列舉幾種常見的：200（沒有問題） 302（要你去找別人） 304（要你去拿緩存） 307（要你去拿緩存） 403（有這個資源，可是沒有訪問權限） 404（服務器沒有這個資源） 500（服務器這邊有問題）

若干響應頭：響應頭用於描述服務器的基本信息，以及客戶端如何處理數據

實體內容：服務器返回給客戶端的數據

注：html資源文件應該不是經過 HTTP響應直接返回去的，應該是經過nginx經過io操做去拿到的吧

5.瀏覽器解析html代碼，並請求html代碼中的資源

瀏覽器拿到html文件後，就開始解析其中的html代碼，遇到js/css/image等靜態資源時，就向服務器端去請求下載（會使用多線程下載，每一個瀏覽器的線程數不同），這是時候就用上 keep-alive特性了，創建一次HTTP鏈接，能夠請求多個資源，下載資源的順序就是按照代碼裏面的順序，可是因爲每一個資源大小不同，而瀏覽器又是多線程請求請求資源，因此這裏顯示的順序並不必定是代碼裏面的順序。

6.瀏覽器對頁面進行渲染呈現給用戶

最後，瀏覽器利用本身內部的工做機制，把請求的靜態資源和html代碼進行渲染，渲染以後呈現給用戶

瀏覽器是一個邊解析邊渲染的過程。首先瀏覽器解析HTML文件構建DOM樹，而後解析CSS文件構建渲染樹，等到渲染樹構建完成後，瀏覽器開始佈局渲染樹並將其繪製到屏幕上。這個過程比較複雜，涉及到兩個概念: reflow(迴流)和repain(重繪)。DOM節點中的各個元素都是以盒模型的形式存在，這些都須要瀏覽器去計算其位置和大小等，這個過程稱爲relow;當盒模型的位置,大小以及其餘屬性，如顏色,字體,等肯定下來以後，瀏覽器便開始繪製內容，這個過程稱爲repain。頁面在首次加載時必然會經歷reflow和repain。reflow和repain過程是很是消耗性能的，尤爲是在移動設備上，它會破壞用戶體驗，有時會形成頁面卡頓。因此咱們應該儘量少的減小reflow和repain。

JS的解析是由瀏覽器中的JS解析引擎完成的。JS是單線程運行，JS有可能修改DOM結構，意味着JS執行完成前，後續全部資源的下載是沒有必要的，因此JS是單線程，會阻塞後續資源下載

自此一次完整的HTTP事務宣告完成.

總結：

域名解析 --> 發起TCP的3次握手 --> 創建TCP鏈接後發起http請求 --> 服務器響應http請求，瀏覽器獲得html代碼 --> 瀏覽器解析html代碼，並請求html代碼中的資源（如js、css、圖片等） --> 瀏覽器對頁面進行渲染呈現給用戶

ps：反正我是涼了一會兒沒想起來底層的東西，答非所問

2. 頁面在進行加載的過程當中，作了那些事，link標籤和scrript標籤在加載的時候是同步的仍是異步的

當一個瀏覽器接收到從服務器發來的html頁面，在渲染並呈現到屏幕上以前，有不少步驟要作。瀏覽器渲染頁面須要作的一系列行爲被稱做「關鍵渲染路徑（Critical Rendering Path 簡稱CRP）」。

CRP 的知識對於如何提高網站性能是至關有用的。CRP有6個步驟：

構建DOM樹
構建CSSOM樹
運行JavaScript
建立渲染樹
生成佈局
繪製頁面

具體步驟請移駕 www.jianshu.com/p/e53141edc…

2. 1追問那script 標籤怎樣才能實現異步呢？

敲黑板重點：

一、把<script>標籤放在<head>中意味着必須等到所有的js代碼都下載解析和執行完成之後，纔開始展示頁面內容，爲避免這個問題通常把js代碼所有放在<body>元素內容後面

二、script標籤不帶defer和async屬性：同步模式，腳本獲取和執行都是同步，頁面會被阻塞，瀏覽器都會按照<script>元素在頁面中出現的前後順序對他們依次進行解析

同步模式：又稱阻塞模式，會阻止瀏覽器的後續執行，中止後續解析，只有當前加載完成才能進行下一步操做。

三、async屬性：html5的新屬性，只適合用於外部腳本文件，異步模式

經過createElement建立的script標籤其屬性async默認爲true

四、defer屬性：異步模式，只適合外部腳本文件，會被延遲到整個頁面都解析完畢後再運行，腳本加載不阻塞頁面的解析，同時帶有defer的腳本彼此之間，能保證其執行順序

補充：

<script>標籤打開defer或async屬性，腳本就會異步加載。渲染引擎遇到這一行命令，就會開始下載外部腳本，但不會等它下載和執行，而是直接執行後面的命令。

defer與async的區別是：defer要等到整個頁面在內存中正常渲染結束（DOM 結構徹底生成，以及其餘腳本執行完成），纔會執行；async一旦下載完，渲染引擎就會中斷渲染，執行這個腳本之後，再繼續渲染。一句話，defer是「渲染完再執行」，async是「下載完就執行」。另外，若是有多個defer腳本，會按照它們在頁面出現的順序加載，而多個async腳本是不能保證加載順序的。

3. 解釋下css盒模型(Box Model)

無需多言了吧，仍是貼的細則地址吧 www.runoob.com/css/css-box…

4. 解釋一下webpack的執行機制，和運行原理

Entry: 入口, webpack執行構建的第一步將從Entry開始，可抽象成輸入
Module: 模塊，在webpcak中一切皆模塊，一個模塊對應一個文件。webpack會從配置的Entry開始遞歸找出全部依賴的模塊。
Chunk: 代碼塊，一個Chunk由多個模塊組合而成，用於代碼合併於分割
Loader: 模塊轉換器，用於將模塊的原內容按照需求轉換成新內容。cookies
Plugin: 擴展插件，在webpcak構建流程中的特定時機注入擴展邏輯，來改變構建結果或作咱們想要的事情
Outout: 輸出結果，再webpack通過一些列處理並得出最終想要的代碼後輸出結果

webpcak在啓動後會從Entry裏配置的Module開始，遞歸解析Entry依賴的全部Module.每找到一個Module,就會根據配置的Loader去找出對應的轉換規則，對Module進行轉換後，再解析出當前Module依賴的Module。這些模塊會以Entry爲單位進行分組，一個Entry及其全部依賴的Module被分到一個組也就是一個Chunk.最後，webpack會將全部Chunk轉換成文件輸出。在整個流程中，webpack會在恰當的時機執行Plugin裏定義的邏輯。

細則：移駕 webpack 官網： webpack.docschina.org/