跟大家分享一下CDN，分为2个部分：原理和详解。首先说一下CDN的基本原理。主要分为4个部分来描述：CDN的由来，如何做调度，什么是缓存，关于安全。什么是CDN？这是做完CDN后的拓扑图。这里面有几个概念需要搞清楚：OriginServer：源站，也就是客户做CDN之前的真实服务器；User：访问者，即访问本网站的互联网用户；EdgeServer：CDN服务器，不仅仅是“边缘服务器”，后面会详细说明；s/(single)only/指/；LastMile：最后一英里，即互联网用户访问的CDN服务器之间的路径。我们平时使用的DNS服务器一般称为LDNS。解析域名时，一般有两种情况。一种是域名在DNS中有记录，一种是没有记录。两种情况的处理过程是不同的。当你访问163域名时，如果LDNS中有缓存记录，它会直接给你IP地址。如果没有缓存记录，它会一步步向后续的服务器发起请求，然后将所有的数据汇总，交给最终的客户端。当你访问地址163的时候，其实如果本身没有内容，后面会去获取数据。这个过程的术语是递归。它会先请求全球13个根域服务器，询问com域名在哪，然后根域服务器回答，一步步来，这个过程比较复杂，有兴趣的可以查看相关资料，这里就不赘述了。DNS调度肯定很多人好奇怎么调度定位？其实也是通过LDNS的具体地址来完成的。比如看图，假设你是广东电信的客户，那么你用的DNS服务器做递归的，时不时的，他会去访问某个CDN厂商的GRB，一个全局的调度系统，他就能够查看它来自哪个LDNS。假设如果用户和LDNS使用同一地区的服务器，他会间接认为用户也是广东电信的。再举个例子，比如北京联通的一个用户使用的是DNS地址。一般会自动分配北京联通的服务器。当这个服务器进行递归时，调度服务器会看到请求来自北京联通。LDNS服务器会为其分配一个北京联通的服务器地址，然后让北京联通的用户直接访问北京联通的服务器地址，实现区域精准调度。从这个调度理论我们可以发现一个问题，就是假设用户使用的LDNS地址和你在同一个区域，那么这时候我们的调度可能是正确的。但是比如你是北京联通的用户，但是你用的是广东电信的LDNS，那么GRB系统就会误认为你是广东电信的客户，就会错误调度。以前有一次，我在社区里上网。由于我的路由器问题，我把北京联通的DNS服务器地址设置为202.106.0.20。后来去深圳出差，发现访问比较大的网站比较慢。经过分析发现，我设置的DNS地址是北京联通，而我在广东和深圳使用的网络都是中国电信连接的，但是分配给我的地址是北京中国联通，所以我使用中国电信的线路来访问北京联通的地址，肯定会很慢。因为刚刚提到的DNS调度机制存在一定的问题，所以在某些情况下我们会采用第二种调度机制，称为HTTP调度。了解http协议的都知道http协议中有一个功能叫302跳转。它的实现并不是说你访问一个URL，马上吐出你要的数据，而是吐给你一个302回信Command，这个信令的header会告诉你有一个locationtarget，这个location告诉你要??做什么donext，具体的调度是通过location来实现的。虽然我用的DNS和我不在一个区，但是访问http服务器的时候，服务器是CDN公司提供的。当客户访问服务器时，虽然无法通过DNS的方式获取到客户的真实IP地址，但是如果访问http服务器，他就可以直接看到客户的真实IP。此方法可用于纠正调度。直接给你返回一个302，然后location里面有一个真正离你最近的CDN服务器。这种调度方法的优点是准确，但也有缺点。它需要一个TCP三向握手来建立连接。与DNS不同，它不直接请求数据包并给出反馈。它需要一个TCP三向握手。建立公司。二是如何访问http服务器？如果之前是通过DNS调度的，其实之前的DNS是无法保存的。国内没办法做anycast，也就是没办法直接访问一个知名的所以一般情况下都是用DNS做第一次调度，然后用HTTP做第二次纠偏。在这种情况下，你可以想象一下，如果你下载了一个大文件，比如电影，但是你访问的是一个很小的页面元素，比如只有几千字节的图片，那么，实际上你的调度时间已经占用了很多很棒的成分。事实上，这种302调度是磨刀不误砍柴工的方案。如果你后面有很多工作要做，比如下载电影，会花很长时间，那你的调度是准确的，哪怕是需要一点时间来调度。值得。但是，如果您完成了后续访问，那么以这种方式安排就没有多大意义了。除了DNS调度和http302调度之外，其实还有一种调度方式叫做httpDNS调度。它的原理是通过一个普通的http请求发送一个get请求，然后在请求中以参数的形式携带一个I待解析的域名，然后服务器去数据库中查询，查询后，通过http的正常响应，你要请求的IP通过http协议给你了。这个协议的特点之一是它必须被两端支持，因为这个模式是非标准的。没有RFC文档说您的客户端或您的操作系统本机支持此机制。这有点类似于API的方式，如果要实现，就必须要两端都支持。第三种调度应用场景一般在手机APP端。在APP软件中，如果你想访问一些东西，可能会被运营商劫持。这个劫持问题还有很多篇幅可以谈。为了避免这种劫持，可能会用到这种httpDNS调度方式。由于APP程序是自己写的，所以说实现这么简单的API是借口是很容易的。CDN接入可能会问，你说的那么多DNS和具体的CDN调度有什么关系？因为当你拿到一个具体的DNS域名地址的时候，他给你的是一个IP地址。然后在没有CDN之前，他给你的IP地址就是没有CDN的时候原来的服务器地址。但是如果你做过CDN，你会发现你最后得到的IP地址是CDN的节点，而不是真正的原始服务器。我们平时说的获取IP地址，其实就是DNS的A记录。DNS中有很多不同的记录，比如A记录负责给你一个IP地址；例如，CNAME记录为您提供域名的别名。当然还有很多其他的记录，比如TXT记录，MX记录等等。这个和CDN没有关系，这里就不赘述了。有兴趣的可以查看DNS相关文档。上图是CDN介入后的明显效果图。linux中有一个命令叫dig，可以直接列出要访问的域名的具体解析。那么，从这张图可以看出，当你要访问www.163.com时，虽然他最后给了一个IP地址，但实际上是经过了两次CNAME记录。第一条CNAEM记录就是我们之前提到的CDN的GRB。他拿到这个数据后，就可以间接的知道你的LOCODNS是从哪里来的，然后间接的给你定位。以这张照片为例。其实第一跳是跳转到网速地址，第二跳是分配网速的平台。本平台将其他IP分给最终客户。缓存系统——除了DNS调度，CDN还有一个非常重要的部分，就是Cache系统，即缓存系统。用来缓存能缓存到CDN边缘节点的东西，这样当第二个人访问同一个节点，同一个特定的电影或者MP3时，就不用再回到真正的源站去获取数据通过CDN链接，但是数据是边缘节点直接给的。Cache系统包含了很多技术，比如以空间换取时间的高效数据结构和算法，多级缓存以热度区分，前端SSD后端机械硬盘等等，我就不说了说了很多细节，有兴趣的可以稍后交流。对于Cache系统，有两种不同的工作状态。第一种工作状态就是所谓的命中（hit），第二种是没有命中（miss）。如果命中了，直接搜索找到磁盘或者内存上的数据，把这个数据直接吐给客户，而不是从后面拿数据。在这种情况下，它将具有完美的加速效果。第二个是错过的时候。事实上，miss和hit的唯一区别是，当我发现这个资源在我的本地机器上不存在时，我会去我的上游（upstream）获取数据。收到这些数据后，除了第一时间交给客户外，还会在硬盘上缓存一份。如果硬盘空间满了，就会用一系列的替换方法来替换最旧、最冷的数据。提到了上游，而不是原始服务器。原因是客户访问CDN节点时，发现上面没有数据。不是直接从原来的服务器上获取，而是通过他的另一个CDN节点，再通过middlemell。做一些数据传输。然后上游层从原来的服务器上取数据，通过一系列的加速方式，快速的将数据传递到我们的边缘节点，再传递给终端客户。在此过程中，上下游层会缓存一份数据。通过这种树形结构，例如将多个边缘节点聚合到一个或多个二级层节点，从而逐步实现流量收敛。说到Cache的具体技术，相信在座的很多朋友都是同行业的。有人会说不难，只要你有网络和运维人员。其实我不这么认为，因为你想做好其实很难。例如，您是否考虑过我列出的许多技术？举几个例子，你做过网卡的多队列吗？绑定到CPU的亲和力？是否改进了磁盘的调度算法？另外，收纳的时候还用吗？等等。包括内核的调优，包括架构和CPU的绑定，CPU的多级缓存的使用，然后你用标准的机制给你处理。再比如，编译程序的时候，你还是用intel编译，然后调用很多。比如一个很简单的字符串拷贝，那你用它，你还是用汇编写，用什么方法等等，细节很多。关于高性能的研究还有很多。如果你有兴趣，可以稍后与我交流。我想表达的一个观点是，做CDN看似很简单，上手确实简单，但真正做好却很难。安全问题在你做CDN之前，你的网站很可能会遭受各种攻击。那么攻击一般分为两种。第一种叫做蛮力攻击，它让你的带宽无法抵抗，最终导致拒绝服务。另一个是技术攻击。作为CDN，你原来的服务器IP已经被隐藏了。这样当攻击者访问你的域名时，他真正访问的并不是你的真实服务器。当他访问CDN节点时，没有办法把CDN节点打倒。也就是说，即使他有能力将10g节点或40g大节点等所有CDN节点全部打倒，由于CDN天然的分布式部署，他也很难快速瘫痪所有CDN的所有边缘节点。同时国家。此外，还有另一种针对您的DNS地址的攻击。如果你的GRB瘫痪了，就会导致整个调度系统失效。如果调动系统出现故障，即使你的CDN的Cache服务器还能正常接受请求，但是因为流量问题无法调度。所以你需要在DNS层做很多的保护机制，比如使用高性能的DNS或者使用分布式部署的方式等等。基于技能的攻击不需要很大的流量就可以把你原来的针打下来或者让你的网页出错了。比如注入，挂马甚至更严重的会直接把你的数据库拖走等等。那么作为CDN，其实很多厂商已经开始具备这样的技术防护能力了。比如WAF（WebApplicationFierwall），它是一个应用层防火墙，可以直接分析你的请求内容，分析内容是否恶意，如果恶意，过滤，报警等一系列措施保证你的安全原始服务器。第二部分主要针对网络层的优化、架构的优化、Cache的选择、性能分析等，对整个CDN的基本原理进行了深入分析。原来的CDN其实就是ContentDeliveryNetwork这三个词的缩写，也就是内容分发网络。不过我觉得应该是可以在Network上做点什么。CDN的概念是加速，所以我们千方百计做各种优化，从一层到七层优化，达到最终的优化效果。为什么说第一层是优化，其实是硬件，你选服务器就是一种优化。你用ssd还是saker硬盘，你应该用pce卡还是ssd。您的CPU应该使用Xeon还是AstroBoy等，都需要考虑。至于第二层，链路层的优化指的是资源方面。比如如何选择机房。三层路由层指的是你在middlemell真正的路由选择的具体细节。会有图详细说明。第四层是指传输层的优化。我们一般的业务都是TCP，所以我们可以明确的说，这里指的是TCP的优化。另一件事是七层也可以优化。例如，您强行压缩内容，甚至将压缩级别更改为压缩。作为CDN，基本上我列出了一些可能用到的技术，大概10个。比如就近分发，策略缓存，传输优化，链路层优化，包括内容预取，归源回源。然后是持久连接池、主动压缩，以及你如何确保客户在你原来的服务器宕机时能看到数据，以及许多其他细节。路径优化，其实我们可以把它抽象成一种寻找最短路径最优解的思想来解决实际问题。当你需要将数据从a点传输到b点时，往往会经过c点，这比直接从a点到b点要快。互联网有个三角原理，跟地理位置原理有些区别。虽然有一定的相关性，但还是有区别的。从a到b通过c可能比直接从a到b更快。在数据传输过程中，需要考虑很多综合因素。到目前为止，包括Acme在内，都很难实现链路选择和切换的完全系统自动化。在调度的时候，很多公司都有专门的团队来管理流量调度。很多制度可能只是起到支持和参考的作用，但真正需要做决定的是人。因为你需要考虑的因素太多了，比如你的带宽成本，带宽节点冗余，服务器承载能力，你的客户敏感度，该砍什么不该砍，等等很多细节。刚才说的传输层的优化就是TCP优化。在当今的互联网中，TCP优化是一种能够带来最直接的客户体验的实现方式。
