搞运维的这几年测网络带宽这件事我一直觉得是“看起来简单、做起来闹心”的活。尤其在 Windows 服务器之间互拷数据慢、业务反馈“系统卡”的时候网络到底有没有跑满、瓶颈是网卡还是防火墙、是多线程没开还是 TCP 窗口太小没有趁手的工具基本只能靠猜。后来我换成 NTTTCP 做网络性能测试思路一下子清晰了很多。NTTTCP 是微软开源的命令行网络性能测试工具专门用来压测带宽和评估网络质量在 Windows 和 Linux 上都能跑。相比 iperf3它在 Windows 平台的适配更“原汁原味”线程模型清楚、参数设计直白最重要的是很多人容易忽略的 TCP 窗口调优它也直接暴露成参数这点在排查高带宽时延网络时特别有用。如果你也在 Windows 环境里做网络验收、带宽排查、云服务器到本地机房的链路测试这篇文章就是按我实际使用经验写的照着敲命令就能用。1. 为什么我推荐用 NTTTCP 而不是别的工具1.1 NTTTCP 能做什么、适合谁NTTTCP 的核心作用是制造流量把网络链路“打满”然后告诉你实际能跑多少带宽。它不像 ping 那样只测连通性和时延也不像复制大文件那样受磁盘性能干扰NTTTCP 直接用内存缓冲发包专门考验网卡、交换机、网线、TCP/IP 协议栈这几层的真实能力。它特别适合这几类场景机房服务器之间做带宽验收比如新到的两台千兆/万兆服务器想确认网络是不是跑得到标称速率。上云之后的网络体检云主机和本地服务器之间的带宽经常被限速用 NTTTCP 能快速测出实际吞吐。业务反馈“上传慢”“同步慢”需要区分网络瓶颈和应用瓶颈的时候NTTTCP 可以先把网络底数摸清。网络设备调整后MTU、巨型帧、网卡卸载验证效果前后对比数据最直接。坦白说我最早用这类工具是从 iperf 开始的但后来发现 iperf3 在 Windows 上要么需要 Cygwin 环境要么版本不统一参数行为也有差异。NTTTCP 是微软官方出品Windows 上的支持和文档都更友好跑起来省很多事。1.2 和 iperf3 对比选型理由我知道提到网络测速很多人第一反应是 iperf3。iperf3 确实是个好工具跨平台能力强Linux 上用的很广。但我做 Windows 环境测试时NTTTCP 有几个更顺手的地方对比维度NTTTCPiperf3Windows 原生支持好直接跑 exe无依赖一般需要额外环境或找编译版本多线程模型每个 -P 参数对应一个独立流可跨 CPU 调度也有多线程但单流性能优化更偏重TCP 窗口控制-W 参数直接控制窗口分摊直观需要额外调系统参数统计输出结果清晰可输出 XML 方便解析终端显示友好但结构化输出需要额外参数Linux 支持支持需要 .NET 环境原生支持更成熟选型建议也很简单如果你主要测 Linux 服务器之间的网络用 iperf3 完全没问题如果你的场景是 Windows 服务器、混合环境往 Windows 侧重、或者需要详细的多线程带宽数据NTTTCP 是更省心的选择。两边都是免费工具没必要二选一环境不同换着用就好。2. 部署与基础使用5 分钟跑通一次测速2.1 Windows 环境下载与准备NTTTCP 的发布包在微软的 GitHub 仓库里搜索 microsoft/ntttcp 就能找到。下载的时候注意选对应架构的 release 包我一般下载解压版里面直接是 ntttcp.exe不需要安装拷贝到测试机器就可以用。下载之后有几个小建议都是踩过坑之后总结的把 ntttcp.exe 放到一个固定目录比如 C:\tools\ntttcp方便后面写脚本调用。测试机和目标机都要放一份版本尽量保持一致避免不同版本参数行为差异导致结果失真。运行前用管理员权限打开命令行。虽然普通权限也能跑但管理员权限可以避免一些系统层面的限制尤其是调整 TCP 参数时。如果系统防火墙是开启的先别急着全部关闭等第一次连接失败再排查也不迟。不过为了测试方便我一般直接放行 NTTTCP 使用的端口这个在第 5 节详细写。2.2 Linux 环境安装方法Linux 上跑 NTTTCP 稍微多一步因为它是基于 .NET 的需要先确认环境里有 .NET 运行时。我用的是 Ubuntu 20.04/22.04安装思路是先在测试机的 Windows 侧下载好 Linux 版压缩包再传到 Linux 机器解压或者直接在 Linux 上连 GitHub 下载。大致步骤是这样检查 .NET 环境运行dotnet --info如果没有则需要先安装对应版本的 .NET SDK 或运行时。下载 NTTTCP Linux 包解压后目录里会有 ntttcp 可执行文件。给文件加执行权限chmod x ntttcp。简单验证版本./ntttcp -h能显示帮助就说明环境没问题。注意Linux 版跑起来之后输出格式和 Windows 版基本一致但个别参数比如网卡绑定可能需要用系统工具配合这个不影响核心测速功能。2.3 第一轮测速服务端 客户端最小命令网络测试的原理是一端做接收服务端一端做发送客户端NTTTCP 的角色就是通过-r和-s参数区分的。我习惯把“接收端”称为服务端“发送端”称为客户端。服务端接收端启动命令ntttcp -r -m 1,0,192.168.1.10 -P 8 -t 60客户端发送端启动命令ntttcp -s -m 1,0,192.168.1.10 -P 8 -t 60两个命令拆开解释-r当前机器作为接收端。-s当前机器作为发送端。-m 1,0,IP这里的三元组含义是“sender 数量, receiver 数量, 目标 IP”。服务端填自己的 IP客户端填服务端的 IP测试建立连接时会以这个 IP 为准。-P 8并发连接数也就是同时开 8 个线程各自发数据后面详细讲。-t 60测速持续时间单位秒。跑完之后客户端会打印吞吐结果服务端也会打印一份统计。第一次跑通之后你会看到类似这样的输出Total bytes: 5368709120 Throughput: 445.57 Mbps这个 445 Mbps 就是当前链路的实际带宽。如果测试双方是千兆网卡这个数字明显偏低那就需要排查是不是网卡协商速率不对、网线质量问题、或者 TCP 窗口没调好。后面几节讲的就是这些排查思路。3. 核心参数解析从“能跑”到“会调”这一节是 NTTTCP 的精华也是我实际测试中反复验证过的关键参数。很多人测速就是照着网上的命令复制粘贴结果数据不理想但不知道改哪个参数原因就是对参数背后的逻辑不清楚。3.1 线程数与并发模型-P 参数背后的原理-P是最直观也最容易被误用的参数。它指定并发连接数也就是同时开多少个 TCP 流来传输数据。默认情况下 NTTTCP 会使用 CPU 核数的 4 倍作为并发数所以如果机器是 4 核默认就是 16 条流。为什么需要多线程因为单条 TCP 流的吞吐受网络时延和 TCP 窗口限制。用一个简单类比TCP 传输就像水管注水窗口大小决定了水管里能存多少水时延决定了水从这头到那头要多久。如果“水管容量 × 每秒来回次数”达不到网卡带宽单条流就跑不满。多线程就是开多根水管并行注水用数量换吞吐。我在实际测试中的经验千兆网络环境-P 4到-P 8基本就能打满。万兆网络环境建议从-P 16开始不够再加到-P 32。线程数不是越大越好。开线程需要 CPU 参与如果线程太多把 CPU 跑满反而会因为调度开销导致吞吐下降。我遇到过 64 线程比 32 线程还慢的情况就是 CPU 成了瓶颈。所以调 -P 的正确姿势是先看 CPU 核数从核数乘以 4 开始逐步翻倍测试取吞吐最高的值。顺便用任务管理器或者top确认 CPU 占用如果 CPU 已经接近 100%说明瓶颈在 CPU 而不是网络再加线程没意义。3.2 传输时间与缓冲区-t、-l、-rb、-sb-t指定测试持续时间。我建议至少 30 秒最好 60 秒以上。原因很简单短时间测试容易受到 TCP 慢启动的干扰前几秒吞吐是逐步爬升的测 10 秒可能刚爬上去就结束了数据偏低。另外长时间测试也能暴露出散热、限速策略等问题。-l指定发送缓冲区大小默认是 64KB。这个参数影响单次发送的数据块大小对大带宽场景有一定影响。我的经验是默认值在大多数场景已经够用不需要频繁调整。-rb和-sb分别指定接收缓冲区和发送缓冲区的 socket 大小。有些系统默认的 socket 缓冲太小限制了 TCP 窗口能够申请的空间这时候就需要调大。我遇到过一个典型的场景默认参数测出来只有 300Mbps把-rb 1M -sb 1M加上之后吞吐直接翻倍到 700Mbps。一个更重要的知识点是-l的缓冲区大小和吞吐量之间的关系。理论上吞吐量 缓冲区大小 / 网络时延。如果时延是 1ms缓冲区是 64KB理论极限只有 64MB/s 也就是 512Mbps。所以在高带宽低时延的局域网里缓冲区影响不大但在跨机房、跨城的网络里缓冲区大小直接决定了你能跑多快。这也是为什么跨地域测速时-l或窗口相关参数要跟着调整。3.3 TCP 窗口与带宽时延积-W 参数-W是我觉得 NTTTCP 最值得单独讲的一个参数。它控制 TCP 窗口的大小原理是让“在途数据量”匹配“带宽 × 时延”的乘积也就是常说的 BDP带宽时延积。举个例子便于理解假设链路带宽是 1000Mbps即约 125MB/s双向时延是 10ms。那么链路里最多能“塞进”的数据量是 125MB/s × 0.01s 1.25MB。如果 TCP 窗口小于这个值发送端每发完一窗数据就要停下来等确认带宽自然就浪费了。NTTTCP 的-W参数不是直接指定窗口大小字节数而是指定一个倍数作用是分配默认的 TCP 窗口空间。我测试大带宽场景时的做法是先不加这个参数测一轮再用-W 2甚至-W 4测一轮对比吞吐变化。我踩过的一个坑有一次测两台服务器之间的性能1000Mbps 链路只能跑到 200Mbps第一反应是网线问题换线、换交换机端口都没解决。后来想到可能是窗口太小加上-W 2之后吞吐瞬间到了 900Mbps 以上。那次之后我每次做跨交换机、跨路由器的长距离测试都会先跑一组带-W的对照组。3.4 UDP 测试与统计输出-u、-m 参数精讲UDP 测试是很多人忽略但特别有用的功能。TCP 是可靠传输有重传机制网络一旦有丢包TCP 会自动降速重传所以 TCP 测出来的速率是“可靠速率”。但有些场景比如视频流、语音流用的是 UDP丢包了也不重传这时候需要单独测 UDP 的能力和丢包率。UDP 测试命令在两端都加-u即可# 服务端 ntttcp -r -u -m 1,0,192.168.1.10 -P 4 -t 30 # 客户端 ntttcp -s -u -m 1,0,192.168.1.10 -P 4 -t 30UDP 测试的结果里会多出丢包率数据这个在设计实时音视频系统时特别重要。我做过一个线上音频卡顿排查TCP 测速一切正常UDP 测出来丢包率 5%再往下查发现是交换机端口 buffering 不够问题一下子就定位了。-m参数除了指定 IP 三元组之外还承担统计模式的功能。最常用的是-m 1表示每秒输出一条统计信息打印每个时间点上的吞吐变化。这个对观察吞吐是否稳定、是否存在周期性抖动很有帮助。多客户端场景还会用到-sync来同步各客户端的时间基准不过这个属于进阶用法大家基础掌握之后按需深入即可。4. 结果怎么看带宽、CPU、丢包率的数据解读4.1 测速结果字段含义NTTTCP 跑完之后终端会打印一大段统计信息。新手很容易被一堆数字吓到其实核心就几个字段Total bytes传输的总字节数可以理解为测试期间总共发了多少数据。Throughput平均吞吐量单位 Mbps 或 Gbps这是网络性能最直接的指标。CPU测试期间 CPU 的使用率如果接近 100% 说明瓶颈可能在主机本身。Errors/Packet lossUDP 测试时出现这个字段代表丢包情况。在读结果的时候我一直强调一个思路不要只看吞吐数字要结合 CPU 和丢包一起看。吞吐高、CPU 低网络状态理想还有余量。吞吐低、CPU 高瓶颈在主机 CPU比如网卡卸载功能没开、驱动有问题。吞吐低、CPU 低大概率是网络本身受限比如中间设备限速、链路质量差、TCP 窗口不够。这种交叉判断的思路比单纯套用“测出 XXX 就是好”的结论要靠谱得多。因为网络路径上任何一段都可能成为瓶颈只看一头很难定位问题。4.2 通过 XML 输出做自动化统计如果只是偶尔测一次看终端输出就够了。但如果你的工作是定期做网络巡检手动记录数据不仅效率低还容易出错这时候可以开启 XML 输出。在命令里加一个-xml参数同时指定输出文件名ntttcp -s -m 1,0,192.168.1.10 -P 8 -t 60 -xml result.xml生成的文件里包含完整的测试参数、吞吐数据和统计信息之后写个脚本定时解析就能自动生成趋势报表。我现在的网络巡检脚本就是靠这个功能每天早上自动跑一次带宽测试把结果写入数据库出问题时直接翻历史曲线谁改了什么配置导致网络波动一目了然。XML 输出的另一个好处是标准统一多人协作时不会出现“我看终端你存截图”这种对不上的情况。团队内部如果需要对网络性能做量化考核这算是一个比较省事的落地方案。4.3 实测案例千兆网络、Windows 到 Linux 的测试记录分享一组我最近做的真实测试帮助大家对“什么样的结果是正常的”有个直观概念。测试环境一台 Windows Server 2019、一台 Ubuntu 22.04通过千兆交换机互联网卡自适应协商均为 1000Mbps。第一轮使用默认参数# Windows 服务端 ntttcp -r -m 1,0,192.168.1.10 -t 30 # Linux 客户端 ./ntttcp -s -m 1,0,192.168.1.10 -t 30结果是 510Mbps。乍一看千兆网络跑一半不高不低但既然协商速率是 1000Mbps这个值肯定没达标。第二轮加上 8 线程# Windows 服务端 ntttcp -r -m 1,0,192.168.1.10 -P 8 -t 30 # Linux 客户端 ./ntttcp -s -m 1,0,192.168.1.10 -P 8 -t 30结果到了 940Mbps。这说明第一轮的瓶颈就是单线程流上不去不是网卡或交换机的硬件问题。第三轮测试 UDP# Windows 服务端 ntttcp -r -u -m 1,0,192.168.1.10 -P 8 -t 30 # Linux 客户端 ./ntttcp -s -u -m 1,0,192.168.1.10 -P 8 -t 30吞吐稳定在 950Mbps丢包率 0%说明底层链路相当干净。这个实战过程其实很典型先确认硬件协商速率再用 TCP 单流测出“下限”加并发线程测出“上限”最后用 UDP 确认丢包和链路质量。一套流程下来网络的健康度基本心里有数了。5. 实战中的坑与排查技巧工具用多了自然会遇到各种问题。这一节的内容都是我实际踩过坑之后总结出来的希望对大家有帮助。5.1 防火墙导致连接失败最常见的问题是一端启动后另一端连接超时或直接报错。十有八九是防火墙拦截了流量。NTTTCP 默认使用的端口范围比较固定最简单的办法是在两端防火墙里放行对应端口。两种处理方式测试环境图省事直接把防火墙暂时关闭。但生产环境不建议这么做哪怕只是短暂的测试窗口。更稳妥的方式只放行 NTTTCP 所用的端口范围。如果使用默认端口参考官方文档中提到的 TCP/UDP 端口范围在防火墙入站规则里加一条允许规则。我个人的习惯是提前写好放行端口的命令放到测试脚本里测完再删掉规则。这样既不影响测试也保留了生产环境的防火墙策略。5.2 性能瓶颈的快速定位当测出的带宽明显低于预期时先别急着怪网线或者交换机按下面这个顺序排查基本能覆盖 90% 的情况先看网卡协商速率是不是真的协商到千兆或万兆。我遇到过好几次思科交换机端口配置问题导致协商在百兆的情况这种情况换线是没用的。看 CPU 占用。如果客户端或服务端 CPU 已经跑满优先检查网卡 RSS、卸载功能是否开启。看 TCP 窗口。加上-W 2或调大缓冲区再测一次排除窗口限制。看是否中间链路限速。如果加了线程还是上不去可能是交换机端口限速或运营商策略这个只能找网络管理员确认。这套顺序的核心思路是从“物理层 → 系统层 → 协议层 → 策略层”逐层排查每一步都有明确的数据支撑不会瞎猜。5.3 多版本混用问题NTTTCP 版本迭代会带来参数变化如果服务端和客户端版本差别太大可能出现参数不兼容、统计结果异常之类的奇怪问题。我的建议是测试前花一分钟确认两端版本一致尤其是团队多人协作时把工具包直接统一放到共享目录减少版本漂移带来的不确定性。另外NTTTCP 在 Windows 和 Linux 的发布节奏不完全同步跨平台测试时以功能匹配为准不一定要追求版本号完全一致但核心参数行为最好在同一次测试中固定下来。5.4 需要记住的几个注意点最后分享几个容易被忽略、但实际影响很大的细节测试前先关掉其他网络大流量应用。有一次我测速结果怎么都不对最后发现另一台服务器正在跑备份任务占了大半带宽。巨型帧Jumbo Frame要两端同时开启或同时关闭。只开一端会导致分片吞吐不升反降。虚拟机环境下测试结果会受宿主机影响。同一台宿主机上的两台虚拟机互测性能上限通常是虚拟交换机的能力数值会比物理机测试低不少。测试时长不要低于 30 秒。短时测试数据波动大尤其是 TCP 慢启动特性影响明显结果代表不了稳定带宽。多次测试取平均值。网络本身有波动单次测试可能运气好也可能运气差至少跑 3 轮取中间值或平均值再下结论。结尾就我自己的使用体感来说NTTTCP 是那种“上手不難、用精不易”的工具。刚开始照着命令跑一遍能拿到一个吞吐数字这只是入门真正的价值在于把线程数、缓冲区、TCP 窗口这些参数和数据背后的含义串起来遇到带宽不达标时能快速定位是主机的问题、网络的问题、还是参数配置的问题。我现在的日常工作里NTTTCP 基本是 Windows 环境网络排查的第一板斧凡是涉及“能不能跑满带宽”“链路质量怎么样”的疑问先拉出来测一轮再说。如果你也在做类似的测试最实用的建议是建一个简单的测试记录表把每次测试的环境、参数、结果和当时的变更都记下来。用不了几次你就会发现历史对比往往比单次测试更能说明问题。这个工具本身不复杂真正复杂的网络环境里经验就是这么一点一滴攒下来的。 NTTTCP网络性能测试实战：从参数调优到带宽瓶颈定位
搞运维的这几年测网络带宽这件事我一直觉得是“看起来简单、做起来闹心”的活。尤其在 Windows 服务器之间互拷数据慢、业务反馈“系统卡”的时候网络到底有没有跑满、瓶颈是网卡还是防火墙、是多线程没开还是 TCP 窗口太小没有趁手的工具基本只能靠猜。后来我换成 NTTTCP 做网络性能测试思路一下子清晰了很多。NTTTCP 是微软开源的命令行网络性能测试工具专门用来压测带宽和评估网络质量在 Windows 和 Linux 上都能跑。相比 iperf3它在 Windows 平台的适配更“原汁原味”线程模型清楚、参数设计直白最重要的是很多人容易忽略的 TCP 窗口调优它也直接暴露成参数这点在排查高带宽时延网络时特别有用。如果你也在 Windows 环境里做网络验收、带宽排查、云服务器到本地机房的链路测试这篇文章就是按我实际使用经验写的照着敲命令就能用。1. 为什么我推荐用 NTTTCP 而不是别的工具1.1 NTTTCP 能做什么、适合谁NTTTCP 的核心作用是制造流量把网络链路“打满”然后告诉你实际能跑多少带宽。它不像 ping 那样只测连通性和时延也不像复制大文件那样受磁盘性能干扰NTTTCP 直接用内存缓冲发包专门考验网卡、交换机、网线、TCP/IP 协议栈这几层的真实能力。它特别适合这几类场景机房服务器之间做带宽验收比如新到的两台千兆/万兆服务器想确认网络是不是跑得到标称速率。上云之后的网络体检云主机和本地服务器之间的带宽经常被限速用 NTTTCP 能快速测出实际吞吐。业务反馈“上传慢”“同步慢”需要区分网络瓶颈和应用瓶颈的时候NTTTCP 可以先把网络底数摸清。网络设备调整后MTU、巨型帧、网卡卸载验证效果前后对比数据最直接。坦白说我最早用这类工具是从 iperf 开始的但后来发现 iperf3 在 Windows 上要么需要 Cygwin 环境要么版本不统一参数行为也有差异。NTTTCP 是微软官方出品Windows 上的支持和文档都更友好跑起来省很多事。1.2 和 iperf3 对比选型理由我知道提到网络测速很多人第一反应是 iperf3。iperf3 确实是个好工具跨平台能力强Linux 上用的很广。但我做 Windows 环境测试时NTTTCP 有几个更顺手的地方对比维度NTTTCPiperf3Windows 原生支持好直接跑 exe无依赖一般需要额外环境或找编译版本多线程模型每个 -P 参数对应一个独立流可跨 CPU 调度也有多线程但单流性能优化更偏重TCP 窗口控制-W 参数直接控制窗口分摊直观需要额外调系统参数统计输出结果清晰可输出 XML 方便解析终端显示友好但结构化输出需要额外参数Linux 支持支持需要 .NET 环境原生支持更成熟选型建议也很简单如果你主要测 Linux 服务器之间的网络用 iperf3 完全没问题如果你的场景是 Windows 服务器、混合环境往 Windows 侧重、或者需要详细的多线程带宽数据NTTTCP 是更省心的选择。两边都是免费工具没必要二选一环境不同换着用就好。2. 部署与基础使用5 分钟跑通一次测速2.1 Windows 环境下载与准备NTTTCP 的发布包在微软的 GitHub 仓库里搜索 microsoft/ntttcp 就能找到。下载的时候注意选对应架构的 release 包我一般下载解压版里面直接是 ntttcp.exe不需要安装拷贝到测试机器就可以用。下载之后有几个小建议都是踩过坑之后总结的把 ntttcp.exe 放到一个固定目录比如 C:\tools\ntttcp方便后面写脚本调用。测试机和目标机都要放一份版本尽量保持一致避免不同版本参数行为差异导致结果失真。运行前用管理员权限打开命令行。虽然普通权限也能跑但管理员权限可以避免一些系统层面的限制尤其是调整 TCP 参数时。如果系统防火墙是开启的先别急着全部关闭等第一次连接失败再排查也不迟。不过为了测试方便我一般直接放行 NTTTCP 使用的端口这个在第 5 节详细写。2.2 Linux 环境安装方法Linux 上跑 NTTTCP 稍微多一步因为它是基于 .NET 的需要先确认环境里有 .NET 运行时。我用的是 Ubuntu 20.04/22.04安装思路是先在测试机的 Windows 侧下载好 Linux 版压缩包再传到 Linux 机器解压或者直接在 Linux 上连 GitHub 下载。大致步骤是这样检查 .NET 环境运行dotnet --info如果没有则需要先安装对应版本的 .NET SDK 或运行时。下载 NTTTCP Linux 包解压后目录里会有 ntttcp 可执行文件。给文件加执行权限chmod x ntttcp。简单验证版本./ntttcp -h能显示帮助就说明环境没问题。注意Linux 版跑起来之后输出格式和 Windows 版基本一致但个别参数比如网卡绑定可能需要用系统工具配合这个不影响核心测速功能。2.3 第一轮测速服务端 客户端最小命令网络测试的原理是一端做接收服务端一端做发送客户端NTTTCP 的角色就是通过-r和-s参数区分的。我习惯把“接收端”称为服务端“发送端”称为客户端。服务端接收端启动命令ntttcp -r -m 1,0,192.168.1.10 -P 8 -t 60客户端发送端启动命令ntttcp -s -m 1,0,192.168.1.10 -P 8 -t 60两个命令拆开解释-r当前机器作为接收端。-s当前机器作为发送端。-m 1,0,IP这里的三元组含义是“sender 数量, receiver 数量, 目标 IP”。服务端填自己的 IP客户端填服务端的 IP测试建立连接时会以这个 IP 为准。-P 8并发连接数也就是同时开 8 个线程各自发数据后面详细讲。-t 60测速持续时间单位秒。跑完之后客户端会打印吞吐结果服务端也会打印一份统计。第一次跑通之后你会看到类似这样的输出Total bytes: 5368709120 Throughput: 445.57 Mbps这个 445 Mbps 就是当前链路的实际带宽。如果测试双方是千兆网卡这个数字明显偏低那就需要排查是不是网卡协商速率不对、网线质量问题、或者 TCP 窗口没调好。后面几节讲的就是这些排查思路。3. 核心参数解析从“能跑”到“会调”这一节是 NTTTCP 的精华也是我实际测试中反复验证过的关键参数。很多人测速就是照着网上的命令复制粘贴结果数据不理想但不知道改哪个参数原因就是对参数背后的逻辑不清楚。3.1 线程数与并发模型-P 参数背后的原理-P是最直观也最容易被误用的参数。它指定并发连接数也就是同时开多少个 TCP 流来传输数据。默认情况下 NTTTCP 会使用 CPU 核数的 4 倍作为并发数所以如果机器是 4 核默认就是 16 条流。为什么需要多线程因为单条 TCP 流的吞吐受网络时延和 TCP 窗口限制。用一个简单类比TCP 传输就像水管注水窗口大小决定了水管里能存多少水时延决定了水从这头到那头要多久。如果“水管容量 × 每秒来回次数”达不到网卡带宽单条流就跑不满。多线程就是开多根水管并行注水用数量换吞吐。我在实际测试中的经验千兆网络环境-P 4到-P 8基本就能打满。万兆网络环境建议从-P 16开始不够再加到-P 32。线程数不是越大越好。开线程需要 CPU 参与如果线程太多把 CPU 跑满反而会因为调度开销导致吞吐下降。我遇到过 64 线程比 32 线程还慢的情况就是 CPU 成了瓶颈。所以调 -P 的正确姿势是先看 CPU 核数从核数乘以 4 开始逐步翻倍测试取吞吐最高的值。顺便用任务管理器或者top确认 CPU 占用如果 CPU 已经接近 100%说明瓶颈在 CPU 而不是网络再加线程没意义。3.2 传输时间与缓冲区-t、-l、-rb、-sb-t指定测试持续时间。我建议至少 30 秒最好 60 秒以上。原因很简单短时间测试容易受到 TCP 慢启动的干扰前几秒吞吐是逐步爬升的测 10 秒可能刚爬上去就结束了数据偏低。另外长时间测试也能暴露出散热、限速策略等问题。-l指定发送缓冲区大小默认是 64KB。这个参数影响单次发送的数据块大小对大带宽场景有一定影响。我的经验是默认值在大多数场景已经够用不需要频繁调整。-rb和-sb分别指定接收缓冲区和发送缓冲区的 socket 大小。有些系统默认的 socket 缓冲太小限制了 TCP 窗口能够申请的空间这时候就需要调大。我遇到过一个典型的场景默认参数测出来只有 300Mbps把-rb 1M -sb 1M加上之后吞吐直接翻倍到 700Mbps。一个更重要的知识点是-l的缓冲区大小和吞吐量之间的关系。理论上吞吐量 缓冲区大小 / 网络时延。如果时延是 1ms缓冲区是 64KB理论极限只有 64MB/s 也就是 512Mbps。所以在高带宽低时延的局域网里缓冲区影响不大但在跨机房、跨城的网络里缓冲区大小直接决定了你能跑多快。这也是为什么跨地域测速时-l或窗口相关参数要跟着调整。3.3 TCP 窗口与带宽时延积-W 参数-W是我觉得 NTTTCP 最值得单独讲的一个参数。它控制 TCP 窗口的大小原理是让“在途数据量”匹配“带宽 × 时延”的乘积也就是常说的 BDP带宽时延积。举个例子便于理解假设链路带宽是 1000Mbps即约 125MB/s双向时延是 10ms。那么链路里最多能“塞进”的数据量是 125MB/s × 0.01s 1.25MB。如果 TCP 窗口小于这个值发送端每发完一窗数据就要停下来等确认带宽自然就浪费了。NTTTCP 的-W参数不是直接指定窗口大小字节数而是指定一个倍数作用是分配默认的 TCP 窗口空间。我测试大带宽场景时的做法是先不加这个参数测一轮再用-W 2甚至-W 4测一轮对比吞吐变化。我踩过的一个坑有一次测两台服务器之间的性能1000Mbps 链路只能跑到 200Mbps第一反应是网线问题换线、换交换机端口都没解决。后来想到可能是窗口太小加上-W 2之后吞吐瞬间到了 900Mbps 以上。那次之后我每次做跨交换机、跨路由器的长距离测试都会先跑一组带-W的对照组。3.4 UDP 测试与统计输出-u、-m 参数精讲UDP 测试是很多人忽略但特别有用的功能。TCP 是可靠传输有重传机制网络一旦有丢包TCP 会自动降速重传所以 TCP 测出来的速率是“可靠速率”。但有些场景比如视频流、语音流用的是 UDP丢包了也不重传这时候需要单独测 UDP 的能力和丢包率。UDP 测试命令在两端都加-u即可# 服务端 ntttcp -r -u -m 1,0,192.168.1.10 -P 4 -t 30 # 客户端 ntttcp -s -u -m 1,0,192.168.1.10 -P 4 -t 30UDP 测试的结果里会多出丢包率数据这个在设计实时音视频系统时特别重要。我做过一个线上音频卡顿排查TCP 测速一切正常UDP 测出来丢包率 5%再往下查发现是交换机端口 buffering 不够问题一下子就定位了。-m参数除了指定 IP 三元组之外还承担统计模式的功能。最常用的是-m 1表示每秒输出一条统计信息打印每个时间点上的吞吐变化。这个对观察吞吐是否稳定、是否存在周期性抖动很有帮助。多客户端场景还会用到-sync来同步各客户端的时间基准不过这个属于进阶用法大家基础掌握之后按需深入即可。4. 结果怎么看带宽、CPU、丢包率的数据解读4.1 测速结果字段含义NTTTCP 跑完之后终端会打印一大段统计信息。新手很容易被一堆数字吓到其实核心就几个字段Total bytes传输的总字节数可以理解为测试期间总共发了多少数据。Throughput平均吞吐量单位 Mbps 或 Gbps这是网络性能最直接的指标。CPU测试期间 CPU 的使用率如果接近 100% 说明瓶颈可能在主机本身。Errors/Packet lossUDP 测试时出现这个字段代表丢包情况。在读结果的时候我一直强调一个思路不要只看吞吐数字要结合 CPU 和丢包一起看。吞吐高、CPU 低网络状态理想还有余量。吞吐低、CPU 高瓶颈在主机 CPU比如网卡卸载功能没开、驱动有问题。吞吐低、CPU 低大概率是网络本身受限比如中间设备限速、链路质量差、TCP 窗口不够。这种交叉判断的思路比单纯套用“测出 XXX 就是好”的结论要靠谱得多。因为网络路径上任何一段都可能成为瓶颈只看一头很难定位问题。4.2 通过 XML 输出做自动化统计如果只是偶尔测一次看终端输出就够了。但如果你的工作是定期做网络巡检手动记录数据不仅效率低还容易出错这时候可以开启 XML 输出。在命令里加一个-xml参数同时指定输出文件名ntttcp -s -m 1,0,192.168.1.10 -P 8 -t 60 -xml result.xml生成的文件里包含完整的测试参数、吞吐数据和统计信息之后写个脚本定时解析就能自动生成趋势报表。我现在的网络巡检脚本就是靠这个功能每天早上自动跑一次带宽测试把结果写入数据库出问题时直接翻历史曲线谁改了什么配置导致网络波动一目了然。XML 输出的另一个好处是标准统一多人协作时不会出现“我看终端你存截图”这种对不上的情况。团队内部如果需要对网络性能做量化考核这算是一个比较省事的落地方案。4.3 实测案例千兆网络、Windows 到 Linux 的测试记录分享一组我最近做的真实测试帮助大家对“什么样的结果是正常的”有个直观概念。测试环境一台 Windows Server 2019、一台 Ubuntu 22.04通过千兆交换机互联网卡自适应协商均为 1000Mbps。第一轮使用默认参数# Windows 服务端 ntttcp -r -m 1,0,192.168.1.10 -t 30 # Linux 客户端 ./ntttcp -s -m 1,0,192.168.1.10 -t 30结果是 510Mbps。乍一看千兆网络跑一半不高不低但既然协商速率是 1000Mbps这个值肯定没达标。第二轮加上 8 线程# Windows 服务端 ntttcp -r -m 1,0,192.168.1.10 -P 8 -t 30 # Linux 客户端 ./ntttcp -s -m 1,0,192.168.1.10 -P 8 -t 30结果到了 940Mbps。这说明第一轮的瓶颈就是单线程流上不去不是网卡或交换机的硬件问题。第三轮测试 UDP# Windows 服务端 ntttcp -r -u -m 1,0,192.168.1.10 -P 8 -t 30 # Linux 客户端 ./ntttcp -s -u -m 1,0,192.168.1.10 -P 8 -t 30吞吐稳定在 950Mbps丢包率 0%说明底层链路相当干净。这个实战过程其实很典型先确认硬件协商速率再用 TCP 单流测出“下限”加并发线程测出“上限”最后用 UDP 确认丢包和链路质量。一套流程下来网络的健康度基本心里有数了。5. 实战中的坑与排查技巧工具用多了自然会遇到各种问题。这一节的内容都是我实际踩过坑之后总结出来的希望对大家有帮助。5.1 防火墙导致连接失败最常见的问题是一端启动后另一端连接超时或直接报错。十有八九是防火墙拦截了流量。NTTTCP 默认使用的端口范围比较固定最简单的办法是在两端防火墙里放行对应端口。两种处理方式测试环境图省事直接把防火墙暂时关闭。但生产环境不建议这么做哪怕只是短暂的测试窗口。更稳妥的方式只放行 NTTTCP 所用的端口范围。如果使用默认端口参考官方文档中提到的 TCP/UDP 端口范围在防火墙入站规则里加一条允许规则。我个人的习惯是提前写好放行端口的命令放到测试脚本里测完再删掉规则。这样既不影响测试也保留了生产环境的防火墙策略。5.2 性能瓶颈的快速定位当测出的带宽明显低于预期时先别急着怪网线或者交换机按下面这个顺序排查基本能覆盖 90% 的情况先看网卡协商速率是不是真的协商到千兆或万兆。我遇到过好几次思科交换机端口配置问题导致协商在百兆的情况这种情况换线是没用的。看 CPU 占用。如果客户端或服务端 CPU 已经跑满优先检查网卡 RSS、卸载功能是否开启。看 TCP 窗口。加上-W 2或调大缓冲区再测一次排除窗口限制。看是否中间链路限速。如果加了线程还是上不去可能是交换机端口限速或运营商策略这个只能找网络管理员确认。这套顺序的核心思路是从“物理层 → 系统层 → 协议层 → 策略层”逐层排查每一步都有明确的数据支撑不会瞎猜。5.3 多版本混用问题NTTTCP 版本迭代会带来参数变化如果服务端和客户端版本差别太大可能出现参数不兼容、统计结果异常之类的奇怪问题。我的建议是测试前花一分钟确认两端版本一致尤其是团队多人协作时把工具包直接统一放到共享目录减少版本漂移带来的不确定性。另外NTTTCP 在 Windows 和 Linux 的发布节奏不完全同步跨平台测试时以功能匹配为准不一定要追求版本号完全一致但核心参数行为最好在同一次测试中固定下来。5.4 需要记住的几个注意点最后分享几个容易被忽略、但实际影响很大的细节测试前先关掉其他网络大流量应用。有一次我测速结果怎么都不对最后发现另一台服务器正在跑备份任务占了大半带宽。巨型帧Jumbo Frame要两端同时开启或同时关闭。只开一端会导致分片吞吐不升反降。虚拟机环境下测试结果会受宿主机影响。同一台宿主机上的两台虚拟机互测性能上限通常是虚拟交换机的能力数值会比物理机测试低不少。测试时长不要低于 30 秒。短时测试数据波动大尤其是 TCP 慢启动特性影响明显结果代表不了稳定带宽。多次测试取平均值。网络本身有波动单次测试可能运气好也可能运气差至少跑 3 轮取中间值或平均值再下结论。结尾就我自己的使用体感来说NTTTCP 是那种“上手不難、用精不易”的工具。刚开始照着命令跑一遍能拿到一个吞吐数字这只是入门真正的价值在于把线程数、缓冲区、TCP 窗口这些参数和数据背后的含义串起来遇到带宽不达标时能快速定位是主机的问题、网络的问题、还是参数配置的问题。我现在的日常工作里NTTTCP 基本是 Windows 环境网络排查的第一板斧凡是涉及“能不能跑满带宽”“链路质量怎么样”的疑问先拉出来测一轮再说。如果你也在做类似的测试最实用的建议是建一个简单的测试记录表把每次测试的环境、参数、结果和当时的变更都记下来。用不了几次你就会发现历史对比往往比单次测试更能说明问题。这个工具本身不复杂真正复杂的网络环境里经验就是这么一点一滴攒下来的。