Day4 - 前端高頻面試題之瀏覽器相關

傳送門>>>

上一篇： Day3 - 前端高頻面試題之基礎版

下一篇： Day5 - 前端高頻面試題之計算機網絡相關

一、什麼是options預請求？

options預請求是瀏覽器自主發起的，分別根據預檢請求報文中的 Access-Control-Request-Method、Access-Control-Request-Headers來判斷該請求是不是服務器容許的提交方式和容許的請求頭字段；

服務器基於從預檢請求得到的信息來判斷，是否接受接下來的實際請求。

二、解釋一下事件冒泡和事件捕獲呢？如何阻止冒泡？如何阻止默認事件？手寫一個事件委託的例子呢？

一個完整的JS事件流是從window開始，最後回到window的一個過程； 事件流被分爲三個階段(1 ~ 5)捕獲過程、(5 ~ 6)目標過程、(6 ~ 10)冒泡過程。

事件冒泡就是事件從最深的節點開始，而後逐步向上傳播事件的過程；

事件捕獲就是從window開始，逐步向最深的節點傳播事件的過程

// 事件委託：就是把事件處理器添加到父元素，等待子元素事件冒泡，而且父元素可以經過target（IE爲srcElement）判斷是哪一個子元素，從而作相應處理

var ul = document.getElementByTagName('ul)[0]
ul.onclick = function(e) {
  e = e || window.event
  alert(e.target.innerHtml)
}

// 阻止冒泡: window.event? window.event.cancelBubble = true(IE) : e.stopPropagation()
// 阻止默認事件: e.preventDefault() || window.event.returnValue = false(IE)

複製代碼

三、請描述一下內存泄漏的緣由和場景？那js的垃圾回收機制有哪些？

內存泄漏指的是瀏覽器不能正常的回收內存的現象

1. 全局變量引發的內存泄漏
2. 閉包引發的內存泄漏
3. dom清空或刪除時，事件未清除致使的內存泄漏

---

當函數執行結束，局部變量就不須要了，這時候就能夠釋放他們的內存。

兩種回收機制：

• 引用計數法

跟蹤記錄每一個值被引用的次數。當聲明一個變量並將引用類型的值賦給該變量時，則這個值的引用次數就是1。若是同一個值又被賦給另外一個變量，則該值的引用次 數加1.相反，若是包含對這個值引用的變量又取得另一個值，則這個值的引用次數減1.當這個值的引用次數變成0時，則說明沒有辦法訪問這個值了，所以就 能夠將其佔用的內存空間回收回來

• 標記清除法 標記清除的算法分爲兩個階段，標記(mark)和清除(sweep) 第一階段從引用根節點開始標記全部被引用的對象，第二階段遍歷整個堆，把未標記的對象清除。

四、DOM事件中target和currentTarget的區別

• event.target 返回觸發事件的元素
• event.currentTarget 返回綁定事件的元素

五、跨域的幾種方式？

• （利用script標籤的跨域能力）跨域
• websocket（html5的新特性，是一種新協議）跨域
• 設置代理服務器（由服務器替咱們向不一樣源的服務器請求數據）
• CORS（跨源資源共享，cross origin resource sharing）
• iframe跨域
• postMessage(包含iframe的頁面向iframe傳遞消息)

六、說一下瀏覽器的緩存機制呢

瀏覽器緩存機制有兩種，一種爲強緩存，一種爲協商緩存。

對於強緩存，瀏覽器在第一次請求的時候，會直接下載資源，而後緩存在本地，第二次請求的時候，直接使用緩存。 對於協商緩存，第一次請求緩存且保存緩存標識與時間，重複請求向服務器發送緩存標識和最後緩存時間，服務端進行校驗，若是失效則使用緩存。

• 強緩存方案

Exprires：服務端的響應頭，第一次請求的時候，告訴客戶端，該資源何時會過時。Exprires的缺陷是必須保證服務端時間和客戶端時間嚴格同步。 Cache-control：max-age，表示該資源多少時間後過時，解決了客戶端和服務端時間必須同步的問題，

• 協商緩存方案

If-None-Match/ETag：緩存標識，對比緩存時使用它來標識一個緩存，第一次請求的時候，服務端會返回該標識給客戶端，客戶端在第二次請求的時候會帶上該標識與服務端進行對比並返回If-None-Match標識是否表示匹配。 Last-modified/If-Modified-Since：第一次請求的時候服務端返回Last-modified代表請求的資源上次的修改時間，第二次請求的時候客戶端帶上請求頭If-Modified-Since，表示資源上次的修改時間，服務端拿到這兩個字段進行對比。

七、請詳細描述一下從輸入URL到頁面加載的全過程

主幹流程：瀏覽器構建HTTP Request請求、網絡傳輸、服務器構建HTTP Response請求、網絡傳輸、瀏覽器渲染頁面。

1、構建請求

1. 應用層進行DNS解析

   • 這裏使用DNS預解析，能夠根據瀏覽器定義的規則，提早解析以後可能會用到的域名，使解析結果緩存到系統緩存中，縮短DNS解析時間，來提升網站的訪問速度

2. 應用層生成http請求報文

   • HTTP請求報文包括起始行、首部和主體部分
   • 起始行可能：GET https://baidu.com/ HTTP/1.1
   • 首部包括：HOST keep-alive Accpet-Encoding Accept-Language User-Agent Cookie等
   • 首部和主體內容之間有一個回車換行(CRLF)，主體內容即要傳輸的內容。若是是get請求，則主體內容爲空

3. 傳輸層創建TCP鏈接 （創建三次握手）

   傳輸協議主要有UDP（無鏈接的協議、不可靠）和TCP（有鏈接、可靠）兩種

   TCP可靠主要表如今：

   • 接收方會對接收到的數據進行確認
   • 發送方會重傳接收方未確認的數據
   • 接收方會對接收到的數據按照正確的順序進行從新排列，並刪除重複的數據
   • 提供了控制擁擠的機制

   

   • 三次握手：

     • 第一次握手：主機A發往主機B，主機A初始序號是X，設置SYN（同步）位，未設置ACK（確認）位
     • 第二次握手：主機B發往主機A，主機B初始序號是Y，ACK（確認號）是X+1，X+1暗示已經收到主機A發來主機B的同步序號。設置ACK位和SYN位
     • 第三次握手：主機A發往主機B，主機A初始序號是X+1，ACK是Y+1，Y+1暗示已經收到主機A發來主機B的同步序號。設置ACK位，未設置SYN位。

     三次握手解決的不只僅有序號問題，還解決了包括窗口大小、MTU(Maximum Transmission Unit,最大傳輸單元)，以及所指望的網絡延時等其餘問題。

   • 構建TCP請求會增長大量的網絡時延，經常使用的優化方式以下所示

     • 資源打包，合併請求
     • 多使用緩存，減小網絡傳輸
     • 使用keep-alive創建持久鏈接
     • 使用多個域名，增長瀏覽器的資源併發加載數，或者使用HTTP2的管道化鏈接的多路複用技術

4. 網絡層使用IP協議來選擇路線

5. 數據鏈路層實現網絡相鄰節點間的可靠的數據通訊

6. 物理層傳輸數據

2、網絡傳輸

​ 從客戶機到服務器須要經過許多網絡設備， 通常地，包括集線器、交換器、路由器等

3、服務器處理及反向傳輸

4、瀏覽器渲染

• 首先瀏覽器從服務器接收到html代碼，而後開始解析html
• 根據html代碼自頂向下構建DOM樹，而且同時構建渲染樹
• 遇到js文件加載執行，將阻塞DOM樹的構建
• 遇到css文件，將阻塞渲染樹的構建
• script標籤中的defer屬性：構建DOM樹的過程和js文件的加載異步（並行）進行，可是js文件執行須要在DOM樹構建完成以後
• script標籤中的async屬性：構建DOM樹、渲染樹的過程和js文件的加載和執行異步（並行）進行
• 因此script標籤最好放在標籤的前面，由於放在全部body中的標籤後面就不會出現網頁加載時出現空白的狀況，能夠持續的給用戶提供視覺反饋，同時在有些狀況下，會下降錯誤的發生。
• 而css標籤應該放在標籤之間，由於若是放在標籤的前面，那麼當DOM樹構建完成了，渲染樹才構建，那麼當渲染樹構建完成，瀏覽器不得再也不從新渲染整個頁面，這樣形成了資源的浪費。效率也不高。若是放在之間，瀏覽器邊構建邊渲染，效率要高的多。總的來講，就是提升性能，提升網頁的可讀性。

5、重繪和迴流

• 頁面生成之後，腳本操做、樣式表變動，以及用戶操做均可能觸發重繪和迴流
  • 迴流是指窗口尺寸被修改、發生滾動操做，或者元素位置相關屬性被更新時會觸發佈局過程，也就是從新進行流式佈局的過程。發生在Render樹上，常說的脫離文檔流，就是指脫離渲染樹Render Tree
  • 重繪是指當與視覺相關的樣式屬性值被更新時會觸發繪製過程，在繪製過程當中要從新計算元素的視覺信息，使元素呈現新的外觀。是發生在渲染層 render layer上
• 減小回流次數的方法
  • 不要一條一條地修改DOM樣式，而是修改className或者修改style.cssText
  • 在內存中屢次操做節點，完成後再添加到文檔中去
  • 對於一個元素進行復雜的操做時，能夠先隱藏它，操做完成後再顯示
  • 在須要常常獲取那些引發瀏覽器迴流的屬性值時，要緩存到變量中
  • 不要使用table佈局，由於一個小改動可能會形成整個table從新佈局。並且table渲染一般要3倍於同等元素時間
• 減小重繪範圍的方法
  • 將須要屢次重繪的元素獨立爲render layer渲染層，如設置absolute，能夠減小重繪範圍
  • 對於一些進行動畫的元素，能夠進行硬件渲染，從而避免重繪和迴流

八、http狀態碼

http狀態碼是表示服務器對請求的響應狀態， 主要分爲如下幾個部分

• 1**：這類響應是臨時響應，只包含狀態行和某些可選的響應頭信息，並以空行結束
• 2**：表示請求成功
• 3**：表示重定向
• 4**：表示客戶端錯誤
• 5**：表示服務器端錯誤
• 100（continue），客戶端應當繼續發送請求。這個臨時響應是用來通知客戶端它的部分請求已經被服務器接收
• 200（OK），表示請求成功，請求所但願的響應頭或數據體將隨此響應返回。
• 202（Accepted），服務器已接受請求，但還沒有處理。
• 204（No-Content），服務器成功處理了請求，但不須要返回任何實體內容
• 205（Reset-Content），服務器成功處理了請求，且沒有返回任何內容。可是與204響應不一樣，返回此狀態碼的響應要求請求者重置文檔視圖。該響應主要是被用於接受用戶輸入後，當即重置表單，以便用戶可以輕鬆地開始另外一次輸入。
• 206（Partial-Content），服務器已經成功處理了部分 GET 請求。
• 301（Moved-Permanently），永久性重定向
• 302（Moved-Temporarily），暫時性重定向
• 304（Not-Modified），瀏覽器端緩存的資源依然有效
• 400（Bad-Reques），請求有誤，當前請求沒法被服務器理解。
• 401（Unauthorized），當前請求須要用戶驗證。
• 403（Forbidden），服務器已經理解請求，可是拒絕執行它。
• 404（Not-Found），請求的資源沒有被找到
• 500（Interval Server Error），服務器內部錯誤
• 502（Bad GateWay），網關出錯
• 503（Service Unavailable），因爲臨時的服務器維護或者過載，服務器當前沒法處理請求。
• 504（Gateway Timeout），做爲網關或者代理工做的服務器嘗試執行請求時，未能及時從上游服務器（URI標識出的服務器，例如HTTP、FTP、LDAP）或者輔助服務器（例如DNS）收到響應。