NS2网络仿真从入门到实践：rar编译、Tcl修改与trace分析指南

简介：NS2（Network Simulator 2）是经典的开源网络模拟器，这份代码示例包面向刚接触NS2的初学者，覆盖从Tcl脚本编写、协议仿真到结果分析的完整入门路径。压缩包共28个文件，约623KB，以tcl脚本为主，辅以h/cc源码、awk统计脚本及nam/tr输出文件；tcl用于搭建仿真场景，h/cc体现协议实现，awk负责解析仿真数据，nam/tr可输出可视化轨迹，目录按章节组织，便于对照学习。目前已有222人学习下载，适合作为网络课程实验或自学仿真技术的配套参考资料。代码内容依托事件驱动模拟机制，涵盖TCP/IP协议模拟、DSDV等路由协议、TCP拥塞控制、移动性模型、吞吐量与延迟统计，以及OOPSI接口和图形化输出等关键模块；结合nam动画可直观观察数据包转发路径与节点运动。通过修改参数并重新运行，读者能直观比较不同配置下的网络表现，逐步掌握NS2仿真实验的设计、排错与性能分析方法。

1. 拿到 ns2.rar 这一步，决定了你后面 NS2 之路的顺逆

很多做网络仿真的同学手里都有一份 ns2.rar，里面是 NS2 的代码。NS2 虽然老，但在 MANET、无线传感网和传统 TCP 研究中仍是硬通货。这份压缩包通常包括 NS2 的完整源码、补丁和一堆示例 Tcl 脚本，但真正用它跑出第一个仿真结果的人，比下载它的人少得多。这篇文章讲的是从解压 rar 到编译、改代码、跑仿真、避坑、批量出数据的完整路径，适合手里有这份代码、或者正打算用 NS2 做课题的读者。新手能照做，老手也能看到几个平时容易忽略的边界。

2. 先看包里有什么，再动手：NS2 代码包结构、编译顺序与最简命令

2.1 解压前先识别包里是 NS2 全量源码还是裸补丁

拿到 ns2.rar 后，第一件事不是双击解压，而是列出目录内容。常见做法是用unrar l ns2.rar或者7z l ns2.rar看一眼。一份典型的 NS2 代码包会出现ns-allinone-2.35/这样的顶层目录，里面是ns-2.35、tcl8.5.10、tk8.5.10、otcl-1.14、libpcap和nam-1.15。但也有的包只放了一个ns-2.35/源码树，这时候你还需要另外补齐 otcl 和 tcl 的库，后面编译会麻烦很多。

我一般先看包顶层的文件数量，如果是几百个文件的源码树，基本可以确定是完整的 ns-allinone；如果只有十几个文件，那大概率是二次开发过的补丁包，缺少编译链。解压时最好隔离到一个独立工作目录，别随意撒到用户根目录下面。命令是这样：

mkdir -p ~/ns2_work && cd ~/ns2_work 7z x ../ns2.rar -o./ns2_work chmod -R u+rw ./ns2_work

这里的-o参数指定输出目录，解压后立刻chmod -R u+rw，因为这份 rar 很可能是从 Windows 侧压出来的，文件权限默认是只读，后面你改源码时不会遇到权限错误。解压完先不急着编译，再看一眼目录结构是否完整。

2.2 ns-allinone-2.35 的模块结构与编译顺序

ns-allinone 内部的模块之间有依赖顺序。./install脚本会按顺序自动跑，但一旦某个模块失败，它会停在那里。理解这个顺序能帮你快速判断报错来源。一般顺序是 tcl、tk、otcl、tclcl、ns、nam。其中 otcl 依赖 tcl/tk，ns 依赖 otcl 和 tclcl，nam 依赖 tk 和 libXmu。

模块依赖关系可以用一个表说明：

如果你看到configure报错说找不到 Tcl，那问题出在 tcl/tk 没有先编译，或者系统里没有对应的tclConfig.sh。这比直接看 ns 的报错更有用。我习惯在顶层跑一次./install，但如果它中途翻车，不要从头重复跑，而是进入失败模块单独编译，成功后回到上层继续。这样省去很多重复 configure 的时间。

2.3 编译环境选择：为什么新版 gcc 会让 rar 变成废纸

NS2 源码写成时主流编译器是 gcc 3/4，里面大量用了stl_hash_fun.h、hash_map这类旧头文件。新版 libstdc++ 把它们挪到了 ext 命名空间，直接导致编译失败。这不是你这份 rar 的问题，是工具链错配。我自己最稳的组合是 Ubuntu 18.04 加 gcc-4.8，Ubuntu 20.04 以上需要手动装 gcc-4.8 或者直接在 Docker 里用老镜像。

依赖包也要装全，否则 configure 会在各种地方中断。Ubuntu/Debian 下可以这样装：

sudo apt-get update sudo apt-get install -y make gcc-4.8 g++-4.8 flex bison perl \ tcl8.5 tcl8.5-dev tk8.5 tk8.5-dev libxmu-dev libxmu-dev sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.8 50 sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-4.8 50

其中gcc-4.8和g++-4.8在 Ubuntu 20.04 的默认源里可能没有，需要先加ubuntu-toolchain-r/testPPA。libxmu-dev是 nam 的绘图依赖，缺了它 nam 会黑屏或报错。update-alternatives是让gcc默认指向 4.8，防止系统里的 gcc-9 干扰。

装完之后验证一下：

gcc --version

看到gcc (Ubuntu 4.8.5-...)就对了。如果还是 gcc-9，检查ls -l /usr/bin/gcc的软链接，手动调整优先级。

2.4 最简编译命令与安装环境变量

进入 ns-allinone-2.35 目录后，最快路径是先跑./install。但有时候 install 脚本会把 tcl 配置到它自带的路径，而你想用系统 tcl，可以在 ns-2.35 下手动执行 configure：

cd ns-2.35 ./configure --disable-gcc-warning --with-tcl=/usr/lib/tcl8.5 --with-tk=/usr/lib/tk8.5 make -j2 make install

这里的--disable-gcc-warning不是官方选项，但实际很管用，它能跳过旧代码里那一堆 warning，否则有些版本会因为 warning 被当作 error 直接停掉。--with-tcl和--with-tk指向系统库路径，确保版本是 8.5 而不是 8.6，因为 NS2 内部对 Tcl 8.6 的兼容性并不好。-j2限制并行编译数，不要加-j8，旧 Makefile 并行一多就会出现头文件互相覆盖的诡异问题。

编译完成后，把下面几行写进~/.bashrc：

export NS2_HOME=~/ns2_work/ns-allinone-2.35 export PATH=$NS2_HOME/ns-2.35:$NS2_HOME/nam-1.15:$PATH export LD_LIBRARY_PATH=$NS2_HOME/otcl-1.14:$NS2_HOME/lib

然后source ~/.bashrc。验证环境：

ns -e "puts {NS2 OK}"

能输出NS2 OK就说明ns可执行文件找到了。如果提示 command not found，说明 PATH 里的路径不匹配；如果报动态库错误，多半是LD_LIBRARY_PATH没指向真正的库位置。

2.5 编译前先跑通自带的 hello 示例

编译成功先别急着写自己的脚本，先跑一个 NS2 自带的例子。ns-2.35/tcl/ex/simple.tcl或者ns-tutorial/examples/tiny.tcl都可以。命令直接：

cd ns-2.35 ns tcl/ex/simple.tcl

跑完会生成out.tr或trace.tr。用head -5看一眼文件内容。如果能看到+、-、r、d四类事件，说明整个链路已经通了，你的 rar 包里的源码没缺东西，后面改协议才有基础。如果这个 hello 都跑不出 trace，回头检查 2.3 的 gcc 版本或 2.4 的 PATH，别急着往下走。

3. 读懂 NS2 代码：从 Tcl 脚本到 C++ 协议的修改路线

3.1 OTcl 和 C++ 怎么绑在一起：一个属性的生命轨迹

NS2 是双语言架构。你在.tcl脚本里写的set tcp [new Agent/TCP]，其实是在 OTcl 层创建一个对象，这个对象的 C++ 实体映射到TcpAgent类。两者通过 tclcl 绑定机制连接。C++ 构造函数里会调用bind("window_", &window_)，把 OTcl 变量名和成员变量地址挂钩。所以你在 Tcl 里写$tcp set window_ 20时，底层的赋值会直接写入 C++ 的window_成员，不需要重新编译。

这个机制决定了修改协议有两种路线：一种是参数已经在 C++ 里 bind 过，直接改 Tcl 脚本；另一种是参数没暴露，必须改 C++ 代码再加 bind。区分方法很简单，在 Tcl 里尝试设置一个变量，如果运行时报错说 invalid option 或 unknown variable，那它就还没绑定。

3.2 Tcl 侧改参数：实例设置和类默认设置的区别

大部分时候我们只需要调参数，不需要动 C++。比如要改 TCP 初始拥塞窗口，在 Tcl 脚本里可以用：

set tcp [new Agent/TCP] $tcp set window_ 20 $tcp set packetSize_ 1000

这样只影响当前创建的这个 Agent。如果想让所有后续创建的 TCP Agent 都用同一套默认值，应该在创建之前设置类默认值：

Agent/TCP set window_ 20 set tcp [new Agent/TCP]

这两种写法的区别很大。用了类默认值之后，后面任何新建 TCP 对象都拿 20；而实例设置只覆盖当前对象。我看过很多人把类默认值写在对象创建之后，结果整场仿真只有第一个节点变了，其他节点全是旧行为。

3.3 C++ 侧改常数：以 TCP 初始拥塞窗口为例

如果某项参数没有绑定到 OTcl，就必须直接改 C++。最常见的例子是 TCP 初始拥塞窗口，很多 NS2 版本里它没有暴露成 Tcl 可调变量，而是硬编码在源码中。你可以这样找：

cd ns-2.35/tcp grep -n "cwnd_" tcp.cc tcp.h | head -20

找到cwnd_ = 2;或者类似赋值，把它改成你想要的初始值。我一般会同时检查构造函数和init()函数，因为有的版本在两个地方都赋了初值。改完以后回到ns-2.35目录重新编译：

make clean make -j2

注意先make clean，否则有可能新值没编译进去。这一步的坑会在第 5 章细说。

3.4 新增一个自定义 Agent 类：完整骨架与 Makefile 修改

如果你的需求不是调参数，而是加一个新协议类，那要动的地方就多了。常见做法是在ns-2.35/tcp/目录下新建myagent.cc和myagent.h，然后在 Makefile 里加入编译目标。

头文件骨架：

// myagent.h #ifndef NS_MYAGENT_H #define NS_MYAGENT_H #include "agent.h" class MyAgent : public Agent { public: MyAgent(); virtual void recv(Packet* p, Handler* h); protected: int my_var_; }; #endif

实现文件：

// myagent.cc #include "myagent.h" #include "packet.h" #include "tclcl.h" MyAgent::MyAgent() : Agent(PT_MYAGENT) { my_var_ = 1; } void MyAgent::recv(Packet* p, Handler* h) { // 在这里写收包逻辑 Packet::free(p); }

然后要有 OTcl 绑定，让 Tcl 层能new Agent/MyAgent：

static class MyAgentClass : public TclClass { public: MyAgentClass() : TclClass("Agent/MyAgent") {} TclObject* create(int, const char*const*) { return (new MyAgent); } } class_myagent;

这三段代码中，PT_MYAGENT是一个协议类型编号，需要在packet.h的枚举里注册。如果你漏了这步，Tcl 里创建对象时会报 invalid protocol type。

Makefile 的处理：打开ns-2.35/Makefile，找到OBJ_CC那一行，在末尾追加tcp/myagent.o。然后编译：

make -j2

3.5 编译新代码后的验证逻辑

新增协议后不能只看编译通过，还要用一小段 Tcl 脚本验证。比如创建 Agent，把它挂到节点，然后发一个包，检查 trace 文件里是否出现你预设的协议类型。最简验证脚本：

set ns [new Simulator] $ns trace-all [open mytest.tr w] set n0 [$ns node] set n1 [$ns node] $ns duplex-link $n0 $n1 1Mb 10ms DropTail set a [new Agent/MyAgent] $ns attach-agent $n0 $a set b [new Agent/MyAgent] $ns attach-agent $n1 $b $ns connect $a $b $ns at 0.1 "$a sendmsg" $ns at 1.0 "$ns halt" $ns run

跑完后cat mytest.tr，如果能看到AGT层的发送事件，说明协议类已经接入了事件循环。如果什么都没有，优先检查PT_MYAGENT是否正确、sendmsg函数是否被你实现了。这里sendmsg是 Agent 自带的方法，但也可以直接继承默认实现。

4. 运行仿真并把 trace 变成有效数据：Tcl模板、awk 与 gnuplot 的配合

4.1 Tcl 仿真脚本最小模板：两条链路和一点流量

写 NS2 仿真脚本最怕一开始就堆很多节点。我自己的习惯是最小跑通一个双节点链路，再加复杂拓扑。下面是一个可以直接使用的模板：

set ns [new Simulator] $ns trace-all [open trace.tr w] $ns namtrace-all [open out.nam w] set n0 [$ns node] set n1 [$ns node] $ns duplex-link $n0 $n1 1Mb 10ms DropTail set tcp [new Agent/TCP] set sink [new Agent/TCPSink] $ns attach-agent $n0 $tcp $ns attach-agent $n1 $sink $ns connect $tcp $sink set app [new Application/FTP] $app attach-agent $tcp $ns at 0.1 "$app start" $ns at 50.0 "$app stop" $ns at 51.0 "$ns halt" $ns run

这段代码里，Simulator是仿真的顶层容器，trace-all打开 trace 文件的写入通道，namtrace-all生成 nam 可视化文件。duplex-link的参数是带宽、延迟和队列管理类型。Agent/TCP是发送方，TCPSink是接收方，两者通过connect建立连接。Application/FTP只是持续发送数据，适合验证拥塞控制。

运行命令是ns simple.tcl。每次运行前建议删掉旧的 trace.tr，或者把 trace 文件名改成带场景编号的，不然会覆盖之前的结论。

4.2 trace 文件各字段的含义和分版本陷阱

NS2 的 trace 文件本质是文本行，每行代表一个包事件。常见格式分为老版和新版。老版是事件类型、时间、节点、网关等位置，新版增加了-t、-s、-d等带标签的字段。所以分析 trace 前必须先head -5 trace.tr看结构，不能一套 awk 脚本通吃。

以最典型的老格式为例：

+ 0.1 0 1 tcp 1000 ------- 1 0.1 0.1 - 0.1 0 1 tcp 1000 ------- 1 0.1 0.1 r 0.100002 1 0 tcp 1000 ------- 1 0.1 0.1 d 0.1002 0 1 tcp 1000 ------- 1 0.1 0.1

第一字段是事件：+表示包入队，-表示包出队，r表示接收，d表示丢弃。第二个字段是时间。第三和第四字段是源节点和目的节点，但这里要注意有的是src dst，有的版本是from to。第五字段是协议类型，比如 tcp、udp、ack。第六字段是包大小。后面的字段是流 ID 和标志位。

不同 NS2 版本的顺序确实有差异，所以我在写 awk 前一般会先用一个简单命令确认每列内容：

awk '{print $1, $2, $3, $4, $5}' trace.tr | head -5

这样能看到事件、时间、节点和协议是否在预期位置。

4.3 用 awk 提取吞吐量、延迟与丢包率

吞吐量是接收端收到的字节数除以仿真时间。下面这段 awk 统计接收到的 tcp 包：

# throughput.awk BEGIN { bytes = 0 last_time = 0 } $1 == "r" && $8 == "tcp" { bytes += $6 last_time = $2 } END { printf "throughput = %.2f Kbps\n", bytes * 8 / last_time / 1000 }

这里的$6是包大小字段，$8是协议类型。如果你的 trace 格式不同，把字段序号替换一下即可。最后用last_time做分母，避免仿真尾部没有事件导致时间偏差。

丢包率可以单独统计：

# loss.awk BEGIN { sent = 0 recv = 0 drop = 0 } $1 == "+" { sent++ } $1 == "r" { recv++ } $1 == "d" { drop++ } END { printf "sent:%d recv:%d drop:%d loss_rate:%.4f\n", sent, recv, drop, drop/sent }

逻辑是+表示包进入队列，d表示丢弃，丢弃事件数除以总发送数就是丢包率。注意不能用drop/recv计算，因为丢掉的包永远没机会被接收。

4.4 用 gnuplot 把多场景曲线叠在一张图里

研究路由协议或者拥塞控制时，对比多条曲线比单看一个数字更直观。gnuplot 的脚本可以一次读多个数据文件：

set terminal pngcairo size 800,600 set output "compare.png" set xlabel "time(s)" set ylabel "throughput(Kbps)" set grid plot "result_1.dat" using 1:2 with lines title "1Mb", \ "result_2.dat" using 1:2 with lines title "2Mb", \ "result_3.dat" using 1:2 with lines title "5Mb"

这里的using 1:2表示第一列是时间，第二列是吞吐量。用title区分场景。生成曲线图以后，直接放进论文或报告里作为仿真结果。

如果每个场景的数据不是按秒聚合的，可以先在 bash 里用 awk 循环生成：

for f in result_*.dat; do awk '{print $2, $1}' $f > ${f%.dat}_xy.dat done

数据准备和 plot 分离，避免 gnuplot 图难看的排版问题。

5. NS2 避坑：高频翻车点的现象、原因与处理

5.1 编译时找不到 stl_hash_fun.h

现象：运行make到一半，报错fatal error: stl_hash_fun.h: No such file or directory。

原因：NS2 源码依赖 SGI STL 的头文件，现代 libstdc++ 已经移除了它。这个错误几乎只出现在 gcc 5 以上的系统上。

解决：切换到 gcc-4.8 后一般能消失。如果还想继续用新 gcc，可以安装旧版 libstdc++ 开发包，然后手动创建符号链接。我自己的做法是在 ns-2.35 目录下加一个include路径指向/usr/include/c++/4.8/backward。不过最省心的还是按 2.3 节把 gcc 切换回 4.8。

5.2 configure 检查 tcl/tk 找不到库

现象：执行./configure时出现checking for tclsh... no或者checking for TclConfig.sh... no。

原因：NS2 的 configure 脚本需要找到tclConfig.sh，这个文件通常在 tcl 开发包里，而不在运行时包里。你如果只装了tcl8.5没装tcl8.5-dev，就会触发这个问题。

解决：先安装开发包，再明确指定路径：

sudo apt-get install tcl8.5-dev tk8.5-dev ./configure --with-tcl=/usr/lib/tcl8.5 --with-tk=/usr/lib/tk8.5

如果还是找不到，可以用find /usr -name tclConfig.sh找到真实路径，再把它填进去。

5.3 运行脚本时 command not found 或 couldn't read file

现象：在 shell 里输入ns simple.tcl返回command not found，或者ns能启动但秒退，提示couldn't read file "simple.tcl"。

原因：前者是 PATH 没设对，which ns什么都找不到。后者是当前目录不是脚本所在目录，以及可能没有给脚本写绝对路径。

解决：先which ns确认二进制位置。如果输出为空，重新检查 2.4 的 PATH 导出。如果ns能运行但读不到脚本，就在脚本路径前加./，或者用ns /绝对路径/simple.tcl。对于自动批量脚本，我一般会让 bash 在循环里先cd到目标目录，再用相对路径写。

5.4 修改了 C++ 但重新 make 后效果没变

现象：改了tcp.cc里的初始拥塞窗口，重新编译然后跑脚本，结果 Tcl 里看到的窗口大小还是旧值。

原因：最常见的是没有make clean，增量编译没有感知到头文件变化；第二个原因是 Tcl 脚本里用类默认值把 C++ 里的值覆盖了，比如出现Agent/TCP set window_ 20，而代码里写的初始值被脚本覆盖。

解决：在ns-2.35下先make clean再make -j2。同时把 Tcl 脚本里所有Agent/TCP set window_找出来确认是注释掉了还是保留着。如果确实需要代码里的默认值生效，脚本里的类默认设置必须删掉。

5.5 trace 文件数据过少甚至为空

现象：跑完脚本后wc -l trace.tr只有十几行，或者head -5 trace.tr看到全是+没有r和d。

原因：仿真时间太短，流量还没来得及到达接收端就结束了；或者链路带宽与流量不匹配，比如 FTP 还没启动到被观察的时间段。

解决：先把$ns at 50.0 "$app stop"这类时间值拉长，确保 app start 事件早于 stop。再看 tracer 输出路径是否和你gl打开的是同一文件。我曾经犯过把 trace-all 写到trace.tr，然后用cat out.tr查数据的低级错误。最简单的方法是把名字统一，全程用同一个变量名：

set tf [open trace.tr w] $ns trace-all $tf

这样就不会出现两个文件互相混淆。

6. 批量跑仿真并用 nam 验证行为：把一次性的 NS2 变成竞争性评估工具

6.1 批量场景脚本：sed 参数扫描的常见做法

研究不会只跑一遍。最常见的做法是用 bash 循环改变链路带宽，生成多个 Tcl 脚本再逐个运行：

for bw in 1Mb 2Mb 5Mb 10Mb; do sed "s/1Mb/$bw/g" simple.tcl > run_$bw.tcl ns run_$bw.tcl awk -f throughput.awk trace.tr > result_$bw.dat rm -f trace.tr done

这里的sed把模板里的1Mb替换成当前循环值，生成新的 Tcl 脚本。每次运行后及时用 awk 提取吞吐量到独立文件，然后清理掉 trace 以免下次被覆盖。如果要同时改延迟或丢包率，可以用多个 sed 表达式串联。

6.2 nam 可视化能帮你确认的问题

nam 是一个稳妥的验证工具。运行nam out.nam会打开一个动画窗口，你能看到节点之间包的流动。它的价值不只是展示，而是快速定位几种问题：链路是否建立、包是否卡在队列里、丢包是否发生在预期节点。如果 trace 分析结果很奇怪，比如吞吐量突降到 0，先开 nam 看是不是节点之间根本没有连接，而不是一开始就怀疑 awk 脚本写错。

6.3 我的习惯

我每次跑 NS2 之前，都会先在一个最小双节点拓扑上跑通整个流程，确认 trace 有预期事件后，再加节点加流量。每改一次 C++ 代码，我会把make clean && make -j2 && ns simple.tcl连成一行敲下去，省得中途忘掉某一步。批量仿真时，我会把所有重复参数抽到环境变量里，而不是直接用 sed 硬替换文件，因为 sed 改多了容易误伤。保持这套工作流，NS2 这个小黑匣子也能变成可复现的实验台。希望帮到你。

本文还有配套的精品资源，点击获取