我们的系统使用在Ubuntu 10.04上运行的Cassandra，在最后一次stream量峰值期间，我们在日志中观察到以下消息：
possible SYN flooding on port 9160. Sending cookies. 这些机器不公开，stream量合法 – 来自我们自己的应用服务器。
有人知道内核进入调用者的“cookie”模式的后果是什么？ 我知道服务器停止添加半开连接（SYN_RECV）的积压队列，但它会影响调用者（即我们的.NET应用程序）以任何方式吗？ 是否有一些节stream/延迟踢，可能会开始一个恶性循环？
鉴于这些是内部机器，这种保护是否有意义？ 那么默认值tcp_max_syn_backlog=1024呢？
你可以用下面的方法禁用它们：
echo 0 > /proc/sys/net/ipv4/tcp_syncookies
为了使更改永久，编辑/etc/sysctl.conf添加一行，如：
net.ipv4.tcp_syncookies=0
我不认为这将是一个问题，如果stream量是本地生成和合法的，除非你自己洪水你的服务器:)
鉴于这是有效的stream量，您将希望禁用此行为 – 在连接的每一侧使用SYN Cookie都会产生显着的性能影响。 这个想法是通过将负担转移到CPU（在接收到有效的回复之前不分配存储器的cookie）来防止SYN泛滥中的RAM资源耗尽。
但是，序列计算的计算量很大，可能会影响应用程序和服务器，限制因素将是CPU。 这是一个DDoS预防机制，当stream量已知是好的时候，不应该运行这种机制，但实际上这是浪费资源。 为什么密集计算你不需要所有的stream量？
如果您禁用syn cookies，并认为您的服务器可能会因此受到攻击，您可以在服务器上添加逻辑，以便在检测到其他端口发生洪泛时重新启用cookie，也可以放置IDS / LoadBalancer或类似的中间有专门的资源来处理这种攻击。