腾讯云服务器网络规格：内网带宽、PPS 与并发瓶颈
上个月一个客户的腾讯云服务器网络规格踩了坑：十台扩到二十台，压测的 QPS 曲线几乎还是一条平线，只抬了个头。他第一反应是"是不是买的带宽不够"，准备再升一档公网带宽。我让他先别动，把云监控切到出包量那一栏，五分钟就看到了答案：带宽只用了三成，出包量却贴着规格上限。这种单子我们每年要接十几起，问题从来不是"带宽买少了"，而是把三件不同的事当成了一件。
三个"带宽"混着说，故障就永远说不清
公网带宽、内网带宽、网络收发包能力，是三个独立的资源，由三套不同的机制约束，也对应三种完全不同的故障现象。
在腾讯云服务器上，公网带宽的单位是 Mbps，管的是实例与互联网之间的通路，出方向计费、入方向通常不计费但同样受限，可以按固定带宽买，也可以按使用流量计费。内网带宽的单位是 Gbps，管的是同一 VPC 内实例之间、实例与云数据库和缓存之间、实例与负载均衡之间的通路，同地域内网流量不计费，但速度被规格卡死。网络收发包能力（PPS，Packets Per Second）管的是每秒能处理多少个数据包，与包有多大无关。
这三者的关系不是"越大越好"，而是"谁先到顶谁决定上限"。 一个每秒处理三万次 Redis 读的业务，包都很小，公网带宽可能只跑了几 Mbps，PPS 却早已打满；反过来，一个做图片分发的站点，单连接大包为主，PPS 富余得很，公网带宽先见底。判断方向错了，钱花了，问题还在。
我在售前最常纠正的一个误解是"内网不要钱所以内网无限快"。内网流量确实不计费，但内网带宽是规格的一部分，写在同一张规格表里，和 vCPU、内存并列。买一台入门规格却指望它扛住数据库全量同步加备份传输，跟买一台两核机器跑编译是一样的性质。
内网带宽：规格表里最容易被跳过的一列
打开腾讯云服务器网络规格表，绝大多数人只看 vCPU 和内存，往下两列的"内网带宽"和"网络收发包能力"直接略过。这两列恰恰是扩缩容时最容易翻车的地方。
同一代规格族里，内网带宽随规格档位递增，小规格可能是 Gbps 里较低的一档，中高规格往上走，部分规格族还会标注网络增强或更高的转发能力。具体数值每代产品都在调整，下单前请以控制台当日规格表为准，不要拿两年前的选型表当依据。我见过客户拿一份三年前的架构文档做容量规划，买回来的机器内网带宽只有预期的一半，压测第一天就返工。
内网带宽被打满的现场，往往不长"网络故障"的样子。一个典型场景是主从数据库：一主两从，半同步复制，加上每天凌晨的备份传输到另一台机器，白天业务正常，凌晨两点应用 RT 突然抖到几百毫秒，早上又恢复。查应用日志什么都没有，查慢查询也正常，最后看内网出带宽曲线，恰好在那段时间贴着天花板。复制流量和备份流量抢的是同一条内网通路，谁也没错，就是不够用。
处理办法有几个层次。第一层是把备份目标换成对象存储或独立网络路径，别让备份和复制共用同一块网卡；第二层是把大 value、大 key 拆掉，Redis 单次取几百 KB 的场景对内网带宽的消耗远超想象；第三层才是换规格族。跨可用区部署还要多留一层余量，同可用区内网通路和跨可用区通路的实际能力不一样，延迟也从零点几毫秒变成一到三毫秒，规格表上的数字通常指同可用区，跨区链路的实际表现要以实测为准。
验证内网带宽别看单流。用 iperf3 单条 TCP 流去测，经常只能跑到标称值的一小部分，原因在后面讲多队列时细说。正确做法是多流并发，至少四条流同时打，才能逼近真实上限。
PPS：小包业务真正的天花板
PPS 这件事，用一句话概括：带宽是水管粗细，PPS 是水表转得多快，小包业务卡在水表上。
算一笔账就清楚了。以太网上一帧 64 字节的小包，加上前导码、帧头、IP 头、TCP 头、帧尾校验，实际在线路上要占八十多字节。一条 1 Gbps 的链路跑满 64 字节小包，理论包速率大约是每秒一百四十八万包；换成 1500 字节的大包，同样 1 Gbps 只能跑到每秒八万包左右，差了将近二十倍。云上的转发面还要做虚拟化封装、安全组匹配、连接跟踪，开销比物理交换机更高，所以规格表给的 PPS 数字，是这套转发能力的实测口径。
换算公式可以记成：包数 ≈ 带宽 ÷（(包长 + 66) × 8）。式子里 66 是各类头部和帧间隙的近似开销，包长按 MTU 或实际业务包大小代入。用它估一遍就知道自己的业务属于哪一类：一个返回 400 字节 JSON 的接口，一个 Redis 的 GET 请求，一次 DNS 查询，一个每秒一次的心跳，都落在小包区间，PPS 消耗和带宽消耗完全不成比例。
还有一类常被忽略的包：负载均衡的健康检查。后端从十台扩到五十台，健康检查的频次跟着线性增长，检查包本身很小，但对 PPS 和新建连接数的占用是实打实的。有些客户扩容后入口反而更慢，查到最后是健康检查把转发面的小包预算吃掉了一块。
怎么确认自己撞的是 PPS 墙？云监控里看"出包量/入包量"两项，换算成每秒包数，再和规格表的收发包能力对比。如果带宽利用率只有三成而包速率到了七八成，答案就很明确了。这时升公网带宽没有任何作用，要么换 PPS 更高的规格族，要么把协议改大：合并小请求、批量接口、长连接代替轮询、压缩响应体，都是把包变少变大的办法。
连接数不是带宽问题，但症状一模一样
有一类故障，现象和带宽打满完全一致：响应变慢、偶发超时、监控上带宽没满、CPU 也不高，但用户就是觉得卡。这时要看的不是带宽，是连接。
第一处是内核的连接跟踪表。做了 NAT 或经过安全组深度检测的实例，每条连接都要在 nf_conntrack 表里占一个位置，表满了新连接直接被丢弃，日志里是 nf_conntrack: table full, dropping packet。查当前用量看 /proc/sys/net/netfilter/nf_conntrack_count，上限看同目录下的 nf_conntrack_max。短连接多、超时时间长的业务，这张表消耗得极快。
第二处是本地端口。客户端角色为主的机器，每条对外短连接要占一个本地端口，可用范围由 net.ipv4.ip_local_port_range 决定，默认只有两万多个。如果业务每秒新建上千条短连接，且 TIME_WAIT 要占用几十秒，端口很快就不够分，报错是 Cannot assign requested address。这类问题在"我们的服务要调很多第三方接口"的场景里特别常见。
第三处是 NAT 网关的 SNAT 端口。几十台机器经同一个 NAT 网关访问同一个外部地址，源端口映射会在网关上被复用和耗尽，现象是"偶发连接超时，重试就好"，应用侧完全看不出规律。这个坑很难查，因为问题不在你的机器上，也不在对端，而在中间那台你平时不看监控的网关。
第四处是全连接队列。somaxconn 和应用层的 backlog 设得太小，突发流量时握手完成但应用没来得及取走，内核直接丢掉，netstat -s 里的 listen overflows 会计数。这个计数一旦开始涨，用户侧就是间歇性连接失败。
四处问题的处理思路一致：能长连接就别短连接，能连接池就别每次新建，能调超时回收就别让 TIME_WAIT 堆着。 应用侧开连接池、把 keepalive 打开、把上游空闲连接数设对，比调内核参数有效得多。内核参数是兜底，不是主方案。
排查顺序：机器、内核、网关
在腾讯云服务器上排查网络问题，最怕上来就抓包。抓包能确认现象，但很难直接指向原因，而且在高并发下抓包本身会放大问题。我通常按下面这张表的顺序走，从粗到细，每一步都能排除掉一大片可能。
观测维度 单位 打满时的典型表现 观测方式
公网出带宽 Mbps 下载变慢、首屏卡在图片、监控曲线贴顶 云监控公网出带宽，对照套餐或带宽上限
内网带宽 Gbps 数据库复制延迟、备份窗口拉长、RT 抖动 云监控内网出入带宽，配合 sar -n DEV 1
收发包能力 万 PPS 带宽只用三成但延迟上升、请求排队 云监控出入包量换算包速率，对照规格表
连接跟踪 条 新连接偶发失败、重试即恢复 ss -s 看 timewait 与 estab，读 conntrack 计数
队列与丢包 个 握手失败、吞吐忽高忽低 netstat -s 看 listen overflows 与重传，ethtool -S 看 drop
网关规格 连接数/带宽 全部后端都慢、单机指标却正常 NAT 网关与负载均衡的监控页，看规格档位
顺序上先看云监控的两条曲线，能在一分钟内区分"带宽型"和"包量型"，这一步不需要登录机器。确认不是带宽之后，再登机器看 sar -n DEV 1，重点看 rxpck/s 和 txpck/s 是否接近规格上限，同时看 rxdrop/s 有没有非零值。接着 ss -s 看连接状态分布，如果 timewait 数量长期在几万条，基本可以定性为短连接过多。最后才是 netstat -s 里的重传、乱序、队列溢出计数，以及 ethtool -S 里的网卡级丢包。
有一件事要提前说清楚：云监控的采集有粒度，通常是一分钟一个点，秒级毛刺看不到。所以"监控显示只有六成"不等于没打满，峰值可能在你没看到的十几秒里。给关键业务加一个机器上的秒级采样脚本，比反复怀疑监控准不准有用。
多队列与单连接：加机器不一定更快
很多人有这样的经验：一台机器用 curl 下载只有几 MB/s，开多线程下载立刻翻几倍。这不是带宽不够，是单条 TCP 连接吃不满多队列网卡。
现代实例的网卡是多队列的，每个队列绑定一个中断，再由内核分给不同的 CPU 核做软中断处理。一条 TCP 连接在正常情况下只落在一个队列上，也就只用一个核做协议栈处理。单核的软中断跑满了，这条连接就到顶了，剩下的队列和核对它没有帮助。这也是为什么用 iperf3 单流测内网带宽经常测不出标称值，而四流、八流并发就能接近上限。
判断方法很简单：top 里看 si（软中断）这一列，如果某个核的 si 长期在很高位，其他核很闲，就是典型的单队列瓶颈。ethtool -l 看队列数，/proc/interrupts 看中断在各核上的分布，分布严重不均说明中断亲和性或 irqbalance 没配好。
但这个结论不要用错方向。业务侧的"加机器"解决的是应用层的并发，不解决入口侧的单点上限。十台扩到二十台，如果瓶颈在负载均衡的规格、在 NAT 网关的带宽、在单台 Redis 的连接数，后端加一倍也不会快。我遇到过最典型的一次，客户把后端从八台扩到二十四台，QPS 只涨了两成，最后发现入口负载均衡的每秒新建连接数已经到了规格上限，后端再闲也接不进来。
网关的隐形上限：扩后端之前先看它
云上有一条很容易被忽略的链路：流量不是从客户端直接到你的实例，中间隔着一层或几层托管组件。负载均衡、NAT 网关、共享带宽包、云防火墙，每一个都有自己的规格档位，每一个都可能是真正的瓶颈。
负载均衡的规格通常按每秒新建连接数、并发连接数、每秒请求数几个维度分档，档位不够时表现为新建连接被限、长连接被挤掉，后端监控一片正常。NAT 网关按规格分档，带宽和连接数都有上限，出口流量大或并发连接多的业务，网关先于实例见顶。共享带宽包把多台实例的公网带宽合成一个池子，池子总量和每台实例的带宽上限是两回事，实例侧的带宽上限没调，池子里再多也用不上。
还有一个反直觉的组合：小规格实例配了大带宽。CVM 的公网带宽可以单独加，实例规格却不跟着变，额度买够了，吞吐还是要看机器体质——最终受教育于它的内网带宽和收发包能力。带宽额度是"许可"，实例转发能力是"体力"，许可再大，体力不够也跑不动。 客户抱怨"买了一百兆只能跑三十兆"，八成是规格选小了，而不是带宽没给够。
到这一步，排查思路应该已经很清楚：入口组件看规格档位，实例看带宽与 PPS，内核看连接与队列，三层都过一遍再谈加机器。轻量应用服务器在这条链路上