瀏覽器從輸入url到呈現(xiàn)發(fā)生了什么

1、根據(jù)輸入的網(wǎng)址解析域名到對應的ip地址，查找順序：
瀏覽器緩存、操作系統(tǒng)緩存、路由器緩存、DNS 服務器（記錄這域名和ip地址的映射）、根服務器。
2、找到ip地址需要先建立TCP鏈接
客戶端發(fā)送 SYN數(shù)據(jù)包表示請求連接，服務端響應SYN 和 ACK 表示問答，客戶端收到后回應一個 ACK數(shù)據(jù)包表示建立連接成功。
3、發(fā)送HTTP請求
完整的請求報文包括請求行（包含請求的方法、url、協(xié)議版本）、請求頭（瀏覽器的信息鍵值對組成）、空行、請求體（請求的數(shù)據(jù)）；
4、服務器處理返回http響應報文
5、（解析DOM）瀏覽器收到html文件，瀏覽器會將收到的字節(jié)內(nèi)容、轉(zhuǎn)為字符、token化、轉(zhuǎn)為節(jié)點對象，將對象鏈在一起形成文本對象模型也就是DOM
6、遇到link標簽加載css，同時繼續(xù)解析DOM
7、接收到css文件后通用需要把字節(jié)轉(zhuǎn)為字符、token化生產(chǎn)CSSOM
8、如果遇到script標簽，下載對應的腳本，CSSOM構(gòu)建完成后才會執(zhí)行JS的內(nèi)容，因為JS即可以操作DOM又可以操作CSSOM，所以需要等js加載完成后再生產(chǎn)渲染樹
8、匹配DOM和CSSOM節(jié)點，生成渲染樹
9、獲取節(jié)點樹的結(jié)構(gòu)、位置、大小、依據(jù)盒模型布局
10、將渲染樹以像素的形式繪制，呈現(xiàn)網(wǎng)頁
11、請求完成后還有一個四次揮手的過程，客戶端主動發(fā)送FIN 給服務端，服務端收到后先響應ACK等數(shù)據(jù)全部傳輸完成再發(fā)送FIN，客戶端收到后再回應ACK至此，連接斷開。

cookie、 session、token 的區(qū)別

cookie ：用戶第一次登錄請求時服務端在響應頭設置set-cookie，瀏覽器發(fā)送請求并攜帶cookie，服務器驗證cookie正確正常響應。
session： 用戶第一次登錄請求時服務端創(chuàng)建一個session，并將sessionId設置在響應頭set-cookie給客戶端，客戶端發(fā)送請求并攜帶cookie，服務端通過sessionId找session，驗證正確正常響應。
token ：用戶第一次登錄請求時服務端生產(chǎn)token，token中帶有用戶id，客戶方發(fā)送請求時將token放在請求頭中，服務端獲取到token校驗通過后正常響應。
三者的區(qū)別：
1、cookie 存儲在客戶端，大小4KB，不夠安全；
2、session 存儲在服務端 無大小限制 更安全，但是消耗服務器資源；
3、token 都可以存儲，體積小，只存了用戶id相對安全，需要根據(jù)id查找用戶信息速度慢；

常見的HTTP請求方法

GET，表示向服務器獲取資源
POST，表示向服務器提交信息，通常用于產(chǎn)生新的數(shù)據(jù)，比如注冊
PUT，表示希望修改服務器的數(shù)據(jù)，通常用于修改
DELETE，表示希望刪除服務器的數(shù)據(jù)
OPTIONS，發(fā)生在跨域的預檢請求中，表示客戶端向服務器申請跨域提交
TRACE，回顯服務器收到的請求，主要用于測試和診斷
CONNECT，用于建立連接管道，通常在代理場景中使用，網(wǎng)頁中很少用到

常見的HTTP請求頭和響應頭

常見的請求頭:
Content-Type: 請求發(fā)送的數(shù)據(jù)類型，使用最多的是application/json
Cookie: 攜帶的用戶信息
Origin:協(xié)議 + 域名 + 端口號
Accept:瀏覽器可以接受服務器回發(fā)的類型 */* 代表瀏覽器可以處理所有類型
User-Agent：客戶端使用的操作系統(tǒng)和瀏覽器的名稱和版本
Connection: 是否保持長連接，設置為keep-alive當一個網(wǎng)頁打開完成后，客戶端和服務器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會關(guān)閉

常見的響應頭：
Access-Control-Allow-Origin: 指定哪些網(wǎng)站可以跨域資源共享
Content-Type:告訴客戶端，資源文件的類型
Date：服務端發(fā)送資源時的服務器時間
跟緩存相關(guān)的響應頭：ETag、Expires、Cache-Control

GET 和 POST請求的區(qū)別

一、GET不會對服務器資源產(chǎn)生影響，而POST會對服務器資源產(chǎn)生影響；
二、瀏覽器一般會對GET請求緩存，但很少對POST請求緩存；
三、GET請求的參數(shù) url 可見，而 POST 請求的參數(shù) url 不可見（放在請求體中）；
四、GET傳送的數(shù)據(jù)量較小，不能大于2KB（這主要是因為它受約于url長度的限制）

POST的參數(shù)可以放在URL上嗎

雖然POST方法更加安全，但是并不代表它不能在URL中放參數(shù)。
HTTP協(xié)議中并沒有規(guī)定POST方法不能在URL中放參數(shù)，只是這種方式不符合HTTP協(xié)議的規(guī)范，且不安全，所以一般不建議使用這種方式

HTTP和HTTPS協(xié)議的區(qū)別

一、HTTP協(xié)議是超文本傳輸協(xié)議，信息是明文傳輸；HTTPS協(xié)議使用 SSL 或 TLS 來加密數(shù)據(jù)確保數(shù)據(jù)傳輸?shù)陌踩?br> 二、HTTP協(xié)議使用的端口是80；HTTPS協(xié)議使用的端口是443。
三、HTTPS協(xié)議需要CA證書，費用較高；而HTTP協(xié)議不需要；

HTTP請求報文的是什么樣的？

請求報文有4部分組成:
請求行（請求方法、URL、HTTP協(xié)議版本）
請求頭部（瀏覽器相關(guān)的信息，鍵值對組成）
空行
請求體（請求攜帶的數(shù)據(jù)）

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

http狀態(tài)碼大致分為5類
第一類、1xx 表示提示信息，一般服務器精致向客戶端發(fā)送這種狀態(tài)碼，見得少；
第二類、2xx 表示請求已經(jīng)被服務器接收、理解；
200 OK 請求成功
第三類、3xx 重定向，表示需要客戶端進一步操作；
301 Moved Permanently 永久性重定向，該狀態(tài)碼表示請求的資源已被分配了新的 URI
302 Found 該狀態(tài)碼表示請求的資源已被臨時分配了新的 URI
304 Not Modified 請求資源未修改，使用上次緩存
第四類、4xx 請求錯誤，通過是客戶端錯誤
400 Bad Request，該狀態(tài)碼表示請求報文中存在語法錯誤
401 Unauthorized 需要有通過 HTTP 認證
403 Forbidden 該狀態(tài)碼表明對請求資源的訪問被服務器拒絕了
404 Not Found 該狀態(tài)碼表明服務器上無法找到請求的資源
第五類、5xx 服務器錯誤
500 Internal Server Error 該狀態(tài)碼表明服務器端在執(zhí)行請求時發(fā)生了錯誤
503 Service Unavailable 該狀態(tài)碼表明服務器暫時處于超負載或正在進行停機維護
504 Gateway timeout 代表網(wǎng)關(guān)超時是指服務器作為網(wǎng)關(guān)或代理，但是沒有及時從上游服務器收到請求

http1.0 和 http1.1 的區(qū)別

1、長連接，http1.0 默認使用非持久連接（每次請求響應完成后TCP連接就斷開，繼續(xù)請求需要重新建立連接每次都需要經(jīng)過三次握手四次揮手），而 http1.1 默認開啟Connection： keep-alive使用持久連接（響應后無需重新連接可繼續(xù)發(fā)送請求）
2、管道機制，HTTP/1.0不支持請求管道化（同一個TCP連接請求上個請求需要服務端響應后客戶端才能繼續(xù)發(fā)送下個請求），HTTP/1.1支持請求管道化（允許客戶端同時發(fā)送多個請求，服務端按照順序響應；但是如果前面的請求處理的特別慢會造成隊頭阻塞）
3、緩存策略，在HTTP1.0中主要使用header里的If-Modified-Since，Expires來做為緩存判斷的標準，HTTP1.1則引入了更多的緩存控制策略，例如Entity tag，If-Unmodified-Since，If-Match，If-None-Match等更多可供選擇的緩存頭來控制緩存策略

http1.1 和 2.0 的區(qū)別

1、服務器推送： HTTP/2 允許服務器未經(jīng)請求，主動向客戶端發(fā)送資源
2、二進制協(xié)議：在 HTTP/1.1 版中，報文的頭信息必須是文本（ASCII 編碼），數(shù)據(jù)體可以是文本，也可以是二進制。HTTP/2 則是一個徹底的二進制協(xié)議，頭信息和數(shù)據(jù)體都是二進制，并且統(tǒng)稱為"幀"，可以分為頭信息幀和數(shù)據(jù)幀（使用二進制傳輸數(shù)據(jù)包更小解析開銷更低）
3、頭信息壓縮機制：由于 HTTP 1.1協(xié)議不帶狀態(tài)，每次請求都必須附上所有頭信息，但是每次請求很多字段都是重復的，每次請求都必須附帶，這會浪費很多帶寬，也影響速度。HTTP/2 對這一點做了優(yōu)化，引入了頭信息壓縮機制。一方面，頭信息使用 gzip 或 compress 壓縮后再發(fā)送；另一方面，客戶端和服務器同時維護一張頭信息表，所有字段都會存入這個表，生成一個索引號，以后就不發(fā)送同樣字段了，只發(fā)送索引號，這樣就能提高速度了
4、數(shù)據(jù)流： HTTP/2 使用了數(shù)據(jù)流的概念，因為 HTTP/2 的數(shù)據(jù)包是不按順序發(fā)送的，同一個連接里面連續(xù)的數(shù)據(jù)包，可能屬于不同的請求。因此，必須要對數(shù)據(jù)包做標記，指出它屬于哪個請求。HTTP/2 將每個請求或回應的所有數(shù)據(jù)包，稱為一個數(shù)據(jù)流。每個數(shù)據(jù)流都有一個獨一無二的編號。數(shù)據(jù)包發(fā)送時，都必須標記數(shù)據(jù)流 ID ，用來區(qū)分它屬于哪個數(shù)據(jù)流
5、多路復用： HTTP/2 實現(xiàn)了多路復用，HTTP/2 仍然復用 TCP 連接，但是在一個連接里，客戶端和服務器都可以同時發(fā)送多個請求或回應，而且不用按照順序一一發(fā)送，這樣就避免了"隊頭堵塞"的問題

前端緩存說下

我們常說的前端緩存是HTTP緩存，又分為強緩存和協(xié)商緩存；
先說下強緩存，是指客戶端第一次請求的時候服務端會在響應頭中放入expires 或者 cache-control：max-age 字段設置資源新鮮的時間，expires和cache-control：max-age的區(qū)別在于 Expires 是http1.0的產(chǎn)物，保存的是一個服務端的時間，但實際對比的是客戶端時間，可能會存在時間差；Cache-Control是http1.1的產(chǎn)物，兩者同時存在的話，Cache-Control優(yōu)先級高于Expires；當我們再次請求的時候，瀏覽器會先自己判斷，如果在有效期內(nèi)，則直接使用緩存，不會發(fā)起請求；
第二種是協(xié)商緩存，協(xié)商緩存每一次發(fā)起請求都不會再去詢問瀏覽器的緩存情況，而是直接向服務端去確認該資源是否過期。協(xié)商緩存依賴于服務端和瀏覽器之間的通信，通常客戶端第一次請求的時候服務端會在響應頭中放入cache-control：no-cache 表示資源被緩存但立即失效，下次會發(fā)起請求驗證資源是否過期；同時在響應頭添加Last-Modified 最后更新日期；瀏覽器在下次請求時會自動帶入If-Modified-Since請求頭為上次請求服務端返回的資源更新日期，服務端會對比自己的日期和請求頭中帶來的日期，如果判斷自上次請求后資源未修改，則直接返回304，重定向到瀏覽器緩存，否則重新返回數(shù)據(jù)。
但是根據(jù)文件最后修改時間判斷有個弊端，就是文件被編輯，但實際內(nèi)容未發(fā)生變化，這種情況我們預期中是使用緩存，而實際上會被當做新資源引發(fā)一次完整的響應；
所有我們會使用Etag 作為 Last-Modified 的補充，Etag 是由服務器為每個資源生成的唯一的標識字符串，這個標識字符串是基于文件內(nèi)容編碼的，只要文件內(nèi)容不同，它們對應的 Etag 就是不同的。
在響應頭中添加，Etag后下次請求時請求一個值相同的、名為 if-None-Match 的字符串供服務端比對，他能更精準的感知文件的變化，但是Etag 的生成過程需要服務器額外付出開銷，會影響服務端的性能，所以我們需要權(quán)衡；

在設置緩存策略是，我們需要根據(jù)實際情況決定，當我們的資源不可復用是，直接將Cache-Control 設置 no-store，拒絕一切形式的緩存；
如果需要每次向服務器進行確認，那么設置協(xié)商緩存，對于幾乎不怎么變更的資源可以設置強緩存；

瀏覽器緩存是存到哪里呢

內(nèi)存、磁盤

設置緩存是否過期怎么判斷

1、如果是強緩存，瀏覽器會將上次請求時間和max-age、expires絕對值，以及當前時間對比；
2、如果是協(xié)商緩存，服務端通過客戶端記錄的If-Modified-Since和自己記錄的Last-Modified字段對比；

webpack 常用的配置

const HtmlWebpackPlugin = require('html-webpack-plugin');
const webpack = require('webpack'); // 用于訪問內(nèi)置插件
module.exports = {
  // 指示 webpack 應該使用哪個模塊，來作為構(gòu)建其內(nèi)部 依賴圖(dependency graph) 的開始
  entry: './path/to/my/entry/file.js', 
  // 告訴 webpack 在哪里輸出它所創(chuàng)建的 bundle，以及如何命名這些文件。
  output: {
    filename: 'my-first-webpack.bundle.js', 
  },
 // webpack 只能理解 JavaScript 和 JSON 文件，這是 webpack 開箱可用的自帶能力。loader 讓 webpack 能夠去處理其他類型的文件，并將它們轉(zhuǎn)換為有效 模塊，以供應用程序使用，以及被添加到依賴圖中。
  module: {
    rules: [{ test: /\.txt$/, use: 'raw-loader' }],
  },
  // 選擇 development, production 或 none 之中的一個
  mode: 'production', 
  // 插件則可以用于執(zhí)行范圍更廣的任務。包括：打包優(yōu)化，資源管理，注入環(huán)境變量。
  plugins: [new HtmlWebpackPlugin({ template: './src/index.html' })], /
};

axios 常用的配置

baseURL：將自動加在 url 前面，除非 url 是一個絕對 URL
timeout ：指定請求超時的毫秒數(shù)，如果請求話費了超過 timeout 的時間，請求將被中斷
headers：是即將被發(fā)送的自定義請求頭
method：是創(chuàng)建請求時使用的方法
params：是即將與請求一起發(fā)送的 URL 參數(shù)
data：是作為請求主體被發(fā)送的數(shù)據(jù)，只適用于這些請求方法 ‘PUT’, ‘POST’
ransformRequest：允許在向服務器發(fā)送前，修改請求數(shù)據(jù)
transformResponse ：在傳遞給 then/catch 前，允許修改響應數(shù)據(jù)
withCredentials`：表示跨域請求時是否需要使用憑證
proxy：定義代理服務器的主機名稱和端口
axios.interceptors.request.use：添加請求攔截器，在請求發(fā)送之前統(tǒng)一判斷和處理
axios.interceptors.response.use： 統(tǒng)一處理請求成功和錯誤的情況

什么是事件委托

事件委托也叫事件代理，利用的是事件冒泡機制，通過指定一個事件處理程序來管理某一類型的所有事件的方法。
例如為ul 中所有的li 綁定一個點擊事件，那么直接綁定在ul上即可；

為什么使用CDN 會更快（了解）？

沒有使用CDN的情況下，用戶從瀏覽器輸入地址，依次經(jīng)過瀏覽器緩存、操作系統(tǒng)緩存（如本地host文件）、域名解析服務器、根域名解析服務器、頂級域名服務器直到找到對應的ip地址返回給用戶，用戶向該地址發(fā)起請求；
使用了CDN的情況下，用戶在瀏覽器中輸入要訪問的域名，瀏覽器向DNS服務器請求對域名進行解析。由于CDN對域名解析進行了調(diào)整，DNS服務器會最終將域名的解析權(quán)交給CNAME指向的CDN專用DNS服務器。
1、CDN的DNS服務器將CDN的負載均衡設備IP地址返回給用戶。
2、用戶向CDN的負載均衡設備發(fā)起內(nèi)容URL訪問請求。
3、CDN負載均衡設備會為用戶選擇一臺合適的緩存服務器提供服務。選擇的依據(jù)包括：根據(jù)用戶IP地址，判斷哪一臺服務器距離用戶最近；根據(jù)用戶所請求的URL中攜帶的內(nèi)容名稱，判斷哪一臺服務器上有用戶所需內(nèi)容；查詢各個服務器的負載情況，判斷哪一臺服務器的負載較小?；谝陨线@些依據(jù)的綜合分析之后，負載均衡設置會把緩存服務器的IP地址返回給用戶。
4、用戶向緩存服務器發(fā)出請求。
5、緩存服務器響應用戶請求，將用戶所需內(nèi)容傳送到用戶。

瀏覽器是如何知道什么域名應該交給CND專用的DNS服務器（了解）？

1、DNS查詢：使用nslookup或者dig等工具查詢網(wǎng)站的域名解析結(jié)果。如果返回的IP地址與原始主機的IP地址不一致，那么很有可能該網(wǎng)站使用了CDN。
2、響應頭：使用瀏覽器的開發(fā)者工具，查看網(wǎng)站的響應頭信息。如果響應頭中包含類似于"X-Cache"，"X-CDN"或者"Cache-Control"等字段，那么該網(wǎng)站可能使用了CDN。
3、網(wǎng)絡請求路徑：通過瀏覽器的開發(fā)者工具，查看網(wǎng)站請求的靜態(tài)資源(例如圖片、CSS、JavaScript等)的URL路徑。如果路徑中包含類似于"cdn"或者"static"等關(guān)鍵字，那么很有可能該網(wǎng)站使用了CDN。

使用CDN有什么好處？

① 減少網(wǎng)絡延遲：CDN在全球各地建立了分布式的服務器節(jié)點，將網(wǎng)站的內(nèi)容緩存到離用戶最近的節(jié)點。當用戶訪問網(wǎng)站時，CDN會自動將內(nèi)容傳送到最近的服務器節(jié)點，這樣可以減少數(shù)據(jù)在全球范圍內(nèi)傳輸所需的時間，從而減少網(wǎng)絡延遲。
② 節(jié)省帶寬：由于CDN可以緩存網(wǎng)站的內(nèi)容，因此當用戶訪問網(wǎng)站時，CDN會從最近的服務器節(jié)點提供內(nèi)容，而不是從源服務器上提取。這可以減少源服務器的負載，從而節(jié)省帶寬和服務器資源。
③ 提高網(wǎng)站可用性：當源服務器發(fā)生故障或停機時，CDN可以自動將流量重定向到其他可用的服務器節(jié)點，從而確保網(wǎng)站的可用性。

說說你對webworker的理解（了解）

文章文章來源地址http://www.zghlxwxcb.cn/news/detail-803706.html

到了這里，關(guān)于計算機網(wǎng)絡、瀏覽器面試題的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！