整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
雙引號
在js代碼中
在js中單、雙引號引起來的是字符串，如果我們要在字符串中使用單、雙引號，需要反斜杠進行轉義
let str='user\'s name'; // or let str=" user's name"; // or let str="she said:\"...\".";
如果在字符串中輸出反斜杠，仍然是用反斜杠轉義，即2個反斜杠輸出1個反斜杠
在html代碼中
html標簽中，屬性值通常用雙引號引起來，也可以使用單引號或不用引號。
<input name=user /> <input name="user" /> <input name='user' />
這3種寫法都正確，不過通常我們是選擇用雙引號引起來。
如果我們要在屬性值中使用單、雙綽號，我們不能直接寫成下面這樣
<input name=user'name /> <input name="user"name" /> <input name='user'name' />
這些全部是錯誤的。我們要像在js中對單、雙引號轉義一樣，對屬性中的單、雙引號轉義
在html中輸出預留符號，可以使用字符實體轉義的形式，這里有簡單介紹：http://www.w3school.com.cn/html/html_entities.asp。即想輸出一個雙引號可以使用"的形式，
<input name="user"name" />
除此之外，html還支持十進制與十六進制編碼的形式輸出字符，如我們知道字符a的ascii碼的十進制是97 十六進制是61
所以我們在頁面body中輸出一個字符a，有以下3種形式
<body> a<!--直接輸出--> a<!--十進制輸出--> a<!--十六進制輸出--> </body>
同樣，單雙引號也有十進制(單：39，雙：34)與十六進制（單：27，雙：22），所以我們在屬性中輸出一個單引號有2種選擇，十進制與十六進制
<input name='user'name' /><!--十進制--> <input name='user'name' /><!--十六進制-->
而輸出一個雙引號則有3種選擇
<input name="user"name" /><!--實體--> <input name="user"name" /><!--十進制--> <input name="user"name" /><!--十六進制-->
當js代碼遇上實體編碼
我們可以通過dom節點提供的事件寫上調用js的代碼，如點擊body彈出hello這個字符串，我們可以寫成
<body onclick="alert('hello')">
click here
</body>
如果我們的需求是就彈出一個雙引號呢？
根據前述規則，我們要寫成：
<body onclick="alert('"')"><!--這里用十進制或十六進制都可以-->
click here
</body>
當然，alert里的單引號也可以使用十進制或十六進制編碼
<body onclick="alert("'")"><!--"單引號 '雙引號-->
click here
</body>
這樣也是可以的。
是不是有點xss的感覺?
如果我們把彈雙引號的需求改成單引號呢？
<body onclick="alert(''')"><!--這樣html中是合法的，但js中并不合法，因為在js中，中間的單引號并沒有轉義-->
click here
</body>
如果我們用十進制或十六進制編碼呢？
<body onclick="alert('"')"><!--這樣可以嗎-->
click here
</body>
這樣仍然是不可以的
我們要對js字符串中的單引號進行轉義，如
<body onclick="alert('\'')"><!--轉義后可正確彈出-->
click here
</body>
或
<body onclick="alert('\"')"><!--轉義后可正確彈出-->
click here
</body>
前面的onclick="alert('\'')"看起來還正常，后面的這個onclick="alert('\"')"就有點不直觀了。因為后面這個看上去反斜杠像在轉義&這1個字符，而&在js的字符串中并不需要轉義的。
動態輸出
如前述的alert彈出的消息，如果是一個變量控制，動態輸出呢？
<body onclick="alert('${msg}')">
click here
</body>
那我們這個msg字符串就得注意了，從這個示例來看，這個動態的msg即出現在屬性onclick中，也出現在alert的單引號開始的字符串中。
我們要對msg中的雙引號轉成"或"或"，并對msg中單引號的前面加上一個反斜杠\ ?
題外話：對msg中的反斜杠需要做double處理，因為反斜杠在html屬性中并不是特殊的，但在js的字符串中是特殊的。因此正確的做法是對反斜杠及單引號前面各加上一個反斜杠
然而，你并不能保證屬性是用雙引號，alert中的字符串用的是單引號，因為可以寫成下面這樣
<body onclick='alert("${msg}")'>
click here
</body>
?
這種情況我們要對msg中的單引號轉成'或'，并對msg中雙引號前面加上一個反斜杠\
題外話：同上
看上去要根據不同的情況做不同的處理，其實也不需要
我們只需要對單、雙引號前面加上一個反斜杠\然后再對單、雙引號實體編碼即可。
在js中如果反斜杠后面跟的不需要反斜杠轉義的字符，那么這個反斜杠是被丟棄的，因此像
var str="user\'s name";
單引號前面多加一個反斜杠也不要緊的。
自動化處理與識別提醒
在magix項目中，由于magix-combine的支持，可識別出屬性中js代碼的部分，并自動化處理，如
<button mx-click="showName({name:'<%=name%>'})">click here</button>
name這個變量可包含任意的單、雙引號及反斜杠。工具自動識別并處理，開發者不需要做任何事情。
而對于這樣的寫法：
<button mx-click="showName({name:'"'})">click here</button>
<!-- or-->
<button mx-click="showName({name:'\"'})">click here</button>
第一種寫法其實并不正確，但第二種情況看上去又怪怪的。magix-combine工具能識別出來是否需要添加反斜杠，并自動添加處理。
第一種需要添加反斜杠，工具會自動加上，并提醒開發者這里的寫法是不正確的。
第二種說明開發者意識到了問題所在，自己處理了，工具就不再處理也不再提醒開發者。
eb安全是指保護Web應用程序、Web服務器和Web瀏覽器免受各種網絡攻擊和惡意行為的方法和技術。隨著越來越多的業務和活動轉移到互聯網上，Web安全成為越來越重要的問題。
Web安全包括以下方面:
以下以編碼安全、邏輯安全、數據安全展開說明。
本文介紹編碼安全，邏輯安全、數據安全在下一篇文章中介紹。
1. 什么是編碼安全？
安全編碼規范是一種定義編碼要求的標準化方法。它確保代碼是高質量、可重用和安全的。安全編碼規范應該適用于代碼開發、測試和維護的所有階段。
安全編碼規范應該涵蓋以下方面：身份驗證、授權、輸入驗證、輸出編碼、錯誤處理和安全配置管理等。
2. 編碼安全-輸入驗證
任何來自客戶端的數據，如 URL 和參數、HTTP 頭部、Javascript 或其他嵌入代碼提交的信息，都屬于不可信數據。在應用外部邊界或內部每個組件或功能邊界，都將其當做潛在的惡意輸入來校驗。
輸入驗證通常采用以下幾點：
a. 白名單
不可信數據可以設定白名單校驗的，應接受所有和白名單匹配的數據，并阻止其他數據。
b. 黑名單
不可信數據中包含不良輸入字符時，如空字節(%00)、換行符(%0d，%0a)、路徑字符(../或..)等，建議直接阻止該數據，若需要接受該數據，則應做不同方式的凈化處理。
c. 規范化/合法性校正
不可信數據需實施各種凈化處理時，應徹底刪除惡意字符，只留下已知安全的字符，或者在處理前對它們進行適當編碼或“轉義”，如數據輸出到應用頁面時對其進行HTML編碼可防止腳本攻擊、不可信數據的合法性校驗包括:數據類型如字符。數字、日期等特征;數據長度等。
d. 防范SQL注入
不可信數據進入后端數據庫揉作前，建議使用正確的參數化查詢來處理，禁止拼接 SQL 語句，避免出現 SQL 注入。
e. 訪問控制
不可信數據通過上述校驗后，還應確認所提交的內容是否與用戶的身份匹配，避免越權訪問。
3. 編碼安全-輸出驗證：
考慮目標編譯器的安全性，對所有輸出字符進行正確編碼。
輸入驗證通常采用以下幾點
a. 編碼輸出
不可信數據輸出到前后端頁面時，根據輸出場景對其進行相關編碼，如 HTML 實體編碼、UR 編碼。
b. 凈化輸出
針對操作系統命令、SQL 和 LDAP查詢，凈化所有輸出的敏感信息，如銀行卡、手機號、系統信息等
c. 規范輸出
可以采用JSON 格式作為統一的返回值格式這樣方便客戶端和服務器端進行數據交換（包括返回的狀態碼、消息、數據等信息）
4. Sql注入
SQL注入就是在Web表單提交數據/傳輸數據時，將預先準備好的SQL語句添加進去，達到欺騙服務器、修改SQL語句執行結果，非法獲取服務器端數據的目的。
4.1 Sql注入原理
攻擊者猜測Web系統的數據驗證過程，在輸入數據的最后加上一段SQL語句，讓服務器端的SQL執行出現偏差，從而欺騙服務器，甚至可獲取數據庫的管理權限，然后將數據庫管理用戶權限提升至操作系統管理用戶權限，控制服務器操作系統，獲取重要信息及機密文件
4.2 SQL注入流程
?判斷是否存在注入，注入是字符型還是數字型
?猜解SQL查詢語句中的字段數
?確定顯示位置
?獲取當前數據庫
?獲取數據庫中的表
?獲取表中的字段名
?下載數據
4.3 尋找SQL注入點
SQL注入可以出現在任何從系統或用戶接收數據輸入的前端應用程序中，這些應用程序之后被用于訪問數據庫服務器。如果要對一個網站進行SQL注入攻擊，首先就需要找到存在SQL注入漏洞的地方，也就是尋找所謂的注入點。可能的SQL注入點一般存在于登錄頁面、查找頁面或添加頁面等用戶可以查找或修改數據的地方。最常用的尋找SQL注入點的方法，是在網站中尋找如下形式的頁面鏈接：http://www.abc.com/xyz.xxx?id=yy，其中“yy”可能是數字，也有可能是字符串，分別被稱為整數類型數據或者字符型數據。
4.4 Sql注入判斷
a.整型參數的判斷
當輸入的參數YY為整型時，通常xyz.asp中SQL語句原貌大致如下：
select * from表名where字段=YY，所以可以用以下步驟測試SQL注入是否存在。
http://www.abc.com/xyz.xx?p=YY’(附加一個單引號)，此時xyz.asp中的SQL語句變成了select * from表名where字段=YY’，xyz.asp運行異常；
http://www.abc.com/xyz.xx?p=YYand 1=1，xyz.asp運行正常，而且與http://www.abc.com/xyz.xxp?p=YY運行結果相同；
http://www.abc.com/xyz.xx?p=YYand1=2，xyz.asp運行異常；
如果以上三步全面滿足，xyz.asp中一定存在SQL注入漏洞。
b.字符串型參數的判斷
當輸入的參數YY為字符串時，通常xyz.asp中SQL語句原貌大致如下：
select * from表名where字段='YY'，所以可以用以下步驟測試SQL注入是否存在。
http://www.abc.com/xyz.xx?p=YY’(附加一個單引號)，此時xyz.asp中的SQL語句變成了select * from表名where字段=YY’，xyz.asp運行異常；
http://www.abc.com/xyz.xx?p=YY&nb...39;1'='1'，xyz.asp運行正常，而且與http://www.abc.com/xyz.xx?p=YY運行結果相同；
http://www.abc.com/xyz.xx?p=YY&nb...39;1'='2'，xyz.asp運行異常；
如果以上三步全面滿足，xyz.asp中一定存在SQL注入漏洞
c.特殊情況的處理
有時程序員會在程序員過濾掉單引號等字符，以防止SQL注入。此時可以用以下幾種方法試一試。
大小寫混合法：某些語言并不區分大小寫(如asp)，此時可將SQL語句中的命令字進行大小寫混合來規避過濾技術，如用wHeRe代替where等。
ASCII碼法：將輸入內容的部分或全部字符使用ASCII碼來代替，這樣也有可能規避過濾技術，如A=chr(65)，a=chr(97)等
d.Sql注入示例
5. XSS攻擊
5.1 什么是XSS攻擊
XSS攻擊又稱為跨站腳本，XSS的重點不在于跨站點，而是在于腳本的執行。XSS是一種經常出現在Web應用程序中的計算機安全漏洞，是由于Web應用程序對用戶的輸入過濾不足而產生的，它允許惡意web用戶將代碼植入到提供給其它用戶使用的頁面中。
5.2 XSS漏洞的危害
a.竊取管理員帳號或Cookie。入侵者可以冒充管理員的身份登錄后臺，使得入侵者具有惡意操縱后臺數據的能力，包括讀取、更改、添加、刪除一些信息。
b.竊取用戶的個人信息或者登錄帳號。對網站的用戶安全產生巨大的威脅。例如冒充用戶身份進行各種操作。
c.網站掛馬。先將惡意攻擊代碼嵌入到Web應用程序之中。當用戶瀏覽該掛馬頁面時，用戶的計算機會被植入木馬。
d.發送廣告或者垃圾信息。攻擊者可以利用XSS漏洞植入廣告，或者發送垃圾信息，嚴重影響到用戶的正常使用。
5.3 Xss漏洞分類
a.反射型XSS
反射型XSS，也稱為非持久性XSS，是最常見的一種XSS。
XSS代碼常常出現在URL請求中，當用戶訪問帶有XSS代碼的URL請求時，服務器端接收請求并處理，然后將帶有XSS代碼的數據返回給瀏覽器，瀏覽器解析該段帶有XSS代碼的數據并執行，整個過程就像一次反射，故稱為反射型XSS。
該類攻擊的主要特點是它的及時性和一次性，即用戶提交請求后，響應信息會立即反饋給用戶。該類攻擊常發生在搜索引擎、錯誤提示頁面等對用戶的輸入做出直接反應的場景中。
b.存儲型XSS
存儲型XSS，也稱為持久性XSS。
在存儲型XSS中，XSS代碼被存儲到服務器端，因此允許用戶存儲數據到服務器端的Web應用程序可能存在該類型XSS漏洞。攻擊者提交一段XSS代碼后，服務器接收并存儲，當其他用戶訪問包含該XSS代碼的頁面時，XSS代碼被瀏覽器解析并執行。
存儲型XSS攻擊的特點之一是提交的惡意內容會被永久存儲，因而一個單獨的惡意代碼就會使多個用戶受害，故被稱為持久性XSS，它也是跨站腳本攻擊中最危險的一類。二是被存儲的用戶提交的惡意內容不一定被頁面使用，因此存在危險的響應信息不一定被立即返回，也許在訪問那些在時間上和空間上沒有直接關聯的頁面時才會引發攻擊，因此存在不確定性和更好的隱蔽性。
這類攻擊的一個典型場景是留言板、博客和論壇等，當惡意用戶在某論壇頁面發布含有惡意的Javascript代碼的留言時，論壇會將該用戶的留言內容保存在數據庫或文件中并作為頁面內容的一部分顯示出來。當其他用戶查看該惡意用戶的留言時，惡意用戶提交的惡意代碼就會在用戶瀏覽器中解析并執行。
c.DOM型XSS
DOM (Document Objet Model)指文檔對象模型。
DOM常用來表示在HTML和XML中的對象。DOM可以允許程序動態的訪問和更新文檔的內容、結構等。客戶端JavaScript可以訪問瀏覽器的文檔對象模型。也就是說，通過JavaScript代碼控制DOM節點就可以不經過服務器端的參與重構HTML頁面。
該類攻擊是反射型XSS的變種。它通常是由于客戶端接收到的腳本代碼存在邏輯錯誤或者使用不當導致的。比如Javascript代碼不正確地使用各種DOM方法(如document.write)和Javascript內部函數(如eval函數)，動態拼接HTML代碼和腳本代碼就容易引發DOM型的跨站腳本攻擊。
因此，DOM型XSS與前面兩種XSS的區別就在于DOM型XSS攻擊的代碼不需要與服務器端進行交互，DOM型XSS的觸發基于瀏覽器端對DOM數據的解析來完成，也就是完全是客戶端的事情。
5.4 Xss漏洞分類判斷
如何判斷是哪一種XSS， 發送一次帶XSS代碼的請求，若只能在當前返回的數據包里發現XSS代碼，則是反射型；若以后這個頁面的返回包里都會有XSS代碼，則是存儲型；若在返回包里找不到XSS代碼，則是DOM型。
5.5 XSS漏洞的檢測與防御
a.手工檢測
手工檢測重點要考慮數據輸入的地方，且需要清楚輸入的數據輸出到什么地方。
在檢測的開始，可以輸入一些敏感字符，比如“<、>、（）”等，提交后查看網頁源代碼的變化以發現輸入被輸出到什么地方，且可以發現相關敏感字符是否被過濾。
手工檢測結果相對準確，但效率較低。
b.工具檢測
常用工具有AVWS（Acunetix Web Vulnerability Scanner）、BurpSuite等。還有一些專門針對XSS漏洞的檢測工具，如：XSSer、XSSF（跨站腳本攻擊框架）、BeEF(The Browser Exploitation Framework)等
c.防御
使用黑名單進行：
●對HTML標簽或特殊字符進行過濾
●使用內容安全的CSP
●使用設計上就會自動編碼的框架，如：OWASP ESAPI、React JS、JSOUP等，對于JAVA而言，可以使用ESAPI.encoder().encodeForHTML()對字符串進行HTML編碼。
●對于反射型和存儲型XSS，可以在數據返回給客戶端瀏覽器時，將敏感字符進行轉義，如：將單引號進行編碼替換（十進制編碼'、十六進制編碼'、HTML編碼&apos、Unicode編碼\u0027等）。
●對于DOM型XSS，可以使用上下文敏感數據編碼。如：在PHP中的htmlspecialchars（）、htmlentities（）函 數可以將一些預定義的字符轉換為HTML實體，如：小于轉化為<、大于轉化為>、雙引號轉化為"、單引號轉化為&apos、轉化為&等。
●啟用瀏覽器的HttpOnly特性可以組織客戶端腳本訪問cookie。如：在PHP中可以通過下面的代碼設置cookie并啟用HttpOnly。
案例1：某app搜索接口越權獲取敏感信息
cloud/search/group/userstaff_id 可枚舉，通過遍歷將任意的用戶拉入群聊，直接獲取大量員工的個人敏感信息，涉及組織機構、手機號
案例2：“某某查”付費資源泄露
5. 文件管理-上傳/下載
5.1 文件上傳
a. 身份校驗
進行文件上傳時，在服務端對用戶的身份進行合法性校驗。
b. 文件類型限制
須在服務器端采用白名單方式對上傳或下載的文件類型、大小進行嚴格的限制。僅允許業務所需文件類型上傳，避免上傳.jsp、.jspx、.class、.java 等可執行文件
c.禁止外部文件存儲于可執行目錄
禁止外部文件存儲于 WEB 容器的可執行目錄。建議保存在專門的文件服務器中。
d.隱藏文件路徑
進行文件保存時，成功上傳的文件需要進行隨機化重命名，禁止給客戶端返回保存的路徑信息。
5.2 文件下載
a.身份校驗
進行文件下載時，在服務端對用戶的身份進行合法性校驗。
b.文件訪問設置
進行文件下載時，應以二進制形式下載，建議不提供直接訪問(防止木馬文件)。
c.目錄跳轉
禁止客戶端自定義文件下載路徑(如:使用../../../../../或..%2F..%2F..%2F..%2F 進行跳轉)
下一篇更新邏輯安全和數據安全，敬請期待！
參考答案：
TCP 協議通過三次握手建立可靠的點對點連接，具體過程是：
首先服務器進入監聽狀態，然后即可處理連接
第一次握手：建立連接時，客戶端發送 syn 包到服務器，并進入 SYN_SENT 狀態，等待服務器確認。在發送的包中還會包含一個初始序列號 seq。此次握手的含義是客戶端希望與服務器建立連接。
第二次握手：服務器收到 syn 包，然后回應給客戶端一個 SYN+ACK 包，此時服務器進入 SYN_RCVD 狀態。此次握手的含義是服務端回應客戶端，表示已收到并同意客戶端的連接請求。
第三次握手：客戶端收到服務器的 SYN 包后，向服務器再次發送 ACK 包，并進入 ESTAB_LISHED 狀態。
最后，服務端收到客戶端的 ACK 包，于是也進入 ESTAB_LISHED 狀態，至此，連接建立完成
參考答案：
針對 HTTPS 攻擊主要有 SSL 劫持攻擊和 SSL 剝離攻擊兩種。
SSL 劫持攻擊是指攻擊者劫持了客戶端和服務器之間的連接，將服務器的合法證書替換為偽造的證書，從而獲取客戶端和服務器之間傳遞的信息。這種方式一般容易被用戶發現，瀏覽器會明確的提示證書錯誤，但某些用戶安全意識不強，可能會點擊繼續瀏覽，從而達到攻擊目的。
SSL 剝離攻擊是指攻擊者劫持了客戶端和服務器之間的連接，攻擊者保持自己和服務器之間的 HTTPS 連接，但發送給客戶端普通的 HTTP 連接，由于 HTTP 連接是明文傳輸的，即可獲取客戶端傳輸的所有明文數據。
參考答案：
首先說 http1.0
它的特點是每次請求和響應完畢后都會銷毀 TCP 連接，同時規定前一個響應完成后才能發送下一個請求。這樣做有兩個問題：
無法復用連接
每次請求都要創建新的 TCP 連接，完成三次握手和四次揮手，網絡利用率低
隊頭阻塞
如果前一個請求被某種原因阻塞了，會導致后續請求無法發送。
然后是 http1.1
http1.1 是 http1.0 的改進版，它做出了以下改進：
長連接
http1.1 允許在請求時增加請求頭connection:keep-alive，這樣便允許后續的客戶端請求在一段時間內復用之前的 TCP 連接
管道化
基于長連接的基礎，管道化可以不等第一個請求響應繼續發送后面的請求，但響應的順序還是按照請求的順序返回。
緩存處理
新增響應頭 cache-control，用于實現客戶端緩存。
斷點傳輸
在上傳/下載資源時，如果資源過大，將其分割為多個部分，分別上傳/下載，如果遇到網絡故障，可以從已經上傳/下載好的地方繼續請求，不用從頭開始，提高效率
最后是 http2.0
http2.0 進一步優化了傳輸效率，它主要有以下改進：
二進制分幀
將傳輸的消息分為更小的二進制幀，每幀有自己的標識序號，即便被隨意打亂也能在另一端正確組裝
多路復用
基于二進制分幀，在同一域名下所有訪問都是從同一個 tcp 連接中走，并且不再有隊頭阻塞問題，也無須遵守響應順序
頭部壓縮
http2.0 通過字典的形式，將頭部中的常見信息替換為更少的字符，極大的減少了頭部的數據量，從而實現更小的傳輸量
服務器推
http2.0 允許服務器直接推送消息給客戶端，無須客戶端明確的請求
參考答案：
HTTP/1.1 不是二進制傳輸，而是通過文本進行傳輸。由于沒有流的概念，在使用并行傳輸（多路復用）傳遞數據時，接收端在接收到響應后，并不能區分多個響應分別對應的請求，所以無法將多個響應的結果重新進行組裝，也就實現不了多路復用。
參考答案：
在 HTTP/2 中，有兩個非常重要的概念，分別是幀（frame）和流（stream）。 幀代表著最小的數據單位，每個幀會標識出該幀屬于哪個流，流也就是多個幀組成的數據流。 多路復用，就是在一個 TCP 連接中可以存在多條流。換句話說，也就是可以發送多個請求，對端可以通過幀中的標識知道屬于哪個請求。通過這個技術，可以避免 HTTP 舊版本中的隊頭阻塞問題，極大的提高傳輸性能。
TCP 協議通過三次握手建立可靠的點對點連接，具體過程是：
首先服務器進入監聽狀態，然后即可處理連接
第一次握手：建立連接時，客戶端發送 syn 包到服務器，并進入 SYN_SENT 狀態，等待服務器確認。在發送的包中還會包含一個初始序列號 seq。此次握手的含義是客戶端希望與服務器建立連接。
第二次握手：服務器收到 syn 包，然后回應給客戶端一個 SYN+ACK 包，此時服務器進入 SYN_RCVD 狀態。此次握手的含義是服務端回應客戶端，表示已收到并同意客戶端的連接請求。
第三次握手：客戶端收到服務器的 SYN 包后，向服務器再次發送 ACK 包，并進入 ESTAB_LISHED 狀態。
最后，服務端收到客戶端的 ACK 包，于是也進入 ESTAB_LISHED 狀態，至此，連接建立完成
當需要關閉連接時，需要進行四次揮手才能關閉
Client 向 Server 發送 FIN 包，表示 Client 主動要關閉連接，然后進入 FIN_WAIT_1 狀態，等待 Server 返回 ACK 包。此后 Client 不能再向 Server 發送數據，但能讀取數據。 Server 收到 FIN 包后向 Client 發送 ACK 包，然后進入 CLOSE_WAIT 狀態，此后 Server 不能再讀取數據，但可以繼續向 Client 發送數據。 Client 收到 Server 返回的 ACK 包后進入 FIN_WAIT_2 狀態，等待 Server 發送 FIN 包。 Server 完成數據的發送后，將 FIN 包發送給 Client，然后進入 LAST_ACK 狀態，等待 Client 返回 ACK 包，此后 Server 既不能讀取數據，也不能發送數據。 Client 收到 FIN 包后向 Server 發送 ACK 包，然后進入 TIME_WAIT 狀態，接著等待足夠長的時間（2MSL）以確保 Server 接收到 ACK 包，最后回到 CLOSED 狀態，釋放網絡資源。 Server 收到 Client 返回的 ACK 包后便回到 CLOSED 狀態，釋放網絡資源。
參考答案：
客戶端請求服務器，并告訴服務器自身支持的加密算法以及密鑰長度等信息 服務器響應公鑰和服務器證書 客戶端驗證證書是否合法，然后生成一個會話密鑰，并用服務器的公鑰加密密鑰，把加密的結果通過請求發送給服務器 服務器使用私鑰解密被加密的會話密鑰并保存起來，然后使用會話密鑰加密消息響應給客戶端，表示自己已經準備就緒 客戶端使用會話密鑰解密消息，知道了服務器已經準備就緒。 后續客戶端和服務器使用會話密鑰加密信息傳遞消息
參考答案：
校驗證書的頒發機構是否受客戶端信任。 通過 CRL 或 OCSP 的方式校驗證書是否被吊銷。 對比系統時間，校驗證書是否在有效期內。 通過校驗對方是否存在證書的私鑰，判斷證書的網站域名是否與證書頒發的域名一致。
參考答案：
301 表示永久重定向，302 表示臨時重定向。
如果瀏覽器收到的是 301，則會緩存重定向的地址，之后不會再重新請求服務器，直接使用緩存的地址請求，這樣可以減少請求次數。但如果瀏覽器收到的是 302，則不會緩存重定向地址，瀏覽器將來會繼續以原有地址請求。
因此，301 適合地址永久轉移的場景，比如域名變更；而 302 適合臨時轉移的場景，比如首頁臨時跳轉到活動頁
參考答案：
由于瀏覽器會自動發送 cookie 到服務器，因此攻擊者可以利用這種特點進行 csrf 攻擊。
而通常 token 是不放到 cookie 中的，需要瀏覽器端使用 JS 自行保存到 localstorage 中，在請求時也需要手動的加入到請求頭中，因此不容易引發 csrf 攻擊。
參考答案：
以最常見的 token 格式 jwt 為例, token 分為三段，分別是 header、payload、signature。 其中，header 標識簽名算法和令牌類型；payload 標識主體信息，包含令牌過期時間、發布時間、發行者、主體內容等；signature 是使用特定的算法對前面兩部分進行加密，得到的加密結果。
token 有防篡改的特點，如果攻擊者改動了前面兩個部分，就會導致和第三部分對應不上，使得 token 失效。而攻擊者不知道加密秘鑰，因此又無法修改第三部分的值。
所以，在秘鑰不被泄露的前提下，一個驗證通過的 token 是值得被信任的。
參考答案：
SSO 一般都需要一個獨立的認證中心（passport），子系統的登錄均得通過 passport，子系統本身將不參與登錄操作，當一個系統成功登錄以后，passport 將會頒發一個令牌給各個子系統，子系統可以拿著令牌會獲取各自的受保護資源，為了減少頻繁認證，各個子系統在被 passport 授權以后，會建立一個局部會話，在一定時間內可以無需再次向 passport 發起認證。
具體流程是：
用戶訪問系統 1 的受保護資源，系統 1 發現用戶未登錄，跳轉至 sso 認證中心，并將自己的地址作為參數 sso 認證中心發現用戶未登錄，將用戶引導至登錄頁面 用戶輸入用戶名密碼提交登錄申請 sso 認證中心校驗用戶信息，創建用戶與 sso 認證中心之間的會話，稱為全局會話，同時創建授權令牌 sso 認證中心帶著令牌跳轉會最初的請求地址（系統 1） 系統 1 拿到令牌，去 sso 認證中心校驗令牌是否有效 sso 認證中心校驗令牌，返回有效，注冊系統 1 系統 1 使用該令牌創建與用戶的會話，稱為局部會話，返回受保護資源 用戶訪問系統 2 的受保護資源 系統 2 發現用戶未登錄，跳轉至 sso 認證中心，并將自己的地址作為參數 sso 認證中心發現用戶已登錄，跳轉回系統 2 的地址，并附上令牌 系統 2 拿到令牌，去 sso 認證中心校驗令牌是否有效 sso 認證中心校驗令牌，返回有效，注冊系統 2 系統 2 使用該令牌創建與用戶的局部會話，返回受保護資源
參考答案：
客戶端請求服務器時，通過請求行告訴服務器使用的協議是 http1.1，同時在請求頭中附帶connection:keep-alive（為保持兼容），告訴服務器這是一個長連接，后續請求可以重復使用這一次的 TCP 連接。
這樣做的好處是減少了三次握手和四次揮手的次數，一定程度上提升了網絡利用率。但由于 http1.1 不支持多路復用，響應順序必須按照請求順序抵達客戶端，不能真正實現并行傳輸，因此在 http2.0 出現之前，實際項目中往往把靜態資源，比如圖片，分發到不同域名下的資源服務器，以便實現真正的并行傳輸。
參考答案：
客戶端將文件的二進制內容進行分片，每片數據按順序進行序號標識，上傳每片數據時同時附帶其序號。服務器接收到每片數據時，將其保存成一個臨時文件，并記錄每個文件的 hash 和序號。
若上傳中止，將來再次上傳時，可以向服務器索要已上傳的分片序號，客戶端僅需上傳剩余分片即可。
當全部分片上傳完成后，服務器按照分片的順序組裝成完整的文件，并刪除分片文件。
參考答案：
它們都是用于保證傳輸安全的協議，介于傳輸層和應用層之間，TLS 是 SSL 的升級版。
它們的基本流程一致：
客戶端向服務器端索要公鑰，并使用數字證書驗證公鑰。 客戶端使用公鑰加密會話密鑰，服務端用私鑰解密會話密鑰，于是得到一個雙方都認可的會話密鑰 傳輸的數據使用會話密鑰加密，然后再傳輸，接收消息方使用會話密鑰解密得到原始數據
參考答案：
從上到下分別為：應用層、傳輸層、網絡層、數據鏈路層、物理層。在發送消息時，消息從上到下進行打包，每一層會在上一層基礎上加包，而接受消息時，從下到上進行解包，最終得到原始信息。
其中：
應用層主要面向互聯網中的應用場景，比如網頁、郵件、文件中心等等，它的代表協議有 http、smtp、pop3、ftp、DNS 等等
傳輸層主要面向傳輸過程，比如 TCP 協議是為了保證可靠的傳輸，而 UDP 協議則是一種無連接的廣播，它們提供了不同的傳輸方式
網絡層主要解決如何定位目標的問題，比如 IP、ICMP、ARP 等等
數據鏈路層的作用是將數據可靠的傳輸到目標，比如常見的以太網協議、P2P 協議
物理層是要規范網絡兩端使用的物理設備，比如藍牙、wifi、光纖、網線接頭等等
參考答案：
從 http 協議的角度來說，GET 和 POST 它們都只是請求行中的第一個單詞，除了語義不同，其實沒有本質的區別。
之所以在實際開發中會產生各種區別，主要是因為瀏覽器的默認行為造成的。
受瀏覽器的影響，在實際開發中，GET 和 POST 有以下區別：
瀏覽器在發送 GET 請求時，不會附帶請求體 GET 請求的傳遞信息量有限，適合傳遞少量數據；POST 請求的傳遞信息量是沒有限制的，適合傳輸大量數據。 GET 請求只能傳遞 ASCII 數據，遇到非 ASCII 數據需要進行編碼；POST 請求沒有限制 大部分 GET 請求傳遞的數據都附帶在 path 參數中，能夠通過分享地址完整的重現頁面，但同時也暴露了數據，若有敏感數據傳遞，不應該使用 GET 請求，至少不應該放到 path 中 刷新頁面時，若當前的頁面是通過 POST 請求得到的，則瀏覽器會提示用戶是否重新提交。若是 GET 請求得到的頁面則沒有提示。 GET 請求的地址可以被保存為瀏覽器書簽，POST 不可以
參考答案：
是指攻擊者在客戶端和服務器之間同時建立了連接通道，通過某種方式，讓客戶端請求發送到自己的服務器，然后自己就擁有了控制響應內容的能力，從而給客戶端展示錯誤的信息。
參考答案：
http 劫持是指攻擊者在客戶端和服務器之間同時建立了連接通道，通過某種方式，讓客戶端請求發送到自己的服務器，然后自己就擁有了控制響應內容的能力，從而給客戶端展示錯誤的信息，比如在頁面中加入一些廣告內容。
DNS 劫持是指攻擊者劫持了 DNS 服務器，獲得了修改 DNS 解析記錄的權限，從而導致客戶端請求的域名被解析到了錯誤的 IP 地址，攻擊者通過這種方式竊取用戶資料或破壞原有正常服務。
XSS 是指跨站腳本攻擊。攻擊者利用站點的漏洞，在表單提交時，在表單內容中加入一些惡意腳本，當其他正常用戶瀏覽頁面，而頁面中剛好出現攻擊者的惡意腳本時，腳本被執行，從而使得頁面遭到破壞，或者用戶信息被竊取。
要防范 XSS 攻擊，需要在服務器端過濾腳本代碼，將一些危險的元素和屬性去掉或對元素進行HTML實體編碼。
參考答案：
XSS：
XSS 是指跨站腳本攻擊。攻擊者利用站點的漏洞，在表單提交時，在表單內容中加入一些惡意腳本，當其他正常用戶瀏覽頁面，而頁面中剛好出現攻擊者的惡意腳本時，腳本被執行，從而使得頁面遭到破壞，或者用戶信息被竊取。
要防范 XSS 攻擊，需要在服務器端過濾腳本代碼，將一些危險的元素和屬性去掉或對元素進行HTML實體編碼。
CSRF：
CSRF 是跨站請求偽造，是一種挾制用戶在當前已登錄的Web應用上執行非本意的操作的攻擊方法
它首先引導用戶訪問一個危險網站，當用戶訪問網站后，網站會發送請求到被攻擊的站點，這次請求會攜帶用戶的cookie發送，因此就利用了用戶的身份信息完成攻擊。
防御 CSRF 攻擊有多種手段：
不使用cookie 為表單添加校驗的 token 校驗 cookie中使用sameSite字段 服務器檢查 referer 字段
參考答案：
客戶端請求服務器，并告訴服務器自身支持的加密算法以及密鑰長度等信息 服務器響應公鑰和服務器證書 客戶端驗證證書是否合法，然后生成一個會話密鑰，并用服務器的公鑰加密密鑰，把加密的結果通過請求發送給服務器 服務器使用私鑰解密被加密的會話密鑰并保存起來，然后使用會話密鑰加密消息響應給客戶端，表示自己已經準備就緒 客戶端使用會話密鑰解密消息，知道了服務器已經準備就緒。 后續客戶端和服務器使用會話密鑰加密信息傳遞消息
參考答案：
主要是為了解決證書的可信問題。如果沒有權威機構對證書進行簽名，客戶端就無法知曉證書是否是偽造的，從而增加了中間人攻擊的風險，https 就變得毫無意義。
參考答案：
密鑰
密鑰是一種參數，它是在明文轉換為密文或將密文轉換為明文的算法中輸入的參數。密鑰分為對稱密鑰與非對稱密鑰，分別應用在對稱加密和非對稱加密上。
對稱加密
對稱加密又叫做私鑰加密，即信息的發送方和接收方使用同一個密鑰去加密和解密數據。對稱加密的特點是算法公開、加密和解密速度快，適合于對大數據量進行加密，常見的對稱加密算法有 DES、3DES、TDEA、Blowfish、RC5 和 IDEA。
非對稱加密
非對稱加密也叫做公鑰加密。非對稱加密與對稱加密相比，其安全性更好。對稱加密的通信雙方使用相同的密鑰，如果一方的密鑰遭泄露，那么整個通信就會被破解。而非對稱加密使用一對密鑰，即公鑰和私鑰，且二者成對出現。私鑰被自己保存，不能對外泄露。公鑰指的是公共的密鑰，任何人都可以獲得該密鑰。用公鑰或私鑰中的任何一個進行加密，用另一個進行解密。
摘要
摘要算法又稱哈希/散列算法。它通過一個函數，把任意長度的數據轉換為一個長度固定的數據串（通常用 16 進制的字符串表示）。算法不可逆。
參考答案：
websocket 協議 HTML5 帶來的新協議，相對于 http，它是一個持久連接的協議，它利用 http 協議完成握手，然后通過 TCP 連接通道發送消息，使用 websocket 協議可以實現服務器主動推送消息。
首先，客戶端若要發起 websocket 連接，首先必須向服務器發送 http 請求以完成握手，請求行中的 path 需要使用ws:開頭的地址，請求頭中要分別加入upgrade、connection、Sec-WebSocket-Key、Sec-WebSocket-Version標記
然后，服務器收到請求后，發現這是一個 websocket 協議的握手請求，于是響應行中包含Switching Protocols，同時響應頭中包含upgrade、connection、Sec-WebSocket-Accept標記
當客戶端收到響應后即可完成握手，隨后使用建立的 TCP 連接直接發送和接收消息。
參考答案：
當頁面中需要觀察實時數據的變化（比如聊天、k 線圖）時，過去我們往往使用兩種方式完成:
第一種是短輪詢，即客戶端每隔一段時間就向服務器發送消息，詢問有沒有新的數據
第二種是長輪詢，發起一次請求詢問服務器，服務器可以將該請求掛起，等到有新消息時再進行響應。響應后，客戶端立即又發起一次請求，重復整個流程。
無論是哪一種方式，都暴露了 http 協議的弱點，即響應必須在請求之后發生，服務器是被動的，無法主動推送消息。而讓客戶端不斷的發起請求又白白的占用了資源。
websocket 的出現就是為了解決這個問題，它利用 http 協議完成握手之后，就可以與服務器建立持久的連接，服務器可以在任何需要的時候，主動推送消息給客戶端，這樣占用的資源最少，同時實時性也最高。
參考答案：
https 有防篡改的特點，只要瀏覽器證書驗證過程是正確的，很難在用戶不察覺的情況下進行攻擊。但若能夠更改瀏覽器的證書驗證過程，便有機會實現 https 中間人攻擊。
所以，要劫持 https，首先要偽造一個證書，并且要想辦法讓用戶信任這個證書，可以有多種方式，比如病毒、惡意軟件、誘導等。一旦證書被信任后，就可以利用普通中間人攻擊的方式，使用偽造的證書進行攻擊。
參考答案：
使用 JSONP
這是一種古老的解決跨域問題的思路。在需要跨域請求時，事先準備好一個處理服務器數據的函數，然后生成一個script元素，src指向跨域站點，同時把準備好的函數名通過地址參數傳遞到服務器。
跨域站點返回一段調用該函數的腳本，當客戶端接收到腳本后就會運行事先準備的函數，從而實現跨域獲取數據。
JSONP 實現簡單、兼容性好，但缺點也很明顯，它只支持 get 請求，同時也有安全性問題，并且對服務器端代碼侵入性比較強。
使用 cors
在請求時，客戶端使用一些特殊的請求頭向服務器申請跨域訪問，并通過這些請求頭告訴服務器自己的行為。服務器根據自身的規則決定是否允許跨域，如果允許，則通過響應頭告訴客戶端可以發送跨域請求。
cors 協議已被各種主流瀏覽器支持，它安全性高，同時也不會侵入服務器代碼，是目前最主流的跨域方式
除此之外，遠古時期的跨域處理還包括 iframe、form 等，由于它們缺陷非常明顯，故很少使用了。
參考答案：
短輪詢。即客戶端每隔一段時間就向服務器發送消息，詢問有沒有新的數據 長輪詢，發起一次請求詢問服務器，服務器可以將該請求掛起，等到有新消息時再進行響應。響應后，客戶端立即又發起一次請求，重復整個流程。 websocket，握手完畢后會建立持久性的連接通道，隨后服務器可以在任何時候推送新消息給客戶端
參考答案：
301 永久重定向，瀏覽器會把重定向后的地址緩存起來，將來用戶再次訪問原始地址時，直接引導用戶訪問新地址
302 臨時重定向，瀏覽器會引導用戶進入新地址，但不會緩存原始地址，下一次用戶訪問源地址時，瀏覽器仍然要請求原地址的服務器
304 資源未修改，服務器通過該狀態碼告訴客戶端，請求的資源和過去一樣，并沒有任何變化，建議自行使用過去的緩存。通常，304 狀態碼的響應中，服務器不會附帶任何的響應體。
403 不允許訪問。服務器通過該狀態碼告訴客戶端，這個資源目前不允許訪問。這種狀態碼通常出現在權限不足的情況下。
參考答案：
瀏覽器自動補全協議、端口 瀏覽器自動完成url編碼 瀏覽器根據url地址查找本地緩存，根據緩存規則看是否命中緩存，若命中緩存則直接使用緩存，不再發出請求 通過DNS解析找到服務器的IP地址 瀏覽器向服務器發出建立TCP連接的申請，完成三次握手后，連接通道建立 若使用了HTTPS協議，則還會進行SSL握手，建立加密信道。使用SSL握手時，會確定是否使用HTTP2 瀏覽器決定要附帶哪些cookie到請求頭中 瀏覽器自動設置好請求頭、協議版本、cookie，發出GET請求 服務器處理請求，進入后端處理流程。完成處理后，服務器響應一個HTTP報文給瀏覽器。 瀏覽器根據使用的協議版本，以及Connection字段的約定，決定是否要保留TCP連接。 瀏覽器根據響應狀態碼決定如何處理這一次響應 瀏覽器根據響應頭中的Content-Type字段識別響應類型，如果是text/html，則對響應體的內容進行HTML解析，否則做其他處理 瀏覽器根據響應頭的其他內容完成緩存、cookie的設置 瀏覽器開始從上到下解析HTML，若遇到外部資源鏈接，則進一步請求資源 解析過程中生成DOM樹、CSSOM樹，然后一邊生成，一邊把二者合并為渲染樹（rendering tree），隨后對渲染樹中的每個節點計算位置和大小（reflow），最后把每個節點利用GPU繪制到屏幕（repaint） 在解析過程中還會觸發一系列的事件，當DOM樹完成后會觸發DOMContentLoaded事件，當所有資源加載完畢后會觸發load事件
參考答案：
客戶端請求服務器，并告訴服務器自身支持的加密算法以及密鑰長度等信息 服務器響應公鑰和服務器證書 客戶端驗證證書是否合法，然后生成一個會話密鑰，并用服務器的公鑰加密密鑰，把加密的結果通過請求發送給服務器 服務器使用私鑰解密被加密的會話密鑰并保存起來，然后使用會話密鑰加密消息響應給客戶端，表示自己已經準備就緒 客戶端使用會話密鑰解密消息，知道了服務器已經準備就緒。 后續客戶端和服務器使用會話密鑰加密信息傳遞消息
參考答案：
驗證碼主要用于讓服務器區分請求是人還是機器發送的。這樣做是為了避免某些程序惡意的提交大量信息到服務器，進而導致服務器產生大量的垃圾數據。有時，驗證碼也可以防止機器暴力破解用戶密碼，它通過在短時間內不斷提交登錄信息，嘗試各種密碼組合來達到破解的目的。
參考答案：
http1.0
每次請求和響應完畢后都會銷毀 TCP 連接，同時規定前一個響應完成后才能發送下一個請求。這樣做有兩個問題：
無法復用連接
每次請求都要創建新的 TCP 連接，完成三次握手和四次揮手，網絡利用率低
隊頭阻塞
如果前一個請求被某種原因阻塞了，會導致后續請求無法發送。
http2.0
http2.0 優化了傳輸效率，它主要有以下改進：
二進制分幀
將傳輸的消息分為更小的二進制幀，每幀有自己的標識序號，即便被隨意打亂也能在另一端正確組裝
多路復用
基于二進制分幀，在同一域名下所有訪問都是從同一個 tcp 連接中走，并且不再有隊頭阻塞問題，也無須遵守響應順序
頭部壓縮
http2.0 通過字典的形式，將頭部中的常見信息替換為更少的字符，極大的減少了頭部的數據量，從而實現更小的傳輸量
服務器推
http2.0 允許服務器直接推送消息給客戶端，無須客戶端明確的請求
http3.0
http3.0 它完全拋棄了 TCP 協議，轉而使用 UDP 協議，是為了進一步提升性能。 雖然 http2.0 進行了大量的優化，但它無法擺脫 TCP 協議本身的問題，比如建立連接時間長、對頭阻塞問題等等。為了保證傳輸的可靠性，http3.0 使用了 QUIC 協議。
參考答案：
cookie、sessionStorage、localStorage 都是保存本地數據的方式
其中，cookie 兼容性較好，所有瀏覽器均支持。瀏覽器針對 cookie 會有一些默認行為，比如當響應頭中出現set-cookie字段時，瀏覽器會自動保存 cookie 的值；再比如，瀏覽器發送請求時，會附帶匹配的 cookie 到請求頭中。這些默認行為，使得 cookie 長期以來擔任著維持登錄狀態的責任。與此同時，也正是因為瀏覽器的默認行為，給了惡意攻擊者可乘之機，CSRF 攻擊就是一個典型的利用 cookie 的攻擊方式。雖然 cookie 不斷的改進，但前端仍然需要另一種更加安全的保存數據的方式。
HTML5 新增了 sessionStorage 和 localStorage，前者用于保存會話級別的數據，后者用于更持久的保存數據。瀏覽器針對它們沒有任何默認行為，這樣一來，就把保存數據、讀取數據的工作交給了前端開發者，這就讓惡意攻擊者難以針對登錄狀態進行攻擊。
cookie 的大小是有限制的，一般瀏覽器會限制同一個域下的 cookie 總量為 4M，而 sessionStorage 和 localStorage 則沒有限制
cookie 會與 domain、path 關聯，而 sessionStorage 和 localStorage 只與 domain 關聯
參考答案：
form data 適合傳遞簡單的鍵值對信息，由于傳遞的信息比較扁平，難以傳遞深層次嵌套的數據
request payload 適合傳遞任意格式的數據，包括單個數字、布爾、深層次嵌套的對象、數組等，但 request payload 不適合傳遞文件數據
在前后端分離的項目中，對于非文件數據的傳遞，都推薦使用 request payload 的形式，以傳遞最明確的數據類型和數據結構，而對于文件上傳，則推薦使用傳統的 form data
參考答案：
GET，表示向服務器獲取資源 POST，表示向服務器提交信息，通常用于產生新的數據，比如注冊 PUT，表示希望修改服務器的數據，通常用于修改 DELETE，表示希望刪除服務器的數據 OPTIONS，發生在跨域的預檢請求中，表示客戶端向服務器申請跨域提交 TRACE，回顯服務器收到的請求，主要用于測試和診斷 CONNECT，用于建立連接管道，通常在代理場景中使用，網頁中很少用到
參考答案：
優化打包體積
利用一些工具壓縮、混淆最終打包代碼，減少包體積
多目標打包
利用一些打包插件，針對不同的瀏覽器打包出不同的兼容性版本，這樣一來，每個版本中的兼容性代碼就會大大減少，從而減少包體積
壓縮
現代瀏覽器普遍支持壓縮格式，因此服務端的各種文件可以壓縮后再響應給客戶端，只要解壓時間小于優化的傳輸時間，壓縮就是可行的
CDN
利用 CDN 可以大幅縮減靜態資源的訪問時間，特別是對于公共庫的訪問，可以使用知名的 CDN 資源，這樣可以實現跨越站點的緩存
緩存
對于除 HTML 外的所有靜態資源均可以開啟協商緩存，利用構建工具打包產生的文件 hash 值來置換緩存
http2
開啟 http2 后，利用其多路復用、頭部壓縮等特點，充分利用帶寬傳遞大量的文件數據
雪碧圖
對于不使用 HTTP2 的場景，可以將多個圖片合并為雪碧圖，以達到減少文件的目的
defer、async
通過 defer 和 async 屬性，可以讓頁面盡早加載 js 文件
prefetch、preload
通過 prefetch 屬性，可以讓頁面在空閑時預先下載其他頁面可能要用到的資源
通過 preload 屬性，可以讓頁面預先下載本頁面可能要用到的資源
多個靜態資源域
對于不使用 HTTP2 的場景，將相對獨立的靜態資源分到多個域中保存，可以讓瀏覽器同時開啟多個 TCP 連接，并行下載
參考答案：
過期時間
當客戶端長時間沒有傳遞 sessionid 過來時，服務器可以在過期時間之后自動清除 session
客戶端主動通知
可以使用 JS 監聽客戶端頁面關閉或其他退出操作，然后通知服務器清除 session
參考答案：
DNS 域名解析是指把域名解析成 IP 地址的過程。
在具體的實現上，域名解析是由多個層級的服務器共同完成的。在查詢域名時，客戶端會先檢查自身的 DNS 映射表，若找不到解析記錄，則使用用戶配置的 DNS 服務器，若目標 DNS 服務器中找不到記錄，則繼續往上一個層級尋找，直到到達根域名服務器，根域名服務器會根據域名的類型，將解析任務分發到對應的子域名服務器依次查找，直到找到解析記錄為止。
注： 至此，網絡篇內容就整理完了，目前正在整理關于vue方面的，大家可以期待一下。歡大家迎關注我哈，點擊鏈接即可關注 法醫，大家認真看哦，奧利給！
作者：法醫
鏈接：https://juejin.cn/post/7197070078360322109
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
