cdn方案建议书.doc

cdn方案建议书 cdn方案建议书篇一：网站通用CDN改造建议书 网站通用 CDN改造建议书 2010年6月 北京蓝汛通信技术有限责任公司 目录 1. 面向CACHE改造网站的通用建议. 1 1.1 CACHE设备的一般工作原理 . 1 1.2 控制设备的缓存动作 . 2 1.2.1使用HTML Meta Tags和 HTTP Headers. 2 1.2.2不起作用的Pragma HTTP Headers . 2 1.2.3使用Expires HTTP Header控制内容更新 . 3 1.2.4Cache-Control HTTP headers . 3 1.2.5认证条件和认证 . 4 1.3 建造CACHE易于识别的WEB站点. 5 1.4 写CACHE易于识别的脚本. 6 2. 其它CDN加速相关问题 . 7 2.1 图片加速优先 . 7 2.2 分离不同性质的域名 . 7 2.3 用户登录后个性化信息的改造 . 8 2.4 加速后如何获取页面访问量统计结果 . 8 2.5 内容刷新 . 8 2.6 内容分页、URL不变的情况 . 8 2.7 将访问频率高的从数据库获取的内容发布为静态页面 . 9 2.8 评论和原ASP文件分开显示 . 9 2.9 避免使用重新定向 . 9 2.10 URL参数部分避免使用中文字符和IP，URL不可过长 . 9 2.11 对于受口令保护的页面，CACHE设备如何处理 . 10 2.12 我将我的页面标记成了可缓存，可是我的浏览器的每次请求都穿过了CACHE设备，如何能强制CACHE保存内容副本？ . 10 1. 面向Cache改造网站的通用建议 1.1 Cache设备的一般工作原理 所有的Cache设备都有一套规则来确定何时向用户提供Cache中已有的可用内容。有些规则通过http 1.01.1 规范设置，有些规则可以由管理员在Cache设备上设置。 一般而言，下面是一些应普遍遵循的规则： 1、 2、 如果响应Headers标明对象不可Cache，设备就不Cache； 如果响应Headers中没有过期验证的Header（如Etag或 Last-Modified），Cache设备将认为此对象为不可Cache。 3、 4、 如果请求要经过用户认证或是保密内容，响应内容将不被Cache 被cache的内容如果符合一下条件之一，将被认为不过时，不需 向源站检查，就可提供给请求客户： ? 被Cache内容具有过期时间或其它控制有效期Header设 置，且按此设置内容尚不过期； ? 浏览器在设置成一次会话检查一次的情况下，在缓存中发现 此副本。 ? 代理服务器中发现此副本，该副本已经有相当长的时间没有 被修改过了。 5、 如果副本过期，Cache设备会向源站确认内容是否可用，如果源 站告诉Cache设备内容不可用，Cache设备从源站获取最新内容， 否则将Cache设备内容提供给用户，同时延长Cache中副本的过 期时间。 总之，通过副本“Freshness”确认，在该内容未改变的情况下，避免 服务器再次发送全部内容，确保了访问客户能从Cache设备上立刻获得所需内容。 1.2 控制设备的缓存动作 1.2.1使用HTML Meta Tags和 HTTP Headers HTML作者可以在文档中放入meta tags标明文档不可缓存， 或在指定时间后过期。Meta tags容易使用但效率不高，因为它控制浏览器的缓存动作，而不能控制专用Cache设备的缓存动作。 HTTP headers却可以让你同时控制浏览器和专用Cache设备的缓 存动作，他们通常由Web服务器自动生成，不能在HTML页面中看到。根据使用服务器的不同，你可以在不同程度上控制Headers。HTTP headers在HTML页面之前发送，只能被浏览器和中间层Cache设备看 到。典型的HTTP 1.1 响应头可能像这个样子： HTTP/1.1 200 OK Date: Fri, 30 Oct 1998 13:19:41 GMT Server: Apache/1.3.3 (Unix) Cache-Control: max-age=3600, must-revalidate Expires: Fri, 30 Oct 1998 14:19:41 GMT Last-Modified: Mon, 29 Jun 1998 02:28:12 GMT ETag: 3e86-410-3596fbbc Content-Length: 1040 Content-Type: text/html 1.2.2不起作用的Pragma HTTP Headers 许多人认为指定一个pragma值为“no cache”可以使内容不被 cache，这种说法并不正确，HTTP规范没有对Pragma 响应header做 出任何规定。相反只讨论了pragma请求header。虽然可能有少数Cache 设备支持这个响应header，但大部分不支持，所以设置它不起作用 在蓝汛公司使用的cache 设备中加入filter，可以对“pragma: no cache”页面强行cache。 1.2.3使用Expires HTTP Header控制内容更新 Expires HTTP header是一种控制Cache设备的基本方式，它告诉 设备某一副本在多长的时间内不过期，在此之后，设备将回源站检查页面是否被更新过。事实上，所有的Cache设备都支持Expires header。大多数Web服务器允许通过几种方式设置Expires 响应Header。服务 器通常允许你为页面设置一个绝对过期时间。 Expires header对控制静态图片的缓存动作尤其有效，因为他们不 经常变化，站点对用户响应速度肯定会比较快。它对控制有规律改变的页面也很有效，比如你每天早上6点更新页面，你就可以设定副本在早上6点过期，Cache设备就知道何时去源站获取新的内容，而不用用户作任何操作。 Expires header的唯一值就是一个HTTP 日期；任何其他值都会被 按过时理解，造成内容不可缓存。还要注意，HTTP date是GMT（Greenwich Mean Time）时间，而不是本地时间。格式：Expires: Fri, 30 Oct 1998 14:19:41 GMT 如果你使用Expires header，就必须确保服务器时钟准确。方法之 一是使用NTP（Network Time Protocol），找本地系统管理员确定可以 使用哪些NTP Server。 使用Expires header要注意确保Web服务器和Cache设备的时间 一致，否则就可能出现Cache设备把过时内容提供给用户的结果。 最后一点，记住在页面过期之前为页面指定新的过期时间，否则所 有的用户请求都要回源站验证，增加源站的负载和延迟。 1.2.4Cache-Control HTTP headers HTTP 1.0缺乏对cache设备缓存动作的控制方法，HTTP 1.1引入 了一种新的headers：Cache-Control response headers， web发行系统可以通过它解决页面过期问题，实现对页面内容的更多地控制 可用的Cache-Control response headers 包括：cdn方案建议书篇二：店铺装修优化建议 商家店铺装修优化建议 一、 背景 目前店中店商家店铺由商家自己装修。商家在装修店铺过程中造成了一些问题。其中最为严重的就是网页速度过慢。为了提升页面速度，提高客户体验和转化率。特制订该规范。 二、 问题概述 1，嵌套外部网站xml 外部网站xml数据传输比较慢.有的数据量比较大.并且很多是垃圾数据.并且在页面没有加载完情况.没有数据显示.造成了页面加载速度慢. 解决方法建议：不引用外部网站XML 2，嵌套外部网站swf 网站中swf格式文件加载速度比较慢.目前在很多网站已经禁止在页面使用swf格式文件，改为用js方式实现。目前店铺中还有很多这种情况。 解决方法建议：不嵌套外部网站swf，改用js方式实现 3使用很多大图片 网站图片过大.直接造成了页面加载速度慢.严重情况图片请求超时打不开. 解决方法建议：压缩图片大小，控制图片大小在100K以下 4外链了很多第三方网站js 外链js一方面加载速度慢.另一方面执行时候效率没有保证.严重情况会造成用户浏览器死机. 解决方法建议：不外链第三方js，可在自定义模块中添加js。 5外链了很多没有经过cdn优化处理的网站的图片 由于某些网站图片没有走cdn.只在一个指定区域或者网络运营商下打开速度可以.其它情况不支持. 解决方法建议：使用一号店图片空间或淘宝相册或有cdn加速的图片空间。 6. 自定义模块太多并且不规范造成页面渲染过慢 自定义模块过多,并且不规范造成了页面渲染速度过慢. 解决方法建议：减少自定义模块，模块建议不多于三个 三、 举例 商家：新农哥 原本店铺打开速度为6.8s，新农哥参照我们提出优化建议进行修改，现在店铺打开速度已经降到3.8s，提高了56%。 以下为新农哥店铺的优化点： 四、 规范店铺装修建议 1、通栏自定义模块.轮换广告模块980宽度的图片不超过3张,高度不超过200px 2、中栏或者两栏的右栏自定义模块轮换广告图片高度不超过300px 3、自定义模块采用div，css样式，去除table格式,并且整个店铺首页自定义模块不多于3个 4、 不引用外部xml格式数据 ，js文件以及swf文件 5、店铺内建议只使用1号店或淘宝或有cdn加速的图片空间,并且图片禁止超过100KB,最好控制在50KB以内cdn方案建议书篇三：IPS解决方案建议 采用入侵防御系统 网络安全解决方案 1. 需求分析 1.1 权威研究指出系统入侵/渗透是目前最大的安全威胁 VanDyke Software 组织的一次广泛而具有影响力的调查显示，66% 的公司认为系统渗透是政府、组织和企业所面临的最大威胁。 该项调查还显示，被调查企业所经历的最为严重的八种威胁分别是：病毒（占 78%）、系统渗透（占 50%）、DoS (占 40%)、内部人员错误操作（占 29%）、电子欺诈（占 28%）、数据或网络故障（占 20%）以及内部人员的非法访问（占 16%）。 图 1 权威调查揭示2/3的受访者认为系统渗透/入侵是面临的最大安全威胁 1.2 现有的安全架构无法应对系统入侵的新威胁 虽然在被调查的企业中，有 86% 已经部署了防火墙（老实说，相对于时代的发展和今天的大环境，这个数字低得让人无法接受），但很明显，防火墙面对很多入侵行为仍然无计可施。普通的防火墙设计旨在拒绝那些明显可疑的网络流量（例如，企业的安全策略完全禁止 Telnet 访(转 载于:wWw.xmsJOB.cOm 厦门培 训 考 试 网:cdn方案)问，但仍有某些用户试图通过 Telnet 访问某个设备），但仍允许某些流量通过（例如，发送到内部 Web 服务器的 Web 流量）。 图 2 现有的FW无法识别拦截应用层面攻击 问题在于，很多攻击都会尝试利用那些外围防火墙允许通过的协议的漏洞，而且，一旦 Web 服务器遭到攻击，攻击者会以此为跳板继续对其它内部服务器发起攻击。一旦服务器上被安装了“rootkit”或“后门”，那么黑客们就能够在未来的任何时间里“大摇大摆”地访问这台机器。 一般来说，我们仅将防火墙部署在网络外围。但很多攻击，无论是全球性攻击还是其它类型的攻击，往往都是从组织内部发起的。虚拟专用网、便携式计算机以及无线网络都能够接入到内部网络，而且经常会越过防火墙。入侵检测系统在检测可疑活动时可能很有效，但却不能提供对攻击的防护。臭名昭著的蠕虫（例如 Slammer 和 Blaster）都具有惊人的传播速度，当系统发出警报时，蠕虫实际上已经导致了损失，而且正在飞速地向外扩散。 图 3 攻击历史回顾提醒我们蠕虫的快速传播曾造成巨大损失 1.3 安全缺口在扩大 随之网络和应用的不断发展，安全的需求也在不断增长，而我们现有的安全能力却没有提高，造成安全缺口不断在扩大，如下图所示： 图 4 安全缺口在不断扩大 1.4 系统和网络安全面临的实际问题 依靠现有的FW、IDS等安全设备，我们已经不能及时掌握网络和系统的安全状况，也无法及时拦截攻击和进行补救。下面是一些亟待解决的问题： 1. FW、IDS已经不能保护应用安全，攻击能够穿透防火墙，比如SQL注入攻击，而我们不可能将SQL使用的TCP端口在防火墙上关闭，因为这样会将正常的SQL操作也阻断。这说明FW不能对数据流作深度分析，不能检测到应用层面的攻击，仅起到访问控制的作用，而IDS虽然能够监测到攻击，但是却不能够及时自动的拦截攻击，需要大量的人工干预，效率较低。 2. 网络中的设备和系统越来越多，同时，这些设备和系统使用的操作系统和应用软件存在的漏洞也不断被发现，应用层面的攻击正是利用了这些漏洞，比如，微软已经公布了很多Web 服务器软件 IIS和数据库软件