專利名稱：消息傳輸方法、網(wǎng)絡(luò)裝置及網(wǎng)絡(luò)系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及互聯(lián)網(wǎng)技術(shù)領(lǐng)域，具體涉及一種消息傳輸方法、網(wǎng)絡(luò)裝置及網(wǎng) 絡(luò)系統(tǒng)。
背景技術(shù)：
安全套接層(SSL, Secure Sockets Layer )協(xié)議及傳輸層安全(TLS, Transport Layer Security)協(xié)議是互聯(lián)網(wǎng)提供安全保密的一種通訊協(xié)議，為數(shù)據(jù)傳輸例如 電子郵件傳輸、網(wǎng)上傳真等提供安全保密服務(wù)。本文以TLS協(xié)議舉例說明。 TLS協(xié)議利用密鑰算法在互聯(lián)網(wǎng)上提供端點(diǎn)間的身份認(rèn)證與通訊保密等服務(wù)， 其應(yīng)用&出 一般是公鑰基礎(chǔ)設(shè)施(PKI ， Public Key Infrastructrue )。
TLS協(xié)議的握手過程中，客戶端第一次連接服務(wù)器時(shí)，將向服務(wù)器發(fā)送客 戶端發(fā)現(xiàn)消息(ClientHello消息)，服務(wù)器接收到ClientHello消息后向客戶端 返回服務(wù)器發(fā)現(xiàn)消息(ServerHello消息)，并向客戶端發(fā)送證書消息(Certificate 消息)，Certificate消息中攜帶服務(wù)器的證書鏈。所說的證書鏈， 一般包括一系 列由CA簽發(fā)的證書序列，最終以根證書結(jié)束。如果后續(xù)服務(wù)器要求客戶端發(fā) 送客戶端證書，則客戶端會(huì)向服務(wù)器發(fā)送Certificate消息，其中攜帶客戶端的 證書鏈。
在對(duì)此方法的研究和實(shí)踐過程中，本發(fā)明的發(fā)明人發(fā)現(xiàn)現(xiàn)有技術(shù)中，不 論客戶端是否是第一次與服務(wù)器通信，每次客戶端與服務(wù)器端進(jìn)行TLS握手 時(shí)，服務(wù)器都要向客戶端發(fā)送完整的服務(wù)器證書鏈因此，現(xiàn)有技術(shù)方法進(jìn)行 TLS握手時(shí)的消息傳輸方法存在傳輸開銷大的問題。

發(fā)明內(nèi)容
本發(fā)明實(shí)施例提供能夠減小傳輸開銷的一種消息傳輸方法、網(wǎng)絡(luò)裝置及網(wǎng) 絡(luò)系統(tǒng)。
一種消息傳輸方法，包括
接收第一消息，所述第一消息中攜帶根據(jù)證書鏈生成的認(rèn)證字串值；
5當(dāng)確定所述第 一消息中的認(rèn)證字串值為采用的證書鏈對(duì)應(yīng)的認(rèn)證字串值 時(shí)，發(fā)送第二消息，所述第二消息表明采用所述第一消息中的認(rèn)證字串值對(duì)應(yīng)
的i正書鏈。
一種網(wǎng)絡(luò)裝置，包括
接收單元，用于接收第一消息，所述第一消息中攜帶根據(jù)證書鏈生成的認(rèn) 證字串值；
確定單元，用于確定所述第一消息中的認(rèn)證字串值是否為釆用的證書鏈對(duì) 應(yīng)的iU正字串值；
發(fā)送單元，用于當(dāng)所述確定單元確定所述第一消息中的i人證字串值為采用 的證書鏈對(duì)應(yīng)的認(rèn)證字串值時(shí)，發(fā)送第二消息，所述第二消息表明采用所述第 一消息中的認(rèn)證字串值對(duì)應(yīng)的證書鏈。
一種網(wǎng)絡(luò)系統(tǒng)，包括
第一裝置，用于發(fā)送第一消息，所述第一消息中攜帶根據(jù)證書鏈生成的認(rèn) 證字串值；
第二裝置，用于接收所述第一消息；當(dāng)確定所述第一消息中的認(rèn)證字串值 為采用的證書鏈對(duì)應(yīng)的認(rèn)證字串值時(shí)，發(fā)送第二消息，所述第二消息表明釆用 所述第 一消息中的認(rèn)證字串值對(duì)應(yīng)的證書鏈。
上述內(nèi)容可以看出，本發(fā)明實(shí)施例由于接收的第 一消息中攜帶根據(jù)證書鏈 生成的認(rèn)證字串值，因此接收端接收第一消息后如果確定所述第一消息中的認(rèn) 證字串值為采用的證書鏈對(duì)應(yīng)的認(rèn)證字串值，則可以認(rèn)為發(fā)送端已經(jīng)存儲(chǔ)相應(yīng) 的證書鏈，那么可以向發(fā)送端返回第二消息表明采用所述第一消息中的認(rèn)證字 串值對(duì)應(yīng)的證書鏈，就不再需要再向發(fā)送端發(fā)送證書鏈，因此就避免了因?yàn)閭?輸證書鏈帶來的巨大的傳輸開銷。


圖l是本發(fā)明實(shí)施例一消息傳輸方法流程圖； 圖2是本發(fā)明實(shí)施例二消息傳輸方法流程圖； 圖3是本發(fā)明實(shí)施例三消息傳輸方法流程圖； 圖4是本發(fā)明實(shí)施例四消息傳輸方法流程圖；圖5是本發(fā)明實(shí)施例網(wǎng)絡(luò)裝置結(jié)構(gòu)示意圖； 圖6是本發(fā)明實(shí)施例網(wǎng)絡(luò)系統(tǒng)結(jié)構(gòu)示意圖。
具體實(shí)施例方式
本發(fā)明實(shí)施例提供一種提供能夠減小傳輸開銷的消息傳輸方法。本發(fā)明實(shí) 施例還提供相應(yīng)的網(wǎng)絡(luò)裝置及網(wǎng)絡(luò)系統(tǒng)。以下分別進(jìn)行詳細(xì)說明。 圖l是本發(fā)明實(shí)施例一消息傳輸方法流程圖，主要包括步驟 步驟IOI、接收第一消息，所述第一消息中攜帶根據(jù)證書鏈生成的認(rèn)證字
串值；
步驟102、當(dāng)確定所述第一消息中的認(rèn)證字串值為釆用的證書鏈對(duì)應(yīng)的認(rèn) 證字串值時(shí)，發(fā)送第二消息，所述第二消息表明采用所述第一消息中的認(rèn)證字 串值對(duì)應(yīng)的證書鏈。
其中，所述接收的第一消息包括客戶端發(fā)現(xiàn)消息；所述發(fā)送的第二消息包 括服務(wù)器發(fā)現(xiàn)消息，所述服務(wù)器發(fā)現(xiàn)消息攜帶與所述客戶端發(fā)現(xiàn)消息中的認(rèn)證 字串值相同的認(rèn)證字串值；或者，攜帶認(rèn)證字串值為空的認(rèn)證字串?dāng)U展。認(rèn)證 字串值為空的認(rèn)證字串?dāng)U展為事先約定表示可釆用客戶端發(fā)現(xiàn)消息中的認(rèn)證 字串值對(duì)應(yīng)的證書鏈。進(jìn)一步的，還可以發(fā)送第一證書消息，所述第一證書消 息攜帶與所述客戶端發(fā)現(xiàn)消息中的認(rèn)證字串值相同的認(rèn)i正字串值；或者，所述 第一證書消息中的內(nèi)容為空。第一證書消息中的內(nèi)容為空為事先約定表示可釆 用客戶端發(fā)現(xiàn)消息中的認(rèn)證字串值對(duì)應(yīng)的證書鏈。
或者，所述接收的第一消息包括客戶端發(fā)現(xiàn)消息；所述發(fā)送的第二消息包 括第一證書消息，所述第一證書消息攜帶與所ii^戶端發(fā)現(xiàn)消息中的認(rèn)證字串 值相同的認(rèn)證字串值；或者，所述第一證書消息中的內(nèi)容為空。第一證書消息 中的內(nèi)容為空為事先約定表示可釆用客戶端發(fā)現(xiàn)消息中的認(rèn)證字串值對(duì)應(yīng)的 證書鏈。
或者，所述接收的第一消息包括客戶端證書請(qǐng)求消息；所述發(fā)送的第二消 息包括第二證書消息，所述第二證書消息攜帶與所述客戶端證書請(qǐng)求消息中的 認(rèn)證字串值相同的認(rèn)證字串值；或者，所述第二證書消息中的內(nèi)容為空。第二 證書消息中的內(nèi)容為空為事先約定表示可采用客戶端發(fā)現(xiàn)消息中的認(rèn)證字串值對(duì)應(yīng)的證書鏈。
該實(shí)施例內(nèi)容可以看出，本發(fā)明實(shí)施例由于接收的第 一消息中攜帶根據(jù)證 書鏈生成的認(rèn)證字串值，因此接收端接收第一消息后如果確定所述第一消息中 的認(rèn)證字串值為釆用的證書鏈對(duì)應(yīng)的認(rèn)證字串值，則可以認(rèn)為發(fā)送端已經(jīng)存儲(chǔ) 相應(yīng)的證書鏈，那么可以向發(fā)送端返回第二消息表明采用所述第 一消息中的認(rèn) 證字串值對(duì)應(yīng)的證書鏈，就不再需要再向發(fā)送端發(fā)送證書鏈，因此就避免了因 為傳輸證書鏈帶來的巨大的傳輸開銷。
以下對(duì)本發(fā)明實(shí)施例技術(shù)方案進(jìn)行更詳細(xì)介紹。
圖2是本發(fā)明實(shí)施例二消息傳輸方法流程圖，主要包括步驟
步驟201 、客戶端發(fā)送客戶端發(fā)現(xiàn)消息(ClientHello消息)，所述ClientHello 消息中攜帶認(rèn)證字串值；
該步驟中，客戶端存儲(chǔ)有將要進(jìn)行通信的服務(wù)器的證書鏈，該證書鏈可以 是上一次與服務(wù)器進(jìn)行交互時(shí)所存儲(chǔ)的由服務(wù)器發(fā)送的證書鏈，或者是通過其 他途徑獲取的服務(wù)器的證書鏈。
客戶端將ClientHello消息進(jìn)行擴(kuò)展，在該消息中設(shè)置認(rèn)證字串?dāng)U展，認(rèn)證 字串?dāng)U展中的內(nèi)容稱為認(rèn)證字串值。如果認(rèn)證字串?dāng)U展中的內(nèi)容為空，則不含 有認(rèn)證字串值。認(rèn)證字串值是對(duì)證書鏈按設(shè)定算法進(jìn)行處理后得到的字串值， 可以反映證書鏈的特征。認(rèn)證字串值的字節(jié)數(shù)相對(duì)證書鏈的字節(jié)數(shù)來說較小。
本發(fā)明實(shí)施例中是以對(duì)證書鏈按哈希算法進(jìn)行處理得到哈希值舉例說明 但不局限于此，也可以按其他算法(例如循環(huán)冗余校驗(yàn)(CRC, Cyclic Redundancy Check)算法)進(jìn)行處理得到反映證書鏈特征的認(rèn)證字串值。其中， 哈希算法可以是第一代安全散列算法(SHA-1, Secure Hash Algorithm 1)、 SHA-2 、 SHA-512或信息-摘要算法(MD5, Message-digest Algorithm 5 )等哈 希算法中的任意一種，但通信雙方使用的哈希算法要一致。
采用哈希算法時(shí)，客戶端在ClientHello消息進(jìn)行擴(kuò)展的認(rèn)證字串?dāng)U展為證 書哈希擴(kuò)展(certs—hash擴(kuò)展)，該certs—hash擴(kuò)展的內(nèi)容是客戶端將存儲(chǔ)的服務(wù) 器的證書鏈按哈希算法進(jìn)行處理得到的哈希值。
以下對(duì)設(shè)置認(rèn)證字串?dāng)U展進(jìn)行舉例說明但不局限于此，也可以釆用其他方式進(jìn)行擴(kuò)展。 一般對(duì)消息的字段進(jìn)行擴(kuò)展(extensions)的定義格式可以如下 struct {
ExtensionType extension—type; opaque extension_data<0..2A16-1 >; } Extension;
其中，"extension—data"表示該擴(kuò)展的值，本發(fā)明實(shí)施中的"extension—data" 為certs—hash擴(kuò)展的值，即p合希值也可稱為CertsHash。 certs hash擴(kuò)展可以如下表示 6num {
certsJiash(TBD)， (65535) } ExtensionType; 證書鏈的哈希值CertsHash，格式可以如下表示 struct {
opaque certificates—hash <1..2A8-1〉； } CertsHash;
經(jīng)過上述處理，客戶端向服務(wù)器發(fā)送ClientHello消息，其中攜帶服務(wù)器的 證書鏈的哈希值。
步驟202、服務(wù)器向客戶端發(fā)送服務(wù)器發(fā)現(xiàn)消息(ServerHello消息)，其中 攜帶認(rèn)證字串值；
服務(wù)器收到客戶端發(fā)送的ClientHello消息后，查看certs一hash字段的哈希值 是否是服務(wù)器設(shè)定的可以采用的證書鏈的哈希值。服務(wù)器一般可以設(shè)定可采用 的多種證書鏈，并且對(duì)證書鏈按設(shè)定算法進(jìn)行處理后得到認(rèn)證字串值，例如得 到哈希值。本發(fā)明實(shí)施例中以哈希值舉例說明。
月良務(wù)器如果確定ClientHello消息中certs—hash字段的哈希值是設(shè)定的可以 采用的證書鏈的哈希值，則可以認(rèn)為客戶端已經(jīng)存儲(chǔ)有服務(wù)器的證書鏈。此時(shí)， 服務(wù)器向客戶端返回ServerHello消息。
服務(wù)器將ServerHello進(jìn)行擴(kuò)展，在該消息中設(shè)置認(rèn)證字串?dāng)U展。采用哈希 算法時(shí)，認(rèn)證字串?dāng)U展具體為證書哈希擴(kuò)展(certs hash擴(kuò)展)。服務(wù)器向客戶端返回的ServerHello消息中的certs—hash擴(kuò)展所包含的哈希 值，與ClientHello消息中的certs—hash字段所包含的哈希值相同，表示可以使用 該。合希值對(duì)應(yīng)的證書《連。
步驟203、服務(wù)器向客戶端發(fā)送證書消息(Certificate消息)，其中不攜帶 認(rèn)證字串值，即發(fā)送內(nèi)容為空的證書消息。
該步驟中，服務(wù)器向客戶端發(fā)送Certificate消息，該Certificate消息為空消 息，其中的內(nèi)容為空(其中不攜帶服務(wù)器的證書鏈，也不攜帶哈希值)，通過 空消息表示服務(wù)器可以采用ClientHello消息中的哈希值對(duì)應(yīng)的證書鏈。服務(wù)器 和客戶端可以事先約定通過內(nèi)容為空的Certificate消息表示可以采用 ClientHello消息中的哈希值對(duì)應(yīng)的證書鏈。因此，此時(shí)Certificate消息不攜帶服 務(wù)器的證書鏈，就避免了傳輸?shù)木薮箝_銷。之后，服務(wù)器與客戶端的交互過程 與現(xiàn)有過程基本相同，例如服務(wù)器將向客戶端發(fā)送服務(wù)器密鑰交換消息 (ServerKeyExchange消息)，其中攜帶用于協(xié)商預(yù)主密鑰(pre—maseter—secret) 所需的一些密鑰參數(shù)；向客戶端發(fā)送服務(wù)器發(fā)現(xiàn)完成消息(ServerHelloDone 消息)，用于告知客戶端ServerHello消息及相關(guān)消息已經(jīng)發(fā)送完畢。
需要說明的是，服務(wù)器如果確定ClientHello消息中certs一hash字段的哈希值 不是設(shè)定的可以采用的證書鏈的哈希值，則響應(yīng)的ServerHello消息中不攜帶 certs—hash字段，即與現(xiàn)有的握手過程一樣。之后在Certificate消息中攜帶服務(wù) 器的證書鏈，發(fā)送給客戶端?？蛻舳藢⒎?wù)器的Certificate消息中的證書鏈存 儲(chǔ)，待收到服務(wù)器發(fā)送的完成消息(finished消息)并且—瞼證該消息正確后， 替代之前存儲(chǔ)的證書鏈，并在下一次與該服務(wù)器進(jìn)行通信時(shí)使用，即在 ClientHello消息攜帶的certs—hash擴(kuò)展中攜帶該新存儲(chǔ)的證書鏈的哈希值。
該實(shí)施例內(nèi)容可以看出，本發(fā)明實(shí)施例由于客戶端已經(jīng)存儲(chǔ)有服務(wù)器的證 書鏈，在向服務(wù)器發(fā)送的ClientHello消息中攜帶認(rèn)證字串值，該認(rèn)證字串值是 根據(jù)服務(wù)器的證書鏈生成，因此服務(wù)器接收ClientHello消息后可以認(rèn)為客戶端 已經(jīng)存儲(chǔ)服務(wù)器的證書鏈，那么可以向客戶端返回消息表示可以釆用 ClientHello消息中的認(rèn)證字串值對(duì)應(yīng)的證書鏈，該返回的消息可以是攜帶與 ClientHello消息中的認(rèn)證字串值相同的認(rèn)證字串值的ServerHello消息，也可以
10是內(nèi)容為空的Certificate消息。并且，可以釆用攜帶與ClientHello消息中的認(rèn)證 字串值相同的認(rèn)證字串值的ServerHello消息和內(nèi)容為空的Certificate消息中的 其中一個(gè)消息告知客戶端，也可以同時(shí)采用該兩個(gè)消息告知客戶端，進(jìn)一步確 ?？蛻舳丝梢垣@知該信息。這樣，服務(wù)器就不再需要再向客戶端發(fā)送服務(wù)器的 證書鏈，因此就避免了因?yàn)閭鬏敺?wù)器的證書鏈帶來的巨大的傳輸開銷，特別 是對(duì)于低帶寬、高延遲、高誤碼率的網(wǎng)絡(luò)，可以帶來很大好處。
需要說明的是，在步驟203中，也可以是服務(wù)器向客戶端發(fā)送攜帶認(rèn)證字 串值的Certificate消息。即該步驟可以是服務(wù)器向客戶端發(fā)送Certificate消息， 該Certificate消息不攜帶服務(wù)器的證書鏈，而是攜帶服務(wù)器的證書鏈的哈希值， 該哈希值與ClientHello消息中的certs—hash擴(kuò)展所包含的哈希值相同，表示服務(wù) 器可采用哈希值對(duì)應(yīng)的證書鏈。此時(shí)Certificate消息沒有攜帶服務(wù)器的證書鏈， 就避免了傳輸?shù)木薮箝_銷。
還需要說明的是，也可以不需要步驟203,即服務(wù)器不再向客戶端發(fā)送 Certificate消息。
圖3是本發(fā)明實(shí)施例三消息傳輸方法流程圖。實(shí)施例三與實(shí)施例二的主要 區(qū)別是服務(wù)器發(fā)送的ServerHello消息中的certs—hash字段的內(nèi)容為空，即其中不 攜帶哈希值，另外服務(wù)器發(fā)送的Certificate消息攜帶哈希值。
如圖3所示，主要包括步驟
步驟301 、客戶端發(fā)送ClientHello消息，所述ClientHello消息中攜帶認(rèn)證字
串值；
該步驟的內(nèi)容與實(shí)施例二相同，具體請(qǐng)參見實(shí)施例二中的描述。
經(jīng)過上述處理，客戶端向服務(wù)器發(fā)送ClientHello消息，其中攜帶服務(wù)器的 證書鏈的哈希值。
步驟302、服務(wù)器向客戶端發(fā)送ServerHello消息，其中不攜帶認(rèn)證字串值； 該步驟的內(nèi)容與實(shí)施例二不相同。
服務(wù)器如果確定ClientHello消息中certs—hash擴(kuò)展的哈希值是設(shè)定的可以 采用的證書鏈的哈希值，則可以認(rèn)為客戶端已經(jīng)存儲(chǔ)有服務(wù)器的證書鏈。此時(shí)， 服務(wù)器向客戶端返回ServerHello消息。進(jìn)行擴(kuò)展，在該消息中設(shè)置認(rèn)證字串?dāng)U展。釆用哈 希算法時(shí)，認(rèn)證字串?dāng)U展具體為證書哈希擴(kuò)展擴(kuò)展(certsjiash擴(kuò)展)。
與實(shí)施例二不同的是，服務(wù)器向客戶端返回ServerHello消息，但其中的 certs—hash擴(kuò)展的內(nèi)容為空，即其中不攜帶哈希值。通過ServerHello消息的 certs—hash擴(kuò)展的內(nèi)容為空表示服務(wù)器可以采用ClientHello消息中的哈希值對(duì) 應(yīng)的證書鏈。服務(wù)器和客戶端可以事先約定通過certs一hash擴(kuò)展的內(nèi)容為空 ServerHello消息表示可以釆用ClientHello消息中的"合希值對(duì)應(yīng)的證書鏈。
步驟303、服務(wù)器向客戶端發(fā)送Certificate消息，其中攜帶認(rèn)證字串值。
該步驟的內(nèi)容與實(shí)施例二不相同。
該步驟中，服務(wù)器向客戶端發(fā)送Certificate消息，該Certificate消息不攜帶 服務(wù)器的證書鏈，而是攜帶服務(wù)器的證書鏈的哈希值Certificate消息中包含的 哈希值與ClientHello消息中的certsjiash擴(kuò)展所包含的哈希值相同，表示服務(wù)器 可采用哈希值對(duì)應(yīng)的證書鏈。此時(shí)Certificate消息沒有攜帶服務(wù)器的證書鏈， 就避免了傳輸?shù)木薮箝_銷。
該實(shí)施例技術(shù)方案的效果與實(shí)施例二基本相同，主要區(qū)別是在服務(wù)器發(fā)送 的ServerHello消息中的certs—hash擴(kuò)展的內(nèi)容為空，服務(wù)器發(fā)送的Certificate消 息中攜帶哈希值。
上述描述的可以針對(duì)握手過程中的第一和第二階段的過程，對(duì)于第三和第 四階段的過程，也可以采用上述方法，避免客戶端需要通過Certificate消息向 服務(wù)器發(fā)送客戶端的證書鏈所帶來的巨大的傳輸開銷。
圖4是本發(fā)明實(shí)施例四消息傳輸方法流程圖，主要包括步驟
步驟401、服務(wù)器發(fā)送客戶端證書請(qǐng)求消息(CertificateRequest消息)，所 述CertificateRequest消息中攜帶認(rèn)證字串值；
該步驟中，服務(wù)器存儲(chǔ)有將要進(jìn)行通信的客戶端的證書鏈，該證書鏈可以 是上一次與客戶端進(jìn)行交互時(shí)所存儲(chǔ)的由客戶端發(fā)送的證書鏈，或者是通過其 他途徑獲取的客戶端的證書鏈。
CertificateRequest消息用于向客戶端請(qǐng)求發(fā)送客戶端的證書鏈。該步驟中， 服務(wù)器將CertificateR叫uest消息進(jìn)行擴(kuò)展，在該消息中設(shè)置認(rèn)證字串?dāng)U展，認(rèn)證字串?dāng)U展中的內(nèi)容稱為認(rèn)證字串值。如果認(rèn)證字串?dāng)U展中的內(nèi)容為空，則不 含有認(rèn)證字串值。認(rèn)證字串值是對(duì)證書鏈按設(shè)定算法進(jìn)行處理后得到的字串 值，可以反映證書鏈的特征。認(rèn)證字串值的字節(jié)數(shù)相對(duì)證書鏈的字節(jié)數(shù)較小。 本發(fā)明實(shí)施例中是以對(duì)證書鏈按哈希算法進(jìn)行處理得到哈希值舉例說明
但不局限于此，也可以按其他算法(例如循環(huán)冗余校驗(yàn)算法CRC)進(jìn)行處理得 到反映證書鏈特征的認(rèn)證字串值。其中，哈希算法可以是SHA-1、 SHA-2、 SHA-512或MD5等哈希算法中的任意一種，但通信雙方使用的哈希算法要一 致。
采用哈希算法時(shí)，服務(wù)器在CertificateR叫uest消息進(jìn)行擴(kuò)展的認(rèn)證字串字 段為證書哈希擴(kuò)展(certs—hash擴(kuò)展)，該certsjiash擴(kuò)展的內(nèi)容是服務(wù)器將存儲(chǔ) 的客戶端的證書鏈按哈希算法進(jìn)行處理得到的哈希值。
對(duì)CertificateR叫uest消息進(jìn)行擴(kuò)展的過程與實(shí)施例二中描述的基^f目同。
經(jīng)過上述處理，服務(wù)器向客戶端發(fā)送CertificateRequest消息，其中攜帶客 戶端的證書鏈的p合希值。
步驟402、客戶端向服務(wù)器發(fā)送Certificate消息，其中攜帶認(rèn)證字串值。
客戶端收到服務(wù)器發(fā)送的CertificateR叫uest消息后，查看certs—hash字段的 哈希值是否是客戶端設(shè)定的可以采用的證書鏈的哈希值?？蛻舳艘话憧梢栽O(shè)定 可采用的多種證書鏈，并且對(duì)證書鏈按設(shè)定算法進(jìn)行處理后得到認(rèn)證字串值， 例如得到哈希值。本發(fā)明實(shí)施例中以哈希值舉例說明。
客戶端如果確定CertificateRequest消息中certsjiash字段的哈希值是設(shè)定 的可以采用的證書鏈的哈希值，則可以認(rèn)為服務(wù)器已經(jīng)存儲(chǔ)有客戶端的證書 鏈。此時(shí)，客戶端向服務(wù)器返回Certificate消息。
客戶端向服務(wù)器返回的Certificate消息中不攜帶服務(wù)器的證書鏈，而是攜 帶服務(wù)器的證書鏈的哈希值。Certificate消息中的certs—hash字段所包含的哈希 值，與CertificateR叫uest消息中的certs—hash字段所包含的哈希值相同，表示可 以使用該哈希值對(duì)應(yīng)的證書鏈。此時(shí)Certificate消息沒有攜帶客戶端的證書鏈， 就避免了傳輸?shù)木薮箝_銷。
之后，服務(wù)器與客戶端的交互過程與現(xiàn)有過程基本相同。需要說明的是，客戶端如果確定CertificateRequest消息中certsjiash擴(kuò)展的 哈希值不是設(shè)定的可以采用的證書鏈的哈希值，則響應(yīng)的Certificate消息與現(xiàn) 有的握手過程一樣，在Certificate消息中攜帶客戶端的證書鏈，發(fā)送給服務(wù)器。 服務(wù)器將客戶端的Certificate消息中的證書鏈存儲(chǔ)，待收到服務(wù)器發(fā)送的完成 消息(finished消息)并且驗(yàn)證該消息正確后，替代之前存儲(chǔ)的證書鏈，并在 下 一 次與該客戶端進(jìn)行通信時(shí){吏用，即在CertificateRequest消息攜帶的 certs—hash擴(kuò)展中攜帶該新存儲(chǔ)的證書鏈的哈希值。
該實(shí)施例內(nèi)容可以看出，本發(fā)明實(shí)施例由于服務(wù)器已經(jīng)存儲(chǔ)有客戶端的證 書鏈，在向客戶端發(fā)送的CertificateR叫uest消息中攜帶認(rèn)證字串值，該認(rèn)證字 串值是根據(jù)客戶端的證書鏈生成，因此客戶端接收CertificateRequest消息后可 以認(rèn)為服務(wù)器已經(jīng)存儲(chǔ)客戶端的證書鏈，那么可以向服務(wù)器返回消息表示可以 采用CertificateR叫uest消息中的認(rèn)i正字串值對(duì)應(yīng)的證書鏈，該返回的消息可以 是攜帶與CertificateR叫uest消息中的認(rèn)證字串值相同的認(rèn)證字串值的 Certificate消息。這樣，客戶端就不再需要再向服務(wù)器發(fā)送客戶端的證書鏈， 因此就避免了因?yàn)閭鬏斂蛻舳说淖C書鏈帶來的巨大的傳輸開銷，特別是對(duì)于低 帶寬、高延遲、高誤碼率的網(wǎng)絡(luò)，可以帶來^f艮大好處。
另外，與前面實(shí)施例二的方案類似，上述過程也可以是
服務(wù)器在向客戶端發(fā)送的CertificateR叫uest消息中攜帶客戶端的證書鏈 的哈希值，客戶端向服務(wù)器發(fā)送的Certificate消息中的內(nèi)容為空，即其中不攜 帶哈希值，也不攜帶證書鏈。通過空消息表示客戶端可以釆用CertificateRequest 消息中的哈希值對(duì)應(yīng)的證書鏈。服務(wù)器和客戶端可以事先約定通過內(nèi)容為空的 Certificate消息表示可以采用CertificateRequest消息中的"合希值對(duì)應(yīng)的證書鏈。
上述內(nèi)容詳細(xì)介紹了本發(fā)明實(shí)施例的消息傳輸方法，相應(yīng)的，本發(fā)明實(shí)施 例提供一種網(wǎng)絡(luò)裝置和網(wǎng)絡(luò)系統(tǒng)。
圖5是本發(fā)明實(shí)施例網(wǎng)絡(luò)裝置結(jié)構(gòu)示意圖。
如圖5所示，網(wǎng)絡(luò)裝置包括*接收單元51、確定單元52、發(fā)送單元53。 接收單元51,用于接收第一消息，所述第一消息中攜帶才艮據(jù)證書鏈生成的 認(rèn)證字串值；確定單元52,用于確定所述第一消息中的認(rèn)證字串值是否為釆用的證書鏈 對(duì)應(yīng)的認(rèn)證字串值；
發(fā)送單元53,用于當(dāng)所述確定單元52確定所述第一消息中的認(rèn)證字串值為 采用的證書鏈對(duì)應(yīng)的認(rèn)證字串值時(shí)，發(fā)送第二消息，所述第二消息表明采用所 述第一消息中的認(rèn)證字串值對(duì)應(yīng)的證書鏈。
當(dāng)所述網(wǎng)絡(luò)裝置為服務(wù)器時(shí)；所述接收單元5 l接收的第 一消息包括客戶端 發(fā)現(xiàn)消息；所述發(fā)送單元53發(fā)送的第二消息包括服務(wù)器發(fā)現(xiàn)消息，所述服務(wù)器 發(fā)現(xiàn)消息攜帶與所述客戶端發(fā)現(xiàn)消息中的認(rèn)證字串值相同的認(rèn)證字串值；或 者，攜帶認(rèn)證字串值為空的認(rèn)證字串?dāng)U展；發(fā)送單元53還可以發(fā)送第一證書消 息，所述第一證書消息攜帶與所述客戶端發(fā)現(xiàn)消息中的認(rèn)證字串值相同的認(rèn)證 字串值；或者，所述第一證書消息中的內(nèi)容為空?；蛘撸?br> 當(dāng)所述網(wǎng)絡(luò)裝置為服務(wù)器時(shí)；所述接收單元51接收的第一消息包括客戶端 發(fā)現(xiàn)消息；所述發(fā)送單元53發(fā)送的第二消息包括第一證書消息，所述第一證書
述第 一證書消息中的內(nèi)容為空。
當(dāng)所述網(wǎng)絡(luò)裝置為客戶端時(shí)；所述接收單元5l接收的第一消息包括客戶端 證書請(qǐng)求消息；所述發(fā)送單元53發(fā)送的第二消息包括第二i正書消息，所述第二 證書消息攜帶與所述客戶端證書請(qǐng)求消息中的認(rèn)證字串值相同的認(rèn)證字串值； 或者，所述第二證書消息中的內(nèi)容為空。
另夕卜，當(dāng)確定單元52確定所述第一消息中的認(rèn)證字串值為非采用的證書鏈 對(duì)應(yīng)的認(rèn)證字串值時(shí)，發(fā)送單元53可以發(fā)送第三消息，所述第三消息攜帶采用 的i正書鏈。
上述所說的認(rèn)證字串值為證書鏈的哈希值。 圖6是本發(fā)明實(shí)施例網(wǎng)絡(luò)系統(tǒng)結(jié)構(gòu)示意圖。 如圖6所示，網(wǎng)絡(luò)系統(tǒng)包括第一裝置61、第二裝置62。 第一裝置61,用于發(fā)送第一消息，所述第一消息中攜帶根據(jù)證書鏈生成的 iU正字串值；
第二裝置62,用于接收所述第一消息；當(dāng)確定所述第一消息中的認(rèn)證字串值為采用的證書鏈對(duì)應(yīng)的認(rèn)證字串值時(shí)，發(fā)送第二消息，所述第二消息表明采 用所述第 一消息中的認(rèn)證字串值對(duì)應(yīng)的證書鏈。第一裝置61為客戶端，第二裝置62為服務(wù)器；或者，第一裝置61為服務(wù)器， 第二裝置62為客戶端。第一裝置61或第二裝置62的具體結(jié)構(gòu)，可以參見圖5中的描述，此處不 再贅述。綜上所述，本發(fā)明實(shí)施例由于接收的第一消息中攜帶根據(jù)證書鏈生成的認(rèn) 證字串值，因此接收端接收第一消息后如果確定所述第一消息中的認(rèn)證字串值 為釆用的證書鏈對(duì)應(yīng)的認(rèn)證字串值，則可以認(rèn)為發(fā)送端已經(jīng)存儲(chǔ)相應(yīng)的證書 鏈，那么可以向發(fā)送端返回第二消息表明采用所述第一消息中的認(rèn)證字串值對(duì) 應(yīng)的證書鏈，就不再需要再向發(fā)送端發(fā)送證書鏈，因此就避免了因?yàn)閭鬏斪C書 鏈帶來的巨大的傳輸開銷。進(jìn)一步的，無論是針對(duì)服務(wù)器需要向客戶端發(fā)送服務(wù)器的證書鏈，或者是 客戶端需要向服務(wù)器發(fā)送客戶端的證書鏈的場(chǎng)景，都能適用。本領(lǐng)域普通技術(shù)人員可以理解上述實(shí)施例的各種方法中的全部或部分步 驟是可以通過程序來指令相關(guān)的硬件來完成，該程序可以存儲(chǔ)于一計(jì)算機(jī)可讀 存儲(chǔ)介質(zhì)中，存儲(chǔ)介質(zhì)可以包括只讀存儲(chǔ)器(ROM, Read Only Memory )、 隨才幾存^^"儲(chǔ)器(RAM, Random Access Memory )、》茲盤或光盤等。以上對(duì)本發(fā)明實(shí)施例所提供的一種消息傳輸方法、網(wǎng)絡(luò)裝置及網(wǎng)絡(luò)系統(tǒng)進(jìn)對(duì)于本領(lǐng)域的一般技術(shù)人員，依據(jù)本發(fā)明的思想，在具體實(shí)施方式
及應(yīng)用范圍 上均會(huì)有改變之處，綜上所述，本說明書內(nèi)容不應(yīng)理解為對(duì)本發(fā)明的限制。
權(quán)利要求
1、一種消息傳輸方法，其特征在于，包括接收第一消息，所述第一消息中攜帶根據(jù)證書鏈生成的認(rèn)證字串值；當(dāng)確定所述第一消息中的認(rèn)證字串值為采用的證書鏈對(duì)應(yīng)的認(rèn)證字串值時(shí)，發(fā)送第二消息，所述第二消息表明采用所述第一消息中的認(rèn)證字串值對(duì)應(yīng)的證書鏈。
2、 根據(jù)權(quán)利要求l所述的消息傳輸方法，其特征在于 所述接收的第 一 消息包括客戶端發(fā)現(xiàn)消息；所述發(fā)送的第二消息包括服務(wù)器發(fā)現(xiàn)消息，所述服務(wù)器發(fā)現(xiàn)消息攜帶與所 述客戶端發(fā)現(xiàn)消息中的認(rèn)證字串值相同的認(rèn)證字串值；或者，攜帶認(rèn)證字串值 為空的i人證字串?dāng)U展。
3、 根據(jù)權(quán)利要求2所述的消息傳輸方法，其特征在于 所述發(fā)送服務(wù)器發(fā)現(xiàn)消息后還包括發(fā)送第一證書消息，所述第一證書消息攜帶與所述客戶端發(fā)現(xiàn)消息中的認(rèn)證字串值相同的認(rèn)證字串值；或者，所述 第一證書消息中的內(nèi)容為空。
4、 根據(jù)權(quán)利要求l所述的消息傳輸方法，其特征在于 所述接收的第 一消息包括客戶端發(fā)現(xiàn)消息；所述發(fā)送的第二消息包括第一證書消息，所述第 一證書消息攜帶與所M 戶端發(fā)現(xiàn)消息中的認(rèn)證字串值相同的認(rèn)證字串值；或者，所述第一證書消息中 的內(nèi)容為空。
5、 根據(jù)權(quán)利要求l所述的消息傳輸方法，其特征在于 所述接收的第 一消息包括客戶端證書請(qǐng)求消息；所述發(fā)送的第二消息包括第二證書消息，所述第二證書消息攜帶與所述客 戶端證書請(qǐng)求消息中的認(rèn)證字串值相同的認(rèn)"i正字串值；或者，所述第二"i正書消 息中的內(nèi)容為空。
6、 根據(jù)權(quán)利要求1至5任一項(xiàng)所述的消息傳輸方法，其特征在于當(dāng)確定所述第 一消息中的認(rèn)證字串值為非采用的證書鏈對(duì)應(yīng)的認(rèn)證字串 值時(shí)，發(fā)送第三消息，所述第三消息攜帶采用的證書鏈。
7、 根據(jù)權(quán)利要求1至5任一項(xiàng)所述的消息傳輸方法，其特征在于所述認(rèn)證字串值為證書鏈的哈希值。
8、 一種網(wǎng)絡(luò)裝置，其特征在于，包括接收單元，用于接收第一消息，所述第一消息中攜帶才艮據(jù)證書鏈生成的認(rèn)確定單元，用于確定所述第一消息中的認(rèn)證字串值是否為采用的證書鏈對(duì) 應(yīng)的認(rèn)證字串值；發(fā)送單元，用于當(dāng)所述確定單元確定所述第 一 消息中的認(rèn)證字串值為采用 的證書鏈對(duì)應(yīng)的認(rèn)證字串值時(shí)，發(fā)送第二消息，所述第二消息表明釆用所述第 一消息中的認(rèn)證字串值對(duì)應(yīng)的證書鏈。
9、 根據(jù)權(quán)利要求8所述的網(wǎng)絡(luò)裝置，其特征在于 所述網(wǎng)絡(luò)裝置為服務(wù)器；所述接收單元接收的第 一 消息包括客戶端發(fā)現(xiàn)消息； 所述發(fā)送單元發(fā)送的第二消息包括服務(wù)器發(fā)現(xiàn)消息，所述服務(wù)器發(fā)現(xiàn)消息證字串值為空的認(rèn)證字串?dāng)U展。
10、 根據(jù)權(quán)利要求9所述的網(wǎng)絡(luò)裝置，其特征在于所述發(fā)送單元在發(fā)送服務(wù)器發(fā)現(xiàn)消息后，還發(fā)送第一證書消息，所述第一 證書消息攜帶與所述客戶端發(fā)現(xiàn)消息中的認(rèn)證字串值相同的認(rèn)證字串值；或 者，所述第一證書消息中的內(nèi)容為空。
11、 根據(jù)權(quán)利要求8所述的網(wǎng)絡(luò)裝置，其特征在于 所述網(wǎng)絡(luò)裝置為服務(wù)器；所述接收單元接收的第 一 消息包括客戶端發(fā)現(xiàn)消息；所述發(fā)送單元發(fā)送的第二消息包括第 一證書消息，所述第 一證書消息攜帶 與所述客戶端發(fā)現(xiàn)消息中的認(rèn)證字串值相同的認(rèn)證字串值；或者，所述第一證 書消息中的內(nèi)容為空。
12、 根據(jù)權(quán)利要求8所述的網(wǎng)絡(luò)裝置，其特征在于 所述網(wǎng)絡(luò)裝置為客戶端；所述接收單元接收的第 一消息包括客戶端證書請(qǐng)求消息；所述發(fā)送單元發(fā)送的第二消息包括第二證書消息，所述第二證書消息攜帶與所述客戶端證書請(qǐng)求消息中的認(rèn)證字串值相同的iU正字串值；或者，所述第 二證書消息中的內(nèi)容為空。
13、 一種網(wǎng)絡(luò)系統(tǒng)，其特征在于，包括第一裝置，用于發(fā)送第一消息，所述第一消息中攜帶根據(jù)證書鏈生成的認(rèn) i正字串值；第二裝置，用于接收所述第一消息；當(dāng)確定所述第一消息中的認(rèn)證字串值 為采用的證書鏈對(duì)應(yīng)的認(rèn)證字串值時(shí)，發(fā)送第二消息，所述第二消息表明采用 所述第 一消息中的認(rèn)證字串值對(duì)應(yīng)的證書鏈。
全文摘要
本發(fā)明實(shí)施例公開一種消息傳輸方法、網(wǎng)絡(luò)裝置及網(wǎng)絡(luò)系統(tǒng)。該消息傳輸方法包括接收第一消息，所述第一消息中攜帶根據(jù)證書鏈生成的認(rèn)證字串值；當(dāng)確定所述第一消息中的認(rèn)證字串值為采用的證書鏈對(duì)應(yīng)的認(rèn)證字串值時(shí)，發(fā)送第二消息，所述第二消息表明采用所述第一消息中的認(rèn)證字串值對(duì)應(yīng)的證書鏈。相應(yīng)的，本發(fā)明實(shí)施例還提供一種網(wǎng)絡(luò)裝置及網(wǎng)絡(luò)系統(tǒng)。本發(fā)明實(shí)施例提供的技術(shù)方案能夠減小傳輸開銷。
文檔編號(hào)H04L9/32GK101534262SQ200910132348
公開日2009年9月16日 申請(qǐng)日期2009年3月30日 優(yōu)先權(quán)日2009年3月30日
發(fā)明者敏 黃 申請(qǐng)人:成都市華為賽門鐵克科技有限公司