SYN丢包的几个例子

老王 2017-10-31 19:50

如果出现 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 的流程是这样的:

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

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

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

[返回] [原文链接]