记一次解决阿里云服务器偶尔连接不上的问题（由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://toolsietforg/pdf/rfc7323pdf

开启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://blog51ctocom/hld1992/2285410

https://blogcsdnnet/chengm8/article/details/51668992

既然网速已经测试过了是正常的，则说明使用阿里云服务器有问题就是其他原因了，大体有如下几种，登录的服务器与自己的宽带不是同一运营商，这属于运营商之间的网络瓶颈，只能更换同一运营商的服务器。另外还可能此服务器端口速率过低或者处理能力不行造成的。

阿里云虚拟主机管理是通过云服务器（Elastic Compute Service，简称ECS）来实现的。

云服务器是阿里云提供的性能卓越、稳定可靠、弹性扩展的IaaS（Infrastructure as a Service）级别云计算服务。

使用阿里云虚拟主机管理，将拥有以下优势的计算机资源。

1、无需自建机房，无需采购以及配置硬件设施。

2、分钟级交付，快速部署，缩短应用上线周期。

3、快速接入部署在全球范围内的数据中心和BGP机房。

4、成本透明，按需使用，支持根据业务波动随时扩展和释放资源。

5、提供GPU和FPGA等异构计算服务器、弹性裸金属服务器以及通用的x86架构服务器。

6、支持通过内网访问其他阿里云服务，形成丰富的行业解决方案，降低公网流量成本。

7、提供虚拟防火墙、角色权限控制、内网隔离、防病毒攻击及流量监控等多重安全方案。

8、提供性能监控框架和主动运维体系。

9、提供行业通用标准API，提高易用性和适用性。

阿里云ECS（ElasticComputeService）是一种云服务器产品，位于云端，用户可以使用它来运行自己的应用程序、网站或服务等。用户可以在阿里云控制台上购买ECS实例，并根据自己的需求选择不同的实例规格、操作系统、网络配置和存储选项。

虽然ECS实例位于云端，但用户仍然可以像使用本地服务器一样使用它们。用户可以通过SSH或远程桌面等方式远程连接到ECS实例，并在上面安装和配置自己的应用程序、网站或服务等。此外，阿里云还提供了丰富的工具和服务，例如弹性IP、负载均衡、自动化部署、监控和告警等，帮助用户更轻松地管理和运维ECS实例。

需要注意的是，由于ECS实例位于云端，与本地服务器相比，网络延迟和带宽限制可能会对应用程序的性能和响应时间产生影响。因此，在设计和部署应用程序时，需要考虑网络瓶颈和优化策略，以确保应用程序在ECS实例上的正常运行。

1 卸载当前云盾插件：

使用命令ps aux | grep AliYunDun 找出aegis进程的pid（第二列数字number）

使用命令kill -9 number杀死云盾进程

使用命令find / -name aegis查找云盾插件相关文件，然后删除罗列出来的文件以及文件夹

2    安装最新版本云盾插件

#wget http://updateaegisaliyuncom/download/installsh

#chmod +x installsh

#/installsh

3    按照云监控ECS监控插件安装方法，重新安装云监控插件。

https://helpaliyuncom/knowledge_detail/6533475html

dos在应用层的防御方法？

1最常见的针对应用层DDOS攻击的防御措施，是在应用中针对每个“客户端”做一个请求频率的限制。

2应用层DDOS攻击是针对服务器性能的一种攻击，那么许多优化服务器性能的方法，都或多或少地能缓解此种攻击。合理地使用memcache就是一个很好的优化方案，将数据库的压力尽可能转移到内存中。此外还需要及时地释放资源，比如及时关闭数据库连接，减少空连接等消耗。

3在网络架构上做好优化。善于利用负载均衡分流，避免用户流量集中在单台服务器上，同时可以充分利用好CDN和镜像站点的分流作用，缓解主站的压力。

通用防火墙是怎么样防DDOS的，是依靠规则，策略，还是什么？

首相要判断是什么样的攻击，DDoS是针对IP的攻击，而CC攻击的是网页，DDoS可以用硬件防火墙来过滤攻击，CC攻击本身的请求就是正常的请求，硬件防火墙对他起不到很好的防御效果。

如果用的云服务器比如腾讯阿里这些都有配套的高防服务，阿里云盾和腾讯的大禹，一般的DDOS攻击应该没什么问题，中等以下规模攻击上面的高防服务器都可以搞定，如果遇到CC就得上高防IP

储备的知识防御的了小打小闹的问题，解决不了根本痛点，顶多算是和对方打游击。寻求正统的解决办法直接了断吧。

下面是高防服务器和高防IP的传送门你要了解飞过去吧，我就不复制粘贴了。

DDoS防护_BGP高防_DDoS攻击防护

BGP高防IP

如果是大流量持续性的那你就跟他耗吧，看谁先受不了，毕竟对方也有成本的都是玩钱。

对了也可以直接联系云服务商的客服，腾讯的客服反应还是很迅速而且有一定的技术支持给你解决突发的情况都是没问题的。

linux下防DDOS攻击软件及使用方法有哪些？

一些常用的防DDOS攻击的方法，罗列如下：

1增加硬件防火墙和增加硬件设备来承载和抵御DDOS攻击，最基本的方法，但成本比较高。

2修改SYN设置抵御SYN攻击：SYN攻击是利用TCP/IP协议3次握手的原理，发送大量的建立连接的网络包，但不实际建立连接，最终导致被攻击服务器的网络队列被占满，无法被正常用户访问。Linux内核提供了若干SYN相关设置，使用命令：sysctl-a|grepsyn

3安装iptables对特定ip进行屏蔽。A安装iptables和系统内核版本对应的内核模块kernel-smp-modules-connlimitB配置相应的iptables规则

4安装DDoSdeflate自动抵御DDOS攻击：DDoSsdeflate是一款免费的用来防御和减轻DDoS攻击的脚本。它通过netstat监测跟踪创建大量网络连接的IP地址，在检测到某个结点超过预设的限制时，该程序会通过APF或IPTABLES禁止或阻挡这些IP

ddos手段有哪些？

ddos攻击主要有以下3种方式。

大流量攻击

大流量攻击通过海量流量使得网络的带宽和基础设施达到饱和，将其消耗殆尽，从而实现淹没网络的目的。一旦流量超过网络的容量，或网络与互联网其他部分的连接能力，网络将无法访问。大流量攻击实例包括ICMP、碎片和UDP洪水。

TCP状态耗尽攻击

TCP状态耗尽攻击试图消耗许多基础设施组件(例如负载均衡器、防火墙和应用服务器本身)中存在的连接状态表。例如，防火墙必须分析每个数据包来确定数据包是离散连接，现有连接的存续，还是现有连接的完结。同样，入侵防御系统必须跟踪状态以实施基于签名的数据包检测和有状态的协议分析。这些设备和其他有状态的设备—包括负责均衡器—被会话洪水或连接攻击频繁攻陷。例如，Sockstress攻击可通过打开套接字来填充连接表以便快速淹没防火墙的状态表。

应用层攻击

应用层攻击使用更加尖端的机制来实现黑客的目标。应用层攻击并非使用流量或会话来淹没网络，它针对特定的应用/服务缓慢地耗尽应用层上的资源。应用层攻击在低流量速率下十分有效，从协议角度看，攻击中涉及的流量可能是合法的。这使得应用层攻击比其他类型的DDoS攻击更加难以检测。HTTP洪水、DNS词典、Slowloris等都是应用层攻击的实例。