WebCache系统集中采购工程技术规范书.doc

WebCache系统集中采购工程技术规范书

65
2020年5月29日
文档仅供参考

中国移动 Web Cache系统集中采购工程
技 术 规 范 书

中国移动通信有限公司
8月

目 录
1 总则 1
1.1 概述 1
1.2 技术规范 1
1.3 总体技术要求 1
1.4 规范书应答要求 2
1.5 技术文件 2
1.6 技术建议书应包括的内容 3
1.7 报价要求 4
2 Web Cache系统建设主要技术要求 6
2.1 Web Cache系统请求引导机制 6
2.2 Web Cache系统建设功能要求 9
2.3 与其它系统接口 23
2.4 局域网组网结构 23
2.5 安全策略 23
2.6 网管需求 24
3 设备硬件要求 25
3.1 总体要求 25
3.2 模块化、冗余、容错等 26
3.3 服务器的要求 26
3.4 网络设备要求 26
4 软件要求 27
4.1 模块化 27
4.2 人机控制 27
4.3 兼容性及升级 27
4.4 操作系统 27
4.5 软件系统优化 27
5 系统容量要求 28
5.1 系统容量的定义 28
5.2 系统容量要求 28
5.3 系统扩展要求 28
5.4 本期集中采购建设规模需求 29
6 电源要求 31
7 设备安装调测、验收以及试运行 31
7.1 安装和调试 31
7.2 验收 32
8 技术服务和培训 32
8.1 技术服务 32
8.2 培训 33

1 总则
1.1 概述
本文件是中国移动通信有限公司(以下简称买方) Web Cache系统集中采购工程向设备厂商(以下简称卖方)提出的技术规范书。本规范书与相关规范一起将作为 集中采购Web Cache系统主设备的技术文件。根据此文件,卖方应提出具体的技术应答和详细的报价。
1.2 技术规范
卖方所提供的所有各项设备和系统(包括软、硬件)应符合技术标准的要求如下:
(1) 符合有关标准(如ISO、ITU-T、ETSI、IETF等),卖方应在建议书中具体说明,并附上相应的详细技术资料;
(2) 符合中国移动通信有限公司<中国移动WebCache系统总体技术要求>、<中国移动WebCache系统设备规范>、<中国移动WebCache系统接口规范>、<工程和维护合同安全管理要求>等相关规范中对流程、设备、网管等方面的要求,且以上规范今后如有修改,卖方应免费修改其系统以满足要求;卖方如对以上规范内容有不满足的地方,请给出技术上不满足情况的偏离表(偏离表格式详见附件一)并做出相应说明。对于满足部分,应给出明确的书面承诺。
(3) 国家已颁发的相关法律文件(例如招标法等)。
1.3 总体技术要求
(1) 卖方应按照本文件的要求提供报价和详细的技术建议。卖方应承诺所提供的设备在产品性能、技术指标、服务内容等方面满足本技术规范书的要求。对于本文件未规定的有关设备性能,卖方应提出建议,并陈述其理由。
(2)本文件提出的具体技术要求如与上述文件及补充规范不一致的地方,以本文件为准。
(3)当买方有新建议,而本技术规范书又尚未包括或与本技术规范书不符时,则应符合买方新建议的要求;对于买方尚未有标准的,而本技术规范书又未提及的部分,卖方提出其标准,留待双方认可后执行。
(4)当卖方的设备中包含自己的专用标准,应在建议书中具体说明,并附上相应的详细资料。
(5)卖方应列出其建议书中所提供设备和系统在世界范围内和国内的应用情况,诸如最大规模、业务类型及开展方式等。
(6)卖方提供的设备,硬件设备从系统最终验收开通之日起五年内,如果买方需要,卖方应以不高于本次价格提供备板、备件,卖方不得以设备停产等理由而拒绝提供。如果由于买方系统改进或扩容,所需的软件设备卖方应以不高于本次价格提供。
(7)在合同签订之前,买方能够随时对本技术规范书进行修改。
(8)本技术规范书解释权归中国移动通信有限公司。
1.4 规范书应答要求
(1)卖方对于技术规范书的疑问能够经过书面材料与买方联系。在规定的建议书提交最后期限以前,买方将以书面材料给予答复。有关买方答复材料的复印件也将递交所有得到技术规范书的卖方。
(2) 在技术谈判的各个阶段,买方将以书面形式要求卖方对有关问题进行进一步的技术澄清,卖方应以书面资料给予正式应答;所有各阶段的技术澄清文件都将作为合同附件。
(3)买方在任何时候保留和拥有对本文件的解释权。买方有权在签定合同前,根据需要修改和补充本技术规范书,修改补充后的最终技术规范书将作为合同的附件。
(4)卖方的应答书中,要求对本文件的所提出的各项条款进行逐项答复、说明和解释,首先对实现或满足程度明确作出”满足”、”部分满足”、”不满足”等应答。在答复中,凡采用”详见”、”参见”方式说明的,应指明参见文档的具体章节或页码。请卖方特别注意:凡采用”详见”、”参见”方式说明的条款,必须在点对点应答书中注有适当的总结性文字,简洁、明了地回答相应的条款。对于本文件中要求列举的条款,必须在点对点应答书中进行列举,不得简单答复”满足”等,否则视该条款的应答为”不满足”。如果回答”部分满足”,需要详细说明哪些部分满足,哪些部分不满足,而且详细说明原因。卖方应答应与详细的说明内容一致,如果应答与说明内容矛盾则视为”不满足”。
1.5 技术文件
卖方所提供的应答文本应按照以下内容格式进行编制:
附件一:系统价格清单;
(1)总清单
(2)分项清单
(3)设备配置说明
附件二:技术规范书及应答
(1)卖方点对点答复
附件三 :技术建议书
包括整个系统总体模块组成(包括网络、硬件、软件等)、各模块具体结构、配置依据、各种业务流程、系统与相关其它系统接口、系统管理、系统安全、统计等方面
附件四 :技术文件清单
应包含本次提供的技术文件的种类、数量及简要内容介绍
附件五 :软件功能清单
附件六 :工程实施计划
附件七 :设备情况、机架状况及场地环境要求
附件八:合同双方的责任分工及界面(要求图示并加以说明)
附件九:验收及测试
附件十: 工程协调会
附件十一:售后服务
附件十二 :最终用户人员培训
附件十三 :相关备忘录及承诺
附件十四:产品说明(包括相关资质及入网许可证)
1.6 技术建议书应包括的内容
1.6.1 系统概况
(1)Web Cache系统的结构、系统组成情况以及典型的工作流程。
(2)Web Cache系统与DPI、网管系统的连接方式。
(3)系统过负荷控制机制,即业务量达到或超过最大硬件处理能力的流控机制。
(4)系统的License控制机制,即在业务量超过License容量但未达到系统最大处理能力系统的处理流程。
1.6.2 系统配置
(1)现网各省Web Cache系统使用的服务器设备的型号配置。
(2)本工程计划使用的服务器设备的型号配置。
(3)主设备配置的核算方法。
1.6.3 系统容量
(1) 现网存在的各个版本以及各种硬件配置情况下单台设备的最大容量和处理能力。系统容量的定义见第5节系统容量需求。
(2)本期工程配置设备在各个版本下单台设备最大的容量和处理能力,并说明设备容量或处理能力的测试条件、方法和计算方法。
(3)Web Cache的容量需求的核算方法。
(4)Web Cache系统的病毒防护以及防止恶意攻击等安全防护机制。
1.6.4 版本情况
(1) 现网主设备的版本情况以及分布的省份。
(2) Web Cache系统的版本路标。
(3) 在各个新版本中提供的新的功能以及导致容量的变化情况。
(4) 版本升级需要进行软、硬件改造、增加的情况。
(5) 系统硬件对新版本的支持情况。
1.7 报价要求
1.7.1 总体要求
(1)报价应包括根据设备完备性要求的所有必须的硬件设备、软件以及系统集成所需要的安装材料、工具、技术文件及安装调测、培训、技术支持等;
(2)报价应包括硬件设备名称、型号及配置模块、数量,软件模块、版本、Licence数量、相关配置情况,系统集成所需要的相关软硬件及配套设备和部件等详细内容;
(3)报价应以人民币为单位;
(4)报价应按目录价列清单;
(5)报价应详细列出提供终验后一年服务费用(包括系统维护所需要的软硬件费用和技术服务费用),以及相应的服务水平;
(6)报价应详细列出人员培训的单价;
(7)卖方在报价中应明确标注采用的第三方软、硬件。
(8)针对本工程所建系统,在本工程实施后买方针对原需求若有部分变化、买方有新的有关标准制定出来或者原有标准进行修改后,对于本工程所建系统已有同等功能的改进、完善、优化等,卖方应免费修改其系统以满足要求。
1.7.2 报价方式
(1) 设备以人民币为单位报价。
(2)报价应报出设备到现场价。
(3) 卖方应承诺当所购置设备种类、数量发生变化时,所提供的价格折扣水平、技术服务等方面的各种优惠条件不变。
(4) 卖方应承诺在随后的工程扩容、备件采购中,采购同种设备的价格水平不高于本次的价格水平。
(5) 本技术规范书为保证网络运行所需的最低要求,如有遗漏,卖方应予以补充,否则一旦中标将认为卖方认同遗漏部分并免费提供。
(6) 卖方应说明随着网络规模的扩充、用户数的增加,其软硬件扩容方式及收费标准。
(7)要求卖方应用软件采用功能模块配置方法和/或许可证配置方法,其中功能模块的功能应与软件功能清单对应一致,许可证只能与系统处理能力(实际出口带宽)相关联,而且在Web Cache平台系统实际运行中系统达到该许可证数量时不应限制业务处理(而只是向网管系统发出告警信息,并在系统日志中记录),不接受许可证与某种形式的系统静态容量(例如服务器数量、设备数量)相关联的配置方法。
1.7.3 报价体系要求
请卖方按照以下各项要求分别报价:
(1)报价清单总表中应体现,硬件、软件、服务、培训部分的目录价,分类项目小计价格及总价。
(2)硬件清单分别提供服务器设备清单以及其它硬件部分的清单。服务器设备清单包含PC服务器以及PC终端设备。卖方购买服务器厂家提供商的服务应在服务器清单中作为单独条目列出。
(3)软件清单中卖方应将自产软件以及外购软件分别列出。
(4)设备应按类别分别提出详细的分项单价和总价,对能够独立工作或能够单独采购的设备和部件及软件模块均分别报价,即按不可拆分原则报价。
1.7.4 设备清单要求
(1)设备硬件应细分到板件。
(2)第三方提供的设备应详细的列出厂家名称,产品型号、设备配置等内容。
(3)软件清单应将自产软件和外购软件分别列出。
2 Web Cache系统建设主要技术要求
WebCache系统是在中国移动现有的IP承载网络中部署的缓存设备,存储互联网热点或特定内容。经过引导网内用户的访问请求转发到WebCache系统中,由WebCache系统直接将数据返回给用户,避免直接从互联网源站下载数据,从而降低客户访问互联网资源的时延,有效提升用户访问速度和质量,降低互联网出口拥塞的现状。从技术上解决由于网络带宽小、用户访问量大、互联网资源分布不均等原因所造成的用户访问互联网资源响应速度慢的问题,提升用户的业务感知,同时降低因网间流量产生的网间结算费用。
WebCache系统支持对Web浏览、文件下载、视频播放等基于HTTP协议的互联网业务进行加速,系统对于本地存储的文件格式、音视频及文件编码方式均没有特定要求,各类互联网音频、视频、图像、文本等文件均可经过系统实现缓存和加速服务。
WebCache系统应支持移动蜂窝网(2G/3G/LTE)、WLAN、固定宽带等不同的网络接入方式,并能够同时为PC、手机、Pad等不同形态的终端提供服务。
2.1 Web Cache系统请求引导机制
2.1.1 DNS重定向模式
WebCache系统经过检测用户侧发出的DNS解析请求,如果用户访问的站点域名属于系统配置的白名单,则在DNS解析响应消息中向用户返回WebCache系统的IP地址,引导用户的HTTP业务请求发送至WebCache系统,由WebCache系统响应用户访问请求。
在面向互联网网站、web小文件场景进行缓存加速时,建议WebCache系统优先采用DNS重定向模式。
对于文件下载、视频播放类的应用场景,也可选择采用DNS重定向模式。但对于以IP地址标识的对象,由于在下载过程前没有DNS解析流程,故无法经过DNS重定向模式进行处理。
DNS重定向模式下,WebCache系统可经过如下两种方式获取用户发起的DNS解析请求,在实际部署中建议根据网络部署情况选择使用。
(1) 分光镜像方式
分光镜像方式要求在需监测的链路上部署无源分光设备,将链路中的信号经过分光处理后发送至WebCache系统的DPI功能中。
DPI功能中应根据需要配置过滤流量的条件,如DNS协议类型、端口号等,将满足条件的用户请求转发送至后端的请求重定向功能模块。
在DPI功能中不开启流量过滤功能时,DPI功能会将全量的上行请求均发送至WebCache系统。此时由WebCache系统需根据本地配置的域名白名单进行匹配,如满足一致性条件,再向用户返回对应的重定向响应消息。
由于分光镜像模式需要在源网站的授权DNS返回响应结果之前对用户进行重定向,故要求重定向子系统发送重定向报文应当满足时延要求。
(2) DNS转发方式
DNS转发模式要求将省内的Local DNS与WebCache系统相连接。由管理员在Local DNS上开启Forward功能,并在转发策略中将需要加速的域名列表(白名单)配置为Forward First模式,目标为WebCache系统的调度服务器的IP地址。Forward First模式下DNS服务器会优先选择转发的目标DNS返回的解析结果,当Forward目标因故无法返回结果或返回结果延迟较大,Local DNS本身则会继续递归解析以获取解析结果。
当用户终端发起的DNS解析请求发送至Local DNS服务器后,DNS服务器将目标域名与本地配置的Forward名单进行匹配,如满足一致性条件,则将该条DNS解析请求前传至WebCache系统的请求调度功能模块。
WebCache系统的请求调度功能模块在接收到该条DNS解析请求后,应向Local DNS返回对应的DNS解析响应消息,解析结果的目标地址为缓存子系统的IP地址。
2.1.2 HTTP重定向模式
HTTP重定向模式包含非代理方式和代理方式两种处理机制:
l 非代理处理机制:仅当WebCache系统监测到用户发出的HTTP访问请求属于本地已缓存的资源,才由WebCache系统向用户返回HTTP 302重定向报文,响应报文的目标地址为WebCache系统的IP地址,用户终端接收到该条HTTP 302响应消息后,将向WebCache系统发起请求下载数据。
l 代理处理机制:HTTP重定向模式也支持工作于代理模式,对于满足域名匹配条件的请求均引导至缓存子系统,如已缓存则直接向用户提供服务;如该内容在本地未缓存时,则由WebCahe系统作为代理向外网下载并传送给用户侧。
在面向大文件下载、视频播放类的场景进行缓存加速时,建议WebCache系统优先采用HTTP重定向模式及非代理处理机制。
HTTP重定向机制下,WebCache系统应采用分光镜像方式获取用户发起的HTTP请求。经过在需监测的链路上部署无源分光设备,将链路中的信号经过分光处理后发送至WebCache系统的DPI功能中。DPI功能中应根据需要配置过滤流量的条件,如HTTP协议类型、端口号(80/8080)、关注域名或IP地址列表等维度,将满足一致性要求的HTTP请求转发送至后端的请求重定向功能模块。
由于分光镜像模式需要在源网站返回响应结果之前对用户进行重定向,故要求重定向子系统发送重定向报文应当满足时延要求。
特定场景下,也能够经过端口镜像方式获取用户请求。端口镜像模式主要面向网络流量较小的场景,经过在路由器或交换机上开启端口镜像功能,将所有流量均通特定端口转发至WebCache系统,并由DPI设备过滤出所需的HTTP流量。端口镜像方式可进行全流量进行,也能够依据能够是端口号、目标地址、源地址等进行镜像。
2.1.3 策略路由引导模式
策略路由模式主要应用于省网内部署的WebCache系统,经过在核心路由器上开启策略路由(PBR)功能,将满足条件的用户流量经过路由转发至WebCache系统,判断依据能够是端口号、目标地址、源地址等,后续相关的上行、下行流量均会经由WebCache系统进行处理,而无需向终端侧发送重定向报文。
对于用户请求,如果WebCache系统本地命中,则直接向用户返回数据;如果本地未命中,则由WebCache系统代理用户向源网站请求数据,并返回给用户。对于热点内容,由WebCache系统在本地存储一份副本。
对于思科路由器,也能够经过其专用的WCCP协议进行流量转发。
策略路由引导模式下,当网络中断时,路由器应能够自动调整为直通模式,避免可能出现的访问故障。
策略路由引导模式下,也能够采用发布BGP路由的方式将需加速的流量从核心路由器汇聚转发到WebCache系统专用的路由器,然后再在该台路由器上面配置PBR策略进行流量引导。
2.2 Web Cache系统建设功能要求
2.2.1 重定向子系统
2.2.1.1 深度报文解析模块
DPI设备经过串行或者旁路分光方式部署在网络汇聚节点,采集并分析业务原始网络数据流量及用户请求,将对应的用户流量转发至系统后端,为WebCache系统实施用户请求重定向提供基础数据支持。
在WebCache系统采用DNS 转发模式、策略路由引导模式时,由于WebCache系统能够直接从DNS服务器获得对应的DNS请求解析流量,从路由器直接获取到对应的用户HTTP流量,此时WebCache系统中也可不部署DPI设备,或由其它设备兼作。
1. 流量分析功能
DPI设备必须支持基于L3/L4信息、基于L7应用层特征(如应用层协议特征码)对数据流量进行分析和识别。
DPI设备必须支持HTTP、DNS协议。
2. 流量转发功能
DPI设备支持流量转发功能,具体要求如下:
l 支持对于满足设定规则匹配条件的报文进行处理,将满足匹配条件的报文从指定接口转发到用户请求调度设备,例如DNS解析请求报文、HTTP访问请求报文等;
l 支持灵活配置过滤转发规则,规则能够是指定协议类型、IP地址、端口号、流量方向、应用层特征等组合方式;
l 支持无效流量的灵活过滤,支持灵活按照协议类型、应用层特征、源/目的IP地址、流量方向等作为过滤条件,能够镜像出高比例收敛的有效流量;
l 支持配置多个出接口组,能够根据负载均衡策略实施转发;
3. 流量统计功能
DPI设备提供支持的流量统计功能如下:
l 支持多种流量统计,如对字节数、当前带宽、峰值流量、新增连接数、最大并发连接数、当前并发连接数等网络流量参数进行统计;
l 支持输出外部网站及域名的请求次数、流量统计及排名次序等统计数据;
l 支持经过手动或自动方式上报至其它外部系统,例如WebCache系统或全网管理控制中心;
2.2.1.2 用户请求调度模块
用户请求调度设备的主要功能是根据缓存白名单配置或者本地已缓存内容,将用户的访问请求重定向至后端的缓存子系统。
1. DNS重定向功能
用户请求调度设备处理接收到用户终端发出的DNS解析请求报文,根据WebCache系统服务器状态和配置参数,生成相应的DNS响应消息。
用户请求调度设备必须支持对DNS请求的源IP地址进行判断:
l 如果是WebCache系统发送的请求则不实施处理,该请求将被透传至外网上一级DNS服务器进行处理。
l 对于源IP地址为用户侧的DNS请求报文,如果WebCache系统运行正常,则将WebCache系统的IP地址作为DNS解析响应结果发送给用户终端。
l 支持对特定源IP地址的调度Bypass功能,对满足源地址匹配条件的DNS请求不进行重定向,不对这部分用户进行缓存加速。源IP地址段必须可灵活配置。
2. HTTP重定向功能
用户请求调度设备处理接收到用户终端发出的HTTP请求报文,并根据WebCache系统服务器状态、本地缓存数据以及IP地址配置参数等,生成对应的HTTP 302重定向消息,其中目标为缓存子系统的公网IP地址。
在缓存子系统中没有部署负载均衡设备的场景下,用户请求调度设备必须能够实时获取缓存子系统中已缓存的内容资源信息,对用户的HTTP请求进行综合判断,根据资源分布、设备负载以及内容策略等信息将用户的请求制定路由导向策略,将用户请求重定向至最合适的缓存服务器上。
如果用户请求调度设备监测到WebCache缓存子系统不可用,则不对用户的HTTP请求作出重定向操作。
支持对特定源IP地址的调度Bypass功能,对满足源IP地址匹配条件的HTTP请求不进行重定向,不对这部分用户进行缓存加速。源IP地址段必须可灵活配置。

3. 黑白名单功能
WebCache系统支持配置加速域名列表(白名单),仅对于白名单内的网站域名进行加速,对于其它请求不进行响应,也可返回DNS递归解析结果以保护用户DNS请求的成功性。
WebCache系统支持配置黑名单,包含非HTTP协议的域名和不适合进行缓存加速的域名,如邮箱域名、FTP域名、SSL域名等。
黑白名单域名信息配置必须支持如下2类方式:
l 精确域名:如
l 泛域名:如*,
可支持正则匹配域名配置方式:如dl[1-9]\.qq\.com,ww*\
对于黑白名单中配置的域名,用户请求调度设备仅对在白名单内、且不在黑名单内的访问请求进行响应。
当系统配置的白名单与黑名单存在交叠时,必须优先使用匹配黑名单的策略生效。
支持黑白名单的管理功能,支持手工增删改查。
4. 健康检查功能
用户请求调度设备支持经过多种方式监测缓存子系统的可用性及工作状态,能够根据缓存子系统的可用性及存储的文件内容进行调度。可用性至少应包括如下方面:
l 设备可达:设备硬件层面是否可用,例如可发送ICMP报文实施探测;
l 服务状态:检查TCP/UDP端口是否提供服务;
l 负载情况:接收并监测Cache服务器上报的设备状态负载信息,如CPU、内存、硬盘空间使用率等预先协商的数据项(可选);
用户请求调度设备的负载监测功能可经过SNMP协议实现,对WebCache服务器设备层面的监控项实施数据采集,此时缓存服务器中需要安装SNMP Agent服务。
用户请求调度设备根据设定的时间周期性探测对端设备的健康状态。如果在采集周期内缓存子系统出现不可用的状态,用户请求调度设备将继续探测以确认设备不可用,最多进行3次累计探测或探测累计时间在超时范围内,则判定系统不可用。
请求调度模块能够根据缓存子系统的可用性进行调度,具体要求如下:
l 缓存子系统单个文件损坏时,请求调度模块应自动停止对应损坏文件的重定向;
l 缓存子系统数据硬盘出现故障时,请求调度模块应自动停止对应故障磁盘缓存文件的重定向;
l 缓存子系统不可用时,请求调度模块应不对用户请求作出响应。
l 缓存子系统负载过重时,请求调度模块应自动识别,并降低向缓存子系统的重定向用户请求;
用户请求调度设备可支持经过HTTP方式对其它WebCache节点的可用性进行周期性检查。
5. 主备冗余功能
用户请求调度设备需具备冗余切换能力,两台设备之间使用网线传递心跳信号、主备切换触发信号,以监控对端设备的状态。
6. 策略同步功能
支持与管理子系统交互,获取本地缓存内容情况、以及由全网管控中心、内容资源管理平台或者其它外部网元实体下发的各类资源信息、内容信息以及调度策略数据,并在本地配置生效。
2.2.2 缓存子系统
2.2.2.1 负载均衡模块
1. 健康检查功能
负载均衡设备必须支持对Cache服务器资源的健康检查,常见的健康检查机制如下表所示。
系统的可用性至少应包括:
l 设备可达:设备硬件层面是否可用,可基于发送ICMP报文实施探测;
l 服务状态:检查TCP/UDP端口是否提供服务;
l 负载情况:接收并监测Cache服务器上报的设备状态负载信息,如CPU利用率、内存利用率、存储资源、EBI、EBO、CC或其它预先协商的监控数据项;此时Cache服务器组中需要部署SNMP Agent服务或其它资源插件来支持数据获取。
当判定缓存服务器不可用时,负载均衡设备需将该服务器从WebCache服务队列中取出,不参加下一次的分发,直到该设备恢复正常。
2. 负载均衡功能
支持将用户请求和Internet网络流量按照配置的负载分担算法分发到不同的Cache服务器进行处理。当用户请求到达缓存子系统时,负载均衡功能根椐配置策略,选择特定的缓存服务器,由该台Cache服务器响应用户的请求、提供缓存服务,例如选择性能最佳的缓存服务器,存储该份内容的缓存服务器等。
支持会话保持功能,对于同一用户、同一会话的多个访问请求,可分配至同一台缓存服务器中,避免出现会话失效的问题。
支持基于L4和L7的流量分发机制。负载均衡模块必须支持配置多个VIP地址。
支持对IPv6协议报文的负载均衡功能,能够对IPv6报文实现接收、解析和分发处理。
支持根据使用的分发机制来决定选择监控的数据项,监控数据项的采集周期可灵活配置。支持的流量分发机制如表所示。
序号
均衡算法
详细描述
是否必须
1
轮询
(RoundRobin)
负载均衡设备将所有用户请求按照Cache资源池的队列顺序,分发给资源池内每台Cache服务器进行处理,依次循环。
必选
2
L4负载分担
按照用户请求的4层信息,如IP地址、端口等对数据流进行分配。
必选
3
L7负载分担
按照用户请求的7层信息对数据流进行分配,例如根据目的URL映射至特定的Cache服务器中。
必选
4
动态性能分配
(DynamicRatio)
根据收集到应用程序和Cache服务器的各项性能参数如CPU、内存和磁盘的占用情况,动态调整流量分配。动态性能分配可经过标准SNMP或Cache服务器端的插件实现。
可选
5
最快模式
(Fastest)
将新的用户请求分发给响应最快的Cache服务器。
可选
6
最少连接方式
(LeastConnection)
将新的用户请求分发给最少连接的Cache服务器。
可选
7
优先权
(Priority)
负载均衡设备将所有Cache服务器进行分组,为每个组定义优先权,将用户请求分配给优先级最高的Cache服务器组(在同一组内,采用轮询或比率算法,分配用户请求)。
当最高优先级中所有Cache服务器出现故障,才将请求送给次优先级的Cache服务器组。为用户提供Cache服务器组的热备份功能。
可选
其中L7负载分担功能中要求至少支持如下两类方式:
l Hash:负载均衡设备同一文件的Hash结果,把相同的HASH文件用户请求分发到每台Cache服务器;
l 一致性Hash:对请求内容和缓存服务器使用相同的Hash函数,并将资源和地址节点在统一地址空间进行编址,从数据映射到的位置开始顺时针查找,将请求转发至找到的第一个服务器;
3. 主备冗余功能
负载均衡模块应具备多台设备的冗余能力,不同设备之间应当具有心跳监控及切换能力,监控对端负载均衡设备的状态。主用负载均衡设备将心跳信号定时发送到备用负载均衡设备,备用设备在一定周期内没有收到主用设备的心跳信号,支持主动将自己切换为主用设备。
2.2.2.2 负载均衡模块
缓存服务服务模块是整个WebCache系统的核心组件。
1. 网页对象缓存功能
支持对于互联网站点页面的解析,能够将网页中的静态Web对象存储于本地的缓存服务器中。在接收到用户发送的Web访问请求时,分析请求是否在本地命中,对于命中请求直接响应,就近为用户提供服务;对未命中的请求,系统能够从互联网源站下载内容,并就近返回给用户终端。
缓存的网页对象类型包括但不限于:
l 文本:HTML、XML、XHTML、JS、CSS、DOC、PDF、TXT等;
l 图像:JPG、PNG、GIF等;
l 视频:FLV、MP4、MOV、WMV、RMVB、F4V等;
l 音频:MP3、WAV等;
l 其它:ZIP、RAR等;
支持HTTP/1.0、HTTP/1.1协议定义的缓存字段:
l 支持根据Expires头域对页面对象的可缓存性进行判断,在Expire Date到达之前不再向源站发送HTTP请求获取该文件;
l 支持根据Cache-Control头域对页面对象的可缓存性进行判断,对于设置为public的内容进行缓存,对于设置为private、no-cache、no-store等的对象,默认不进行缓存,支持根据max-age参数所指定的相对时间间隔进行数据缓存;
对于源网站中在HTTP头域中指明不应被缓存的内容,要求缓存服务模块工作于代理模式,所有数据不在本地缓存。
对于互联网中的动态内容,要求系统能够予以识别,不在本地缓存,对于所有用户的请求,均以代理方式向源网站下载数据并传送给用户。
支持针对特定网站或域名实现静态对象的缓存周期配置,用户能够经过修改配置来设定本地缓存时间和缓存对象的类型。在本地设置与源站设置冲突时,优先以本地设定为准。
2. 大文件/视频缓存功能
支持基于HTTP协议传输的大文件缓存加速功能,如游戏、软件、升级包下载服务等。缓存服务模块接收用户的文件下载请求,分析该内容是否已经被WebCache系统在本地缓存,对于已缓存的内容,将经过重定向引导用户从缓存服务器下载数据。
工作于代理模式时,对于被引导至缓存服务器,但本地未命中的请求,要求系统能够以代理方式向内容源站下载后,将对应的数据发送至用户终端。
支持HTTP视频内容的缓存和下载,主要针对基于HTTP方式的各类在线视频媒体对象,包括FLV、MP4、MOV、WMV、RMVB、F4V等多种文件格式,设备应该支持对流媒体对象的缓存配置。
支持基于HTTP Live Streaming(HLS)协议的互联网视频内容的缓存和加速。
支持面向手机终端的各类应用软件(APP)内容的下载与加速功能。
3. 代理下载功能
在用户请求被引导到缓存子系统后,缓存子系统首先检查用户请求的文件是否在本地命中,如果命中则直接为用户提供服务;如果未命中,缓存子系统将作为代理转发用户的请求至互联网源网站,并将源网站返回的数据转发给用户。如果源网站返回的是有效数据且可缓存,缓存服务器根据热度规则,在本地同时存储热点内容的文件副本。
对于大文件和视频播放等应用场景,需能够支持边下载边服务功能,避免将用户请求长时间置于等待状态。
代理下载功能必须根据实际的网站列表选择开启,对于可能存在认证失败、cookie校验等问题的网站,要求不开启。
4. URL防盗链功能
针对主流的文件下载、视频播放、网络存储类网站的URL文件防盗链功能,支持对加密后的URL进行反向处理,获取真实的文件对象URL。
支持网站URL规则库,能够识别并兼容国内绝大多数视频及下载网站。可根据互联网站的功能及版本升级,支持经过加载新的规则库插件即可实现对新规则的反向处理,支持自动远程升级。
支持校验排错功能,能够对已缓存的下载类资源对象进行验证,例如经过对进行文件HASH运算,读取资源部分头信息或散列信息等方式,以防止内容资源定位错误,影响用户的正常访问。
5. 持久连接功能
支持基于HTTP/1.1的持久连接(Persistent Connection),能够针对同一对象的多个用户请求只建立一条连接。当多个用户请求相同的网页对象时,缓存服务器仅与源网站服务器建立一条连接,以便避免为每次单独的请求/应答建立新的连接。得到响应报文后,WebCache系统将响应内容的副本保存在本地,同时复制报文分发给发起请求各个用户。经过使用同一HTTP连接的方式以解决频繁建立连接带来的时间消耗,缩短响应时间提升用户体验,有效减少终端与服务器建立的连接数。
6. 内容复制功能
对于用户从Cache系统下载的TOP N热点资源,缓存服务器支持自动检测(如可按照命中次数排序),能够根据热度在本地不同缓存服务器之间进行复制,使得热点内容能够由多个缓存服务器并行提供加速服务,支撑高性能并发。
复制时间周期、复制的热点资源数量应支持灵活配置,默认时间周期为一天。
7. 数据复用功能
针对不同URL但文件内容相同的互联网文件,Cache服务器能够经过文件比对或依据站点的防盗链处理规则处理后实施甄别比对,识别出相同的文件对象,实现缓存数据复用,仅缓存初始URL所对应的数据,对于向其它URL发起的文件请求也能够保持命中。经过重用初始缓存文件的数据,能够提升访问命中率,节省系统回源流量,也避免针对同一对象重复下载,减少对于本地存储空间的占用。
对于不同URL、但内容一致的文件内容,必须支持经过URL规则、文件名称、大小进行关联,如:
l URL1:
l URL2:
l URL3:
系统也可支持经过对文件内容计算Hash值的方式进行有效关联。经过该算法生成与文件内容相对应的摘要数值,经过该摘要信息能够唯一标识某一文件。
8. 内容热度更新功能
内容热度更新是指在缓存服务器的存储空间占用达到一定程度时,必须删除掉一些不常见的缓存数据。对于每个对象,缓存服务器根据其访问频率计算相应的热度值,访问频率越高则其热度值也越高,热度值较低的缓存对象将会被优先删除。对于相同热度值的对象,能够比较对象的超时周期,优先删除超时周期指标较低的数据对象。
内容热度更新算法的核心是输入参数及权值函数,缓存对象在某时间点的热度值可根据如下输入参数计算:
l 上次数据热度值计算时间
l 特定时间段内数据访问次数
l 数据对象上一次的热度值
l 文件大小
缓存对象的老化时间的设定需要参考网页HTTP 头域中的超期参数,当超期时间到达时内容也会被自动删除。当源网站没有指定超期参数或错误参数时,能够根据WebCache系统配置进行更新,支持对不同域名、不同类型的对象独立设定老化时间。
9. 内容预取功能
支持自动预取互联网内容的功能,对于热点内容,支持根据源网站在HTTP头域中确定内容的超期时间,或者WebCache系统本地强制配置的更新周期,可实现在用户发起请求之前提前将网页内容或文件更新为最近的版本。预取数据后WebCache系统将重新刷新对象的超期时间。
内容预取功能能够有效降低用户请求到达后,缓存服务器进行校验和回源下载的时间,提升用户的访问体验。
内容预取功能默认不开启,可根据需求对特定网站开启,预取周期可按照网站域名为维度进行灵活配置。
10. 超期校验功能
支持HTTP/1.1协议的If-Modified机制。在Cache系统缓存内容已经过期时,缓存服务器支持向源网站发送If-Modified-Since 头信息,包含上一次从服务器获取数据的产生时间。如果文件从上次获取后没有更新,源站服务器将返回 HTTP 状态代码 304 Not Modified,表示从上一次请求后这个数据没有改变,此时缓存服务器能够直接使用原有缓存数据,无需再次下载。
支持HTTP/1.1协议的Etag校验机制。对于源服务器生成的唯一标志符Etag的文件,缓存服务器能够进行校验,由缓存