首页 游戏 软件 排行 专题

账单多出三成流量:我把每个字节的口径拆开对了一遍

来源: 本站整理 日期:2026/11/5 8:03:47

上个月底客户发来一张账单,说这台机器上个月业务量没涨,出网流量却比上个月多出了三成。他一直跑着同一个站点、同一场活动、同样的流量曲线,账单却跳了一截。客户怀疑是被人刷了流量,我查了一圈,最后发现不是攻击,是三件很朴素但加在一起就不能忽略的事:协议头开销、弱网重传、还有统计口径本身就不一样。这篇就把我当时怎么算这笔账的整个过程写下来,顺带把阶梯计费、超额流量费这些容易看晕的规则也捋一遍。

如果你也在琢磨一台机器每月的流量成本到底怎么算、账单和监控面板为什么老对不上,下面这两家服务器商家的产品说明里有比较清楚的带宽和流量口径描述,可以先拿来做横向对比:profitserver(全球云服务器,不限流量套餐)、恒创科技(香港及亚太带宽资源)

一、先说结论:那多出来的三成在哪

我那天把机器的网络计数器按小时拉出来,和客户业务后台的下载量对了一遍。业务后台显示全天真传了 2.1TB,网卡口径算出来是 2.74TB,差了 630GB 左右。这个差值不是玄学,它基本能拆成三块:

  • 协议头和封装开销。每个 TCP 包有 20 字节 TCP 头加 20 字节 IP 头,加以太网封装后 40 字节起步;如果是 HTTPS,还有 TLS 记录层和握手流量。你如果传的是大量小文件或者小请求,这个开销能吃掉 5%~15%。举个例子,1440 字节的 MSS 装满时,链路层效率大概在 97% 左右;但如果你的业务每次只发 200 字节,有效载荷占比立刻掉到 50% 上下,看着不多,乘上全天的量就很可观。
  • 重传和乱序。跨境线路抖动是常态,TCP 丢了包就得重发,那部分字节是真金白银要计费的。出站方向算一次,入站方向部分商家也计,两个方向都算的话差距更明显。我那次抓包看了十分钟,发现 8 个连接里有 3 个在持续重传,丢包率大概 1.5%,重传直接把出网量抬高了差不多 15%。
  • 统计口径本身不一致。这一条最容易被忽略。你在面板上看到的「流量」,可能来自应用埋点、可能来自 Nginx 的 access log 加总、也可能是宿主机上 eth0 的计数器。这三个数字本来就不相等:应用埋点记的是业务对象大小,Nginx 记的是响应体大小,网卡记的是链路上跑过的所有字节,包括内网其他容器、镜像拉取、apt 更新、日志上报、监控探针。

所以「账单比实测多」这件事,很多时候根本不需要怀疑任何人,先问一句「这两个数字是同一个口径吗」。

出网流量账单与实际用量对不上的技术示意图

二、怎么把每个字节拆开算

我现在排查这类问题的顺序基本固定。第一步,读网卡计数器,这是最接近计费口径的数据:

cat /sys/class/net/eth0/statistics/tx_bytes
cat /sys/class/net/eth0/statistics/rx_bytes

这两个数是网卡视角的累计字节,会包含所有进程的收发。把它和下面这几个交叉验证,就能快速定位差距来源。

第二步,看应用层真实传输量。如果你的服务是 Nginx,用 access log 里的 $body_bytes_sent 加总,这是发出去的响应体字节,不含请求头和响应头。再往下就是业务埋点了。用一条 awk 把一天的日志加起来,几秒钟就能出结果:

awk '{s+=$10} END {printf "%.2f GB\n", s/1024/1024/1024}' access.log

第三步,用 vnstat 或 nload 看时间维度上的分布。vnstat --hours 能按小时给出收发的字节数,配合数据库里的业务量曲线一起看,很容易发现「凌晨三点还在跑流量」这种异常那次就顺手抓到过一个同事在拿服务器跑同步盘。

第四步才是抓包。tcpdump 抓一小段,然后看 seq 号的缺口和重复,能直接量化重传:

tcpdump -i eth0 -nn -c 2000 'tcp port 443' -w /tmp/cap.pcap

拿到包里重传段的比例,再乘上当天总流量,重传这块的账就算平了。三块加起来,账单和实测的差值基本能对上九成以上,剩下那一成通常是小数点进位、采样时间点错位,以及商家侧四舍五入。

TCP 协议头开销与真实载荷差异示意图

三、阶梯计费和超额流量费是怎么算的

说回计费本身。包月套餐里带的那个流量额度,很多商家不是「用完就停」,而是用完之后按更高的单价继续算,这就是阶梯计费。

典型的三段式是这样的:

  • 额度以内:比如 2TB,按套餐价折算的单价算;
  • 超出第一档:比如 2TB 到 5TB,单价上浮;
  • 超出第二档:再往上,单价再上浮,甚至封顶。

关键在于「超出」是按整个区间的量还是按超出部分的量计价,这两种算法结果差得很多。举个数:套餐 2TB,超出后第一档单价是套餐单价的 2 倍。假设你用满了 3TB,如果按「超出部分算双倍」,你付的是 2TB 原价 + 1TB 双倍;如果按「用满 3TB 全部按双倍算」,你付的是 3TB 双倍。前者比后者省整整 1TB 的钱。所以签约前一定要问清:跳档是分段计价还是整段重算。

另一个坑是超额之后的处理方式。有的商家是限速但不收费(端口从 100M 降到 1M,流量继续跑不计钱),有的是直接停机,还有的是限速加收费。业务如果对时延敏感、只是需要大文件传输,限速不断机可能是最划算的;如果是跑对等节点或者备份任务,停机反而能逼你及时发现问题。这三种模式没有优劣之分,取决于你能不能接受。

流量监控看板与出网流量统计

四、不限流量套餐到底适合谁

不限流量的机器听着很香,但要看清楚它的限制在哪。常见的三种:

第一,不限流量不等于不限带宽。端口还是 100M 甚至 1Gbps,流量随便跑,但速度封顶。适合下载站、镜像站、备份机这种带宽敏感的场景;如果你要的是高并发小请求,不限流量帮不了你,因为瓶颈在端口不在总量。

第二,不限流量通常附带公平使用条款。持续跑满带宽跑满端口,可能触发限速;月流量超过某个阈值也可能被要求迁移。这类条款各家写得都不太一样,买之前最好让客服给一条明确的书面答复,别只信页面上的「不限」两个字。

第三,要看清不限的方向。有的商家不限出网但计入网(回源流量、跨机房同步就可能踩雷),有的商家双向都算。我那次帮客户对账,就是因为他以为「拉回来的流量不算钱」,结果对方的计费口径是出入双向都算,一台做数据同步的机器,账单直接翻了倍。

带宽桶与流量分层计量模型

五、给日常运维的几个具体建议

结合这些年的排查经历,我现在给客户的固定建议是这么几条。

第一,装一个不依赖应用的流量监控。服务器上跑一个 NetWorx 之类的工具,直接读网卡计数器,它跟计费口径的差距远比应用埋点小,也能第一时间发现异常进程。这个工具免费版就够用,win 和 linux 都有。

第二,给流量设三条线。我一般设 60%、80%、95% 三个告警阈值,分别对应「注意」「该查了」「快超额」。80% 那条线最关键,超额之后如果是分段计价,代价其实没想象中高,但如果是整段重算就非常贵。

第三,把静态资源和动态接口分开算。如果你的流量大头是图片和视频压缩包,那优先考虑的优化手段是压缩率和缓存命中率,而不是换更大的带宽。用 gzip 或者 brotli 把体积压掉三成,效果比把端口从 10M 提到 30M 直接得多。

第四,跨机房同步和备份流量单独记账。这类流量往往是突发且单向,容易在月结时吓你一跳。可以用 iptables 或者 tc 工具给这类流量打上单独的标记,在监控里拆出来看,账才算是算明白了。

说到底,流量这件事没有神秘的公式,它就是「网卡上跑过的字节」乘以「那个区间的单价」,难的是把它和业务量对上、和合同条款对上、和每天的监控曲线对上。把口径统一了,账单上多出来的那三成就再也吓不到你了。

玩家留言 跟帖评论
查看更多评论
相关文章
猜你喜欢
同类下载