链路负载均衡，由于国内 南电信，北网通的现状和业务需求，竞争这个市场的厂商比较多，在很多地方也都在使用这种产品。但是有一次我们去访问一个高校客户，客户却表示仍旧愿意使用防火墙来做,使用静态策略和必要时的手动修改，也不愿意使用链路负载均衡的设备，原因何在？

进一步了解后客户指出，链路负载均衡的设备他们也测试过多个厂商，在流量调度和链路冗余备份上当然比现有防火墙要灵活的多，但是最大的问题是作为一个高容量的出口设备，防***能力远远不如防火墙。

高校情况类似一个小的运营商，内部用户可以数万计，出口在Gbps的级别，学生求知欲强，喜欢新鲜事物，流量类型复杂，内部也容易出现中***的肉鸡现象。最常见的SYN Flood的***，对防火墙而言，可以通过连接状态的监测过滤，而对基于四层和会话的常见链路负载均衡设备，则有可能迅速耗尽设备可使用session资源，造成正常流量无法处理的故障情况出现。例如下图显示( 带宽信息等隐藏)：

设备统计下图上毛刺即为不定期出现的由内网发出的SYN Flood***，源IP伪造，目标地址是同一个***目标，由于新建连接迅速耗尽设备可创建连接数，正常用户的请求得不到相应，设备吞吐量在***时明显下降，用户上网受到影响。

 IPS记录：

Apr 22 19:20:47    info     IPS: event<syn flood>: from src<235.242.124.84> to dest<123.147.240.179>: 1 times
Apr 22 19:20:47    info     IPS: event<syn flood>: from src<24.155.131.131> to dest<123.147.240.179>: 1 times
Apr 22 19:20:47    info     IPS: event<syn flood>: from src<121.217.252.5> to dest<123.147.240.179>: 1 times
Apr 22 19:20:47    info     IPS: event<syn flood>: from src<150.183.171.150> to dest<123.147.240.179>: 1 times
Apr 22 19:20:47    info     IPS: event<syn flood>: from src<111.63.169.80> to dest<123.147.240.179>: 1 times
Apr 22 19:20:47    info     IPS: event<syn flood>: from src<238.81.1.192> to dest<123.147.240.179>: 1 times
Apr 22 19:20:47    info     IPS: event<syn flood>: from src<213.116.80.206> to dest<123.147.240.179>: 1 times
Apr 22 19:20:47    info     IPS: event<syn flood>: from src<100.213.59.43> to dest<123.147.240.179>: 1 times
Apr 22 19:20:47    info     IPS: event<syn flood>: from src<201.150.168.150> to dest<123.147.240.179>: 1 times
Apr 22 19:20:47    info     IPS: event<syn flood>: from src<217.121.39.9> to dest<123.147.240.179>: 1 times
Apr 22 19:20:47    info     IPS: event<syn flood>: from src<213.116.80.206> to dest<123.147.240.179>: 1 times
Apr 22 19:20:47    info     IPS: event<syn flood>: from src<100.213.59.43> to dest<123.147.240.179>: 1 times

其实针对SYN Flood***有一些很成熟的手段，例如SYN Cookie机制; 原理也容易理解：SYN Cookie是对TCP服务器端的三次握手协议作一些修改，专门用来防范SYN Flood***的一种手段。它的原理是，在TCP服务器收到TCP SYN包并返回TCP SYN+ACK包时，不分配一个专门的数据区，而是根据这个SYN包计算出一个cookie值。在收到TCP ACK包时，TCP服务器在根据那个cookie值检查这个TCP ACK包的合法性。如果合法，再分配专门的数据区进行处理未来的TCP连接。

通常的Linxu服务器上其实就可以把该功能打开，但是一般服务器和链路负载即使打开该功能，由于大量并发的请求，传统基于软件的处理方式仍旧会对设备造成影响。部分厂商(例如A10 Networks，Juniper等)的产品使用了自己开发的FPGA硬件作为SYN Cookie防御手段，在打开该功能后对CPU无影响，效果也相当明显

启用前后的现象对比：

之前内网(6509进入)的SYN Flood ***会影响到电信和网通的出口链路；

之后SYN Flood***仍旧到达设备，但已经被设备抑制，对电信和网通出口无影响，流量平滑

链路负载均衡设备通常对设备的性能要求高，安全性同时也一定需要考虑，最后贴一个较高流量的设备吞吐量图：

 

(J.L)