SYN丢包的几个例子

如果出现 SYN 丢包，那么将导致严重的性能问题，如果没有严重到完全连不上，那么在延迟时间上会表现出明显的时间特征，比如：1秒，3秒，7秒，15秒，31秒，具体可以参考：「SYN和RTO」，本文不说这个，就说说哪些情况会出现 SYN 丢包。

SYN Flood 攻击：

攻击者通过伪造大量不存在的 SYN 请求来消耗服务器资源，正常情况下，SYN 请求会被放到半连接队列中，一旦队列满了，后续的 SYN 请求将会被丢弃。

比较容易想到的方法一个是加快淘汰无效 SYN 请求，可以通过降低 tcp_syn_retries 来实现，另一个是加大队列的长度，此长度和 tcp_max_syn_backlog 相关，但又不是完全由它决定的，计算方法比较复杂，有兴趣的可以参考：

• Linux 诡异的半连接(SYN_RECV)队列长度
• 关于 TCP 半连接队列和全连接队列

不过在高强度攻击面前，调优 tcp_syn_retries 和 tcp_max_syn_backlog 并不能解决根本问题，更有效的防御手段是激活 tcp_syncookies，在连接真正创建起来之前，它并不会立刻给请求分配数据区存储连接状态，而是通过构建一个带签名的序号来屏蔽伪造请求。虽然 tcp_syncookies 使用起来很简单，可惜它却不能完整支持 TCP 的扩展项，这意味着我们将不得不放弃一些 TCP 的扩展功能，详细介绍参考维基百科。

还有一些诸如 SYN Proxy 防火墙之类的方法，本文就不多说了。

不当的 tcp_tw_recycle 设置：

当多个客户端通过NAT方式联网并与服务端交互时，服务端看到的是同一个IP，也就是说对服务端而言这些客户端实际上等同于一个，由于这些客户端的时间戳可能存在差异，于是乎从服务端的视角看，便可能出现时间戳错乱的现象，此时如果服务端开启了 tcp_tw_recycle，那么时间戳慢的客户端发送的 SYN 就会被丢弃。解决方法只有一个，永远不要开启 tcp_tw_recycle，除非你知道自己在干什么。

参考：tcp_tw_recycle和tcp_timestamps导致connect失败问题。

过小的 unres_qlen 设置：

关于此原因的描述，我直接摘录蘑菇街技术博客中的相关描述，可惜的是相关文章现在已经下线了，大家有兴趣的可以访问国外网站通过 archive.org 来浏览。

TCP Connect 的流程是这样的：

1. TCP 发出 SYN 建立报文后，报文到 IP 层需要进行路由查询。
2. 路由查询完成后，报文到 ARP 层查询下一跳 MAC 地址。
3. 如果本地没有对应网关的 ARP 缓存，就需要缓存住这个报文，发起 ARP 请求。
4. ARP 层收到 ARP 回应报文之后，从缓存中取出 SYN 报文，完成 MAC 头填写并发送给驱动。

问题在于，ARP 层缓存队列长度默认很小。如果你运气不好，刚好赶上缓存已满，那么这个报文就会被丢弃。好在它是可配置的：「sysctl -a | grep unres」。所以， 解决方法是，把这个值调大，一切都 OK 了。红帽官方文档推荐加大此设置。参考：

• 同一client并发connect同一server超时失败问题
• ARP相关内核参数unres_qlen研究

目前我就知道这几个例子了，如果大家知道别的，请赐教。