??xml version="1.0" encoding="utf-8" standalone="yes"?>亚洲精品电影天堂网,亚洲av午夜成人片精品网站 ,在线观看亚洲精品专区http://www.tkk7.com/huyi2006/articles/188616.html胡意胡意Tue, 25 Mar 2008 15:27:00 GMThttp://www.tkk7.com/huyi2006/articles/188616.htmlhttp://www.tkk7.com/huyi2006/comments/188616.htmlhttp://www.tkk7.com/huyi2006/articles/188616.html#Feedback0http://www.tkk7.com/huyi2006/comments/commentRss/188616.htmlhttp://www.tkk7.com/huyi2006/services/trackbacks/188616.html
其主要特征有Q?

1Q?客户?服务?C/S)模式

一个网l接入服务器(以下UNAS)作ؓRADIUS的客hQ它负责用户信息传入RADIUS服务器,然后按照RADIUS服务器的不同的响应来采取相应动作。另外,RADIUS服务器还可以充当别的RADIUS服务器或者其他种c认证服务器的代理客戗?

2Q网l安全(Network SecurityQ?

NAS和RADIUS服务器之间的事务信息交流׃者共享的密钥q行加密Qƈ且这些信息不会在两者之间泄漏出厅R?

3Q灵z认证机ӞFlexible Authentication MechanismsQ?

RADIUS服务器支持多U认证机制。它可以验证来自PPP、PAP、CHAP和UNIXpȝd的用户信息的有效性?

4Q协议可扩展?Extensible Protocol)

所有的认证协议都是Z“属性-长度Q属性值?元素而组成的。所以协议是扩展h非常方便。在目前很多比较高版本的Linux中,它们都把 RADIUS的安装程序包含在pȝ源码中。这样得我们可以很Ҏ地通过免费的Linuxpȝ学习RADIUS授权、认证的原理和应用?


RADIUS协议原理


要弄清楚RADIUS协议Z能实现授权和认证Q我们必d该从四个斚w去认识RADIUS协议Q协议基本原理、数据包l构、数据包cd、协议属性。下面我们就来详l地介绍q些内容?

协议基本原理

NAS提供l用L服务可能有很多种。比如,使用telnetӞ用户提供用户名和口o信息Q而用PPPӞ则是用户发送带有认证信息的数据包?

NAS一旦得到这些信息,制造ƈ且发送一个“Access-Request”数据包lRADIUS服务器,其中包含了用户名、口令(ZMD5加密Q、NAS的ID号和用户讉K的端口号?

如果RADIUS服务器在一D规定的旉内没有响应,则NAS会重新发送上q数据包Q另外如果有多个RADIUS服务器的话,NAS在屡ơ尝试主RADIUS服务器失败后Q会转而用其他的RADIUS服务器?

RADIUS服务器会直接抛弃那些没有加“共享密钥”(Shared SecretQ的h而不做出反应。如果数据包有效Q则RADIUS服务器访问认证数据库Q查找此用户是否存在。如果存在,则提取此用户的信息列表,其中包括了用户口令、访问端口和讉K权限{?

当一个RADIUS服务器不能满用L需要时Q它会求助于其他的RADIUS服务器,此时它本w充当了一个客L?

如果用户信息被否认,那么RADIUS服务器给客户端发送一个“Access-Reject”数据包Q指C此用户非法。如果需要的话,RADIUS服务器还会在此数据包中加入一D包含错误信息的文本消息Q以便让客户端将错误信息反馈l用戗?

相反Q如果用戯认QRADIUS服务器发送“Access-Challenge”数据包l客LQƈ且在数据包中加入了客户端反馈给用户?信息Q其中包括状态属性。接下来Q客L提示用户做出反应以提供进一步的信息Q客L得到q些信息后,再ơ向RADIUS服务器提交带有新hID?“Access-Request”数据包Q和起初的“Access-Request”数据包内容不一L是:起初“Access-Request”数据包 中的“用户名/口o”信息被替换成此用户当前的反应信息(l过加密Q,q且数据包中也包含了“Access-Challenge”中的状态属性(表示? ?Q。此ӞRADIUS服务器对于这U新的“Access-Request”可以有三种反应Q“Access-Accept”、“Access- Reject”或“Access-Challenge”?

如果所有的要求都属合法QRADIUSq回一个“Access-Accept”回应,其中包括了服务类?SLIP, PPP, Login User{?和其附属的信息。例如:对于SLIP和PPPQ回应中包括了IP地址、子|掩码、MTU和数据包qo标示信息{?

数据包结?

RADIUS数据包被包装在UDP数据报的数据块(Data field)Q中Q其中的目的端口?812。具体的数据包结构如??


8?8?16?
code Identifier Length
AuthenticatorQ?28位)
Attributes…(不定长)



· Code Code域长度ؓ8位,具体取D?。其中,1??用于用户认证Q??则是l计量用,12?3 用于试验阶段Q?55作ؓ保留?


code 含义
1 Access-Request
2 Access-Accept
3 Access-Reject
4 Accounting-Request
5 5Accounting-Response
11 Access-Challenge
12 Status-Server(experimenta)
13 Status-client(experimenta)
255 Reserved



· Identifier Identifier域长度ؓ8位,主要用于匚wh和回应数据包Q也x数据包的~号?

· Length 长度?6位,取D_20<=Length<=4096Q,此长度包括Code、Identifier、Length?Authenticator?Attribute五个数据域的长度dQCode、Identifier、Length、Authenticator为定长,Attribute为变 ?。超围的数据被视ؓ附加数据QPaddingQ或直接被忽略?

· Authenticator 长度?6个字?128?Q主要用于鉴定来自RADIUS服务器的回应Q同时也用于对用户口令进行加密?

(1) Request Authenticator

在“Access-Request”数据包中,Authenticator是一?6字节的随机数Q称为“Request Authenticator”。它在NAS和RADIUS服务器之间通过“共享密码?secret)传输数据的整个生命周期中是唯一的。  

(2) Response Authenticator

在“Access-Accept”、“Access-Reject”和“Access-Challenge”中的Authenticator域被UCؓ“Response Authenticator”?

有下面的计算ҎQ?

ResponseAuth = MD5(Code+ID+Length+RequestAuth+ Attributes+Secret) ——(公式1Q?



· Attributes 属性域的数据格式如?所C?


8?8?不定长(0或多个字节)
Type Length value?



Type指示了Atribute的类型,通用的有几十U,如表4所C?


Type 说明 Type 说明
1 User-Name 5 NAS-Port-Id
2 Password 6 Service-Type
3 CHAP-Password 7 Framed-Protocol
4 NAS-IP-Address ??

数据包类?

RADIUS数据包的cd由其Code域(?位)指定?

· Access-RequestQ接?hQ?

“Access-Request”数据包由NAS发出Q由RADIUS服务器接收?

其中的“User-Password”或“CHAP-Password”属性D默认CMD5Ҏ加密?

数据包结构如?所C?


8?8?16?
CodeQ? Identifier-随着Attributes的Value变化而变化,重传时则保持不变 Length
AuthenticatorQ?28位)—根据Identifier变化而变?
Attributes…(不定长)



Attributes应该包括以下几个属性:

?“User-Name?
?“User-Password”或“CHAP-Password?
?“NAS-IP-Address?
* “NAS-Identifier?
?“NAS-Port?
?“NAS-Port-Type?



· Access-Accept

“Access-Accept?由RADIUS服务器发出,q回lNAS。表C用L信息是合法的。其中包括了必要的配|信息,以便下一步ؓ用户提供服务。数据包l构如表6所C?


8?8?16?
CodeQ? Identifier-和“AccessQRequest”的Identifier相同 Length
Authenticator(128?Q属于Response AuthenticatorQ由公式1计算得到
Attributes…(不定长)



Access-Reject“Access-Reject”由RADIUS服务器发出,q回lNAS。表C用L信息是非法的。其中应该包括一个或多个的“Reply-Message”(回复消息Q包含一些便于NASq回l用L一些错误信息)。数据包l构如表7所C?


8?8?16?
CodeQ? IdentifierQ和“AccessQRequest”的Identifier相同 Length
AuthenticatorQ?28位)Q属于Response的AuthenticatorQ由公式1计算得到
Attributes…(不定长)



属?

属性如?所C。其中,Length的计方法ؓQType+Length+Value?


8?8?不定长(0或多个字节)
Type Length Value?



Value?U类型:

?String —?0~253字节Q字W串

?Ipaddress —?32位,IP地址

?Integer —?32位,整数

?Time —?32位,?0:00:00 GMT, January 1, 1970到当前的ȝ?

从这里可看出QRADIUS协议是一个不定长的协议栈?img src ="http://www.tkk7.com/huyi2006/aggbug/188616.html" width = "1" height = "1" />

胡意 2008-03-25 23:27 发表评论
]]>
内存数据库在BSS账务处理中的应用http://www.tkk7.com/huyi2006/articles/178434.html胡意胡意Tue, 29 Jan 2008 16:19:00 GMThttp://www.tkk7.com/huyi2006/articles/178434.htmlhttp://www.tkk7.com/huyi2006/comments/178434.htmlhttp://www.tkk7.com/huyi2006/articles/178434.html#Feedback0http://www.tkk7.com/huyi2006/comments/commentRss/178434.htmlhttp://www.tkk7.com/huyi2006/services/trackbacks/178434.html        BSSpȝ是每个电信运行商的核心业务支撑系l。近q来Q随着支持用户量和话单量的成倍增长和实时业务的不断扩展,数据处理量大量增加,业务处理模式日趋复杂Q必然导致主机CPU和I/O占用不断成线性增加。在此情况下Q即使增加硬件支持,现有架构下系l的处理速度也很隑־到质的提高?br />引言
中国加入WTO之后Q电信市场将逐步向外资开放,2006q开始外资将全面q入中国电信业,国际先进的服务模式和服务水^势必会对国内电信q营商提出更高的挑战。同时国内电信业的竞争格局也发生了深刻的变化:W三、四张移动牌照即发放,竞争形势更ؓD酷Q用户增量市场逐渐萎羃Q作为我们运营商更需要的是如何提高自w服务质量,在存量市Z保持原有客户以及从竞争对手中获得客户。这些都意味着市场的竞争已逐步由技术驱动{向市场驱动和客户需求驱动,电信q营商必M传统的经营模式向“以客户Z心,以市Zؓ导向”的l营模式转变Q也从单纯的网l竞争、h格竞争{向网l、hg服务、渠道、品牌相l合的全方位的竞争模式?br />电信业正q入C轮的高速发展时期,市场需求成为驱动力??市场部门不断推出的各U各样促销计划和市场推q活动,以及用于刺激用户使用q营商的服务以扩大用L的全新变化,使得计费账务pȝ必须实现非常复杂的资贏V折扣的理能力和资ҎL能力。随着电信业务的迅猛发展,电信q营商的计费账务pȝ的压力也来大Q如何保证计费̎务系l的实时性成为各q营商关心的重点?br />BSSpȝ是每个电信运行商的核心业务支撑系l。近q来Q随着支持用户量和话单量的成倍增长和实时业务的不断扩展,数据处理量大量增加,业务处理模式日趋复杂Q必然导致主机CPU和I/O占用不断成线性增加。在此情况下Q即使增加硬件支持,现有架构下系l的处理速度也很隑־到质的提高。由此对业务产生了极其不利的影响Q̎务功能不灉|Q系l对业务需求的支撑灉|度不够;难以在短旉内响应市场需求,效率与灵zd难以兼得Q计费实时性得不到切的保障,无法l用h供实时准的查询服务Q̎务批处理情况下可能造成与营业应用的性能怺影响。ؓ此,现有的BSSpȝq行框架l构上的全面攚w已l是大势所?/p>

  内存数据库介l?br />1Q什么是内存数据?br />众所周知Q相对于盘Q内存的数据d速度要高出几个数量Q将数据保存在内存中相对于从盘上访问数据能够极大地提高应用的性能。一斚w׃从磁盘上d数据旉要进行磁头的机械UdQ直接从内存中读写数据则是电信号的移动,两者速度完全不在一个数量上;另外一个容易被忽略的时间就是系l调用时_因ؓ每次对磁盘进行访问都需要进行一ơ操作系l的pȝ调用Q而系l调用相对于普通的库函数调用要p更多的时间。之所以要q行pȝ调用是因为处于用h的应用E序不能直接对外部设备进行操作,而需要进入内核态,由操作系l调用相应设备的驱动E序完成对设备的操作。系l调用一般是通过中断来完成得QCPU只有在完成当前时钟周期的操作后在下一个时钟周期处理中断请求,q且在进行中断处理时需要进行上下文信息的保存与切换。所以一个应用如果频J地q行pȝ调用也会极大地降低系l地性能。正是由于这两方面的原因Q得从盘上读写数据比从内存中d数据的时间开销要大得多?br />传统的数据库理pȝ的所有数据都是放在磁盘上q行理Q需要频J地讉K盘来进行数据的操作。如上所qͼ׃盘数据讉K本n的性能瓉Q数据库理pȝ的性能提升受到了很大的限制。然而,q年来,随着计算机技术的飞速发展,要解册一问题已经有了现实可能Q内存容量的不断提高Q而hg断下跌;计算入了64位时代,操作pȝ可以支持更大的地址I间?br />正是Z技术的发展Q以及市ZҎ加快速和实时的数据库理pȝ的需求,出现了内存数据库pȝ。内存数据库pȝ抛弃了磁盘数据管理的传统方式Q基于全部数据都在内存中理q行了新的体pȝ构的设计Qƈ且在数据~存、快速算法、ƈ行操作方面也q行了相应的改进Q所以数据处理速度一般比传统数据库的数据处理速度要快很多Q一般都?0倍以上?/p>

2Q内存数据库和磁盘数据库的性能试Ҏ
以下比较Z内存数据库和盘数据库中完全相同的数据库表结构和应用Q测试对比的数据库ؓOracle 9i和ALTIBASE 3.5.7Q在相同的测试环境下q行?br />? 
INSERTQ对oracle和ALTIBASEq行相同表的插入操作Q查看插入的效率?

INSERTQ对oracle和ALTIBASEq行相同表的插入操作Q查看插入的效率?/p>

3Q内存数据库和利用程序吊用内存的Ҏ
׃内存的高速特点,早在2000q以前就有通过q程吊用内存的方式来q行E序处理Q内存数据库提供的是一个模块化l构Q保持一个核心引擎相对不变,外围可变Q提供标准扩展接口和灉|的二ơ开发能力和良好的流E优化能力:

在BSSpȝ中采用内存数据库的理?br />拿江苏联通过ȝBSSpȝZQ̎务处理模块的性能瓉是在计费处理和销账处理?br />׃数据量大、用戯料量大、计费处理模型相对复杂、以Flist支持字段变化和格式可配置{原因,使得现在的计费处理速度相对较慢。而由于清单数据量非常大,其全部攑օ内存数据库中是不太可能的。ؓ了利用内存数据库的高速度Q则只能采取折中的方法,全部清单数据攑֜盘数据库中Q根据实际情况只一D|间内的清单数据保存在内存数据库中Q费用篏计和优惠可以针对q一D|间内的清单数据进行一个事务性处理。其他数据,例如累计费用数据Q用戯料,费率和优惠信息等相对与清单数据来说数据量较小Q可以直接放在内存数据库中。将数据加蝲到内存数据库中的基本原则是,数据l常用到且数据量不会很大Q数据查询操作比数据写和更新操作要频J。除计费处理外,当其他业务应用需要用到这些数据时也都直接从内存数据库中取?br />对于销账处理而言Q由于在销账处理的q程中涉及到多张表,在用戯求缴ҎQ在数据库中会将查询出来的资料信息和费用信息攑֜两张临时表中Q一个ؓ资料信息临时表,一个ؓ费用临时表。由于所有缴费h员都同时用到q两张时表Q在传统数据库中往往出现大量争用Q大大g长这两张物理表查询所需数据的时间。将q两临时表放在内存数据库中后Q由于内存处理速度q远快于盘IOQ争用出现的可能大ؓ降低Q极大减了单独事务的相应处理时_得以满大量q发讉K的要求?/p>

? 江苏联通BSS原̎务处理流E?/p>

当然Q如果不采用内存数据库来理以上的数据,我们可以采取这些数据组l成相应的数据结构,q用一些共享内存算法来q行查询和更新处理。但是从前面提到的两者对比来看,q样做,开发量大,开发周期长Q对E序员要求高Q徏立的pȝ也会难以l护、查询和二次开发,q且逻辑l构复杂Q接口也难以扩展Q而最关键的是Q数据完整性和一致性难以保障。相对于利用E序开发调用内存处理来_内存数据库自有其优势。首先,内存数据库是产品化的数据库管理YӞ已经是完整的产品Q极大羃短了开发周期;其次Q内存数据库有着开攄q_和接口,E序开发和UL更加灉|便捷Q也便于l护和二ơ开发;可以通过使用l一的SQL语言方便的查询内存中的数据;在数据库中保障数据的安全性和完整性。这些优势,对于快速部|和化维护都是有利的?/p>

内存数据库在江苏联通BSS账务处理pȝ中应用的特点和效?br />江苏联通在账务处理pȝ中采用了韩国的品ALTIBASE内存数据库。ؓ完成公司提出的计费实时性指标要求,我们认ؓ只有从底层彻底改变整个̎务处理的体系架构Q才能对性能有质的提高。ALTIBASE内存数据库管理系l是一个在事务优先的环境中提供高性能和高可用性的软g解决Ҏ。在江苏联通运用之前,在电信领域ALTIBASE内存数据库只有韩国SK有大型的全面解决Ҏ。江苏联通在l合分析了SK的案例以及组l了多次大规模周详的试后才军_q用此品?br />江苏联通是国内W一家将内存数据库运用于大型支撑pȝ的运营商。因̎务处理模块是效率瓉最大、也是对pȝ压力最大的一个模块,对用h电话后查询话单的实时性感知度以及额Ơ费都有较大影响Q江苏联通重炚w对̎务处理系l引入了ALTIBASE技术,以便于提高客h意度和减费用流失?br />自ALTIBASE内存数据库在江苏联通BSS账务处理pȝ中上U一q来Q运行一直非常稳定。在应用中,只把最需要的中间数据攑ֈ内存库中Q节省了内存的开销又提高了效率Q把好钢用在了刀刃上。因为原先的账务处理瓉在于读取营账的用户数据以及写入账务中间数据的频ơ非帔RQ频J的物理d造成了I/O的瓶颈,而且会媄响前台系l的性能。通过采用复制技术将Oracle盘数据库中账务处理需要用到的营̎数据实时复制增量数据到ALTIBASE内存数据库中去,处理好的中间̎务结果也写入ALTIBASEQ这样做C只把造成瓉的数据放到内存中处理Q也是用最快速的存储资源解决了开销最大的处理操作。另外,ALTIBASE内存数据库管理系lؓ需要容错服务的pȝ提供实时数据库复制的功能Q采用联机日志的|络复制实现了双Z间数据的同步。采用双机热备的方式Q既实现了高可用性又实现了负荷分摊。在我们的设计架构中实现了双机热备,同时我们前台的实时话费的查询接口都链接到备库上Q这样就实现了双机分摊̎务和营业两种应用的功效?/p>


? 江苏联通BSS现̎务处理流E?/p>

1Q内存数据库在江苏联通BSS账务处理pȝ中应用的特点
(1)只把最需要的中间数据攑ֈ内存库中Q节省了内存的开销又提高了效率Q把好钢用在了刀刃上
因ؓ原先的̎务处理瓶颈就在于d营̎的用h据以及写入̎务中间数据的频次非常高,频繁的物理读写造成了I/O的瓶颈,而且会媄响前台系l的性能。我们采用了复制技术将Oracle盘数据库中账务处理需要用到的营̎数据实时复制增量数据到Altibase内存中去Q将处理好的中间账务l果也写入AltibaseQ这样做C只把造成瓉的数据放到内存中处理Q也是用最快速的存储资源解决了开销最大的处理操作?br />2Q采用双机热备的方式Q既实现了高可用性又实现了负荷分?br />ALTIBASE内存数据库管理系lؓ需要容错服务的pȝ提供实时数据库复制的功能Q采用联机日志的|络复制实现了双Z间数据的同步。在我们的设计架构中Q备机既实现了双机热备、同时我们将前台的实时话费的查询接口都链接到备库上,q样实C双机分摊账务和营业两U应用的功效?br />3Q投资保?br />使用内存数据库可节省g投资和系l维护成本。通过ҎQ如果要辑ֈ目前的计费实时性指标要求,按照开发商的徏议,要将CPU扩展?2个,内存64GQ同时系l开发商q要作大量的E序修改工作Q而目前在10个CPU?5G内存上系l正常运行,CPU的^均占用率大约?5%--75%Q原先ؓ95%Q。按照常识,1G内存的h格约?颗CPU?/10。即节省了约19个CPU的投资。而在收益斚wQ根据指标数据,采用内存数据库后Q^均小额欠费率下降到老系l的55Q左叻I按此推算Q每月给公司节约成本千万以上?br />l束?br />在当今电信领域,传统的一些支撑系l的架构已经逐渐不能满日益增长的业务需求和客户需求,引入一些新的技术来解决我们生中遇到的问题是必然的Q这些新的技术架构很可能在今后会成ؓ一U发展趋势,像SAN替代DAS、关pd数据库替代传l数据库那样?br />ALTIBASE在江苏联通BSSpȝ中的q用是一个采用新技术架构实现系l目标的典型案例。主要有以下几点l验可以借鉴于同cȝC品的应用上:
Q?Q不L对现有架构做大范围的改动Q保证框架稳定;
Q?Q控制成本、有效用,好钢用在刀刃上Q?br />Q?Q针对系l中最主要的问题,投入最合适的产品或解x案,实现既定的目标?br />江苏联通在账务处理pȝ中率先采用ALTIBASE内存数据库体pL构,提高了系l处理速度2.5倍,使得pȝ的实时性大大提高,降低了小额欠费率、减d生pȝ的压力?br />内存数据库只是多U新技术中有代表性的一U而已Q只要解放思想、选用得当Q完全可以在投入不大的情况下以这cd用的产品解决pȝ中本来难以改变的瓉。在未来的BSS发展方向中内存数据库会逐渐成长Z股中坚力量,在客L分、用戯为分析、品管理、欠Ҏ制系l等需要复杂高速运的pȝ中发挥作用?/p>

 



胡意 2008-01-30 00:19 发表评论
]]>
վ֩ģ壺 պƷƷƵ߹ۿ| ۺѾƷþþ| 99þƷƵ77| һ| һ| ˳77777վ| aëƬѹۿ| ޳avƬ߹ۿ벻| 9i9ƷѾþ| avr| һƬѿ| AV˾Ʒվ߲| 91Ʒȫѹۿ߲ | ޺Ʒһ | 99ֻоƷ6| ޳Ļ| av߿վ| 㽶߹ۿ| պƷƵַ| AëƬѿ| VVA| ĻþƷ | ŷղ߹ۿ| 98ƷȫѹۿƵ| պ޲߹ۿ| ?VþþƷ| ˿wwwѸ| ձһ߶ | ޾Ʒٸ30P| ޾Ʒ| 95˾Ѹ| Ʒާѡ벥鶹 | ŷպĶ| ޾Ʒ߹ۿ| **aaaaaëƬͬͬŮ| AVþWWW| þþ޹| þþþþþƵ| ֻˬʹƬҹ| ɫʮʮɫ| ձƬ߿a|