腾讯云slb（腾讯云官网首页）
本文目录一览：
一次限流的引发思考
一个api接口 /srm/api2/disabletime 需要提供最大600qps的能力，超过600qps之后需要进行限流，返回429 http code。
现在业务节点一共20台，为了异地多活，分布在2机房gz和gz6,俩机房各十台机器上。
服务限流通常有以下俩种方式：
俩种方式各有优点和缺点
本次实验就是使用的第一种方式，为了保证qps达到600之后能限流，所以理想情况下(也就是流量分部均匀的情况)每台机器的qps为30=600/20，但是实际情况发现，每天机器上的该api的请求量非常的不均，有的是个位数，有的达到了50多个。
可能有人有疑惑，每个节点流量不均有什么影响呢？那我解释下。当整个服务的流量来了600qps时，由于流量不均，有的节点流量分布是40或者50的请求量，有的节点是个位数8，5的请求量。现在每台机器的配置的qps为30，那么大于30qps的那些节点就出触发限流了，最终导致整个服务没有达到600qps时就触发限流了。
想要了解流量为什么不均匀，需要首先搞清楚业务整体架构。
最初理解的架构如下，可以很明显的发现，在gz和gz6俩机房的slb数量不一致，也就导致了gz的业务机器流量大于gz6的业务机器流量。
理论上 ,gz 的 slb流量会发给 gz 的 nginx,gz6 的slb流量会发给 gz6 的 nginx。腾讯云的负载均衡，发给 slb 的流量，不区分 gz 与 gz6 ，在所有 slb 的机器里执行轮询策略的负载均衡。
那么gz 的 slb 机器数量比 gz6 多，那 gz机房获得的流量就比 gz6机房多， gz 的 nignx获得的流量就比 gz6的nginx多。
上面解释看似合理，结论就是：由于gz和gz6俩机房的业务节点数量相同，而gz和gz6的slb的数量不同， 最终导致了俩机房的流量不均，进而导致了gz和gz6的业务节点的流量不均 。
下图是对接口压测2分钟，每秒600qps的流量趋势图，可以出在gz和gz6的流量大致分部均匀，大致在300Qps左右，这也就间接的证明了上面的想法不对。
上面俩张的流量分部印证了上面的架构是不对的，通过查询，正确的架构如下，可以看出和上面的架构图有几点不同
架构看起来是没问题，流量到最终端的业务节点也是均匀的，但是事实就是流量是不均匀的，我们结合实际情况来看下，比如轮训业务节点为a-b-c：
首先slb的轮训 据指定url来轮训 的，是 根据整个服务的所有请求 的来轮训的 ，比如第一个压测请求打到的是a业务节点，如果当前时间整个服务没有别的请求，那么第二个压测请求肯定会打到b业务节点，但实际情况是，当前时间肯定有别的请求，所以第二个压测请求时可能打到的还是a业务节点，也可能是b业务节点，可能是集群中的任何一个业务节点，我猜测就是这个原因导致了最终的流量不均匀。
为了证明这个猜想，我们可以看看 21:49:00 这个时间点所有机器上的所有请求是不是大致平均的，如果是平均的，则证明我们猜想正确。
可以看出所有机器的请求量大致基本相同，我们的猜想正确。
使用第一种方式通常有个大前提： 是各个机器流量分布必须非常均匀的，每台机器配置的qps=总qps/机器节点数量。但是由于网络总是不稳定性或者其他原因通常流量是不均匀的，所以需要每台节点配置的qps加一些Buffer，40或者50qps 。
如果使用第二种方式的话，我们直接在redis配置600qps即可，因为不需要关注每台机器流量的流量分布，管你节点的流量是50还8呢，只要总和大于600qps后，服务就会触发限流了。
如果第二种方式能够实现，建议使用第二种方式。
阿里云oss对象存储 什么意思
oss 也叫对象存储，用来存放图片，css、视频等静态文件。可以作为网站、app等web应用的：附件服务器、头像服务器、图片服务器、下载服务器。
每家叫法不一样，阿里云叫oss，腾讯云叫cos，其实都是一个东西。老魏为此写过云服务器oss建站等多篇教程，看完有疑问可以问，在线了就回答。
云提供的服务层次由低到高比喻什么
可以比喻为一座大楼，其中从基础层到高级层的服务依次有：基础层：腾讯云的基础设施服务，如：CVM（云服务器）、CCM（云存储）、COS（对象存储）等，支撑着整个云服务架构的基础。
1、核心层：腾讯云的核心服务，如：CDN（内容分发网络）、VPC（专有网络）、SLB（负载均衡）等，是云服务架构的核心功能和支撑。
2、应用层：腾讯云的应用服务，如：TKE（容器服务）、CLB（负载均衡）、CVM（云服务器）等，可以在基础和核心层的基础上搭建应用和服务，满足不同业务需求。
3、最上层：腾讯云的管理层服务，如：CAM（云资源管理）、TMT（腾讯云统一管理）、IM（实时通信）等，可以提供丰富的管理功能，帮助用户更好地管理和控制腾讯云资源。
服务器被DDOS攻击最佳解决方案是什么？报网警有用么？
服务器被DDOS攻击最佳解决方案是什么？报网警有用么？
目前，有效缓解DDoS攻击的解决方案可分为 3 大类：
架构优化
服务器加固
商用的DDoS防护服务
架构优化
在预算有限的情况下，建议您优先从自身架构的优化和服务器加固上下功夫，减缓DDoS攻击造成的影响。
部署DNS智能解析通过智能解析的方式优化DNS解析，有效避免DNS流量攻击产生的风险。同时，建议您托管多家DNS服务商。
屏蔽未经请求发送的DNS响应信息
典型的DNS交换信息是由请求信息组成的。DNS解析器会将用户的请求信息发送至DNS服务器中,在DNS服务器对查询请求进行处理之后,服务器会将响应信息返回给DNS解析器。
但值得注意的是,响应信息是不会主动发送的。服务器在没有接收到查询请求之前,就已经生成了对应的响应信息,这些回应就应被丢弃。
丢弃快速重传数据包
即便是在数据包丢失的情况下,任何合法的DNS客户端都不会在较短的时间间隔内向同- -DNS服务器发送相同的DNS查询请求。如果从相同IP地址发送至同一目标地址的相同查询请求发送频率过高,这些请求数据包可被丢弃。
启用TTL
如果DNS服务器已经将响应信息成功发送了，应该禁 止服务器在较短的时间间隔内对相同的查询请求信息进行响应。
对于一个合法的DNS客户端,如果已经接收到了响应信息,就不会再次发送相同的查询请求。
每一个响应信息都应进行缓存处理直到TTL过期。当DNS服务器遭遇大查询请求时,可以屏蔽掉不需要的数据包。
丢弃未知来源的DNS查询请求和响应数据
通常情况下,攻击者会利用脚本对目标进行分布式拒绝服务攻击( DDoS攻击) , 而且这些脚本通常是有漏洞的。因此,在服务器中部署简单的匿名检测机制,在某种程度上可以限制传入服务器的数据包数量。
丢弃未经请求或突发的DNS请求
这类请求信息很可能是由伪造的代理服务器所发送的,或是由于客户端配置错误或者是攻击流量。无论是哪一种情况，都应该直接丢弃这类数据包。
非泛洪攻击(non-flood) 时段,可以创建一个白名单 ,添加允许服务器处理的合法请求信息。
白名单可以屏蔽掉非法的查询请求信息以及此前从未见过的数据包。
这种方法能够有效地保护服务器不受泛洪攻击的威胁,也能保证合法的域名服务器只对合法的DNS查询请求进行处理和响应。
启动DNS客户端验证
伪造是DNS攻击中常用的一种技术。如果设备可以启动客户端验证信任状,便可以用于从伪造泛洪数据中筛选出非泛洪数据包。
对响应信息进行缓存处理如果某- -查询请求对应的响应信息已经存在于服务器的DNS缓存之中,缓存可以直接对请求进行处理。这样可以有效地防止服务器因过载而发生宕机。
使用ACL的权限
很多请求中包含了服务器不具有或不支持的信息,可以进行简单的阻断设置。例如,外部IP地址请求区域转换或碎片化数据包,直接将这类请求数据包丢弃。
利用ACL , BCP38及IP信营功能
托管DNS服务器的任何企业都有用户轨迹的限制,当攻击数据包被伪造,伪造请求来自世界各地的源地址。设置-个简单的过滤器可阻断不需 要的地理位置的IP地址请求或只允许在地理位置白名单内的IP请求。
同时,也存在某些伪造的数据包可能来自与内部网络地址的情况,可以利用BCP38通过硬件过滤清除异常来源地址的请求。
部署负载均衡通过部署负载均衡( SLB )服务器有效减缓CC攻击的影响。通过在SLB后端负载多台服务器的方式,对DDoS攻击中的CC攻击进行防护。
部署负载均衡方案后,不仅具有CC攻击防护的作用,也能将访问用户均衡分配到各个服务器上,减少单台服务器的负担,加快访问速度。
使用专有网络通过网络内部逻辑隔离,防止来自内网肉鸡的攻击。
提供余量带宽通过服务器性能测试,评估正常业务环境下能承受的带宽和请求数,确保流量通道
不止是日常的量,有-定的带宽余量可以有利于处理大规模攻击。
服务器加固
在服务器上进行安全加固,减少可被攻击的点,增大攻击方的攻击成本:
确保服务器的系统文件是最新的版本,并及时更新系统补丁。
对所有服务器主机进行检查,清楚访问者的来源。
过滤不必要的服务和端口。例如, WWW服务器,只开放80端口,将其他所有端口关闭,或在防火墙上做阻止策略。
限制同时打开的SYN半连接数目,缩短SYN半连接的timeout时间,限制SYN/ICMP流量。
仔细检查网络设备和服务器系统的日志。一旦出现漏洞或是时间变更,则说明服务器可能遭到了攻击。
限制在防火墙外与网络文件共享。降低黑客截取系统文件的机会,若黑客以特洛伊木马替换它，文件传输功能无疑会陷入瘫痪。
充分利用网络设备保护网络资源。在配置路由器时应考虑以下策略的配置:流控、包过滤、半连接超时、垃圾包丢弃,来源伪造的数据包丢弃, SYN阀值,禁用ICMP和UDP广播。
通过iptable之类的软件防火墙限制疑似恶意IP的TCP新建连接,限制疑似恶意IP的连接、传输速率。
识别游戏特征,自动将不符合游戏特征的连接断开。
防止空连接和假人攻击,将空连接的IP地址直接加入黑名单。
配置学习机制，保护游戏在线玩家不掉线。例如,通过服务器搜集正常玩家的信息,当面对攻击时,将正常玩家导入预先准备的服务器,并暂时放弃新进玩家的接入,以保障在线玩家的游戏体验。
商用的DDoS防护服务
针对超大流量的攻击或者复杂的游戏CC攻击,可以考虑采用专业的DDoS解决方案。目前，阿里云、磐石云、腾讯云有针对各种业务场景的DDOS攻击解决方案。
目前，通用的游戏行业安全解决方案做法是在IDC机房前端部署防火墙或者流量清洗的一些设备, 或者采用大带宽的高防机房来清洗攻击。
当宽带资源充足时,此技术模式的确是防御游戏行业DDoS攻击的有效方式。不过带宽资源有时也会成为瓶颈:例如单点的IDC很容易被打满,对游戏公司本身的成本要求也比较高。
您可根据自己的预算和遭受攻击的严重程度,来决定采用哪些安全措施。
安全防护有日志留存的可以选择报网警,前提是你自己的业务没有涉灰问题。
报网警有用吗？
至于报警，肯定有用，你不报警,警方没有线索,怎么抓人?
但是，这个作用不一定立即体现,警方需要时间侦查,需要取证。
DDoS的特点决定了,如果不在攻击时取证,证据很快就没了。因此要攻击者反复作案,才好抓。
对一一个被害人，只作案一次,或者随机寻找被害人的情况，最难抓。
而且调查涉及多方沟通、协调,比如被利用的主机的运营者,被害人,可能涉及多地警方的合作等等。
指望警方减少犯罪分子是可以的,但是指望通过报警拯救你的业务,只能说远水解不了近渴。
发表评论
暂时没有评论，来抢沙发吧~