[發(fā)明專利]一種實(shí)現(xiàn)負(fù)載均衡持續(xù)性的方法和設(shè)備

無效

• 申請(qǐng)?zhí)枺?/td>: 201010131388.0
• 申請(qǐng)日: 2010-03-24
• 公開（公告）號(hào): CN101783771A
• 公開（公告）日: 2010-07-21
• 發(fā)明（設(shè)計(jì)）人: 張峻;于洪強(qiáng);蔡志峰
• 申請(qǐng)（專利權(quán)）人: 杭州華三通信技術(shù)有限公司
• 主分類號(hào): H04L12/56
• 分類號(hào): H04L12/56;H04L29/06;H04L29/08
• 代理公司: 北京鑫媛睿博知識(shí)產(chǎn)權(quán)代理有限公司 11297
• 代理人: 龔家驊

技術(shù)領(lǐng)域

本發(fā)明涉及通信技術(shù)領(lǐng)域，特別涉及一種實(shí)現(xiàn)負(fù)載均衡持續(xù)性的方法和設(shè)備。

背景技術(shù)

由于目前現(xiàn)有網(wǎng)絡(luò)的各個(gè)核心部分隨著業(yè)務(wù)量的提高，訪問量和數(shù)據(jù)流量的快速增長，其處理能力和計(jì)算強(qiáng)度也相應(yīng)地增大，使得單一的服務(wù)器設(shè)備根本無法承擔(dān)。在此情況下，如果扔掉現(xiàn)有設(shè)備去做大量的硬件升級(jí)，這樣將造成現(xiàn)有資源的浪費(fèi)，而且如果再面臨下一次業(yè)務(wù)量的提升時(shí)，這又將導(dǎo)致再一次硬件升級(jí)的高額成本投入，甚至性能再卓越的設(shè)備也不能滿足當(dāng)前業(yè)務(wù)量增長的需求。為此，引入了負(fù)載均衡(Load?Balance，LB)技術(shù)解決這樣的問題。

在現(xiàn)有技術(shù)中，典型的負(fù)載均衡組網(wǎng)如圖1所示。客戶端將請(qǐng)求發(fā)送給服務(wù)器群前端的負(fù)載均衡設(shè)備，該請(qǐng)求的目的網(wǎng)絡(luò)互聯(lián)協(xié)議(Internet?Protocol，IP)地址為虛服務(wù)網(wǎng)絡(luò)互聯(lián)協(xié)議(Virtual?Service?IP，VSIP)地址，負(fù)載均衡設(shè)備上的虛服務(wù)接收客戶端請(qǐng)求，通過調(diào)度算法，選擇一個(gè)真實(shí)服務(wù)器，將請(qǐng)求發(fā)送給選定的真實(shí)服務(wù)器，真實(shí)服務(wù)器的響應(yīng)報(bào)文通過負(fù)載均衡設(shè)備再返回給客戶，完成整個(gè)負(fù)載均衡調(diào)度過程。

一次業(yè)務(wù)交互可能包括多個(gè)傳輸控制協(xié)議(Transmission?Control?Protocol，TCP)連接，如超文本傳輸協(xié)議(Hyper?Text?Transfer?Protocol，HTTP)應(yīng)用。這些TCP連接間有關(guān)聯(lián)關(guān)系，如HTTP網(wǎng)絡(luò)購物，多條連接組成一次業(yè)務(wù)應(yīng)用，但所有該業(yè)務(wù)的請(qǐng)求應(yīng)發(fā)給同一服務(wù)器，否則可能造成無法完成所請(qǐng)求的功能。將多個(gè)連接持續(xù)重定向到同一個(gè)真實(shí)服務(wù)器的策略，就是持續(xù)性功能。

HTTP協(xié)議是無狀態(tài)協(xié)議，無狀態(tài)是指協(xié)議對(duì)于事務(wù)處理沒有記憶能力，但是很多HTTP業(yè)務(wù)是需要事務(wù)處理的記憶性的，如電子商務(wù)等。HTTP?Session(HTTP會(huì)話)機(jī)制就是一種在客戶端與服務(wù)器之間保持狀態(tài)的解決方案，該機(jī)制是一種服務(wù)器端的機(jī)制，服務(wù)器通常使用一種類似于散列表的結(jié)構(gòu)來保存信息。

當(dāng)服務(wù)器為某個(gè)客戶端的請(qǐng)求創(chuàng)建一個(gè)會(huì)話(Session)時(shí)，服務(wù)器首先檢查這個(gè)客戶端的請(qǐng)求里是否已包含了會(huì)話標(biāo)識(shí)(Session?ID)。

如果已包含一個(gè)Session?ID，則說明以前已經(jīng)為此客戶端創(chuàng)建過Session，服務(wù)器就按照Session?ID把這個(gè)Session檢索出來使用；如果客戶端請(qǐng)求不包含Session?ID，則為此客戶端創(chuàng)建一個(gè)Session并且生成一個(gè)與此Session相關(guān)聯(lián)的Session?ID，這個(gè)Session?ID將被在本次響應(yīng)中返回給客戶端保存。

保存這個(gè)Session?ID的方式可以采用Cookie和URL(Uniform?ResourceLocators，統(tǒng)一資源定位符)重寫方式，這樣后續(xù)交互過程中瀏覽器可以這個(gè)標(biāo)識(shí)發(fā)回給服務(wù)器。

其中，URL重寫就是服務(wù)器把Session?ID直接附加在URL路徑的后面，附加方式有兩種，一種是作為URL路徑的附加信息，表現(xiàn)形式為：

http://...../xxx；sessionid＝abcd，

另一種是作為查詢字符串附加在URL后面，表現(xiàn)形式為：

http://...../xxx？sessionid＝abcd，

這兩種方式對(duì)于用戶來說是沒有區(qū)別的，只是服務(wù)器在解析時(shí)處理的方式不同。

其中，HTTP?URL的基本格式如下：

″http:″″//″host[″：″port][abs_path[″；″params][″？″query]]

一條比較完整的HTTP?URL例子如下：

http://www.google.com：80/intl/index.htm；acount＝tom？sessionid＝abcd

其中，params稱為URL路徑的附加信息，query稱為查詢字符串。

在實(shí)現(xiàn)本發(fā)明的過程中，發(fā)明人發(fā)現(xiàn)現(xiàn)有技術(shù)中的Cookie和URL重寫方式分別存在以下問題：

1、Cookie功能可以被用戶禁用。這種情況下用戶瀏覽器不會(huì)把Cookie標(biāo)識(shí)發(fā)回給服務(wù)器，從而負(fù)載均衡設(shè)備就無法通過Cookie持續(xù)性保證一次交互中的多次連接都能發(fā)給同一個(gè)真實(shí)服務(wù)器。