简介IxChariot 6.7 是一款面向无线网络测试与优化人员的专业打流测试软件主要用于评估无线AP的极限性能通过流量测试获取上行与下行吞吐表现适合网络工程师、WLAN运维人员及从事AP选型、性能对比和实验室验证的技术人员使用。资源包体积约171.95MB采用rar压缩格式文件总数显示为0、类型明细暂无数据实际内容需以解压结果为准。已有644人学习或下载具备一定参考热度。借助该工具可围绕AP吞吐能力建立测试场景观察不同负载下的上下行性能差异为无线覆盖优化、设备对比和故障排查提供数据依据也便于在实验环境中复现打流测试流程并沉淀性能评估思路。1. IxChariot6.7 打流测试软件先看清楚它到底在测什么机房里两台机器用光纤直连交换机标称千兆配置里没看出任何问题可业务一上线就是跑不满——这种时候通常需要一个能把链路压到线速、还能把时延抖动拆开给你看的工具IxChariot6.7 打流测试软件就是干这个的。它和 iperf 那一类单点打流工具最大的区别在于控制台只负责下发测试指令真正发包收包的是装在被测两端机器上的 Endpoint所以流量是真的穿过被测设备交换机、路由器、防火墙、无线 AP跑的不是在本机回环里自娱自乐。这就决定了它的适用面比想象中宽网络设备出厂验收要跑吞吐和丢包、无线覆盖点位要做漫游前后的质量对比、VoIP 上线前要测 MOS 和抖动、防火墙开了策略之后要验证吞吐掉了多少都能用同一套控制台和同一种结果口径去比对。代价是安装和排错比 iperf 麻烦一个量级端点连不上、参数配错、结果读错任何一个环节翻车都会让你得到一份看起来很专业、实际上毫无意义的报告。2. Console 与 Endpoint 的部署链路把管理通道先打通分布式架构这件事理解和不理解排错效率差出十倍。很多人第一次用把控制台和服务端都装在自己笔记本上两端都填 127.0.0.1跑出来一个漂亮的千兆数字然后拿去汇报——那份数据只证明本机回环和 CPU 没问题和被测链路一点关系都没有。所以部署的第一原则是端点必须落在被测链路的两侧控制台放在第三方位置走带外或者管理网接入。2.1 三个角色控制台、端点、被测链路各管什么控制台负责的是测试定义和结果呈现它本身几乎不产生业务流量所以控制台性能基本不影响测试结论一台普通办公机就能带几十个端点。测试定义保存下来是一个后缀为.tst的文件里面描述了配对关系、用哪个脚本、跑多久、采样间隔这些内容这个文件是可以进版本库、可以复用、可以批量生成的后面做回归测试全靠它。端点是被测流量的真实发出方和接收方它才吃 CPU、吃网卡、吃中断。一台端点跑一条千兆 TCP 流通常还撑得住跑到三四条并发流的时候就要开始盯任务管理器的单核占用和网卡队列了这时候表现出来的是链路跑不满但根子其实在端点机器上跟被测设备没关系这也是最容易误判的一类问题。脚本.scr定义的是单次事务的行为一次发多少字节、收多少字节、走 TCP 还是 UDP、有没有双向。控制台只是把脚本和端点组合起来调度所以同一对端点换脚本测出来的东西完全不同。把这三层分清楚之后遇到问题就能快速定位到底该查哪一层。角色部署位置关键关注点控制台 Console管理网独立机器授权、.tst文件管理、结果归档路径端点 Endpoint A/B被测链路两端CPU 核数、网卡队列、防火墙、系统计时精度被测设备 DUT端点之间流控、QoS 策略、会话表容量、无线空口2.2 装完端点先别急着跑测试四个连通性检查端点装好之后控制台里能看到它但不代表能跑测试。管理通道和数据通道是两条不同的路径前者是控制台到端点的指令通道后者是端点 A 到端点 B 的流量通道任何一条没通你都会看到一个测试启动失败之类的模糊提示。第一步是确认端点的服务在跑端口在听。常见做法是装完就把它注册成系统服务排障的时候再手工前台拉起来看输出因为服务模式下的日志往往不往控制台打。# Windows 端点确认端口在监听以及是哪个进程占的 netstat -ano | findstr 10115 tasklist | findstr /i endpoint # Linux 端点看监听状态和防火墙规则 ss -lntp | grep 10115 sudo iptables -L INPUT -n --line-numbers | head -20这两组命令查的是同一件事管理端口有没有对外张开。netstat -ano里的-a是列出所有连接和监听、-n是不做反向解析快很多、-o是带上进程号方便你顺着 PID 找到具体进程。Linux 那边ss -lntp里-l只显示监听态、-n数字端口、-tTCP、-p带进程。如果这里看不到端口后面所有检查都不用做了先回去看服务有没有起来、装的时候是不是被安全软件拦了。第二步才是放行防火墙。端点之间要互通数据所以规则的写法不是放行控制台 IP而是双向放行两个端点之间的通信端口区间。这里有个血泪经验只放行管理端口能连上端点、能启动测试但测试一开始吞吐就是 0 或者只有几 Kbps因为数据通道被挡了而工具报的错通常只说连接超时不会告诉你是哪个方向被挡。# Linux 端点示例只对被测网段放行别图省事全开 sudo iptables -A INPUT -s 192.0.2.0/24 -p tcp --dport 10115 -j ACCEPT sudo iptables -A INPUT -s 192.0.2.0/24 -p tcp --dport 10116 -j ACCEPT sudo iptables -A INPUT -s 192.0.2.0/24 -p udp --dport 10116 -j ACCEPT端口号只是示意管理通道和数据通道在不同小版本上可能不一样装完去看端点安装目录里的配置文件或者直接在控制台的端点属性里看它上报的端口比自己猜靠谱。上面这几条规则的逻辑是源地址限定在测试网段避免把端点暴露给办公网协议和端口按实际配置填TCP 和 UDP 都要放因为 UDP 打流和 TCP 吞吐走的是同一个数据端口但协议不同。第三步是版本对齐。端点版本高于控制台版本是最常见的坑控制台能连上、能读端点信息但一启动测试就报协议不兼容。稳妥做法是控制台和端点用同一批安装包或者端点版本严格不高于控制台。第四步是做一个最小验证取消点用一对端点跑 10 秒默认吞吐脚本能出数字再往下走别一上来就配二十条流。2.3 授权与版本对齐装上了对不上更烦授权这件事在测试工具里属于平时无感、关键时刻致命的类型。控制台导入授权之后能带多少个并发端点、能不能跑某些高级脚本都是授权决定的。常见的翻车场景是单机测试一直正常一到多端点并发就随机有端点连不上重启之后又能连上看起来像网络抖动玄学其实是并发端点数量超了授权上限工具用连接失败这种方式告诉你。判断方法很直接把并发端点数降到两个再跑一遍如果稳定了就去查授权文件里的端点数量限制和有效期。有效期这块也要留意长周期的稳定性测试经常是跨天甚至跨周跑的跑到一半授权过期测试会中断前面几个小时白跑。我一般会在跑长测之前先看一眼剩余天数不够就先续。版本对齐还有一层是脚本兼容。老版本留下来的.scr脚本在新控制台上通常能加载但参数默认值可能已经变了尤其是缓冲区和事务体量这两项。所以复用旧.tst的时候别直接双击就跑先把里面的参数逐项对着当前需求核一遍尤其是别人给你的测试用例——你不知道他当时是在什么环境下配的。3. 选脚本配参数一条 TCP 吞吐测试从建到跑参数配错是打流测试里最常见的问题而且它不像连通性故障那样有明显报错参数配错的结果往往是一份看起来很合理的数据。所以这一章的重点不是教你点菜单而是把每个参数为什么这么设讲清楚让你在换场景的时候知道该动哪个。3.1 脚本选型Throughput 和 High_Performance_Throughput 差在哪控制台自带一批脚本最常用的两个是Throughput.scr和High_Performance_Throughput.scr。前者单次事务的体量在十万字节量级后者在百万字节量级。差别不只是快慢事务体量小单位时间内的事务次数就多端点 CPU 花在系统调用和中断上的开销占比就高测出来的吞吐更容易受端点性能限制事务体量大单次传输时间长TCP 慢启动和拥塞控制的影响就被摊薄更接近链路真实能力。所以选型逻辑是验证链路极限吞吐用高体量脚本验证小包转发能力或者应用层响应用低体量脚本或者自己调事务大小验证语音视频质量那要用专门的 VoIP 和视频脚本它们关心的是抖动、丢包和 MOS不是吞吐。脚本类型事务体量量级适合验证什么端点 CPU 压力Throughput十万字节一般应用层吞吐、响应时间中High_Performance_Throughput百万字节链路极限吞吐、大文件传输低UDP 打流类可配常配小包线速转发、丢包率、抖动高小包时语音/视频类按编码码率抖动、MOS、卡顿中还有一类是自己新建脚本控制台里可以指定发送字节数、接收字节数、协议、是否双向。做防火墙策略验证的时候我一般会建三套64 字节小包、512 字节中包、1518 字节大包分别跑一遍因为很多设备大包线速、小包掉一半只看一个体量会漏掉这个信息。3.2 一条 TCP 上行吞吐测试的建法建测试的顺序是固定的新建 test → 添加 pair → 选脚本 → 指定两个端点 → 设时长和采样 → 保存.tst→ 运行。中间真正容易错的是端点方向。pair 是有方向的A 发 B 收 和 B 发 A 收在交换机上可能是两条完全不同的路径尤其是做过链路聚合或者策略路由的环境所以双向都要测别只测一个方向就下结论。参数这块一张表说清楚每个旋钮管什么参数常用取值调整它会怎样事务体量Send/Receive Bytes1KB / 64KB / 1MB越小越吃 CPU 和中断越大越接近链路极限发送/接收缓冲区与带宽时延积匹配太小直接压不满高带宽长链路测试时长30s300s太短抓不到稳态太长浪费时间且易受干扰采样间隔1s间隔太大曲线看不出瞬时抖动并发 pair 数14 起步单流跑不满先加流别急着改缓冲区带宽时延积这个概念值得单独拎出来一条 1Gbps、往返时延 2ms 的链路理论上要有 250KB 左右的在途数据才能填满管道。TCP 窗口设得比这个小吞吐就被窗口卡死了这时候你把端点 CPU 加到十六核也没用。所以遇到跑不满先算一遍带宽时延积再回头看他配的缓冲区比无头苍蝇式地改参数快得多。保存.tst的时候命名要有规矩我的习惯是协议_方向_体量_时长.tst比如tcp_up_1m_60s.tst。这样半年后回头看归档一眼就知道当时跑的是什么条件不用打开文件猜。这一点在做前后对比测试的时候特别重要很多对比结论之所以站不住就是因为两次测试的条件根本不一样。3.3 UDP 打流的四个旋钮把线速压出来UDP 打流和 TCP 的逻辑完全不同。TCP 有拥塞控制你压不满它会自己退让UDP 没有你让它发多少它就发多少发不出去就丢所以 UDP 能测出链路的真实转发上限但也更容易把端点自己压垮从而测出假数据。第一个旋钮是发包速率。很多脚本默认不限速端点上能发多快发多快这时候如果端点 CPU 弱你测到的是端点的发包能力不是链路能力。正确做法是从目标速率的 50% 开始往上加每次加 10%直到丢包开始明显上升那个拐点才是链路的能力边界。第二个旋钮是包长。小包线速对大包线速是完全不同的两个指标64 字节小包要达到千兆线速意味着每秒接近 150 万个包这对端点的中断处理和网卡队列是巨大压力。所以我一般先用大包测出转发上限再用小包测 PPS两个数字分开报别混成一个吞吐。第三个旋钮是缓冲区。UDP 接收缓冲区太小会直接导致端点侧丢包这种丢包和链路丢包在结果里看起来一模一样但根因完全不同。排查方法是看丢包是发生在发送端计数还是接收端计数如果两端数字对不上那基本就是接收端缓冲区或者 CPU 处理不过来。第四个旋钮是并发流数。单流 UDP 受限于单核处理能力多流能分摊到多核但也会带来乱序和抖动。做稳定性验证的时候我倾向于用 4 条流而不是 1 条因为单流的结果太好看了好看得不真实。4. 结果怎么读吞吐、时延、抖动、丢包的取数与交叉验证跑完一次测试界面上会给你一堆数字平均值、最大值、最小值、百分比分布。新手最容易犯的错是直接抄那个平均值交差而平均值在有丢包或者有抖动尖峰的场景下几乎没有参考价值。4.1 先看 Summary 再看曲线顺序不能反Summary 页给的是整段测试的聚合值吞吐量、事务率、平均/最小/最大响应时间、丢包百分比。它的用途是快速判断这次测试有没有意义——如果吞吐只有几百 Kbps那后面的时延分析全是废的先解决吞吐问题。曲线页才是有信息量的地方。我习惯按这个顺序看先看吞吐曲线在测试中段是不是平的如果是一条持续下降的斜线说明有队列在堆积或者有热衰减再看时延曲线的形态正常应该是围绕某个基线小幅波动如果出现规律性的锯齿那是缓冲区周期性填满和排空的典型特征跟链路本身没关系是参数没配对最后看有没有孤立尖峰孤立尖峰通常来自端点系统的后台任务或者定时器重复跑一次如果尖峰位置随机变化就可以判定为端点侧噪声。判断稳态段的方法是掐头去尾。开头几秒包含 TCP 慢启动和连接建立末尾几秒可能有收尾开销把中间 70% 的区间取出来算统计值比直接用整段平均值靠谱。这一点在 30 秒的短测试里尤其明显掐头去尾之后能用的可能只有十几秒。4.2 批量跑与 CSV 归档单次测试的结果没有可比性真正有用的是同一个条件下的多轮次结果以及不同条件下的对照结果。控制台的图形界面适合看单次批量就得靠命令行和结果文件。# 控制台命令行模式挂 .tst 跑具体开关名以控制台 -h 输出为准 IXC/c/Program Files/IxChariot/IxChariot.exe for i in 1 2 3; do $IXC -t ./cases/tcp_up_1m_60s.tst -r ./results/run0${i}.csv sleep 30 # 轮次之间留间隔让队列排空、机器降温 done这段脚本的逻辑很朴素同一个.tst连跑三轮每轮输出一个 CSV。-t指定测试文件、-r指定结果输出路径这两个开关在不同版本上名字可能略有差异第一次用之前先看一遍命令行帮助别硬套。sleep 30那行不是凑数连续跑会让端点的网卡队列和 CPU 缓存来不及恢复第二轮开始的数据会偏乐观轮次间隔本身就是测试条件的一部分。拿到 CSV 之后用一段脚本把稳态段提出来做统计比手工在界面上读数快一百倍import csv, statistics, glob def load_steady(path, head_ratio0.15, tail_ratio0.15): 读出吞吐列掐掉头尾各 15% 的样本 with open(path, encodingutf-8-sig) as f: rows list(csv.reader(f)) # 表头位置因版本而异靠关键字定位找不到就退回第一个非空行 head_idx next((i for i, r in enumerate(rows) if any(Throughput in c or 吞吐 in c for c in r)), 0) header rows[head_idx] col next(i for i, c in enumerate(header) if Throughput in c or 吞吐 in c) vals [] for r in rows[head_idx 1:]: if len(r) col or not r[col].strip(): continue try: vals.append(float(r[col])) except ValueError: continue n len(vals) s, e int(n * head_ratio), int(n * (1 - tail_ratio)) return vals[s:e] or vals for p in sorted(glob.glob(./results/*.csv)): d load_steady(p) print(f{p} n{len(d)} p50{statistics.median(d):.1f} fmin{min(d):.1f} p90{sorted(d)[int(len(d)*0.9)]:.1f})代码里几个地方的用意utf-8-sig是为了处理 Windows 导出的 BOM 头不加这个第一个列名会带上不可见字符关键字匹配就失效head_idx那段是因为导出的 CSV 前面常常有几行设备信息说明直接按第一行当表头会错位掐头去尾的比例做成参数是因为测试时长不同短测试要多掐一点。参数说明head_ratio和tail_ratio我一般设 0.1510 秒的超短测试会设到 0.3300 秒的长测试设 0.05 就够。输出的 p50 和 min 要一起看。如果 p50 和 min 差距超过 15%说明这段测试不稳定别急着下结论先查端点和背景流量。4.3 时延数据的可信度计时精度与小包时延这一类指标工具给你的是它测到的不一定是真实的。桌面系统的时间片调度精度通常在十几毫秒量级端点进程在一毫秒以内的处理延迟靠这种精度是分辨不出来的。表现出来就是时延最小值一水儿的 0 或者 1看着很漂亮其实是测量分辨率不够不是链路真的那么快。判断方法把事务体量降到很小比如 64 字节如果时延最小值突然变成 0而中等体量下是正常的零点几毫秒那就是精度问题。这种情况下正确的做法是只报中位数和 95 分位不报最小值因为最小值根本不可信。另一类干扰是端点自身的负载。端点在做背景更新、磁盘扫描、杀软实时扫描的时候时延曲线会出现密集的毛刺。这类毛刺有个特点多跑几轮位置是随机的。如果毛刺位置固定出现在测试开始后第 8 秒左右那更可能是链路上某个周期性任务比如路由协议报文导致的。区分这两种情况靠的就是多轮对比所以单轮数据永远别当结论用。5. 排查与避坑跑不满、掉线、数据离谱的五条经验这一章的内容基本都是踩出来的每一条我都对应给出现象是什么、根子在哪、怎么改遇到相似情况可以直接对号入座。5.1 现象控制台里端点在线但启动测试就报连接失败原因通常有三层。第一层是防火墙只放行了管理端口数据通道被挡第二层是两个端点之间跨了三层设备中间有 ACL 或者 NAT端点 A 到 B 的路径根本不通第三层是版本不匹配端点版本高于控制台握手协议对不上。解决顺序是倒过来查先确认两端版本号再从一个端点直接 ping 另一个端点确认三层可达最后在两端都用netstat看着端口建立连接的情况启动一次测试。如果管理连接建立了、数据连接一条都没有那就是数据端口被挡这时候别再折腾控制台了去查中间设备。提示跨网段测试的时候端点之间能不能互通和端点能不能被控制台访问是两件独立的事别用前者的结论去推后者。5.2 现象千兆链路只能跑出三四百兆这个是最经典的跑不满。原因排序TCP 窗口或缓冲区小于带宽时延积、单条流受单核限制、端点网卡开了省电或者中断合并、端点 CPU 被别的进程抢。排查方法是一步步排除先把并发流数从 1 加到 4如果吞吐随流数线性上升那就是单流受限加到 4 条之后吞吐不涨了去看端点 CPU 是不是某个核跑满了CPU 没满再去看网卡高级设置里的省电、流量控制、中断节流逐项关掉重测。这里有个反直觉的点网卡的 offload 特性分段、校验和卸载会让吞吐数字变好看但它同时会让时延测量失真因为数据包在网卡里被重组的时刻软件层根本看不到。所以做时延测试的时候offload 是要关的做纯吞吐测试的时候可以留着但要在报告里注明环境。5.3 现象吞吐曲线中途掉速掉下去再也没回来不是抖动是单边下跌。常见的根因是交换机流控被触发了——接收侧来不及时发 pause 帧发送侧被迫停恢复之后吞吐再也回不到之前的水平。这类问题在跑 UDP 高速率的时候特别容易出现因为 UDP 没有拥塞控制接收端一旦缓冲区不够就疯狂丢包丢包反过来触发流控。处理办法先把发送速率降 20% 看是否还掉速如果稳了说明就是过载触发然后在接收端点确认接收缓冲区调大同时检查两边网卡的流控设置是否一致一边开一边关是更糟的配置。长期看UDP 打流的速率要贴着拐点配不要一上来就顶满。5.4 现象时延最小值为 0或者抖动大得离谱时间精度问题见 4.3 那一节的分析。除此之外还有一个容易忽略的点端点机器的系统时间同步服务。做多端点对时延对比的时候如果各端点的时钟源不一致你看到的时延差异里会混进时钟偏移尤其是跨机器对比的时候。稳妥做法是测试期间关掉时间同步或者确保所有端点同步到同一个源。抖动数据的另一个陷阱是采样间隔。间隔设成 5 秒那 5 秒内的抖动全被平均掉了看起来一片平静实际上中间可能有好几次 50ms 的尖峰。测 VoIP 这类场景采样间隔一定是 1 秒甚至更细别图省事。5.5 现象长测跑到一半中断结果文件是空的三个可能授权到期、结果输出目录没写权限、采样点太多把控制台内存撑爆。第一个看授权剩余时间就能排除第二个换一个本地目录试一次就知道第三个最隐蔽跑 24 小时的测试、1 秒采样、十几个 pair采样点数是以百万计的控制台如果一直把数据放在内存里不落盘撑爆是迟早的事。对策是长测前先做一次 1 小时的短版观察控制台的内存曲线涨得不明显再上长测同时把结果输出路径设在本地磁盘而不是网络盘网络盘在长时间写入的时候掉链路的概率比你想的高。6. 进阶把单次打流变成可回归的测试基线单次跑出来的漂亮数字三个月后没人能复现那这份数据就白跑了。真正有价值的做法是把它变成基线固定环境、固定参数、固定脚本每次变更之后跑同一套.tst看新数据相对基线的偏移。6.1 端点矩阵与并发结构多流测试不是简单地把 pair 数往上堆。一台端点跑四条千兆流光中断处理就能吃掉两个核测出来的数字会比真实链路能力低一截。比较稳的结构是多端点、少流四台低配端点各跑一条流比一台高配端点跑四条流的结果更接近真相因为前者把处理压力分散到了不同的物理机和网卡队列上。具体配置上我会把发送方向的端点分散到不同的网卡上如果一台机器有多网口并且在系统层面把端点进程绑到固定的核避免它被调度到正在处理中断的核上。这一步在 Linux 上用taskset就能做效果比换更贵的机器明显得多。# 把端点进程绑到 2-5 号核把 0-1 号核留给网卡中断 sudo taskset -c 2-5 ./endpoint --daemon # 配合看中断分布确认中断确实落在 0-1 号核 cat /proc/interrupts | grep -E eth|ens绑核的收益在并发流多的时候特别突出抖动会明显收敛。参数上要注意-c 2-5是核编号区间具体编号要按机器实际的核数来别照抄中断分布看的是/proc/interrupts里各队列的计数是否集中在预期的核上如果全是 0 号核在处理说明中断亲和性没配好绑核的效果会被抵消掉。6.2 把一次测试变成可复现的基线基线的最小要素是四样.tst文件、端点清单机器、网卡、系统版本、环境快照offload 开没开、流控开没开、有没有背景流量、结果原始 CSV。这四样放在同一个目录里命名带日期任何一次新测试都能和它逐项对齐。我一般会额外维护一张对照表记录每次变更换了网卡驱动、改了交换机 QoS、升级了固件之后 p50 吞吐和 95 分位时延的变化。这张表的价值在于单个数字看不出趋势连续几行就能看出有没有在退化。有过一次教训某次升级后吞吐只掉了 3%看着在误差范围内但连续三个版本都在掉累计下来掉了 12%等到业务方反馈慢的时候再回头追中间几个版本的原因已经查不清了。从那以后我每次跑完测试不管多急都强制走一遍存.tst、存环境快照、存原始 CSV、更新对照表这四步哪怕这次只是临时验证一个小改动。多花的十分钟换来的是半年后还能回答这个数字是怎么来的。希望帮到你。本文还有配套的精品资源点击获取