如果出现 SYN 丢包，那么将导致严重的性能问题，如果没有严重到完全连不上，那么在延迟时间上会表现出明显的时间特征，比如：1秒，3秒，7秒，15秒，31秒，具体可以参考：「SYN和RTO」，本文不说这个，就说说哪些情况会出现 SYN 丢包。
SYN Flood 攻击：
攻击者通过伪造大量不存在的 SYN 请求来消耗服务器资源，正常情况下，SYN 请求会被放到半连接队列中，一旦队列满了，后续的 SYN 请求将会被丢弃。
比较容易想到的方法一个是加快淘汰无效 SYN 请求，可以通过降低 tcp_syn_retries 来实现，另一个是加大队列的长度，此长度和 tcp_max_syn_backlog 相关，但又不是完全由它决定的，计算方法比较复杂，有兴趣的可以参考：
不过在高强度攻击面前，调优 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 的流程是这样的：
- TCP 发出 SYN 建立报文后，报文到 IP 层需要进行路由查询。
- 路由查询完成后，报文到 ARP 层查询下一跳 MAC 地址。
- 如果本地没有对应网关的 ARP 缓存，就需要缓存住这个报文，发起 ARP 请求。
- ARP 层收到 ARP 回应报文之后，从缓存中取出 SYN 报文，完成 MAC 头填写并发送给驱动。
问题在于，ARP 层缓存队列长度默认很小。如果你运气不好，刚好赶上缓存已满，那么这个报文就会被丢弃。好在它是可配置的：「sysctl -a | grep unres」。所以， 解决方法是，把这个值调大，一切都 OK 了。红帽官方文档推荐加大此设置。参考：
转载请注明：爱开源 » SYN丢包的几个例子