轉(zhuǎn)自：詳解https是如何確保安全的?
Https 介紹
HTTPS（全稱(chēng)：Hypertext Transfer Protocol over Secure Socket Layer）旺嬉，是以安全為目標(biāo)的HTTP通道票唆，簡(jiǎn)單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL陈莽，因此加密的詳細(xì)內(nèi)容就需要SSL
內(nèi)容加密建立一個(gè)信息安全通道贱傀，來(lái)保證數(shù)據(jù)傳輸?shù)陌踩?/p>
身份認(rèn)證確認(rèn)網(wǎng)站的真實(shí)性
數(shù)據(jù)完整性防止內(nèi)容被第三方冒充或者篡改
對(duì)數(shù)據(jù)進(jìn)行加解密決定了它比http慢
需要進(jìn)行非對(duì)稱(chēng)的加解密押桃，且需要三次握手况毅。首次連接比較慢點(diǎn)，當(dāng)然現(xiàn)在也有很多的優(yōu)化异吻。
出于安全考慮裹赴，瀏覽器不會(huì)在本地保存HTTPS緩存。實(shí)際上诀浪，只要在HTTP頭中使用特定命令棋返，HTTPS是可以緩存的。Firefox默認(rèn)只在內(nèi)存中緩存HTTPS雷猪。但是睛竣，只要頭命令中有Cache-Control: Public，緩存就會(huì)被寫(xiě)到硬盤(pán)上求摇。 IE只要http頭允許就可以緩存https內(nèi)容射沟，緩存策略與是否使用HTTPS協(xié)議無(wú)關(guān)殊者。
https協(xié)議需要到CA申請(qǐng)證書(shū)。
http是超文本傳輸協(xié)議验夯，信息是明文傳輸猖吴；https 則是具有安全性的ssl加密傳輸協(xié)議。
http和https使用的是完全不同的連接方式簿姨，用的端口也不一樣距误，前者是80，后者是443扁位。
http的連接很簡(jiǎn)單，是無(wú)狀態(tài)的趁俊；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸域仇、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全寺擂。
http默認(rèn)使用80端口暇务，https默認(rèn)使用443端口
下面就是https的整個(gè)架構(gòu)，現(xiàn)在的https基本都使用TLS了怔软，因?yàn)楦影踩严福韵聢D中的SSL應(yīng)該換為SSL/TLS。
下面就上圖中的知識(shí)點(diǎn)進(jìn)行一個(gè)大概的介紹挡逼。
對(duì)稱(chēng)加密(也叫私鑰加密)指加密和解密使用相同密鑰的加密算法括改。有時(shí)又叫傳統(tǒng)密碼算法，就是加密密鑰能夠從解密密鑰中推算出來(lái)家坎，同時(shí)解密密鑰也可以從加密密鑰中推算出來(lái)嘱能。而在大多數(shù)的對(duì)稱(chēng)算法中，加密密鑰和解密密鑰是相同的虱疏，所以也稱(chēng)這種加密算法為秘密密鑰算法或單密鑰算法惹骂。
常見(jiàn)的對(duì)稱(chēng)加密有：DES（Data Encryption Standard）、AES（Advanced Encryption Standard）做瞪、RC4对粪、IDEA
與對(duì)稱(chēng)加密算法不同，非對(duì)稱(chēng)加密算法需要兩個(gè)密鑰：公開(kāi)密鑰（publickey）和私有密鑰（privatekey）装蓬；并且加密密鑰和解密密鑰是成對(duì)出現(xiàn)的著拭。非對(duì)稱(chēng)加密算法在加密和解密過(guò)程使用了不同的密鑰，非對(duì)稱(chēng)加密也稱(chēng)為公鑰加密矛物，在密鑰對(duì)中茫死，其中一個(gè)密鑰是對(duì)外公開(kāi)的，所有人都可以獲取到履羞，稱(chēng)為公鑰峦萎，其中一個(gè)密鑰是不公開(kāi)的稱(chēng)為私鑰屡久。
非對(duì)稱(chēng)加密算法對(duì)加密內(nèi)容的長(zhǎng)度有限制，不能超過(guò)公鑰長(zhǎng)度爱榔。比如現(xiàn)在常用的公鑰長(zhǎng)度是 2048 位被环，意味著待加密內(nèi)容不能超過(guò) 256 個(gè)字節(jié)。
數(shù)字摘要是采用單項(xiàng)Hash函數(shù)將需要加密的明文“摘要”成一串固定長(zhǎng)度（128位）的密文详幽，這一串密文又稱(chēng)為數(shù)字指紋筛欢，它有固定的長(zhǎng)度，而且不同的明文摘要成密文唇聘，其結(jié)果總是不同的版姑，而同樣的明文其摘要必定一致〕倮桑“數(shù)字摘要“是https能確保數(shù)據(jù)完整性和防篡改的根本原因剥险。
數(shù)字簽名技術(shù)就是對(duì)“非對(duì)稱(chēng)密鑰加解密”和“數(shù)字摘要“兩項(xiàng)技術(shù)的應(yīng)用，它將摘要信息用發(fā)送者的私鑰加密宪肖，與原文一起傳送給接收者表制。接收者只有用發(fā)送者的公鑰才能解密被加密的摘要信息，然后用HASH函數(shù)對(duì)收到的原文產(chǎn)生一個(gè)摘要信息控乾，與解密的摘要信息對(duì)比么介。如果相同，則說(shuō)明收到的信息是完整的蜕衡，在傳輸過(guò)程中沒(méi)有被修改壤短，否則說(shuō)明信息被修改過(guò)，因此數(shù)字簽名能夠驗(yàn)證信息的完整性衷咽。
數(shù)字簽名的過(guò)程如下：
明文 --> hash運(yùn)算 --> 摘要 --> 私鑰加密 --> 數(shù)字簽名
數(shù)字簽名有兩種功效：
一鸽扁、能確定消息確實(shí)是由發(fā)送方簽名并發(fā)出來(lái)的，因?yàn)閯e人假冒不了發(fā)送方的簽名镶骗。
二桶现、數(shù)字簽名能確定消息的完整性。
注意：
數(shù)字簽名只能驗(yàn)證數(shù)據(jù)的完整性鼎姊，數(shù)據(jù)本身是否加密不屬于數(shù)字簽名的控制范圍
對(duì)于請(qǐng)求方來(lái)說(shuō)，它怎么能確定它所得到的公鑰一定是從目標(biāo)主機(jī)那里發(fā)布的相寇，而且沒(méi)有被篡改過(guò)呢慰于？亦或者請(qǐng)求的目標(biāo)主機(jī)本本身就從事竊取用戶(hù)信息的不正當(dāng)行為呢？這時(shí)候唤衫，我們需要有一個(gè)權(quán)威的值得信賴(lài)的第三方機(jī)構(gòu)(一般是由政府審核并授權(quán)的機(jī)構(gòu))來(lái)統(tǒng)一對(duì)外發(fā)放主機(jī)機(jī)構(gòu)的公鑰婆赠，只要請(qǐng)求方這種機(jī)構(gòu)獲取公鑰，就避免了上述問(wèn)題的發(fā)生佳励。
用戶(hù)首先產(chǎn)生自己的密鑰對(duì)休里，并將公共密鑰及部分個(gè)人身份信息傳送給認(rèn)證中心蛆挫。認(rèn)證中心在核實(shí)身份后，將執(zhí)行一些必要的步驟妙黍，以確信請(qǐng)求確實(shí)由用戶(hù)發(fā)送而來(lái)悴侵，然后，認(rèn)證中心將發(fā)給用戶(hù)一個(gè)數(shù)字證書(shū)拭嫁，該證書(shū)內(nèi)包含用戶(hù)的個(gè)人信息和他的公鑰信息可免，同時(shí)還附有認(rèn)證中心的簽名信息(根證書(shū)私鑰簽名)。用戶(hù)就可以使用自己的數(shù)字證書(shū)進(jìn)行相關(guān)的各種活動(dòng)做粤。數(shù)字證書(shū)由獨(dú)立的證書(shū)發(fā)行機(jī)構(gòu)發(fā)布浇借，數(shù)字證書(shū)各不相同，每種證書(shū)可提供不同級(jí)別的可信度驮宴。
證書(shū)頒發(fā)機(jī)構(gòu)的名稱(chēng)
證書(shū)本身的數(shù)字簽名
證書(shū)持有者公鑰
證書(shū)簽名用到的Hash算法
瀏覽器默認(rèn)都會(huì)內(nèi)置CA根證書(shū)逮刨，其中根證書(shū)包含了CA的公鑰
證書(shū)頒發(fā)的機(jī)構(gòu)是偽造的：瀏覽器不認(rèn)識(shí)，直接認(rèn)為是危險(xiǎn)證書(shū)
證書(shū)頒發(fā)的機(jī)構(gòu)是確實(shí)存在的堵泽，于是根據(jù)CA名，找到對(duì)應(yīng)內(nèi)置的CA根證書(shū)恢总、CA的公鑰迎罗。用CA的公鑰，對(duì)偽造的證書(shū)的摘要進(jìn)行解密片仿，發(fā)現(xiàn)解不了纹安，認(rèn)為是危險(xiǎn)證書(shū)。
對(duì)于篡改的證書(shū)砂豌，使用CA的公鑰對(duì)數(shù)字簽名進(jìn)行解密得到摘要A厢岂，然后再根據(jù)簽名的Hash算法計(jì)算出證書(shū)的摘要B，對(duì)比A與B阳距，若相等則正常塔粒，若不相等則是被篡改過(guò)的。
證書(shū)可在其過(guò)期前被吊銷(xiāo)筐摘，通常情況是該證書(shū)的私鑰已經(jīng)失密卒茬。較新的瀏覽器如Chrome、Firefox咖熟、Opera和Internet Explorer都實(shí)現(xiàn)了在線證書(shū)狀態(tài)協(xié)議（OCSP）以排除這種情形：瀏覽器將網(wǎng)站提供的證書(shū)的序列號(hào)通過(guò)OCSP發(fā)送給證書(shū)頒發(fā)機(jī)構(gòu)圃酵，后者會(huì)告訴瀏覽器證書(shū)是否還是有效的。
1馍管、2點(diǎn)是對(duì)偽造證書(shū)進(jìn)行的郭赐，3是對(duì)于篡改后的證書(shū)驗(yàn)證，4是對(duì)于過(guò)期失效的驗(yàn)證确沸。
SSL (Secure Socket Layer捌锭，安全套接字層)
SSL為Netscape所研發(fā)俘陷，用以保障在Internet上數(shù)據(jù)傳輸之安全茴丰，利用數(shù)據(jù)加密(Encryption)技術(shù)圾笨，可確保數(shù)據(jù)在網(wǎng)絡(luò)上之傳輸過(guò)程中不會(huì)被截取，當(dāng)前為3.0版本呼盆。
SSL協(xié)議可分為兩層： SSL記錄協(xié)議（SSL Record Protocol）：它建立在可靠的傳輸協(xié)議（如TCP）之上坎匿，為高層協(xié)議提供數(shù)據(jù)封裝盾剩、壓縮、加密等基本功能的支持替蔬。 SSL握手協(xié)議（SSL Handshake Protocol）：它建立在SSL記錄協(xié)議之上告私，用于在實(shí)際的數(shù)據(jù)傳輸開(kāi)始前，通訊雙方進(jìn)行身份認(rèn)證承桥、協(xié)商加密算法驻粟、交換加密密鑰等。
TLS (Transport Layer Security凶异，傳輸層安全協(xié)議)
用于兩個(gè)應(yīng)用程序之間提供保密性和數(shù)據(jù)完整性蜀撑。
TLS 1.0是IETF（Internet Engineering Task Force，Internet工程任務(wù)組）制定的一種新的協(xié)議剩彬，它建立在SSL 3.0協(xié)議規(guī)范之上酷麦，是SSL 3.0的后續(xù)版本，可以理解為SSL 3.1喉恋，它是寫(xiě)入了 RFC 的沃饶。該協(xié)議由兩層組成： TLS 記錄協(xié)議（TLS Record）和 TLS 握手協(xié)議（TLS Handshake）。較低的層為 TLS 記錄協(xié)議轻黑，位于某個(gè)可靠的傳輸協(xié)議（例如 TCP）上面糊肤。
認(rèn)證用戶(hù)和服務(wù)器，確保數(shù)據(jù)發(fā)送到正確的客戶(hù)機(jī)和服務(wù)器氓鄙；
加密數(shù)據(jù)以防止數(shù)據(jù)中途被竊裙萑唷；
維護(hù)數(shù)據(jù)的完整性玖详，確保數(shù)據(jù)在傳輸過(guò)程中不被改變把介。
對(duì)于消息認(rèn)證使用密鑰散列法：TLS 使用“消息認(rèn)證代碼的密鑰散列法”（HMAC），當(dāng)記錄在開(kāi)放的網(wǎng)絡(luò)（如因特網(wǎng)）上傳送時(shí)蟋座，該代碼確保記錄不會(huì)被變更拗踢。SSLv3.0還提供鍵控消息認(rèn)證，但HMAC比SSLv3.0使用的（消息認(rèn)證代碼）MAC 功能更安全向臀。
增強(qiáng)的偽隨機(jī)功能（PRF）：PRF生成密鑰數(shù)據(jù)巢墅。在TLS中，HMAC定義PRF。PRF使用兩種散列算法保證其安全性君纫。如果任一算法暴露了驯遇，只要第二種算法未暴露，則數(shù)據(jù)仍然是安全的蓄髓。
改進(jìn)的已完成消息驗(yàn)證：TLS和SSLv3.0都對(duì)兩個(gè)端點(diǎn)提供已完成的消息叉庐，該消息認(rèn)證交換的消息沒(méi)有被變更。然而会喝，TLS將此已完成消息基于PRF和HMAC值之上陡叠，這也比SSLv3.0更安全。
一致證書(shū)處理：與SSLv3.0不同肢执，TLS試圖指定必須在TLS之間實(shí)現(xiàn)交換的證書(shū)類(lèi)型枉阵。
特定警報(bào)消息：TLS提供更多的特定和附加警報(bào)，以指示任一會(huì)話端點(diǎn)檢測(cè)到的問(wèn)題预茄。TLS還對(duì)何時(shí)應(yīng)該發(fā)送某些警報(bào)進(jìn)行記錄兴溜。
SSL與TLS握手整個(gè)過(guò)程如下圖所示耻陕，下面會(huì)詳細(xì)介紹每一步的具體內(nèi)容：
由于客戶(hù)端(如瀏覽器)對(duì)一些加解密算法的支持程度不一樣拙徽，但是在TLS協(xié)議傳輸過(guò)程中必須使用同一套加解密算法才能保證數(shù)據(jù)能夠正常的加解密。在TLS握手階段诗宣，客戶(hù)端首先要告知服務(wù)端斋攀，自己支持哪些加密算法，所以客戶(hù)端需要將本地支持的加密套件(Cipher Suite)的列表傳送給服務(wù)端梧田。除此之外，客戶(hù)端還要產(chǎn)生一個(gè)隨機(jī)數(shù)侧蘸，這個(gè)隨機(jī)數(shù)一方面需要在客戶(hù)端保存裁眯，另一方面需要傳送給服務(wù)端，客戶(hù)端的隨機(jī)數(shù)需要跟服務(wù)端產(chǎn)生的隨機(jī)數(shù)結(jié)合起來(lái)產(chǎn)生后面要講到的 Master Secret 讳癌。
客戶(hù)端需要提供如下信息：
支持的協(xié)議版本穿稳，比如TLS 1.0版
一個(gè)客戶(hù)端生成的隨機(jī)數(shù)，稍后用于生成”對(duì)話密鑰”
支持的加密方法晌坤，比如RSA公鑰加密
支持的壓縮方法
服務(wù)端在接收到客戶(hù)端的Client Hello之后逢艘，服務(wù)端需要確定加密協(xié)議的版本，以及加密的算法骤菠，然后也生成一個(gè)隨機(jī)數(shù)它改，以及將自己的證書(shū)發(fā)送給客戶(hù)端一并發(fā)送給客戶(hù)端，這里的隨機(jī)數(shù)是整個(gè)過(guò)程的第二個(gè)隨機(jī)數(shù)商乎。
服務(wù)端需要提供的信息：
協(xié)議的版本
加密的算法
隨機(jī)數(shù)
服務(wù)器證書(shū)
客戶(hù)端首先會(huì)對(duì)服務(wù)器下發(fā)的證書(shū)進(jìn)行驗(yàn)證央拖，驗(yàn)證通過(guò)之后，則會(huì)繼續(xù)下面的操作，客戶(hù)端再次產(chǎn)生一個(gè)隨機(jī)數(shù)（第三個(gè)隨機(jī)數(shù)）鲜戒，然后使用服務(wù)器證書(shū)中的公鑰進(jìn)行加密专控，以及放一個(gè)ChangeCipherSpec消息即編碼改變的消息，還有整個(gè)前面所有消息的hash值遏餐，進(jìn)行服務(wù)器驗(yàn)證伦腐，然后用新秘鑰加密一段數(shù)據(jù)一并發(fā)送到服務(wù)器，確保正式通信前無(wú)誤失都。
客戶(hù)端使用前面的兩個(gè)隨機(jī)數(shù)以及剛剛新生成的新隨機(jī)數(shù)柏蘑，使用與服務(wù)器確定的加密算法，生成一個(gè)Session Secret嗅剖。
ChangeCipherSpec
ChangeCipherSpec是一個(gè)獨(dú)立的協(xié)議辩越，體現(xiàn)在數(shù)據(jù)包中就是一個(gè)字節(jié)的數(shù)據(jù)，用于告知服務(wù)端信粮，客戶(hù)端已經(jīng)切換到之前協(xié)商好的加密套件（Cipher Suite）的狀態(tài)黔攒，準(zhǔn)備使用之前協(xié)商好的加密套件加密數(shù)據(jù)并傳輸了。
服務(wù)端在接收到客戶(hù)端傳過(guò)來(lái)的第三個(gè)隨機(jī)數(shù)的 加密數(shù)據(jù)之后强缘，使用私鑰對(duì)這段加密數(shù)據(jù)進(jìn)行解密督惰，并對(duì)數(shù)據(jù)進(jìn)行驗(yàn)證，也會(huì)使用跟客戶(hù)端同樣的方式生成秘鑰旅掂，一切準(zhǔn)備好之后赏胚，也會(huì)給客戶(hù)端發(fā)送一個(gè) ChangeCipherSpec，告知客戶(hù)端已經(jīng)切換到協(xié)商過(guò)的加密套件狀態(tài)商虐，準(zhǔn)備使用加密套件和 Session Secret加密數(shù)據(jù)了觉阅。之后，服務(wù)端也會(huì)使用 Session Secret 加密一段 Finish 消息發(fā)送給客戶(hù)端秘车，以驗(yàn)證之前通過(guò)握手建立起來(lái)的加解密通道是否成功典勇。
確定秘鑰之后，服務(wù)器與客戶(hù)端之間就會(huì)通過(guò)商定的秘鑰加密消息了叮趴，進(jìn)行通訊了割笙。整個(gè)握手過(guò)程也就基本完成了。
值得特別提出的是：
SSL協(xié)議在握手階段使用的是非對(duì)稱(chēng)加密眯亦，在傳輸階段使用的是對(duì)稱(chēng)加密伤溉，也就是說(shuō)在SSL上傳送的數(shù)據(jù)是使用對(duì)稱(chēng)密鑰加密的！因?yàn)榉菍?duì)稱(chēng)加密的速度緩慢妻率，耗費(fèi)資源乱顾。其實(shí)當(dāng)客戶(hù)端和主機(jī)使用非對(duì)稱(chēng)加密方式建立連接后，客戶(hù)端和主機(jī)已經(jīng)決定好了在傳輸過(guò)程使用的對(duì)稱(chēng)加密算法和關(guān)鍵的對(duì)稱(chēng)加密密鑰舌涨，由于這個(gè)過(guò)程本身是安全可靠的糯耍，也即對(duì)稱(chēng)加密密鑰是不可能被竊取盜用的扔字，因此，保證了在傳輸過(guò)程中對(duì)數(shù)據(jù)進(jìn)行對(duì)稱(chēng)加密也是安全可靠的温技，因?yàn)槌丝蛻?hù)端和主機(jī)之外革为，不可能有第三方竊取并解密出對(duì)稱(chēng)加密密鑰！如果有人竊聽(tīng)通信舵鳞，他可以知道雙方選擇的加密方法震檩，以及三個(gè)隨機(jī)數(shù)中的兩個(gè)。整個(gè)通話的安全蜓堕，只取決于第三個(gè)隨機(jī)數(shù)（Premaster secret）能不能被破解抛虏。
對(duì)于非常重要的保密數(shù)據(jù)，服務(wù)端還需要對(duì)客戶(hù)端進(jìn)行驗(yàn)證套才，以保證數(shù)據(jù)傳送給了安全的合法的客戶(hù)端迂猴。服務(wù)端可以向客戶(hù)端發(fā)出 Cerficate Request 消息，要求客戶(hù)端發(fā)送證書(shū)對(duì)客戶(hù)端的合法性進(jìn)行驗(yàn)證背伴。比如沸毁，金融機(jī)構(gòu)往往只允許認(rèn)證客戶(hù)連入自己的網(wǎng)絡(luò)，就會(huì)向正式客戶(hù)提供USB密鑰傻寂，里面就包含了一張客戶(hù)端證書(shū)息尺。
PreMaster secret前兩個(gè)字節(jié)是TLS的版本號(hào)，這是一個(gè)比較重要的用來(lái)核對(duì)握手?jǐn)?shù)據(jù)的版本號(hào)疾掰，因?yàn)樵贑lient Hello階段搂誉，客戶(hù)端會(huì)發(fā)送一份加密套件列表和當(dāng)前支持的SSL/TLS的版本號(hào)給服務(wù)端，而且是使用明文傳送的静檬，如果握手的數(shù)據(jù)包被破解之后炭懊，攻擊者很有可能串改數(shù)據(jù)包，選擇一個(gè)安全性較低的加密套件和版本給服務(wù)端拂檩，從而對(duì)數(shù)據(jù)進(jìn)行破解凛虽。所以，服務(wù)端需要對(duì)密文中解密出來(lái)對(duì)的PreMaster版本號(hào)跟之前Client Hello階段的版本號(hào)進(jìn)行對(duì)比广恢，如果版本號(hào)變低，則說(shuō)明被串改呀潭，則立即停止發(fā)送任何消息钉迷。
有兩種方法可以恢復(fù)原來(lái)的session：一種叫做session ID，另一種叫做session ticket钠署。
session ID的思想很簡(jiǎn)單糠聪，就是每一次對(duì)話都有一個(gè)編號(hào)（session ID）。如果對(duì)話中斷谐鼎，下次重連的時(shí)候舰蟆，只要客戶(hù)端給出這個(gè)編號(hào)，且服務(wù)器有這個(gè)編號(hào)的記錄，雙方就可以重新使用已有的”對(duì)話密鑰”身害，而不必重新生成一把味悄。
session ID是目前所有瀏覽器都支持的方法，但是它的缺點(diǎn)在于session ID往往只保留在一臺(tái)服務(wù)器上塌鸯。所以侍瑟，如果客戶(hù)端的請(qǐng)求發(fā)到另一臺(tái)服務(wù)器，就無(wú)法恢復(fù)對(duì)話
客戶(hù)端發(fā)送一個(gè)服務(wù)器在上一次對(duì)話中發(fā)送過(guò)來(lái)的session ticket丙猬。這個(gè)session ticket是加密的涨颜，只有服務(wù)器才能解密，其中包括本次對(duì)話的主要信息茧球，比如對(duì)話密鑰和加密方法庭瑰。當(dāng)服務(wù)器收到session ticket以后，解密后就不必重新生成對(duì)話密鑰了抢埋。
目前只有Firefox和Chrome瀏覽器支持弹灭。
https實(shí)際就是在TCP層與http層之間加入了SSL/TLS來(lái)為上層的安全保駕護(hù)航，主要用到對(duì)稱(chēng)加密羹令、非對(duì)稱(chēng)加密鲤屡、證書(shū)，等技術(shù)進(jìn)行客戶(hù)端與服務(wù)器的數(shù)據(jù)加密傳輸福侈，最終達(dá)到保證整個(gè)通信的安全性酒来。
作者：風(fēng)化成石
鏈接：http://www.reibang.com/p/30b8b40a671c
來(lái)源：簡(jiǎn)書(shū)
簡(jiǎn)書(shū)著作權(quán)歸作者所有，任何形式的轉(zhuǎn)載都請(qǐng)聯(lián)系作者獲得授權(quán)并注明出處肪凛。
