关于CDN和EdgeOne的思考

昨晚果果给我弄了一个EdgeOne（说是无限流量无限时长），我就在想：天底下哪里有这么好的事情？有猫腻！
今天一想，不对劲！

既然OSS-->CDN-->User要买两样东西 CDN流量和CDN回流
那么，OSS-->Edgeone-->User是否也要买个什么回流呢？
否则不是直接走的oss流量吗？这玩意死贵死贵的！

だから晚上回家搜了一下

他是这么说的：

传统CDN主打内容加速分发，计费模式简单直接，主要按实际使用的流量或带宽阶梯计费，可购买流量包抵扣。

EdgeOne则是集加速、安全防护（DDoS/WAF）和边缘计算于一体的一站式平台，采用按月套餐订阅制（内含流量额度，超量后按量付费），且其资源包与传统CDN的流量包互不通用。

那..既然这样的话，我还是用cdn吧先。毕竟还有80来个G流量包没用呢。可不能浪费呀哈哈！

之前给咱班做的网站有点恶心到我了

在说这件事之前，先得把我的服务器链路弄清楚

首先，我有一台带宽3Mbps的公网服务器(称作A)+一台200Mbps的公网服务器(称作B)+一台内网服务器（称作C）

之前买A主要是因为挂网站和Napcat、Astrbot，所以没咋注意带宽。

但是吧，云服务器基本都是虚拟机，所以说呢，QQ容易检测然后掉线。

所以我又购入了一台小主机C放在家里挂QQ。

但是，由于我家里没有公网ipv4，所以在外面访问不到服务器C的管理面板(包括ssh、各种应用的管理面板等等)

所以又花79块在阿里云弄了一台新用户的大带宽服务器B，和家里那台服务器C组一个内网映射(B挂frps，C挂frpc)

然后，之前给咱班做的网站是怎么恶心到我的呢？

由于我害怕3Mbps的那台服务器A不够52人同时访问一个网站，于是就用了那一台大带宽服务器B。
但是但是，问题就出在这里！

frp如果要映射网页的话，就必须要80、443端口，
但是nginx挂网页也要80、443端口，
就导致这两个东西冲突了！

于是，我为了不影响到他们“订正”用网站，只能改了一下http、https的端口。
于是导致了我现在访问我内网机C上的网站时，非要在后面加上端口才行！
恶心死了！！！

だから我在学校就在想，回来搜一下看3Mbps到底够不够52人同时访问。
结果很显然，是不够的。
Deepseek这样说：

1. 先看清 3Mbps 的实际传输能力
3Mbps = 3,000,000 bps

换算成字节：3,000,000 ÷ 8 = 375,000 字节/秒 ≈ 375 KB/秒
这是服务器 上行带宽的理论上限（实际有协议开销，一般按 90%~95% 估算，约 340~350 KB/秒）。

2. 52 人“同时”访问意味着什么？
如果这 52 个人真的在同一瞬间发起请求（比如刷新页面），服务器需要在短时间内把页面内容传给他们。

每个人平均能分到的带宽：
375 KB/秒 ÷ 52 ≈ 7.2 KB/秒

也就是说：要想在 1 秒内让所有人都加载完，每个页面的压缩后总大小不能超过 ≈ 7.2 KB。
如果允许 2~3 秒加载完成，那么页面可以到 14~22 KB 左右。

3. HTML 网页有多大？
这里区分两种情况：

✅ 情况一：纯文本 HTML 网页（仅 .html 文件）
一个简单的文本页面（比如几个段落、链接）通常 2~5 KB，启用 Gzip 压缩后可能只有 1~3 KB。

52 人同时请求，总数据量：52 × 3 KB = 156 KB，远小于 375 KB，1 秒内完全可以传完。

结论：这种情况下 3Mbps 基本够用。

❌ 情况二：包含图片、CSS、JS 的普通网页
现在一个普通页面（HTML + CSS + JS + 图片）总大小轻松超过 200 KB，甚至上 MB。

如果按 200 KB 算，52 人同时加载需要：200 KB × 52 = 10,400 KB ≈ 10.4 MB
需要的带宽 ≈ 10.4 MB × 8 = 83.2 Mbps —— 3Mbps 远远不够。

实际表现：带宽会瞬间打满，大部分用户需要排队，页面可能十几秒甚至更久才能出来。

4. 还要考虑的现实因素
请求开销：TCP 握手、HTTP 头部等会占用一些带宽，实际有效载荷会更低。

浏览器并发：浏览器会同时请求页面上的多个资源（CSS、图片等），即使用户只打开一个网页，也会产生很多并发连接，进一步增加带宽压力。

是否真的“同时”：真实场景中，52 个访问通常有几秒的分散，峰值需求会略低，但作为容量评估，按“同时并发”计算是安全的。

其他服务：服务器本身可能还有系统更新、SSH 等其他流量，会挤占这 3Mbps。

所以…唉…还是就着他们吧。

学校趣事

17:53英语考试中

咱武老师路过龙xx的时候，说了一句 菜就多练
靠靠靠
笑死我了