第一次在阿里云上部署网站，很容易被“上行”“下行”这两个词绕进去。拆开看并不复杂。下行是数据从云服务器发往用户的方向，用户打开网页、下载文件、看视频，产生的都是下行流量。上行则是用户往服务器送数据，比如上传图片、提交表单。对内容型网站来说，下行基本决定了账单和访问速度。
选计费方式之前，还要分清两件事。在阿里云ECS上，“包月”和“按量”通常指实例本身的付费方式，而公网带宽是另一个维度，常见的是按固定带宽计费和按使用流量计费。很多人对比时把两者混在一起，算出来的数字自然对不上。下面讨论的是带宽怎么计费，具体价格随地域和活动调整，下单前请以阿里云官网的最新定价页面为准。
下行流量从哪里来
很多人以为下行只是页面本身那点内容，其实远不止。一个网页通常要加载HTML、CSS、JavaScript，还有图片、字体，有时还有视频。每个文件都要从服务器走一趟下行。访问越频繁、页面越重，这部分消耗就越明显。不少站长只盯着CPU和内存，等账单或加载速度出了问题才回头看流量。
两种计费方式各适合什么
- 按固定带宽：按购买的带宽峰值收费，规格买下来就要付费，用不用都一样。访问量比较稳定、峰值大致可估的业务，用它心里更有底。
- 按使用流量：按实际产生的下行流量计费。平时访问少、偶尔有高峰的站点，通常不会为闲置带宽买单。但如果流量本身很大，账单会跟着涨，需要盯紧。
判断的依据是流量曲线，而不是单次峰值。把云监控里的公网出方向流量和带宽使用率拉出来，看一两周，平均水平和高峰时段分开记。平均值很低、只偶尔冲高的，一般更适合按流量；全天都比较满的，固定带宽更容易算清楚。
案例一：小型博客为什么账单偏高
一位个人技术博主把博客搭在ECS上，日常页面浏览量约两千次，每篇文章都配了不少截图。他最初直接买了一个较高的固定带宽，后来发现大部分时间带宽都是闲的，每月成本偏高。
他查了访问日志，发现流量基本集中在文章发布后的两三天，之后就回落了。于是他改成按流量计费，同时把截图压缩，并转换为WebP格式。单页下行体积下降了将近一半，月度支出明显减少，页面打开也更快了。这件事的启发是，先把页面变轻，往往比单纯换计费方式更直接。
案例二：大促当天页面打不开
一家中小型电商在大促当天遇到了页面打不开的问题。商品图多，详情页又长，短时间内大量用户同时进来，下行带宽被瞬间打满。服务器的CPU和内存其实还很宽裕，问题出在出口。
团队的调整分三部分推进。商品图先迁到对象存储OSS，让ECS少承担一层出口压力。接入CDN后，用户就近获取静态资源，源站只需回源少量请求。活动前，他们按活动规模预估了峰值，临时调高带宽上限，活动结束后再降回来。大促期间页面速度保持稳定，服务器负载也回到安全范围。
降低下行消耗的几个做法
- 静态资源放到CDN。图片、视频、脚本这类文件走CDN，源站压力小，跨地域的用户也能更快拿到内容。
- 开启压缩。在Nginx里启用Gzip或Brotli，HTML、CSS、JavaScript这类文本体积通常能明显变小。图片要另外处理，压缩和格式转换的效果更好。
- 让浏览器和CDN多缓存。合理设置缓存时间，重复访问时就不必反复下载同一批文件。更新频繁的文件可以加版本号，避免用户拿到旧资源。
- 活动前留足余量。大促或热点事件前提前评估峰值，并确认带宽调整的生效时间。如果等流量上来再扩容，往往已经卡住了。
阿里云下行本身不难理解，难的是看清自己的流量长什么样。先把访问规律和峰值摸清楚，再决定带宽按固定还是按流量计费，同时用压缩、缓存和CDN把每次下载的体积压下来。这几步做完，大多数站点都能在成本和速度之间找到一个不吃亏的位置。
