简介IxChariot6.7 是一款面向无线网络测试、运维与设备验证人员的专业打流测试软件由美国 IXIA 公司研发主要用于评估无线 AP 的极限性能通过打流方式获取上行与下行吞吐表现。它适合实验室性能测试、AP 选型对比及无线吞吐验证等场景可帮助读者围绕 AP 承载能力开展压力测试与结果观察。资源以 rar 压缩包形式提供整体约 171.95MB上游未提供文件总数与主要文件类型明细因此包内文件构成暂无法展开说明。目前已有 645 人学习下载在无线测试人群中具有一定参考价值。对于需要补充打流工具、开展 AP 吞吐测试或进行无线性能对比的工程师而言这份软件包可作为实际测试环境中的工具资源使用。1. 一条标称 200Mbps 的专线怎么证明它真能跑满验收现场最容易吵起来的一句话是“你这链路跑不满”。厂商标称 200Mbps拿单流 iperf3 跑出 180Mbps是链路缩水还是工具本身到顶双方各说各话。IxChariot6.7 打流测试软件就是在这种场合派上用场的Console 下发测试意图两端 Endpoint 真实发包收包按协议、按方向、按流数把吞吐、时延、抖动、丢包拆开给你看。它不是一条命令跑完就完事的工具而是一套“控制台 端点 脚本 结果曲线”的测试框架适合做网络设备验收、专线与无线覆盖验证、VoIP/视频质量评估的人。后面几章按部署、TCP 打流、UDP/RTP 质量、排错、批量化的顺序拆能照着复现。2. 端点注册与组网打通Console 找不到 Endpoint 时先查这四处IxChariot 的测试模型很朴素Console 只是“指挥”真正产生流量的是两端 Endpoint 守护进程。Console 跑在性能普通的办公本上没关系Endpoint 所在机器的网卡、CPU、中断处理才决定你能打多高。所以第一件事不是急着建 Pair而是把拓扑和端点连通性做实。这一章按组网形态、端点安装、端口验证、Console 识别四步走每一步都有可验证的观察点别靠“看起来连上了”这种玄学判断。2.1 三种组网形态与选型理由最常见的形态是 Console 单独一台机器被测链路两端各挂一台 Endpoint中间夹着被测设备路由器、交换机、防火墙或无线 AP。这种“三点式”好处是 Console 不参与数据面不会因为控制台机器性能不足污染结果代价是 Console 必须能同时访问两端 Endpoint 的管理地址。第二种形态是 Console 与本端 Endpoint 同机远端只放一台适合只有两台机器可用的实验室场景但要接受本机 CPU 同时承担控制与收发的干扰。第三种是嵌入式或专用硬件 Endpoint体积小、功耗低适合放到现场或远端机房配置方式与软件端点一致差别主要在性能和可观测手段上。选型时我一般看两个指标被测速率和目标包长。千兆以下、包长 512 字节以上普通办公机装 Endpoint 基本够用要打万兆或者 64 字节小包拼 ppsEndpoint 的网卡队列、CPU 主频和中断绑定就是瓶颈这时候要么换硬件端点要么把并发连接数压下来分段测。别指望一台老笔记本跑出线速那不是工具的问题。组网还有一个容易忽略的点管理通道和数据通道最好分开。Console 到 Endpoint 走管理网段打流走被测链路两边混在一起时Console 的心跳和结果回传会跟测试流量抢带宽低速率测试看不出来跑到 800Mbps 以上就会在结果曲线上留下周期性掉坑。2.2 Endpoint 安装与 10101 端口连通性验证Endpoint 装完默认以服务或守护进程方式常驻监听 TCP 10101 供 Console 连接。装机时先确认服务在跑再从 Console 侧验证端口可达。Windows 端点用下面这组命令确认服务与端口# 1. 确认 Endpoint 服务处于运行状态服务名以实际安装为准 Get-Service | Where-Object { $_.DisplayName -like *Endpoint* } | Select-Object Name, Status # 2. 本机监听检查应能看到 10101 处于 Listen Get-NetTCPConnection -LocalPort 10101 -State Listen -ErrorAction SilentlyContinue # 3. 从 Console 机器验证到端点的管理端口 Test-NetConnection -ComputerName 10.10.20.31 -Port 10101 -InformationLevel Detailed第一条命令列服务重点是 Status 必须是 RunningStopped 就先手动拉起再设成自动启动。第二条看监听如果端口没起来多半是服务没起或者被别的进程占了。第三条的TcpTestSucceeded为 True 才算管理通道通了注意这一步只证明 10101 可达不代表数据面能跑满。Linux 端点把前两步换成等价命令# 查看 10101 是否在监听以及是哪个进程占的 ss -lntp | grep 10101 # 从本机探测远端端点管理端口-w 3 表示 3 秒超时 nc -zv -w 3 10.10.20.31 10101 # 抓 20 个管理报文确认 Console 与端点之间有来有回 tcpdump -i eth0 -nn host 10.10.20.31 and port 10101 -c 20ss那行如果只看到127.0.0.1:10101说明端点只绑了回环远端 Console 永远连不上要在端点配置里改成监听全部地址或指定管理网卡地址。nc返回 succeeded 才继续往下走。tcpdump是最后一道证据Console 侧发起连接、端点侧回包两个方向都有包才叫通只有 SYN 没有 SYN-ACK 就是中间被拦了。防火墙是最高频的翻车点。Windows 端点要放行入站 TCP 10101Linux 端点要在 iptables/nftables 或 firewalld 里放行云主机还要看安全组。放行时只放 Console 的管理地址段别图省事开成 any现场验收报告里写“端点管理端口对全网开放”是要被追问的。2.3 Console 添加端点与识别失败的三种表现Console 里加端点就是填地址和备注但“加进去”和“识别成功”是两回事。常见三种表现一是列表里端点显示为不可达通常是 2.2 里的端口或防火墙问题二是能连上但版本不匹配Console 与端点版本差太多时会拒绝管理升级到同一大版本即可三是同一 IP 加了两条记录测试时流量忽高忽低原因是两个条目指向同一台端点Console 把两条流都压到一块网卡上。添加时给端点起可读的名字比如“核心侧-万兆口”“接入侧-千兆口”后面建 Pair 选端点不用回头查 IP。多网卡端点要显式指定管理地址和数据地址别让系统按默认路由自己挑否则很容易出现“管理走对了、数据从另一张网卡跑出去”的情况测试结果看起来正常实际测的是一条没被要求的路径。3. TCP 吞吐打流落地脚本选型、Pair 参数与结果字段逐个抠端点通了接下来是建一条能复现的 TCP 打流。这一章的三件事按顺序做先选对脚本脚本决定了测试语义再配 Pair 参数参数决定了压力模型最后读结果字段字段决定了你怎么下结论。顺序反了就会出现“数字有了但说不清代表什么”的尴尬。3.1 脚本选型吞吐、事务率、响应时间各管一段IxChariot 自带一批.scr脚本随装可用选错脚本是新手最常见的浪费。纯吞吐验证选 High_Performance_Throughput 这一类脚本它尽量少做应用层动作把链路能力顶出来要模拟业务系统每秒能处理多少笔请求选 Transaction_Rate 一类关注的是事务率而不是比特率要评估单次交互的往返时延选 Response_Time 一类脚本会按固定节奏发请求并记录每次响应时间。脚本类型主要指标适用场景注意点高吞吐类Throughput (Mbps)链路带宽验收、设备转发能力单流容易受窗口限制建议多并发事务率类Transaction Rate (TPS)业务系统、网关请求处理能力事务大小要贴近真实业务响应时间类Response Time (ms)交互式应用、单次往返时延采样记录数要给够否则曲线毛刺UDP 类吞吐、丢包率视频流、实时数据、小包 pps必须显式设定目标速率RTP 类抖动、丢包、MOS语音、视频通话质量码率和打包周期要匹配 codec选脚本的实用原则验收合同里写的是什么指标就用能直接产出那个指标的脚本别用吞吐脚本反推时延也别用响应时间脚本证明带宽。指标口径对不上后面解释成本极高。3.2 Pair 参数方向、并发、包长、时长四个旋钮建好 Pair 后双击进去参数面板里真正影响结果的就那几个。方向决定是单端发、单端收还是双向同时并发连接数决定你能不能在单流受限时把链路填满发送缓冲区和文件大小决定 TCP 能不能快速爬到稳态测试时长和采样记录数决定结果曲线的粒度和可信度。方向Direction Send / Receive / Both验收一般用 Both 或按合同单向 并发连接数Connections416千兆以上单流跑不满时逐级加 发送缓冲区Send Buffer64KB256KB跨广域网时适当加大 文件大小File Size 1MB10MB太小会导致频繁重建连接曲线锯齿 测试时长Duration 60s 起步做稳定性看 300s 以上 采样记录数Timing Records默认值偏少建议提到 60 以上几个参数的经验值来源并发连接数从 4 开始每次翻倍看吞吐是否还涨涨到不涨为止这时候的数值才是这条链路在当前端点性能下的实际能力文件大小别低于 1MB否则 TCP 慢启动还没结束事务就完了测出来的是连接建立能力不是吞吐时长 60 秒是底线前 10 秒通常是爬坡段取稳态要看曲线中后段。双向同时打流Both要特别小心。两端 Endpoint 同时收发时网卡和 CPU 的压力是单向的两倍如果结果比单向之和还低不少先怀疑端点性能而不是链路。我一般先做单向、再做双向两个数据都留档报告里分开写。3.3 跑起来与结果字段解读点运行后看三样东西实时吞吐曲线、端点 CPU 占用、以及最终汇总表。吞吐曲线的前段爬坡是正常的中段应当平稳如果中段持续锯齿要么是并发不够、要么是端点 CPU 打满、要么是中间设备有流量整形。端点 CPU 占用是最容易被忽略的旁证吞吐上不去而端点 CPU 已经 90% 以上结论应该是“端点能力到顶”不是“链路不行”。结果字段里Throughput 是平均吞吐单位 Mbps报告里要写清楚是单向还是双向、是平均值还是稳态段Transaction Rate 是每秒完成的事务数跟脚本里定义的事务大小强相关脱离事务大小谈 TPS 没有意义Response Time 给的是平均值和最大最小值做交互式应用验收要看最大值而不是只看平均Loss 是丢包率TCP 场景下丢包会体现为吞吐下降而不是直接显示丢包所以 TCP 结果里丢包率低不代表链路没问题。还有一条血泪经验结果曲线一定要连着端点 CPU 和中间设备端口计数一起看。只看吞吐数字很容易把“端点跑不动”误判成“链路有问题”把“中间设备限速”误判成“线缆质量差”。数据要成组出现单个数字说服力很有限。4. UDP 与 RTP 质量打流抖动、丢包、MOS 的参数落点TCP 打流回答“能跑多快”UDP 和 RTP 回答“跑得稳不稳”。实时业务对丢包和抖动极其敏感1% 的丢包在文件传输里几乎无感在语音通话里就是断续。这一章把 UDP 速率设定、RTP 语音视频参数、混合流量并发三块拆开讲参数给到具体落点。4.1 UDP 打流目标速率、包长与 pps 能力UDP 脚本跟 TCP 最大的区别是必须显式告诉它发多快否则它会以端点最大能力狂发把被测设备直接打挂。参数面板里找到速率设定项按被测链路的标称带宽的 80%100% 设先低后高。包长是第二个关键旋钮1518 字节大包测的是带宽能力64 字节小包测的是 pps每秒包数能力很多低端设备带宽标称很高但小包转发能力很差只有小包测试能暴露出来。目标速率Rate 先设标称带宽的 80%逐步逼近 包长Packet Size 1518 字节看带宽64/128 字节看 pps 测试时长Duration 120s 以上UDP 更需要长窗口看稳定性 接收缓冲Receive Buffer端点侧适当加大避免应用层来不及取包造成假丢包小包测试有个换算要记住千兆线速在 64 字节包长下大约是 1.48Mpps算上以太网前导码和帧间隙实际能到 1.4Mpps 左右就算不错。如果端点报告发送 1.4Mpps 而接收端只收到 1.2Mpps中间差了 200Kpps这个差值就是被测设备的真实瓶颈比看 Mbps 更能定位问题。UDP 的丢包率要区分“网络丢”和“端点丢”。端点 CPU 打满、接收缓冲区太小、中断处理不过来都会表现为丢包但根因不在网络。判断方法换一台性能更好的端点复测丢包明显下降就是端点侧的问题两端都换还是丢才往链路和中间设备上查。4.2 RTP 语音视频codec、打包周期与 MOSRTP 脚本模拟的是真实语音视频流参数里最关键的是 codec 和打包周期。G.711 码率约 64kbps打包周期 20ms每个包 160 字节载荷G.729 压缩后约 8kbps同样 20ms 周期但包更小。码率和周期设错MOS 分数就没有参考价值。视频侧按分辨率码率对应设置常见标清 2Mbps、高清 48Mbps帧率与打包方式按脚本支持的选项来。MOS 是综合指标由丢包、抖动、时延共同决定IxChariot 的 RTP 脚本会给出 MOS 值和抖动、丢包的分解。解读时先看抖动再看丢包抖动超过 30ms接收端抖动缓冲会开始补偿补偿不过来就转成丢包丢包率超过 1%MOS 就会明显下滑。验收时把 MOS 目标写进测试计划比如“MOS 不低于 4.0、抖动不高于 30ms、丢包不高于 0.5%”比笼统说“语音质量良好”可执行得多。RTP 测试还有个坑两端时钟不同步会导致抖动数值虚高。端点机器时间不同步不影响 RTP 本身的收发但如果用外部工具做关联分析时间戳对不上就很难对齐。测试前把两端时间同步做掉省得后面扯皮。4.3 多流并发与混合流量别让端点成为唯一瓶颈真实网络里不会只有一条流。多 Pair 并发能模拟多个用户同时访问也能把单流受限的链路填满。做法是复制 Pair、改方向或改脚本然后一起运行。并发数上去之后必须盯端点 CPU因为每个 Pair 都要占用端点资源10 条流把端点 CPU 打到 100%测出来的是端点极限不是网络极限。混合流量更贴近办公场景一条 TCP 大流量做背景叠加几条 RTP 语音流观察语音的抖动和丢包在背景流量下的变化。这种测试能暴露设备的队列调度和 QoS 配置问题单一流量类型看不出来。配置时给 RTP 流打上 DSCP 标记中间设备按标记做优先级调度才能验证 QoS 策略是否真的生效不打标记测出来的结果只能说明“没配 QoS 时语音会受影响”说明不了策略本身。5. 避坑与排查打流跑不满、结果飘、端点掉线的五类现场这一章全是现场踩过的坑按“现象 → 原因 → 解决”写遇到对得上的直接照方抓药。5.1 端点侧连不上与中途掉线现象一Console 显示端点不可达但 ping 得通。原因基本锁定在管理端口ping 走 ICMP、Console 走 TCP 10101两层不是一回事。解决是按 2.2 的顺序查端点服务是否 Running、10101 是否处于 Listen、中间防火墙和安全组是否放行。还有一个隐蔽原因端点装了多张网卡服务只绑在其中一张Console 连的是另一张的地址。现象二打流跑到一半结果中断端点从列表里消失。先看端点是否重启或服务崩溃再看网卡是否进入省电状态。Windows 端点在网卡属性里关掉“允许计算机关闭此设备以节约电源”Linux 端点用ethtool关掉 Wake-on-LAN 相关省电选项同时把 CPU 调频策略设成 performance避免打流过程中降频导致吞吐断崖。现象三管理通、数据不通结果里吞吐接近零。典型原因是端点双网卡路由选错管理报文从管理口出去数据报文也走了管理口被测链路根本没流量。解决是在端点侧加静态路由把对端数据网段指向数据网卡或者干脆在端点配置里绑定数据接口。验证方法是打流时在数据网卡上tcpdump抓包抓不到就是走错口了。5.2 结果侧跑不满与数值飘现象四千兆链路只跑出 600Mbps 左右反复测都差不多。先排除端点性能看端点 CPU 是否接近 100%是就加机器或降并发。CPU 不高的话看单流是否受限把并发连接数从 1 加到 4、8、16吞吐跟着涨说明是 TCP 窗口和单流限制加到不涨为止。文件大小设得太小也会压低头部数值调到 1MB 以上再测。现象五同一配置每次结果差 10% 以上。三个常见来源采样记录数太少导致曲线抖动被平均掉、测试时段有背景流量、网卡 offload 干扰。解决是把时长拉到 300 秒、固定测试时间窗、在端点侧临时关闭 checksum offload 和 TSO 做对比测试。如果关掉 offload 后结果更稳定报告里就注明这个前提别两组数据混着用。现象六UDP 丢包率很高但换 TCP 测吞吐正常。这基本不是链路坏而是发送速率超过了接收端处理能力。先降 20% 速率复测丢包消失就是速率问题降速后仍丢检查接收端 socket 缓冲区是否太小、端点是否被中断风暴拖垮。用sar -n DEV 1或端点自带计数器看收包速率和丢包计数的对应关系能快速区分“网络丢”和“主机丢”。6. 批量化与结果可信度把一次性打流做成可复跑的回归手工点一次测试容易连着跑十轮、每轮换参数、结果还能横向对比就得靠批量化。我一般把调试好的测试存成.tst配置文件用命令行拉起执行结果导出 CSV 后统一处理。不同版本命令行参数略有差异下面这套骨架是我常用的形态参数名以手上版本为准echo off REM 批量回归同一份测试配置跑三轮结果分别落盘 set CHARIOTC:\Program Files\IxChariot\IxChariot.exe set SCRIPTD:\cases\tcp_throughput_1g.tst for /L %%i in (1,1,3) do ( echo Round %%i start %time% %CHARIOT% -f %SCRIPT% -run -q REM 结果导出为 CSV文件名带轮次便于后续聚合 %CHARIOT% -f %SCRIPT% -export D:\results\run_%%i.csv timeout /t 30 /nobreak nul )循环体里三件事执行、导出、冷却。-run触发执行-q静默模式避免弹窗卡住批处理-export把结果落成 CSVtimeout 30是冷却时间让端点从上一轮的高负载里恢复不然第二轮起点的端点状态不干净数据可比性下降。脚本路径和程序路径按实际安装位置改别照抄。拿到 CSV 后用一段 Python 做聚合和达标判断比肉眼扫表格靠谱import csv, statistics def summarize(path, target_mbps): rows list(csv.DictReader(open(path, encodingutf-8))) # 跳过前 10 秒爬坡段只取稳态 steady [float(r[Throughput_Mbps]) for r in rows[10:]] avg statistics.mean(steady) p95 statistics.quantiles(steady, n20)[18] print(f{path}: avg{avg:.1f}Mbps p95{p95:.1f}Mbps f{PASS if avg target_mbps else FAIL}) summarize(D:/results/run_1.csv, 900)rows[10:]是砍掉爬坡段的经验做法采样间隔 1 秒时对应 10 秒quantiles(n20)[18]取的是 95 分位用来判断稳态波动p95 和均值差距超过 10% 就说明这轮数据不够稳需要重跑而不是硬写进报告。达标判断用均值对目标值别用峰值峰值只能说明瞬时能力。从那以后我每次出验收报告前都强制走一遍“三轮取中位 端点 CPU 留档 抓包抽样”的流程宁可多花半小时也不让一个说不清来源的数字进报告。希望帮到你。本文还有配套的精品资源点击获取