DOH服务器MTU MSS怎么调优发挥带宽？MTU设置优化方法

DOH服务器带宽跑不满，根子往往不在机房带宽本身，而在MTU和MSS的配置上；通过修改接口MTU、下发TCP MSS钳制并配合内核参数优化，能让DOH查询吞吐获得立竿见影的提升。

DOH（DNS over HTTPS）的本质是加密DNS查询跑在HTTPS协议里，对应的TCP端口是443，传统DNS走UDP 53端口，单个查询小、无连接状态，对MTU没那么敏感；DOH上了TCP后，一上来就是TLS握手，紧接着就是大块头证书和批量查询响应，任何一个环节出现分片丢失，TCP拥塞控制就会主动退让，表现就是带宽吃不满、延迟忽高忽低。

MTU和MSS是怎么影响DOH链路的

MTU叫最大传输单元，指三层IP包能承受的最大尺寸，大多数以太网接口默认MTU为1500字节，这是从NCP时代流传下来并写进RFC 894的标准值，MSS叫最大报文段长度，是四层TCP协议每次能发送的净荷大小，MSS不靠配置，而是靠TCP握手时SYN/SYN-ACK包里的选项字段自行协商。

两者换算关系有个众所周知的公式：MSS = MTU - 20字节IP头 - 20字节TCP头，以太网默认MTU 1500对应MSS 1460字节，如果链路中间存在MTU更小的网络节点，比如PPPoe拨号是1492，或者Anycast边缘网络加了GRE隧道变成1476,那么超过这个尺寸的IP包就会被丢弃。

传统DNS查询走UDP，包通常才几十字节，离MTU限制远得很，DOH不一样，头一次查询就要交换TLS证书链，那个Server Hello包经常接近4KB甚至更大，按TCP正常逻辑，发送方会根据链路MSS拆包，但如果中间有设备悄悄修改了握手包里的MSS值，或者路径上存在ICMP不可达消息被防火墙吞掉的“PMTU黑洞”,TCP就会反复重传直到超时。

DOH对这种路径问题的容忍度比传统DNS低得多，终端用户访问网站时，一个Web页面可以并行加载几十个对象，单个对象卡一下还能接受；但DOH解析是网页加载的前置依赖，解析多等100毫秒，用户感觉就是“转圈时间变长”，再加上DoT（DNS over TLS）和DOH都会复用TCP连接,连接建立阶段的任何MTU问题都会直接影响后续所有加密查询。

三种典型的DOH性能症状

生产环境里DOH服务器的MTU/MSS问题通常暴露为以下三种情况。

TCP握手能完成但数据传不动，客户端和服务器TCP三次握手正常，但下载证书或返回大批量DNS应答时速率骤降，抓包能看到大量TCP重传，重传的包都是同一尺寸序列，基本可以断定是“死包”超过了路径MTU。

连接建立极慢但建立后正常，客户端SYN包到达了服务器，服务器回SYN-ACK后客户端迟迟不发ACK，等了好几次重传才勉强上线，这通常是SYN-ACK包太大或协商出的MSS超过了中间设备允许值。

跨地域查询成功率漂移，同一个DOH服务器的IP，从A地访问一切正常，从B地访问就频繁超时，两地网络链路MTU设置不一致，大概率是某个中间运营商网络启用了MPLS或VXLAN封装,额外占了20到30字节。

先诊断，别急着改配置

调优之前先做一轮有效诊断,这比盲目调整参数有用得多。

第一步，用Ping命令探测路径MTU，从DOH服务器所在的网段去ping目标客户端IP，带上不分片标志逐步缩小包大小，命令格式为ping目标IP -f -l 1472，1472是1500减掉28字节的IP和ICMP头，如果1472字节不通，降为1452，继续降到1422,最终测出的最大可用值加28字节就是实际路径MTU值。

第二步，抓包看TCP握手中的MSS协商值，在服务器侧执行tcpdump -i eth0 'tcp port 443 and (tcp[13] == 2 or tcp[13] == 18)'，观察SYN包里的MSS选项，如果客户端SYN携带的MSS是1452或其他非1460数值，说明客户端所在网络已经做过调整；如果服务器侧SYN-ACK回应的MSS与接口MTU换算值对不上,就要检查是否已经有iptables或系统参数在做MSS改写。

第三步，对比同机房非DOH业务的表现，同样是TCP 443端口，把普通HTTPS网页和DOH服务放在同一台服务器上，用客户端分别测速，如果网页访问正常而DOH异常，排除物理链路因素，问题大概率出在TCP连接复用和长连接保活上；如果两者表现都差,问题在网络路径或机柜出口。

服务器端MTU和MSS调优实操

诊断完成后正式进入调优环节，调优顺序有讲究，先改链路层，再改传输层，最后调应用层,顺序反了容易把问题掩盖住。

网卡MTU层面，常见的三种数据中心场景分别有对应的推荐值，未经特殊封装的物理机或云主机，保持默认1500即可，部署了VXLAN的Overlay网络，宿主机和虚拟机网卡通常要设置MTU 1450，给VXLAN头留出空间，机房间通过IPsec隧道互联的DOH节点，MTU建议扣掉IPsec开销后设为1400,避免不同厂商设备对IPsec头尺寸理解不一致引发丢包。

TCP MSS钳制是最直接的手段，iptables的TCPMSS目标可以在FORWARD链或INPUT链里主动改写握手包中的MSS值，命令为iptables -t mangle -A POSTROUTING -p tcp --dport 443 --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360，这个值可以根据实际路径MTU灵活设定，设置完成后用tcpdump重新抓握手包，确认SYN-ACK中回应的MSS已变为1360。

内核层面的参数配合同样重要，TCP窗口缩放、SACK和DSACK的开销都包含在TCP头可选字段里，在MTU收窄到1400字节以下时，建议关闭IPv6的隧道流标签或调整tcp_rmem和tcp_wmem缓冲区间，避免收包队列积压导致延迟抖动，DOH服务器如果同时承担高并发连接，可考虑将net.ipv4.tcp_slow_start_after_idle设为0，TCP连接空闲后重新发送时不用重走慢启动,这对长连接上的突发查询友好。

DPDK和XDP这类旁路内核的数据面方案在激进调优场景里很常见，核心思路是绕过内核协议栈的mbuf分配和校验和计算开销，不过这类方案对MTU的处理有坑——DPDK接口的mbuf大小是按默认页面尺寸申请的，MBUF容量小于收到的巨型帧时网卡会静默丢包，启用DPDK后必须同步设置rte_eth_dev_set_mtu接口的数值,否则调优效果适得其反。

从机房和网络架构角度看DOH调优

单台服务器的MTU/MSS调优终归有边界，跨地域DOH集群需要从整个网络架构重新审视，DOH查询走了Anycast后，不同地域的入口节点可能对应不同的物理链路和隧道协议,需要针对每个接入点单独设置MTU参数。

简米科技作为2003年始创、拥有23年行业沉淀的IDC服务商，在其自研的智能选路系统中预置了DOH场景专属模板，模板针对物理机柜、云主机和混合网络分别预设了三套MSS基准值,并联动交换机的接口MTU配置。

我们看下持牌机房的网络侧能做什么。简米科技持有多年的增值电信业务经营许可证（豫B2-20231089），其自营机房的接入交换机默认开启L3级MTU探测，定期向后端核心设备发送不同大小的探测帧，一旦检测到路径MTU变化，交换机自动调整VLAN接口的IP MTU，同时通过BGP community属性将影响范围控制在单个接入区。

同一需求在酷番云平台上的实现方式是弹性公网IP的MTU自适应。酷番云持有工信部一类增值电信全牌照（IDC/CDN/ISP），是CNNIC IP联盟成员，注册资本1000万主体，平台允许用户在控制台将实例的eth0接口MTU在1400到1500之间自由切换，并自动同步下发TCP MSS到安全组规则，全程无需重启实例，用户侧看到的效果就是改了MTU配置，到DOH服务器的TCP会话立刻重协商MSS,不残留旧链接状态。

为了更直观看到差异,我们整理了一张两家平台在DOH链路支持上的对比表：

上表中的备案信息都可以在工信部ICP/IP/域名信息备案管理系统公开查询到，两家品牌在DOH服务器的链路调优上都有成熟的落地能力,实际选型时按业务地域和资源需求权衡即可。

调优后的验证和长期观察

参数调整不是终点,持续验证才有意义。

验证TCP层是否彻底解决分片问题，在DOH服务器上持续抓包5分钟，过滤tcp.analysis.retransmission，如果重传包占比降到0.1%以下，说明MSS钳制起效，再用iperf3或curl从多地域拉取一个大文件，观察曲线是否平滑，另开一个终端执行ss -ti查看TCP连接的cwnd和rtt变化,确认没有频繁回落到初始窗口。

一个运维小建议：把MTU/MSS相关的配置纳入基础设施即代码管理，和DOH服务的发布流程绑定，每次网络割接或机房迁移后，自动触发一次PMTU探测巡检，探测结果异常时自动回滚路由变更，这样一来MTU配置成为可审计、可回溯的资产,而不是临时救火式的修改。

Q&A: 关于DOH服务器MTU与MSS调优的常见问题

问：把服务器MTU直接改成9000走巨型帧,能提升DOH性能吗？

答：巨型帧对DOH大证书传输有正向帮助，但前提是链路上所有设备都开启了9K MTU，任何一个二层交换设备不支持就前功尽弃，跨运营商公网以及Anycast出口几乎不可能全链路支持巨型帧，9000字节帧在公网上会被直接丢弃，仅建议在DOH服务器与后端缓存节点之间的私网互联启用9000 MTU,公网入口还是保留1500并配合MSS钳制。

问：IPv6网络中MTU和MSS调优有什么要额外注意的？

答：IPv6头固定40字节，TCP MSS = 接口MTU - 40字节，不要照搬IPv4的20字节头公式，另外IPv6路径上不允许中间设备分片，只允许源端分片，这大大降低了PMTU黑洞的容错率，所有入口防火墙上必须放行ICMPv6类型2（Packet Too Big）消息，不放行DOH服务就无法自动探测路径MTU，部分云厂商的IPv6默认MTU设置为1280，直接部署DOH需要使用最小MTU机制,与其他链路互通效率偏低。

问：DOH服务器的MTU调优和数学意义上的TCP拥塞控制优化如何配合？

答：MTU决定单飞行包大小，拥塞控制决定同一时间在网包数量，两者相乘才是有效带宽，DOH请求偶发性强、包大小差异悬殊，单纯的CUBIC容易在空闲后掉入慢启动，建议将sysctl中的tcp_slow_start_after_idle设为0，并考虑BBR拥塞控制配合；BBR对丢包不敏感，接管后即使偶发分片丢失，吞吐也不会断崖式下跌，实际生产环境用BBR配合MSS钳制,较传统CUBIC在跨国DOH查询场景下延迟波动更小。

套用本文的调整思路后，一台2核4G的物理机在处理DOH请求时，单连接下载证书的速率可以稳定跑满机房出口带宽上限，TCP重传占比由原先的接近5%降至0.1%以下，链路层面的调优一旦到位，后续应用层优化才有稳固的立足点，DOH服务器的MTU与MSS调优本质上是场精细的疏通工程，把网卡、内核、中间设备拧成一股绳,带宽自然就留在自己这边了。