前端（五）瀏覽器（協議）篇

協議篇

一、從URL輸入到頁面展示到底發生什麼？

整體來講分爲如下幾個過程:

• （1）DNS服務器解析域名，找到對應服務器的IP地址;

• （2）和服務器創建TCP三次握手鏈接；

• （3）發送HTTP請求，服務器會根據HTTP請求到數據服務器取出相應的資源，並返回給瀏覽器；

• （4）瀏覽器處理響應

  • 加載：瀏覽器對一個html頁面的加載順序是從上而下的。
  • 當加載到外部css文件、圖片等資源，瀏覽器會再發起一次http請求，來獲取外部資源。
  • 當加載到js文件，html文檔會掛起渲染（加載解析渲染同步）的線程，等待js文件加載、解析完畢才能夠恢復html文檔的渲染線程。
  • 解析：解析DOM樹和CSSDOM樹。
  • 渲染：構建渲染樹，將DOM樹進行可視化表示，將頁面呈現給用戶。

推薦 浪裏行舟 文章 從URL輸入到頁面展示到底發生什麼？

二、瀏覽器如何解析渲染頁面？

瀏覽器解析渲染頁面分爲一下五個步驟：

• 根據 HTML 解析出 DOM 樹
• 根據CSS解析生成 CSS 規則樹
• 結合 DOM 樹和CSS 規則樹，生成渲染樹
• 根據渲染樹計算每個節點的信息
• 根據計算好的信息繪製頁面

三、緩存

3.一、DNS緩存

1）DNS查詢過程以下:

• 首先搜索瀏覽器自身的DNS緩存,若是存在，則域名解析到此完成。

• 若是瀏覽器自身的緩存裏面沒有找到對應的條目，那麼會嘗試讀取操做系統的hosts文件看是否存在對應的映射關係,若是存在，則域名解析到此完成。

• 若是本地hosts文件不存在映射關係，則查找本地DNS服務器(ISP服務器,或者本身手動設置的DNS服務器),若是存在,域名到此解析完成。

• 若是本地DNS服務器還沒找到的話,它就會向根服務器發出請求,進行遞歸查詢。

2）DNS 屬於哪一個層級?工做在哪一個層級?

DNS屬於應用層協議, 至於TCP/UDP哪一層上面跑,DNS 默認端口是53,走 UDP

DNS 的解析的幾個記錄類型須要瞭解:

• A: 域名直接到 IP
• CNAME: 能夠多個域名映射到一個主機,相似在 Github Page就用 CNAME 指向 -MX: 郵件交換記錄,用的很少,通常搭建郵件服務器纔會用到
• NS: 解析服務記錄,能夠設置權重,指定誰解析
• TTL: 就是生存時間(也叫緩存時間),通常的域名解析商都有默認值,也能夠人爲設置
• TXT: 通常指某個主機名或域名的說明

3.二、CDN 緩存

什麼是CDN

全稱 Content Delivery Network,即內容分發網絡。

摘錄一個形象的比喻,來理解CDN是什麼。

10年前，尚未火車票代售點一說，12306.cn更是無從提及。那時候火車票還只能在火車站的售票大廳購買，而我所在的小縣城並不通火車，火車票都要去市裏的火車站購買，而從我家到縣城再到市裏，來回就是4個小時車程，簡直就是浪費生命。後來就行了，小縣城裏出現了火車票代售點，甚至鄉鎮上也有了代售點，能夠直接在代售點購買火車票，方便了很多，全市人民不再用在一個點苦逼的排隊買票了。

簡單的理解CDN就是這些代售點(緩存服務器)的承包商,他爲買票者提供了便利,幫助他們在最近的地方(最近的CDN節點)用最短的時間(最短的請求時間)買到票(拿到資源),這樣去火車站售票大廳排隊的人也就少了。也就減輕了售票大廳的壓力(起到分流做用,減輕服務器負載壓力)。

用戶在瀏覽網站的時候，CDN會選擇一個離用戶最近的CDN邊緣節點來響應用戶的請求，這樣海南移動用戶的請求就不會千里迢迢跑到北京電信機房的服務器（假設源站部署在北京電信機房）上了。

CDN緩存

關於CDN緩存,在瀏覽器本地緩存失效後,瀏覽器會向CDN邊緣節點發起請求。相似瀏覽器緩存,CDN邊緣節點也存在着一套緩存機制。CDN邊緣節點緩存策略因服務商不一樣而不一樣，但通常都會遵循http標準協議，經過http響應頭中的

Cache-control: max-age   //後面會提到
複製代碼

複製代碼的字段來設置CDN邊緣節點數據緩存時間。

當瀏覽器向CDN節點請求數據時，CDN節點會判斷緩存數據是否過時，若緩存數據並無過時，則直接將緩存數據返回給客戶端；不然，CDN節點就會向服務器發出回源請求，從服務器拉取最新數據，更新本地緩存，並將最新數據返回給客戶端。

CDN服務商通常會提供基於文件後綴、目錄多個維度來指定CDN緩存時間，爲用戶提供更精細化的緩存管理。

CDN 優點

• CDN節點解決了跨運營商和跨地域訪問的問題，訪問延時大大下降。
• 大部分請求在CDN邊緣節點完成，CDN起到了分流做用，減輕了源服務器的負載。

3.三、瀏覽器緩存(http緩存)

請看webfansplz 的文章 實踐這一次,完全搞懂瀏覽器緩存機制

三級緩存原理 (訪問緩存優先級)

• 先在內存中查找,若是有,直接加載。
• 若是內存中不存在,則在硬盤中查找,若是有直接加載。
• 若是硬盤中也沒有,那麼就進行網絡請求。
• 請求獲取的資源緩存到硬盤和內存。

瀏覽器緩存的分類

• 強緩存

• 協商緩存

瀏覽器再向服務器請求資源時,首先判斷是否命中強緩存,再判斷是否命中協商緩存!

瀏覽器緩存的優勢

1.減小了冗餘的數據傳輸

2.減小了服務器的負擔，大大提高了網站的性能

3.加快了客戶端加載網頁的速度

強緩存

瀏覽器在加載資源時，會先根據本地緩存資源的 header 中的信息判斷是否命中強緩存，若是命中則直接使用緩存中的資源不會再向服務器發送請求。
複製代碼

這裏的 header中的信息指的是expires 和 cahe-control

協商緩存

當強緩存沒有命中的時候，瀏覽器會發送一個請求到服務器，服務器根據 header 中的部分信息來判斷是否命中緩存。若是命中，則返回 304 ，告訴瀏覽器資源未更新，可以使用本地的緩存。
複製代碼

這裏的 header 中的信息指的是Last-Modify/If-Modify-Since和 ETag/If-None-Match.

Last-Modified 與 ETag是能夠一塊兒使用的，服務器會優先驗證 ETag，一致的狀況下，纔會繼續比對 Last-Modified，最後才決定是否返回304。

總結

當瀏覽器再次訪問一個已經訪問過的資源時，它會這樣作：
複製代碼

• 1.看看是否命中強緩存，若是命中，就直接使用緩存了。
• 2.若是沒有命中強緩存，就發請求到服務器檢查是否命中協商緩存。
• 3.若是命中協商緩存，服務器會返回 304 告訴瀏覽器使用本地緩存。
• 4.不然，返回最新的資源。

參考文獻：

前端性能優化之緩存利用

四、瀏覽器內核有哪些，移動端用的是哪一個

• Trident內核：IE,MaxThon,TT,The Word,360,搜狗瀏覽器等。[又稱爲MSHTML]
• Gecko內核：Netscape6及以上版本，FF,MozillaSuite/SeaMonkey等；
• Presto內核：Opera7及以上。[Opera內核原爲：Presto，現爲：Blink]
• Webkit內核：Safari,Chrome等。[Chrome的:Blink(Webkit的分支)]

對於Android手機而言，使用率最高的就是Webkit內核。

協議篇

---

一、OSI七層網絡模型

OSI七層模型	做用	對應協議	對應設備
應用層	它是計算機用戶，以及各類應用程序和網絡之間的接口	HTTP, FTP, SMTP, POP3	計算機設備
表示層	信息的語法語義以及它們的關係，如加密解密、轉換翻譯、壓縮解壓縮	IPX, LPP, XDP
會話層	創建、維護、管理應用程序之間的會話	SSL,TLS, DAP, LDAP
傳輸層	服務點編址，分段與重組、鏈接控制、流量控制、差錯控制	TCP, UDP	防火牆
網絡層	爲網絡設備提供邏輯地址，進行路由選擇、分組轉發	IP ，ARP ，RARP ，ICMP ，IGMP	路由器
數據鏈路層	物理尋址，同時將原始比特流轉變爲邏輯傳輸路線	PPTP, ARP, RARP	交換機
物理層	機械、電子、定時接口通道信道上的原始比特流傳輸	IEEE 802.2, Ethernet v.2, Internetwork	網卡

二、介紹下HTTP報文的組成部分？

• 請求報文：請求行、請求頭、空行、請求體

• 響應報文：狀態行、響應頭、空行、響應體

以請求報文爲例：

• 請求行: 這個好理解就是訪問的方法+ 協議+ 訪問的 URL 構成
• 請求頭: key-value值，告訴服務端須要的內容
• 空行：告知服務端如下內容爲請求體
• 請求體: 數據部分

請求報文知道,那你說說cookie是如何跟隨請求的?

Cookie就是保存在 HTTP 協議的請求或者應答頭部(Cookie 是由服務端生成),這樣一路漂泊...

Cookie 隔離是什麼,如何作;

cookie 隔離就是下降 header 的數據包含,以達到加快訪問速度的目的

方案: 靜態資源丟 CDN或者非主域來加載

三、常見的HTTP方法有哪些？

-GET：獲取資源

• POST：傳輸資源
• PUT：更新資源
• DELETE：刪除資源
• HEAD：得到報文首部

四、POST和GET的區別是什麼？

1）GET在瀏覽器回退時是無害的，而POST會再次提交請求

2）GET請求會被瀏覽器主動緩存，而POST不會，除非手動設置

3）GET請求參數會被完整保留在瀏覽器的歷史記錄裏，而POST中的參數不會被保留

4）POST比GET安全，因參數暴露在URL上

5）GET參數經過URL傳遞，POST放在Request body中

高級區別：

• GET 的本質是「得」，而 POST的本質是「給」。GET 的內容能夠被瀏覽器緩存，而POST的數據不能夠。

• get產生一個TCP數據包，一個是請求頭，一個請求體的；post產生兩個TCP數據包；

• 在一次請求中，get一次性完成，post在部分瀏覽器（除了火狐）須要發送兩次信息，因此get比post更快，更有效率。

• 6) 補充補充一個get和post在緩存方面的區別：

  • get請求相似於查找的過程，用戶獲取數據，能夠不用每次都與數據庫鏈接，因此可使用緩存。
  • post不一樣，post作的通常是修改和刪除的工做，因此必須與數據庫交互，因此不能使用緩存。所以get請求適合於請求緩存。

推薦文章 WebTechGarden 微信公衆號的文章 99%的人都理解錯了HTTP中GET與POST的區別

4.一、get和post分別進行幾回數據交互

• get請求過程：（2次交互）

  • 瀏覽器請求tcp鏈接（第一次握手）
  • 服務器答應進行tcp鏈接（第二次握手）
  • 瀏覽器確認，併發送get請求頭和數據（第三次握手，這個報文比較小，因此http會在此時進行第一次數據發送）
  • 服務器返回200 ok響應。

• post請求過程：（3次交互）

  • 瀏覽器請求tcp鏈接（第一次握手）
  • 服務器答應進行tcp鏈接（第二次握手）
  • 瀏覽器確認，併發送post請求頭（第三次握手，這個報文比較小，因此http會在此時進行第一次數據發送）

• 服務器返回100 continue響應

• 瀏覽器開始發送數據

• 服務器返回200 ok響應

五、HTTP1.1的持久連接？

• HTTP協議採用「請求-應答」模式，當使用普通模式，即非keep-Alive模式時，每一個請求/應答客戶和服務器都要新一個鏈接，完成以後當即斷開鏈接。
• 當使用keep-Alive模式（持久連接）時，keep-Alive功能使客戶端到服務器端的鏈接持久有效，當出現服務器的後繼請求時，keep-Alive避免從新創建鏈接

六、http和https的基本概念?

http: 超文本傳輸協議，是互聯網上應用最爲普遍的一種網絡協議，是一個客戶端和服務器端請求和應答的標準（TCP），用於從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議，它可使瀏覽器更加高效，使網絡傳輸減小。

https: 是以安全爲目標的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎是SSL，所以加密的詳細內容就須要SSL。

https協議的主要做用是：創建一個信息安全通道，來確保數組的傳輸，確保網站的真實性。

七、HTTP 和 HTTPS 有何差別?

http傳輸的數據都是未加密的，也就是明文的，網景公司設置了SSL協議來對http協議傳輸的數據進行加密處理，簡單來講https協議是由http和ssl協議構建的可進行加密傳輸和身份認證的網絡協議，比http協議的安全性更高。
複製代碼

主要的區別以下：

• Https協議須要ca證書，費用較高。
• http是超文本傳輸協議，信息是明文傳輸，https則是具備安全性的ssl加密傳輸協議。
• 使用不一樣的連接方式，端口也不一樣，通常而言，http協議的端口爲80，https的端口爲443
• http的鏈接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。

八、Https協議的工做原理

1）客戶使用https url訪問服務器，則要求web 服務器創建ssl連接。

2）web服務器接收到客戶端的請求以後，會將網站的證書（證書中包含了公鑰），返回或者說傳輸給客戶端。

3）客戶端和web服務器端開始協商SSL連接的安全等級，也就是加密等級。

4）客戶端瀏覽器經過雙方協商一致的安全等級，創建會話密鑰，而後經過網站的公鑰來加密會話密鑰，並傳送給網站。

5）web服務器經過本身的私鑰解密出會話密鑰。

6）web服務器經過會話密鑰加密與客戶端之間的通訊。
複製代碼

九、https協議的優勢

• 使用HTTPS協議可認證用戶和服務器，確保數據發送到正確的客戶機和服務器；
• HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，要比http協議安全，可防止數據在傳輸過程當中不被竊取、改變，確保數據的完整性。
• HTTPS是現行架構下最安全的解決方案，雖然不是絕對安全，但它大幅增長了中間人攻擊的成本。

十、https協議的缺點

• https握手階段比較費時，會使頁面加載時間延長50%，增長10%~20%的耗電。
• https緩存不如http高效，會增長數據開銷。
• SSL證書也須要錢，功能越強大的證書費用越高。
• SSL證書須要綁定IP，不能再同一個ip上綁定多個域名，ipv4資源支持不了這種消耗。

十一、HTTPS中的TLS/SSL是如何保護數據？

• 通常有兩種形式,非對稱加密,生成公鑰和私鑰,私鑰丟服務器,公鑰每次請求去比對驗證;

• 更嚴謹的採用 CA(Certificate Authority),給密鑰簽名....

十二、對稱加密和非對稱加密,能說說整個流程如何運轉的麼(HTTPS)

對稱加密:

• 雙方都有一樣的密鑰,每次通信都要生成一個惟一密鑰,速度很快
• 安全性較低且密鑰增加的數量極快

非對稱加密(通常用 RSA)

• 安全性很高,對資源消耗很大(CPU),目前主流的加密算法(基本用於交換密鑰或簽名,而非全部通信內容)

CA(數字簽名):

• 這個是爲了防止中間人給偷換了形成數據被竊取而誕生的 用一些權威機構頒佈的算法來簽名,權威機構作中間人,通信過程都會跟機構覈對一遍

1三、http2.0

• 提高訪問速度（能夠對於，請求資源所需時間更少，訪問速度更快，相比http1.0）
• 容許多路複用：多路複用容許同時經過單一的HTTP/2鏈接發送多重請求-響應信息。改善了：在http1.1中，瀏覽器客戶端在同一時間，針對同一域名下的請求有必定數量限制（鏈接數量），超過限制會被阻塞。
• 二進制分幀：HTTP2.0會將全部的傳輸信息分割爲更小的信息或者幀，並對他們進行二進制編碼
• 首部壓縮
• 服務器端推送

1四、TCP和UDP的區別

（1）TCP是面向鏈接的，udp是無鏈接的即發送數據前不須要先創建連接。

（2）TCP提供可靠的服務,UDP不可靠交付。而且由於tcp可靠，面向鏈接，不會丟失數據所以適合大數據量的交換。

（3）TCP是面向字節流，UDP面向報文，而且網絡出現擁塞不會使得發送速率下降。

（4）TCP只能是1對1的，UDP支持1對1,1對多。

（5）TCP的首部較大爲20字節，而UDP只有8字節。

（6）TCP是面向鏈接的可靠性傳輸，而UDP是不可靠的。
複製代碼

1五、狀態碼

1XX: 通常用來判斷協議更換或者確認服務端收到請求這些

100: 服務端收到部分請求,如果沒有拒絕的狀況下能夠繼續傳遞後續內容

101: 客戶端請求變換協議,服務端收到確認
複製代碼

2xx: 請求成功,是否建立連接,請求是否接受,是否有內容這些

200: (成功)服務器已成功處理了請求。

201: (已建立)請求成功而且服務器建立了新的資源。

202: (已接受)服務器已接受請求，但還沒有處理。

204: (無內容)服務器成功處理了請求，但沒有返回任何內容。
複製代碼

3XX: 通常用來判斷重定向和緩存

301: 全部請求已經轉移到新的 url(永久重定向),會被緩存

302: 臨時重定向,不會被緩存

304: 本地資源暫未改動,優先使用本地的(根據If-Modified-Since or If-Match去比對服務器的資源,緩存)
複製代碼

4XX: 通常用來確認受權信息,請求是否出錯,頁面是否丟失

400: 請求出錯

401: 未受權,不能讀取某些資源

403: 阻止訪問,通常也是權限問題

404: 頁面丟失,資源沒找到

408: 請求超時

415: 媒介類型不被支持，服務器不會接受請求。
複製代碼

5XX: 基本都是服務端的錯誤

500: 服務端錯誤

502: 網關錯誤

504: 網關超時
複製代碼

1六、補充400和40一、403狀態碼

(1)400狀態碼：請求無效

產生緣由：

前端提交數據的字段名稱和字段類型與後臺的實體沒有保持一致

前端提交到後臺的數據應該是json字符串類型，可是前端沒有將對象JSON.stringify轉化成字符串。
複製代碼

解決方法：

對照字段的名稱，保持一致性

將obj對象經過JSON.stringify實現序列化
複製代碼

(2)401狀態碼：當前請求須要用戶驗證

(3)403狀態碼：服務器已經獲得請求，可是拒絕執行

1七、三次握手、四次揮手？

推薦文章 老錢的 跟着動畫來學習TCP三次握手和四次揮手

1八、WebSocket的實現和應用

WebSocket是HTML5中的協議，支持持久連續，http協議不支持持久性鏈接。Http1.0和HTTP1.1都不支持持久性的連接，HTTP1.1中的keep-alive，將多個http請求合併爲1個

1九、Cookie、sessionStorage、localStorage的區別

共同點：都是保存在瀏覽器端，而且是同源的

Cookie：能夠在瀏覽器和服務器端來回傳遞，存儲容量小，只有大約4K左右

sessionStorage：僅在當前瀏覽器窗口關閉前有效，天然也就不可能持久保持，localStorage：始終有效，窗口或瀏覽器關閉也一直保存，所以用做持久數據；cookie只在設置的cookie過時時間以前一直有效，即便窗口或瀏覽器關閉。

localStorage：localStorage在全部同源窗口中都是共享的；cookie也是在全部同源窗口中都是共享的，無論窗口或者瀏覽器關閉與否都會始終生效

補充說明一下cookie的做用：

• 保存用戶登陸狀態。例如將用戶id存儲於一個cookie內，這樣當用戶下次訪問該頁面時就不須要從新登陸了，如今不少論壇和社區都提供這樣的功能。

• cookie還能夠設置過時時間，當超過期間期限後，cookie就會自動消失。所以，系統每每能夠提示用戶保持登陸狀態的時間：常見選項有一個月、三個 月、一年等。

• 跟蹤用戶行爲。例如一個天氣預報網站，可以根據用戶選擇的地區顯示當地的天氣狀況。若是每次都須要選擇所在地是煩瑣的，當利用了cookie後就會顯得很人性化了，系統可以記住上一次訪問的地區，當下次再打開該頁面時，它就會自動顯示上次用戶所在地區的天氣狀況。由於一切都是在後 臺完成，因此這樣的頁面就像爲某個用戶所定製的同樣，使用起來很是方便

• 定製頁面。若是網站提供了換膚或更換佈局的功能，那麼可使用cookie來記錄用戶的選項，例如：背景色、分辨率等。當用戶下次訪問時，仍然能夠保存上一次訪問的界面風格。

20、路由實現的原理

兩種模式 hash 和 history。

推薦尋找海藍96的文章 面試官: 你瞭解前端路由嗎?

2一、負載均衡

多臺服務器共同協做，不讓其中某一臺或幾臺超額工做，發揮服務器的最大做用

• http重定向負載均衡：調度者根據策略選擇服務器以302響應請求，缺點只有第一次有效果，後續操做維持在該服務器
• dns負載均衡：解析域名時，訪問多個ip服務器中的一個（可監控性較弱）
• 反向代理負載均衡：訪問統一的服務器，由服務器進行調度訪問實際的某個服務器，對統一的服務器要求大，性能受到 服務器羣的數量