封面

前言

自從入職新公司到現(xiàn)在僧凰，我們前端團隊內(nèi)部一直在做 ??每周一練 的知識復習計劃，我之前整理了一個 每周一練 之 數(shù)據(jù)結(jié)構(gòu)與算法 學習內(nèi)容熟丸，大家也快去看看~~

最近三周训措，主要復習 網(wǎng)絡基礎 相關(guān)的知識，今天我把這三周復習的知識和參考答案，整理成本文绩鸣，歡迎各位朋友互相學習和指點怀大，覺得本文不錯，也歡迎點贊哈????呀闻。

特別喜歡現(xiàn)在的每周學習和分享化借，哈哈哈~~??

??推薦一個 github 倉庫 —— 《awesome-http》，內(nèi)容挺棒的捡多。

注：本文整理資料來源網(wǎng)絡蓖康，有些圖片/段落找不到原文出處，如有侵權(quán)垒手，聯(lián)系刪除蒜焊。

一. 簡述瀏覽器輸入 URL 地址后發(fā)生的事情

1.1 描述

1. 瀏覽器向 DNS 服務器查找輸入 URL 對應的 IP 地址。
2. NS 服務器返回網(wǎng)站的 IP 地址科贬。
3. 瀏覽器根據(jù) IP 地址與目標 web 服務器在 80 端口上建立 TCP 連接泳梆。
4. 瀏覽器獲取請求頁面的 HTML 代碼。
5. 瀏覽器在顯示窗口內(nèi)渲染 HTML 榜掌。
6. 窗口關(guān)閉時优妙，瀏覽器終止與服務器的連接。

1.2 TCP 知識點補充

參考文章：《TCP三次握手和四次揮手協(xié)議》

建立 TCP 需要三次握手才能建立憎账，而斷開連接則需要四次握手鳞溉。整個過程如下圖所示：

http3

TCP三次握手：

所謂的三次握手，是指建立一個 TCP 連接時鼠哥，需要客戶端和服務器端總共發(fā)送三個包熟菲，三次握手的目的是連接服務器的指定端口，建立 TCP 連接朴恳，并同步連接雙方的序列號和確認號并交換 TCP 窗口大小信息抄罕，在 SOCKET 編程中，客戶端執(zhí)行 connect() 時于颖，將會觸發(fā)三次握手：

http1

TCP四次揮手：

TCP連接的拆除需要發(fā)送四個包呆贿，客戶端或者服務器端均可主動發(fā)起揮手動作，在SOCKET編程中森渐，任何一方執(zhí)行close()即可產(chǎn)生揮手操作做入。

http2

2. 請介紹常見的 HTTP 狀態(tài)碼(至少五個)

狀態(tài)碼是由 3 位數(shù)組成，第一個數(shù)字定義了響應的類別同衣，且有五種可能取值:

1xx：指示信息–表示請求已接收竟块，繼續(xù)處理。

• 100 客戶必須繼續(xù)發(fā)出請求

• 101 客戶要求服務器根據(jù)請求轉(zhuǎn)換HTTP協(xié)議版本

2xx：成功–表示請求已被成功接收耐齐、理解浪秘、接受蒋情。

• 200 （成功） 服務器已成功處理了請求。 通常耸携，這表示服務器提供了請求的網(wǎng)頁棵癣。

• 201 （已創(chuàng)建） 請求成功并且服務器創(chuàng)建了新的資源。

• 202 （已接受） 服務器已接受請求夺衍，但尚未處理狈谊。

3xx：重定向–要完成請求必須進行更進一步的操作。

• 300 （多種選擇） 針對請求沟沙，服務器可執(zhí)行多種操作河劝。 服務器可根據(jù)請求者 (user agent) 選擇一項操作，或提供操作列表供請求者選擇尝胆。

• 301 （永久移動） 請求的網(wǎng)頁已永久移動到新位置丧裁。 服務器返回此響應（對 GET 或 HEAD 請求的響應）時护桦，會自動將請求者轉(zhuǎn)到新位置含衔。

• 302 （臨時移動） 服務器目前從不同位置的網(wǎng)頁響應請求，但請求者應繼續(xù)使用原有位置來進行以后的請求二庵。

4xx：客戶端錯誤–請求有語法錯誤或請求無法實現(xiàn)贪染。

• 400 （錯誤請求） 服務器不理解請求的語法。

• 401 （未授權(quán)） 請求要求身份驗證催享。 對于需要登錄的網(wǎng)頁杭隙，服務器可能返回此響應。

• 403 （禁止） 服務器拒絕請求因妙。

5xx：服務器端錯誤–服務器未能實現(xiàn)合法的請求痰憎。

• 500 （服務器內(nèi)部錯誤） 服務器遇到錯誤，無法完成請求攀涵。

• 501 （尚未實施） 服務器不具備完成請求的功能铣耘。 例如，服務器無法識別請求方法時可能會返回此代碼以故。

• 502 （錯誤網(wǎng)關(guān)） 服務器作為網(wǎng)關(guān)或代理蜗细，從上游服務器收到無效響應。

• 503 （服務不可用） 服務器目前無法使用（由于超載或停機維護）怒详。 通常炉媒，這只是暫時狀態(tài)。

• 504 （網(wǎng)關(guān)超時） 服務器作為網(wǎng)關(guān)或代理昆烁，但是沒有及時從上游服務器收到請求吊骤。

• 505 （HTTP 版本不受支持） 服務器不支持請求中所用的 HTTP 協(xié)議版本。

3. 請介紹常見的 HTTP 頭部(至少五個)

3.1 HTTP 頭部

更多完整內(nèi)容静尼，可以查看 《HTTP響應頭和請求頭信息對照表》

3.2 Request Header

參考文章：《HTTP常用頭部信息》

舉例：

3.3 Response Header

參考文章：《HTTP常用頭部信息》

舉例：

4. 請列舉常用的 HTTP 方法，并介紹 GET 與 POST 請求之間的區(qū)別

4.1 HTTP Request Method

參考文章：《HTTP請求方法對照表》

根據(jù) HTTP 標準走孽，HTTP 請求可以使用多種請求方法惧辈。
HTTP1.0 定義了三種請求方法： GET, POST 和 HEAD方法。
HTTP/1.1 新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法磕瓷。

4.2 GET 與 POST 請求之間的區(qū)別

5. 請分別介紹 Cookie 和 Session 的作用及它們之間的區(qū)別

參考文章： 《3分鐘搞懂Cookie與Session》

5.1 Cookie簡單介紹

Cookie是存儲在用戶本地計算機上抖仅，用于保存一些用戶操作的歷史信息坊夫，當用戶再次訪問我們的服務器的時候砖第，瀏覽器通過HTTP協(xié)議，將他們本地的Cookie內(nèi)容也發(fā)到咱們服務器上环凿，從而完成驗證梧兼。

http4

• Cookie 是存儲在瀏覽器客戶的一小片數(shù)據(jù)；
• Cookie 可以同時被前臺與后臺操作智听；
• Cookie 可以跨頁面存雀ぴ骸；
• Cookie 是不可以跨服務器訪問的瞭稼；
• Cookie 有限制忽洛； 每個瀏覽器存儲的個數(shù)不能超過300個，每個服務器不能超過20個环肘，數(shù)據(jù)量不能超過4K欲虚；
• Cookie 是有生命周期的，默認與瀏覽器相同悔雹，如果進程退出复哆，cookie會被銷毀

5.2 Session

Session 存儲在我們的服務器上，就是在我們的服務器上保存用戶的操作信息腌零。

當用戶訪問我們的網(wǎng)站時梯找，我們的服務器會成一個 Session ID，然后把 Session ID 存儲起來益涧，再把這個 Session ID發(fā)給我們的用戶锈锤，用戶再次訪問我們的服務器的時候，拿著這個 Session ID就能驗證了闲询，當這個ID能與我們服務器上存儲的ID對應起來時久免，我們就可以認為是自己人。

http5

• seesion 數(shù)據(jù)存儲在服務器端扭弧；
• 每一個會話分配一個單獨的 session_id;
• 該 session_id 通過 cookie 傳送到前臺阎姥，默認的 session_id 名稱是PHPSESSIONID;
• 前臺只能看到 Session 的 ID，而不能修改 Session 值;
• 使用 Session之前需要先開啟會話;
• Session存儲在 Session數(shù)組 $_SESSION;
• Session存儲方式比較安全鸽捻，但是如果 Session數(shù)量過多呼巴，會導致服務器性能下降;

5.3 兩者區(qū)別

5.4 兩者結(jié)合使用

• 存儲在服務端：通過 cookie存儲一個 session_id屑埋，然后具體的數(shù)據(jù)則是保存在 session中。如果用戶已經(jīng)登錄，則服務器會在 cookie中保存一個 session_id油宜，下次再次請求的時候，會把該 session_id攜帶上來鼻百，服務器根據(jù) session_id在 session庫中獲取用戶的 session數(shù)據(jù)团搞。就能知道該用戶到底是誰严望，以及之前保存的一些狀態(tài)信息。這種專業(yè)術(shù)語叫做 server side session逻恐。

• 將 session數(shù)據(jù)加密像吻，然后存儲在 cookie中。這種專業(yè)術(shù)語叫做 client side session复隆。

6. 請介紹 HTTP 請求報文與響應報文格式

6.1 請求報文

http6

請求報文由請求行拨匆、請求頭部和請求正文組成：

• 請求行

格式為：

請求方法 + 空格 + URL + 空格 + 協(xié)議版本 + 回車符 + 換行符

例如：

GET www.baidu.com HTTP/1.1  

常見的請求方法有：GET，HEAD挽拂，PUT惭每，POST，TRACE亏栈，OPTIONS台腥，DELETE以及擴展方法。

• 請求頭部

格式為：

頭部字段名 + 冒號（:） + 值 + 回車符 + 換行符

請求頭部為請求報文添加了一些附加信息绒北，由“名/值”對組成黎侈，每行一對，名和值之間使用冒號分隔闷游。

并且峻汉，在請求頭部的最后會有一個空行，表示請求頭部結(jié)束储藐，這一行必不可少俱济。

典型的請求頭部有：

• 請求正文

一般使用在 POST 方法中聂喇， GET 方法不存在請求正文辖源。
POST 方法適用于需要客戶填寫表單的場合。與請求數(shù)據(jù)相關(guān)的最常使用的請求頭是 Content-Type 和 Content-Length 希太。

6.2 響應報文

http7

響應報文由狀態(tài)行克饶、響應頭部和響應正文組成：

• 狀態(tài)行

格式為：

協(xié)議版本 + 空格 + 狀態(tài)碼 + 空格 + 狀態(tài)碼描述 + 回車符 + 換行符

狀態(tài)碼劃分：

100?199的狀態(tài)碼是 HTTP / 1.1 向協(xié)議中引入了信息性狀態(tài)碼；
200?299的狀態(tài)碼表示成功誊辉；
300?399的狀態(tài)碼指資源重定向矾湃；
400?499的狀態(tài)碼指客戶端請求出錯；
500?599的狀態(tài)碼指服務端出錯堕澄；

常見的狀態(tài)碼：

• 響應頭部

格式為：

頭部字段名 + 冒號（:） + 值 + 回車符 + 換行符

常見響應頭部：

7. HTTP/1.1 有什么優(yōu)缺點

參考文章：《HTTP/1.0 HTTP/1.1 HTTP/2.0 主要特性對比》

對于 HTTP/1.1途戒，不僅繼承了 HTTP1.0簡單的特點，還克服了諸多 HTTP1.0性能上的問題僵驰。

7.1 HTTP/1.1 優(yōu)點

1. 增加持久性連接

也就是多個請求和響應可以利用同一個 TCP 連接喷斋，而不是每一次請求響應都要新建一個TCP連接，減少了建立和關(guān)閉連接的消耗和延遲蒜茴。

Connection: keep-alive

2. 增加管道機制

增加了管道機制星爪，請求可以同時發(fā)出，但是響應必須按照請求發(fā)出的順序依次返回粉私，性能在一定程度上得到了改善移必。

管道

3. 分塊傳輸

在 HTTP/1.1 版本中，可以不必等待數(shù)據(jù)完全處理完畢再返回毡鉴，服務器產(chǎn)生部分數(shù)據(jù)崔泵，那么就發(fā)送部分數(shù)據(jù)，很明此種方式更加優(yōu)秀一些猪瞬，可以節(jié)省很多等待時間憎瘸。

4. 增加 host 字段

使得一個服務器能夠用來創(chuàng)建多個 Web 站點。

5. 錯誤提示

HTTP/1.1 引入了一個 Warning 頭域陈瘦，增加對錯誤或警告信息的描述幌甘，此外，在 HTTP/1.1 中新增了24個狀態(tài)響應碼(100痊项，101锅风，203，205鞍泉，206皱埠，301，305… )咖驮。

6. 帶寬優(yōu)化

HTTP/1.1 中在請求消息中引入了 range頭域边器，它允許只請求資源的某個部分。

在響應消息中 Content-Range頭域聲明了返回的這部分對象的偏移值和長度托修。如果服務器相應地返回了對象所請求范圍的內(nèi)容忘巧，則響應碼為 206（Partial Content），它可以防止 Cache將響應誤以為是完整的一個對象睦刃，HTTP/1.1 加入了一個新的狀態(tài)碼 100（Continue）砚嘴。客戶端事先發(fā)送一個只帶頭域的請求，如果服務器因為權(quán)限拒絕了請求际长，就回送響應碼 401（Unauthorized）婆誓；如果服務器接收此請求就回送響應碼 100，客戶端就可以繼續(xù)發(fā)送帶實體的完整請求了也颤。

注意洋幻，HTTP/1.0 的客戶端不支持 100 響應碼。但可以讓客戶端在請求消息中加入 Expect頭域翅娶，并將它的值設置為 100-continue文留。

7.2 HTTP/1.1 缺點

1. 隊頭阻塞

此版本的網(wǎng)絡延遲問題主要由于隊頭堵塞導致，雖然通過持久性連接得到改善竭沫，但是每一個請求的響應依然需要按照順序排隊燥翅，如果前面的響應處理較為耗費時間，那么同樣非常耗費性能蜕提。

2. 技術(shù)不成熟

還有此版本雖然引進了管道機制森书，但是當前存在諸多問題，且默認處于關(guān)閉狀態(tài)谎势。

3. 浪費資源

http/1.1 請求會攜帶大量冗余的頭信息凛膏，浪費了很多寬帶資源。

8. 相比 HTTP/1.1脏榆，HTTP/2.0 有哪些新特性

參考文章：《HTTP1.0 HTTP/1.1 HTTP2.0 主要特性對比》

• 二進制分幀

在應用層（HTTP/2.0）和傳輸層（TCP or UDP）之間增加一個二進制分幀層猖毫，從而突破 HTTP1.1 的性能限制，改進傳輸性能须喂，實現(xiàn)低延遲和高吞吐量吁断。

http12

可見，雖然 HTTP/2.0 的協(xié)議和 HTTP1.x 協(xié)議之間的規(guī)范完全不同了坞生，但是實際上 HTTP/2.0并 沒有改變 HTTP1.x 的語義仔役。

簡單來說，HTTP/2.0 只是把原來 HTTP1.x 的 header 和 body 部分用 frame 重新封裝了一層而已是己。

• 多路復用（連接共享）

允許同時通過單一的 HTTP/2 連接發(fā)起多重的請求-響應消息又兵，這個強大的功能則是基于“二進制分幀”的特性。

http11

從圖中可見赃泡，所有的 HTTP/2.0 通信都在一個 TCP 連接上完成寒波，這個連接可以承載任意數(shù)量的雙向數(shù)據(jù)流。

每個數(shù)據(jù)流以消息的形式發(fā)送升熊，而消息由一或多個幀組成。這些幀可以亂序發(fā)送绸栅，然后再根據(jù)每個幀頭部的流標識符（stream id）重新組裝级野。

• 首部壓縮

HTTP1.1 不支持 header 數(shù)據(jù)的壓縮，HTTP/2.0 使用 HPACK 算法對 header 的數(shù)據(jù)進行壓縮，這樣數(shù)據(jù)體積小了蓖柔，在網(wǎng)絡上傳輸就會更快辰企。高效的壓縮算法可以很大的壓縮 header ，減少發(fā)送包的數(shù)量從而降低延遲况鸣。

• 服務器推送

在 HTTP/2 中牢贸，服務器可以對客戶端的一個請求發(fā)送多個響應，即服務器可以額外的向客戶端推送資源镐捧，而無需客戶端明確的請求潜索。

9. 請簡述 HTTPS 工作原理

9.1 HTTPS 簡介

參考文章：《深入淺出講解HTTPS工作原理》

HTTPS 并非是應用層的一種新協(xié)議。只是 HTTP 通信接口部分用 SSL(Secure Socket Layer)和 TLS(Transport Layer Security)協(xié)議代替而已懂酱。

通常竹习，HTTP 直接和 TCP 通信。當使用 SSL 時列牺，則演變成先和 SSL 通信整陌，再由 SSL 和 TCP 通信了。簡言之瞎领，所謂 HTTPS泌辫，其實就是身披 SSL 協(xié)議這層外殼的 HTTP。

http13

在采用 SSL 后九默，HTTP 就擁有了 HTTPS 的加密甥郑、證書和完整性保護這些功能。也就是說HTTP 加上加密處理和認證以及完整性保護后即是 HTTPS荤西。

http14

HTTPS 協(xié)議的主要功能基本都依賴于 TLS/SSL 協(xié)議澜搅，TLS/SSL 的功能實現(xiàn)主要依賴于三類基本算法：散列函數(shù) 、對稱加密和非對稱加密邪锌，其利用非對稱加密實現(xiàn)身份認證和密鑰協(xié)商勉躺，對稱加密算法采用協(xié)商的密鑰對數(shù)據(jù)加密，基于散列函數(shù)驗證信息的完整性觅丰。

http15

9.2 HTTPS 工作原理

HTTPS 其實是有兩部分組成：HTTP + SSL / TLS饵溅，也就是在 HTTP 上又加了一層處理加密信息的模塊。服務端和客戶端的信息傳輸都會通過 TLS 進行加密妇萄，所以傳輸?shù)臄?shù)據(jù)都是加密后的數(shù)據(jù)蜕企。

http16

1. 客戶端發(fā)起HTTPS請求

瀏覽器里面輸入一個HTTPS網(wǎng)址，然后連接到服務端的443端口上冠句。注意這個過程中客戶端會發(fā)送一個密文族給服務端轻掩，密文族是瀏覽器所支持的加密算法的清單。

2. 服務端配置

采用HTTPS協(xié)議的服務器必須要有一套數(shù)字證書懦底，可以自己制作唇牧，也可以向組織申請。區(qū)別就是自己頒發(fā)的證書需要客戶端驗證通過才可以繼續(xù)訪問，而使用受信任的公司申請的證書則不會彈出提示頁面丐重。

這套證書其實就是一對公鑰和私鑰腔召，可以這么理解，公鑰就是一把鎖頭扮惦，私鑰就是這把鎖的鑰匙臀蛛，鎖頭可以給別人對某個東西進行加鎖，但是加鎖完畢之后崖蜜，只有持有這把鎖的鑰匙才可以解鎖看到加鎖的內(nèi)容浊仆。

3. 傳送證書

這個證書其實就是公鑰，只是包含了很多信息纳猪，如證書的頒發(fā)機構(gòu)氧卧、過期時間等等。

4. 客戶端解析證書

這部分工作是由客戶端的TLS來完成的氏堤，首先會驗證公鑰是否有效沙绝，如頒發(fā)機構(gòu)、過期時間等等鼠锈，如果發(fā)現(xiàn)異常則會彈出一個警告框闪檬，提示證書存在問題。如果證書沒有問題购笆，那么就生成一個隨機值粗悯，然后用證書對該隨機值進行加密。

注意一下上面提到的"發(fā)現(xiàn)異常"同欠。證書中會包含數(shù)字簽名样傍，該數(shù)字簽名是加密過的，是用頒發(fā)機構(gòu)的私鑰對本證書的公鑰铺遂、名稱及其他信息做hash散列加密而生成的衫哥。客戶端瀏覽器會首先找到該證書的根證書頒發(fā)機構(gòu)襟锐，如果有撤逢，則用該根證書的公鑰解密服務器下發(fā)的證書，如果不能正常解密粮坞，則就是"發(fā)現(xiàn)異常"蚊荣，說明該證書是偽造的。

5. 傳送加密信息

這部分傳送的是用證書加密后的隨機值莫杈，目的就是讓服務端得到這個隨機值互例，然后客戶端和服務端的通信就可以通過這個隨機值來進行加密和解密了。

6. 服務端解密信息

服務端用私鑰解密后姓迅，得到了客戶端傳過來的隨機值敲霍，至此一個非對稱加密的過程結(jié)束俊马，看到TLS利用非對稱加密實現(xiàn)了身份認證和密鑰協(xié)商丁存。然后把內(nèi)容通過該值進行對稱加密肩杈。

7. 傳輸加密后的信息

這部分是服務端用隨機值加密后的信息，可以在客戶端被還原解寝。

8. 客戶端解密信息

客戶端用之前生成的隨機值解密服務端傳送過來的信息扩然，于是獲取了解密后的內(nèi)容，至此一個對稱加密的過程結(jié)束聋伦，看到對稱加密是用于對服務器待傳送給客戶端的數(shù)據(jù)進行加密用的夫偶。整個過程即使第三方監(jiān)聽了數(shù)據(jù)，也束手無策觉增。

10. HTTP 和 HTTPS 的共同點和區(qū)別

1. https 協(xié)議需要到 ca 申請證書兵拢，一般免費證書較少，因而需要一定費用逾礁。

2. http 是超文本傳輸協(xié)議说铃，信息是明文傳輸， https 則是具有安全性的ssl加密傳輸協(xié)議嘹履。

3. http 和 https 使用的是完全不同的連接方式腻扇，用的端口也不一樣，前者是80砾嫉，后者是443幼苛。

4. http 的連接很簡單，是無狀態(tài)的焕刮； HTTPS 協(xié)議是由 SSL+HTTP 協(xié)議構(gòu)建的可進行加密傳輸舶沿、身份認證的網(wǎng)絡協(xié)議，比 http 協(xié)議安全配并。

11. 什么是跨域括荡，如何解決跨域

參考文章：《前端常見跨域解決方案（全）》

11.1 什么是跨域

跨域，指的是瀏覽器不能執(zhí)行其他網(wǎng)站的腳本荐绝。它是由瀏覽器的同源策略造成的一汽，是瀏覽器對JavaScript施加的安全限制。

• 什么是同源策略低滩？

同源策略/SOP（Same origin policy）是一種約定召夹，由Netscape公司1995年引入瀏覽器，它是瀏覽器最核心也最基本的安全功能恕沫，如果缺少了同源策略监憎，瀏覽器很容易受到 XSS 、 CSFR 等攻擊婶溯。所謂同源是指"協(xié)議+域名+端口"三者相同鲸阔，即便兩個不同的域名指向同一個ip地址偷霉，也非同源。

• 同源策略限制了以下行為：

1. Cookie褐筛、LocalStorage 和 IndexDB 無法讀取
2. DOM 和 JS對象無法獲取
3. Ajax請求發(fā)送不出去

• 常見跨域場景：

所謂的同源是指：域名类少、協(xié)議、端口均為相同渔扎。

• http://www.a.cn/index.html 調(diào)用 http://www.a.cn/server.php 非跨域硫狞。

• http://www.a.cn/index.html 調(diào)用 http://www.b.cn/server.php 跨域，主域不同晃痴。

• http://abc.a.cn/index.html 調(diào)用 http://def.b.cn/server.php 跨域残吩，子域名不同。

• http://www.a.cn:8080/index.html 調(diào)用 http://www.a.cn/server.php 跨域倘核，端口不同泣侮。

• https://www.a.cn/index.html 調(diào)用 http://www.a.cn/server.php 跨域,協(xié)議不同。

• localhost 調(diào)用 127.0.0.1 跨域紧唱。

11.2 解決跨域

1. jsonp 跨域
2. document.domain + iframe 跨域
3. window.name + iframe 跨域
4. location.hash + iframe 跨域
5. postMessage 跨域
6. 跨域資源共享CORS
7. withCredentials 屬性
8. WebSocket 協(xié)議跨域
9. node 代理跨域
10. nginx 代理跨域

具體每一種解決方法活尊，可以參考：《前端常見跨域解決方案（全）》

12. HTTP 中與緩存相關(guān)的頭部有哪些，它們有什么區(qū)別

13. 分別介紹強緩存和協(xié)商緩存

瀏覽器緩存主要分為強緩存（也稱本地緩存）和協(xié)商緩存（也稱弱緩存）。

13.1 強緩存

強緩存是利用 http 頭中的 Expires 和 Cache-Control 兩個字段來控制的赁濒，用來表示資源的緩存時間轨奄。

強緩存中，普通刷新會忽略它流部，但不會清除它戚绕，需要強制刷新。瀏覽器強制刷新枝冀，請求會帶上 Cache-Control:no-cache 和 Pragma:no-cache舞丛。

通常耘子，強緩存不會向服務器發(fā)送請求，直接從緩存中讀取資源球切，在chrome控制臺的network選項中可以看到該請求返回200的狀態(tài)碼谷誓。分為 from disk cache 和 from memory cache。

• from disk cache ：一般非腳本會存在內(nèi)存當中吨凑，如css捍歪，html等

• from memory cache ：資源在內(nèi)存當中，一般腳本鸵钝、字體糙臼、圖片會存在內(nèi)存當

有緩存命中和緩存未命中狀態(tài):

http17

http18

13.2 協(xié)商緩存

協(xié)商緩存就是由服務器來確定緩存資源是否可用，所以客戶端與服務器端要通過某種標識來進行通信恩商，從而讓服務器判斷請求資源是否可以緩存訪問变逃。

普通刷新會啟用弱緩存，忽略強緩存怠堪。只有在地址欄或收藏夾輸入網(wǎng)址揽乱、通過鏈接引用資源等情況下，瀏覽器才會啟用強緩存粟矿，這也是為什么有時候我們更新一張圖片凰棉、一個js文件，頁面內(nèi)容依然是舊的陌粹，但是直接瀏覽器訪問那個圖片或文件撒犀，看到的內(nèi)容卻是新的。

這個主要涉及到兩組 header 字段： Etag 和 If-None-Match申屹、 Last-Modified和 If-Modified-Since绘证。

向服務器發(fā)送請求，服務器會根據(jù)這個請求的request header的一些參數(shù)來判斷是否命中協(xié)商緩存哗讥。

有緩存命中和緩存未命中狀態(tài):

http19

http20

13.3 流程

瀏覽器第一次發(fā)起請求嚷那，本地有緩存情況： 在瀏覽器第一次發(fā)起請求時，本地無緩存杆煞，向web服務器發(fā)送請求魏宽，服務器起端響應請求，瀏覽器端緩存决乎。過程如下：

1

在第一次請求時队询，服務器會將頁面最后修改時間通過 Last-Modified標識由服務器發(fā)送給客戶端，客戶端記錄修改時間构诚；服務器還會生成一個Etag蚌斩，并發(fā)送給客戶端。

瀏覽器后續(xù)再次進行請求時：

2

14. 請簡單介紹一下 LRU （Least recently used）算法

參考文章：《LRU算法》

14.1 原理

LRU（Least recently used范嘱，最近最少使用）算法根據(jù)數(shù)據(jù)的歷史訪問記錄來進行淘汰數(shù)據(jù)送膳，其核心思想是“如果數(shù)據(jù)最近被訪問過员魏，那么將來被訪問的幾率也更高”。

http21

這里有一張比較卡通的圖片：

http22

14.2 實現(xiàn)

最常見的實現(xiàn)是使用一個鏈表保存緩存數(shù)據(jù)叠聋，詳細算法實現(xiàn)如下：

1. 新數(shù)據(jù)插入到鏈表頭部撕阎；

2. 每當緩存命中（即緩存數(shù)據(jù)被訪問），則將數(shù)據(jù)移到鏈表頭部碌补；

3. 當鏈表滿的時候虏束，將鏈表尾部的數(shù)據(jù)丟棄。

14.3 分析

• 命中率

當存在熱點數(shù)據(jù)時厦章，LRU的效率很好镇匀，但偶發(fā)性的、周期性的批量操作會導致LRU命中率急劇下降闷袒，緩存污染情況比較嚴重坑律。

• 復雜度

實現(xiàn)簡單。

• 代價

命中時需要遍歷鏈表囊骤，找到命中的數(shù)據(jù)塊索引，然后需要將數(shù)據(jù)移到頭部冀值。

結(jié)語

本文主要復習了 HTTP/HTTPS 的一些基礎知識也物，還有 HTTP 的其他版本的知識，對于面試也好列疗，知識沉淀也好滑蚯，這些也是我們作為開發(fā)者必須懂的。

作為一名前端開發(fā)者抵栈，說實話對 HTTP/HTTPS 了解還是太少告材，可能和平常工作內(nèi)容有關(guān)。

關(guān)于我

本文首發(fā)在 pingan8787個人博客古劲，如需轉(zhuǎn)載請保留個人介紹

微信公眾號

bg