本文由 发布，转载请注明出处，如有问题请联系我们！ 发布时间: 2021-08-01阿里云安全组怎么设置-阿里云服务器过户办法

Intro: Redis手机客户端库联接到Redis网络服务器请求超时。

大约一两年前，我还在阿里巴巴云上碰到了一个奇特的Redis联接难题。每十分钟，服务项目中的Redis手机客户端库汇报与Redis网络服务器的网络连接超时。那时候花了非常大劲才发觉，阿里巴巴云会断掉闲置不用好长时间的TCP联接，不容易给2个FIN或是RST包。那时候大家的Redis网络服务器沒有开启tcp_keepalive选择项，因此Redis服务端的联接依然存有于Linux的conntrack表中，而Redis手机客户端关掉是由于数据库连接池器重了联接get和set发觉联接断掉。因而，手机客户端上对应的本地端口被回收利用。当Redis器重这一本地端口进行到Redis网络服务器的联接时，Redis服务端的conntrack表中的四联对应状态为ESTABLISHED，因而当然手机客户端推送的TCP SYN数据文件被丢掉，Redis手机客户端见到的状况是网络连接超时。

处理这个问题非常简单，只需开启Redis网络服务器的tcp_keepalive选择项就可以。殊不知那时候想不到这个问题的多方面缘故会造成较大的干扰和明显的不良影响！

孽债：”SELECT 1″ 开启的 jdbc4.CommunicationsException

近期，工作环境中的Java服务项目基本上每分都是会汇报如下所示不正确:

以前有调研阿里巴巴云异常中断Redis联接的例子，因而担心是相似难题。较为手机客户端和网络服务器的conntrack表花了许多時间，可是详细介绍中沒有叙述难题。随后，较为了好多个MySQL服务端的sysctl设定，科学研究了iptables TRACE，科学研究了tcpdump捕捉的信息。检测tw _ tw_reuse，tw_recyle等主要参数，调节阿里云服务器负载均衡设备后边初始化的MySQL网络服务器总数，都失败了，却出现意外发觉了新的难题* *。应用下列指令立即数据库连接而无需阿里巴巴云SLB的情况下，有的数据库查询600秒就可以回到，有的数据库查询一直挂着，不可以退半小时之上，按Ctrl-C也不可以终断

那时候查了一个一切正常数据库查询和一个出现异常数据库查询，发觉wait_timeout和interactive_timeout全是600s。我千辛万苦思考，却搞不懂发生什么事。随后偶然发现另一个数据库查询的wait _ timeout是60s，可是忽然搞清楚曾经的“select 1”难题是什么原因了。

大家的服务项目应用光JDBC数据库连接池[1]，默认设置状况下其idleTimeout为600s，默认设置状况下maxlifetime为1800s。前面一种就是指假如空余JDBC线程数超出极小值，空闲时间超出空余请求超时，空余联接将被关掉；后面一种代表着数据库连接池中的联接活不上maxLifetime，到時间便会关掉。

发觉“挑选1”的情况后，大家觉得这两个主要参数比数据库查询的wait_timeout=600s大，因此我降低了这两个主要参数，idletimeout = 570s，maxlifetime = 585s，将minimumIdle设定为5。可是，这两个时间设置依然超过在其中一个数据库查询不正确设定的wait_timeout=60s，因而60s后MySQL网络服务器会自动关掉空余联接，而JDBC沒有事情开启回调函数体制来关掉JDBC联接。沒有充分的時间让光开启idleTimeout和maxLifetime清除逻辑性，因此光拿着这一“关掉”的联接，向服务器发送“select 1”SQL来检测链接的实效性，进而开启了上边的出现异常。

解决方案非常简单，只需将配备不正确的数据表中的wait_timeout从60秒更改成600秒。下面，大家将再次探讨“SELECT sleep(1000)”会挂起来且没法进入的难题。

起缘：阿里云服务器安全性组和 TCP KeepAlive

近期好看一点佛家基本常识，对“万法起源于缘分”的起缘论印像很深。在“SELECT sleep(1000)”的调研中，我真实地体会到“从缘分考虑”的实际意义。

最先，表述为何有一些数据库查询网络服务器能够回到“SELECT sleep(1000)”，而有一些则不可以。事实上，wait_timeout和interactive_timeout这两个主要参数只对“空余”的连接数据库起效，即沒有实行SQL的联接，针对“SELECT sleep(1000)”，有一个已经实行的SQL。较大实行時间受MySQL Server的max_execution_time限定，大家企业一般将此基本参数为600s，即“SELECT sleep(1000)”终断“一般数据库查询”的实行，600s撤出。

缺憾的是(能够说成又一次不正确配备)，大家的数据库查询max_execution_time是6000s，因此“SELECT sleep(1000)”在MySQL网络服务器上一切正常会在1000s进行实行——但难题是，根据二分搜索法，tcpdump，iptables TRACE，发觉阿里巴巴云会“默默地”丢掉> =910s的空余TCP联接，不容易向手机客户端和服务器发送FIN或RST强制断开。因而，mysql网络服务器在1000秒完毕时发给服务端的ACK PSH TCP数据文件没法抵达手机客户端，随后在waiting _ timeout = 600s秒后，MySQL网络服务器会断掉这一空余联接——缺憾的是，MySQL手机客户端的cmd程序流程依然不明。等待MySQL缺少对象的环节中是特别长久的，Linux核心的conntrack表表明这一联接一直是创建的，即便MySQL网络服务器关掉了相匹配的联接，也仅有这一关掉姿势的FIN TCP包没法抵达手机客户端！

下边是iptables TRACE日志中这个问题的充分证实。

cmd所属设备的iptables TRACE日志表明，mysql手机客户端在23:58:25联接到mysql网络服务器，逐渐实行SELECT sleep(1000)，从没接到网络服务器信息。最终在00:41:20，我手动式杀掉了mysql手机客户端的cmd过程，mysql手机客户端向mysql服务器发送了FIN包可是沒有接到回应(这时mysql网络服务器早已关掉了联接)。

MySQL server 在 00:15:05 时实行 SELECT sleep(1000) 完毕，给 mysql 手机客户端回送結果，但 mysql 手机客户端无响应（被阿里云服务器丢包率了，mysql 手机客户端根本不能收到），在 00:25:05 时，因为 wait_timeout=600s，因此 MySQL server 给 mysql 手机客户端发 FIN 包以断开，当然，mysql 手机客户端不能收到，因此都没有回复，结果是 MySQL server 一侧的 Linux 核心总之自主关掉 TCP 联接了，mysql client 一侧的 Linux 核心仍在傻傻的的在 conntrack table 保持着 ESTABLISHED 情况的 TCP 联接，mysql client cmd仍在傻傻的的 recv 等待服务器端回到或是关掉连接。00:15:05，mysql网络服务器进行实行SELECT sleep(1000)并将結果送回mysql手机客户端，但mysql手机客户端初始化失败(被阿里巴巴云遗失，MySQL手机客户端压根不能收到)。00:25:05，因为wait_timeout=600s，因而，mysql网络服务器向mysql手机客户端推送FIN包，断开。当然，MySQL手机客户端沒有接到，因此初始化失败。最后的结论是MySQL服务端的Linux核心不管怎样都是会自主关掉TCP联接。mysql手机客户端的Linux核心仍在傻傻的地维护保养着conntrack表中已创建情况的TCP联接，mysql手机客户端cmd仍在傻傻的地等候缺少对象或是关掉recv中的连接。

好啦，如今大家知道，针对TCP包传送> = 910s的vm中间传送数据的空余TCP联接，阿里巴巴云会“悄无声息”的遗失包，那麼是否一切vm虚拟机中间都是有？有海港吗？网络服务器必须挂在负载均衡器后边吗？您是不是必须一定数目的高并发联接到合适的端口号？

阿里巴巴云递交订单查看后，沒有取得一切有價值的信息内容。通过艰难的科学实验——每一次试验都需要等接近20分鐘——总算拥有收益，我发现难题平稳发作的规律性:

两部vm虚拟机各自处在不一样安全性组，沒有一同安全性组；服务器端的安全性组开放端口 P 容许手机客户端的安全性组联接，手机客户端不开放端口给服务器端（依照一般有情况服务器防火墙的配备标准，全是只开服务器端端口号，无需开手机客户端端口号）；手机客户端和服务器端联接之后，闲置不用 >= 910s，不传送所有数据信息，都不传送有 keep alive 主要用途的 ack 包；随后服务器端在这里长连接上发送给手机客户端的 TCP 包会在互联网上丢掉，不到手机客户端；但假如手机客户端这时给服务器端发些数据信息，那麼会再次“激话”这条长连接，但这时或是单工情况，手机客户端能给服务器端分包，服务器端的包还不到手机客户端（大约是在服务器端 OS 核心里再试中）；激话后，服务器端再给手机客户端发数据信息时，以前推送不出去的数据信息（假如仍在核心里的 TCP/IP tcp协议再试中），再加上兴新的数据信息，会一起抵达手机客户端，自此这条长连接进到一切正常的全双工运行状态；

下面的图是数控机床检测的結果。

互联网网络服务器

和网民探讨后，我意识到这应该是阿里巴巴云安全性集团公司根据“集中型服务器防火墙”执行导致的。因为集中型服务器防火墙坐落于互联网的神经中枢，要解决很多的联接，因而其运行内存中的conntrack表必须很短的空余请求超时(现阶段为910s)来清除长期不主题活动的conntrack记录，节约运行内存，因此以上难题的根本原因很清晰。

client 联接 server，安全性组（实际上是服务器防火墙）发觉标准容许，因此添加一个纪录到 conntrack table；client 和 server 到 910s 还没有数据信息来往，因此安全性组把 conntrack 里那一条纪录除掉了；server 在 910s 以后给 client 发数据信息，数据文件到安全性组那边，它一看 conntrack table 里没纪录，而 client 侧安全性组又不允许这一端口号的包根据，因此丢包率了，因此 server -> client 堵塞；client 在同一个长连接上给 server 发些数据信息，安全性组一看标准容许，因此添加 conntrack table 里；server 再试的数据文件，或是新数据文件，根据安全性组时，因为已有 conntrack record 了，因此海关放行，因此能抵达手机客户端了。

我明白为何。大家怎么才能绕开这个问题？阿里巴巴云给了我2个不能做的变通方法:

把 server，client 放入同一个安全性组；改动 client 所属安全性组，对外开放全部端口号给 server 所属安全性组；

转念一想，根据netstat -o，大家看到大家的Java服务项目采用的Jedis库和mysql JDBC库都为tcp协议文件句柄打开了SO_KEEPALIVE选择项[2]:

MySQL网络服务器更为它开启的tcp协议文件句柄打开了SO_KEEPALIVE选择项，因此我只必须在网络服务器和手机客户端的其中一侧改动相同的sysctl选择项。下边是咱们企业网络服务器的默认设置配备，便是TCP联接空余1800s后，每30s向客户推送一个ACK包。较多推送三次，假如另一方在这段时间回应，记时器将被重设，随后等候1800s的空余情况。假如另一方在推送三次后初始化失败，它会将RST包发给另一方，并关掉当地tcp协议文件句柄，即关掉这一长连接。

阿里巴巴云跨安全性组的910s空余请求超时限定规定将net.ipv4.tcp_keepalive_time设定为低于910s，如300s。

默认设置的tcp_keepalive_time十分大，这也表述了为啥设定了SO_KEEPALIVE选择项后，Rediscolient被阿里巴巴云默默地断掉。

假如一些互联网库在封裝后沒有给予启用setsockopt的机遇，则必须根据LD_PRELOAD等黑技术性强制性设定。仅有当tcp协议文件句柄的SO_KEEPALIVE选择项开启时，之上三个sysctl才会在这个tcp协议文件句柄上起效。自然，您还可以应用setsockopt涵数在编码中进一步设定keep_alive_intvl和keep alive _ projects，而不是Linux核心的全局性默认。

最终，除开Java家族对SO_KEEPALIVE的优良解决以外，netstat -o发觉正对面NodeJS大家族知名的Redis手机客户端库打开了SO_KEEPALIVE，但其知名的mysql手机客户端库沒有，而Golang家族认真细致得多，2个库都打开了SO_KEEPALIVE。为何前言说这个问题很严重？由于一旦网络服务器解决慢，例如OLAP情景，沒有阿里巴巴云SLB传送数据，网络服务器910s内不回到数据信息，很有可能就沒有机遇向手机客户端回到数据信息。这个问题是查是否有死尸！你也许会跟我说为什么不根据阿里巴巴云SLB转站，SLB不容易默默地丢包率——但它的闲置不用请求超时限制是900s！！！

头顶部相片个人信用:“沒有小虫子”野兔子

可扩展性构架

更改网络的建设方法。