简介Cisco开源流量测试工具TRex的图形界面客户端面向网络设备测试与运维工程师旨在把TRex从命令行的复杂操作中解放出来通过可视化面板完成端口配置、流量模板编辑与统计结果监控帮助用户快速开展性能测试和压力验证。资源包共499个文件体积仅1.05MB内容组织清晰291个Java源码构成核心逻辑50个FXML文件定义JavaFX界面布局8个CSS负责界面主题另含18个PCAP报文样本可直接用于回放测试以及YAML、XML、JSON等多格式配置样例覆盖了GUI客户端从界面展示到数据交互的完整链路。目前已有265人学习下载。对希望快速掌握TRex图形化使用方式的测试工程师或想借鉴JavaFX项目结构进行二次开发的开发者而言这份资源提供了可直接运行的源码、界面素材、抓包样例与配置模板同时保留了Gradle构建入口和跨平台启动脚本可显著缩短工具搭建与功能验证的时间成本。1. 为什么流量测试要选Cisco TRex它和常见打流工具差在哪做网络性能测试的人手里多多少少都有几套打流工具。Cisco开源的流量测试工具TRex属于那种“第一眼不惊艳、用起来才觉得值”的选择它基于DPDK绕过内核协议栈单台普通服务器就能把万兆甚至40G口打满而且自带图形界面客户端。这个GUI不是锦上添花的玩具它把端口绑定、流量模板、实时统计从命令行黑匣子拉回可视化面板里路由交换设备的吞吐、时延、丢包测试都能在面板上直接完成。这篇笔记就围绕TRex图形界面客户端讲清楚它的架构、部署路径和踩过的坑适合正在搭建自动化测试环境的从业者参考。2. 先搞懂TRex的工作原理服务端、客户端与三种流量模型2.1 trex server 客户端架构和两个角色TRex的部署形态被我第一次接触时误判成“一个软件包跑起来就是一个整体”。实际上它把数据面和控制面分得很清楚TRex server才是真正跑流量的进程它负责从DPDK接管网卡、构造报文、发送和接收而客户端是另一个进程可以跑在同一台机器的另一个终端也可以跑在完全不同的电脑上。我们说的图形界面客户端就是控制面的一种实现它通过RPC和server通信把用户鼠标点出来的配置转成server可执行的指令。这套架构最大的好处是客户端不触碰到数据面。GUI进程再卡顿、再频繁刷新也不会影响正在运行的打流任务。我见过有人把GUI和服务端放在同一台机器上窗口拖动时CPU占用升高但打流吞吐并没有抖动原因就在于此。要是让客户端直接通过socket发原始报文那么一次垃圾回收或者一次磁盘IO都可能让统计曲线出现毛刺数据就不可信了。两者的职责可以这样理解server是发动机客户端是方向盘。生产环境里server要稳定地跑在靠近被测设备的位置最好固定CPU核、锁定大页内存而GUI可以随手开在调试电脑上调完参数关掉都不影响server继续发流。这也是TRex比很多老牌打流软件更适合自动化测试的原因之一控制面和数据面解耦后回归脚本可以随时连上来接管。角色运行位置主要职责常见形态TRex server靠近被测设备的服务器接管网卡、构造并转发报文、统计收发计数二进制程序 t-rex-64CLI 客户端任意终端交互式查看端口、下发流模板、抓包trex-consoleGUI 客户端带图形环境的开发机可视化配置端口和流、实时刷新统计trex_gui.pyPython API测试脚本或CI机器无人值守批量打流、断言丢包率trex_stl_lib.api2.2 无状态/有状态/高级状态选型先看数据面TRex的图形界面客户端启动后会看到它支持三种主要的流量模型无状态Stateless、有状态Stateful和高级有状态ASTF。很多新手一上来就纠结用哪个其实选型不复杂看被测对象对连接状态敏不敏感。无状态模式适合测转发能力只要按模板往端口上怼包不关心这些包是不是属于某个TCP连接。交换机、路由器、网关这类设备主要看吞吐用无状态模式就能说清楚问题。GUI里新建Stream时可以指定帧长、pps、源IP、目的IP、端口号等字段但它不会替你维护TCP状态机。有人拿无状态模式去测防火墙发现吞吐高得离谱因为防火墙根本没把这些散包识别成一个会话自然不执行会话表查询。这不是设备作弊是你选错了模式。有状态模式则完全不同。它基于真实会话回放把pcap包里的交互过程按连接维度重放会执行TCP三次握手、保活和拆除。防火墙、NAT网关、负载均衡器这类“连接感知”设备必须用有状态模式测。代价是服务端需要维护海量连接状态CPU和内存占用高出一大截。高级有状态模式ASTF是进阶选项它不依赖pcap文件而是用协议模板动态生成流量比如指定每秒钟建立多少条TCP连接、每条连接发多少字节。它比单纯回放更贴近自动化测试需要但配置复杂度也更高。我一般建议先测单点吞吐用Stateless要模拟现网业务连接选Stateful需要在固定时间内构造大量新建连接才考虑ASTF。2.3 图形界面客户端在这个架构里扮演什么角色图形界面客户端本质上是Python client的一个封装。它连上server后会拉取端口状态、CFG信息、当前已加载的流模板并订阅实时统计。TRex官方发行包里通常包含GUI目录入口脚本一般是trex_gui.py。启动它之前先看一眼帮助信息不同小版本的参数名会有差异死记参数反而容易翻车# 进入 GUI 所在目录后先确认客户端支持哪些启动参数 python3 trex_gui.py --help这段命令不是多余的。我遇到过有人把老教程里的--server-host直接抄过来结果程序提示Unknown argument。常见的连接参数是--server指定TRex服务端IP--port指定RPC端口服务端默认一般监听在TCP 4501。具体以--help输出和server启动日志为准。如果--help能正常打印参数列表说明Python环境基本可用下一步再考虑窗口能否弹出来。要强调一点GUI和服务端的版本尽量对齐。TRex的RPC协议会随版本增加字段老版本GUI连新服务端可能端口列表能刷出来但点启动时报“field not found”新版本GUI连老服务端则可能直接握手失败。升级TRex时我的习惯是服务端和客户端一起换只换一半的坑实在不值得踩。3. 用图形界面客户端跑通第一轮打流安装、连接与最小配置3.1 准备环境网卡、DPDK和TRex服务端在打开GUI之前服务端必须先能跑起来。先检查网卡型号不是所有网卡都能被DPDK接管。Intel的x520、x710、i350系列是常见选择Mellanox的ConnectX系列也常见。用lspci看一眼本机网卡心里有数lspci -nn | grep -i ethernet输出会列出网卡的PCI地址和型号比如02:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP。记下PCI地址后续DPDK绑定要用。接下来设置大页内存TRex收包时频繁从大页池分配mbuf没有大页很容易报内存分配失败# 临时分配 2048 个 2MB 大页合计 4GB重启后失效 echo 2048 /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages生产环境建议在/etc/sysctl.conf里配vm.nr_hugepages这样重启后不丢配置。大页大小不是越大越好4GB足够跑多数测试如果你要模拟百万级并发流再往上加。设置完后用grep Huge /proc/meminfo确认HugePages_Total不为0。接着绑定网卡到DPDK驱动。TRex发行包里一般带dpdk_setup.sh或者用dpdk-devbind.py# 先看当前哪些网卡被内核驱动占用、哪些被DPDK占用 ./dpdk-devbind.py --status确认PCI地址后把测试网卡从内核解绑绑到igb_uio./dpdk-devbind.py --bindigb_uio 0000:02:00.0 0000:02:00.1注意绑完之后这两张网卡会从操作系统里消失SSH如果只有这两张网卡你会立刻断连。所以我总是建议测试网卡和管理网卡物理分离否则只能跑回服务器前插显示器这个教训很贵。绑定完成后写TRex配置文件常见路径是/etc/trex_cfg.yaml。以下是我常用的精简模板port_info: - ip: 192.168.1.1 default_gw: 192.168.1.254 - ip: 192.168.2.1 default_gw: 192.168.2.254 platform: master_thread_id: 0 latency_thread_id: 1 dual_if: true这里的IP是TRex端口上要承载的测试地址不代表服务器管理IP一般选用私网段。master_thread_id和latency_thread_id分别表示主线程和时延统计线程绑在哪个CPU核上避免互相抢占。dual_if: true意思是两个端口联动作业适合测双工转发如果你只有一张测试网卡需要把这个字段改为false并删掉第二个port_info。启动服务端用交互模式验证配置sudo ./t-rex-64 -i启动日志会显示检测到的端口、绑定的驱动、大页数量。看到“The port 0 is up”这类输出说明server已经就绪。如果在这之前GUI就连上来只会得到一堆连接超时的红字所以顺序一定不能反。3.2 安装并启动图形界面客户端服务端跑起来后回到你的开发机准备GUI。TRex的GUI是Python写的依赖wxPython和PyYAML。在Debian/Ubuntu上先装依赖sudo apt update sudo apt install python3 python3-wxgtk4.0 python3-yaml如果你的系统没有python3-wxgtk4.0这个包用apt-cache search wx搜一下不同发行版包名会有偏差。装完依赖进入TRex发行包的GUI目录启动客户端python3 trex_gui.py --server 192.168.1.100 --port 4501--server填TRex服务端的IP也就是刚才运行t-rex-64那台机器的IP--port填RPC监听端口默认一般是4501。如果启动时窗口一闪而过多半是wxPython没装好回到上一步检查import。GUI启动后通常会有连接框填入IP和端口点Connect。连接成功后主界面会列出服务端识别到的物理端口以及它们的UP/DOWN状态。如果GUI跑在无图形环境的Linux服务器上窗口是弹不出来的。不要急着给服务器装桌面更合理的做法是把GUI放在你的笔记本上TRex服务端继续留在机房服务器里。两者之间只要TCP可达就行架构上本来就是分开的。3.3 在GUI里配置端口和流量模板连接成功后在端口列表里双击某个端口会打开端口配置窗口。这里要填的是L1/L2/L3基础信息是否启用VLAN、端口MAC地址、目的MAC、源IP、目的IP、下一跳MAC等。如果被测设备是纯二层交换机源目MAC写对就能跑如果是三层路由需要把IP和网关填上不然TRex发出的包到不了对端。接下来创建一条无状态流。在Stateless视图下选中端口右键添加Stream弹出的编辑框里有几个关键参数帧长、pps或bps速率、包数、源IP范围、目的IP范围、端口号范围。最小配置是固定帧长加固定速率帧长64字节用来压小包线速速率100000 pps包数不设上限持续发送我偏爱先拿64字节小包做基准测试因为小包最能暴露转发瓶颈。如果设备宣称能线速转发1518字节大包用64字节测还能维持一样线速那才是真nb。GUI里把速率单位切换成pps比直接写百分比线速更直观因为百分比在不同帧长下对应的pps完全不同。配好后再选中另一个端口同样添加一条流。两个端口方向可以配成对称的模拟双向流量。如果不配第二端口只能做单通测试可以看到TX一直涨但RX为零这不叫双向测试很多场景下不能说明问题。3.4 启动流量并查看统计回到主界面选中两个端口点击Start按钮。GUI的统计面板会开始刷新TX、RX、丢包、时延等计数。如果一切正常你会看到两个端口都有发送和接收计数而且丢包率为0。这轮跑通后先点Stop再把当前配置保存下来方便后续复用。GUI里的统计刷新是秒级的拿它判断趋势可以但要写进测试报告还是建议用TRex的Python API取精确值。如果看到的计数是“TX持续涨、RX一直0”不用急着改流模板先在两个端口之间直接用网线短接做一次回环测试。TRex端口A发出、端口B收下如果短接后计数正常问题出在被测设备配置或对外接线如果短接后还是0回头查流模板的目的MAC是不是写了一个不存在的地址。这个“打流自环”的习惯我每次都会强调它能在一分钟内区分是打流端的问题还是被测设备的问题比盯着面板猜有效得多。4. 把参数调对图形界面里最值得改的五个配置项4.1 端口速率与带宽限制无状态流量最核心的配置是速率GUI里常见三种表达方式bps、pps、线速百分比。很多人在这里被绕晕。bps每秒发送的比特数适合描述带宽占用pps每秒发送的包数适合描述转发能力线速百分比则依赖当前帧长因为线速对应的pps会随帧长变化。以万兆口为例64字节帧满线速大约14.88Mpps而1518字节帧满线速只有不到0.81Mpps。如果你配“50%线速”却没指定帧长GUI只能拿当前流的固定帧长去换算。混合帧长场景下这个百分比就不准了。我的做法是需要明确发包率时一律用pps需要明确带宽占用时用bps只有在对比设备在不同帧长下的线速表现时才用百分比并且保证对比条件是同一组帧长。GUI里设置限速后建议再设一个包数上限或时长上限。持续模式最容易出现的问题是一忙起来忘记点Stop流量跑了整晚不仅把测试设备打崩还可能影响同网段的现网业务。所以凡是持续时间测试我都会在“duration”字段里写一个显式秒数比如3600秒。不写是玄学写了才是后悔药。4.2 帧大小与包数分布固定帧长测的是设备性能极限但现网流量是大小帧混合的。以太网测试里常用IMIXInternet Mix分布模拟不同业务的比例。GUI的流编辑器里可以给一条流配置多个帧长段每个段有自己的发送比例。最基础的做法是先测固定帧长序列64、128、256、512、1024、1518。把每种帧长的pps上限打出来你就能看到设备的转发瓶颈在哪里。有些设备64字节只能跑满6Mpps但512字节能跑满线速说明它的处理瓶颈在报文个数而不是字节吞吐。想贴近业务再配一组IMIX。比例可以参考常见的现网分布大约40%的小包、30%中包、30%大包。这个比例不神圣按你的业务模型调。只要记得在GUI里把流配置的帧长模式改成多段分布不要每段建一条流那样统计拆得零碎最后对不上loss数。4.3 流表flows和多流的配比被测设备如果做ECMP或NAT单条5元组流测不出来效果。GUI里可以在一条流的IP字段或端口字段里配置范围让它自动展开成大量flow。比如源IP从10.0.0.1到10.0.0.255目的端口从1024到65535这样可以构造上万个独立会话。配置多流时要保证每个flow收到的发包数足够。假设你每秒发1Mpps总共只有1000个flow那每flow每秒1000包还好如果flow数量开到100万每flow每秒只有1个包很多依赖状态的设备来不及建立条目测试结果会失真。我给个参考测设备会话表容量时让每个flow每秒至少4到8个包给设备处理逻辑留出余量。GUI里对应的概念是“包循环次数”或者用Python API里的count参数。调法不唯一但思路是统一的看被测对象的并发能力设置flow数量而不是无脑开满。4.4 latency和丢包统计的开关TRex统计时延用的是单独的latency流它不参与带宽计量而是混在业务流里一起发往对端再由对端打时间戳并返回。GUI里要为参与时延统计的端口指定一条latency流通常是固定小包。如果没开这个开关统计面板里的latency字段会一直是0或者异常值很多人误以为设备时延为零其实是自己没配。丢包统计依赖TX和RX计数相减。但要注意如果被测设备改了包内容或做了NATTRex回收到包后可能认不出这条流RX会偏低误报丢包。遇到这种情况先把被测设备的NAT功能关掉确认转发路径是纯路由再回来测丢包。如果要测NAT设备建议改用有状态模式并显式配置地址映射。时延数据的另一个坑是“尾巴”很多设备在满负荷时时延的P99和P99.9可能差很多。只看平均时延看不出问题。TRex的latency统计里有min、max、average等字段我建议至少看max和P99档它们比average更能暴露缓存被填满的问题。4.5 持续模式与burst的差别GUI里的Stream发送模式大致有单次、持续、burst三种。单次适合定位问题发固定包数后停止持续适合跑长时间稳定性burst适合测试设备缓存、调度和限速策略。实际测试时最隐蔽的问题是burst模式下的pps峰值。很多人设置了burst总量却没注意要求的pps是否超出网卡线速。比如要求一秒内打出1百万个1518字节包10G端口根本不可能完成那么GUI会按实际最大线速慢慢发burst时间被拉长看起来像是设备吞吐不足实际是打流端PPS已经到顶。正确的做法是先按帧长算出该网卡线速对应的pps上限再回头配burst参数。持续模式跑久了如果发现丢包率慢慢爬升先别急着怀疑设备。把TRex服务端的大页使用情况和CPU占用调出来看一眼记住它们的基线和峰值。打流端通常跑在几百万ppsCPU和内存波动都会体现成测试结果抖动这个锅不该让被测设备背。5. TRex GUI避坑指南常见报错、黑匣子与替代方案5.1 GUI连不上服务端先查这三处现象点击Connect后进度条转了一圈返回connection refused或timeoutGUI一直停在登录页。原因多数在三处服务端没正常监听、客户端和server版本对不上、网络中间设备拦了TCP端口。解决先在服务端所在机器执行ss -ltn | grep 4501确认端口在监听。如果没有输出说明t-rex-64没起来或者不是正常启动状态。检查服务端终端日志看是不是卡在平台初始化阶段。确认监听后再从客户端机器telnet server_ip 4501看看TCP层通不通。如果中间有管理防火墙放行这个端口云环境里还要看安全组。版本问题比较隐蔽我遇到过GUI能连上但握手失败的情况最后统一换成同版本号连接立刻恢复。5.2 端口不upDPDK绑定和普通网卡的冲突现象服务端启动正常但GUI里物理端口列表显示DOWN右键起端口也没反应。原因多半是网卡没有成功绑定到DPDK驱动或者配置文件和实际PCI地址对应不上。解决回到服务端跑一次./dpdk-devbind.py --status看目标网卡的driver列是不是igb_uio或vfio-pci。如果还是e1000e、ixgbe这类内核驱动说明没绑成功。重新绑定前先把网卡down掉否则内核驱动持有着设备。配置文件的port_info顺序必须和dpdk-devbind.py --status里看到的PCI顺序一致顺序错乱会导致TRex认为端口A对应了另一张网卡。还有一类情况是板载网卡不在DPDK支持列表里例如某些瑞昱芯片老老实实换一张Intel或Mellanox的网卡别在GUI上死磕。5.3 通了但没有流量这是新手最常翻车的点现象端口显示UPstats面板也在刷新但TX发送计数一直不涨或者TX涨了RX始终是0。原因可以拆成两类发送不出去和发出去了回不来。解决发送不出去先看流模板是否真正绑定到了端口。GUI里新建Stream后如果没勾选端口模板是游离状态。再看目的MACTRex默认包的目的MAC需要填实际转发路径上的下一跳MAC不是随便写的。如果目的MAC是广播或全零很多设备会直接丢弃。打开GUI里的Capture抓包功能抓几个包看发出的是什么如果抓到的包目的MAC不是你预期值回去改。发出去了回不来先检查对端TRex端口有没有启动收发。把两个端口用网线直连绕过被测设备做回环再Start一次。回环通过问题就在中间链路或被测设备配置回环不通过打流配置仍然有问题。这个排查顺序能省掉大半天瞎猜的时间。5.4 统计数字异常时序和聚合口径搞错了现象TX和RX数值巨大到离谱或者丢包率一会100%一会0时延字段永远是0。原因大多数不是设备问题而是统计口径没搞清。第一个坑是计数类型。TRex的RX统计里既有对端口回包的计数也有本端口收到的对端流计数。两台设备手动配了不对称的流就可能出现一端的RX远高于另一端的TX。第二个坑是时延开关没有配置latency流的情况下latency字段显示的是空值不能解读为“时延为0”。第三个坑是统计周期GUI面板秒级刷新如果你想取某一秒的精确pps需要看瞬时速率而不是累计计数两者差异在burst测试里特别明显。解决方式很简单先用网线把TRex两个端口短接做一个已知流量对测。比如发100万包短接后RX应该精确等于TX减去少量实际丢包。这个基准如果都对不上说明测试环境里有环路、有其他终端在抢IP或者统计选错了字段。5.5 没有图形界面环境怎么办用CLI和Python客户端顶上现象TRex服务端所在的机器是机房无桌面环境SSH过去后发现GUI根本起不来报错找不到DISPLAY。原因很简单GUI需要X11或Wayland一类图形环境。解决首选方案是“远程连GUI”把GUI装在你本地的Windows或Linux开发机上通过--server指向机房TRex服务端不需要服务端有桌面。其次是使用CLI客户端trex-console它也能看端口状态、加载流模板、启动停止、抓包只是操作体验不如GUI。再往后就是Python API适合你把同样的参数固化成脚本。这里不要为了一个小GUI给服务器装完整套桌面既增加攻击面又白白吃几十GB的磁盘和内存不值得。6. 从GUI到自动化把图形界面当调试台把Python脚本当生产工具等你在GUI里把一条流调到预期的pps并且确认丢包、时延都符合预期下一步建议把同样的配置固化成Python脚本让回归测试可以无人值守地跑。我现在的习惯是GUI负责前期探索Python负责最终落地。下面是一段无状态模式的Python脚本骨架用来演示从连接、下发流量到取统计的完整流程from trex_stl_lib.api import * # 连接 TRex 服务端 c STLClient(server192.168.100.10, port4501) c.connect() c.reset(ports[0, 1]) # 构造一条 UDP 流64字节小包以 100kpps 发 10 万个包后停止 packet Ether(dst00:0c:29:aa:bb:cc)/IP(src10.0.0.1, dst20.0.0.1)/UDP() stream STLStream( packetpacket, modeSTLTXSingleBurst(pps100000, total_pkts100000) ) c.add_streams(stream, ports0) c.clear_stats() c.start(ports0) c.wait_to_finish() stats c.get_stats() print(TX bytes:, stats[0][obase]) print(RX bytes:, stats[1][ibase]) c.disconnect()这里Ether/IP/UDP指定了二层和三层字段STLTXSingleBurst表示单次突发模式pps100000限制发包速率total_pkts100000控制总量。wait_to_finish会阻塞到流量发完便于脚本按顺序执行。obase和ibase是常用计数项分别表示发出的总字节和收到的总字节字段名在不同版本SDK里基本一致。把这段脚本接上测试用例的断言逻辑比如丢包率大于0.01%就判定不通过一个基础的性能回归任务就成型了。GUI里调整参数时注意看右下角生成的对应字段名很多GUI操作最终都能映射到Python API关键字两边对照着学能少走很多弯路。我踩过最深的坑是GUI跑得好好的换成Python脚本后结果不一致。原因是脚本连接后没有reset(ports[0,1])上一轮测试留下的流模板还挂着新流叠加导致pps翻倍。所以现在我的脚本里连接后第一件事永远是reset清场而不是直接加流。这个习惯救了我很多次。希望帮到你。本文还有配套的精品资源点击获取 Cisco TRex图形界面客户端：架构、部署与避坑指南
简介Cisco开源流量测试工具TRex的图形界面客户端面向网络设备测试与运维工程师旨在把TRex从命令行的复杂操作中解放出来通过可视化面板完成端口配置、流量模板编辑与统计结果监控帮助用户快速开展性能测试和压力验证。资源包共499个文件体积仅1.05MB内容组织清晰291个Java源码构成核心逻辑50个FXML文件定义JavaFX界面布局8个CSS负责界面主题另含18个PCAP报文样本可直接用于回放测试以及YAML、XML、JSON等多格式配置样例覆盖了GUI客户端从界面展示到数据交互的完整链路。目前已有265人学习下载。对希望快速掌握TRex图形化使用方式的测试工程师或想借鉴JavaFX项目结构进行二次开发的开发者而言这份资源提供了可直接运行的源码、界面素材、抓包样例与配置模板同时保留了Gradle构建入口和跨平台启动脚本可显著缩短工具搭建与功能验证的时间成本。1. 为什么流量测试要选Cisco TRex它和常见打流工具差在哪做网络性能测试的人手里多多少少都有几套打流工具。Cisco开源的流量测试工具TRex属于那种“第一眼不惊艳、用起来才觉得值”的选择它基于DPDK绕过内核协议栈单台普通服务器就能把万兆甚至40G口打满而且自带图形界面客户端。这个GUI不是锦上添花的玩具它把端口绑定、流量模板、实时统计从命令行黑匣子拉回可视化面板里路由交换设备的吞吐、时延、丢包测试都能在面板上直接完成。这篇笔记就围绕TRex图形界面客户端讲清楚它的架构、部署路径和踩过的坑适合正在搭建自动化测试环境的从业者参考。2. 先搞懂TRex的工作原理服务端、客户端与三种流量模型2.1 trex server 客户端架构和两个角色TRex的部署形态被我第一次接触时误判成“一个软件包跑起来就是一个整体”。实际上它把数据面和控制面分得很清楚TRex server才是真正跑流量的进程它负责从DPDK接管网卡、构造报文、发送和接收而客户端是另一个进程可以跑在同一台机器的另一个终端也可以跑在完全不同的电脑上。我们说的图形界面客户端就是控制面的一种实现它通过RPC和server通信把用户鼠标点出来的配置转成server可执行的指令。这套架构最大的好处是客户端不触碰到数据面。GUI进程再卡顿、再频繁刷新也不会影响正在运行的打流任务。我见过有人把GUI和服务端放在同一台机器上窗口拖动时CPU占用升高但打流吞吐并没有抖动原因就在于此。要是让客户端直接通过socket发原始报文那么一次垃圾回收或者一次磁盘IO都可能让统计曲线出现毛刺数据就不可信了。两者的职责可以这样理解server是发动机客户端是方向盘。生产环境里server要稳定地跑在靠近被测设备的位置最好固定CPU核、锁定大页内存而GUI可以随手开在调试电脑上调完参数关掉都不影响server继续发流。这也是TRex比很多老牌打流软件更适合自动化测试的原因之一控制面和数据面解耦后回归脚本可以随时连上来接管。角色运行位置主要职责常见形态TRex server靠近被测设备的服务器接管网卡、构造并转发报文、统计收发计数二进制程序 t-rex-64CLI 客户端任意终端交互式查看端口、下发流模板、抓包trex-consoleGUI 客户端带图形环境的开发机可视化配置端口和流、实时刷新统计trex_gui.pyPython API测试脚本或CI机器无人值守批量打流、断言丢包率trex_stl_lib.api2.2 无状态/有状态/高级状态选型先看数据面TRex的图形界面客户端启动后会看到它支持三种主要的流量模型无状态Stateless、有状态Stateful和高级有状态ASTF。很多新手一上来就纠结用哪个其实选型不复杂看被测对象对连接状态敏不敏感。无状态模式适合测转发能力只要按模板往端口上怼包不关心这些包是不是属于某个TCP连接。交换机、路由器、网关这类设备主要看吞吐用无状态模式就能说清楚问题。GUI里新建Stream时可以指定帧长、pps、源IP、目的IP、端口号等字段但它不会替你维护TCP状态机。有人拿无状态模式去测防火墙发现吞吐高得离谱因为防火墙根本没把这些散包识别成一个会话自然不执行会话表查询。这不是设备作弊是你选错了模式。有状态模式则完全不同。它基于真实会话回放把pcap包里的交互过程按连接维度重放会执行TCP三次握手、保活和拆除。防火墙、NAT网关、负载均衡器这类“连接感知”设备必须用有状态模式测。代价是服务端需要维护海量连接状态CPU和内存占用高出一大截。高级有状态模式ASTF是进阶选项它不依赖pcap文件而是用协议模板动态生成流量比如指定每秒钟建立多少条TCP连接、每条连接发多少字节。它比单纯回放更贴近自动化测试需要但配置复杂度也更高。我一般建议先测单点吞吐用Stateless要模拟现网业务连接选Stateful需要在固定时间内构造大量新建连接才考虑ASTF。2.3 图形界面客户端在这个架构里扮演什么角色图形界面客户端本质上是Python client的一个封装。它连上server后会拉取端口状态、CFG信息、当前已加载的流模板并订阅实时统计。TRex官方发行包里通常包含GUI目录入口脚本一般是trex_gui.py。启动它之前先看一眼帮助信息不同小版本的参数名会有差异死记参数反而容易翻车# 进入 GUI 所在目录后先确认客户端支持哪些启动参数 python3 trex_gui.py --help这段命令不是多余的。我遇到过有人把老教程里的--server-host直接抄过来结果程序提示Unknown argument。常见的连接参数是--server指定TRex服务端IP--port指定RPC端口服务端默认一般监听在TCP 4501。具体以--help输出和server启动日志为准。如果--help能正常打印参数列表说明Python环境基本可用下一步再考虑窗口能否弹出来。要强调一点GUI和服务端的版本尽量对齐。TRex的RPC协议会随版本增加字段老版本GUI连新服务端可能端口列表能刷出来但点启动时报“field not found”新版本GUI连老服务端则可能直接握手失败。升级TRex时我的习惯是服务端和客户端一起换只换一半的坑实在不值得踩。3. 用图形界面客户端跑通第一轮打流安装、连接与最小配置3.1 准备环境网卡、DPDK和TRex服务端在打开GUI之前服务端必须先能跑起来。先检查网卡型号不是所有网卡都能被DPDK接管。Intel的x520、x710、i350系列是常见选择Mellanox的ConnectX系列也常见。用lspci看一眼本机网卡心里有数lspci -nn | grep -i ethernet输出会列出网卡的PCI地址和型号比如02:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP。记下PCI地址后续DPDK绑定要用。接下来设置大页内存TRex收包时频繁从大页池分配mbuf没有大页很容易报内存分配失败# 临时分配 2048 个 2MB 大页合计 4GB重启后失效 echo 2048 /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages生产环境建议在/etc/sysctl.conf里配vm.nr_hugepages这样重启后不丢配置。大页大小不是越大越好4GB足够跑多数测试如果你要模拟百万级并发流再往上加。设置完后用grep Huge /proc/meminfo确认HugePages_Total不为0。接着绑定网卡到DPDK驱动。TRex发行包里一般带dpdk_setup.sh或者用dpdk-devbind.py# 先看当前哪些网卡被内核驱动占用、哪些被DPDK占用 ./dpdk-devbind.py --status确认PCI地址后把测试网卡从内核解绑绑到igb_uio./dpdk-devbind.py --bindigb_uio 0000:02:00.0 0000:02:00.1注意绑完之后这两张网卡会从操作系统里消失SSH如果只有这两张网卡你会立刻断连。所以我总是建议测试网卡和管理网卡物理分离否则只能跑回服务器前插显示器这个教训很贵。绑定完成后写TRex配置文件常见路径是/etc/trex_cfg.yaml。以下是我常用的精简模板port_info: - ip: 192.168.1.1 default_gw: 192.168.1.254 - ip: 192.168.2.1 default_gw: 192.168.2.254 platform: master_thread_id: 0 latency_thread_id: 1 dual_if: true这里的IP是TRex端口上要承载的测试地址不代表服务器管理IP一般选用私网段。master_thread_id和latency_thread_id分别表示主线程和时延统计线程绑在哪个CPU核上避免互相抢占。dual_if: true意思是两个端口联动作业适合测双工转发如果你只有一张测试网卡需要把这个字段改为false并删掉第二个port_info。启动服务端用交互模式验证配置sudo ./t-rex-64 -i启动日志会显示检测到的端口、绑定的驱动、大页数量。看到“The port 0 is up”这类输出说明server已经就绪。如果在这之前GUI就连上来只会得到一堆连接超时的红字所以顺序一定不能反。3.2 安装并启动图形界面客户端服务端跑起来后回到你的开发机准备GUI。TRex的GUI是Python写的依赖wxPython和PyYAML。在Debian/Ubuntu上先装依赖sudo apt update sudo apt install python3 python3-wxgtk4.0 python3-yaml如果你的系统没有python3-wxgtk4.0这个包用apt-cache search wx搜一下不同发行版包名会有偏差。装完依赖进入TRex发行包的GUI目录启动客户端python3 trex_gui.py --server 192.168.1.100 --port 4501--server填TRex服务端的IP也就是刚才运行t-rex-64那台机器的IP--port填RPC监听端口默认一般是4501。如果启动时窗口一闪而过多半是wxPython没装好回到上一步检查import。GUI启动后通常会有连接框填入IP和端口点Connect。连接成功后主界面会列出服务端识别到的物理端口以及它们的UP/DOWN状态。如果GUI跑在无图形环境的Linux服务器上窗口是弹不出来的。不要急着给服务器装桌面更合理的做法是把GUI放在你的笔记本上TRex服务端继续留在机房服务器里。两者之间只要TCP可达就行架构上本来就是分开的。3.3 在GUI里配置端口和流量模板连接成功后在端口列表里双击某个端口会打开端口配置窗口。这里要填的是L1/L2/L3基础信息是否启用VLAN、端口MAC地址、目的MAC、源IP、目的IP、下一跳MAC等。如果被测设备是纯二层交换机源目MAC写对就能跑如果是三层路由需要把IP和网关填上不然TRex发出的包到不了对端。接下来创建一条无状态流。在Stateless视图下选中端口右键添加Stream弹出的编辑框里有几个关键参数帧长、pps或bps速率、包数、源IP范围、目的IP范围、端口号范围。最小配置是固定帧长加固定速率帧长64字节用来压小包线速速率100000 pps包数不设上限持续发送我偏爱先拿64字节小包做基准测试因为小包最能暴露转发瓶颈。如果设备宣称能线速转发1518字节大包用64字节测还能维持一样线速那才是真nb。GUI里把速率单位切换成pps比直接写百分比线速更直观因为百分比在不同帧长下对应的pps完全不同。配好后再选中另一个端口同样添加一条流。两个端口方向可以配成对称的模拟双向流量。如果不配第二端口只能做单通测试可以看到TX一直涨但RX为零这不叫双向测试很多场景下不能说明问题。3.4 启动流量并查看统计回到主界面选中两个端口点击Start按钮。GUI的统计面板会开始刷新TX、RX、丢包、时延等计数。如果一切正常你会看到两个端口都有发送和接收计数而且丢包率为0。这轮跑通后先点Stop再把当前配置保存下来方便后续复用。GUI里的统计刷新是秒级的拿它判断趋势可以但要写进测试报告还是建议用TRex的Python API取精确值。如果看到的计数是“TX持续涨、RX一直0”不用急着改流模板先在两个端口之间直接用网线短接做一次回环测试。TRex端口A发出、端口B收下如果短接后计数正常问题出在被测设备配置或对外接线如果短接后还是0回头查流模板的目的MAC是不是写了一个不存在的地址。这个“打流自环”的习惯我每次都会强调它能在一分钟内区分是打流端的问题还是被测设备的问题比盯着面板猜有效得多。4. 把参数调对图形界面里最值得改的五个配置项4.1 端口速率与带宽限制无状态流量最核心的配置是速率GUI里常见三种表达方式bps、pps、线速百分比。很多人在这里被绕晕。bps每秒发送的比特数适合描述带宽占用pps每秒发送的包数适合描述转发能力线速百分比则依赖当前帧长因为线速对应的pps会随帧长变化。以万兆口为例64字节帧满线速大约14.88Mpps而1518字节帧满线速只有不到0.81Mpps。如果你配“50%线速”却没指定帧长GUI只能拿当前流的固定帧长去换算。混合帧长场景下这个百分比就不准了。我的做法是需要明确发包率时一律用pps需要明确带宽占用时用bps只有在对比设备在不同帧长下的线速表现时才用百分比并且保证对比条件是同一组帧长。GUI里设置限速后建议再设一个包数上限或时长上限。持续模式最容易出现的问题是一忙起来忘记点Stop流量跑了整晚不仅把测试设备打崩还可能影响同网段的现网业务。所以凡是持续时间测试我都会在“duration”字段里写一个显式秒数比如3600秒。不写是玄学写了才是后悔药。4.2 帧大小与包数分布固定帧长测的是设备性能极限但现网流量是大小帧混合的。以太网测试里常用IMIXInternet Mix分布模拟不同业务的比例。GUI的流编辑器里可以给一条流配置多个帧长段每个段有自己的发送比例。最基础的做法是先测固定帧长序列64、128、256、512、1024、1518。把每种帧长的pps上限打出来你就能看到设备的转发瓶颈在哪里。有些设备64字节只能跑满6Mpps但512字节能跑满线速说明它的处理瓶颈在报文个数而不是字节吞吐。想贴近业务再配一组IMIX。比例可以参考常见的现网分布大约40%的小包、30%中包、30%大包。这个比例不神圣按你的业务模型调。只要记得在GUI里把流配置的帧长模式改成多段分布不要每段建一条流那样统计拆得零碎最后对不上loss数。4.3 流表flows和多流的配比被测设备如果做ECMP或NAT单条5元组流测不出来效果。GUI里可以在一条流的IP字段或端口字段里配置范围让它自动展开成大量flow。比如源IP从10.0.0.1到10.0.0.255目的端口从1024到65535这样可以构造上万个独立会话。配置多流时要保证每个flow收到的发包数足够。假设你每秒发1Mpps总共只有1000个flow那每flow每秒1000包还好如果flow数量开到100万每flow每秒只有1个包很多依赖状态的设备来不及建立条目测试结果会失真。我给个参考测设备会话表容量时让每个flow每秒至少4到8个包给设备处理逻辑留出余量。GUI里对应的概念是“包循环次数”或者用Python API里的count参数。调法不唯一但思路是统一的看被测对象的并发能力设置flow数量而不是无脑开满。4.4 latency和丢包统计的开关TRex统计时延用的是单独的latency流它不参与带宽计量而是混在业务流里一起发往对端再由对端打时间戳并返回。GUI里要为参与时延统计的端口指定一条latency流通常是固定小包。如果没开这个开关统计面板里的latency字段会一直是0或者异常值很多人误以为设备时延为零其实是自己没配。丢包统计依赖TX和RX计数相减。但要注意如果被测设备改了包内容或做了NATTRex回收到包后可能认不出这条流RX会偏低误报丢包。遇到这种情况先把被测设备的NAT功能关掉确认转发路径是纯路由再回来测丢包。如果要测NAT设备建议改用有状态模式并显式配置地址映射。时延数据的另一个坑是“尾巴”很多设备在满负荷时时延的P99和P99.9可能差很多。只看平均时延看不出问题。TRex的latency统计里有min、max、average等字段我建议至少看max和P99档它们比average更能暴露缓存被填满的问题。4.5 持续模式与burst的差别GUI里的Stream发送模式大致有单次、持续、burst三种。单次适合定位问题发固定包数后停止持续适合跑长时间稳定性burst适合测试设备缓存、调度和限速策略。实际测试时最隐蔽的问题是burst模式下的pps峰值。很多人设置了burst总量却没注意要求的pps是否超出网卡线速。比如要求一秒内打出1百万个1518字节包10G端口根本不可能完成那么GUI会按实际最大线速慢慢发burst时间被拉长看起来像是设备吞吐不足实际是打流端PPS已经到顶。正确的做法是先按帧长算出该网卡线速对应的pps上限再回头配burst参数。持续模式跑久了如果发现丢包率慢慢爬升先别急着怀疑设备。把TRex服务端的大页使用情况和CPU占用调出来看一眼记住它们的基线和峰值。打流端通常跑在几百万ppsCPU和内存波动都会体现成测试结果抖动这个锅不该让被测设备背。5. TRex GUI避坑指南常见报错、黑匣子与替代方案5.1 GUI连不上服务端先查这三处现象点击Connect后进度条转了一圈返回connection refused或timeoutGUI一直停在登录页。原因多数在三处服务端没正常监听、客户端和server版本对不上、网络中间设备拦了TCP端口。解决先在服务端所在机器执行ss -ltn | grep 4501确认端口在监听。如果没有输出说明t-rex-64没起来或者不是正常启动状态。检查服务端终端日志看是不是卡在平台初始化阶段。确认监听后再从客户端机器telnet server_ip 4501看看TCP层通不通。如果中间有管理防火墙放行这个端口云环境里还要看安全组。版本问题比较隐蔽我遇到过GUI能连上但握手失败的情况最后统一换成同版本号连接立刻恢复。5.2 端口不upDPDK绑定和普通网卡的冲突现象服务端启动正常但GUI里物理端口列表显示DOWN右键起端口也没反应。原因多半是网卡没有成功绑定到DPDK驱动或者配置文件和实际PCI地址对应不上。解决回到服务端跑一次./dpdk-devbind.py --status看目标网卡的driver列是不是igb_uio或vfio-pci。如果还是e1000e、ixgbe这类内核驱动说明没绑成功。重新绑定前先把网卡down掉否则内核驱动持有着设备。配置文件的port_info顺序必须和dpdk-devbind.py --status里看到的PCI顺序一致顺序错乱会导致TRex认为端口A对应了另一张网卡。还有一类情况是板载网卡不在DPDK支持列表里例如某些瑞昱芯片老老实实换一张Intel或Mellanox的网卡别在GUI上死磕。5.3 通了但没有流量这是新手最常翻车的点现象端口显示UPstats面板也在刷新但TX发送计数一直不涨或者TX涨了RX始终是0。原因可以拆成两类发送不出去和发出去了回不来。解决发送不出去先看流模板是否真正绑定到了端口。GUI里新建Stream后如果没勾选端口模板是游离状态。再看目的MACTRex默认包的目的MAC需要填实际转发路径上的下一跳MAC不是随便写的。如果目的MAC是广播或全零很多设备会直接丢弃。打开GUI里的Capture抓包功能抓几个包看发出的是什么如果抓到的包目的MAC不是你预期值回去改。发出去了回不来先检查对端TRex端口有没有启动收发。把两个端口用网线直连绕过被测设备做回环再Start一次。回环通过问题就在中间链路或被测设备配置回环不通过打流配置仍然有问题。这个排查顺序能省掉大半天瞎猜的时间。5.4 统计数字异常时序和聚合口径搞错了现象TX和RX数值巨大到离谱或者丢包率一会100%一会0时延字段永远是0。原因大多数不是设备问题而是统计口径没搞清。第一个坑是计数类型。TRex的RX统计里既有对端口回包的计数也有本端口收到的对端流计数。两台设备手动配了不对称的流就可能出现一端的RX远高于另一端的TX。第二个坑是时延开关没有配置latency流的情况下latency字段显示的是空值不能解读为“时延为0”。第三个坑是统计周期GUI面板秒级刷新如果你想取某一秒的精确pps需要看瞬时速率而不是累计计数两者差异在burst测试里特别明显。解决方式很简单先用网线把TRex两个端口短接做一个已知流量对测。比如发100万包短接后RX应该精确等于TX减去少量实际丢包。这个基准如果都对不上说明测试环境里有环路、有其他终端在抢IP或者统计选错了字段。5.5 没有图形界面环境怎么办用CLI和Python客户端顶上现象TRex服务端所在的机器是机房无桌面环境SSH过去后发现GUI根本起不来报错找不到DISPLAY。原因很简单GUI需要X11或Wayland一类图形环境。解决首选方案是“远程连GUI”把GUI装在你本地的Windows或Linux开发机上通过--server指向机房TRex服务端不需要服务端有桌面。其次是使用CLI客户端trex-console它也能看端口状态、加载流模板、启动停止、抓包只是操作体验不如GUI。再往后就是Python API适合你把同样的参数固化成脚本。这里不要为了一个小GUI给服务器装完整套桌面既增加攻击面又白白吃几十GB的磁盘和内存不值得。6. 从GUI到自动化把图形界面当调试台把Python脚本当生产工具等你在GUI里把一条流调到预期的pps并且确认丢包、时延都符合预期下一步建议把同样的配置固化成Python脚本让回归测试可以无人值守地跑。我现在的习惯是GUI负责前期探索Python负责最终落地。下面是一段无状态模式的Python脚本骨架用来演示从连接、下发流量到取统计的完整流程from trex_stl_lib.api import * # 连接 TRex 服务端 c STLClient(server192.168.100.10, port4501) c.connect() c.reset(ports[0, 1]) # 构造一条 UDP 流64字节小包以 100kpps 发 10 万个包后停止 packet Ether(dst00:0c:29:aa:bb:cc)/IP(src10.0.0.1, dst20.0.0.1)/UDP() stream STLStream( packetpacket, modeSTLTXSingleBurst(pps100000, total_pkts100000) ) c.add_streams(stream, ports0) c.clear_stats() c.start(ports0) c.wait_to_finish() stats c.get_stats() print(TX bytes:, stats[0][obase]) print(RX bytes:, stats[1][ibase]) c.disconnect()这里Ether/IP/UDP指定了二层和三层字段STLTXSingleBurst表示单次突发模式pps100000限制发包速率total_pkts100000控制总量。wait_to_finish会阻塞到流量发完便于脚本按顺序执行。obase和ibase是常用计数项分别表示发出的总字节和收到的总字节字段名在不同版本SDK里基本一致。把这段脚本接上测试用例的断言逻辑比如丢包率大于0.01%就判定不通过一个基础的性能回归任务就成型了。GUI里调整参数时注意看右下角生成的对应字段名很多GUI操作最终都能映射到Python API关键字两边对照着学能少走很多弯路。我踩过最深的坑是GUI跑得好好的换成Python脚本后结果不一致。原因是脚本连接后没有reset(ports[0,1])上一轮测试留下的流模板还挂着新流叠加导致pps翻倍。所以现在我的脚本里连接后第一件事永远是reset清场而不是直接加流。这个习惯救了我很多次。希望帮到你。本文还有配套的精品资源点击获取