当MySQL数据库遇到Syn Flooding

Syn攻击是最多见又最容易被利用的一种攻击手法，利用TCP协议的缺陷，发送大量伪造TCP链接请求，经常使用假冒的IP发来海量的SYN包，被攻击的服务器回应SYN+ACK，由于对方是假冒的IP，永远收不到包而且不会回应，致使被攻击服务器保持大量SYN_RECV状态的半链接，而且会重试默认5次回应握手包，塞满TCP等待链接队列，资源耗尽，让正常的业务请求链接不进来。

Syn攻击常见于应用服务器，而数据库服务器在内网中，应该很难碰到相似的攻击，但有时候应用程序若是和数据库建连姿式不正确，在数据库端，也会被认为是Syn攻击，并拒绝链接创建。

【问题描述】

数据库突发的拒绝连接，应用报错，出问题的时间点上，数据库服务器的操做系统日志里，即/var/log/messages，可看到以下报错信息：

kernel: possible SYN flooding on port 3306. Sending cookies.

【问题分析】

出问题的点上，从数据库的监控指标来看，Threads Connected 这个指标有增加。这个也是很明显，由于对数据库来讲，Syn Flooding就是应用程序突发的对数据库发起建连，操做系统处理不过来，因此报Syn Flooding, 从数据库的性能指标来看，链接数确定是会有一个突发的增加。应对方案就是须要分析这些突发的增加是怎么来的，削峰填谷，让链接更平稳。

【解决方案】

在数据库服务端，作以下调整：这个调整的意思是说：增长TCP半链接的缓冲，默认值是2048，咱们调整到8192，让系统的抗突发压力增大一些。Tcp_syn_retires和Tcp_synack_retires默认是5，也就是服务器端要发送五次包，才会终止重试，咱们把这个参数调整为2. 只重试一次，让出错的包尽可能提前出错，以减小缓存的链接数。

echo 8192 > /proc/sys/net/ipv4/tcp_max_syn_backlog
echo 2 > /proc/sys/net/ipv4/tcp_syn_retries
echo 2 > /proc/sys/net/ipv4/tcp_synack_retries

这个参数调整，即时生效，无需重启。固然服务器重启后，这些参数也会回退到默认值。经此调整，数据库端的抗压能力获得增强，但并无彻底解决问题。

咱们在客户端也作相应调整：

为减小数据库的链接数压力，一般咱们建议链接池作以下配置：

testWhileIdle="false"。空闲时不检测链接串健康
minIdle="0"。链接池里面空闲链接的最小个数
maxAge="30000"。一个连接超过多少毫秒就能够回收掉。
initialSize="1"。链接池里面初始链接的最小个数
timeBetweenEvictionRunsMillis="5000"。回收线程的运行间隔（毫秒）

对于如今的场景，咱们建议调高minIdle这个参数，从0调整到5. 让链接池平时有5个空闲链接存在，这样，发起对数据库请求的时候，会先使用这5个空闲链接。达到削峰填谷的做用。固然，反作用就是数据库平时的链接数会增加。具体调整到多少合适，须要结合实际的数据库链接负载状况。对于.NET程序，也有相应的链接池参数能够调整：能够适当修改minPoolSize这个参数，也调整到5.

经此调整，基本上大部分的数据库Syn Flooding问题都能解决。

固然，这些都是调优的手段，只能是微微的改善系统。提升抗压能力。最终的分析，仍是要看链接压力从何而来。以及为什么须要突发创建大量链接到数据库。对于此种突发场景，用数据库是否合适。替代方案是前面用Redis加一层缓冲。避免突发的对数据库发起建连请求。这个就涉及到应用的改造了。