IP电话中RADIUS服务器负载平衡的设计与实现
大型VOIP系统RADIUS服务器的设计与分析
大型VOIP系统RADIUS服务器的设计与分析李亚鹏，马跃北京邮电大学计算机科学与技术学院，北京（100876）E-mail：liyapeng8319@摘要：本文重点讨论了一种大型VOIP系统RADIUS服务器的设计方法，并给出了采用Java 语言结合Hibernate和线程池技术的具体实现方案。
关键词：VOIP，RADIUS，多线程，线程池，Hibernate1.引言VoIP产品越来越多的走向市场，对于其计费管理系统的需求也越来越大。
RADIUS(Remote Authentication Dial-In User Service)协议是一种访问服务器NAS认证和记账协议，现在被越来越多的应用在VOIP设备的认证与计费上。
随着VOIP技术的发展，终端用户的数量会急剧增长，业务种类也会越来越多，这时作为认证与计费中枢系统的RADIUS 服务器的负荷会越来越大。
如何使其做到响应迅速，数据处理功能强大是设计和实现RADIUS服务器的关键。
基于以上问题，本文提出了了一种采用面向对象的语言——Java编程语言，对RADIUS 服务器进行设计和实现的可行方案，并采用Hibernate和线程池技术对RADIUS服务器进行最大程度的优化，使其能较好的运行在大型的VOIP系统中。
在本文中，拟以北京万林克通信技术有限公司的网守作为典型的VOIP设备进行讨论，介绍我们的RADIUS服务器实现方案。
2.RADIUS协议介绍RADIUS（Remote Address Dial-In User Service）协议是目前广泛使用的对远程用户集中认证和记账的协议。
RFC2865、RFC2866定义了RADIUS的认证和记账标准。
RADIUS数据包被封装在UDP数据报的数据块中，其中的默认目的端口为1812[1]。
具体的数据包结构如图1所示。
8位8位 16位编号(Code) 标识符(Identifier)长度(Length)认证(Authenticator) 128位属性(Attributes)… 变长图1 RADIUS数据包结构图标识符：长度为8位，标识消息类型。
Radius负载均衡配置指导书
Radware Radius负载均衡配置指导书Table of Contents目录第1章AppDirector产品介绍 (3)1.1 Radware基本概念 (3)第2章主AD设备配置 (6)第3章初始化AD设备 (7)3.1 连接AD设备 (7)3.2 登录AD设备 (9)3.3 确认当前设备的版本 (10)3.4 查看当前设备的License (11)3.5 初始化AD设备 (11)第4章WEB配置 (14)4.1 登录WEB管理界面 (14)4.2 配置端口IP地址 (15)4.3 配置路由 (17)4.4 配置farm (18)4.5 配置负载均衡算法中的Radius属性 (20)4.6 配置L4 Policy (22)4.7 配置server (23)4.8 配置server NAT (24)第5章健康检查配置 (26)5.1 全局打开高级健康检查功能 (26)5.2 设置Check Table (26)5.3 设置Bining Table (29)5.4 修改Farm Table (30)5.5 查看健康检查结果 (30)第6章主备AD冗余配置 (31)6.1 配置冗余方式 (31)6.2 配置Selective Interface Grouping (31)6.3 配置Virtual Router (32)6.4 配置浮动ip (33)6.5 配置端口Associated IP (34)第7章启动主备冗余 (35)7.1 基本配置 (35)7.2 启动冗余 (36)7.3 配置会话表镜像 (36)Table of Contents 目录第1章AppDirector产品介绍 (3)1.1 Radware基本概念 (3)第2章主AD设备配置 (6)第3章初始化AD设备 (7)第4章WEB配置 (14)第5章健康检查配置 (26)第6章主备AD冗余配置 (31)第7章 3.5启动主备冗余 (35)AppDirector产品介绍AppDirector产品有一系列产品，从低端到高端产品分别是AD200/202、AD1000、AD3020和AD6000，对应的产品相关指标分别如下，对于AppDirector产品而言处理的关键在于处理流量的大小,以下简称AD。
校园网IP电话的设计与实现
（ 三 ）Ｖ ｏ Ｉ Ｐ网络 配 置过 程
（ 一 ）网络的基本要求
目前 ，大多数高校都具有 比较完备的校园网 ， 网 络 出 口带 宽 充 裕 ，所 以 在 校 园 网 中 部 署 Ｖ ｏ Ｉ Ｐ
Ｉ ｐ ａ ｄ ｄ ｒ ｅ ｓ ｓ １ ． １ ． １ ． １ ２５ ５． ２５ ５ ． ２５ ５． ０ ．
音模块 比如 Ｆ Ｘ Ｏ、Ｅ ＆ Ｍ、Ｅ Ｉ Ｖ Ｉ 、Ｆ Ｘ Ｓ等。 在校园网中组建 Ｖ ｏ Ｉ Ｐ语音通信 网可利用 Ｐ Ｂ Ｘ 交 换机 和 路 由器语 音 网关 为 核心进 行 配置 ，它 们 之
一
／ ／ 进入 Ｅ ｔ ｈ ｅ ｍｅ ｔ 口
／ ／ 在ｅ ｔ ｈ ｅ ｍｅ ｔ 口封 装 ８ ０ ２ ． １ ｑ协 议
Ｄｉ ａ ｌ — ｐｅ ｅ ｒ ｖ ｏ ｉ ｃ ｅ Ｉ ｐ ｏ ｔ ｓ Ｄｅ ｓ ｔ ｉ ｎ ａ ｔ ｉ ｏ ｎ －ｐ ａ ｔ ｔ ｅ ｎ ｒ ０１ ０１ ０１
音信号 ，然后通过 Ｉ ｎ ｔ ｅ ｍ ｅ ｔ 传送到被 叫用户的网关 端 ，由被叫端的网关进行分组数据 的解包 、解压和
解 码 ，还原为可被识别 的模拟语音 信号 ，再 通过 Ｐ Ｓ Ｔ Ｎ 传到被叫方的终端。这就完成 了一个 完整 的
Ｉ Ｐ电话通 信过 程 。
三、 Ｉ Ｐ电话 的设计 与 实现
置
ｓ ｉ ｐ ／ ／ 启用 Ｓ Ｉ Ｐ 协议 Ｖ ｏ ｉ ｃ ｅ — ｓ ｅ ｔ ｕ ｐ ／ ／ 进 入语 音 特性 设
Ｄｉ ａ ｌ － ｐ ｒ ｏ ｇ ｒ ａ ｍ
ｅ ｎｔ ｉ ｔ ｙ ７ ５ ５ Ｖｏ Ｉ Ｐ
Radware福建省电信Radius服务器及Web认证服务器负载均衡解决方案
作为网络运营商为公众提供服务，精准的认证计费系统将是保证业务发展的基础。
而针对不同类型的用户，必须提供不同的认证计费方式。
因此，在此次升级改造中，主要作任务是建设一个更高处理能力的Radius认证计费系统与一个简单便捷的WEB认证计费系统。
对应用的支持：通过多种手段正确判断服务器的健康状况,识别不同的会话，支持会话保持功能。
三、Radware解决方案二、客户需求·根据应用定制负载均衡解决方案Radware AppDirector针对应用服务提供了定制的负载均AppDirector毫秒级故障切换技术，确保了Radius服务系统的不间断运行。
先进的服务器管理技术AppDirector可以对不同性能的服务器进行加权计算，对性能好的服务器可以多分担一些流量。
对有用户数限制的服务器，AppDirector通过连接数限制技术，从而保证服务器连接不会超过限制，同时也保证了性能一般的服务器不会因为连接太多而宕机。
同时AppDirector还有ShutdownTime，Recovery Time，Warm up Time，Port Multiplexing 等技术，针对于服务器在关机，重起暖身至正常工作的每一个阶段所应采取的相应的方式来加强服务器的管理。
扩充能力灵活AppDirector与任何品牌、使用界面、操作系统的网络服务器均兼容，在安装时完全不须改变企业原有的网路架构。
当您为业务扩充而更新网络服务器，新设备只要与AppDi-rector连接，您不须费时集成新旧设备、或统合协定机制。
因此AppDirector 使您对网络服务器的投资更为灵活，随时依企业需求而弹性更新网络架构；若您的企业将扩张至全球，AppDirector灵活的扩充能力，帮助您轻松加入全球服务的行列。
同时，两台AppDirector互为备份，并可以向用户提供最快100ms的故障切换能力，从而最大程度地提高服务器系统的有效性与持续性。
IP网络电话网建设设计方案
IP网络网建设设计方案iP方案设计一、IP网络体系结构IP网络技术是一个正在迅速发展的新兴网络技术，因此有关IP网络的技术以及有关的标准还处在不停变化的阶段。
目前，关于IP的标准主要有IETF的SGCP/MGCP和来自多媒体电视会议系统标准的H323协议。
SGCP/MGCP的标准是将来发展的一个方向，但它还在制定过程中，没有成熟，也没有实际的产品支持它。
实际上，目前大多数IP采用的基本上是的H.323体系结构。
因此，在目前的情况下，我们建议采用H.323协议来组建IP网络。
H.323本来是为在已有的局域网上运行多媒体系统而设计的。
它描述了将实时的语音、图像数据传输到PC机和视频中所需要提供的设备和服务。
但实际上，H.323可以用于任意分组交换网，与底层物理层无关。
H.323是一个伞式标准，它参考了其他ITU-T标准如H.245，H.225，Q.931等来描述会议系统。
H.323提供了系统和组件描述，呼叫模型描述以及呼叫信号处理。
其中H.225描述了媒体（音频和视频）流打包，媒体流同步、控制流打包、以及控制消息格式。
H.245则描述了用于打开和关闭传输音频、视频和数据的逻辑信道以及容量交换、模式请求、控制和指示。
这两个标准用于控制H.323设备的操作和H.323终端之间的通信。
和其他的ITU-T终端标准不同，H.323不仅定义了终端，而且还定义了LAN 上许多其他组件，包括网关、网闸、多点控制器、多点处理器以及MCU。
在IP网中，网关（Gateway）允许H.323终端和路由器与运行其他协议的终端通信。
它提供了运行不同类型协议的终端和路由器之间的协议转换。
在网关上线路交换的呼叫被编码和重新打包成IP包。
在局域网上，H.323网关作为一个端点可以提供局域网上H.323终端之间实时的双向通信或者和其他WAN上的ITU-T终端、其他H.323网关的通信。
网闸（Gatekeeper）在H.323协议中是一个可选项，它用于管理H.323网络上的其他节点。
RADIUS服务器负载平衡的设计与实现
络 电话 ， 来满 足人 仃进行 夜时 通话的 需求 。 Ｊ 由
是十分 要的指标。 Ａ）Ｕ 议的安伞措施 Ｒ Ｉ Ｓ Ｉ
ｔ括 方ｉ １， ｆ ］Ｊ ￣ Ｘ＿ 用户舜码的加密和 对数据包进
于用户信息会存网络 卜 传输 ， 系统采用目前应
互不 存住 业务 联 系的 ，而随 着 计算机 披
术 、光 纤通 信 技 术 、 数 字 技 术 、交 换技 术
和语音压缩技术的发展 ，曲人 络 语音网
络 和 数据 『 出现 了融 合的趋 势 ，便 产生 Ｊ 圳络 ，
ＶｏＰ （ ｏ ｃ ｖ ｒ Ｉｔ ｒ ｅ Ｐ ｏ ｏ ｏ ）阚 ｌ Ｖ ｉ ｏ ｅ ｎ ｅ ｎ ｔ ｒ ｔ ｃ １ ｅ
ｌｉ 一 ｉｉ ｌｌ 雾 ｌｌ 震 ｌｉ ｉ ｌｌ
Ａ‘ ＵＳ 隧 鬻 ）
王融丽 谭子尤 吉首大学物理科学与信息工程学院 ４ ０ ０ １ ０ ６
。ＨＭ Ａ ｃ。Ｔ ｕ． ＡＧＮ Ｎ．。 。Ｎ． Ｔ 。Ⅸ ｃ 。。 Ｙ。
表 ２编码域类型
蝙峙 值 随日 月
ｕ｝ 袖的４ｎｅｓ 叠番 『 ｌ ＆ｃ 协ｍ 糟瞬Ｉ ｆ聃Ｐｅ ，ｗ ｉ ｌ ｏ； ｖｒ Ｉ ’ ∞８ ８ ｈｈ ｃ
确 酞ｅ甜 群姆 埘 ∞ 艟 卿ｌ 眦．Ａ ￥ ｝ ｄ ∞０ ｏ ａ
首先用户Ｉ令按ｊ １ １ ｛ ｛ ６卞节一 进行划 ｛
分 ，Ｉ为 ｐ ，ｐ ，ｐ ， …， ｉ不 足 １ ｌ ２ ３ ｐ， ６字节
据 Ｒ Ｉ 数据 包的 类型 同 不同 。每 … ＡＤ ＵＳ 个属性都 是 Ｔ ｐ ，Ｌ ｎ ｔ ｙ ｅ ｅｇｈ，Ｖ ｌｅ ａ 二部分 ｕ 传统 意义 的 Ｐ ＴＮ （ ｕ ｌ ｗｉ ｈ ｄ Ｓ Ｉ ｂｉ Ｓ ｔ ｅ ｃ ｃ ｌ Ｐ电话讥 证计费 系统使 用时要将 用户名 、 密 碣 荦教 惠信 息在 网络上 传输 这样 就需要 对 Ｔ ｌ ｈ ｎ ｅｗｏｋ ｅ ｐ ｏ ｅＮ ｔ ｒ ）网络 丰以 Ｉ Ｔ ｃ Ｅ ｅ Ｉ Ｎ ｝ ＮＴ 】 Ｒ 为代 表 的数据 网络 在 出现之 初 ，都 足彼此 孤 ＝
IP电话扩容承载网工程实施方案设计
IP电话扩容承载网工程实施方案设计目录网络详细设计及实施方案工程需求情况说明CNC(中国网通)正在建设一全国范围的VoIP电话，整个VoIP网络的组成部分分为两大部分：●IP Backbone●VoIP系统(运行于IP Backbone 上)CNC的 IP 电话网采用 ITU-T H.323 组网。
中国网络通信公司I P网现状在经过割接后，CNC的原有北电VoIP系统已全部为Cisco的系统取代(IP Backbone使用原有的Bay的路由器)，系统经过这段时间的运营，取得了良好的经济及社会效益，系统进入扩容阶段。
整个CNCVoIP-Net系统：●国内IP部分●国际IP部分通过专线接到FEG的LA和HK国内部分(phase 1)：CNC现VoIP系统 - 国内部分示意图全网共有14个国内城市，北京，上海，广州，南京，深圳，福州，厦门，杭州，武汉，天津，石家庄，济南，郑州，长沙。
全网国内IP骨干部分为暂时使用原Bay的BLN路由器，全网为独立封闭的网络，现运行OSPF路由协议，Cisco5300网关通过Static路由指向Bay的OSPF AREA，并Redistribute到 OSPF，同时Bay 路由器的亦由Static路由指向Cisco5300网关。
为方便VoIP系统设计，将全网设计分成3个区域：本地区域A：北京(关守)，石家庄，济南，天津，郑州本地区域B：上海(关守)，南京，杭州，福州，厦门本地区域C：广州(关守)，武汉，长沙，深圳各节点之间有2M物理链路对接，形成IP网络。
为了全网的时钟同步，全网设有两台主备的NTP服务器，分别放在北京和广州。
考虑到流量的分布，成本以及安全性，全网现暂时设TFTP服务器三台，分别在北京，广州和上海。
在北京全网中心，包括目录VoIP关守，计费系统网通公司选用以色列公司MIND的系统(包含基于SUN的Solaris操作系统的Orcale数据库，一台Client Server 和5 台RTS)，负责认证，授权，记帐的RADIUS服务器，及计费系统和用户数据库。
正文 IP电话系统设计
1 设计目的传统电话网是以电路交换方式传输语音信号，它需要基本带宽为64Kb/s。
据统计，在正常通话情况下，大约只有40％时间为有声期，其余时间电路均为空占，网络带宽利用率不高。
随着计算机技术不断发展，尤其是互联网络不断完善，基于分组交换数据通信成为最重要通信方式。
而要在基于IP分组网络上传输语音，就必须对模拟语音信号进行特殊处理，使处理后信号可以适合在面向无连接分组网络上传输，这就是分组语音技术。
设计基于ARM7内核的IP电话，建立一个以Internet为基础的IP电话网络，以替代传统电话设备系统成为企业的目标。
2 设计要求根据设计要求分析系统功能，掌握设计中所涉及到的电话通信技术、语言传输技术，阐明设计原理，设计系统结构。
根据设计要求及已知参数进行需求分析，选择确定处理器型号、其他芯片型号，完成系统硬件电路设计，完成软件设计，使设计符合要求，可行性强。
3 设计内容3.1.1 IP电话原理从技术观点来看，我们认为m电话(或者VolP Voice over IP)的定义应是：在整个语音通信进程中，部分或全程采用分组交换技术，通过IP网络来进行的语音传输都称之为IP电话。
IP电话的本质特征在于语音分组交换技术。
分组交换技术是Intemet网络采用的体系结构，其核心是将要传输的数据报文分成长度较短且具有标准格式的分组，并采用存储转发传输机制，有效降低数据传输过程中的网络时延，满足数据传输和交换的要求111。
IP电话网络也采用这一技术，具有以下特点：(1)数据包排队传输产生的时延较小，基本满足话音通信的要求。
(2)路由共享，传输线路动态统计时分复用，资源利用率高。
(3)为不同传输速率、不同编码方式、不同同步方式、不同通信规程的用户之间提供了语音通信的环境。
(4)可靠性高。
采用分组技术，传输误码率降低；从源端到目的端存在多个路由，网络中某一节点发生问题时，分组可以自动选择另外路由，保持通信不会中断。
(5)经济性好。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Ａｃ ｅ ｓ Ｒｅ ｕ ｓ ｃ ｓ— ｑ ｅ ｔ Ａｃ ｅ ｓ Ａｃ ｅ ｔ ｃ ｓ— ｃ ｐ
请 求 用 户 身 份认 证
用 户 身 份 验 证 通 过 用 户 身 份 验 证 拒 绝 记 帐请 求 记 帐 响 应
图１ Ｒ Ｉ ＡＤ ＵＳ数据 报格 式
Ａｃ ｅ ｓＲ ｊ ｃ ｃ ｓ— ｅｅ ｔ
文 ｜标 识 码 ： Ｉ Ａ 文章 编 号 ：Ｏ ０—１ ９ （ ０ ７ ０ ０ ８ ｌＯ ８ １ ２ ０ ） １— ０ ５—０ ３ 中 圈分 类 号 ： ３ ３０ ＴＰ ９ 、 ９
传 统意 义 的公共 电话 交换 网络 （ Ｓ Ｐ ＴＮ） 和以 Ｉｔｒ ｅ 为 代表 的数据 网络 ， 初都 是 彼 此 孤立 、 不 关 ｎｅｎ ｔ 最 互 联 的．随着 计算 机 技术 、 光纤 通信 技术 、 字技术 、 换 技术 和语音 压缩 技术 的发展 ， 音 网络 和 数 据 网络 数 交 语
（ Ｃ２ ６ ［ ） ＲＦ ８ ６ ｚ ． ２
Ｉ Ｉ 数 据 包结 构 ．
ＲＡＤ ＵＳ数据 包 的格式 见 图 １ Ｉ ．编码 域共 ８ｂｔ其 类 型见 表 １ ｉ， ．
堡！
ｌ堡 丝！
鉴 别 码 （ ６ｂｔ １ ｉ ）
Ｉ量 ！ ！
表 １ 编 码 域 类型
类 型 说 明
维普资讯
大
庆
石
油
学
院
学
报
第 ３ １卷
２０ ０ ７年
ｂ ｌ— Ｍ Ｄ５ Ｓ ＋ Ｒ ） （ ）一 Ｐｌ （ Ａ ｆ１ ＸＯＲ ｌ ｂ， ｂ ２一 Ｍ Ｄ５ Ｓ＋ ｃ １ ） （ ）一 Ｐ （ （ ）ｆ ２ ｚ ＸＯＲ ｚ ｂ ，
维普资讯
大
庆
石
油
学
院
学
报
第３ １卷
Ｖｏ ． ３ １ １
第 １期
Ｎｏ １ ．
２０ ０ ７年 ２月
Ｆｅ ． ２ ０ ｂ ０ ７
Ｊ ＯＵＲＮＡＬ ＯＦ ＤＡＱ Ｉ ＮＧ ＰＥＴＲＯＬＥＵＭ ＮＳ ＴＵＴＥ Ｉ ＴＩ
Ｉ Ｐ电话 中 ＲＡ ＵＳ服 务 器 负载 平衡 的设 计 与 实现 ＤＩ
许 少 华 ，刘 飒
（大 庆石 油 学 院 计 算 机 与 信 息 技 术 学 院 ， 龙 江 大 庆 １３ １ 黑 ６ ３ ８） 摘 要 ：Ｐ电话 系统 中 ， Ｉ 因多 用 户 并 发 访 问 ， 务 器 的 资 源 处 于 瓶 颈 状 态 ， 重 影 响 了 系统 的 性 能 ．设的服 务器 无法 承担 多用 户并 发访 问 的负荷 ， 因此 ， 者提 出在 多 台服务 器 之 间 引 入 负载 平 衡 服 务器 ， 笔 通过 合理 调度 ， 高 系统服 务性 能． 提
１ 基 本 原理
ＲＡ ＵＳ是 朗讯 公 司 提 出 的 一 种 基 于 ｃ ｓ的 安 全 协 议 ， 括 认 证 部 分 （ Ｃ ８ ５＇） ＤＩ ／ 包 ＲＦ ２ ６ ［ 和计 费 部 分
出现 了融合 的趋 势 ， 由此 产生 了 ＶｏＰ Ｖｏｃ ｖ ｒ ｎｅ ｎ ｔ ｒ ｔｃ １网络 电话 ， 足人 们 进 行实 时 通话 的 Ｉ （ ｉ ｏ ｅ ｔｒ ｅ Ｐ ｏｏ ｏ） ｅ Ｉ 满
需 求 ．由于用 户 信 息会 在 网络 上 传 输 ， 以 系统 采 用 ＲＡＤ ＵＳ（ ｅ ｔ Ａｕｈ ｎ ｉ ｔ ｎ Ｄ ａ —Ｉ ｅ 所 Ｉ Ｒ ｍｏｅ ｔ ｅ ｔ ａｉ ｉｌ ｎ Ｕｓｒ ｃ ｏ Ｓ ｒｉｅ 简称 ＲＡ ＵＳ 协议 对 信息 进行 加 密 、 证用 户 身份 和计 费．随着 Ｉ ｅｖｃ ， ＤＩ ） 认 Ｐ电话 用 户 规 模 的不 断增 长 ，
Ａｃ ｏ ｎ ｉ ｇ Ｒｅ ｕ ｓ ｃ ｕ ｔｎ － ｑ ｅ ｔ Ａｃ ｏｕ ｔｎ — ｓ ｏ ｓ ｃ ｎ ｉ ｇ Ｒｅ ｐ ｎ ｅ
具体 报 文格 式见 文献 ［ ，］ １２ ．
１ ２ ＲＡ Ｉ Ｓ的 安 全 性 ． ＤＵ
ＲＡ ＵＳ协议 的安 全措施 包 括对 用户 密码 的加 密 和对数 据包 进行 完整 性 的检测 ．密码 的加 密 采用 客 ＤＩ 户端 和服务 器共 享公 共 密钥 的机 制．在 网络上 传播 的 ＲＡ Ｉ Ｄ ＵＳ数 据包 中 ， 户 口令 属 性 采用 ＭＤ５ Ｍｅ — 用 （ ｓ ｓｇ ｉｅｔ 息摘 要 ）３ ａ ｅＤ ｇ ｓ 信 ［ 加密算 法 进行 加 密． 首先 ， 户 口令 按 照 １ ｉ 一组进 行 划分 ， 为 Ｐ ， … ， 不 足 １ ｉ 的组 在 末 尾 补 ０ 将 公 共密 用 ６ｂｔ 记 。Ｐ ， Ｐ ， ６ｂｔ ； 钥连 接在 数据 包 中请求 鉴别 码 （ ｅ ｕ ｓ ｔｅ ｔ ａｏ ） 分 的后 面 ， 成一 个 字 符 串 ， 用 ＭＤ５算 法对 Ｒ ｑｅｔ Ａｕｈ ｎ ｉ ｔｒ 部 ｃ 组 使 字符 串进行 处理 得 到 的结果记 为 ｂ ， ｂ 。将 。和用 户 口令 的第 １ Ｐ 进 行异 或 运算 ， 到加 密 后 口令 的第 １ 组 。 得 组 ｆ １ ．若用 户 的 口令 长度 大 于 １ ｉ， 分成 多组．具 体算 法为 （） ６ｂｔ则
的负载平衡服务器 ， 度多个 Ｒ 调 ＡＤＩ ＵＳ服 务 器 ， 得 各 个 服 务 器 的 负 载 达 到 均 衡 、经 测试 ， 使 系统 采 用 负 载 平 衡 服 务 器 后 ，
客户访问数 由原来的 ２ ５提高到 １０ ０ ．测试结果表 明， 该设计在服务性能调优方面有重要作用．
关 ｔ 词： ＲＡＤ ＵＳ安 全 协 议 ；负 载 平 衡 ； 发 Ｉ 并