基于包内容的关键字过滤－－－求助

i.am

统一ls

dreamice

这样效率如何？
IP queue原来是干这个的？

Godbach

一般要分析应用数据的时候，就可以考虑使用这种机制，把报文丢到应用空间，用户态根据报文的内容进行判断，并决定ACCEPT或DROP。当然，就算在内核态做也可以哈。

dreamice

原帖由 Godbach 于 2009-2-24 09:31 发表
一般要分析应用数据的时候，就可以考虑使用这种机制，把报文丢到应用空间，用户态根据报文的内容进行判断，并决定ACCEPT或DROP。当然，就算在内核态做也可以哈。

iptables的string匹配其实可以做一些简单的关键字匹配检查，但涉及到应用层一些复杂的匹配规则，ip queue倒是不错的选择，但不太清楚其性能如何

Godbach

原帖由 dreamice 于 2009-2-24 11:00 发表


iptables的string匹配其实可以做一些简单的关键字匹配检查，但涉及到应用层一些复杂的匹配规则，ip queue倒是不错的选择，但不太清楚其性能如何

恩，iptables的string匹配应该功能有限。Ip Queue的可以测试一下啊

dreamice

原帖由 Godbach 于 2009-2-25 09:22 发表


恩，iptables的string匹配应该功能有限。Ip Queue的可以测试一下啊

从它的实现机理来看，效率可能是个瓶颈——如果大规模的用这种机制的话

Godbach

原帖由 dreamice 于 2009-2-25 14:13 发表

从它的实现机理来看，效率可能是个瓶颈——如果大规模的用这种机制的话

何以见得效率是瓶颈呢？ dreamice兄判断的原因可否讲一下。
难道数据报文在用户态处理而不是在内核态处理，就一定会导致效率问题吗？

dreamice

原帖由 Godbach 于 2009-2-25 15:09 发表


何以见得效率是瓶颈呢？ dreamice兄判断的原因可否讲一下。
难道数据报文在用户态处理而不是在内核态处理，就一定会导致效率问题吗？

这个数据周转的路径比较长，内核的匹配-->用户空间-->用户空间Process-->内核空间
整个走了一圈，数据包的延迟就不用说了，如果量比较大，这个效率是可想而知的。

Godbach

原帖由 dreamice 于 2009-2-25 23:11 发表


这个数据周转的路径比较长，内核的匹配-->用户空间-->用户空间Process-->内核空间
整个走了一圈，数据包的延迟就不用说了，如果量比较大，这个效率是可想而知的。

我觉得可以这样理解：
（1） 内核空间对某些报文的数据部分处理的效率没有用户空间高，或者处理的速度上相差比较大；
（2）内核把数据包丢到应用空间之后，就可以处理其他报文了，直到这个报文再次被丢回内核空间。

dreamice

那被丢上去这个报文的延迟就可想而知了