一種基于安全套接層協(xié)議特征的負載分發(fā)方法
【技術(shù)領(lǐng)域】
[0001]本發(fā)明屬于計算機網(wǎng)絡(luò)技術(shù)領(lǐng)域，具體涉及一種基于安全套接層協(xié)議特征的負載分發(fā)方法。
【背景技術(shù)】
[0002]隨著互聯(lián)網(wǎng)用戶的急劇增長，獲取信息的速度快慢已經(jīng)成為制約互聯(lián)網(wǎng)發(fā)展的重要因素。由于現(xiàn)有網(wǎng)絡(luò)的各個核心部分隨著業(yè)務(wù)量的提高，訪問量和數(shù)據(jù)流量的快速增長，其處理能力和計算強度也相應(yīng)地增大，使得單一的服務(wù)器設(shè)備根本無法承擔(dān)。
[0003]負載均衡就是將負載(工作任務(wù))進行平衡、分攤到多個操作單元上進行執(zhí)行，例如Web服務(wù)器、FTP服務(wù)器、企業(yè)關(guān)鍵應(yīng)用服務(wù)器和其它關(guān)鍵任務(wù)服務(wù)器等，從而共同完成工作任務(wù)。
[0004]通常，負載均衡會根據(jù)網(wǎng)絡(luò)的不同層次(網(wǎng)絡(luò)七層)來劃分。近幾年來，四到七層網(wǎng)絡(luò)負載均衡首先在電信、移動、銀行、大型網(wǎng)站等單位進行了應(yīng)用，因為其網(wǎng)絡(luò)流量瓶頸的現(xiàn)象最突出。
[0005]當(dāng)前四層的負載均衡分發(fā)技術(shù)主要根據(jù)后臺服務(wù)器負載情況將TCP/IP網(wǎng)絡(luò)的數(shù)據(jù)包進行分發(fā)，分發(fā)時主要依據(jù)數(shù)據(jù)包中的源地址、目標地址、源端口、目標端口信息。
[0006]四層的負載均衡，就是通過發(fā)布三層的IP地址(VIP)，然后加四層的端口號，來決定哪些流量需要做負載均衡，對需要處理的流量進行NAT處理，轉(zhuǎn)發(fā)至后臺服務(wù)器，并記錄下這個TCP或者UDP的流量是由哪臺服務(wù)器處理的，后續(xù)這個連接的所有流量都同樣轉(zhuǎn)發(fā)到同一臺服務(wù)器處理。七層的負載均衡，就是在四層的基礎(chǔ)上再考慮應(yīng)用層的特征，比如同一個Web服務(wù)器的負載均衡，除了根據(jù)VIP加80端口辨別是否需要處理的流量，還可根據(jù)七層的URL、瀏覽器類別、語言來決定是否要進行負載均衡。
[0007]隨著電子商務(wù)業(yè)務(wù)的不斷發(fā)展壯大，越來越多的電子商務(wù)應(yīng)用采用安全套接層(TLS/SSL)技術(shù)來保護后臺業(yè)務(wù)，采用安全套接層(TLS/SSL)技術(shù)以后，普遍的七層負載均衡由于HTTP協(xié)議數(shù)據(jù)被加密，無法根據(jù)HTTP協(xié)議(如URL，瀏覽器類型、語言等)來進行負載分發(fā)，為了進行正確的分發(fā)，可使用安全套接層(TLS/SSL)協(xié)議對數(shù)據(jù)包進行解密，然后根據(jù)應(yīng)用數(shù)據(jù)進行負載分發(fā)，這樣就導(dǎo)致存在如下問題:
[0008]I)分發(fā)效率的降低，負載均衡設(shè)備必須進行了多余的解密操作；
[0009]2)造成信息的泄露，負載均衡設(shè)備不應(yīng)獲得加密的內(nèi)容。

【發(fā)明內(nèi)容】

[0010]本發(fā)明的目的在于克服現(xiàn)有技術(shù)的不足，提供一種分發(fā)效率高且安全可靠的基于安全套接層協(xié)議特征的負載分發(fā)方法。
[0011]為實現(xiàn)以上目的，本發(fā)明采用如下技術(shù)方案:一種基于安全套接層協(xié)議特征的負載分發(fā)方法，其特征在于:該方法包括如下步驟:
[0012]S1、從網(wǎng)絡(luò)上獲取IP數(shù)據(jù)包；
[0013]S2、解析出IP數(shù)據(jù)包的頭部信息并保存；
[0014]S3、判斷IP數(shù)據(jù)包是否為SSL協(xié)議數(shù)據(jù)，若判斷結(jié)果為真，則執(zhí)行步驟S4，若判斷結(jié)果為假，則過程結(jié)束；
[0015]S4、獲取IP數(shù)據(jù)包中IP包載荷部分中的算法套件類型；
[0016]S5、根據(jù)不同的算法套件類型構(gòu)造不同的負載分發(fā)策略。
[0017]進一步，所述步驟S2中IP數(shù)據(jù)包的頭部信息包括源地址、源端口、目標地址和目標端口 O
[0018]進一步，所述步驟S3包括如下步驟:S21、從頭部信息中讀取IP包載荷部分前3個字節(jié)中的SSL握手消息類型和協(xié)議版本號；S22、根據(jù)步驟S21中的SSL握手消息類型和協(xié)議版本號判斷是否為SSL協(xié)議。
[0019]進一步，所述步驟S4包括如下步驟:S41、從頭部信息中讀取IP包載荷部分從第4至第46共計43個字節(jié)內(nèi)容；S42、從步驟S41中的43個字節(jié)之最后3字節(jié)中獲取算法套件之長度標識位內(nèi)容和算法套件長度內(nèi)容；S43、判斷步驟S42中最后3個字節(jié)內(nèi)容是否為00Xl x2，若算法套件之長度標識位內(nèi)容為真，則獲取xl x2字節(jié)內(nèi)容；S44、將步驟S43中獲取的xl x2字節(jié)內(nèi)容作為算法套件類型，并執(zhí)行步驟S5。
[0020]進一步，所述步驟S43中，若算法套件之長度標識位內(nèi)容為假，則進一步做如下處理:S431、進一步判斷步驟S42中最后3個字節(jié)內(nèi)容是否為20 yl y2，若算法套件之長度標識位內(nèi)容為真，則獲取yl 12字節(jié)內(nèi)容；若為假，則過程結(jié)束；S432、將步驟S431中獲取的yl y2字節(jié)內(nèi)容作為算法套件類型，并執(zhí)行步驟S5。
[0021]本發(fā)明采用以上技術(shù)方案，獲取IP數(shù)據(jù)包中IP包載荷部分中的算法套件類型；根據(jù)不同的算法套件類型構(gòu)造不同的負載分發(fā)策略。與現(xiàn)有技術(shù)相比，不需要對安全套接層(TLS/SSL)數(shù)據(jù)包進行解密操作就可以進行負載分發(fā)，本發(fā)明使用安全套接層(TLS/SSL)協(xié)議數(shù)據(jù)包的特征動態(tài)構(gòu)造負載分發(fā)策略，分發(fā)效率高且安全可靠。
[0022]本發(fā)明還具有如下優(yōu)點:
[0023]I)、因僅需要檢查IP包載荷的內(nèi)容，使得實現(xiàn)構(gòu)造分發(fā)策略的難度和復(fù)雜度顯著降低；
[0024]2)、因?qū)崿F(xiàn)難度和復(fù)雜度較低，可在操作系統(tǒng)內(nèi)核或系統(tǒng)驅(qū)動內(nèi)實現(xiàn)，明顯減少數(shù)據(jù)處理的層次。
【附圖說明】
[0025]圖1是本發(fā)明基于安全套接層協(xié)議特征的負載分發(fā)方法之IP包載荷部分結(jié)構(gòu)示意圖之一；
[0026]圖2是本發(fā)明基于安全套接層協(xié)議特征的負載分發(fā)方法之IP包載荷部分結(jié)構(gòu)示意圖之二 ；
[0027]圖3是本發(fā)明基于安全套接層協(xié)議特征的負載分發(fā)方法的流程圖。
【具體實施方式】
[0028]為了使本發(fā)明的目的、技術(shù)方案及優(yōu)點更加清楚明白，下面對IP包載荷部分結(jié)構(gòu)示意圖做說明。
[0029]如圖1所示，前三個字節(jié)為SSL握手消息類型(0x16) +協(xié)議版本號(0x030x02)；
[0030]接下來的43個字節(jié)包括的內(nèi)容有:
[0031]a) 2個字節(jié)的長度，具體為握手包長度；
[0032]b) I個字節(jié)的類型標識(01表示ClientHello消息);
[0033]c) 3個字節(jié)的長度，具體為ClientHello消息長度；
[0034]d) 2個字節(jié)的版本號；
[0035]e) 32個字節(jié)的隨機數(shù)；
[0036]f)最后3個字節(jié)中第一個字節(jié)為算法套件之長度標識位；
[0037]g) length長度的算法套件類型，每個類型2字節(jié)
[0038]3)需搜索的長度范圍不超過f)子項的長度length
[0039]如圖2所示，前三個字節(jié)為SSL握手消息類型(0x16) +協(xié)議版本號(0x030x02)；
[0040]接下來的43個字節(jié)包括的內(nèi)容有:
[0041]a) 2個字節(jié)的長度，具體為握手包長度；
[0042]b) I個字節(jié)的類型標識(01表示ClientHello消息)
[0043]c) 3個字節(jié)的長度，具體為ClientHello消息長度；
[0044]d) 2個字節(jié)的版本號
[0045]e) 32個字節(jié)的隨機數(shù)
[004