windows中没有将loopback当成一个网卡来实现，而是直接在比较高的层次解决了对127.0.0.0网段的访问，因此使用wiresharck是无法抓取这种loopback包的，pcap工作在非常低的层次，127.0.0.0网段的数据流是不会到这个层次的。因此你必须按照驱动或者自己写一个驱动去将127.0.0.0网段的数据包抓取，已经比较好的实现有CommView，然而它需要安装一大堆的驱动程序，而且没有微软徽标，很恐怖的，虽然它没有公布驱动的源码，然而很显然，它在比较高的层次截取了127.0.0.0网段的数据流。
     本来想安装microsoft的loopback adapter驱动程序，但是这个adapter还不能指定127.0.0.0网段的地址，只能指定一个别的地址，并且它还不会生成自动路由，也就是本网段的路由通过本adapter，还必须手工添加一条主机路由才能实现抓包，也就是自己到自己的路由：
route add 192.168.40.34 192.168.40.34 mask 255.255.255.255
如果没有这条路由，那么它的行为和127.0.0.0网段的行为一样，所不同的是，wiresharck认出了这个loopback网卡，然而还是不能抓取它上面的包，也不知道这个loopback adapter的作用到底是什么？资料上说是为了模拟出一个本地网卡来，可是为何不直接自带一个呢？内置127.0.0.0网段的ip地址，就像linux那样。在linux中所有源和目的地都是本地网卡或者127网段的数据都会通过lo这个虚拟网卡发送接收，而且它还能配置别的ip地址：
ifconfig lo 11.22.33.44 netmask 255.255.255.0
唯一觉得不妥的是即使是linux的lo也没有办法配置mac地址，不过这无所谓，问题不大，至少在lo上能抓到本地包可以分析，而在windows上却只能安装loopback adapter然后还要配置路由，可见如果不配置路由的话，虽然有了一个环回的网卡，数据还是下不去，可能是路由将数据给导入到这个loopback adapter的。
     影响linux协议栈数据流的方式有两个，第一是通过netfilter的用户态接口配置(有时候还要写内核模块)，第二就是写一个协议处理驱动注册进内核，第一种方式更方便，不使用的时候直接在用户态清除配置即可，比如iptables -F，而第二种方式只能卸载内核模块了。然而不是每种需求都适合这两种方式的，如果你想在5个HOOK点对数据进行影响，那么可以使用第一种方式，如果你想对一个新的协议进行处理，那么使用第二种方式，linux不允许对协议栈进行纵向插入hook，比如在ip层和tcp层中间加一个“过滤层”，linux只能根据数据包的内容进行横向过滤，要么使用netfilter，要么注册一个协议和既有协议平行，也就是说linux不运行增加协议栈的高度，然而却可以增加每一层的宽度。
     对于windows而言，由于它的驱动实现方式本身就是分层的，协议栈实现也不例外，和linux正好相反，它在横向扩展方面很吃力，虽然可以实现类似netfilter的机制，却很少有人尝试，这是由于windows的协议栈很容易在任何一个位置而不是仅有的几个HOOK位置插入一个新的“层”来过滤数据包，ndis的驱动模型十分善于做这个，tdi之上的东西更善于，直到用户态的lsp还在干这个。因此windows的数据过滤完全是纵向的，协议栈自然可以越来越高。因此在稳定性和配置的灵活性方面，windows远远不如linux，然而在windows上很少有人想做配置协议栈之类的工作。
     添加了loopback adapter之后，重启机器，然后发现虚拟机突然就不通了，虚拟机中的网卡使用了bridge模式，不通的原因在于在虚拟机的网络配置中勾选了“Automatically choose an available physical network adapter to bridge to VMnet0”，并且loopback adapter的本地连接属性中又勾选了“VMware Bridge Protocol”，这样由于loopback adapter已经被模拟成了physical network adapter，因此它接管了这个虚拟机的bridge的话，自然就和真实机器的物理网卡不通了，然而此时虚拟机里面却能ping通外面的loopback adapter上的ip地址，实际上虚拟机的网卡bridge到这个loopback adapter了。解决办法就是不勾选loopback adapter的bridge选项或者手工指定虚拟机网卡bridge到哪个网卡。由此引出了下面的关于vmnet的预研。