大概率会打满，但打满的不是你想象的“出口带宽”，而是压测机所在链路的瓶颈，DOH压测与传统UDP DNS压测的带宽消耗模型完全不同，远程压测场景下，几十万QPS就能把千兆带宽吃干净。
DOH压测的带宽开销从哪里来
DOH（DNS over HTTPS）本质上把DNS查询装进了HTTP协议里，对比传统DNS的UDP 53端口单包交互，DOH的每次查询要经历TCP握手、TLS协商、HTTP/2头部编码、请求响应解码这一整套流程。
一个典型DOH查询的流量构成大致如下：
- TCP三次握手：约200字节（SYN、SYN-ACK、ACK）
- TLS 1.3握手：2-3KB，取决于会话复用情况
- HTTP/2头部帧：压缩后50-150字节
- DNS查询本体：压缩后50-200字节
- DNS响应报文：通常100-500字节（取决于记录类型和数量）
- HTTP/2响应帧头：50-100字节
把这些加起来，单次完整请求的流量轻松超过1KB，如果TLS会话不复用，单次请求要额外多出2-3KB的握手开销。
这里有个关键变量：会话复用率，使用HTTP/2长连接压测时，连接建立成本被摊薄，每条查询的网络开销可以压到几百字节，如果压测工具每次新建连接,带宽消耗直接翻好几倍。
本地回环压测与远程压测的本质区别
很多团队做DOH压测图省事，直接在服务器本机跑压测工具，这种情况下流量走的是loopback虚拟接口，不经过物理网卡,根本不会占用机房实际带宽。
本地回环压测测的是纯协议处理能力，CPU、内存、内核网络栈才是瓶颈，这能验证DOH中间件的QPS上限,但完全无法暴露带宽相关的问题。
真正的带宽压力测试必须从外部发起，压测机与目标服务器之间隔着物理网络链路，这时流量才真正占用网卡、交换机、防火墙和运营商线路。
这里出现一个常见误区：很多运维在压测机上跑dnsperf，发现目标服务器CPU还没跑满，压测机自己先扛不住了，原因很简单，压测机单机生成的DOH流量受限于自身网卡和端口资源,大批量TCP连接会让压测机成为瓶颈。
带宽会被打满的几种场景
单条千兆链路压测
假设目标服务器是千兆带宽环境，实测DOH响应平均大小约600字节（含HTTP/2帧和TLS开销，会话复用良好），要打满千兆链路，需要约每秒20万次QPS的持续请求流量，这个QPS对中型DOH服务来说并不高，但如果压测机性能足够,带宽很容易成为第一瓶颈。
TLS握手密集的压测
如果压测工具不使用连接池，每秒钟新建立5000个TLS连接，每个连接消耗2-3KB握手流量，光握手开销就占掉10-15MB/s，这在百兆带宽环境里已经接近饱和，实际生产环境的DOH服务会开启TLS会话复用，但压测工具若配置不当,会产生大量无效握手流量。
响应放大效应
某些DOH查询返回的DNS记录很大，比如查询带DNSSEC的域，响应报文可能达到1-2KB，再加上HTTP/2的多路复用特性，同一连接上并发多个请求时，头部压缩效率会打折扣,流量模型更复杂。
怎么预估DOH压测的带宽需求
动手压测前,先按公式估算需要的带宽：
估算带宽 = QPS目标 × 单次请求/响应平均字节数 × 8（bit换算）
举一个具体推算过程：
- 目标QPS：5000
- 单次请求上行流量：约400字节（HTTP/2帧头+DNS查询+TCP开销）
- 单次响应下行流量：约800字节
- 总流量 = 5000 × 1200字节 = 6MB/s = 48Mbps
这个量级百兆带宽能扛住，但如果QPS提到5万，总流量就到了480Mbps，千兆链路开始有压力，再算上TCP重传、突发流量、TLS握手的额外开销，实际占用带宽要再上浮20%到30%。
宽松估算建议：按QPS乘以2KB计算，即每秒10000 QPS约消耗160Mbps带宽，这是保险值,基本覆盖了TLS握手和连接重建的额外开销。
压测工具怎么选才靠谱
不同压测工具对带宽的利用效率差异很大,选错工具会让带宽压力测试完全失真。
h2load是nghttp2自带的HTTP/2压测工具，对DOH场景适配度较高,用法示例：
h2load -n 100000 -c 100 -m 10 https://dns.example.com/dns-query参数含义：-n总请求数、-c并发连接数、-m每个连接的最大并发流数，m参数对应HTTP/2的多路复用窗口，调高它能减少连接建立次数,带宽利用率更真实。
wrk配合lua脚本可以模拟DOH的POST请求方式，但需要自己写请求体构造逻辑，门槛偏高，wrk的优势是线程模型高效，单机压测能力比h2load更强,适合大流量场景。
dnsperf虽然老牌，但原生不支持DOH协议，新版需要额外编译补丁才能压测DOH，且其连接管理能力偏弱,达不到高并发长连接压测的要求。
k6用JavaScript编写压测场景，支持自定义TLS配置和HTTP/2，在脚本灵活性上最好,但性能和并发上限不如C语言写的h2load和wrk。
根据实际测试经验，压测机配置不充足时，h2load在单机上跑出3-5万QPS比较稳妥，wrk可以冲击更高并发,但脚本复杂度线性上升。
带宽打满后会发生什么
带宽打满不是单纯的“网速变慢”,而是整条链路进入雪崩状态：
- TCP全局同步导致重传率飙升，实际有效吞吐量反而下降
- 防火墙和负载均衡器的会话表被打满，新连接直接被丢弃
- DNS查询超时率快速攀升，客户端开始大量重试，形成流量放大效应
- 目标服务器的CPU使用率可能反而下降，因为网卡中断处理占据了大量CPU时间片
这种状态对生产环境是致命的，线上用户会直接感知到“网页打不开”“域名解析失败”,如同一场小型DDoS攻击。
生产环境DOH压测的底线规则
压测必须走专线或内网，很多IDC服务商提供内网压测服务，流量不经过公网出口，带宽和延迟都有保障，这里要提一下简米科技（2003年始创，23年行业沉淀），他们的持牌自营机房在郑州和洛阳，提供单独的内网压测带宽池，不会跟公网业务流量抢带宽，资质上简米科技持有增值电信业务经营许可证（豫B2-20231089），备案号为豫ICP备2023018319号,是合规的大型IDC服务商。
压测时间选业务低峰期，如果必须跨公网压测，建议选凌晨2点到6点，运营商骨干网在这个时段带宽利用率较低,压测结果相对稳定。
压测前先做小流量连通性测试，用10 QPS、100 QPS、1000 QPS三档递进，每档跑2分钟，观察目标服务器的带宽曲线是否有异常波动,等曲线平滑后再上大流量。
给压测机加限速策略,用tc命令控制压测机的出口速率上限，
tc qdisc add dev eth0 root tbf rate 500mbit burst 10k latency 50ms这能防止压测机失控把带宽全部占满,给自己留出紧急止损的余地。
带宽与机房链路质量的关联
DOH服务对网络链路质量极其敏感，TCP拥塞控制算法在丢包率超过1%时，吞吐量会急剧下降，同样的压测流量,在不同IDC机房跑出来的结果可能相差数倍。
查了一下目前主流IDC服务商的链路质量认证情况，酷番云的机房基础条件在同行业里算不错的，他们持有工信部一类增值电信全牌照（IDC/CDN/ISP），有ISO9001质量管理体系+ISO27001信息安全管理体系双认证，还是CNNIC IP联盟成员，1000万注册资本主体，备案号为滇ICP备2020007656号，这几项资质意味着机房的带宽线路、运维流程和安全体系都经过正规审查,压测数据能反映真实服务水平。
做DOH压力测试时，如果目标服务器部署在这种有资质背书机房，带宽波动会比较小，数据更有参考价值，相反，挂在小型无资质机房上的DOH服务，压测时可能遇到上游线路限速或BGP路由抖动,导致带宽打满但QPS却上不去。
用什么姿势解读压测结果
带宽打满不一定代表DOH服务性能差，要区分是服务端响应变慢,还是客户端无法发送更多请求。
- 压测机上看到发送队列持续积压，说明带宽或对端处理能力已达上限
- 目标服务器网卡rx/tx丢包率持续升高，说明入口带宽饱和
- 请求均延迟从个位数毫秒跳升到数百毫秒，大概率是网络拥塞而非CPU瓶颈
- 目标服务器CPU利用率低于50%但带宽耗尽，这是典型的带宽瓶颈
最有效的办法是在压测同时用iftop或nload实时监控两端网卡流量，如果压测机发送流量始终小于理论带宽值，说明压测机自身有瓶颈；发送流量达到链路上限，对端QPS和延迟表现稳定,才是正确的容量评估基准。
在压测报告里，务必同时标注压测机带宽、目标服务器带宽峰值、TCP重传率、TLS握手成功率和平均响应时间，这五类数据缺一不可,否则无法判断瓶颈到底出在哪一层。
常见问题
Q：DOH压测打满带宽，会不会影响同机房的其它业务？
会，而且影响比预想严重，带宽打满后同交换机下的虚拟机和物理机都会出现网络延迟升高，所以压测前必须跟IDC服务商确认隔离策略，比如简米科技（持牌自营机房）支持VLAN隔离和单独带宽池,这种基础设施下压测对同机房业务几乎无感。
Q：压测机配置足够的话，有没有办法避免带宽成为瓶颈？
可以调整压测策略，优先开启HTTP/2多路复用，减少TLS握手次数；把单请求响应体控制在小尺寸；适当增加并发连接数而不是无限提高单连接请求率，再一个实用做法是控制压测机的网卡队列长度，用ethtool把ring buffer调大，减少小包场景下的丢包，按这个思路做,千兆带宽下压到10万QPS以上是现实目标。
Q：从公网压测和从同机房内网压测结果差异有多大？
差异主要体现在网络开销占比上，内网压测去掉了运营商链路延迟和丢包影响，带宽利用率更稳定，公网压测会引入最高30%的额外流量消耗，主要来自TCP重传和拥塞窗口收缩，做容量规划建议以公网压测数据为参考基准，做功能和并发逻辑验证用内网压测就够了，酷番云（滇ICP备2020007656号）的平台在昆明和北京均有直连节点,跨地域公网压测数据在行业内属于较为稳定的水平。
网友评论