WEB驗(yàn)證jwt session cookie之間的關(guān)系

這篇文章主要講解了“WEB驗(yàn)證jwt session cookie之間的關(guān)系”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來(lái)研究和學(xué)習(xí)“WEB驗(yàn)證jwt session cookie之間的關(guān)系”吧！

Web認(rèn)證是任何一個(gè)認(rèn)真一點(diǎn)的網(wǎng)站都必須實(shí)現(xiàn)的基本功能。這個(gè)功能解決了讓服務(wù)器“認(rèn)識(shí)你就是你“的問(wèn)題。這個(gè)功能看起來(lái)貌似很簡(jiǎn)單，但是實(shí)際上處處是坑。因?yàn)檎J(rèn)證是依靠一套技術(shù)整體運(yùn)作才能完成，所以僅僅是把一些現(xiàn)成的技術(shù)簡(jiǎn)單拼起來(lái)是不夠的。你必須了解每一種技術(shù)能做什么，不能做什么，解決了哪些問(wèn)題，才能精心設(shè)計(jì)一套認(rèn)證功能。

兩種認(rèn)證

目前市面上能見(jiàn)到的認(rèn)證方式分為兩大種——基于Session的和基于Token的。

所謂基于Session的認(rèn)證，是指在客戶端存儲(chǔ)一個(gè)Session Id。認(rèn)證時(shí)，請(qǐng)求攜帶Session Id，并由服務(wù)器從Session數(shù)據(jù)存儲(chǔ)中找到對(duì)應(yīng)的Session。這種方式在很多網(wǎng)站框架下都有

所謂基于Token的認(rèn)證，是指將所有認(rèn)證相關(guān)的信息在服務(wù)器端編碼成一個(gè)Token，并由服務(wù)器簽名，以確保不被篡改。Token本身是明文的。存在Token里的信息可以有比如user id、權(quán)限列表、用戶昵稱一類(lèi)的。這樣服務(wù)器只要拿著token和token的簽名，就可以直接驗(yàn)證用戶的身份是合法的。在現(xiàn)實(shí)當(dāng)中，基于Token的認(rèn)證的主要標(biāo)準(zhǔn)是Json Web Token （JWT），見(jiàn)RFC 7519。

認(rèn)證方式

但是我不得不說(shuō)的是，基于Token的認(rèn)證在現(xiàn)實(shí)當(dāng)中并不是很實(shí)用……

JWT

一個(gè)JWT大概長(zhǎng)這樣：

base64(header).base64(json payload).signature

• header部分描述一些基本信息，比如這個(gè)token是用什么算法簽名的，是什么版本的等等。

• payload就是一個(gè)json object。你可以任意放置你想要的信息，只要符合json的格式即可。標(biāo)準(zhǔn)中已經(jīng)規(guī)定好了有一些字段的意思，比如iat表示issue at，token簽發(fā)的時(shí)間；exp表示token過(guò)期的時(shí)間等等。根據(jù)這些約定就可以實(shí)現(xiàn)一些小的代碼庫(kù)來(lái)檢查比如token是不是過(guò)期了等等。但是請(qǐng)注意，很多人誤解，認(rèn)為JWT是加了密的，但其實(shí)payload是明文的。

• signature是一個(gè)簽名。服務(wù)器端可以自行選擇一個(gè)算法和一個(gè)secret，與payload拼接上，得到一個(gè)簽名。secret并不會(huì)在網(wǎng)絡(luò)中傳輸，所以客戶端無(wú)法偽造一個(gè)JWT。這樣，一旦一個(gè)簽名生成，再傳回給服務(wù)器，服務(wù)器就可以知道這個(gè)token是不是它當(dāng)初生成的。

通過(guò)這樣的機(jī)制，JWT中可以存儲(chǔ)一些認(rèn)證必要的信息。給定一個(gè)JWT，服務(wù)器只要驗(yàn)證：

• 這個(gè)JWT的簽名是對(duì)的

• 這個(gè)JWT還在生效（即當(dāng)前時(shí)間在JWT生效時(shí)刻之后，在失效時(shí)刻之前）

之后服務(wù)器就可以信任這個(gè)JWT中包含的信息，包括user id、包含的權(quán)限等等。服務(wù)器不需要自己再去查詢一遍這個(gè)用戶的信息，以及這個(gè)用戶的權(quán)限信息，就可以對(duì)請(qǐng)求作出相應(yīng)。不用session了，無(wú)狀態(tài)大法好！然而，需要潑一下冷水的是：

• 使用了JWT，無(wú)法實(shí)現(xiàn)在服務(wù)器端對(duì)用戶請(qǐng)求進(jìn)行管理——管理員沒(méi)法統(tǒng)計(jì)多少個(gè)人登錄了，一個(gè)人登錄了多少次，登陸了什么設(shè)備；同時(shí)，也無(wú)法強(qiáng)行“踢”掉一個(gè)用戶的登錄——JWT一旦生成，在失效之前，總是有效的。如果實(shí)現(xiàn)了一個(gè)token黑名單之類(lèi)的功能，就等價(jià)于實(shí)現(xiàn)了Session機(jī)制，無(wú)狀態(tài)帶來(lái)的好處就無(wú)從談起。這個(gè)限制對(duì)于任何一個(gè)要認(rèn)真做用戶風(fēng)險(xiǎn)控制的網(wǎng)站來(lái)說(shuō)都是不可能接受的。

• 使用了JWT，無(wú)法很好的控制payload的數(shù)據(jù)量。盡管規(guī)范表示，應(yīng)該只把認(rèn)證的相關(guān)信息放到payload里。但實(shí)際上，開(kāi)發(fā)人員往往會(huì)誤用，把幾乎所有和user相關(guān)的數(shù)據(jù)都放到payload里。而payload的尺寸過(guò)大，比如達(dá)到數(shù)KB，就會(huì)極大的損耗帶寬和IO性能。要記得，為了達(dá)成“無(wú)狀態(tài)”，每個(gè)請(qǐng)求都必須把全量的JWT都帶著……

這兩個(gè)嚴(yán)重的缺陷限定了JWT只能用到一些不太認(rèn)真的場(chǎng)景。而對(duì)于真正的社交、金融、游戲等認(rèn)真一點(diǎn)的服務(wù)，還是要選擇基于Session的認(rèn)證。

當(dāng)然，token中的簽名還是有好處的，簽名可以確保token的確是服務(wù)器產(chǎn)生的，不會(huì)被篡改。如果token中包含了user id，那么還可以實(shí)現(xiàn)簡(jiǎn)單的前端錯(cuò)誤上報(bào)；如果token中還有session id，就可以在服務(wù)器端實(shí)現(xiàn)基于Session的認(rèn)證。因此，你可以將user id、session id、token過(guò)期時(shí)間等幾個(gè)關(guān)鍵數(shù)據(jù)放到payload里——只放這幾個(gè)，不放其他的數(shù)據(jù)，得到一個(gè)用來(lái)做Session認(rèn)證的JWT。更進(jìn)一步，如果你把JWT的規(guī)范稍微小改一下，比如payload不用JSON，而是更緊湊的格式；定死了簽名算法，即可省略JWT的header了；最后再優(yōu)化一下編碼格式，就能得到一個(gè)你自己的token。

但，無(wú)論用session還是token，還是什么其他的名字，這些都不重要。重要的是服務(wù)器這邊必須實(shí)現(xiàn)session機(jī)制，以便于對(duì)用戶登錄信息進(jìn)行有效的管理。

有人告訴過(guò)我一個(gè)使用基于Token + 無(wú)狀態(tài)的認(rèn)證方式的原因：他們的存儲(chǔ)是一個(gè)云服務(wù)，并且按照調(diào)用次數(shù)收費(fèi)。所以他們讓用戶每次將Token傳給服務(wù)器，就是希望盡量少的調(diào)用那個(gè)云服務(wù)。對(duì)此我表示很無(wú)語(yǔ)……

怎么存儲(chǔ)認(rèn)證信息

談完了session和token，我們來(lái)說(shuō)所說(shuō)這個(gè)信息在客戶端怎么存儲(chǔ)?？蛻羲阋卜謨纱箢?lèi)——瀏覽器和Native App。先說(shuō)說(shuō)瀏覽器。

瀏覽器

瀏覽器中的存儲(chǔ)主要是Local Storage和Cookie。

其實(shí)瀏覽器用于存放認(rèn)證信息的存儲(chǔ)還有Session Storage，但是它和Local Storage差不多，只是失效的機(jī)制不太一樣。這里只用Local Storage討論。

使用基于Token認(rèn)證的開(kāi)發(fā)人員很喜歡使用Header + Local Storage。因?yàn)檫@樣可以有效防止CSRF （下一小節(jié)專(zhuān)門(mén)講）。

但是使用Local Storage，反而會(huì)增加中招XSS（Crossing Site Script）的機(jī)會(huì)。一旦中招XSS，攻擊者可以輕易的拿到認(rèn)證信息，并且傳回自己的接受網(wǎng)址而不被用戶察覺(jué)。這樣一來(lái)攻擊者能夠輕易的代替用戶登錄了。

整個(gè)瀏覽器中，只有一種資源是腳本無(wú)法訪問(wèn)到的。這就是被設(shè)置為HttpOnly的cookie。這是非常理想的放置認(rèn)證token/session id的地方。設(shè)置這種token只需要在Set Cookie時(shí)這么寫(xiě)：

Set-Cookie: access_token=xxxxxxxxxxxxxxxxxx; HttpOnly; Secure; Same-Site=strict; Path=/;

(Secure和Same-Site是什么？下文會(huì)解釋)

XSS攻擊者沒(méi)有任何辦法從HttpOnly的Cookie中拿到你的認(rèn)證信息，除非他能在你登錄網(wǎng)站后，直接進(jìn)入你的電腦，打開(kāi)瀏覽器的開(kāi)發(fā)者工具并人肉復(fù)制粘貼（叫你不鎖屏，哼）。

有些人堅(jiān)稱自己的程序可以保證不受XSS的攻擊，所以可以放心的用Local Storage。比如使用React框架開(kāi)發(fā)的程序理論上所有的DOM節(jié)點(diǎn)都由React的虛擬DOM產(chǎn)生，所有的標(biāo)簽生成都進(jìn)行了escape。espace掉的腳本就無(wú)法執(zhí)行，也就不可能XSS了。

這樣講沒(méi)有錯(cuò)誤，但是XSS最令人頭疼的地方在于你很難保證你的網(wǎng)站對(duì)所有用戶的輸入都進(jìn)行了escape。

• 你編寫(xiě)的是一個(gè)寫(xiě)文章的網(wǎng)站，需要支持用戶手工輸入HTML，并且HTML必須得直接展示；

• 你編寫(xiě)的網(wǎng)站99%是React這樣的框架生成的，但是可能會(huì)有一些邊角，為了方便還是使用jquery等傳統(tǒng)技術(shù)

• 你的網(wǎng)站是一個(gè)團(tuán)隊(duì)開(kāi)發(fā)，盡管開(kāi)發(fā)規(guī)范要求大家都要對(duì)用戶的輸入進(jìn)行escape處理，但是只要是人就會(huì)忘，而escape這件事情不一定能進(jìn)入到測(cè)試的Case清單；

• ……

只要有一個(gè)漏洞存在，那么整個(gè)防護(hù)體系就完全失效。這就是為什么HttpOnly Cookie這樣的絕對(duì)隔離措施很關(guān)鍵的原因。

Native App

Native App比瀏覽器相對(duì)簡(jiǎn)單。一般Native App都是靜態(tài)編譯產(chǎn)生，不存在XSS的問(wèn)題。同時(shí)移動(dòng)操作系統(tǒng)都會(huì)有沙箱機(jī)制，避免其他App讀取到自己的數(shù)據(jù)（除非你root了……）。因此，Native App可以比較放心的將數(shù)據(jù)存在App沙箱內(nèi)某個(gè)存儲(chǔ)即可。如果不放心，可以考慮如iOS KeyChain或者Android KeyStore這樣的設(shè)施。

但Native App與服務(wù)器交互有一些區(qū)別。Native App一般是不直接支持Cookie機(jī)制的。所以如果一個(gè)服務(wù)器端使用Cookie來(lái)保存認(rèn)證信息，就需要Natvie App手工解析Set-Cookie Header，同時(shí)，Native App因?yàn)椴恢苯又С諧ookie，所以傾向于在請(qǐng)求中使用AuthorizationHeader來(lái)傳入認(rèn)證信息。這也需要服務(wù)器適配。當(dāng)然，最簡(jiǎn)單的辦法是讓Native App引入一個(gè)模擬Cookie行為的庫(kù)。

防止CSRF

CSRF代表Crossing Site Recource Forge。大致的觸發(fā)流程是：

1. 用戶登錄了站點(diǎn)A，并且在Cookie中留下了A站點(diǎn)的認(rèn)證信息

2. 用戶進(jìn)入了站點(diǎn)B，而站點(diǎn)B用一些方式（比如一個(gè)提交行為是到A站點(diǎn)某關(guān)鍵接口的表單）引誘用戶去點(diǎn)擊。當(dāng)用戶點(diǎn)擊時(shí)，會(huì)發(fā)出到A站點(diǎn)的請(qǐng)求。而瀏覽器會(huì)給這個(gè)請(qǐng)求附帶上A站點(diǎn)的認(rèn)證信息，從而讓這個(gè)請(qǐng)求能夠執(zhí)行。這種行為可能是，但不限于，給某個(gè)A站點(diǎn)的某個(gè)其他用戶提權(quán)/轉(zhuǎn)賬/發(fā)文辱罵等等。

上文中提到了，很多人用JWT+Local Storage的本心是為了防護(hù)CRSF。這樣做的原因是——因?yàn)镃ookie的發(fā)送是完全由瀏覽器控制的，不受網(wǎng)頁(yè)本身的控制。所以最簡(jiǎn)單直接的辦法，就是不用Cookie，不讓自動(dòng)發(fā)送認(rèn)證信息成為可能。問(wèn)題在于，這么干是有XSS風(fēng)險(xiǎn)的。從上文中可以看到，為了避免XSS，就必須用HttpOnlyCookie。

那么怎么在使用Cookie的同時(shí)，還能防范CSRF呢？

傳統(tǒng)頁(yè)面Web網(wǎng)站

在傳統(tǒng)頁(yè)面Web網(wǎng)站中，一般會(huì)使用CSRF Token。這是個(gè)非常流行的做法。像Tomcat這類(lèi)的容器都會(huì)自帶CSRF Token的產(chǎn)生和檢查Filter。

CSRF Token是這樣工作的?？蛻舳艘紫认蚍?wù)器請(qǐng)求一個(gè)帶有提交表單的頁(yè)面，服務(wù)器返回的頁(yè)面中會(huì)嵌入一個(gè)CSRF Token。當(dāng)用戶提交表單時(shí)，CSRF Token會(huì)被一起攜帶發(fā)給服務(wù)器做驗(yàn)證。所以當(dāng)服務(wù)器看到CSRF Token，就可以放心大膽的確認(rèn)用戶的的確確是看看到了提交前的表單界面，從而避免了用戶稀里糊涂提交一個(gè)被偽造的表單的可能性。

SPA

CSRF Token只適合于傳統(tǒng)的頁(yè)面請(qǐng)求，在SPA的情況下會(huì)比較尷尬。

在SPA中，客戶端與服務(wù)器之間的交互主要是通過(guò)接口完成的，沒(méi)有頁(yè)面的概念。此時(shí)，你的確可以照貓畫(huà)虎的做一個(gè)接口讓用戶拿到CSRF Token，但這樣什么也確認(rèn)不了。因?yàn)楣粽呖梢哉{(diào)用同樣的接口，拿到合法的CSRF Token。

這時(shí)有幾種辦法：

• 給所有接口都添加一個(gè)請(qǐng)求secret，來(lái)標(biāo)記其來(lái)自于合法的客戶端。這個(gè)secrect可以是固定的隨機(jī)字符串，也可以通過(guò)某些動(dòng)態(tài)算法產(chǎn)生。對(duì)于CSRF，瀏覽器只會(huì)做自動(dòng)傳Cookie而已，并不能幫助傳入secret。這樣一來(lái)，就可以確定消除CSRF的風(fēng)險(xiǎn)。但注意，這個(gè)機(jī)制僅能防范CSRF，而不能防范人為的攻擊。黑客只要拿得到客戶端，就一定能找到生成secret的辦法。

  secret有一個(gè)順帶的功能是提高了第三方用戶隨意調(diào)用接口的門(mén)檻——他們必須得去查看客戶端源代碼，學(xué)會(huì)了怎么生成secret才能調(diào)用接口。

• 用Same-Site Cookie。回到上面CSRF步驟的第二步驟。當(dāng)用戶看到了B站點(diǎn)偽造的表單，點(diǎn)擊了提交，向站點(diǎn)A發(fā)出請(qǐng)求時(shí)，被標(biāo)記了Same-Site=strict的Cookie是不會(huì)被攜帶的，因?yàn)楫?dāng)時(shí)的主站點(diǎn)域名B和提交的站點(diǎn)域名A不一樣。這是Same-Site=strict標(biāo)記是個(gè)相對(duì)較新的標(biāo)準(zhǔn)。目前大部分瀏覽器都已經(jīng)支持了。但如果大量的用戶群還在類(lèi)似于IE8這樣的老系統(tǒng)上，這個(gè)招數(shù)便是無(wú)效的。

• 歪招，總是用json格式提交。CSRF可能發(fā)生的一個(gè)前提條件是必須用傳統(tǒng)表單提交。這是因?yàn)閭鹘y(tǒng)表單提交可以跨域——你在站點(diǎn)B，可以提交表單給站點(diǎn)A。而Ajax的請(qǐng)求除非開(kāi)啟CORS，是不允許跨域的，所以天然的屏蔽掉了這個(gè)問(wèn)題。傳統(tǒng)表單的提交的格式必然是application/x-www-form-urlencoded。因此只要保證服務(wù)器能夠拒絕處理所有application/x-www-form-urlencoded格式的POST請(qǐng)求，就能確保SPA不受CSRF的影響。那用啥呢？JSON - application/json。（我專(zhuān)門(mén)寫(xiě)這一條的原因是，jquery的ajax庫(kù)的默認(rèn)行為正是使用application/x-www-form-urlencoded格式。如果你還在用，可以考慮改一下。）

• 另一個(gè)歪招，雙認(rèn)證。將你的認(rèn)證信息同時(shí)放在HttpOnly Cookie和Authorization Header。服務(wù)器要先比對(duì)這兩個(gè)值是一樣的，然后再去執(zhí)行認(rèn)證過(guò)程。這樣可以同時(shí)防范XSS和CSRF。代價(jià)是，如果你的認(rèn)證信息比較長(zhǎng)，會(huì)浪費(fèi)一些帶寬。

總是使用https

大學(xué)上網(wǎng)絡(luò)課時(shí)，老師講解了http的一些原理，然后給我們留了個(gè)作業(yè)——去外邊提供WIFI的餐廳用嗅探器扒別人的密碼。兩周后，我們做完了作業(yè)，心情是悲催的——尼瑪互聯(lián)網(wǎng)都發(fā)明了十幾年了，連最基本的防護(hù)都沒(méi)有……

http是明文傳輸?shù)?/strong>。在http下，用戶輸入的任何信息，從他的電腦到服務(wù)器之間的每個(gè)鏈路節(jié)點(diǎn)都是明文的。在這里個(gè)鏈路中的任何地方，都可以截取到完整的數(shù)據(jù)，包含你的密碼，認(rèn)證token……

這就是為什么https是必須的。https主要提供三個(gè)保證：

• 端端加密。通過(guò)https交互的原始數(shù)據(jù)，只有用戶的瀏覽器和最終的服務(wù)器可以看到。其他中間節(jié)點(diǎn)無(wú)法獲）。

• 客戶端可以認(rèn)定要訪問(wèn)的服務(wù)器就是那個(gè)服務(wù)器。這是被證書(shū)體系所支撐的。一旦瀏覽器的地址欄出現(xiàn)了網(wǎng)址的證書(shū)信息，并且是綠色的提示，那么用戶的心里就可以穩(wěn)了。（當(dāng)然國(guó)內(nèi)其實(shí)也不完全是這樣，講多了查水表，懂者自懂）。

• 服務(wù)器可以認(rèn)定訪問(wèn)的客戶端就是合法的客戶端。這種模式被稱為“2-Way SSL”或者“Mutal SSL”。這種模式是可選的，需要多配置一個(gè)客戶端證書(shū)，一般場(chǎng)景用不到，多見(jiàn)于企業(yè)Web服務(wù)。

早些時(shí)候，很多人對(duì)https有一些抵觸，大致的原因是，支持https需要軟件改造；服務(wù)器對(duì)證書(shū)進(jìn)行密碼學(xué)運(yùn)算要耗費(fèi)很多CPU；同時(shí)也會(huì)帶來(lái)跟多的網(wǎng)絡(luò)請(qǐng)求和響應(yīng)（多了ssl握手）。這無(wú)疑會(huì)帶來(lái)一些成本和體驗(yàn)上的問(wèn)題。但那已經(jīng)是10多年前的事情了?，F(xiàn)在的軟硬件處理能力和網(wǎng)絡(luò)基礎(chǔ)設(shè)施比起10年前都有數(shù)倍的提高。如果今天，一個(gè)商業(yè)網(wǎng)站仍然堅(jiān)持不用https，那么可以請(qǐng)他的老板去大街上裸奔。

使用了https后，為了進(jìn)一步保證安全，將Cookie設(shè)置為Secure。這樣，瀏覽器就可以只在訪問(wèn)https網(wǎng)址時(shí)才會(huì)攜帶Cookie。如果不做這樣的設(shè)置，通過(guò)https站點(diǎn)設(shè)置的Cookie，仍然會(huì)向http站點(diǎn)發(fā)送。當(dāng)這個(gè)站點(diǎn)的域名解析被劫持，就可能造成向一個(gè)偽造的服務(wù)器發(fā)出你的認(rèn)證信息。

認(rèn)證信息不應(yīng)該永久有效

很多人為了“用戶體驗(yàn)”，選擇讓一個(gè)登錄永久有效。這樣做是非常危險(xiǎn)的。因?yàn)橐坏┯脩舻恼J(rèn)證信息被別人獲取了，就永久性的失去了防御的機(jī)會(huì)（記得上面說(shuō)的不鎖電腦屏幕的后果嗎？）。

因此，總是要保證認(rèn)證信息的有效期是有限的。一般根據(jù)業(yè)務(wù)場(chǎng)景的安全級(jí)別不同，可以設(shè)為若干分鐘～若干天。就算是社交娛樂(lè)類(lèi)的應(yīng)用，有效期最好也不要超過(guò)兩周。

但，為了讓頻繁使用的用戶體驗(yàn)更好，可以考慮實(shí)現(xiàn)會(huì)話期續(xù)期。但需要注意，這里說(shuō)的續(xù)期是指從用戶角度看可以延續(xù)其不需要登錄的時(shí)間長(zhǎng)度，而不是直接讓session/token有效期變長(zhǎng)。必須實(shí)現(xiàn)為給用戶替換一個(gè)新的session id/token。這樣做，既能保證同一個(gè)認(rèn)證信息不會(huì)永久有效，又能讓正常的、頻繁使用的用戶免除登錄之苦。

總結(jié)一下

總結(jié)下來(lái)，一個(gè)靠譜的Web認(rèn)證應(yīng)該：

• 可以使用Session也可以使用Token做認(rèn)證，但是總是要保證服務(wù)器端可以管理Session，通過(guò)Session是否存在來(lái)最終確定認(rèn)證的有效性；

• 將認(rèn)證信息存放在標(biāo)記為HttpOnly，Secure，Same-Site=strict的Cookie中，從而避免XSS和CSRF；

• 總是使用https，只要你的網(wǎng)絡(luò)鏈路經(jīng)過(guò)了公網(wǎng)；

• 如果是傳統(tǒng)的頁(yè)面網(wǎng)站，請(qǐng)使用CSRF Token機(jī)制；

• 如果可以，做一個(gè)簡(jiǎn)單的請(qǐng)求secret，可以輔助防止CSRF，也可以稍稍的提高接口被爬取的門(mén)檻；

• 如果是SPA應(yīng)用，放心大膽的禁用對(duì)application/x-www-form-urlencoded的支持

• 保證token/session必須有一個(gè)有效期

感謝各位的閱讀，以上就是“WEB驗(yàn)證jwt session cookie之間的關(guān)系”的內(nèi)容了，經(jīng)過(guò)本文的學(xué)習(xí)后，相信大家對(duì)WEB驗(yàn)證jwt session cookie之間的關(guān)系這一問(wèn)題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！