前端知识总结之浏览器知识
1對(duì)瀏覽器的理解
? 瀏覽器的主要功能是將用戶選擇的 web 資源呈現(xiàn)出來，它需要從服務(wù)器請(qǐng)求資源，并將其顯示在瀏覽器窗口中，資源的格式通常 是 HTML，也包括 PDF、image 及其他格式。用戶用 URI（Uniform Resource Identifier 統(tǒng)一資源標(biāo)識(shí)符）來指定所請(qǐng) 求資源的位置。
? HTML 和 CSS 規(guī)范中規(guī)定了瀏覽器解釋 html 文檔的方式，由 W3C 組織對(duì)這些規(guī)范進(jìn)行維護(hù)，W3C 是負(fù)責(zé)制定 web 標(biāo)準(zhǔn)的 組織。
? 但是瀏覽器廠商紛紛開發(fā)自己的擴(kuò)展，對(duì)規(guī)范的遵循并不完善，這為 web 開發(fā)者帶來了嚴(yán)重的兼容性問題。
? 簡(jiǎn)單來說瀏覽器可以分為兩部分，shell 和 內(nèi)核。
? 其中 shell 的種類相對(duì)比較多，內(nèi)核則比較少。shell 是指瀏覽器的外殼：例如菜單，工具欄等。主要是提供給用戶界面操作， 參數(shù)設(shè)置等等。它是調(diào)用內(nèi)核來實(shí)現(xiàn)各種功能的。內(nèi)核才是瀏覽器的核心。內(nèi)核是基于標(biāo)記語言顯示內(nèi)容的程序或模塊。也有一些 瀏覽器并不區(qū)分外殼和內(nèi)核。從 Mozilla 將 Gecko 獨(dú)立出來后，才有了外殼和內(nèi)核的明確劃分。
2. 瀏覽器內(nèi)核
? 主要分成兩部分：渲染引擎和 JS 引擎。
? 渲染引擎的職責(zé)就是渲染，即在瀏覽器窗口中顯示所請(qǐng)求的內(nèi)容。默認(rèn)情況下，渲染引擎可以顯示 html、xml 文檔及圖片，它也 可以借助插件（一種瀏覽器擴(kuò)展）顯示其他類型數(shù)據(jù)，例如使用 PDF 閱讀器插件，可以顯示 PDF 格式。
? JS 引擎：解析和執(zhí)行 javascript 來實(shí)現(xiàn)網(wǎng)頁的動(dòng)態(tài)效果。
? 最開始渲染引擎和 JS 引擎并沒有區(qū)分的很明確，后來 JS 引擎越來越獨(dú)立，內(nèi)核就傾向于只指渲染引擎。
3. 常見的瀏覽器內(nèi)核比較
五大主流瀏覽器內(nèi)核的源起以及國(guó)內(nèi)各大瀏覽器內(nèi)核總結(jié)
? Trident：這種瀏覽器內(nèi)核是 IE 瀏覽器用的內(nèi)核，因?yàn)樵谠缙?IE 占有大量的市場(chǎng)份額，所以這種內(nèi)核比較流行，以前有很多 網(wǎng)頁也是根據(jù)這個(gè)內(nèi)核的標(biāo)準(zhǔn)來編寫的，但是實(shí)際上這個(gè)內(nèi)核對(duì)真正的網(wǎng)頁標(biāo)準(zhǔn)支持不是很好。但是由于 IE 的高市場(chǎng)占有率，微 軟也很長(zhǎng)時(shí)間沒有更新 Trident 內(nèi)核，就導(dǎo)致了 Trident 內(nèi)核和 W3C 標(biāo)準(zhǔn)脫節(jié)。還有就是 Trident 內(nèi)核的大量 Bug 等 安全問題沒有得到解決，加上一些專家學(xué)者公開自己認(rèn)為 IE 瀏覽器不安全的觀點(diǎn)，使很多用戶開始轉(zhuǎn)向其他瀏覽器。
? Gecko：這是 Firefox 和 Flock 所采用的內(nèi)核，這個(gè)內(nèi)核的優(yōu)點(diǎn)就是功能強(qiáng)大、豐富，可以支持很多復(fù)雜網(wǎng)頁效果和瀏覽器擴(kuò) 展接口，但是代價(jià)是也顯而易見就是要消耗很多的資源，比如內(nèi)存。
? Presto：Opera 曾經(jīng)采用的就是 Presto 內(nèi)核，Presto 內(nèi)核被稱為公認(rèn)的瀏覽網(wǎng)頁速度最快的內(nèi)核，這得益于它在開發(fā)時(shí)的 天生優(yōu)勢(shì)，在處理 JS 腳本等腳本語言時(shí)，會(huì)比其他的內(nèi)核快3倍左右，缺點(diǎn)就是為了達(dá)到很快的速度而丟掉了一部分網(wǎng)頁兼容性。
? Webkit：Webkit 是 Safari 采用的內(nèi)核，它的優(yōu)點(diǎn)就是網(wǎng)頁瀏覽速度較快，雖然不及 Presto 但是也勝于 Gecko 和 Trid ent，缺點(diǎn)是對(duì)于網(wǎng)頁代碼的容錯(cuò)性不高，也就是說對(duì)網(wǎng)頁代碼的兼容性較低，會(huì)使一些編寫不標(biāo)準(zhǔn)的網(wǎng)頁無法正確顯示。WebKit 前身是 KDE 小組的 KHTML 引擎，可以說 WebKit 是 KHTML 的一個(gè)開源的分支。
? Blink：谷歌在 Chromium Blog 上發(fā)表博客，稱將與蘋果的開源瀏覽器核心 Webkit 分道揚(yáng)鑣，在 Chromium 項(xiàng)目中研發(fā) B link 渲染引擎（即瀏覽器核心），內(nèi)置于 Chrome 瀏覽器之中。其實(shí) Blink 引擎就是 Webkit 的一個(gè)分支，就像 webkit 是 KHTML 的分支一樣。Blink 引擎現(xiàn)在是谷歌公司與 Opera Software 共同研發(fā)，上面提到過的，Opera 棄用了自己的 Presto 內(nèi)核，加入 Google 陣營(yíng)，跟隨谷歌一起研發(fā) Blink。
4. 瀏覽器的渲染原理？
5. 渲染過程中遇到 JS 文件怎么處理？（瀏覽器解析過程）
JavaScript 的加載、解析與執(zhí)行會(huì)阻塞文檔的解析，也就是說，在構(gòu)建 DOM 時(shí)，HTML 解析器若遇到了 JavaScript，那么 它會(huì)暫停文檔的解析，將控制權(quán)移交給 JavaScript 引擎，等 JavaScript 引擎運(yùn)行完畢，瀏覽器再?gòu)闹袛嗟牡胤交謴?fù)繼續(xù)解 析文檔。 也就是說，如果你想首屏渲染的越快，就越不應(yīng)該在首屏就加載 JS 文件，這也是都建議將 script 標(biāo)簽放在 body 標(biāo)簽底部的 原因。當(dāng)然在當(dāng)下，并不是說 script 標(biāo)簽必須放在底部，因?yàn)槟憧梢越o script 標(biāo)簽添加 defer 或者 async 屬性。
6. async 和 defer 的作用是什么？有什么區(qū)別？（瀏覽器解析過程）
腳本沒有 defer 或 async，瀏覽器會(huì)立即加載并執(zhí)行指定的腳本，也就是說不等待后續(xù)載入的文檔元素，讀到就加載并執(zhí) 行。回到頂部
7. 什么是文檔的預(yù)解析？（瀏覽器解析過程）
Webkit 和 Firefox 都做了這個(gè)優(yōu)化，當(dāng)執(zhí)行 JavaScript 腳本時(shí)，另一個(gè)線程解析剩下的文檔，并加載后面需要通過網(wǎng)絡(luò)加 載的資源。這種方式可以使資源并行加載從而使整體速度更快。需要注意的是，預(yù)解析并不改變 DOM 樹，它將這個(gè)工作留給主解析 過程，自己只解析外部資源的引用，比如外部腳本、樣式表及圖片。
8. 渲染頁面時(shí)常見哪些不良現(xiàn)象？（瀏覽器渲染過程）
? FOUC：主要指的是樣式閃爍的問題，由于瀏覽器渲染機(jī)制（比如firefox），在 CSS 加載之前，先呈現(xiàn)了 HTML，就會(huì)導(dǎo)致展示 出無樣式內(nèi)容，然后樣式突然呈現(xiàn)的現(xiàn)象。會(huì)出現(xiàn)這個(gè)問題的原因主要是 css 加載時(shí)間過長(zhǎng)，或者 css 被放在了文檔底 部。
? 白屏：有些瀏覽器渲染機(jī)制（比如chrome）要先構(gòu)建 DOM 樹和 CSSOM 樹，構(gòu)建完成后再進(jìn)行渲染，如果 CSS 部分放在 HTML 尾部，由于 CSS 未加載完成，瀏覽器遲遲未渲染，從而導(dǎo)致白屏；也可能是把 js 文件放在頭部，腳本的加載會(huì)阻塞后面 文檔內(nèi)容的解析，從而頁面遲遲未渲染出來，出現(xiàn)白屏問題。
9. CSS 如何阻塞文檔解析？（瀏覽器解析過程）
? 理論上，既然樣式表不改變 DOM 樹，也就沒有必要停下文檔的解析等待它們，然而，存在一個(gè)問題，JavaScript 腳本執(zhí)行時(shí)可 能在文檔的解析過程中請(qǐng)求樣式信息，如果樣式還沒有加載和解析，腳本將得到錯(cuò)誤的值，顯然這將會(huì)導(dǎo)致很多問題。
? 所以如果瀏覽器尚未完成 CSSOM 的下載和構(gòu)建，而我們卻想在此時(shí)運(yùn)行腳本，那么瀏覽器將延遲 JavaScript 腳本執(zhí)行和文檔 的解析，直至其完成 CSSOM 的下載和構(gòu)建。也就是說，在這種情況下，瀏覽器會(huì)先下載和構(gòu)建 CSSOM，然后再執(zhí)行 JavaScript， 最后再繼續(xù)文檔的解析。
10. 如何優(yōu)化關(guān)鍵渲染路徑？（瀏覽器渲染過程）
為盡快完成首次渲染，我們需要最大限度減小以下三種可變因素：
（1）關(guān)鍵資源的數(shù)量。
（2）關(guān)鍵路徑長(zhǎng)度。
（3）關(guān)鍵字節(jié)的數(shù)量。
關(guān)鍵資源是可能阻止網(wǎng)頁首次渲染的資源。這些資源越少，瀏覽器的工作量就越小，對(duì) CPU 以及其他資源的占用也就越少。
同樣，關(guān)鍵路徑長(zhǎng)度受所有關(guān)鍵資源與其字節(jié)大小之間依賴關(guān)系圖的影響：某些資源只能在上一資源處理完畢之后才能開始下載， 并且資源越大，下載所需的往返次數(shù)就越多。
最后，瀏覽器需要下載的關(guān)鍵字節(jié)越少，處理內(nèi)容并讓其出現(xiàn)在屏幕上的速度就越快。要減少字節(jié)數(shù)，我們可以減少資源數(shù)（將它 們刪除或設(shè)為非關(guān)鍵資源），此外還要壓縮和優(yōu)化各項(xiàng)資源，確保最大限度減小傳送大小。
優(yōu)化關(guān)鍵渲染路徑的常規(guī)步驟如下：
（1）對(duì)關(guān)鍵路徑進(jìn)行分析和特性描述：資源數(shù)、字節(jié)數(shù)、長(zhǎng)度。
（2）最大限度減少關(guān)鍵資源的數(shù)量：刪除它們，延遲它們的下載，將它們標(biāo)記為異步等。
（3）優(yōu)化關(guān)鍵字節(jié)數(shù)以縮短下載時(shí)間（往返次數(shù)）。
（4）優(yōu)化其余關(guān)鍵資源的加載順序：您需要盡早下載所有關(guān)鍵資產(chǎn)，以縮短關(guān)鍵路徑長(zhǎng)度。
11 什么是重繪和回流？（瀏覽器繪制過程）
重繪: 當(dāng)渲染樹中的一些元素需要更新屬性，而這些屬性只是影響元素的外觀、風(fēng)格，而不會(huì)影響布局的操作，比如 background -color，我們將這樣的操作稱為重繪。
回流：當(dāng)渲染樹中的一部分（或全部）因?yàn)樵氐囊?guī)模尺寸、布局、隱藏等改變而需要重新構(gòu)建的操作，會(huì)影響到布局的操作，這樣 的操作我們稱為回流。
常見引起回流屬性和方法： 任何會(huì)改變?cè)貛缀涡畔?#xff08;元素的位置和尺寸大小）的操作，都會(huì)觸發(fā)回流。
32. 添加或者刪除可見的 DOM 元素；
33. 元素尺寸改變——邊距、填充、邊框、寬度和高度
34. 內(nèi)容變化，比如用戶在 input 框中輸入文字
35. 瀏覽器窗口尺寸改變——resize事件發(fā)生時(shí)
36. 計(jì)算 offsetWidth 和 offsetHeight 屬性
37. 設(shè)置 style 屬性的值
38. 當(dāng)你修改網(wǎng)頁的默認(rèn)字體時(shí)。 回流必定會(huì)發(fā)生重繪，重繪不一定會(huì)引發(fā)回流。回流所需的成本比重繪高的多，改變父節(jié)點(diǎn)里的子節(jié)點(diǎn)很可能會(huì)導(dǎo)致父節(jié)點(diǎn)的一系列 回流。
12. 如何減少回流？（瀏覽器繪制過程）
13. 為什么操作 DOM 慢？（瀏覽器繪制過程）
一些 DOM 的操作或者屬性訪問可能會(huì)引起頁面的回流和重繪，從而引起性能上的消耗。
14. DOMContentLoaded 事件和 Load 事件的區(qū)別？
? 當(dāng)初始的 HTML 文檔被完全加載和解析完成之后，DOMContentLoaded 事件被觸發(fā)，而無需等待樣式表、圖像和 子框架的加載完成。
? Load 事件是當(dāng)所有資源加載完成后觸發(fā)的。
回到頂部
15. 主流瀏覽器內(nèi)核私有屬性 css 前綴？
? mozilla 內(nèi)核 （firefox,flock 等） -moz
? webkit 內(nèi)核 （safari,chrome 等） -webkit
? opera 內(nèi)核 （opera 瀏覽器） -o
? trident 內(nèi)核 （ie 瀏覽器） -ms
16、什么叫優(yōu)雅降級(jí)和漸進(jìn)增強(qiáng)？
漸進(jìn)增強(qiáng) progressive enhancement：
針對(duì)低版本瀏覽器進(jìn)行構(gòu)建頁面，保證最基本的功能，然后再針對(duì)高級(jí)瀏覽器進(jìn)行效果、交互等改進(jìn)和追加功能達(dá)到更好的用戶體驗(yàn)。
優(yōu)雅降級(jí) graceful degradation：
一開始就構(gòu)建完整的功能，然后再針對(duì)低版本瀏覽器進(jìn)行兼容。
區(qū)別：
a. 優(yōu)雅降級(jí)是從復(fù)雜的現(xiàn)狀開始，并試圖減少用戶體驗(yàn)的供給
b. 漸進(jìn)增強(qiáng)則是從一個(gè)非常基礎(chǔ)的，能夠起作用的版本開始，并不斷擴(kuò)充，以適應(yīng)未來環(huán)境的需要
c. 降級(jí)（功能衰減）意味著往回看；而漸進(jìn)增強(qiáng)則意味著朝前看，同時(shí)保證其根基處于安全地帶
17、sessionStorage 、localStorage 和 cookie 之間的區(qū)別
共同點(diǎn)：用于瀏覽器端存儲(chǔ)的緩存數(shù)據(jù)
不同點(diǎn)：
(1)、存儲(chǔ)內(nèi)容是否發(fā)送到服務(wù)器端：當(dāng)設(shè)置了Cookie后，數(shù)據(jù)會(huì)發(fā)送到服務(wù)器端，造成一定的寬帶浪費(fèi)；
web storage,會(huì)將數(shù)據(jù)保存到本地，不會(huì)造成寬帶浪費(fèi)；(2)、數(shù)據(jù)存儲(chǔ)大小不同：Cookie數(shù)據(jù)不能超過4K,適用于會(huì)話標(biāo)識(shí)；web storage數(shù)據(jù)存儲(chǔ)可以達(dá)到5M;
(3)、數(shù)據(jù)存儲(chǔ)的有效期限不同：cookie只在設(shè)置了Cookid過期時(shí)間之前一直有效，即使關(guān)閉窗口或者瀏覽器；
sessionStorage,僅在關(guān)閉瀏覽器之前有效；localStorage,數(shù)據(jù)存儲(chǔ)永久有效；(4)、作用域不同：cookie和localStorage是在同源同窗口中都是共享的；sessionStorage不在不同的瀏覽器窗口中共享，即使是同一個(gè)頁面；
18、Web Storage與Cookie相比存在的優(yōu)勢(shì)：
(1)、存儲(chǔ)空間更大：IE8下每個(gè)獨(dú)立的存儲(chǔ)空間為10M，其他瀏覽器實(shí)現(xiàn)略有不同，但都比Cookie要大很多。
(2)、存儲(chǔ)內(nèi)容不會(huì)發(fā)送到服務(wù)器：當(dāng)設(shè)置了Cookie后，Cookie的內(nèi)容會(huì)隨著請(qǐng)求一并發(fā)送的服務(wù)器，這對(duì)于本地存儲(chǔ)的數(shù)據(jù)是一種帶寬浪費(fèi)。而Web Storage中的數(shù)據(jù)則僅僅是存在本地，不會(huì)與服務(wù)器發(fā)生任何交互。
(3)、更多豐富易用的接口：Web Storage提供了一套更為豐富的接口，如setItem,getItem,removeItem,clear等,使得數(shù)據(jù)操作更為簡(jiǎn)便。cookie需要自己封裝。
(4)、獨(dú)立的存儲(chǔ)空間：每個(gè)域（包括子域）有獨(dú)立的存儲(chǔ)空間，各個(gè)存儲(chǔ)空間是完全獨(dú)立的，因此不會(huì)造成數(shù)據(jù)混亂。
19、請(qǐng)指出document load和document ready的區(qū)別？
共同點(diǎn)：這兩種事件都代表的是頁面文檔加載時(shí)觸發(fā)。
異同點(diǎn)：
ready 事件的觸發(fā)，表示文檔結(jié)構(gòu)已經(jīng)加載完成（不包含圖片等非文字媒體文件）。
onload 事件的觸發(fā)，表示頁面包含圖片等文件在內(nèi)的所有元素都加載完成。
開發(fā)及性能優(yōu)化
1、規(guī)避javascript多人開發(fā)函數(shù)重名問題
命名空間
封閉空間
js模塊化mvc（數(shù)據(jù)層、表現(xiàn)層、控制層）
seajs
變量轉(zhuǎn)換成對(duì)象的屬性
對(duì)象化
2、請(qǐng)說出三種減低頁面加載時(shí)間的方法
壓縮css、js文件
合并js、css文件，減少http請(qǐng)求
外部js、css文件放在最底下
減少dom操作，盡可能用變量替代不必要的dom操作
3、你所了解到的Web攻擊技術(shù)
（1）XSS（Cross-Site Scripting，跨站腳本攻擊）：指通過存在安全漏洞的Web網(wǎng)站注冊(cè)用戶的瀏覽器內(nèi)運(yùn)行非法的HTML標(biāo)簽或者JavaScript進(jìn)行的一種攻擊。
（2）SQL注入攻擊
（3）CSRF（Cross-Site Request Forgeries，跨站點(diǎn)請(qǐng)求偽造）：指攻擊者通過設(shè)置好的陷阱，強(qiáng)制對(duì)已完成的認(rèn)證用戶進(jìn)行非預(yù)期的個(gè)人信息或設(shè)定信息等某些狀態(tài)更新。
4、web前端開發(fā)，如何提高頁面性能優(yōu)化？
內(nèi)容方面：
1.減少 HTTP 請(qǐng)求 (Make Fewer HTTP Requests)
2.減少 DOM 元素?cái)?shù)量 (Reduce the Number of DOM Elements)
3.使得 Ajax 可緩存 (Make Ajax Cacheable)
針對(duì)CSS：
1.把 CSS 放到代碼頁上端 (Put Stylesheets at the Top)
2.從頁面中剝離 JavaScript 與 CSS (Make JavaScript and CSS External)
3.精簡(jiǎn) JavaScript 與 CSS (Minify JavaScript and CSS)
4.避免 CSS 表達(dá)式 (Avoid CSS Expressions)
針對(duì)JavaScript ：
腳本放到 HTML 代碼頁底部 (Put Scripts at the Bottom)
從頁面中剝離 JavaScript 與 CSS (Make JavaScript and CSS External)
精簡(jiǎn) JavaScript 與 CSS (Minify JavaScript and CSS)
移除重復(fù)腳本 (Remove Duplicate Scripts)
面向圖片(Image)：
1.優(yōu)化圖片
2 不要在 HTML 中使用縮放圖片
3 使用恰當(dāng)?shù)膱D片格式
4 使用 CSS Sprites 技巧對(duì)圖片優(yōu)化
5、前端開發(fā)中，如何優(yōu)化圖像？圖像格式的區(qū)別？
優(yōu)化圖像：
1、不用圖片，盡量用css3代替。 比如說要實(shí)現(xiàn)修飾效果，如半透明、邊框、圓角、陰影、漸變等，在當(dāng)前主流瀏覽器中都可以用CSS達(dá)成。
2、 使用矢量圖SVG替代位圖。對(duì)于絕大多數(shù)圖案、圖標(biāo)等，矢量圖更小，且可縮放而無需生成多套圖。現(xiàn)在主流瀏覽器都支持SVG了，所以可放心使用！
3.、使用恰當(dāng)?shù)膱D片格式。我們常見的圖片格式有JPEG、GIF、PNG。
基本上，內(nèi)容圖片多為照片之類的，適用于JPEG。
而修飾圖片通常更適合用無損壓縮的PNG。
GIF基本上除了GIF動(dòng)畫外不要使用。且動(dòng)畫的話，也更建議用video元素和視頻格式，或用SVG動(dòng)畫取代。
4、按照HTTP協(xié)議設(shè)置合理的緩存。
5、使用字體圖標(biāo)webfont、CSS Sprites等。
6、用CSS或JavaScript實(shí)現(xiàn)預(yù)加載。
7、WebP圖片格式能給前端帶來的優(yōu)化。WebP支持無損、有損壓縮，動(dòng)態(tài)、靜態(tài)圖片，壓縮比率優(yōu)于GIF、JPEG、JPEG2000、PG等格式，非常適合用于網(wǎng)絡(luò)等圖片傳輸。
圖像格式的區(qū)別：
矢量圖：圖標(biāo)字體，如 font-awesome；svg
位圖：gif,jpg(jpeg),png
區(qū)別：
1、gif:是是一種無損，8位圖片格式。具有支持動(dòng)畫，索引透明，壓縮等特性。適用于做色彩簡(jiǎn)單(色調(diào)少)的圖片，如logo,各種小圖標(biāo)icons等。
2、JPEG格式是一種大小與質(zhì)量相平衡的壓縮圖片格式。適用于允許輕微失真的色彩豐富的照片，不適合做色彩簡(jiǎn)單(色調(diào)少)的圖片，如logo,各種小圖標(biāo)icons等。
3、png:PNG可以細(xì)分為三種格式:PNG8，PNG24，PNG32。后面的數(shù)字代表這種PNG格式最多可以索引和存儲(chǔ)的顏色值。
關(guān)于透明：PNG8支持索引透明和alpha透明;PNG24不支持透明;而PNG32在24位的PNG基礎(chǔ)上增加了8位（256階）的alpha通道透明;
優(yōu)缺點(diǎn)：
1、能在保證最不失真的情況下盡可能壓縮圖像文件的大小。
2、對(duì)于需要高保真的較復(fù)雜的圖像，PNG雖然能無損壓縮，但圖片文件較大，不適合應(yīng)用在Web頁面上。
20、瀏覽器是如何渲染頁面的？
渲染的流程如下：
1.解析HTML文件，創(chuàng)建DOM樹。
自上而下，遇到任何樣式（link、style）與腳本（script）都會(huì)阻塞（外部樣式不阻塞后續(xù)外部腳本的加載）。
2.解析CSS。優(yōu)先級(jí)：瀏覽器默認(rèn)設(shè)置<用戶設(shè)置<外部樣式<內(nèi)聯(lián)樣式<HTML中的style樣式；
3.將CSS與DOM合并，構(gòu)建渲染樹（Render Tree）
4.布局和繪制，重繪（repaint）和重排（reflow）
21、深入理解瀏覽器的緩存機(jī)制
一、前言
緩存可以說是性能優(yōu)化中簡(jiǎn)單高效的一種優(yōu)化方式了。一個(gè)優(yōu)秀的緩存策略可以縮短網(wǎng)頁請(qǐng)求資源的距離，減少延遲，并且由于緩存文件可以重復(fù)利用，還可以減少帶寬，降低網(wǎng)絡(luò)負(fù)荷。
對(duì)于一個(gè)數(shù)據(jù)請(qǐng)求來說，可以分為發(fā)起網(wǎng)絡(luò)請(qǐng)求、后端處理、瀏覽器響應(yīng)三個(gè)步驟。瀏覽器緩存可以幫助我們?cè)诘谝缓偷谌襟E中優(yōu)化性能。比如說直接使用緩存而不發(fā)起請(qǐng)求，或者發(fā)起了請(qǐng)求但后端存儲(chǔ)的數(shù)據(jù)和前端一致，那么就沒有必要再將數(shù)據(jù)回傳回來，這樣就減少了響應(yīng)數(shù)據(jù)。
接下來的內(nèi)容中我們將通過緩存位置、緩存策略以及實(shí)際場(chǎng)景應(yīng)用緩存策略來探討瀏覽器緩存機(jī)制。
二、緩存位置
從緩存位置上來說分為四種，并且各自有優(yōu)先級(jí)，當(dāng)依次查找緩存且都沒有命中的時(shí)候，才會(huì)去請(qǐng)求網(wǎng)絡(luò)。
? Service Worker
? Memory Cache
? Disk Cache
? Push Cache
1.Service Worker
Service Worker 是運(yùn)行在瀏覽器背后的獨(dú)立線程，一般可以用來實(shí)現(xiàn)緩存功能。使用 Service Worker的話，傳輸協(xié)議必須為 HTTPS。因?yàn)?Service Worker 中涉及到請(qǐng)求攔截，所以必須使用 HTTPS 協(xié)議來保障安全。Service Worker 的緩存與瀏覽器其他內(nèi)建的緩存機(jī)制不同，它可以讓我們自由控制緩存哪些文件、如何匹配緩存、如何讀取緩存，并且緩存是持續(xù)性的。
Service Worker 實(shí)現(xiàn)緩存功能一般分為三個(gè)步驟：首先需要先注冊(cè) Service Worker，然后監(jiān)聽到 install 事件以后就可以緩存需要的文件，那么在下次用戶訪問的時(shí)候就可以通過攔截請(qǐng)求的方式查詢是否存在緩存，存在緩存的話就可以直接讀取緩存文件，否則就去請(qǐng)求數(shù)據(jù)。
當(dāng) Service Worker 沒有命中緩存的時(shí)候，我們需要去調(diào)用 fetch 函數(shù)獲取數(shù)據(jù)。也就是說，如果我們沒有在 Service Worker 命中緩存的話，會(huì)根據(jù)緩存查找優(yōu)先級(jí)去查找數(shù)據(jù)。但是不管我們是從 Memory Cache 中還是從網(wǎng)絡(luò)請(qǐng)求中獲取的數(shù)據(jù)，瀏覽器都會(huì)顯示我們是從 Service Worker 中獲取的內(nèi)容。
2.Memory Cache
Memory Cache 也就是內(nèi)存中的緩存，主要包含的是當(dāng)前中頁面中已經(jīng)抓取到的資源,例如頁面上已經(jīng)下載的樣式、腳本、圖片等。讀取內(nèi)存中的數(shù)據(jù)肯定比磁盤快,內(nèi)存緩存雖然讀取高效，可是緩存持續(xù)性很短，會(huì)隨著進(jìn)程的釋放而釋放。 一旦我們關(guān)閉 Tab 頁面，內(nèi)存中的緩存也就被釋放了。
那么既然內(nèi)存緩存這么高效，我們是不是能讓數(shù)據(jù)都存放在內(nèi)存中呢？
這是不可能的。計(jì)算機(jī)中的內(nèi)存一定比硬盤容量小得多，操作系統(tǒng)需要精打細(xì)算內(nèi)存的使用，所以能讓我們使用的內(nèi)存必然不多。
當(dāng)我們?cè)L問過頁面以后，再次刷新頁面，可以發(fā)現(xiàn)很多數(shù)據(jù)都來自于內(nèi)存緩存
內(nèi)存緩存中有一塊重要的緩存資源是preloader相關(guān)指令（例如）下載的資源。總所周知preloader的相關(guān)指令已經(jīng)是頁面優(yōu)化的常見手段之一，它可以一邊解析js/css文件，一邊網(wǎng)絡(luò)請(qǐng)求下一個(gè)資源。
需要注意的事情是，內(nèi)存緩存在緩存資源時(shí)并不關(guān)心返回資源的HTTP緩存頭Cache-Control是什么值，同時(shí)資源的匹配也并非僅僅是對(duì)URL做匹配，還可能會(huì)對(duì)Content-Type，CORS等其他特征做校驗(yàn)。
3.Disk Cache
Disk Cache 也就是存儲(chǔ)在硬盤中的緩存，讀取速度慢點(diǎn)，但是什么都能存儲(chǔ)到磁盤中，比之 Memory Cache 勝在容量和存儲(chǔ)時(shí)效性上。
在所有瀏覽器緩存中，Disk Cache 覆蓋面基本是最大的。它會(huì)根據(jù) HTTP Herder 中的字段判斷哪些資源需要緩存，哪些資源可以不請(qǐng)求直接使用，哪些資源已經(jīng)過期需要重新請(qǐng)求。并且即使在跨站點(diǎn)的情況下，相同地址的資源一旦被硬盤緩存下來，就不會(huì)再次去請(qǐng)求數(shù)據(jù)。絕大部分的緩存都來自 Disk Cache，關(guān)于 HTTP 的協(xié)議頭中的緩存字段，我們會(huì)在下文進(jìn)行詳細(xì)介紹。
瀏覽器會(huì)把哪些文件丟進(jìn)內(nèi)存中？哪些丟進(jìn)硬盤中？
關(guān)于這點(diǎn)，網(wǎng)上說法不一，不過以下觀點(diǎn)比較靠得住：
? 對(duì)于大文件來說，大概率是不存儲(chǔ)在內(nèi)存中的，反之優(yōu)先
? 當(dāng)前系統(tǒng)內(nèi)存使用率高的話，文件優(yōu)先存儲(chǔ)進(jìn)硬盤
4.Push Cache
Push Cache（推送緩存）是 HTTP/2 中的內(nèi)容，當(dāng)以上三種緩存都沒有命中時(shí)，它才會(huì)被使用。它只在會(huì)話（Session）中存在，一旦會(huì)話結(jié)束就被釋放，并且緩存時(shí)間也很短暫，在Chrome瀏覽器中只有5分鐘左右，同時(shí)它也并非嚴(yán)格執(zhí)行HTTP頭中的緩存指令。
結(jié)論：
? 所有的資源都能被推送，并且能夠被緩存,但是 Edge 和 Safari 瀏覽器支持相對(duì)比較差
? 可以推送 no-cache 和 no-store 的資源
? 一旦連接被關(guān)閉，Push Cache 就被釋放
? 多個(gè)頁面可以使用同一個(gè)HTTP/2的連接，也就可以使用同一個(gè)Push Cache。這主要還是依賴瀏覽器的實(shí)現(xiàn)而定，出于對(duì)性能的考慮，有的瀏覽器會(huì)對(duì)相同域名但不同的tab標(biāo)簽使用同一個(gè)HTTP連接。
? Push Cache 中的緩存只能被使用一次
? 瀏覽器可以拒絕接受已經(jīng)存在的資源推送
? 你可以給其他域名推送資源
如果以上四種緩存都沒有命中的話，那么只能發(fā)起請(qǐng)求來獲取資源了。
那么為了性能上的考慮，大部分的接口都應(yīng)該選擇好緩存策略，通常瀏覽器緩存策略分為兩種：強(qiáng)緩存和協(xié)商緩存，并且緩存策略都是通過設(shè)置 HTTP Header 來實(shí)現(xiàn)的。
三、緩存過程分析
瀏覽器與服務(wù)器通信的方式為應(yīng)答模式，即是：瀏覽器發(fā)起HTTP請(qǐng)求 – 服務(wù)器響應(yīng)該請(qǐng)求，那么瀏覽器怎么確定一個(gè)資源該不該緩存，如何去緩存呢？瀏覽器第一次向服務(wù)器發(fā)起該請(qǐng)求后拿到請(qǐng)求結(jié)果后，將請(qǐng)求結(jié)果和緩存標(biāo)識(shí)存入瀏覽器緩存，瀏覽器對(duì)于緩存的處理是根據(jù)第一次請(qǐng)求資源時(shí)返回的響應(yīng)頭來確定的。
? 瀏覽器每次發(fā)起請(qǐng)求，都會(huì)先在瀏覽器緩存中查找該請(qǐng)求的結(jié)果以及緩存標(biāo)識(shí)
? 瀏覽器每次拿到返回的請(qǐng)求結(jié)果都會(huì)將該結(jié)果和緩存標(biāo)識(shí)存入瀏覽器緩存中
以上兩點(diǎn)結(jié)論就是瀏覽器緩存機(jī)制的關(guān)鍵，它確保了每個(gè)請(qǐng)求的緩存存入與讀取，只要我們?cè)倮斫鉃g覽器緩存的使用規(guī)則，那么所有的問題就迎刃而解了，本文也將圍繞著這點(diǎn)進(jìn)行詳細(xì)分析。為了方便大家理解，這里我們根據(jù)是否需要向服務(wù)器重新發(fā)起HTTP請(qǐng)求將緩存過程分為兩個(gè)部分，分別是強(qiáng)緩存和協(xié)商緩存。
四、強(qiáng)緩存
強(qiáng)緩存：不會(huì)向服務(wù)器發(fā)送請(qǐng)求，直接從緩存中讀取資源，在chrome控制臺(tái)的Network選項(xiàng)中可以看到該請(qǐng)求返回200的狀態(tài)碼，并且Size顯示from disk cache或from memory cache。強(qiáng)緩存可以通過設(shè)置兩種 HTTP Header 實(shí)現(xiàn)：Expires 和 Cache-Control。
1.Expires
緩存過期時(shí)間，用來指定資源到期的時(shí)間，是服務(wù)器端的具體的時(shí)間點(diǎn)。也就是說，Expires=max-age + 請(qǐng)求時(shí)間，需要和Last-modified結(jié)合使用。Expires是Web服務(wù)器響應(yīng)消息頭字段，在響應(yīng)http請(qǐng)求時(shí)告訴瀏覽器在過期時(shí)間前瀏覽器可以直接從瀏覽器緩存取數(shù)據(jù)，而無需再次請(qǐng)求。
Expires 是 HTTP/1 的產(chǎn)物，受限于本地時(shí)間，如果修改了本地時(shí)間，可能會(huì)造成緩存失效。Expires: Wed, 22 Oct 2018 08:41:00 GMT表示資源會(huì)在 Wed, 22 Oct 2018 08:41:00 GMT 后過期，需要再次請(qǐng)求。
2.Cache-Control
在HTTP/1.1中，Cache-Control是最重要的規(guī)則，主要用于控制網(wǎng)頁緩存。比如當(dāng)Cache-Control:max-age=300時(shí)，則代表在這個(gè)請(qǐng)求正確返回時(shí)間（瀏覽器也會(huì)記錄下來）的5分鐘內(nèi)再次加載資源，就會(huì)命中強(qiáng)緩存。
Cache-Control 可以在請(qǐng)求頭或者響應(yīng)頭中設(shè)置，并且可以組合使用多種指令：
public：所有內(nèi)容都將被緩存（客戶端和代理服務(wù)器都可緩存）。具體來說響應(yīng)可被任何中間節(jié)點(diǎn)緩存，如 Browser <-- proxy1 <-- proxy2 <-- Server，中間的proxy可以緩存資源，比如下次再請(qǐng)求同一資源proxy1直接把自己緩存的東西給 Browser 而不再向proxy2要。
private：所有內(nèi)容只有客戶端可以緩存，Cache-Control的默認(rèn)取值。具體來說，表示中間節(jié)點(diǎn)不允許緩存，對(duì)于Browser <-- proxy1 <-- proxy2 <-- Server，proxy 會(huì)老老實(shí)實(shí)把Server 返回的數(shù)據(jù)發(fā)送給proxy1,自己不緩存任何數(shù)據(jù)。當(dāng)下次Browser再次請(qǐng)求時(shí)proxy會(huì)做好請(qǐng)求轉(zhuǎn)發(fā)而不是自作主張給自己緩存的數(shù)據(jù)。
no-cache：客戶端緩存內(nèi)容，是否使用緩存則需要經(jīng)過協(xié)商緩存來驗(yàn)證決定。表示不使用 Cache-Control的緩存控制方式做前置驗(yàn)證，而是使用 Etag 或者Last-Modified字段來控制緩存。需要注意的是，no-cache這個(gè)名字有一點(diǎn)誤導(dǎo)。設(shè)置了no-cache之后，并不是說瀏覽器就不再緩存數(shù)據(jù)，只是瀏覽器在使用緩存數(shù)據(jù)時(shí)，需要先確認(rèn)一下數(shù)據(jù)是否還跟服務(wù)器保持一致。
no-store：所有內(nèi)容都不會(huì)被緩存，即不使用強(qiáng)制緩存，也不使用協(xié)商緩存
max-age：max-age=xxx (xxx is numeric)表示緩存內(nèi)容將在xxx秒后失效
s-maxage（單位為s)：同max-age作用一樣，只在代理服務(wù)器中生效（比如CDN緩存）。比如當(dāng)s-maxage=60時(shí)，在這60秒中，即使更新了CDN的內(nèi)容，瀏覽器也不會(huì)進(jìn)行請(qǐng)求。max-age用于普通緩存，而s-maxage用于代理緩存。s-maxage的優(yōu)先級(jí)高于max-age。如果存在s-maxage，則會(huì)覆蓋掉max-age和Expires header。
max-stale：能容忍的最大過期時(shí)間。max-stale指令標(biāo)示了客戶端愿意接收一個(gè)已經(jīng)過期了的響應(yīng)。如果指定了max-stale的值，則最大容忍時(shí)間為對(duì)應(yīng)的秒數(shù)。如果沒有指定，那么說明瀏覽器愿意接收任何age的響應(yīng)（age表示響應(yīng)由源站生成或確認(rèn)的時(shí)間與當(dāng)前時(shí)間的差值）。
min-fresh：能夠容忍的最小新鮮度。min-fresh標(biāo)示了客戶端不愿意接受新鮮度不多于當(dāng)前的age加上min-fresh設(shè)定的時(shí)間之和的響應(yīng)。
從圖中我們可以看到，我們可以將多個(gè)指令配合起來一起使用，達(dá)到多個(gè)目的。比如說我們希望資源能被緩存下來，并且是客戶端和代理服務(wù)器都能緩存，還能設(shè)置緩存失效時(shí)間等等。
3.Expires和Cache-Control兩者對(duì)比
其實(shí)這兩者差別不大，區(qū)別就在于 Expires 是http1.0的產(chǎn)物，Cache-Control是http1.1的產(chǎn)物，兩者同時(shí)存在的話，Cache-Control優(yōu)先級(jí)高于Expires；在某些不支持HTTP1.1的環(huán)境下，Expires就會(huì)發(fā)揮用處。所以Expires其實(shí)是過時(shí)的產(chǎn)物，現(xiàn)階段它的存在只是一種兼容性的寫法。
強(qiáng)緩存判斷是否緩存的依據(jù)來自于是否超出某個(gè)時(shí)間或者某個(gè)時(shí)間段，而不關(guān)心服務(wù)器端文件是否已經(jīng)更新，這可能會(huì)導(dǎo)致加載文件不是服務(wù)器端最新的內(nèi)容，那我們?nèi)绾潍@知服務(wù)器端內(nèi)容是否已經(jīng)發(fā)生了更新呢？此時(shí)我們需要用到協(xié)商緩存策略。
五、協(xié)商緩存
協(xié)商緩存就是強(qiáng)制緩存失效后，瀏覽器攜帶緩存標(biāo)識(shí)向服務(wù)器發(fā)起請(qǐng)求，由服務(wù)器根據(jù)緩存標(biāo)識(shí)決定是否使用緩存的過程，主要有以下兩種情況：
? 協(xié)商緩存生效，返回304和Not Modified
? 協(xié)商緩存失效，返回200和請(qǐng)求結(jié)果
協(xié)商緩存可以通過設(shè)置兩種 HTTP Header 實(shí)現(xiàn)：Last-Modified 和 ETag 。
1.Last-Modified和If-Modified-Since
瀏覽器在第一次訪問資源時(shí)，服務(wù)器返回資源的同時(shí)，在response header中添加 Last-Modified的header，值是這個(gè)資源在服務(wù)器上的最后修改時(shí)間，瀏覽器接收后緩存文件和header；
Last-Modified: Fri, 22 Jul 2016 01:47:00 GMT
瀏覽器下一次請(qǐng)求這個(gè)資源，瀏覽器檢測(cè)到有 Last-Modified這個(gè)header，于是添加If-Modified-Since這個(gè)header，值就是Last-Modified中的值；服務(wù)器再次收到這個(gè)資源請(qǐng)求，會(huì)根據(jù) If-Modified-Since 中的值與服務(wù)器中這個(gè)資源的最后修改時(shí)間對(duì)比，如果沒有變化，返回304和空的響應(yīng)體，直接從緩存讀取，如果If-Modified-Since的時(shí)間小于服務(wù)器中這個(gè)資源的最后修改時(shí)間，說明文件有更新，于是返回新的資源文件和200
但是 Last-Modified 存在一些弊端：
? 如果本地打開緩存文件，即使沒有對(duì)文件進(jìn)行修改，但還是會(huì)造成 Last-Modified 被修改，服務(wù)端不能命中緩存導(dǎo)致發(fā)送相同的資源
? 因?yàn)?Last-Modified 只能以秒計(jì)時(shí)，如果在不可感知的時(shí)間內(nèi)修改完成文件，那么服務(wù)端會(huì)認(rèn)為資源還是命中了，不會(huì)返回正確的資源
既然根據(jù)文件修改時(shí)間來決定是否緩存尚有不足，能否可以直接根據(jù)文件內(nèi)容是否修改來決定緩存策略？所以在 HTTP / 1.1 出現(xiàn)了 ETag 和If-None-Match
2.ETag和If-None-Match
Etag是服務(wù)器響應(yīng)請(qǐng)求時(shí)，返回當(dāng)前資源文件的一個(gè)唯一標(biāo)識(shí)(由服務(wù)器生成)，只要資源有變化，Etag就會(huì)重新生成。瀏覽器在下一次加載資源向服務(wù)器發(fā)送請(qǐng)求時(shí)，會(huì)將上一次返回的Etag值放到request header里的If-None-Match里，服務(wù)器只需要比較客戶端傳來的If-None-Match跟自己服務(wù)器上該資源的ETag是否一致，就能很好地判斷資源相對(duì)客戶端而言是否被修改過了。如果服務(wù)器發(fā)現(xiàn)ETag匹配不上，那么直接以常規(guī)GET 200回包形式將新的資源（當(dāng)然也包括了新的ETag）發(fā)給客戶端；如果ETag是一致的，則直接返回304知會(huì)客戶端直接使用本地緩存即可。
3.兩者之間對(duì)比：
? 首先在精確度上，Etag要優(yōu)于Last-Modified。
Last-Modified的時(shí)間單位是秒，如果某個(gè)文件在1秒內(nèi)改變了多次，那么他們的Last-Modified其實(shí)并沒有體現(xiàn)出來修改，但是Etag每次都會(huì)改變確保了精度；如果是負(fù)載均衡的服務(wù)器，各個(gè)服務(wù)器生成的Last-Modified也有可能不一致。
? 第二在性能上，Etag要遜于Last-Modified，畢竟Last-Modified只需要記錄時(shí)間，而Etag需要服務(wù)器通過算法來計(jì)算出一個(gè)hash值。
? 第三在優(yōu)先級(jí)上，服務(wù)器校驗(yàn)優(yōu)先考慮Etag
六、緩存機(jī)制
強(qiáng)制緩存優(yōu)先于協(xié)商緩存進(jìn)行，若強(qiáng)制緩存(Expires和Cache-Control)生效則直接使用緩存，若不生效則進(jìn)行協(xié)商緩存(Last-Modified / If-Modified-Since和Etag / If-None-Match)，協(xié)商緩存由服務(wù)器決定是否使用緩存，若協(xié)商緩存失效，那么代表該請(qǐng)求的緩存失效，返回200，重新返回資源和緩存標(biāo)識(shí)，再存入瀏覽器緩存中；生效則返回304，繼續(xù)使用緩存。
看到這里，不知道你是否存在這樣一個(gè)疑問:如果什么緩存策略都沒設(shè)置，那么瀏覽器會(huì)怎么處理？
對(duì)于這種情況，瀏覽器會(huì)采用一個(gè)啟發(fā)式的算法，通常會(huì)取響應(yīng)頭中的 Date 減去 Last-Modified 值的 10% 作為緩存時(shí)間。
七、實(shí)際場(chǎng)景應(yīng)用緩存策略
1.頻繁變動(dòng)的資源
Cache-Control: no-cache
對(duì)于頻繁變動(dòng)的資源，首先需要使用Cache-Control: no-cache 使瀏覽器每次都請(qǐng)求服務(wù)器，然后配合 ETag 或者 Last-Modified 來驗(yàn)證資源是否有效。這樣的做法雖然不能節(jié)省請(qǐng)求數(shù)量，但是能顯著減少響應(yīng)數(shù)據(jù)大小。
2.不常變化的資源
Cache-Control: max-age=31536000
通常在處理這類資源時(shí)，給它們的 Cache-Control 配置一個(gè)很大的 max-age=31536000 (一年)，這樣瀏覽器之后請(qǐng)求相同的 URL 會(huì)命中強(qiáng)制緩存。而為了解決更新的問題，就需要在文件名(或者路徑)中添加 hash， 版本號(hào)等動(dòng)態(tài)字符，之后更改動(dòng)態(tài)字符，從而達(dá)到更改引用 URL 的目的，讓之前的強(qiáng)制緩存失效 (其實(shí)并未立即失效，只是不再使用了而已)。
在線提供的類庫(kù) (如 jquery-3.3.1.min.js, lodash.min.js 等) 均采用這個(gè)模式。
八、用戶行為對(duì)瀏覽器緩存的影響
所謂用戶行為對(duì)瀏覽器緩存的影響，指的就是用戶在瀏覽器如何操作時(shí)，會(huì)觸發(fā)怎樣的緩存策略。主要有 3 種：
? 打開網(wǎng)頁，地址欄輸入地址： 查找 disk cache 中是否有匹配。如有則使用；如沒有則發(fā)送網(wǎng)絡(luò)請(qǐng)求。
? 普通刷新 (F5)：因?yàn)?TAB 并沒有關(guān)閉，因此 memory cache 是可用的，會(huì)被優(yōu)先使用(如果匹配的話)。其次才是 disk cache。
? 強(qiáng)制刷新 (Ctrl + F5)：瀏覽器不使用緩存，因此發(fā)送的請(qǐng)求頭部均帶有 Cache-control: no-cache(為了兼容，還帶了 Pragma: no-cache),服務(wù)器直接返回 200 和最新內(nèi)容。
關(guān)于Cookies和有/無狀態(tài)的關(guān)系，如果把有狀態(tài)、無狀態(tài)理解成相同的請(qǐng)求是否返回相同的結(jié)果，那么要讓某個(gè)HTTP服務(wù)器有狀態(tài)，真的需要Cookies嗎？不需要對(duì)不對(duì)？只需要大家都共享一個(gè)全局狀態(tài)就行了，比如說首頁上有一個(gè)訪問計(jì)數(shù)器“您是第XXXX個(gè)訪問本頁的用戶”，每訪問一次這個(gè)計(jì)數(shù)器就加1，誰訪問都加1，這從剛才的理解來說也是“有狀態(tài)”，對(duì)不對(duì)？Cookies/Session的作用是創(chuàng)建和維護(hù)多組獨(dú)立的狀態(tài)，而不是有狀態(tài)。這個(gè)狀態(tài)指的是后端服務(wù)的狀態(tài)，而非HTTP協(xié)議本身的狀態(tài)。所以說，HTTP協(xié)議是無狀態(tài)的協(xié)議，這個(gè)其實(shí)跟服務(wù)的狀態(tài)是無關(guān)的。一個(gè)服務(wù)不管使用何種協(xié)議，都可以在服務(wù)層面上是有狀態(tài)的，因?yàn)檫@和通信協(xié)議無關(guān)，只需要它在響應(yīng)請(qǐng)求時(shí)改變自己的狀態(tài)即可，例如有一個(gè)Shutdown命令可以直接關(guān)掉整個(gè)服務(wù)器不再接受響應(yīng)，那么它無論如何都是有狀態(tài)的對(duì)吧。所以說，服務(wù)本身有沒有狀態(tài)、支不支持會(huì)話，其實(shí)跟HTTP協(xié)議是否有狀態(tài)是無關(guān)的。
1.cookie設(shè)置
那 Cookie 是怎么設(shè)置的呢？簡(jiǎn)單來說就是
Cookie 的作用
Cookie 主要用于以下三個(gè)方面：
Cookie 的缺點(diǎn)
1、隱私問題
大多數(shù)用戶主要關(guān)心的是隱私。啟用Cookie的Web瀏覽器會(huì)跟蹤您訪問過的所有網(wǎng)站。這意味著，經(jīng)許可（或不在Google的情況下），第三方可以訪問這些cookie存儲(chǔ)的信息。在某些情況下，這些第三方可以是廣告商，其他用戶。。。。
2、不安全
Cookie安全性是一個(gè)大問題，因?yàn)樗鼈兪且悦魑男问酱鎯?chǔ)，可能會(huì)造成安全風(fēng)險(xiǎn)，因?yàn)槿魏稳硕伎梢源蜷_并篡改cookie。
Cookie容易在客戶端被發(fā)現(xiàn)意味著它們很容易被黑客入侵和修改。
3、難以解密
我們可以手動(dòng)加密和解密cookie，但由于加密和解密所需的時(shí)間，它需要額外的編碼并影響應(yīng)用程序性能。
4、大小有限制，只能儲(chǔ)存簡(jiǎn)單字符串信息
cookie文本的大小（一般為4kb），cookie的數(shù)量（一般每個(gè)站點(diǎn)20個(gè)）存在一些限制，每個(gè)站點(diǎn)只能容納20個(gè)cookie。
Cookie僅限于簡(jiǎn)單的字符串信息，他們無法存儲(chǔ)復(fù)雜的信息。
5、可以被禁用
用戶可以選擇從瀏覽器設(shè)置中禁用其計(jì)算機(jī)上的cookie。這意味著用戶可以決定不在他的瀏覽器上使用cookie，這可能會(huì)在瀏覽器的運(yùn)行中產(chǎn)生一些問題。
6、可以被刪除
用戶可以從其計(jì)算機(jī)中刪除cookie，這使他們可以更好地控制cookie。
總結(jié)
以上是生活随笔為你收集整理的前端知识总结之浏览器知识的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 遥感图像预处理
- 下一篇： 浏览器内核以及渲染过程