type
status
date
slug
summary
tags
category
icon
password
最近在做一个网页聊天的项目，前后端通过`stream`保持长链接，但感觉`stream`更新比较慢，反映在网页上的表现是聊天输出卡顿。
针对`stream`更新慢的问题，后端开发第一时间想到的是API加速，说的是“可以通过CDN来提高API响应速度”。我当时并没有想太多，心想由后端开发和SRE搞好加速就行，前端无非是换一个API链接。
后来SRE跟我说已经搞好了，我换了加速后的API连接进行测试，果然快了很多，响应速度几乎提升了一倍。中午吃饭的时候便和同事聊到：
“那个项目的接口使用CDN加速后，果然快了很多。”
“API使用CDN加速？你确定吗？”
“额。。。总之是API加速了，我也不确定是不是使用了CDN。”
“CDN不是用于缓存作用吗？API是动态结果，为什么要用CDN？即便用了，真的能加速？”
“额。。。”
虽然我相信即便API是动态结果，即便我们不需要依赖缓存，使用CDN后肯定也能达到加速的效果。但一时间也说不出个所以然，所以吃完饭赶紧向SRE请教。
诚然，CDN提速的一个重要原因是因为缓存，多个CDN节点组成的网络像一层膜一样横穿在请求端和响应端之间，当一个请求到达CDN层的时候，CDN如果检查到缓存中有该请求需要的结果，则直接响应请求结果，本次请求甚至无法穿过CDN这层“膜”；只在当CDN层匹配不到本次请求的结果时，才允许请求穿透这层“膜”，达到响应服务器，我们称之为源站，而穿透“膜”的这种行为，我们称之为击穿CDN。
难道真的像同事说的那样，“API是动态结果，无法缓存，必然每次都击穿CDN，所以API无法使用CDN加速”？这么想的话，还是太低估了CDN在背后帮我们做的事情。所谓缓存，其实就是静态资源缓存，对应的是静态内容加速；与静态内容加速相对应的，是动态内容加速，指的是用户在请求一些动态内容时，不直接请求源站，而是由基于地理位置的DNS调度，请求最靠近用户的云服务节点，再由云服务节点通过优化过的传输网络（公网，但比普通BGP更优化的链路），转发请求到源站，达到优化和加速的目的。
所以即便没有缓存，使用CDN也能帮助我们更快的达到源站。
但是和SRE聊完后才知道，原来本次API加速，使用的并不是CDN（这是由于牵扯到一些业务原因，并非说CDN加速不好），而是使用了一种叫做Anycast的技术。
Anycast又叫任播，是指一个发送方同最近的一组接收方之间的通信。当一个单播地址被分配到多于一个的接口上时，发到该接口的报文被网络路由到由路由协议度量的最近的目标接口上。原理为，普通的IP是单播寻址，全程走公网，如果用Anycast的话，该公网IP用任播形式寻址，在腾讯云的多个节点都发路由，这样客户端的包只需要走公网到达最近的腾讯云节点即可，剩下来的路程是走更有保障的腾讯云内网。
以上是摘抄了网络上的一些解释，按照我的理解，有点像是“直达专车”的概念，乘客只需找到最近的“直达专车”，一旦上车之后，它就会走直达通道，这比各种“中转”“并道”等来得更快。希望我的理解没问题。
后来还了解到，除了以上的CDN加速和Anycast，能到达到加速目的的还有很多，虽然不懂，但还是记录一下吧：
- 静态CDN服务
- 动态内容加速
- 全站加速（动态+静态加速）
- Anycast 公网加速 AIA
- CLB跨地域部署
- 全球应用加速GAAP