2NSME实现.docVIP

2 NSME的实现 2.1 总体框架 2.1.1 拓扑与事件调度 图1给出了NSME拓扑组织及支撑其运行的内核事件调度过程。其网络拓扑一般由虚拟主机、路由器及相关链路构成，而在非全虚拟条件下，映射主机和接口路由器能够充当NSME模型与外部交互的接口。抽象子网能够将属于同一子网的数据流量交由子网应用逻辑层综合处理，因此将规模和复杂度灵活的交由上层设计者把握。 数据包的产生、处理或销毁主要由主机的应用逻辑负责，当其在链路中传输时则被作为事件调入事件列表。此前，链路会根据包的尺寸、带宽及时延等算出其传输时间，当拥塞时则根据排队策略选择性丢包。NSME继承了NS2的双重调度思想，使用CalendarScheduler类执行全虚拟建模的调度任务，其它情况则使用EmuScheduler类执行实时调度，用系统时钟取代虚拟时钟并用独立的线程捕获网络数据包。 2.1.2 通信结构 NSME为每个虚拟主机构建了一个小型的、但较为完善的TCP/IP协议栈，因此应用层不再是附属物而成为逻辑实现的主体。主机应用逻辑通过虚拟套接口(Virtual Socket)层获得网络能力。它们代替Agent来处理网络和传输层协议，但不再是预配置的而是由协议栈和应用逻辑共同管理。这种结构的变化带来保真度的提高，在任何虚拟度条件下应用层都可以直接使用真实数据包通信而不必考虑对方程序到底是在虚拟主机上还是在外部真实主机上运行。 2.1.3 用户视图 C++语言和Otcl脚本将NSME的用户视图分成两层。由于在网络安全研究中，往往需要由应用层解决具体的问题，而且为了与真实环境保持统一，必须能够为用户提供可运行于虚拟主机之上的虚拟应用程序编程接口，因此C++构成了用户的主要逻辑实现层。在通信结构支持下，编写NSME的虚拟应用程序将与编写真正的面向对象网络程序几乎没有区别(Socket API不同)，因此NSME本身构成了一个编程环境。 Otcl脚本主要用于后期模型场景的构建，此空间中只存在网络拓扑元素和虚拟应用程序实体。因此当在Otcl空间中组建和配置完毕一个网络拓扑后，只需为其中的虚拟主机等指派不同的虚拟应用执行即可。 2.2 包、路由与寻址 NSME的数据包不再采用ns_addr_t地址等内部数据结构而全部依赖真实协议的协议头域。为满足非全虚拟条件，包的数据域得到全面支持，而在全虚拟条件下则可使用抽象数据包，即允许包尺寸大于包头域与数据域长度之和。 目前的路由算法仍采用经典的Dijkstra算法，但在路由节点内的包寻址及转发过程中，NSME实现了真实的Radix树路由表和相关算法，并从NsObject基类派生出新的RadixTreeClassifier路由分类器。从而在底层保证了网络模型可以像真实网络那样进行IP地址分配和网段划分。 2.3 协议栈实现 2.3.1 虚拟套接口层 NSME仿照Visual C++(MFC)的网络套接口类实现了包括RawSocket, UDPSocket, TCPSocket和TCPListenSocket在内的虚拟套接口层以支持正常的编程逻辑。其中，RawSocket类可提供最底层的网络能力，它负责发送任意协议的数据包以及拦截到达本地的数据包。UDPSocket类则负责传输层的UDP封装，而较为复杂的TCP协议则由TCPSocket类和TCPListenSocket类完成。 NSME没有在Otcl空间为这些Socket类关联Otcl类，因为这些类是被作为通信基础类提供给上层的，安全研究者不必在Otcl空间关心和了解下层的实现细节。 2.3.2 数据包本地分发 NSME协议栈用ip_local_deliver类执行数据包的本地分发过程。图2给出了NSME协议栈的设计示意。当创建虚拟套接口的派生类实例时，该实例将在ip_local_deliver中进行注册(如端口绑定等)。当ip_local_deliver收到数据包后首先将其送入rawip_filter内过滤。此时如果有RawSocket的派生类实例注册了对某协议的截听，则匹配的包将被转发给它。rawip_filter还将根据协议类型把包继续向上传递给对应协议的处理入口，其中icmp_handler直接处理ICMP的协议包，而tcp_demuxer和udp_demuxer则具有较复杂的协议管理功能。它们需要为已经注册的套接口建立快速索引(如平衡查找树)。对于不存在的UDP端口请求，udp_demuxer将通知icmp_handler返回端口不可达ICMP报文。而tcp_demuxer不仅要为每个合法的TCP连接建立索引，而且还必须对主动连接和被动连接加以区别。当处于被动连接的情况时，需要结合已注册的TCPListenSocket派生类实例共同实现动态的连接管理。 2.4 虚实网络接口 虚实网络