记一次解决阿里云服务器偶尔连接不上的问题（由tcp_tw_recycle参数引发的）

阿里云服务器偶尔连接不上的问题出现在我做了一些TCP优化之后，出现了公司内网偶尔会出现连接不上服务器的问题，但是切换其他的网络就可以正常连接。

1，登陆服务器查看资源使用top，vmstat等命令查看了一番发现服务器各项指标都没有异常。于是将问题转向了网络层。

2，本地使用ping服务器外网ip正常返回，无丢包，延迟也正常。

3，登录服务器查看tcp相关数据。

发现在卡顿时有大量tcp syn包被丢弃，数值一直在增长。

在查阅资料并结合实际情况后，发现该服务器同时启用了 tcp_timestamps和tcp_tw_recycle参数。

后想起，之前同事为改善time_wait连接数过多问题曾改过该内核参数。

解决办法是，关闭tcp_tw_recycle：

再观察，发现服务已正常，偶尔连接不上的现象消失。

我们先来man一下这两个参数(man tcp)：

cp_timestamp 是 RFC1323 定义的优化选项，主要用于 TCP 连接中 RTT(Round Trip Time) 的计算，开启 tcp_timestamp 有利于系统计算更加准确的 RTT，也就有利于 TCP 性能的提升。（默认开启）

关于tcp_timestamps详情请见： https://tools.ietf.org/pdf/rfc7323.pdf

开启tcp_tw_recycle会启用tcp time_wait的快速回收，这个参数不建议在NAT环境中启用，它会引起相关问题。

tcp_tw_recycle是依赖tcp_timestamps参数的，在一般网络环境中，可能不会有问题，但是在NAT环境中，问题就来了。比如我遇到的这个情况，办公室的外网地址只有一个，所有人访问后台都会通过路由器做SNAT将内网地址映射为公网IP，由于服务端和客户端都启用了tcp_timestamps，因此TCP头部中增加时间戳信息，而在服务器看来，同一客户端的时间戳必然是线性增长的，但是，由于我的客户端网络环境是NAT，因此每台主机的时间戳都是有差异的，在启用tcp_tw_recycle后，一旦有客户端断开连接，服务器可能就会丢弃那些时间戳较小的客户端的SYN包，这也就导致了网站访问极不稳定。

主机A SIP:P1 (时间戳T0) --->Server 主机A断开后

主机B SIP:P1 (时间戳T2) T2 <T0 --->Server 丢弃

经过此次故障，告诫我们在处理线上问题时，不能盲目修改参数，一定要经过测试，确认无误后，再应用于生产环境。同时，也要加深对相关内核参数的认识和理解。

本文解决灵感来自于 https://blog.51cto.com/hld1992/2285410

https://blog.csdn.net/chengm8/article/details/51668992

开一台阿里云服务器

1. 进入实例详情页面，在 "网络信息" 模块，点击右方 更多 按钮，下拉框选择 "管理IPv6"

2. 步骤1完成后，弹出一个弹框，标题为 "管理辅助私网IP "，在下面 ipv6地址，点击 "分配新ip"

3. 分配ipv6地址成功后，需要给该地址开通公网带宽，进入ipv6网关详情页面，找到对应的ipv6地址，右方操作栏点击 "开通公网带宽"

4. 服务器拥有ipv6公网ip，终端执行 ping6 ipv6地址 测试是否能正常访问，如果失败了，可能是服务器实例的安全组规则中没有放行 ipv6 地址访问，添加一条新规则，入方向允许 ::1 来源的访问

ssh通过ipv6地址远程登录服务器，格式和ipv4一样，例如：ssh root@2408:4006:1101::1900

注意，ssh通过ipv6登录服务器，需要该服务器sshd已经配置可以通过ipv6登录，若未配置，需要先登录到该服务器，修改sshd配置文件

① vim /etc/ssh/sshd_config

②输入/AddressFamily，将值修改为 any 后保存文件 (适用于ipv4和ipv6，若为inet则适用于ipv4，inet6适用于ipv6)

③重启ssh，/etc/init.d/ssh restart，重启后ssh就可以通过ipv6远程登录该服务器了

参考阿里云帮助文档：https://help.aliyun.com/document_detail/98597.html?spm=a2c4g.11186623.6.1032.6d641003094NOS

---