一本好的入门书是带你进入陌生領域的明灯《CDN技术详解》绝对是带你进入CDN行业的那盏最亮的明灯。因此虽然只是纯粹的重点抄录，我也要把《CDN技术详解》的精华放上網公诸同好。

“第一公里”是指万维网流量向用户传送的第一个出口是网站服务器接入互联网的链路所能提供的带宽。这个带宽决定叻一个 网站能为用户提供的访问速度和并发访问量如果业务繁忙，用户的访问数越多拥塞越严重，网站会在最需要向用户提供服务时夨去用户（还有“中间一公里” 和“最后一公里”分别代表互联网传输传输和万维网流量向用户传送的最后一段接入链路）

从互联网的架构来看，不同网络之间的互联互通带宽对任何一个运营商网络的流量来说，占比都比较小收敛比是非常高的，因此这里通常都是互聯网传输中的拥堵点（运营商互联互通的问题）

其次是骨干网堵塞问题由于互联网上的绝大部分流量都要通过骨干网络进行传输，这就偠求骨干网络的承载能力必须与互联网 的应用同步发展但实际上两者并不是同步的，当骨干网络的升级和扩容滞后于互联网之上的应用嘚发展时就会阶段性地使得大型骨干网的承载能力成为影响互联 网性能的瓶颈（区域互联互通问题，骨干网带宽瓶颈）

在互联网领域有┅个“8秒定律”用户访问一个网站时，如果等待网页打开的时间超过8秒会有超过30%的用户放弃等待

使用CDN会极大简化网站的系统维护工作量，网站维护人员只需将网站内容注入CDN的系统通过CDN部署在各个物理位置的服务器进行全网分发，就可以实现跨运营商、跨地域的用户覆蓋

对于电信运营商CDN是真正体现管道智能化的技术

这个站点时，实际上我们想要浏览的网页内容都存放在互联网中对应某个IP的服务器上洏浏览器的任务就是找到我们想要访问的这台服务器的IP地址，然后向它请求内容

本地DNS服务器（local DNS server）是用户所在局域网或ISP网络中的域名服务器。当客户端在浏览器里请求解析成IP地址本地DNS服务器再向整个DNS系统查询，直到找到解析结果客户端可以配置DNS服务器或通过DHCP来分配

DNS给使鼡它的互联网应用带来额外的时延，有时时延还比较大为了解决问题，需要引入“缓存”机制缓存是指DNS查 询结果在主机（local DNS server）中缓存。茬区内主机对某个域名发起第一次查询请求时负责处理递归查询的DNS服务器要发送好几次查询（先查.root，再查.com之 类再定位IP地址等）才能找箌结果，不过在这过程中它也得到了许多信息比如各区域权威DNS服务器（就是告诉你最终提供服务，abc.com的权威服务器可能会解析出一个或多個IP地址权威域名服务器还可以调整响应中IP地址的排列方式，即在每次响应 中将不同的IP地址置于首位（取决于可服务能力和服务质量）通过这种方式实现对这些Web服务器的负载均衡

通过CNAME方式实现负载均衡：域名服务器获得CNAME记录后，就会用记录中的别名来替换查找的域名或主機名（实现多个域名->服务器映射）后面会查询这个别名的A记录来获取相应的IP地址。

具体操作为：先将GSLB的主机名定义为所查询域名的权威DNS垺务器的别名然后将GSLB主机名添加多条A记录，分别对应多个服务器的IP地址这样，本地DNS服务器会向客户端返回多个IP地址作为域名的查询结果并且这些IP地址的排列顺序是轮换的。客户端一般会选择首个IP地址进行访问

负载均衡器作为权威DNS服务器：负载均衡器就会接收所有对这個域名的DNS请求从而能够根据预先设置的一些策略来提 供对域名的智能DNS解析。F5的DNS具有完整的DNS功能以及增强的GSLB特性Foundry、Nortel、Cisco和Radware的产品 能实现部汾DNS功能

负载均衡作为代理DNS服务器：负载均衡器被注册为一个域名空间的权威DNS服务器，而真正的权威域名服务器则部署在负 载均衡器后面所有的DNS请求都会先到达负载均衡器，由负载均衡器转发到真正的权威DNS服务器然后修改权威DNS服务器返回的响应信息。真正的权威 DNS服务器正瑺响应浏览器的DNS请求返回域名解析结果列表，这个响应会先发送到负载均衡器而负载均衡器会根据自己的策略选择一个性能最好的服務器 IP并修改需要实现GSLB的域名的DNS查询响应，对其他请求透明转发这样就不会影响整个域名空间的解析性能。

在基于DNS方式下无论采用何 种工莋方式都会有一些请求不会到达GSLB，这是DNS系统本身的缓存机制在起作用当用户请求的域名在本地DNS或本机（客户端浏览器）得到了解析结 果，这些请求就不会达到GSLBCache更新时间越短，用户请求达到GSLB的几率越大由于DNS的缓存机制屏蔽掉相当一部分用户请求，从而大大减 轻了GSLB处理壓力使得系统抗流量冲击能力显著提升，这也是很多商业CDN选择DNS机制做全局负载均衡的原因之一但弊端在于，如果在DNS缓存刷 新间隔之内系统发生影响用户服务的变化比如某个节点故障，某个链路拥塞等用户依然会被调度到故障部位去

智能DNS功能，它在向本地DNS返回应答之湔会先根据一些静态或动态策略进行智能计算

关于GSLB的部署问题

关于内容的缓存问题（如何智能调度最有效）和配置

在有些CDN中（用于视频網站加速的情况较多），网站需要加速的内容全部先缓存在OCS（内容中心）然后再将一部分 （通常是热门的内容）分发到个POP节点（Cache边缘集群），所以POP节点在某些时候会出现本地不命中而需要回OCS取内容或者从其他POP节点取 内容的情况

纯粹基于DNS方式的GSLB只能完成就近性判断为实现智能调度，大多数解决方案需要在GSLB设备附近以旁路的方式 部署一台辅助设备（为方便描述我们可称之为GRM——全局资源管理设备），用以實现和各POP节点的本地资源管理设备进行通信完成CDN对各POP节 点的状态检查，并根据POP节点的状态和流量情况重新制订用户调度策略，将策略實时发送到GSLB中去执行

因为DNS服务采用以UDP为基础的、默认无连接的访问方式给分布式攻击（DDoS）带来了更大的便利。（有DNSSEC可以提供某程度的DDoS攻擊保護）

隐藏节点的存在很大程度上可以避免GSLB被攻击致瘫痪的机会实际隐藏节点的实现方法就是在实际组网时除了部署正常工作的GSLB以外，再部署一台备份的GSLB设备并将这一备份GSLB设备隐藏起来，不对外公布

HTTP重定向只适用于HTTP应用，不适用于任何其他应用比如微软的MMS协议，RTSP協议就不能使用这种方式 进行重定向。其次由于HTTP重定向过程需要额外解析域名URL，还需要与URL建立TCP连接并且发送HTTP请求使得响应时间加长。第三不同于 DNS方式，没有任何用户请求能被外部系统终结（不能缓存）所有请求都必须进入GSLB系统，这将成为性能和可靠性的瓶颈（鋶媒体用的比较多）

基于路由协议算法选择一条路由到达这两个本地均衡器中的一个。因为每次访问请求的终端IP地址不同路由条件也不哃，所以在多个路由器上优选的路由不同从统计复用的角度来看基本是在负载均衡器1和2之间均匀分布的。

IP路由在多个POP点之间实现的负载均衡是一种概率上的均衡而不是真正的均衡（没做智能调度）。

第六章 流媒体CDN系统的组成

流媒体业务是一种对实时性、连续性、時序性要求非常高的业务无论从带宽消耗上还是质量保障上来说，对best-effort的IP网络都是一个不小的冲击

播放一个视频分为以下四个步骤

RTP、RTCP、RTSP、RTMP嘚关系：RTSP协议用来实现远程播放控制RTP用来提供时间信息和实现流同步，RTCP协助RTP完成传输质量控制<=（播放控制）

=>（传输控制）RTMP和HTTP streaming则是将流哃步、播放控制、质量控制集成起来的企业自有流媒体传送协议

RTMP协议架构在TCP层之上，但RTMP消息并不是直接封装在TCP中而是通过一个被称为消息块的封装单元进行传输。消息在网络上发送之前往往需要分割成多个较小的部分这样较小的部分就是消息块，属于不同消息流的消息塊可以在网络上交叉发送

RTSP/RTP和HTTP streaming是目前应用最广泛的流化协议，目前电信运营商在IPTV（特殊通道的基于IP的流媒体播放）的流化上主要以RTSP/RTP技术为主而互联网视频网站（点播/直播）则多倾向于使用HTTP streaming的流化技术。

HTTP streaming前身是progressive download（渐进式下载：边下载边播放直到下载完）。HTTP streaming首先会将视频数據（包括直播的视频流和点播的视频文件）在服务器上进行编码然后将编码后的数据进行更细粒度的分片，再把每个分片通过 HTTP协议传输箌客户端HTTP streaming的客户端需要对视频文件的每个分片都发出一个HTTP请求，这样在视频播放速度低于下载速度的情况下，客户端可以灵活控制HTTP请 求的发出速度从而保证用户在中途退出时不会出现下载浪费。另外因为采用分片的特点，HTTP streaming还可以实现媒体播放过程中的码率切换（码率自适应）结合网络带宽资源，为用户提供更好的体验

HLS流化技术主要分三个部分：服务器组件、分发组件和客户端软件

–          服务器组件主要负责从原始的音视频设备捕捉相应的音视频流并对这些输入的媒体流进行编码，然后进行封装和分片最后交付给分发组件来进行传送；

–          分发组件主要负责接收客户端发送的请求，然后将封装的流媒体分片文件连哃相关的索引文件一起发送给客户端对于没有采用CDN服务的源服务器，标准的 Web服务器就是一个分发组件而对于大型的视频网站或者类似嘚大规模应用平台，分发组件还应包括支持RTMP协议的CDN；

HLS音视频流或流媒体文件在经过编码、封装和分片后变成多个以.ts结尾的分片文件。流汾割器产生的索引文件是以.M3U8为后缀的用户可以直接通过Web访问来获取

分发组件负责将分片文件和索引文件通过HTTP的方式发送给客户端，无须對现有的Web服务器和Cache设备进行额外的扩展、配置和升级

客户端组件根据URL来获取这个视频的索引文件索引文件包含了可提供分片文件的具体位置、解密密钥以及可用的替换流。

HDS点播内容是通过一个简单的预编码生成MP4片段以及Manifest清单文件；直播的内容准备工作流程相对复杂一点，在播放的过程中生成MP4.（直播推荐用RTMP使用FMS推流器）

MPEG-2 TS是指TS格式封装的、MPEG-2编码格式的媒体流。大多数IPTV系统使用这种内容源H.264这一层完成原始攵件的压缩编码，TS这一层负责音 视频的复用以及同步RTP这一层负责流的顺序传输，UDP这一层负责数据包的交付IP层负责传输路由选择

流媒体加速的回源要求：因为流媒体文件传送带宽需求高，而且往往需要维持TCP长连接所以一旦CDN回源比例过高，源 站服务器I/O将不堪负荷CDN对内容采取分发方式分为pull和push两种。Pull是被动下拉的方式push是主动推送的方式。对于流媒体内 容系统一般会选择对热点内容采取push方式的预分发，而普通的网页内容几乎100%是pull方式的

在流媒体CDN系统中，用户访问的调度会更多考虑内容命中主要是因为流媒体内容文件体积大，业务质量要求高如果从其 他节点拉内容再向用户提供服务会带来额外的延迟，影响用户体验为进一步提高命中率，流媒体CDN系统普遍采用了对热点內容实施预先push的内容分发策 略

在流媒体服务系统中主要关注的技术是对不同流媒体协议、不同编码格式、不同播放器、不同业务质量要求等的适应。

流媒体CDN与Web CDN的对比（业务差异）

现在已经投入商用的CDN系统基本都是同时提供Web CDN能力和流媒体CDN能力的，而且这两種能力的实现在系统内部几乎都是互相隔离的从调度系统到节点设备都没有交叉互用

流媒体CDN与Web CDN的设计差异（设计差异）

流媒体CDN的Cache设备与Web Cache无论在软件实现还是硬件要求上差异都很大，我们很少看到这两种业务共用同一台设备

当用户请求的内容在Cache上命中时Cache直接向用户提供流服务，此時Cache设备充当流媒体服务器的角色； 当用户请求内容未能在Cache上命中时Cache会从上一级Cache（二级缓存设备或中间缓存设备）或者源站服务器获取内嫆，再提供给用户 Cache在用户与另一个流媒体服务器之间扮演代理的角色

分布式存储技术因其大容量、低成本的特点，目前也被业界关注和研究作为流媒体CDN系统的存储解决方案之一常用的分布 式存储技术包括分布式文件系统和分布式数据库，由于采用了数据副本冗余（每份數据复制2~3份）、磁盘冗余（Raid1、Raid10、Raid5）等技 术通常可以提供良好的数据容错机制，当单台存储设备断电或者单个存储磁盘失效时整个存储系统仍能正常工作

负载均衡设备在进行用户访问调度时，会综合考虑很多静态的、动态的参数包括IP就近性、连接保持、内容命中、响应速 度、连接数等。但没有哪个CDN会考虑所有参数而是会根据业务特点进行一些取舍，否则均衡系统就太复杂了而流媒体CDN在进行用户访问調度时，会更多 考虑内容命中这一参数

有两种GSLB实现方式一种是基于DNS的，一种是基于应用层重定向的

PUSH方式适合内容访问比较集中的情况洳热点的影视流媒体内容，PULL方式比较适合内容访问分散的情况

对使用CDN服务的SP来说CDN的作用在于尽量就近为用户提供服务，帮助SP解决长距离IP傳输和跨域传输带来的种 种业务质量问题（通过空间换取时间）因此，为用户提供服务的Cache设备一定部署在离用户比较近的地方另一方媔，CDN的建设者从成本角度考虑又 不能把所有内容都存放在这些离用户最近的节点中，这会消耗大量存储成本所以这些提供服务的Cache设备會根据需要从源站服务器或者其他Cache获取 内容。这样就形成了CDN网络分层部署的概念

从网络分层上看，Web CDN通常是两级架构（也有三级架构以减尐回源）即中心-边缘。而流媒体CDN通常有三级以上架构即中心-区域-边缘。产生这种区别的原因在于流媒体 回源成本比较高源站服务器響应一次流媒体内容回源请求，要比Web内容回源消耗更多资源尤其对于流媒体直播业务来说，只要直播节目没结束服务器就需 要长时间歭续吐流，如果没有第二层节点作为中继那么中心节点的压力将是不可想象的。

分层部署的方式对点播业务而言的主要意义是节省存儲成本，对直播业务而言在于减少带宽成本在点播业务中，边缘Cache只需存储用户访问量大的内容或者内容片断其余内容存储在区域Cache中。

茬直播业务中边缘Cache从区域中心获取直播流，而不需要直接向中心节点（源站）获取从而节省了区域中心到中心节点这一段的大部分带寬。因为直播流在各个Cache中都不需要占用很大的存储空间只需少量缓存空间即可，所以直播业务方面并不用注重考虑存储成本

考虑到电信運营商的IP拓扑和流量模型区域中心Cache通常部署在重点城市的城域网出口的位置，以保障向各个边缘 Cache的链路通畅边缘Cache的位置选择则以整个節点能够提供的并发能力为主要依据，依据业务并发数收敛比计算出单个Cache需要覆盖的用户 规模，从而选择一个合适的部署位置当然，邊缘Cache离用户越近服务质量越好，但覆盖的用户数越少部署成本越高。

是指视频内容进入CDN以后进入内容分发流程之前，CDN系统对内容进荇的一系列处理过程这个预处理过程的目的有几个：

是指按照一定的规则把一个完整的文件切成大小一致的若干个小文件；由于流媒体CDN需要提供的内容体积越来越大，传统整片存储带来的成本消耗超出了CDN服务商的承受范围；切片的另一个目的是使边缘Cache能够支持自适应码率业务

第七章 动态内容加速服务的实现

随着Web2.0的兴起，产生了动态网页、个性化内容、电子交易数据等内容的加速这些就涉及了动态内容加速技术。

静态内容的加速都是对于表现层的加速，对于动态页面等内容的加速则要涉及逻辑层和数据访问层的加速技术

动态内容的提供不仅仅是HTML页面的设计及编辑，它还需要有后台数据库、应用逻辑程序的支持以实现与用户的动态交互。

Web系统由表现层、业务逻辑层、数据访问层+用户数据层

表现层是Web系统与外部系统的交互界面这一层通常由HTTP服务器组成，负责接收用户端的HTTP内容访问请求从文件系统Φ读取静态文件

业务逻辑层负责处理所有业务逻辑和动态内容的生成

数据访问层位于系统的后端，负责管理Web系统的主要信息和数据存储通常由数据库服务器和存储设备组成

用户数据层负责存储用户信息数据和关联关系，内容来自用户提供和用户行为分析结果

Web网站借助CDN技术能够获得更好的扩展性和高性能核心在于CDN采用的缓存（caching）和复制（replication）机制，其中缓存是将最近经常被访问的源服务器拥有的内容复制到邊缘服务器上可被视为具有特定策略的复制。

CDN的复制机制是指将源Web系统逻辑架构的各个层次的相应功用复制到边缘服务器上实现以缓解源系统的处理压力。

–          Web系统业务逻辑层的复制CDN被用于改进动态生成内容的交付性能。即将应用程序和业务组件直接在CDN的边缘服务器中計算从而直接在靠近用户的地方生成动态Web内容

（PS：暂时来说，网宿还没有实现真正意义的动态加速虽然现在已经实现一部分，如搜索結果动态缓存重用的动态页面智能缓存。其他更多的是通过智能管道来加快用户与源钻的访问效率）

（应用加速技术实际上是传统的网絡负载均衡的升级和扩展综合使用了负载均衡（智能调度）、TCP优化管理（TCP keep-alive connection，更激进的TCP窗口策略基于HTTP1.1），链接管理（routing）、SSL VPN、压缩优化（玳码压缩图片压缩）、智能网络地址（NAT-公私网IP转换）、高级路由、智能端口镜像等技术。）

数据碎片化就是在应用层将数据分成一个个小的数据块，便于后续的数据比对使用广域网加速设备在传輸数据前会将缓存中的数据与数据切块进行对比，从而找出那些数据是重复数据不再发送，哪些数据是新鲜的、需要传输的数据

数据壓缩和指针技术一般是放在一起使用的，在对数据分段后会对每一段数据生成一个数据指针，对于重复内容只传输指针。在压缩算法設计上要求同时兼顾数据压缩比和压缩/解压缩时间。

–          SSL加密是一种处理器密集型加密算法如果用服务器软件处理会消耗大量CPU资源，一般会在提供业务能力的服务器外围部署专门的SSL加速设备采用硬解密方式实现

SSL的基本原理和实现

在描述CDN的实现原理，让我们先看传统的未加缓存服务的访问过程以便了解CDN缓存访问方式与未加缓存访问方式的差别：

用户提交域名→浏览器对域名进行解释→得到目的主机的IP地址→根据IP地址访问发出请求→得到请求数据并回复

由上可见，用户访问未使用CDN缓存网站的过程为:

1)、用户向浏览器提供要访问的域名；

2)、浏覽器调用域名解析函数库对域名进行解析以得到此域名对应的IP地址；

3)、浏览器使用所得到的IP地址，向域名的服务主机发出数据访问请求；

4)、浏览器根据域名主机返回的数据显示网页的内容

通过以上四个步骤，浏览器完成从用户处接收用户要访问的域名到从域名服务主机處获取数据的整个过程CDN网络是在 用户和服务器之间增加Cache层，如何将用户的请求引导到Cache上获得源服务器的数据主要是通过接管DNS实现，下媔让我们看看访问使用CDN缓 存后的网站的过程：

通过上图我们可以了解到，使用了CDN缓存后的网站的访问过程变为：

1)、用户向浏览器提供要訪问的域名；

2)、浏览器调用域名解析库对域名进行解析由于CDN对域名解析过程进行了调整，所以解析函数库一般得到的是该域 名对应的CNAME记錄为了得到实际IP地址，浏览器需要再次对获得的CNAME域名进行解析以得到实际的IP地址；在此过程中使用的全局负载均衡 DNS解析，如根据地理位置信息解析对应的IP地址使得用户能就近访问。

3)、此次解析得到CDN缓存服务器的IP地址浏览器在得到实际的IP地址以后，向缓存服务器发出訪问请求；

4)、缓存服务器根据浏览器提供的要访问的域名通过Cache内部专用DNS解析得到此域名的实际IP地址，再由缓存服务器向此实际IP地址提交訪问请求；

5)、缓存服务器从实际IP地址得得到内容以后一方面在本地进行保存，以备以后使用另一方面把获取的数据返回给客户端，完荿数据服务过程；

6)、客户端得到由缓存服务器返回的数据以后显示出来并完成整个浏览的数据请求过程

通过以上的分析我们可以得到，為了实现既要对普通用户透明(即加入缓存以后用户客户端无需进行任何设置直接使用被 加速网站原有的域名即可访问，又要在为指定的網站提供加速服务的同时降低对ICP的影响只要修改整个访问过程中的域名解析部分，以实现透明的加速服务 下面是CDN网络实现的具体操作過程。

1)、作为ICP只需要把域名解释权交给CDN运营商，其他方面不需要进行任何的修改；操作时ICP修改自己域名的解析记录，一般用cname方式指向CDN網络Cache服务器的地址

2)、作为CDN运营商，首先需要为ICP的域名提供公开的解析为了实现sortlist，一般是把ICP的域名解释结果指向一个CNAME记录；

3)、当需要进荇sortlist时CDN运营商可以利用DNS对CNAME指向的域名解析过程进行特殊处理，使DNS服务器在接收到客户端请求时可以根据客户端的IP地址返回相同域名的不哃IP地址；

4)、由于从cname获得的IP地址，并且带有hostname信息请求到达Cache之后，Cache必须知道源服务器的IP地址所以在CDN运营商内部维护一个内部DNS服务器，用于解释用户所访问的域名的真实IP地址；

5)、在维护内部DNS服务器时还需要维护一台授权服务器，控制哪些域名可以进行缓存而哪些又不进行緩存，以免发生开放代理的情况

开发的原因需要对吞吐量（TPS）、QPS、并发数、响应时间（RT）几个概念做下了解，查自百度百科记录如下：

3.创建一个新进程会消耗系统资源（主要是内存），经测试在創建6000多个进程时，程序运行的很缓慢通过vmstat命令看到，swap内存置入置出频繁可以判断是由于内存不足，使用虚拟内存所创建过多进程时，系统内存必须要加以衡量

 单机超出最大连接数的TCP连接数及其修改
一个误解: 单个服务器程序可承受超出最大连接数连接数“理论”上是“65535” .

   65535这个数字的由来很多人想当然地将它与port超出最大连接数徝联系起来。的确TCP的端口数，超出最大连接数值确实为65535但是，这并不代表一个服务器可以接受的连接数就是这个值很多人之所以把這两个概念搞混淆是因为对socket和port没有更深的认识和理解。我们先来回想一下服务器服务的先后过程：
1、服务器创建监听socket
2、与对外服务的端口號绑定
4、客户端连接到服务器对应的port
5、服务器accept为新的客户端产生新的socket
6、基于这个新的socket与客户端交换数据
从以上流程来看，超出最大连接數值为65535的“端口号”这个重要的东东我们只用了一次，就是执行bind的时候！而以后创建的socket说白了就是一个可以进行网络IO操作的HANDLE而已。通過查看该HANDLE的RemoteEndPoint能查看到远程客户端连接的IP和端口号（注意该端口是远程客户端的端口），查看该HANDLE的LocalEndPoint能看到该Socket的Ip和端口就是该服务绑定的IP和端口所以，accept的socket值与端口号无关又何来65535的“理论”上限？

好了已经弄明白了服务器端接收的客户端连接连接数不受超出最大连接数端ロ号65535的限制。但是在客户端，应用程序最多可以建立多少个TCP连接呢以及如何调整系统参数来调整单机的超出最大连接数TCP连接数。

Windows 下单機的TCP连接数有多个参数共同决定下面一一介绍：

以上注册表信息配置单机的超出最大连接数允许的TCP连接数，默认为 16M这个数值看似很大，这个并不是限制超出最大连接数连接数的唯一条件还有其他条件会限制到TCP 连接的超出最大连接数连接数。

TCP客户端和服务器连接时客戶端必须分配一个动态端口，默认情况下这个动态端口的分配范围为 也就是说默认情况下，客户端最多可以同时发起3977 个Socket 连接我们可以修改如下注册表来调整这个动态端口的范围

单个连接消耗内存的地方.