1.1 CDN（网站加速）
1.1.1 什么是CDN
CDN的全称Content Delivery Network，即内容分发网络。其基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快，更稳定。通过在网络各处放置节点服务器所构成的在现有的互联网基础之上的一层智能虚拟网络，CDN系统能够实时地根据网络流量和各节点的连接，负债情况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。其目的是使用户可就近取得所需内容，解决Internet网络拥挤的状况，提高用户访问网站的响应速度。
产生背景：
BGP机房虽然可以提升用户体验但是价格昂贵，那么CDN的诞生可以提供比BGP机房对于用户更好的体验（让地区的同一线路访问当地的同一线路的网站），BGP机房和普通机房价格将近5-10倍的价格差。CDN使用单线的机房，根据用户的线路以及位置为用户选择靠近用户的位置以及相同的运营商线路，即提升了用户体验价格又降下来了。
CDN的价值：为客户省钱，同时提升用户体验。
1.1.2 CDN的特点
（1）本地Cache加速提高了企业站点（尤其含有大量图片和静态页面站点）的访问速度，并大大提高以上性质站点的稳定性（省钱，用户体验提升）。
（2）镜像服务消除了不同运营商之间互联的瓶颈造成的影响，实现了跨运营商的网络加速，保证不同网络中的用户都能得到良好的访问质量。
（3）远程加速远程访问用过户根据DNS负载均衡技术智能自动选择Cache服务器，选择最快的Cache服务器，加快远程访问的速度。
（4）带宽优化自动生成服务器的远程Mirror（镜像）cache服务器，远程用户访问时从cache服务器上读取数据，减少远程访问的带宽，分担网络流量，减轻原站点WEB服务器负载等功能。
[root@web01 ~]# curl -I www.163.com
HTTP/1.1 200 OK
Expires: Wed, 02 Aug 2017 01:07:33 GMT
Date: Wed, 02 Aug 2017 01:06:13 GMT
Server: nginx
Content-Type: text/html; charset=GBK
Transfer-Encoding: chunked
Vary: Accept-Encoding,User-Agent,Accept
Cache-Control: max-age=80
Age: 43
X-Via: 1.1 fzhwtxz28:9 (Cdn Cache Server V2.0), 1.1 wangtong40:9 (Cdn Cache Server V2.0)
Connection: keep-alive(5)集群抗攻击广泛分布的CDN节点加上节点之间的智能冗余机制，可以有效地预防黑客入侵以及降低各种DDOS攻击对网站的影响，同时保证较好的服务质量。
1.1.3 使用CDN的基本要求
要加速的业务应该存在独立的域名，例如：www.yunjisuan.com，业务内容图片，附件JS，CSS等静态元素。
正常的DNS解析范例：
我们DNS服务器上的加速前的A记录。
A records
www.yunjisuan.com IN A 124.106.0.21(服务器IP)
删除上面的记录：
www.yunjisuan.com IN A 124.106.0.21(服务器IP)
然后，做下面的别名解析：
CNAME records
www.yunjisuan.com IN CNAME bbs
1.1.4 CDN服务提供商架构的关键元素
- DNS和智能DNS集群
- Cache集群
- 用户源站（cdn服务的客户）
- 外围（计费，日志分析，存储，protal展示）
1.1.5 智能DNS
1.1.6 CDN的原理
1.1.7 CDN的用途
企业或门户网站的图片，视频，css，js，html等静态数据的缓存
大网站会把全站首页静态化放CDN，推广页面。
支持动态加速
1.1.8 CDN架构图
1.1.9 CDN计费
CDN用多少交多少钱，这和IDC机房先购买固定带宽是有区别的。
计费方式说明：当前的计费方式为95%值计费方式，即取查询时间段中，所有带宽数据点，按带宽大小从低到高排序后，取第95%个点所对应的值作为计费带宽。如一段时间内有N（N=100）个带宽数据点，将这些点从低到高排序，第N*95%（100*95%=95）个点对应的带宽大小为该计费带宽的值。
CDN案例：有的时候我们源站负载很高（Web服务以及存储）
排查：
1）分析Web日志。IP来源谁
2）有可能CDN频繁来抓数据（a，源站更新频繁，b，CDN的缓存经常倒腾数据，c，命中率要高于98%）。CDN遇到404 403错误，是不缓存的，会向后请求源站
3）CDN公司增加缓存节点（一增加就是几百台级别）。抓源站，告诉CDN抓自己的服务器，不要老抓源站。
1.1.10 CDN后台
CDN删除违规图片流程：
1，CDN通知源站删除图片
2，源站运维从CDN提供的后台管理页面提交删除后的图片的位置的URL进行更新。
源站更新了图片，那么CDN怎么更新？
1）源站更新，CDN不知道也不专注，
外部用户触发：用户会请求元素，这个元素CDN第一次没有，CDN会去源站请求。
内部编辑触发：源站更新时，通过CDN接口推送到CDN
1.1.11 CDN价格
30-100/M/月
1.1.12 如何选择CDN公司
网宿，chinacache（蓝讯），快网，帝联
1.1.13 跨机房分布式部署技术
1.1.14 其他问题
（1）CDN节点宕机，企业网站人员如何知道？
不能可自主知道，只能通过：
1，CDN节点宕机地区的用过户反馈（其他地区都是好的，就这里有问题）
2，基调网络，博瑞，分布式测试
附录1：CDN流量暴高如何分析与解决企业案例
1.1：列举案例：
（1）实际案例一：
凌晨三点某公司（网站业务）的一个IDC机房带宽流量突然从平时高峰期150M猛增至1000M，如下图：
该故障的影响：直接导致数百台服务器无法连接，该机房全部业务中断。
（2）实际案例二：
某年某月某日夜接到学生紧急求助，公司网站（Web游戏业务）平时几十M带宽，结果突然跑满100M，持续100M已经很久。事后，该学生的总结开头如下：
凌晨一点接到报警短信，网站无法访问。立马拿起笔记本上网查看，发现整个机柜的网络都无法正常访问。第一感觉是不是IDC网络出问题了，给机房打电话反馈回来的信息是机房网络正常，但是带宽流量异常（100M带宽的流量峰值已跑满）该故障的影响：直接导致数十台服务器无法连接，该机房全部业务中断，且故障持续时间长。
（3）实际案例三：
某月某日，接到运维朋友紧急求助，其公司的CDN源站，源站的流量没有变动，CDN那边的流量无故超了好几个G，不知道怎么处理？
该故障的影响：由于是购买的CDN，虽然流量多了几个G，但是业务未受影响，但是，这么大的异常流量，持续下去可直接导致公司无故损失数万元。解决这个问题体现运维的价值。
1.2 分析问题：
1）IDC带宽被占满的原因很多，常见的有：
a，真实遭受DDOS攻击（遇到过几次，造成影响的不多见，其中还有黑客勒索的案例）
b，内部服务器中毒，大量外发流量
c，网站元素（如图片）被盗链，在门户页面被推广导致大量流量产生
d，合作公司来抓数据，如：对合作单位提供了API数据接口
e，购买了CDN业务，CDN猛抓源站
2）CDN带宽异常，源站没异常
这类问题基本都是缓存在CDN的数据被频繁访问引起的。解决方法见结尾案例。
3）CDN带宽异常，源站也异常。
可能原因如公司做推广，大量数据访问，热点数据cache里不全。或CDN问题导致数据回源。影响就是带宽高，后端静态服务器及图片及存储压力大。
1.3 解决问题：
分析了问题的可能原因，就好比较排查了。
1）真实遭受DDOS攻击
如何防护DDOS攻击?
- 了解DDOS的几种攻击类型，攻击原理，攻击特征，抓包和分析日志那是必须的，只有知道这些信息，才能制定应对措施。
- 了解自己公司带宽，服务器，防火墙，架构的承受能力，再就是制定相应的应急预案，有什么情况下起用什么样的应对策略，让处理问题有序进行，以保证业务正常对外提供服务为原则。
- IDC机房的选用：这一点确实很关键，要寻找一些有实力，能提供更高级别防护，当面对攻击时能快速响应并配合做各种防护策略的IDC厂商合作，当然这种机房的价格也就相对会高些，这个根据实际情况来考虑，成本和安全找到一个平衡点，不要为公司省钱，当出现问题时，公司可能就不会考虑你为公司省了多少，而是损失多少。
- 架构设计：对于整体架构的设计要基于核心单点无单点（如果要求更高些，可以整体无单点），多缓存的原则，保证高可用，跨ISP，跨机房多点分布式部署，不能在一棵树上吊死，大量的DDOS攻击导致整个机房跨掉的我是碰到过几次。
- 系统优化：操作系统内核优化，程序层的代码优化，数据库层的结构优化，存储层的性能优化，业务层的业务逻辑优化，整体构架的节点优化...，另外，不要动不动就配置65535，很多运维人员总觉得配置的最大连接数越大越好，其实不然，这个要根据实际情况来设置，如果把连接数设的太大，一旦攻击来了，还没等你去分析问题，服务器就已经挂了。
- CDN：借助CDN来分担压力
- 硬件防护：对于软件防护，我想一般在对操作系统内核做优化的时候这些都已经考虑进去了，对于硬件防护我们可以使用傲盾，黑洞等专业的防DDOS防火墙组建集群。
- 数据包及日志分析：对于那种四两拨千斤（SYN flood，CC）或者疑似DDOS的攻击，可以通过分析数据包，日志来按制定防护策略，如果说要报警，这些也可以为警方提供线索。
- 疑似DDOS攻击：如果文件被盗链，服务器中毒，前端缓存服务器设置不合理，程序BUG，交换机（路由器）故障等要通过抓包分析，日志分析来定位问题。
- 第三方求助：对于大量的攻击可以请求上层的IDC或者ISP协助处理，对于一些无法准确判断的攻击方式可以请求行业内相熟的高手来协助处理，懂得求助往往事半功倍，还能快速的处理问题。
2）内部服务器中毒，大量外发流量。
-这个问题的解决比较简单，可能有的同学说，看看服务器流量，哪个机器带宽高处理下就好了。其实不然，实际解决比这复杂得多，带宽打满，所有监控都是看不到的。
- 比较好的思路，是联系机房确定机房自身无问题后（机房一般没法帮我们的），请机房断开连接外部IP服务器的网线，如负载均衡器，仅保留VPN SERVER，然后断掉内部服务器出网关的线路，切断外发流量源头。
- 接下来查看监控流量服务，判断外发流量的服务器，然后进行处理。
- 其实，这个问题的发生及快速定位和很多公司的运维规范，制度关系很大，在给一些公司做运维培训分享时发现这个问题很严重（表象很好，内部运维规范，制度欠缺很多），大家都讨论的很深入，实际用的还是和聊的有差距。
- 比如有的公司开发直接FTP连接随时发布代码，或者由开发人员负责定时多次上线。而运维人员又不知晓，结果导致问题发生定位时间长。
- 建议的运维思路是：如果把网站机房比喻为一座房子，那首先要堵住后门（内部），其次是监控好前门（做好安全，留个小窗户给外面人看，即80端口服务，同时安排站岗值班的）
- 网站的无休止的随时随意发布代码，对网站的稳定影响是至关重要的。对运维人员对故障的定位快慢也很关键。根据不完全的调查统计，约50%以上的重要运维故障都是程序代码导致的，这也是在企业做培训分享时，灌输建议CTO的，多把网站稳定的责任分给开发，而不是运维。如果这个思路不扭转，网站不稳定状况就难以改变。
3）网站元素（如图片）被盗链
这个属于网站的基本优化了，apache，lighttpd，nginx都有防盗链的方案，必须要搞。说到这也提个案例，有个学生，到了企业工作，发现人家网站没有防盗链，结果上来没有通知老大，就直接做防盗链了，然后美美的当时还给我留言，说给公司搞防盗链了，很有成就，结果导致公司对外合作的业务，都是小叉子了，幸亏发现的及时没有出大问题。
（4）合作公司来抓数据，如：对合作单位提供了API数据接口或购买了CDN业务。
- 最常见的就是购买CDN服务，如：CDN新建一个节点（可能数十机器），直接来我们IDC源站来抓数据（有的做的好点的夜里来抓）。把源站抓的流量暴涨，严重的导致服务宕机。几家CDN公司，都有过这样的问题。
- 当然和电信，联通，GOOGLE，BAIDU，词霸等公司合作，也会有流量爆高的情况，这里面包括了为合作的站搜索引擎爬虫爬数据的问题。有时虽然带宽流量不高，但是服务器或数据库撑不住了，搜索引擎专门喜欢爬站内搜索，DISCUZ，CMS等早期的开源程序的搜索都是全站like%%方式去数据库搜索的，几个爬虫过来，直接就挂掉了。
1.4 实战解决案例
下面的例子适合于网站流量很高，但是，还没达到全网瘫痪的严重地步时的解决方案，适合我们自己的IDC机房及CDN业务（如果是CDN，那么，分析处理可以交给CDN，自己下载CDN日志分析也可）。
**范例：分析图片服务日志，把日志（每个图片访问次数*图片大小的总和）排行，取top10，也就是计算每个url的总访问大小**
在生产环境里的应用：这个功能可以用于IDC及CDN网站流量带宽很高，然后通过分析服务器日志哪些元素占用流量过大，进而进行优化裁剪该图片，压缩js等措施。
本题需要输出三个指标： 【访问次数】 【访问次数*单个文件大小】 【文件名（可以带URL）】
解答：
测试数据
59.33.26.105 - - [08/Dec/2010:15:43:56 +0800] "GET /static/images/photos/2.jpg HTTP/1.1" 200 11299 "http://oldboy.blog.51cto.com/static/web/column/17/index.shtml?courseId=43" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"
59.33.26.105 - - [08/Dec/2010:15:43:56 +0800] "GET /static/images/photos/2.jpg HTTP/1.1" 200 11299 "http://oldboy.blog.51cto.com/static/web/column/17/index.shtml?courseId=43" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"
59.33.26.105 - - [08/Dec/2010:15:44:02 +0800] "GET /static/flex/vedioLoading.swf HTTP/1.1" 200 3583 "http://oldboy.blog.51cto.com/static/flex/AdobeVideoPlayer.swf?width=590&height=328&url=/[[DYNAMIC]]/2" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"
124.115.4.18 - - [08/Dec/2010:15:44:15 +0800] "GET /?= HTTP/1.1" 200 46232 "-" "-"
124.115.4.18 - - [08/Dec/2010:15:44:25 +0800] "GET /static/js/web_js.js HTTP/1.1" 200 4460 "-" "-"
124.115.4.18 - - [08/Dec/2010:15:44:25 +0800] "GET /static/js/jquery.lazyload.js HTTP/1.1" 200 1627 "-" "-"