对Panabit的一些想法

zhaoht

一些不成熟的想法,供参考.

1.流控设备目前的主要市场是针对中高端用户,特别是高校和政府.他们的需求和中小企业等低端市场的需求是不同的.
性能
- 对于中高端用户,流量管理关注性能,FreeBSD 6.x在SMP的实现上比FreeBSD 7.0有一段不小的距离.
- FreeBSD的桥接实现方式本身有很大的提升空间.
- 基于队列的管理方式,在大流量的环境下性能比较成问题.
- 我看到测试报告中,测试的方式和防火墙一样,建议做个单向1G带宽的测试,在做策略的情况下,看CPU占用的情况.

基于应用的流量管理方式
- 对于中高端用户,似乎更关注整体带宽的顺畅,试想:一个高校10K以上的用户,应用成千上万,针对应用来做管理,其实和防病毒软件一样进入一个恶性循环,各种应用不断增加,需要不断更新协议库.采用这种方式,很难和其他流控厂家竞争.
- 而且基于应用的流量管理方式,等于是几个网管和所有用户在不停的战斗.

2.现在论坛中大部分的人好像都是网吧,企业用户,按他们的思路来开发产品可能会有问题.

panabit

谢谢您同我们分享您的想法，下面是我的一些comments或points:

1) 关于FreeBSD 6.2和7.0的SMP问题

    这个对Panabit而言不是问题。Panabit运行在PanaOS里，PanaOS接管系统的部分调度，所以无论是FreeBSD 6.2还是其它以上版本，其性能均是一样的。

2) 关于FreeBSD的网桥

    Panabit没有使用FreeBSD网桥代码，而是采取自己编写的代码，正于上面所说，Panabit完全运行在PanaOS中，所以同FreeBSD kernel没有任何关系，这也是Panabit之所以稳定的一个重要原因，也正式因为如此，即使Panabit down掉，FreeBSD也不会crash。

3) 关于队列的管理方式

    您说得很对，基于队列的管理方式，在大流量的环境下性能比较成问题，而且会占用大量的内存。Panabit不是采取这种方式，所以不存在类似于ipfw那样的问题或延迟。采用队列方式另外一个大问题就是延迟，Panabit基本上不会产生类似的延迟。

4) 关于测试报告

    我们有根据典型的100条策略的测试情况，性能基本上没有太大的差别（大概少50kpps）。这主要是由于，Panabit的算法比较高效，对CPU要求不高。

5) 关于"基于应用的流量管理方式"

    目前来看，要疏通大流量环境的网络，基于应用的流量管理方式目前看来还是一种最好的管理方式，这也使得SLA成为可能。另外一个方面，现在的P2P软件越来越多，其传输方式也越来越诡秘，传统的流量管理方式（如Packeteer）已经不能适应网络的变化。至于特征库，那是必须解决的问题，而这正式象Panabit这样的设备的价值之所在。
     从您的话语中，我觉得您在这方面应该有一些不同的想法，如果方便，请同我短信联系，我们多多交流一下。