文章目錄
- 1. HTTP的幾種請求方法用途
- 2. 介紹一下你對瀏覽器內核的理解？
- 3. 主流瀏覽器機器內核
- 4. 請描述一下 cookies，sessionStorage 和 localStorage 的區別？
- 5. HTML5的離線儲存怎麼使用，工作原理能不能解釋一下？
- 6. 如何實現瀏覽器內多個標籤頁之間的通信?
- 7. webSocket 如何兼容低瀏覽器？
- 8. 瀏覽器是怎麼對 HTML5 的離線儲存資源進行管理和加載的呢？
- 9. 從瀏覽器地址欄輸入url到顯示頁面的步驟有哪些？
- 10. 如何進行網站性能優化?
- 11. HTTP狀態碼及其含義
- 12.瀏覽器是怎麼對HTML5的離線儲存資源進行管理和加載的呢
- 13. web 網頁驗證碼是幹嘛的，是爲了解決什麼安全問題
- 14. 你能描述一下漸進增強和優雅降級之間的不同嗎
- 15. 爲什麼利用多個域名來存儲網站資源會更有效？
- 16. 如何優化圖片加載？
- 17. web開發中會話跟蹤的方法有哪些
- 18. HTTP request報文結構是怎樣的
- 19. HTTP response報文結構是怎樣的？
- 20. 一次js請求一般情況下有哪些地方會有緩存處理？
- 21. 渲染優化
1. HTTP的幾種請求方法用途
- GET方法：發送一個請求來取得服務器上的某一資源
- POST方法：向URL指定的資源提交數據或附加新的數據
- PUT方法：跟POST方法很像，也是想服務器提交數據。但是，它們之間有不同。PUT指定了資源在服務器上的位置，而POST沒有
- HEAD方法：只請求頁面的首部
- DELETE方法：刪除服務器上的某資源
- OPTIONS方法：它用於獲取當前URL所支持的方法。如果請求成功，會有一個Allow的頭包含類似“GET,POST”這樣的信息
- TRACE方法：TRACE方法被用於激發一個遠程的，應用層的請求消息迴路
- CONNECT方法：把請求連接轉換到透明的TCP/IP通道
2. 介紹一下你對瀏覽器內核的理解？
- 主要分成兩部分：渲染引擎(layout engineer 或 Rendering Engine)和 JS 引擎。
- 渲染引擎：負責取得網頁的內容（HTML、XML、圖像等等）、整理訊息（例如加入 CSS 等），以及計算網頁的顯示方式，然後渲染到用戶的屏幕上。
- JS 引擎：解析和執行 javascript 來實現邏輯和控制 DOM 進行交互。
- 最開始渲染引擎和 JS 引擎並沒有區分的很明確，後來 JS 引擎越來越獨立，內核就傾向於只指渲染引擎。
3. 主流瀏覽器機器內核
| 瀏覽器 | 內核 | 備註 |
|---|---|---|
| IE | Trident | IE、獵豹安全、360 極速瀏覽器、百度瀏覽器 |
| firefox | Gecko | |
| Safari | webkit | 從 Safari 推出之時起，它的渲染引擎就是 Webkit，一提到 webkit，首先想到的便是 chrome，Webkit 的鼻祖其實是 Safari。 |
| chrome | Chromium/Blink | 在 Chromium 項目中研發 Blink 渲染引擎（即瀏覽器核心），內置於 Chrome 瀏覽器之中。Blink 其實是 WebKit 的分支。大部分國產瀏覽器最新版都採用 Blink 內核。二次開發 |
| Opera | blink | Opera內核原爲：Presto，現在跟隨 chrome 用 blink 內核。 |
4. 請描述一下 cookies，sessionStorage 和 localStorage 的區別？
- cookie 是網站爲了標示用戶身份而儲存在用戶本地終端（Client Side）上的數據（通常經過加密）
- cookie 數據始終在同源的 http 請求中攜帶（即使不需要），記會在瀏覽器和服務器間來回傳遞。
- sessionStorage 和 localStorage 不會自動把數據發給服務器，僅在本地保存。
- 存儲大小：
- cookie 數據大小不能超過 4k。
- sessionStorage 和 localStorage 雖然也有存儲大小的限制，但比 cookie 大得多，可以達到 5M 或更大。
- 有效期（生命週期）：
- localStorage: 存儲持久數據，瀏覽器關閉後數據不丟失除非主動刪除數據；
- sessionStorage: 數據在當前瀏覽器窗口關閉後自動刪除。
- cookie: 設置的 cookie 過期時間之前一直有效，即使窗口或瀏覽器關閉
- 共享：
- sessionStorage不能共享，
- localStorage在同源文檔之間共享，
- cookie在同源且符合path規則的文檔之間共享
5. HTML5的離線儲存怎麼使用，工作原理能不能解釋一下？
- 在用戶沒有與因特網連接時，可以正常訪問站點或應用，在用戶與因特網連接時，更新用戶機器上的緩存文件
- 原理：HTML5的離線存儲是基於一個新建的.appcache文件的緩存機制(不是存儲技術)，通過這個文件上的解析清單離線存儲資源，這些資源就會像cookie一樣被存儲了下來。之後當網絡在處於離線狀態下時，瀏覽器會通過被離線存儲的數據進行頁面展示
- 如何使用：
- 頁面頭部像下面一樣加入一個manifest的屬性；
- 在cache.manifest文件的編寫離線存儲的資源
- 在離線狀態時，操作window.applicationCache進行需求實現
6. 如何實現瀏覽器內多個標籤頁之間的通信?
- WebSocket、SharedWorker；
- 也可以調用 localstorge、cookies 等本地存儲方式；
- localstorge 另一個瀏覽上下文裏被添加、修改或刪除時，它都會觸發一個
storage事件，我們通過監聽事件，控制它的值來進行頁面信息通信； - 注意 quirks：Safari 在無痕模式下設置 localstorge 值時會拋出 QuotaExceededError 的異常；
7. webSocket 如何兼容低瀏覽器？
- Adobe Flash Socket 、
- ActiveX HTMLFile (IE) 、
- 基於 multipart 編碼發送 XHR 、
- 基於長輪詢的 XHR
8. 瀏覽器是怎麼對 HTML5 的離線儲存資源進行管理和加載的呢？
- 在線的情況下，瀏覽器發現 html 頭部有 manifest 屬性，它會請求 manifest 文件，如果是第一次訪問 app，那麼瀏覽器就會根據 manifest 文件的內容下載相應的資源並且進行離線存儲。如果已經訪問過 app 並且資源已經離線存儲了，那麼瀏覽器就會使用離線的資源加載頁面，然後瀏覽器會對比新的 manifest 文件與舊的 manifest 文件，如果文件沒有發生改變，就不做任何操作，如果文件改變了，那麼就會重新下載文件中的資源並進行離線存儲。
- 離線的情況下，瀏覽器就直接使用離線存儲的資源。
- 在離線狀態時，操作 window.applicationCache 進行需求實現。參考鏈接：HTML5 離線緩存-manifest 簡介
9. 從瀏覽器地址欄輸入url到顯示頁面的步驟有哪些？
-
基礎版本
- 瀏覽器根據請求的URL交給DNS域名解析，找到真實IP，向服務器發起請求；
- 服務器交給後臺處理完成後返回數據，瀏覽器接收文件（HTML、JS、CSS、圖象等）；
- 瀏覽器對加載到的資源（HTML、JS、CSS等）進行語法解析，建立相應的內部數據結構（如HTML的DOM）；
- 載入解析到的資源文件，渲染頁面，完成。
-
詳細版
- 在瀏覽器地址欄輸入URL
- 瀏覽器查看緩存，如果請求資源在緩存中並且新鮮，跳轉到轉碼步驟
- 如果資源未緩存，發起新請求
- 如果已緩存，檢驗是否足夠新鮮，足夠新鮮直接提供給客戶端，否則與服務器進行驗證。
- 檢驗新鮮通常有兩個HTTP頭進行控制Expires和Cache-Control：
- HTTP1.0提供Expires，值爲一個絕對時間表示緩存新鮮日期
- HTTP1.1增加了Cache-Control: max-age=,值爲以秒爲單位的最大新鮮時間
- 瀏覽器解析URL獲取協議，主機，端口，path
- 瀏覽器組裝一個HTTP（GET）請求報文
- 瀏覽器獲取主機ip地址，過程如下：
- 瀏覽器緩存
- 本機緩存
- hosts文件
- 路由器緩存
- ISP DNS緩存
- DNS遞歸查詢（可能存在負載均衡導致每次IP不一樣）
- 打開一個socket與目標IP地址，端口建立TCP鏈接，三次握手如下：
- 客戶端發送一個TCP的SYN=1，Seq=X的包到服務器端口
- 服務器發回SYN=1， ACK=X+1， Seq=Y的響應包
- 客戶端發送ACK=Y+1， Seq=Z
- TCP鏈接建立後發送HTTP請求
- 服務器接受請求並解析，將請求轉發到服務程序，如虛擬主機使用HTTP Host頭部判斷請求的服務程序
- 服務器檢查HTTP請求頭是否包含緩存驗證信息如果驗證緩存新鮮，返回304等對應狀態碼
- 處理程序讀取完整請求並準備HTTP響應，可能需要查詢數據庫等操作
- 服務器將響應報文通過TCP連接發送回瀏覽器
- 瀏覽器接收HTTP響應，然後根據情況選擇關閉TCP連接或者保留重用，關閉TCP連接的四次握手如下：
- 主動方發送Fin=1， Ack=Z， Seq= X報文
- 被動方發送ACK=X+1， Seq=Z報文
- 被動方發送Fin=1， ACK=X， Seq=Y報文
- 主動方發送ACK=Y， Seq=X報文
- 瀏覽器檢查響應狀態嗎：是否爲1XX，3XX， 4XX， 5XX，這些情況處理與2XX不同
- 如果資源可緩存，進行緩存
- 對響應進行解碼（例如gzip壓縮）
- 根據資源類型決定如何處理（假設資源爲HTML文檔）
- 解析HTML文檔，構件DOM樹，下載資源，構造CSSOM樹，執行js腳本，這些操作沒有嚴格的先後順序，以下分別解釋
- 構建DOM樹：
- Tokenizing：根據HTML規範將字符流解析爲標記
- Lexing：詞法分析將標記轉換爲對象並定義屬性和規則
- DOM construction：根據HTML標記關係將對象組成DOM樹
- 解析過程中遇到圖片、樣式表、js文件，啓動下載
- 構建CSSOM樹：
- Tokenizing：字符流轉換爲標記流
- Node：根據標記創建節點
- CSSOM：節點創建CSSOM樹
- 根據DOM樹和CSSOM樹構建渲染樹:
- 從DOM樹的根節點遍歷所有可見節點，不可見節點包括:
- script,meta這樣本身不可見的標籤。
- 被css隱藏的節點，如display: none
- 對每一個可見節點，找到恰當的CSSOM規則並應用
- 發佈可視節點的內容和計算樣式
- 從DOM樹的根節點遍歷所有可見節點，不可見節點包括:
- js解析如下：
- 瀏覽器創建Document對象並解析HTML，將解析到的元素和文本節點添加到文檔中，此時document.readystate爲loading
- HTML解析器遇到沒有async和defer的script時，將他們添加到文檔中，然後執行行內或外部腳本。這些腳本會同步執行，並且在腳本下載和執行時解析器會暫停。這樣就可以用document.write()把文本插入到輸入流中。同步腳本經常簡單定義函數和註冊事件處理程序，他們可以遍歷和操作script和他們之前的文檔內容
- 當解析器遇到設置了async屬性的script時，開始下載腳本並繼續解析文檔。腳本會在它下載完成後儘快執行，但是解析器不會停下來等它下載。異步腳本禁止使用document.write()，它們可以訪問自己script和之前的文檔元素
- 當文檔完成解析，document.readState變成interactive
- 所有defer腳本會按照在文檔出現的順序執行，延遲腳本能訪問完整文檔樹，禁止使用document.write()
- 瀏覽器在Document對象上觸發DOMContentLoaded事件
- 此時文檔完全解析完成，瀏覽器可能還在等待如圖片等內容加載，等這些內容完成載入並且所有異步腳本完成載入和執行，document.readState變爲complete，window觸發load事件
- 顯示頁面（HTML解析過程中會逐步顯示頁面）
-
詳細簡版
- 從瀏覽器接收url到開啓網絡請求線程（這一部分可以展開瀏覽器的機制以及進程與線程之間的關係）
- 開啓網絡線程到發出一個完整的HTTP請求（這一部分涉及到dns查詢，TCP/IP請求，五層因特網協議棧等知識）
- 從服務器接收到請求到對應後臺接收到請求（這一部分可能涉及到負載均衡，安全攔截以及後臺內部的處理等等）
- 後臺和前臺的HTTP交互（這一部分包括HTTP頭部、響應碼、報文結構、cookie等知識，可以提下靜態資源的cookie優化，以及編碼解碼，如gzip壓縮等）
- 單獨拎出來的緩存問題，HTTP的緩存（這部分包括http緩存頭部，ETag，catch-control等）
- 瀏覽器接收到HTTP數據包後的解析流程（解析html-詞法分析然後解析成dom樹、解析css生成css規則樹、合併成render樹，然後layout、painting渲染、複合圖層的合成、GPU繪製、外鏈資源的處理、loaded和DOMContentLoaded等）
- CSS的可視化格式模型（元素的渲染規則，如包含塊，控制框，BFC，IFC等概念）
- JS引擎解析過程（JS的解釋階段，預處理階段，執行階段生成執行上下文，VO，作用域鏈、回收機制等等）
- 其它（可以拓展不同的知識模塊，如跨域，web安全，hybrid模式等等內容）
10. 如何進行網站性能優化?
- content方面
- 減少HTTP請求：合併文件、CSS精靈、inline Image
- 減少DNS查詢：DNS緩存、將資源分佈到恰當數量的主機名
- 減少DOM元素數量
- Server方面
- 使用CDN
- 配置ETag
- 對組件使用Gzip壓縮
- Cookie方面
- 減小cookie大小
- css方面
- 將樣式表放到頁面頂部
- 不使用CSS表達式
- 使用不使用@import
- Javascript方面
- 將腳本放到頁面底部
- 將javascript和css從外部引入
- 壓縮javascript和css
- 刪除不需要的腳本
- 減少DOM訪問
- 圖片方面
- 優化圖片：根據實際顏色需要選擇色深、壓縮
- 優化css精靈
- 不要在HTML中拉伸圖片
11. HTTP狀態碼及其含義
-
1XX：信息狀態碼
- 100 Continue 繼續，一般在發送post請求時，已發送了http header之後服務端將返回此信息，表示確認，之後發送具體參數信息
-
2XX：成功狀態碼
- 200 OK 正常返回信息
- 201 Created 請求成功並且服務器創建了新的資源
- 202 Accepted 服務器已接受請求，但尚未處理
-
3XX：重定向
- 301 Moved Permanently 請求的網頁已永久移動到新位置。
- 302 Found 臨時性重定向。
- 303 See Other 臨時性重定向，且總是使用 GET 請求新的 URI。
304 Not Modified 自從上次請求後，請求的網頁未修改過。
-
4XX：客戶端錯誤
- 400 Bad Request 服務器無法理解請求的格式，客戶端不應當嘗試再次使用相同的內容發起請求。
- 401 Unauthorized 請求未授權。
- 403 Forbidden 禁止訪問。
- 404 Not Found 找不到如何與 URI 相匹配的資源。
-
5XX: 服務器錯誤
- 500 Internal Server Error 最常見的服務器端錯誤。
- 503 Service Unavailable 服務器端暫時無法處理請求（可能是過載或維護）。
12.瀏覽器是怎麼對HTML5的離線儲存資源進行管理和加載的呢
- 在線的情況下，瀏覽器發現html頭部有manifest屬性，它會請求manifest文件，如果是第一次訪問app，那麼瀏覽器就會根據manifest文件的內容下載相應的資源並且進行離線存儲。如果已經訪問過app並且資源已經離線存儲了，那麼瀏覽器就會使用離線的資源加載頁面，然後瀏覽器會對比新的manifest文件與舊的manifest文件，如果文件沒有發生改變，就不做任何操作，如果文件改變了，那麼就會重新下載文件中的資源並進行離線存儲。
- 離線的情況下，瀏覽器就直接使用離線存儲的資源。
13. web 網頁驗證碼是幹嘛的，是爲了解決什麼安全問題
- 區分用戶是計算機還是人的公共全自動程序。可以防止惡意破解密碼、刷票、論壇灌水
- 有效防止黑客對某一個特定註冊用戶用特定程序暴力破解方式進行不斷的登陸嘗試
14. 你能描述一下漸進增強和優雅降級之間的不同嗎
-
漸進增強：針對低版本瀏覽器進行構建頁面，保證最基本的功能，然後再針對高級瀏覽器進行效果、交互等改進和追加功能達到更好的用戶體驗。
-
優雅降級：一開始就構建完整的功能，然後再針對低版本瀏覽器進行兼容。
區別：優雅降級是從複雜的現狀開始，並試圖減少用戶體驗的供給，而漸進增強則是從一個非常基礎的，能夠起作用的版本開始，並不斷擴充，以適應未來環境的需要。降級（功能衰減）意味着往回看；而漸進增強則意味着朝前看，同時保證其根基處於安全地帶
15. 爲什麼利用多個域名來存儲網站資源會更有效？
1. CDN緩存更方便
2. 突破瀏覽器併發限制
3. 節約cookie帶寬
4. 節約主域名的連接數，優化頁面響應速度
5. 防止不必要的安全問題
16. 如何優化圖片加載？
一個頁面上有大量的圖片（大型電商網站），加載很慢，你有哪些方法優化這些圖片的加載，給用戶更好的體驗。
- 圖片懶加載，在頁面上的未可視區域可以添加一個滾動事件，判斷圖片位置與瀏覽器頂端的距離與頁面的距離，如果前者小於後者，優先加載。
- 如果爲幻燈片、相冊等，可以使用圖片預加載技術，將當前展示圖片的前一張和後一張優先下載。
- 如果圖片爲css圖片，可以使用CSSsprite，SVGsprite，Iconfont、Base64等技術。
- 如果圖片過大，可以使用特殊編碼的圖片，加載時會先加載一張壓縮的特別厲害的縮略圖，以提高用戶體驗。
- 如果圖片展示區域小於圖片的真實大小，則因在服務器端根據業務需要先行進行圖片壓縮，圖片壓縮後大小與展示一致。
17. web開發中會話跟蹤的方法有哪些
- cookie
- session
- url重寫
- 隱藏input
- ip地址
18. HTTP request報文結構是怎樣的
-
首行是Request-Line包括：請求方法，請求URI，協議版本，CRLF
-
首行之後是若干行請求頭，包括general-header，request-header或者entity-header，每個一行以CRLF結束
-
請求頭和消息實體之間有一個CRLF分隔
-
根據實際請求需要可能包含一個消息實體一個請求報文例子如下：
GET /Protocols/rfc2616/rfc2616-sec5.html HTTP/1.1
Host: www.w3.org
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
Referer: https://www.google.com.hk/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: zh-CN,zh;q=0.8,en;q=0.6
Cookie: authorstyle=yes
If-None-Match: "2cc8-3e3073913b100"
If-Modified-Since: Wed, 01 Sep 2004 13:24:52 GMT
name=qiu&age=25
19. HTTP response報文結構是怎樣的？
-
首行是狀態行包括：HTTP版本，狀態碼，狀態描述，後面跟一個CRLF
-
首行之後是若干行響應頭，包括：通用頭部，響應頭部，實體頭部
-
響應頭部和響應實體之間用一個CRLF空行分隔
-
最後是一個可能的消息實體響應報文例子如下：
HTTP/1.1 200 OK
`Date: Tue, 08 Jul 2014 05:28:43 GMT`
`Server: Apache/2`
`Last-Modified: Wed, 01 Sep 2004 13:24:52 GMT`
`ETag: "40d7-3e3073913b100"`
`Accept-Ranges: bytes`
`Content-Length: 16599`
`Cache-Control: max-age=21600`
`Expires: Tue, 08 Jul 2014 11:28:43 GMT`
`P3P: policyref="http://www.w3.org/2001/05/P3P/p3p.xml"`
`Content-Type: text/html; charset=iso-8859-1`
`{"name": "qiu", "age": 25}`
20. 一次js請求一般情況下有哪些地方會有緩存處理？
web 在css/js代碼上線之後開發人員經常會優化性能，從用戶刷新網頁開始，一次js請求一般情況下有哪些地方會有緩存處理？
dns緩存，cdn緩存，瀏覽器緩存，服務器緩存
21. 渲染優化
-
禁止使用iframe（阻塞父文檔onload事件）
- iframe會阻塞主頁面的Onload事件
- 搜索引擎的檢索程序無法解讀這種頁面，不利於SEO
- iframe和主頁面共享連接池，而瀏覽器對相同域的連接有限制，所以會影響頁面的並行加載
- 使用iframe之前需要考慮這兩個缺點。如果需要使用iframe，最好是通過javascript，動態給iframe添加src屬性值，這樣可以繞開以上兩個問題
-
禁止使用gif圖片實現loading效果（降低CPU消耗，提升渲染性能）
-
使用CSS3代碼代替JS動畫（儘可能避免重繪重排以及迴流）
-
對於一些小圖標，可以使用base64位編碼，以減少網絡請求。但不建議大圖使用，比較耗費CPU
-
小圖標優勢在於
- 減少HTTP請求
- 避免文件跨域
- 修改及時生效
-
頁面頭部的 會阻塞頁面；（因爲 Renderer進程中 JS線程和渲染線程是互斥的）
-
頁面中空的 href 和 src 會阻塞頁面其他資源的加載 (阻塞下載進程)
-
網頁gzip，CDN託管，data緩存 ，圖片服務器
-
前端模板 JS+數據，減少由於HTML標籤導致的帶寬浪費，前端用變量保存AJAX請求結果，每次操作本地變量，不用請求，減少請求次數
-
用innerHTML代替DOM操作，減少DOM操作次數，優化javascript性能
-
當需要設置的樣式很多時設置className而不是直接操作style
-
少用全局變量、緩存DOM節點查找的結果。減少IO讀取操作
-
圖片預加載，將樣式表放在頂部，將腳本放在底部 加上時間戳
-
對普通的網站有一個統一的思路，就是儘量向前端優化、減少數據庫操作、減少磁盤IO