在做高可用负载时，可以清楚的看到，我们在11：21时跑的正常，然后我们通过防火墙的方式模拟网络故障。发现直到11：38才开始恢复正常，切换正常。为什么会这么久？我们是否可以进行优化呢？我们该如何进行分析呢？
故障表象
1、模拟故障：
iptables -A INPUt -p tcp --dport 22581 --j DROP
2、查看当时的网络状态：
ss |grep ESTAB | grep 22581
当时的网络状态如下图所示：
模拟网络中断，及卡住时网络状态
3、通过上图，我们可以清晰的看到，网络状态还是 ESTABLISHED状态。 这个状态很重要，了解TCP的想必大家都知道。这个状态时，双方已经建立了通信，在通信中，属于正常状态。但是我刚刚确实是通过防火墙拒绝了？但是它为啥还没变状态呢？通过这里，我们就可以初步判断为内核参数问题。是不是应该有一个类似于keepalive的参数，在连接活跃时，为了保持连接不断开及有效性检查，隔段时间进行一次检测呢？
4、果然在内存参数的相关介绍中，找到了此参数（tcp_retries2）。但是因为我的英文不太好，就不翻译了。我直接附上原文解释：
原文解释
从原文解释，大致的意思是，默认配置，活跃连接重传，确定连接是否有效的下限时间924.6s，超过15分钟。而此参数我们正好没有修改，于是对其进行了调试。为了验证自己的是否和它有关，于是调整为1。
5、临时修改参数：
echo 1 > /proc/sys/net/ipv4/tcp_retries2
永久修改的话，在/etc/sysctl.conf中添加即可。sysctl -p reload生效
net.ipv4.tcp_retries2 = 5
6、验证：
验证图片
从上图中，可以看到我们 12:04:26发生故障，12:04:45已经切换完成。大大的缩短了故障的切换时间。证明了我们上面的判断是正确的。到此故障完美解决。
参考链接：https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt