现在就差主机到虚拟机的捕获包的实验了，设想了一下，假设以500Mbit/s的流量发给一个100M的以太网卡，显然丢包率是很明显，所以这个问题的实验就暂时不做了，这跟网卡的收发速度相关，属于硬件上的问题，所以暂时不做实验，那么我们所面临的问题就成了，内核和应用程序应该怎么处理数据包，才能真正体现100M网卡的性能，当然大多数情况下，丢包的情况是比较严重的。
结合别人的经验，现分析如下：
- 内核将网卡缓冲区的内容直接拷贝到应用程序（libpcap）,严重浪费cpu的性能，导致到来的数据处理不及时。
- 采用中断响应的方式会导致，处理器的时间浪费在中断处理上，就是所说的中断活锁的问题。
解决方案如下：
- 对于中断响应的问题，多是采用设备轮循的方式，减少同类中断的次数。
- 给内核打实时补丁，加速中断的响应。
- PF_RING套接字和内存零拷贝的技术。
当然前两种方案只能解决小部分问题。真正的问题解决应该是后一种方案，内存零拷贝和PF_RING的原理其实是一样的，都是采用将内核缓冲区的数据直接映射到用户空间，采用DMA，用户空间可以直接访问，这样就避免了数据包从内核到应用程序的拷贝。至于具体如何实现，我还在研究中，如果哪位高手知道的话，可以帮帮我，当然实现了，我会第一时间把结果帖出来，第一时间和大家分享。
本来想用WINDOWS下的tcpreplay给linux下发包测试的，但是下载的tcpreplay在windows下安装，太过麻烦，一点都不智能，还不如linux下的tcpreplay呢，但是linux下用tcpreplay我发的包，大部分都能正确捕获，当然捕获后也有很高的丢包率，不知道为什么。我的猜测是凡是经过网卡的数据，libpcap都能统计出来，也就是说除了如果流量太大，导致网卡的包进不去网卡的情况之外，libpcap都能探测得准确。也就是说前两个实验得结果中收到得包数，就是到达网卡得包数，也就是说我进行文件传输的实际发包数和捕获的发包数是一致的，只是处理速度不够导致丢包。
至于经过网卡的包等不等于实际发包数，当然是网络流量小于网卡处理能力的情况下，也就是不考率发送的包的速率超过网卡的接受速度的情况下，如果结论成立，那么我的假设就是成立的，如果结论不成立，那么我上面的假设就是错误的。
说白了，就是libpcap自带的统计功能里的抓包数，是不是经过网卡的包数的问题，当然要过滤掉规则外的包。现在时间忙就暂且不做这个实验了，十分希望网友能帮帮忙。如有疑问，请直接留言。我现在先去研究下怎么样提高包得处理速度，也就是PF_RING和内存零拷贝技术怎么应用在内核中。
<script type=text/javascript charset=utf-8 src="http://static.bshare.cn/b/buttonLite.js#style=-1&uuid=&pophcol=3&lang=zh"></script> <script type=text/javascript charset=utf-8 src="http://static.bshare.cn/b/bshareC0.js"></script>
阅读(1354) | 评论(0) | 转发(0) |
相关热门文章
给主人留下些什么吧！~~
评论热议
264
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
