Linux服务器在高并发压力测试后，测试计算机或服务器请求（telnet）linux服务器的任何端口（包括22）

本人只是将本次问题的解决方案，整理上传，以便于解决各位同仁的问题。 也便于自己查看阅读。

部署环境简介：

                A服务器：项目部署地址，windows服务器

               B服务器：数据库，redis部署位置.（linux服务器）

                接口简单流程：A链接B数据库获取信息，存入B的redis。

           内部机房

出现问题情况：

                用测试工具jmeter高并发测试A的http接口时，在同时1000线程的测试环境下面运行了将近30秒时，请求全部报错，链接不上B服务器的数据库与redis，马上在A服务器上面去telnetB的redis端口也出现连不上的情况，然后去测试系统级端口，还是出现连不上的情况。

              当我们重启了B服务器后，A服务器又可以连上数据库与redis,一切正常，但是我们的接口bi必须支持高并发，所以再一次测试并发，还是出现这种问题，我们内部判断可能是机房网络原因，因为之前出现过丢包的情况。约了机房运维，进入机房ji解决。

解决步骤：

        一：可能两边端口池用完，排除应用端口，请求系统端口。

       答案：端口池没有用完，系统级的端口也请求不到。

       二：排除交换机原因，两台服务器直接网线连接，在A上面请求B任意端口。

       答案：还是请求不到，应用、系统等端口meiy没有一个能请求到。

       三：B服务器防火墙原因，检查B、A所有防火墙，全部关闭，还是不行。

      四：抓包，在B上面抓取A的请求系统级端口的包。

      linux抓包：https://www.cnblogs.com/test1988/p/7707802.html

       答案：只有请求，没有ACK返回。

请求抓包

    正常的情况下：

正常的请求抓包

      所以问题找到了，是请求了没返回，那么排查这个问题出现原因。

     五：解决问题

    通过百度、google找到有人也出现过这种问题，是通过调整sysctl -w net.ipv4.tcp_timestamps=0或者sysctl -w net.ipv4.tcp_tw_recycle=0来解决这个问题。于是就找为什么这样可以解决。

而在查询这两个参数的过程中，发现问题原因如下：

发现是 Linux tcp_tw_recycle/tcp_timestamps设置导致的问题。 因为在linux kernel源码中发现tcp_tw_recycle/tcp_timestamps都开启的条件下，60s内同一源ip主机的socket connect请求中的timestamp必须是递增的。经过测试，我这边centos6系统（kernel 2.6.32）和centos7系统（kernel 3.10.0）都有这问题。

于是找到了这篇文章：http://blog.51cto.com/leejia/1954628，请自己理解，谢谢。

根据上面文章，解决办法：echo "0" > /proc/sys/net/ipv4/tcp_tw_recycle

如何优化ip4的内核参数与配置，就看各位大佬们自己，本人萌新一枚、还是只会喊666的那种。

解决之后，再次高并发测试，没有此类问题出现，但是将这个关闭会不会引发另外新的问题，就得各位同仁自己查询资料去解决，我们也在慢慢验证与摸索阶段，请各位大佬多多指点，如有问题，请留言。