Web Cache系统集中采购工程技术规范书DOC 36页Word文档下载推荐.docx
《Web Cache系统集中采购工程技术规范书DOC 36页Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《Web Cache系统集中采购工程技术规范书DOC 36页Word文档下载推荐.docx（31页珍藏版）》请在冰豆网上搜索。
（5）卖方应列出其建议书中所提供设备和系统在世界范围内和国内的应用情况，诸如最大规模、业务类型及开展方式等。
（6）卖方提供的设备，硬件设备从系统最终验收开通之日起五年内，如果买方需要，卖方应以不高于本次价格提供备板、备件，卖方不得以设备停产等理由而拒绝提供。
如果由于买方系统改进或扩容，所需的软件设备卖方应以不高于本次价格提供。
（7）在合同签订之前，买方可以随时对本技术规范书进行修改。
（8）本技术规范书解释权归中国移动通信有限公司。
1.4规范书应答要求
（1）卖方对于技术规范书的疑问可以通过书面材料与买方联系。
在规定的建议书提交最后期限以前，买方将以书面材料给予答复。
有关买方答复材料的复印件也将递交所有得到技术规范书的卖方。
（2）在技术谈判的各个阶段，买方将以书面形式要求卖方对有关问题进行进一步的技术澄清，卖方应以书面资料给予正式应答；
所有各阶段的技术澄清文件都将作为合同附件。
（3）买方在任何时候保留和拥有对本文件的解释权。
买方有权在签定合同前，根据需要修改和补充本技术规范书，修改补充后的最终技术规范书将作为合同的附件。
（4）卖方的应答书中，要求对本文件的所提出的各项条款进行逐项答复、说明和解释，首先对实现或满足程度明确作出“满足”、“部分满足”、“不满足”等应答。
在答复中，凡采用“详见”、“参见”方式说明的，应指明参见文档的具体章节或页码。
请卖方特别注意：
凡采用“详见”、“参见”方式说明的条款，必须在点对点应答书中注有适当的总结性文字，简洁、明了地回答相应的条款。
对于本文件中要求列举的条款，必须在点对点应答书中进行列举，不得简单答复“满足”等，否则视该条款的应答为“不满足”。
如果回答“部分满足”，需要详细说明哪些部分满足，哪些部分不满足，并且详细说明原因。
卖方应答应与详细的说明内容一致，如果应答与说明内容矛盾则视为“不满足”。
1.5技术文件
卖方所提供的应答文本应按照以下内容格式进行编制：
附件一：
系统价格清单；
（1）总清单
（2）分项清单
（3）设备配置说明
附件二：
技术规范书及应答
（1）卖方点对点答复
附件三：
技术建议书
包括整个系统总体模块组成（包括网络、硬件、软件等）、各模块具体结构、配置依据、各种业务流程、系统与相关其它系统接口、系统管理、系统安全、统计等方面
附件四：
技术文件清单
应包含本次提供的技术文件的种类、数量及简要内容介绍
附件五：
软件功能清单
附件六：
工程实施计划
附件七：
设备情况、机架状况及场地环境要求
附件八：
合同双方的责任分工及界面（要求图示并加以说明）
附件九：
验收及测试
附件十：
工程协调会
附件十一：
售后服务
附件十二：
最终用户人员培训
附件十三：
相关备忘录及承诺
附件十四：
产品说明（包括相关资质及入网许可证）
1.6技术建议书应包括的内容
1.6.1系统概况
（1）WebCache系统的结构、系统组成情况以及典型的工作流程。
（2）WebCache系统与DPI、网管系统的连接方式。
（3）系统过负荷控制机制，即业务量达到或超过最大硬件处理能力的流控机制。
（4）系统的License控制机制，即在业务量超过License容量但未达到系统最大处理能力系统的处理流程。
1.6.2系统配置
（1）现网各省WebCache系统使用的服务器设备的型号配置。
（2）本工程计划使用的服务器设备的型号配置。
（3）主设备配置的核算方法。
1.6.3系统容量
（1）现网存在的各个版本以及各种硬件配置情况下单台设备的最大容量和处理能力。
系统容量的定义见第5节系统容量需求。
（2）本期工程配置设备在各个版本下单台设备最大的容量和处理能力，并说明设备容量或处理能力的测试条件、方法和计算方法。
（3）WebCache的容量需求的核算方法。
（4）WebCache系统的病毒防护以及防止恶意攻击等安全防护机制。
1.6.4版本情况
（1）现网主设备的版本情况以及分布的省份。
（2）WebCache系统的版本路标。
（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）要求卖方应用软件采用功能模块配置方法和/或许可证配置方法，其中功能模块的功能应与软件功能清单对应一致，许可证只能与系统处理能力（实际出口带宽）相关联，并且在WebCache平台系统实际运行中系统达到该许可证数量时不应限制业务处理（而只是向网管系统发出告警信息，并在系统日志中记录），不接受许可证与某种形式的系统静态容量（例如服务器数量、设备数量）相关联的配置方法。
1.7.3报价体系要求
请卖方按照以下各项要求分别报价：
（1）报价清单总表中应体现，硬件、软件、服务、培训部分的目录价，分类项目小计价格及总价。
（2）硬件清单分别提供服务器设备清单以及其他硬件部分的清单。
服务器设备清单包含PC服务器以及PC终端设备。
卖方购买服务器厂家提供商的服务应在服务器清单中作为单独条目列出。
（3）软件清单中卖方应将自产软件以及外购软件分别列出。
（4）设备应按类别分别提出详细的分项单价和总价，对能够独立工作或可以单独采购的设备和部件及软件模块均分别报价，即按不可拆分原则报价。
1.7.4设备清单要求
（1）设备硬件应细分到板件。
（2）第三方提供的设备应详细的列出厂家名称，产品型号、设备配置等内容。
（3）软件清单应将自产软件和外购软件分别列出。
2WebCache系统建设主要技术要求
WebCache系统是在中国移动现有的IP承载网络中部署的缓存设备，存储互联网热点或特定内容。
通过引导网内用户的访问请求转发到WebCache系统中，由WebCache系统直接将数据返回给用户，避免直接从互联网源站下载数据，从而降低客户访问互联网资源的时延，有效提升用户访问速度和质量，降低互联网出口拥塞的现状。
从技术上解决由于网络带宽小、用户访问量大、互联网资源分布不均等原因所造成的用户访问互联网资源响应速度慢的问题，提升用户的业务感知，同时降低因网间流量产生的网间结算费用。
WebCache系统支持对Web浏览、文件下载、视频播放等基于HTTP协议的互联网业务进行加速，系统对于本地存储的文件格式、音视频及文件编码方式均没有特定要求，各类互联网音频、视频、图像、文本等文件均可通过系统实现缓存和加速服务。
WebCache系统应支持移动蜂窝网（2G/3G/LTE）、WLAN、固定宽带等不同的网络接入方式，并能够同时为PC、手机、Pad等不同形态的终端提供服务。
2.1WebCache系统请求引导机制
2.1.1DNS重定向模式
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转发模式要求将省内的LocalDNS与WebCache系统相连接。
由管理员在LocalDNS上开启Forward功能，并在转发策略中将需要加速的域名列表（白名单）配置为ForwardFirst模式，目标为WebCache系统的调度服务器的IP地址。
ForwardFirst模式下DNS服务器会优先选择转发的目标DNS返回的解析结果，当Forward目标因故无法返回结果或返回结果延迟较大，LocalDNS本身则会继续递归解析以获取解析结果。
当用户终端发起的DNS解析请求发送至LocalDNS服务器后，DNS服务器将目标域名与本地配置的Forward名单进行匹配，如满足一致性条件，则将该条DNS解析请求前传至WebCache系统的请求调度功能模块。
WebCache系统的请求调度功能模块在接收到该条DNS解析请求后，应向LocalDNS返回对应的DNS解析响应消息，解析结果的目标地址为缓存子系统的IP地址。
2.1.2HTTP重定向模式
HTTP重定向模式包含非代理方式和代理方式两种处理机制：
●非代理处理机制：
仅当WebCache系统监测到用户发出的HTTP访问请求属于本地已缓存的资源，才由WebCache系统向用户返回HTTP302重定向报文，响应报文的目标地址为WebCache系统的IP地址，用户终端接收到该条HTTP302响应消息后，将向WebCache系统发起请求下载数据。
●代理处理机制：
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.2WebCache系统建设功能要求
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设备支持流量转发功能，具体要求如下：
●支持对于满足设定规则匹配条件的报文进行处理，将满足匹配条件的报文从指定接口转发到用户请求调度设备，例如DNS解析请求报文、HTTP访问请求报文等；
●支持灵活配置过滤转发规则，规则可以是指定协议类型、IP地址、端口号、流量方向、应用层特征等组合方式；
●支持无效流量的灵活过滤，支持灵活按照协议类型、应用层特征、源/目的IP地址、流量方向等作为过滤条件，能够镜像出高比例收敛的有效流量；
●支持配置多个出接口组，能够根据负载均衡策略实施转发；
3.流量统计功能
DPI设备提供支持的流量统计功能如下：
●支持多种流量统计，如对字节数、当前带宽、峰值流量、新增连接数、最大并发连接数、当前并发连接数等网络流量参数进行统计；
●支持输出外部网站及域名的请求次数、流量统计及排名次序等统计数据；
●支持通过手动或自动方式上报至其他外部系统，例如WebCache系统或全网管理控制中心；
2.2.1.2用户请求调度模块
用户请求调度设备的主要功能是根据缓存白名单配置或者本地已缓存内容，将用户的访问请求重定向至后端的缓存子系统。
1.DNS重定向功能
用户请求调度设备处理接收到用户终端发出的DNS解析请求报文，根据WebCache系统服务器状态和配置参数，生成相应的DNS响应消息。
用户请求调度设备必须支持对DNS请求的源IP地址进行判断：
●如果是WebCache系统发送的请求则不实施处理，该请求将被透传至外网上一级DNS服务器进行处理。
●对于源IP地址为用户侧的DNS请求报文，如果WebCache系统运行正常，则将WebCache系统的IP地址作为DNS解析响应结果发送给用户终端。
●支持对特定源IP地址的调度Bypass功能，对满足源地址匹配条件的DNS请求不进行重定向，不对这部分用户进行缓存加速。
源IP地址段必须可灵活配置。
2.HTTP重定向功能
用户请求调度设备处理接收到用户终端发出的HTTP请求报文，并根据WebCache系统服务器状态、本地缓存数据以及IP地址配置参数等，生成对应的HTTP302重定向消息，其中目标为缓存子系统的公网IP地址。
在缓存子系统中没有部署负载均衡设备的场景下，用户请求调度设备必须能够实时获取缓存子系统中已缓存的内容资源信息，对用户的HTTP请求进行综合判断，根据资源分布、设备负载以及内容策略等信息将用户的请求制定路由导向策略，将用户请求重定向至最合适的缓存服务器上。
如果用户请求调度设备监测到WebCache缓存子系统不可用，则不对用户的HTTP请求作出重定向操作。
支持对特定源IP地址的调度Bypass功能，对满足源IP地址匹配条件的HTTP请求不进行重定向，不对这部分用户进行缓存加速。
3.黑白名单功能
WebCache系统支持配置加速域名列表（白名单），仅对于白名单内的网站域名进行加速，对于其他请求不进行响应，也可返回DNS递归解析结果以保护用户DNS请求的成功性。
WebCache系统支持配置黑名单，包含非HTTP协议的域名和不适合进行缓存加速的域名，如邮箱域名、FTP域名、SSL域名等。
黑白名单域名信息配置必须支持如下2类方式：
●精确域名：
如
●泛域名：
如*,
可支持正则匹配域名配置方式：
如dl[1-9]\.qq\.com，ww*\
对于黑白名单中配置的域名，用户请求调度设备仅对在白名单内、且不在黑名单内的访问请求进行响应。
当系统配置的白名单与黑名单存在交叠时，必须优先使用匹配黑名单的策略生效。
支持黑白名单的管理功能，支持手工增删改查。
4.健康检查功能
用户请求调度设备支持通过多种方式监测缓存子系统的可用性及工作状态，能够根据缓存子系统的可用性及存储的文件内容进行调度。
可用性至少应包括如下方面：
●设备可达：
设备硬件层面是否可用，例如可发送ICMP报文实施探测；
●服务状态：
检查TCP/UDP端口是否提供服务；
●负载情况：
接收并监测Cache服务器上报的设备状态负载信息，如CPU、内存、硬盘空间使用率等预先协商的数据项（可选）；
用户请求调度设备的负载监测功能可通过SNMP协议实现，对WebCache服务器设备层面的监控项实施数据采集，此时缓存服务器中需要安装SNMPAgent服务。
用户请求调度设备根据设定的时间周期性探测对端设备的健康状态。
如果在采集周期内缓存子系统出现不可用的状态，用户请求调度设备将继续探测以确认设备不可用，最多进行3次累计探测或探测累计时间在超时范围内，则判定系统不可用。
请求调度模块能够根据缓存子系统的可用性进行调度，具体要求如下：
●缓存子系统单个文件损坏时，请求调度模块应自动停止对应损坏文件的重定向；
●缓存子系统数据硬盘出现故障时，请求调度模块应自动停止对应故障磁盘缓存文件的重定向；
●缓存子系统不可用时，请求调度模块应不对用户请求作出响应。
●缓存子系统负载过重时，请求调度模块应自动识别，并降低向缓存子系统的重定向用户请求；
用户请求调度设备可支持通过HTTP方式对其它WebCache节点的可用性进行周期性检查。
5.主备冗余功能
用户请求调度设备需具备冗余切换能力，两台设备之间使用网线传递心跳信号、主备切换触发信号，以监控对端设备的状态。
6.策略同步功能
支持与管理子系统交互，获取本地缓存内容情况、以及由全网管控中心、内容资源管理平台或者其他外部网元实体下发的各类资源信息、内容信息以及调度策略数据，并在本地配置生效。
2.2.2缓存子系统
2.2.2.1负载均衡模块
1.健康检查功能
负载均衡设备必须支持对Cache服务器资源的健康检查，常用的健康检查机制如下表所示。
系统的可用性至少应包括：
设备硬件层面是否可用，可基于发送ICMP报文实施探测；
接收并监测Cache服务器上报的设备状态负载信息，如CPU利用率、内存利用率、存储资源、EBI、EBO、CC或其它预先协商的监控数据项；
此时Cache服务器组中需要部署SNMPAgent服务或其它资源插件来支持数据获取。
当判定缓存服务器不可用时，负载均衡设备需将该服务器从WebCache服务队列中取出，不参加下一次的分发，直到该设备恢复正常。
2.负载均衡功能
支持将用户请求和Internet网络流量按照配置的负载分担算法分发到不同的Cache服务器进行处理。
当用户请求到达缓存子系统时，负载均衡功能根椐配置策略，选择特定的缓存服务器，由该台Cache服务器响应用户的请求、提供缓存服务，例如选择性能最佳的缓存服务器，存储该份内容的缓存服务
升级会员 