个人做电影网站合法吗不包括

  ns3的官方手册很全，相关书籍也是有的，官网先贴在这里：

ns-3 | a discrete-event network simulator for internet systemsa discrete-event network simulator for internet systemshttps://www.nsnam.org/相关的脚本介绍也都有一些：

ns-3.35_wifi-he-network.cc_ns-3网络仿真工具wifi脚本解析_wifi脚本网络拓扑_ns-3wifi6吞吐脚本关键注释_吞吐部分_基础ns-3_ns3.35-CSDN博客

ns-3-model-library wifi 浅析_ns-3wifi部分解析_ns-3网络模拟器wifi部分文档分析_Part1_ns3 wifiphy物理层冲突-CSDN博客

ns-3-model-library wifi 浅析_ns-3wifi部分解析_ns-3网络模拟器wifi部分文档分析_Part2_yansphy-CSDN博客

问题现象

在进行eht吞吐仿真的时候，我进行了时间间隔较短的吞吐测试：

PktLen	1000
UdpInterval	0.0005
UdpTime	0.5

    UdpServerHelper echoServer(9); // 端口9ApplicationContainer serverApps = echoServer.Install(pppNodes.Get(0));serverApps.Start(Seconds(1.0));serverApps.Stop(Seconds(2+UdpTime));for (uint32_t i = 0; i < staNodes.GetN(); ++i){UdpClientHelper client(pppAp1Interfaces.GetAddress(0), 9);client.SetAttribute("MaxPackets", UintegerValue(2127283647));client.SetAttribute("Interval", TimeValue(Seconds(UdpInterval)));client.SetAttribute("PacketSize", UintegerValue(PktLen));ApplicationContainer clientApp = client.Install(staNodes.Get(i));clientApp.Start(Seconds(2));clientApp.Stop(Seconds(2+UdpTime));}

可见如果要是链路没有限制，正常的pcap应该是UDP包从2秒开始到2.5s结束，应该是0.5/0.0005=1000包。

由于我们需要进行的是饱和吞吐的测试，实际产生的数据包的数目当然要多余链路容量，所以pcap抓包数目一定小于这个数值，且是一个2秒开始到2.5s结束的记录。

但事实上抓包发现抓到的太多了——936*1000*8/0.5=14976000 bps的吞吐，就是14Mbps的吞吐，比链路理论速率8.6高得多了。

具体分析

在脚本中添加log，查看udp流量结束时间：

可以看到流量确实是2.5s结束的——吞吐也是合理的7.07M（忽略掉80+80，那个是随意打印的字符串），所以问题就出在pcap上：

 

ns-3里面，UDP流也和正常的iperf类似，包里面是有应用层序号的——此包序号3e7：

可以看到这个是udp产生的第999包——换言之pcap并没有完全的抓取两端包发送完成的时间，而是抓取了全部时间。

其中原因

数据包的产生确实是产生了999包，但是双方在2.5s后就不处理udp了，不过wifi仍然连接，且AP STA的缓冲区都是无限大的，所以2.5s后包还是会进入空气，直到产生的包全部发发送完成，只不过这些包与UDP无关了而已——他们来的，太晚啦。

事实上对于吞吐分析，pcap这里面2.5s以后的内容会让大家产生迷惑——需要更多的注意