您所在位置： &
&nbsp&&nbsp&nbsp&&nbsp
服务器监控系统的设计与实现.pdf68页
本文档一共被下载：
次 ,您可免费全文在线阅读后下载本文档
文档加载中...广告还剩秒
需要金币：150 &&
中图分类号：
学校代码：
硕士专业学位论文
服务器监控系统的设计与实现
DesignImplementationMonitoringSystem
南开大学研究生院
二。一一年十一月
南开大学学位论文使用授权书lI掣型攀磐磐㈣27㈣9帅
根据《南开大学关于研究生学位论文收藏和利用管理办法》，我校的博士、硕士学位获
得者均须向南开大学提交本人的学位论文纸质本及相应电子版。
本人完全了解南开大学有关研究生学位论文收藏和利用的管理规定。南开大学拥有在
《著作权法》规定范围内的学位论文使用权，即： 1 学位获得者必须按规定提交学位论文 包
括纸质印刷本及电子版 ，学校可以采用影印、缩印或其他复制手段保存研究生学位论文，
并编入《南开大学博硕士学位论文全文数据库》； 2 为教学和科研目的，学校可以将公开
的学位论文作为资料在图书馆等场所提供校内师生阅读，在校园网上提供论文目录检索、文
摘以及论文全文浏览、下载等免费信息服务； 3 根据教育部有关规定，南开大学向教育部
指定单位提交公开的学位论文； 4 学位论文作者授权学校向中国科技信息研究所及其万方
数据电子出版社和中国学术期刊 光盘 电子出版社提交规定范围的学位论文及其电子版并
收入相应学位论文数据库，通过其相关网站对外进行信息服务。同时本人保留在其他媒体发
正在加载中，请稍后...SUM服务器监控软件监控磁盘SMART信息
SUM服务器监控软件监控磁盘SMART信息
S.M.A.R.T.，全称为“Self-Monitoring Analysis and Reporting Technology”，即“自我监测、分析及报告技术”。是一种自动的硬盘状态检测与预警系统和规范。通过在硬盘硬件内的检测指令对硬盘的硬件如磁头、盘片、马达、电路的运行情况进行监控、记录并与厂商所设定的预设安全值进行比较，若监控情况将或已超出预设安全值的安全范围，就可以通过主机的监控硬件或软件自动向用户作出警告并进行轻微的自动修复，以提前保障硬盘数据的安全。除一些出厂时间极早的硬盘外，现在大部分硬盘均配备该项技术。哲涛SUM对ATA磁盘的SMART可以全面监控和自主分析,主要监控磁道错误、磁盘稳定性、预测性错误、重定位扇区（常发生重定位扇区则说明磁盘即将损坏）、磁盘温度等。
磁盘SMART监控
磁盘SMART温度监控历史最早期的硬盘监控技术起源于1992年IBM在为AS/400计算机的IBM9337硬盘阵列中的IBM 0662 SCSI2代硬盘驱动器之中，后来该技术被命名为Predictive Failure Analysis（故障预警分析技术），它是通过在固件中测量几个重要的硬盘安全参数和评估他们的情况。从物理硬盘发送到监控软件的结果中被限定两种结果：“硬盘安全”和“硬盘不久后会发生故障”。不久，由微机制造商Compaq和硬盘制造商Seagate、Quantum和Conner提出了名为IntelliSafe的类似技术。通过该技术，硬盘会测量自身的的健康指标并将参量值传送给操作系统和用户的监控软件中，每个硬盘生产商有权决定哪些指标需要被监控和它们的安全阈值。Compaq于1995早期将该项技术方案提交到Small Form Factor委员会进行标准化，该方案得到IBM、Seagate、Quantum、Conner和Western Digital所支持。由于IntelliSafe技术的灵活性，委员会接受了该方案，并正式更名S.M.A.R.T.技术，将其标准化并推广至ATA-3行业标准中。运作原理该技术所需数据被存放在硬盘物理盘面最前面的磁道中，由硬盘制作商将相关管理程序和数据该磁道中，包括加解密程序，自监控程序，自修复程序等，主机的监控软件可以通过“SMART RETURN STATUS”的命令读取S.M.A.R.T.信息，且这些信息不允许被用户修改。检测属性下面将列出一些S.M.A.R.T.的原始检测属性和含义。普遍为检测值越高性能越好。即使所有制造商都必须遵守共同的规则，但由于有些检测值在不同硬盘制造商中用不全相同的定义和计量方法而对于不同制作商来说检测值不全是越高越好，所以下面属性的指标只作一般参考。除外，各制造商也会根据自己需要添加一些自己专有的检测属性说明表示数值越高越好表示数值越低越好重要项：粉色底当超出安全范围会对性能严重影响10x01read error rate底层数据读取错误率存储器从一个硬盘表面读取数据时发生的错误率。原始值由于不同厂商的不同计算方法而有所不同，其十进制值往往无意义的。一般来说有数值意味着磁头已出现问题了。20x02Throughput Performance读写通量性能通常是硬盘读写性能的测量值，如果其值有变动，有可能硬盘出现了问题。30x03Spin-Up Time盘片启动时间盘片由静止启动加速到稳定正常运行速度的平均所需时间。40x04Start/Stop Count电机起停次计数一个盘片启动关闭周期的统计值，只有硬盘从完全断电中启动或从睡眠模式恢复，盘片主轴电机被启动时才会记一次数。50x05Reallocated Sector Count重定位磁区计数记录由于损坏而被映射到无损的后备区的扇区计数。当硬盘出现损坏扇区时，可以通过将其物理空间指向到特定的无损区域进行重映射修复，从而出现坏扇区的硬盘仍可使用。但当高过一定数值后，后扇区消耗殆尽而无法再重映射修复时，这些坏扇区就会显现出来且无法自行修复。除外由于要要求磁头读取这些坏扇区时专门再移动到后备区读写数据，对硬盘读写性能也有影响。60x06Read Channel Margin信道读取余量读取数据时信道可用的余量，该属性没制定任何功用。70x07Seek Error Rate寻道错误率（该属性是特定制造商才有的）磁头寻找磁道由于机械问题而出错几率，有多种原因可能引致出错，如：磁头伺服构件，盘体过热，或损坏。于不同厂商的不同计算方法而有所不同，其十进制值往往无意义的。80x08Seek Time Performance寻道性能每次寻道时间的平均值，该值短期内迅速减少，有可能硬盘出现了问题。90x09Power-On Hours硬盘加电时间硬盘自出厂以来加电启动的统计时间，单位为小时（或根据制造商设定为分钟或秒），一般用户以该值判定硬盘是否被使用过。100x0aSpin Retry Count电机起转重试S.M.A.R.T参数电机起转重试，表明了主轴电机的启动尝试次数。这个属性存储了关于主轴电机尝试加速到完全可操作速度的次数（在这种情况下，意味着主轴电机的第一次启动尝试没有成功）。主轴电机频繁的尝试启动，意味着硬盘驱动器的寿命可能将近实际限值。110x0bRecalibration Retries磁头校准重试磁头在一次运行失败时尝试校准至正常状态的统计数，该值改变时意味着硬盘的机械部件已经出现问题了。120x0cPower Cycle Count设备开关计数该属性表示硬盘电源充分开/关循环计数。130x0dSoft Read Error Rate软件读取错误率操作系统读取数据时的出错率。1830xb7SATA Downshift Error CountSATA降级运行计数Western Digital 和 Samsung 特有属性，记录由于兼容问题导致降低SATA传输级别运行的计数。1840xb8End-to-End error终端校验出错HP专有S.M.A.R.T.（SMART IV）技术的一个特有属性，记录硬盘从盘片读取数据到高速缓存后再传输到主机时数据校验出错的次数。1850xb9Head Stability磁头稳定性Western Digital特有属性1860xbaInduced Op-Vibration DetectionWestern Digital特有属性1870xbbReported Uncorrectable Errors报告不可纠正错误硬件ECC无法恢复的错误计数。1880xbcCommand Timeout通信超时由于无法连接至硬盘而终止操作的统计数，一般为0，如果远超过0，则可能电源问题，数据线接口氧化或更严重的问题。1890xbdHigh Fly Writes磁头写入高度硬盘进行写入时对磁头高度进行监控以提供额外的保障。当磁头处于不正常高度进行写入时，写入操作会被终止，原有数据重写入或者将该扇区重映射到安全区域。该属性是统计值。1900xbeAirflow Temperature气流温度Western Digital特有属性，计量硬盘内气流温度，和检测项0xc2相似。1910xbfG-sense Error Rate加速度错误率计量可能对硬盘做成损害的冲击次数。1920xc0Power-off Retract Count电源关闭磁头收回计数计量磁头在没有加电时不移进硬盘的值。1930xc1Load Cycle Count磁头升降计数计量磁头在加电时移进/移出硬盘周期的值。1940xc2Temperature温度计量硬盘的温度1950xc3Hardware ECC Recovered硬件ECC恢复（特定原始值）1960xc4Reallocation Event Count重定位事件计数记录已重映射扇区和可能重映射扇区的事件计数。1970xc5Current Pending Sector Count等候重定的扇区计数记录了不稳定的扇区的数量。1980xc6Uncorrectable Sector Count无法校正的扇区计数记录肯定出错的扇区数量。1990xc7UltraDMA CRC Error CountUltraDMA通讯CRC错误记录硬盘通讯时发生的CRC错误。2000xc8Multi-Zone Error Rate多区域错误率写入一个区域时发现的错误的计数。2000xc8Write Error Rate写入错误率Fujitsu的特别属性，写入一个区域时发现的错误的计数。2010xc9Soft Read Error Rate逻辑读取错误率记录脱轨错误。2020xcaData Address Mark errors数据地址标记错误记录数据地址标记错误（或制造商特定的计数）2030xcbRun Out Cancel用完取消ECC错误计数2040xccSoft ECC Correction逻辑ECC纠正记录由软件ECC更正的错误计数。2050xcdThermal Asperity Rate热嘈率记录高温导致的出错记数。2060xceFlying Height飞行高度记录磁头的飞行高度。飞得太低会增加磁头撞毁的机会，飞得太高增加读写错误的机会。2070xcfSpin High Current主轴电机浪涌电流计数记录主轴电机运转时浪涌电流的次数。2080xd0Spin Buzz记录由于电力不足而启动主轴电机的蜂鸣声次数。2090xd1Offline Seek Performance离线寻址性能在其内部测试硬盘的寻址能力表现。2100xd2？？（没定性，出现在Maxtor 6B200M0 200GB 和Maxtor 2R015H1 15GB 的硬盘中）2110xd3Vibration During Write写操作震动记录写入操作的震动数。2120xd4Shock During Write写操作冲击记录写入操作时的冲击数。2200xdcDisk Shift盘体偏移记录盘体由于冲击或温度导致偏离主轴的相对距离。2210xddG-Sense Error Rate加速计出错率从外部诱发的冲击和振动产生的错误计数。2220xdeLoaded Hours数据加载时间数据读取时所花费的时间。（磁头移动时间）2230xdfLoad/Unload Retry Count加载/卸载重试次数磁头改变位置时所需时间。2240xe0Load Friction负载摩擦读写时由于机械摩擦做成的阻力。2250xe1Load/Unload Cycle Count加载/卸载循环计数总负载周期计数。2260xe2Load 'In'-time磁头磁头加载所需总时间（不包括在停泊区的花费）。2270xe3Torque Amplification Count扭矩放大计数尝试来补偿盘片的速度变化的计数。2280xe4Power-Off Retract Cycle断电缩回周期切断电源后电磁枢自动缩回的时间计数。2300xe6GMR Head AmplitudeGMR磁头振幅磁头振幅计数（磁头反复正反向运动距离）。2310xe7Temperature硬盘温度记录硬盘温度。2320xe8Endurance Remaining耐久性剩余磁盘可使用周期与设计可使用周期的百分比。2320xe8Available Reserved Space可用保留空间Intel固态硬盘报告的可提供的预留空间占作为一支全新的固态硬盘预留空间的百分比。2330xe9Power-On Hours加电时间处于开机状态的小时数。2330xe9Media Wearout Indicator介质耗损指标Intel固态硬盘报告的NAND刷写寿命，全新时值为100，最低值为1，其跌幅随NAND的擦除周期增加而在0到最大额定周期范围减少。2400xf0Head Flying Hours磁头飞行时间磁头处于定位中的时间。2400xf0Transfer Error Rate传输错误率在数据传输时连接被重置的次数计数。（Fujitsu特有属性）2410xf1Total LBAs WrittenLBA写入总数LBA写入总数计数。2420xf2Total LBAs ReadLBA读取总数LBA读取总数计数，部分S.M.A.R.T.检测程序会把原始值显示为负数，这是因为该原始值为48位，而不是32位的。2500xfaRead Error Retry Rate读取错误重试率从磁盘读取时的错误计数。2540xfeFree Fall Protection自由跌落保护对“自由落体事件”检测计数。在非ATA平台上的实现SCSI硬盘的传输端口平台主要分为ATA和SCSI两个平台。作为一种硬盘的检测技术，理论上都能在两个平台上实现的，但由于两个平台也存在巨大的不同，S.M.A.R.T.在SCSI上的实现和在ATA的实现上也有所不同。首先，作为ATA上的专有规范，S.M.A.R.T.对ATA系统的干预要比SCSI更明显，S.M.A.R.T.对SCSI更多是起到检测的作用，即使在检测到磁盘有故障时，其只是报告监控端，要人为地处理故障。其次，由于SCSI平台的硬盘比ATA的更为复杂，所以其检测属性也比ATA的多和复杂准确，如包括对盘片和驱动电路版的温度检测（ATA多只对盘片温度检测），对电压的检测等。USB在USB标准中，USB不能用于计算机内部储存设备的基本总线（如ATA，SCSI等），其本身没有为S.M.A.R.T.提供传输数据的途径。在使用ATA硬盘，以USB为传输端口的移动硬盘中，即使硬盘内S.M.A.R.T.仍然运作，但没办法直接向系统提供S.M.A.R.T.的数据。现在新的移动硬盘的内部驱动转换电路已经能以一些方法将硬盘内S.M.A.R.T.的数据通过USB传输到系统或监控程序中读取。
S.M.A.R.T(Self&Monitoring&Analysis&and&Reporting&Technology&/自我监测、分析与报告技术)是为了提高硬盘数据的安全性而开发的。它可以使硬盘实时检查自身的状态，通过一定机理及时分析出潜在的问题，报告给系统，有时甚至能给出预计的硬盘故障日期，实际就是一种预警技术。这个功能可以比较客观的反映硬盘目前的健康状况。
Value/Current(当前值)&当前硬盘改属性的值。
Worst(最坏值)&该属性出现过的峰值。
Threshold/Warn(阈值/临界/极限值)&硬盘厂商所规定的该属性峰值。如果某个属性超过Threshold规定的极限值时，就表示你的硬盘可能出现了问题。
Raw&Values/Data&(Raw值/数据)&。和该属性有关联的数据总值。
怎么看这类属性？
主要是看Raw和Worst的值是否还在临界值之内(&或&临界值)
一般使用软件如HDTune、CrystalDiskInfo等，一般属性中有黄色或者红色你就要注意了，硬盘可能快坏了，要是还在保修期内，就赶紧备份数据，送去检修。
下面我们来介绍各个属性(按日&维基百科&上的解释)
ID&Hex&=英文属性名&/&中文属性名&属性描述
--------------------------------------------------
01&01&=Read&Error&Rate&/&(底层)数据读取错误率
指从磁盘表面读取数据时发生的硬件读取错误的比率，Raw值对于不同的厂商有着不同的体系，单纯看做1个十进制数字是没有任何意义的。
*以上为Wiki上的英文翻译版本，此属性貌似存在分歧，有的说值高了好，有的说低了好,此处我们还是按照Wiki上的吧，反正只要&Worst不小于&Threshold&就行了。
**这里的Raw值也可能不同，比如我笔记本上的ST硬盘就Raw为0，而台式机上1.5T的ST就为。
02&02&=Throughput&Performance&/&吞吐性能(读写通量性能)
Raw值越高越好
整体(普通)的硬盘驱动器的吞吐性能。如果这个属性的值一直在下降有很大的可能性是硬盘有问题了。
*&一般在进行了人工&Offline&S.M.A.R.T.&测试以后才会有值。
03&03&=Spin-Up&Time&/&马达旋转到标准转速所需时间
Raw值越低越好
主轴旋转加速的平均时间(从零转速到完全运转(标准转速)[毫秒])。
单位也可能为秒。
如果是0的话证明这一项没有读对，或者是这一项的数据生成错误。不应该出现0的结果。
04&04&=Start/Stop&Count&/&启动/停止计数
马达&启动/停止&周期的计数。当马达启动或硬盘完全停止工作后(断开电源)启动和硬盘从睡眠模式回复到先前状态，计数都会增加。
*一般来说开机一次这个就加1，也可以看做是通电次数，这一般是个寿命参考值，本身不具有任何指标性，购买硬盘时可以参考此值。
05&05&=Reallocated&Sectors&Count&/&重新配扇区的计数
Raw值越低越好
对重新分配的扇区的计数，当硬盘发现一个&读取/写入/校验&错误时它将这个扇区标示为“重新分配”，并且将数据传输到一个特殊的保留区(空闲区)。这个过程也称为是“重定向”，这个重新分配的扇区叫做“重新映射”。这就是为什么，现在的硬盘当进行表面测试的时候是找不到“坏块”的，所有的坏块都被隐藏在重新分配的扇区中。然而，随着重新定位的扇区增加，读取/写入速度趋向于降低。Raw值通常代表一系列已经发现和重映射的坏扇区，因此，这个属性值越高，硬盘就有越多的扇区被重定位，所以这个值是越小越好。
*&理想情况下这个值应该为0，如果不为0也不要太惊慌，而是应该比较密切的关注这个值的变化情况：如果连续几周没有变化，那你应该可以放心的继续使用比较长的一段时间；如果这个值持续攀升，那么请尽快备份所有数据，并考虑购买新硬盘。
06&06&=Read&***nel&Margin&/&读取通道边界
读取数据时通道的边界，这个属性的功能并不明确
07&07&=Seek&Error&Rate&/&寻道错误率
磁头寻道错误的比率，如果机械定位系统中有局部的故障，那么寻道错误率会增加，这种故障是多种因素造成的。Raw值对于不同的厂商有着不同的体系，单纯看做1个十进制数字是没有任何意义的
08&08&=Seek&Time&Performance&/&寻道时间性能
Raw值越高越好
磁头寻道操作的平均性能，如果这个属性的值持续下降，这是机械子系统有问题的标志
09&09&=Power-On&Hours&(POH)&/&累计通电时间
Raw值越低越好
通电时间计数，Raw值显示在通电状态下的总小时数(或者是&分钟，秒，取决于制造商)
磁盘加电时间。初始值的字段显示为此装置总开机时间的累计。
*&参考磁盘厂家给的该款硬盘的&MTBF(平均故障间隔时间)&可以估计故障概率。但是也有可能超过MTBF而不会出现故障，因为统计数据对于个体来说是不精确的，是一个寿命参考值，本身不具任何指标性。
**购买硬盘时可以看此值，新的硬盘一般为0或者几十以内，过分大的可能就是被人用过了。
10&0A&=Spin&Retry&Count&或&Spin-up&Retry&Count&/&旋转重试计数&或&马达重试计数
Raw值越低越好
马达重试启动尝试的的总数，这个属性存储马达尝试启动的到全速运转(第一次尝试失败的情况)的总数，这个属性的值的上升，是硬盘机械子系统有问题的标志
*&理想情况应该为0，在某些情况下可能人为造成这个值的非故障升高，比如电压供给不足。
11&0B&=Recalibration&Retries&/&校准重试
Calibration_Retry_Count&/&校准重试计数&
Raw值越低越好
这个属性指被要求重新校验的次数(第一次尝试失败的情况下)。这个属性的值的上升，是硬盘机械子系统有问题的标志
12&0C&=Power&Cycle&Count&/&通电周期计数
这个属性是指这个硬盘电源&开/关&周期的总数。
这是个寿命参考值，本身不具任何指标性。
13&0D&=Soft&Read&Error&Rate&/&软件读出误码率(可校正读出误码率)
Raw值越低越好
报告给操作系统的未修正的读取错误。
高值暗示有扇区不稳定。
183&B7&=SATA&Downshift&Error&Count&/&SATA&降档错误计数
西部数据和三星的属性。
184&B8&=End-to-End&error&/&端对端错误
Raw值越低越好
这个属性是HP的SMART&IV技术的一部分，它表示传输通过高速缓存内存数据缓冲区后主机和硬盘驱动器间的校验数据不匹配。
185&B9&=Head&Stability&/&头稳定性
西部数据的属性。
186&BA&=Induced&Op-Vibration&Detection&/&感应运算振动检测
西部数据的属性。
187&BB&=Reported&Uncorrectable&Errors&/&反馈无法校正的错误
Raw值越低越好
不能使用硬件ECC恢复的错误总数。
188&BC&=Command&Timeout&/&命令超时
Raw值越低越好
因为HDD超时导致放弃操作的数量，通常情况下，这个属性值应该等于0，如果这个只远远高于0，那么，很可能电源供应有很严重的问题，或者数据线被氧化。
189&BD&=High&Fly&Writes&/&高飞写入
Raw值越低越好
HDD生产商实现&一个飞行高度监视器来尝试对于检测到记录头正在飞出它的正常操作范围时的写入操作提供额外的保护，如果发生不安全的飞行高度条件，写入进程停止工作，信息将被重写或者重定向到磁盘上一个安全的区域。这个显示在硬盘生命周期内检测到的这些错误的总数。这个特性实现在大多数现代的希捷驱动器和一些西部数据的驱动器中，西部数据驱动器开始于&WD企业级WDE18300和WDE9180&Ultra2&SCSI硬盘驱动器，它将被包含在未来所有西部数据企业级产品中。
190&BE&=Airflow&Temperature&(WDC)&/&气流温度(西部数据)
Raw值越低越好
西部数据硬盘上的气流温度(和[C2]的&Temperature&数值一样，但是在有些型号上臂当前值会少50.此值已经废弃了)。
190&BE&=Temperature&Difference&from&100&/&从100开始的温差
Raw值越高越好
值和&(100&–&温度°C)相同,&允许制造商对于符合的最高温度设置一个最小限制(可能是希捷专有？)。
191&BF&=G-sense&Error&Rate&/&加速度错误率&或&震动侦测错误率
Raw值越低越好
因外来的冲击和震动导致的错误数。
192&C0&=Power-off&Retract&Count&/&断电磁头缩回计数
Emergency&Retract&Cycle&Count&(Fujitsu)&/&紧急回缩周期计数(富士通)&
Raw值越低越好
磁头被载离媒体的次数计数。磁头能在没完全断电的前缩回。
*这个属性所显示的数字表示这块磁盘自动关机(突然断电)的次数。保持登录。
单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.
在您首次登录 developerWorks 时，会为您创建一份个人概要。您的个人概要中的信息（您的姓名、国家/地区，以及公司名称）是公开显示的，而且会随着您发布的任何内容一起显示，除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。
所有提交的信息确保安全。
当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。
单击提交则表示您同意developerWorks
的条款和条件。 .
所有提交的信息确保安全。
developerWorks 社区:
我的概要信息
选择语言：
很多应用譬如监控、即时通信、即时报价系统都需要将后台发生的变化实时传送到客户端而无须客户端不停地刷新、发送请求。本文首先介绍、比较了常用的“服务器推”方案，着重介绍了 Comet － 使用 HTTP 长连接、无须浏览器安装插件的两种“服务器推”方案：基于 AJAX 的长轮询方式；基于 iframe 及 htmlfile 的流方式。最后分析了开发 Comet 应用需要注意的一些问题，以及如何借助开源的 Comet 框架－pushlet 构建自己的“服务器推”应用。
(), 软件工程师, IBM 中国软件开发技术实验室
周婷，软件工程师，目前在 IBM 中国软件开发技术实验室从事刀片服务器管理固件的开发工作。您可以通过
和她联系。
“服务器推”技术的应用传统模式的 Web 系统以客户端发出请求、服务器端响应的方式工作。这种方式并不能满足很多现实应用的需求，譬如：监控系统：后台硬件热插拔、LED、温度、电压发生变化；即时通信系统：其它用户登录、发送信息；即时报价系统：后台数据库内容发生变化；这些应用都需要服务器能实时地将更新的信息传送到客户端，而无须客户端发出请求。“服务器推”技术在现实应用中有一些解决方案，本文将这些解决方案分为两类：一类需要在浏览器端安装插件，基于套接口传送信息，或是使用 RMI、CORBA 进行远程调用；而另一类则无须浏览器安装任何插件、基于 HTTP 长连接。将“服务器推”应用在 Web 程序中，首先考虑的是如何在功能有限的浏览器端接收、处理信息：客户端如何接收、处理信息，是否需要使用套接口或是使用远程调用。客户端呈现给用户的是 HTML 页面还是 Java applet 或 Flash 窗口。如果使用套接口和远程调用，怎么和 JavaScript 结合修改 HTML 的显示。客户与服务器端通信的信息格式，采取怎样的出错处理机制。客户端是否需要支持不同类型的浏览器如 IE、Firefox，是否需要同时支持 Windows 和 Linux 平台。基于客户端套接口的“服务器推”技术Flash XMLSocket如果 Web 应用的用户接受应用只有在安装了 Flash 播放器才能正常运行， 那么使用 Flash 的 XMLSocket 也是一个可行的方案。这种方案实现的基础是：Flash 提供了 XMLSocket 类。JavaScript 和 Flash 的紧密结合：在 JavaScript 可以直接调用 Flash 程序提供的接口。具体实现方法：在 HTML 页面中内嵌入一个使用了 XMLSocket 类的 Flash 程序。JavaScript 通过调用此 Flash 程序提供的套接口接口与服务器端的套接口进行通信。JavaScript 在收到服务器端以 XML 格式传送的信息后可以很容易地控制 HTML 页面的内容显示。关于如何去构建充当了 JavaScript 与 Flash XMLSocket 桥梁的 Flash 程序，以及如何在 JavaScript 里调用 Flash 提供的接口，我们可以参考 AFLAX（Asynchronous Flash and XML）项目提供的 Socket Demo 以及 SocketJS（请参见 ）。Javascript 与 Flash 的紧密结合，极大增强了客户端的处理能力。从 Flash 播放器 V7.0.19 开始，已经取消了 XMLSocket 的端口必须大于 1023 的限制。Linux 平台也支持 Flash XMLSocket 方案。但此方案的缺点在于：客户端必须安装 Flash 播放器；因为 XMLSocket 没有 HTTP 隧道功能，XMLSocket 类不能自动穿过防火墙；因为是使用套接口，需要设置一个通信端口，防火墙、代理服务器也可能对非 HTTP 通道端口进行限制；不过这种方案在一些网络聊天室，网络互动游戏中已得到广泛使用。Java Applet 套接口 在客户端使用 Java Applet，通过 java.net.Socket 或 java.net.DatagramSocket 或 java.net.MulticastSocket 建立与服务器端的套接口连接，从而实现“服务器推”。这种方案最大的不足在于 Java applet 在收到服务器端返回的信息后，无法通过 JavaScript 去更新 HTML 页面的内容。 基于 HTTP 长连接的“服务器推”技术Comet 简介浏览器作为 Web 应用的前台，自身的处理功能比较有限。浏览器的发展需要客户端升级软件，同时由于客户端浏览器软件的多样性，在某种意义上，也影响了浏览器新技术的推广。在 Web 应用中，浏览器的主要工作是发送请求、解析服务器返回的信息以不同的风格显示。AJAX 是浏览器技术发展的成果，通过在浏览器端发送异步请求，提高了单用户操作的响应性。但 Web 本质上是一个多用户的系统，对任何用户来说，可以认为服务器是另外一个用户。现有 AJAX 技术的发展并不能解决在一个多用户的 Web 应用中，将更新的信息实时传送给客户端，从而用户可能在“过时”的信息下进行操作。而 AJAX 的应用又使后台数据更新更加频繁成为可能。图 1. 传统的 Web 应用模型与基于 AJAX 的模型之比较“服务器推”是一种很早就存在的技术，以前在实现上主要是通过客户端的套接口，或是服务器端的远程调用。因为浏览器技术的发展比较缓慢，没有为“服务器推”的实现提供很好的支持，在纯浏览器的应用中很难有一个完善的方案去实现“服务器推”并用于商业程序。最近几年，因为 AJAX 技术的普及，以及把 IFrame 嵌在“htmlfile“的 ActiveX 组件中可以解决 IE 的加载显示问题，一些受欢迎的应用如 meebo，gmail+gtalk 在实现中使用了这些新技术；同时“服务器推”在现实应用中确实存在很多需求。因为这些原因，基于纯浏览器的“服务器推”技术开始受到较多关注，Alex Russell（Dojo Toolkit 的项目 Lead）称这种基于 HTTP 长连接、无须在浏览器端安装插件的“服务器推”技术为“Comet”。目前已经出现了一些成熟的 Comet 应用以及各种开源框架；一些 Web 服务器如 Jetty 也在为支持大量并发的长连接进行了很多改进。关于 Comet 技术最新的发展状况请参考关于 Comet 的 wiki。下面将介绍两种 Comet 应用的实现模型。基于 AJAX 的长轮询（long-polling）方式如
所示，AJAX 的出现使得 JavaScript 可以调用 XMLHttpRequest 对象发出 HTTP 请求，JavaScript 响应处理函数根据服务器返回的信息对 HTML 页面的显示进行更新。使用 AJAX 实现“服务器推”与传统的 AJAX 应用不同之处在于：服务器端会阻塞请求直到有数据传递或超时才返回。客户端 JavaScript 响应处理函数会在处理完服务器返回的信息后，再次发出请求，重新建立连接。当客户端处理接收的数据、重新建立连接时，服务器端可能有新的数据到达；这些信息会被服务器端保存直到客户端重新建立连接，客户端会一次把当前服务器端所有的信息取回。图 2. 基于长轮询的服务器推模型一些应用及示例如 “Meebo”, “Pushlet Chat” 都采用了这种长轮询的方式。相对于“轮询”（poll），这种长轮询方式也可以称为“拉”（pull）。因为这种方案基于 AJAX，具有以下一些优点：请求异步发出；无须安装插件；IE、Mozilla FireFox 都支持 AJAX。在这种长轮询方式下，客户端是在 XMLHttpRequest 的 readystate 为 4（即数据传输结束）时调用回调函数，进行信息处理。当 readystate 为 4 时，数据传输结束，连接已经关闭。Mozilla Firefox 提供了对 Streaming AJAX 的支持， 即 readystate 为 3 时（数据仍在传输中），客户端可以读取数据，从而无须关闭连接，就能读取处理服务器端返回的信息。IE 在 readystate 为 3 时，不能读取服务器返回的数据，目前 IE 不支持基于 Streaming
AJAX。基于 Iframe 及 htmlfile 的流（streaming）方式iframe 是很早就存在的一种 HTML 标记， 通过在 HTML 页面里嵌入一个隐蔵帧，然后将这个隐蔵帧的 SRC 属性设为对一个长连接的请求，服务器端就能源源不断地往客户端输入数据。图 3. 基于流方式的服务器推模型上节提到的 AJAX 方案是在 JavaScript 里处理 XMLHttpRequest 从服务器取回的数据，然后 Javascript 可以很方便的去控制 HTML 页面的显示。同样的思路用在 iframe 方案的客户端，iframe 服务器端并不返回直接显示在页面的数据，而是返回对客户端 Javascript 函数的调用，如“&script type="text/javascript"&js_func(“data from server ”)&/script&”。服务器端将返回的数据作为客户端 JavaScript 函数的参数传递；客户端浏览器的 Javascript 引擎在收到服务器返回的 JavaScript 调用时就会去执行代码。从
可以看到，每次数据传送不会关闭连接，连接只会在通信出现错误时，或是连接重建时关闭（一些防火墙常被设置为丢弃过长的连接， 服务器端可以设置一个超时时间， 超时后通知客户端重新建立连接，并关闭原来的连接）。使用 iframe 请求一个长连接有一个很明显的不足之处：IE、Morzilla Firefox 下端的进度栏都会显示加载没有完成，而且 IE 上方的图标会不停的转动，表示加载正在进行。Google 的天才们使用一个称为“htmlfile”的 ActiveX 解决了在 IE 中的加载显示问题，并将这种方法用到了 gmail+gtalk 产品中。Alex Russell 在 “What else is burried down in the depth's of Google's amazing JavaScript?”文章中介绍了这种方法。Zeitoun 网站提供的 comet-iframe.tar.gz，封装了一个基于 iframe 和 htmlfile 的 JavaScript comet 对象，支持 IE、Mozilla Firefox 浏览器，可以作为参考。（请参见 ）使用 Comet 模型开发自己的应用上面介绍了两种基于 HTTP 长连接的“服务器推”架构，更多描述了客户端处理长连接的技术。对于一个实际的应用而言，系统的稳定性和性能是非常重要的。将 HTTP 长连接用于实际应用，很多细节需要考虑。不要在同一客户端同时使用超过两个的 HTTP 长连接我们使用 IE 下载文件时会有这样的体验，从同一个 Web 服务器下载文件，最多只能有两个文件同时被下载。第三个文件的下载会被阻塞，直到前面下载的文件下载完毕。这是因为 HTTP 1.1 规范中规定，客户端不应该与服务器端建立超过两个的 HTTP 连接， 新的连接会被阻塞。而 IE 在实现中严格遵守了这种规定。HTTP 1.1 对两个长连接的限制，会对使用了长连接的 Web 应用带来如下现象：在客户端如果打开超过两个的 IE 窗口去访问同一个使用了长连接的 Web 服务器，第三个 IE 窗口的 HTTP 请求被前两个窗口的长连接阻塞。所以在开发长连接的应用时， 必须注意在使用了多个 frame 的页面中，不要为每个 frame 的页面都建立一个 HTTP 长连接，这样会阻塞其它的 HTTP 请求，在设计上考虑让多个 frame 的更新共用一个长连接。服务器端的性能和可扩展性一般 Web 服务器会为每个连接创建一个线程，如果在大型的商业应用中使用 Comet，服务器端需要维护大量并发的长连接。在这种应用背景下，服务器端需要考虑负载均衡和集群技术；或是在服务器端为长连接作一些改进。应用和技术的发展总是带来新的需求，从而推动新技术的发展。HTTP 1.1 与 1.0 规范有一个很大的不同：1.0 规范下服务器在处理完每个 Get/Post 请求后会关闭套接口连接； 而 1.1 规范下服务器会保持这个连接，在处理两个请求的间隔时间里，这个连接处于空闲状态。 Java 1.4 引入了支持异步 IO 的 java.nio 包。当连接处于空闲时，为这个连接分配的线程资源会返还到线程池，可以供新的连接使用；当原来处于空闲的连接的客户发出新的请求，会从线程池里分配一个线程资源处理这个请求。 这种技术在连接处于空闲的机率较高、并发连接数目很多的场景下对于降低服务器的资源负载非常有效。但是 AJAX 的应用使请求的出现变得频繁，而 Comet 则会长时间占用一个连接，上述的服务器模型在新的应用背景下会变得非常低效，线程池里有限的线程数甚至可能会阻塞新的连接。Jetty 6 Web 服务器针对 AJAX、Comet 应用的特点进行了很多创新的改进，请参考文章“AJAX，Comet and Jetty”（请参见 ）。控制信息与数据信息使用不同的 HTTP 连接使用长连接时，存在一个很常见的场景：客户端网页需要关闭，而服务器端还处在读取数据的堵塞状态，客户端需要及时通知服务器端关闭数据连接。服务器在收到关闭请求后首先要从读取数据的阻塞状态唤醒，然后释放为这个客户端分配的资源，再关闭连接。所以在设计上，我们需要使客户端的控制请求和数据请求使用不同的 HTTP 连接，才能使控制请求不会被阻塞。在实现上，如果是基于 iframe 流方式的长连接，客户端页面需要使用两个 iframe，一个是控制帧，用于往服务器端发送控制请求，控制请求能很快收到响应，不会被堵塞；一个是显示帧，用于往服务器端发送长连接请求。如果是基于 AJAX 的长轮询方式，客户端可以异步地发出一个 XMLHttpRequest 请求，通知服务器端关闭数据连接。在客户和服务器之间保持“心跳”信息在浏览器与服务器之间维持一个长连接会为通信带来一些不确定性：因为数据传输是随机的，客户端不知道何时服务器才有数据传送。服务器端需要确保当客户端不再工作时，释放为这个客户端分配的资源，防止内存泄漏。因此需要一种机制使双方知道大家都在正常运行。在实现上：服务器端在阻塞读时会设置一个时限，超时后阻塞读调用会返回，同时发给客户端没有新数据到达的心跳信息。此时如果客户端已经关闭，服务器往通道写数据会出现异常，服务器端就会及时释放为这个客户端分配的资源。如果客户端使用的是基于 AJAX 的长轮询方式；服务器端返回数据、关闭连接后，经过某个时限没有收到客户端的再次请求，会认为客户端不能正常工作，会释放为这个客户端分配、维护的资源。当服务器处理信息出现异常情况，需要发送错误信息通知客户端，同时释放资源、关闭连接。Pushlet - 开源 Comet 框架Pushlet 是一个开源的 Comet 框架，在设计上有很多值得借鉴的地方，对于开发轻量级的 Comet 应用很有参考价值。观察者模型Pushlet 使用了观察者模型：客户端发送请求，订阅感兴趣的事件；服务器端为每个客户端分配一个会话 ID 作为标记，事件源会把新产生的事件以多播的方式发送到订阅者的事件队列里。客户端 JavaScript 库pushlet 提供了基于 AJAX 的 JavaScript 库文件用于实现长轮询方式的“服务器推”；还提供了基于 iframe 的 JavaScript 库文件用于实现流方式的“服务器推”。JavaScript 库做了很多封装工作：定义客户端的通信状态：STATE_ERROR、STATE_ABORT、STATE_NULL、STATE_READY、STATE_JOINED、STATE_LISTENING；保存服务器分配的会话 ID，在建立连接之后的每次请求中会附上会话 ID 表明身份；提供了 join()、leave()、subscribe()、 unsubsribe()、listen() 等 API 供页面调用；提供了处理响应的 JavaScript 函数接口 onData()、onEvent()…网页可以很方便地使用这两个 JavaScript 库文件封装的 API 与服务器进行通信。客户端与服务器端通信信息格式pushlet 定义了一套客户与服务器通信的信息格式，使用 XML 格式。定义了客户端发送请求的类型：join、leave、subscribe、unsubscribe、listen、refresh；以及响应的事件类型：data、join_ack、listen_ack、refresh、heartbeat、error、abort、subscribe_ack、unsubscribe_ack。
服务器端事件队列管理pushlet 在服务器端使用 Java Servlet 实现，其数据结构的设计框架仍可适用于 PHP、C 编写的后台客户端。Pushlet 支持客户端自己选择使用流、拉（长轮询）、轮询方式。服务器端根据客户选择的方式在读取事件队列（fetchEvents）时进行不同的处理。“轮询”模式下 fetchEvents() 会马上返回。”流“和”拉“模式使用阻塞的方式读事件，如果超时，会发给客户端发送一个没有新信息收到的“heartbeat“事件，如果是“拉”模式，会把“heartbeat”与“refresh”事件一起传给客户端，通知客户端重新发出请求、建立连接。客户服务器之间的会话管理服务端在客户端发送 join 请求时，会为客户端分配一个会话 ID， 并传给客户端，然后客户端就通过此会话 ID 标明身份发出 subscribe 和 listen 请求。服务器端会为每个会话维护一个订阅的主题集合、事件队列。服务器端的事件源会把新产生的事件以多播的方式发送到每个会话（即订阅者）的事件队列里。小结本文介绍了如何在现有的技术基础上选择合适的方案开发一个“服务器推”的应用，最优的方案还是取决于应用需求的本身。相对于传统的 Web 应用， 目前开发 Comet 应用还是具有一定的挑战性。“服务器推”存在广泛的应用需求，为了使 Comet 模型适用于大规模的商业应用，以及方便用户构建 Comet 应用，最近几年，无论是服务器还是浏览器都出现了很多新技术，同时也出现了很多开源的 Comet 框架、协议。需求推动技术的发展，相信 Comet 的应用会变得和 AJAX 一样普及。
参考资料 developerWorks 文章“
”：受异步服务器端事件驱动的 Ajax 应用程序实现较为困难，本文介绍了一种结合使用 Comet 模式和 Jetty 6 Continuations API 的解决方法。
“”：Alex Russell 是 Dojo Toolkit 的项目主管和 Dojo Foundation 的主席，他在这篇博客文章中提出了 Comet 这个术语。
“”（Alex Russel，2006 年 2 月）：Alex 在这篇文章里介绍了如何使用“htmlfile”ActiveX 控件解决 iframe 请求长连接时 IE 的加载显示问题。：提供了很多开源 Comet 框架的链接。：Jetty 是一种开源的基于标准的 Web 服务器，完全使用 Java 语言实现。
“”（Greg Wilkins，Webtide，2006 年 1 月）：Wilkins 的这份白皮书讨论了扩展 Ajax 连接的 Jetty 架构方法。：了解更多关于 Jetty 的 Continuations 特性的信息。
“”：开源 comet 框架，使用了观察者模型。浏览器端提供了基于 AJAX 和 iframe 的 JavaScript 库，服务器端使用 Java Servlet。
“”：提供的 comet-iframe.tar.gz 使用 iframe/htmlfile 封装了一个 JavaScript comet 对象，支持 IE、Mozilla Firefox 浏览器。
“”：Asynchronous Flash and XML，提供了强大的 Flash、Javascript 库和很多范例。：能找到更多关于 Ajax 技术的文章和教程。：提供了关于 Web 开发和架构方面的大量文章。：提供了关于 Java 编程各个方面的数百篇文章。 浏览 ，查阅有关本文所述主题以及其他技术主题的书籍。
：下载 Jetty。
查看 ，加入 。
developerWorks: 登录
标有星（*）号的字段是必填字段。
保持登录。
单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件。
在您首次登录 developerWorks 时，会为您创建一份个人概要。您的个人概要中的信息（您的姓名、国家/地区，以及公司名称）是公开显示的，而且会随着您发布的任何内容一起显示，除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。
所有提交的信息确保安全。
选择您的昵称
当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。昵称长度在 3 至 31 个字符之间。
您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。
标有星（*）号的字段是必填字段。
(昵称长度在 3 至 31 个字符之间)
单击提交则表示您同意developerWorks 的条款和条件。 .
所有提交的信息确保安全。
IBM PureSystems(TM) 系列解决方案是一个专家集成系统
通过学习路线图系统掌握软件开发技能
软件下载、试用版及云计算
static.content.url=/developerworks/js/artrating/SITE_ID=10Zone=Web development, Java technology, Open sourceArticleID=252250ArticleTitle=Comet：基于 HTTP 长连接的“服务器推”技术publish-date=}