P2P的流控问题

瀚海书香

回复 9# Godbach
有很多链接好像是只能通过helper来实现的，但是这些helper的特点有不像ftp那样的有规律。

Godbach

是的。如果要做p2p识别的话，建议先了解一下ipp2p和l7-filter的实现。

瀚海书香

回复 12# Godbach
这两个都已经看过了，但还是没事思路
以前看到过一个基于freebsd的p2p流控，但是没找到源码。。。

Godbach

其实前面白金兄和九贱兄也都提到了。关键还是在于如何准确识别出p2p下载流。

独孤九贱

九贱兄是不是分析出了 command channel 和 data channel，并自己编写了 helper 来辅助 conntrack？
platinum 发表于 2010-07-12 14:13

没有呀，一个p2p应用一个helper，好像会使Netfilter变得更加肥大喔！！哈哈！P2P识别一个难题，可能基于会话的特征识别还是王道，像panabit就做得很好，可惜开放出来的文档太少。

platinum

没有呀，一个p2p应用一个helper，好像会使Netfilter变得更加肥大喔！！哈哈！P2P识别一个难题，可能基于 ...
独孤九贱 发表于 2010-07-14 10:17

我觉得 panabit 最牛的地方不是协议识别率，而是性能
去年我和同事一起做了一个实验
在纯 Linux 网桥（不开 conntrack）、纯 FreeBSD 网桥，以及 panabit 上做 64 字节小包单向千兆线速转发测试
硬件都是一样的，intel 的 82571 网卡，PCI-E 接口
Linux 38%
FreeBSD 42%
panabit 99.98%

不知道是怎么做到的……

独孤九贱

绕过协议栈，只做自己想做的事，然后直接转发。不知是不是这样，另外，FB的dev polling方式性能本身就要大大高于Linux，在处理小包时。

platinum

绕过协议栈，只做自己想做的事，然后直接转发。不知是不是这样。
独孤九贱 发表于 2010-07-14 10:38

应该不仅是这样，panabit 使用了自己的 em.ko 网卡驱动，可能实现了零拷贝
另外，我在 Linux 里也做国实验，在 dev.c 里直接把从 A 网卡收到的数据从 B 网卡 xmit 出去，然后 kfree_skb，结果吞吐量有上升，却也没达到 50%

独孤九贱

应该不仅是这样，panabit 使用了自己的 em.ko 网卡驱动，可能实现了零拷贝
另外，我在 Linux 里也做国 ...
platinum 发表于 2010-07-14 10:56

1、首先，我讨论是转发情况，不是服务器本身收包那种。

像常用的e1000e，本身就是“零拷贝”吧？？我觉得像PCI-E解决了总线性能瓶颈后，Linux想要在小包上性能有所突破，估计还是要改善NAPI机制，进一步降低中断频率，另外，发送的中断性能消耗也不容小视！

Godbach

P2P识别一个难题，可能基于会话的特征识别还是王道，像panabit就做得很好，可惜开放出来的文档太少。

嗯，p2p识别中panabit做的确实挺好