理解Linux 系统负载

视频讲解linux 系统负载,当我们电脑很卡的时候,系统的负载肯定也很高,那怎么衡量Linux 系统负载,又应该怎么理解系统负载?

你好,我是好刚,这一讲我们来了解Linux 系统负载。如果你的电脑很慢,你或许想查看一下,它的工作负载是不是很高。这里我将通过一座大桥通车能力的类比,带你理解Linux 系统负载。

先说明视频内容来源,这期视频来源于阮一峰老师的博客《理解Linux 系统负载》,这是阮老师的博客地址。

1. 查看系统负载

先来看看怎么查看系统负载。在Linux 系统中,可以使用uptime 命令,在终端输入 uptime ,会看到这么一行信息:

这里后半部分 load average 就是系统的平均负载,这有三个数字,分别是1分钟、5分钟和15分的系统平均负载。当CPU 完全空闲的时候,平均负载为0,当CPU 工作量饱和的时候平均负载为1.0,数值越低说明电脑的工作量越小。

这里有3 个数字,它们的值可能不一样,要从这3 个数字判断出系统负载到底是大还是小,我们还需要理解系统负载的真正含义。

2. 理解负载

2.1 单个CPU 负载

首先假设最简单的情况,就是你的电脑只有一个CPU,并且这个CPU 是单核的,所有的运算都必须由这个CPU 完成。

我们可以把这个CPU 想象成一座大桥,桥上只有一条车道,所有车辆都必须从这条车道上通过,车道上一次最多能跑10 辆车。

  • 如果系统负载为0,就相当于大桥上一辆车也没有。
  • 如果系统负载为0.5,意味着大桥一半的路段有车,车道上有5 辆车。
  • 如果系统负载为1.0,那意味着大桥的所有路段都有车,大桥已经”满”了。但是要注意这个时候大桥还是能顺畅通行的。
  • 继续增加,如果系统负载为1.7,这就意味着车辆太多了,大桥已经被占满,车道上有10 辆车,并且还有7 辆车等着上桥。等待的车辆数量是桥面上正在通行车辆的70%。
  • 当系统负载大于1.0,后面的车辆就必须等待,系统负载越大,等待的车辆越多,那就必须等待越久的时间才能过桥。

回到CPU 的负载,这里大桥的通行能力,就是CPU 的最大工作量;桥梁上的车辆,就是一个个等待CPU处理的进程(process)。如果CPU 1分钟最多处理100 个进程。

  • 那当系统负载为 0.5,意味着CPU 在这1分钟里只处理50个进程
  • 如果系统负载1.0,意味着CPU在这1分钟里正好处理100个进程
  • 如果系统负载1.7,意味着除了CPU正在处理的100个进程以外,还有70个进程正排队等着CPU处理。

理解了系统负载我们能轻易得出结论,为了电脑顺畅运行,系统负载最好不要超过1.0,这样就没有进程需要等待,所有进程都能第一时间得到处理。

这里1.0 是一个关键值,超过这个值,系统就不在最佳工作状态。不过1.0 可不是系统负载的理想值,工作中我们需要留一点余地,一般经验是这样的:

  • 当系统负载持续大于0.7,就必须开始调查,看问题出在哪里,防止情况恶化。
  • 当系统负载持续大于1.0,你必须动手寻找解决办法,把这个值降下来,一般是kill 进程。
  • 当系统负载达到5.0,表明你的系统有很严重的问题,基本是死机状态了。

2.2 多CPU 与多核

这里的讲解是假设你的电脑只有1 个CPU。再来看看如果你的电脑装了2个CPU,会发生什么情况呢?

2个CPU,意味着电脑的处理能力翻了一倍,能够同时处理的进程数量也翻了一倍。还是用大桥来类比的话,两个CPU 就意味着大桥有两条车道,通车能力翻倍了。

如果是1 个CPU,你的系统负载可以达到1.0,2个CPU 你的系统负载可以达到2.0,这个时候每个CPU都达到100% 的工作量。推广开来,n个CPU的电脑,可接受的系统负载最大为n * 1.0。

现在个人电脑大多是一个CPU,CPU内部再包含多个CPU 核心,这被称为多核CPU。多核CPU 与多CPU 效果是类似的,每增加一个核心相当于大桥增加了一条车道。

所以我们在考虑系统负载的时候,必须考虑这台电脑有几个CPU、每个CPU有几个核心。把系统负载除以总的核心数,只要每个核心的负载小于1.0,就表明电脑是正常运行状态。

3. 最佳观察时长

理解了系统负载的含义,再来看看对于 “load average” 返回的三个平均值,我们应该参考哪个值?

先用负载数除以电脑上CPU 的总核心数得到平均每个核心的负载,如果只有1 分钟的系统平均负载大于1.0,其他两个时间段都小于1.0,这表明高负载只是暂时现象,问题不大。如果15分钟内,系统平均负载都大于1.0 那就说明问题是持续存在的,需要赶紧解决。所以我们平时观察时,应该主要观察”15分钟系统负载”。

小结

最后小结,这一讲我们了解了Linux 系统平均负载,知道负载与CPU 个数和CPU 核心数有关,只要每个核心的平均负载数小于1.0 就说明所有进程都能在第一时间处理,系统运行顺畅。通过 uptime 命令可以查看负载数值,负载有3 个数值,分别表示1分钟,5分钟和15分钟的负载,我们应该主要关注15 分钟的负载数值。

这就是这一讲的全部内容,我是好刚,如果讲解对你有所帮助,也请你帮忙关注和转发。

最后内容声明,这期视频来源于阮一峰老师的博客《理解Linux 系统负载》,这是博客地址。阮老师写了很多通俗易通的技术文章,我想你也一定读过阮老师的博客,这是阮老师的微信公众号,欢迎您订阅。

好刚编程,让技术更好懂

参考文献

  1. 理解Linux 系统负载

DDoS 攻击

DDoS 攻击

视频讲解DDoS 攻击,包括DDoS 的定义,攻击原理和防御措施

你好,我是好刚,这一讲我们来了解DDoS 攻击。

前段时间阮一峰的博客遭遇了DDoS 攻击,一个个人博客受到这种攻击,实在是说不过去。这里我们来看看DDoS 到底是怎么回事。

1. DDoS 是什么

DDoS 的全称是分布式拒绝服务,这个名字可以分为两部分:拒绝服务和分布式。

拒绝服务可以理解为:让一个网站无法访问,不能正常处理用户的请求。要达到这个目的,方法很简单:攻击者构造超过网站处理能力的请求量,耗尽网站的网络带宽和系统资源,让服务暂时中断或停止,从而让合法用户的请求无法及时处理。拒绝服务是一种攻击手段。

再来看下分布式:对于网站,一般都有很强的网络带宽和服务器,单个攻击者构造的请求攻击基本不可能达到网站服务器的处理极限,很可能网站没被压垮,攻击者自己先出问题。针对这种情况,攻击者会组织很多机器同时发出服务请求,一台不行就用很多台机器进行攻击,直到网站无法访问,这就叫分布式。

DDoS 攻击简单解释:就是大量机器,在短时间内发起大量请求,耗尽目标网站服务器的资源,使得网站无法响应正常的访问。

这就是DDoS 的原理,再来看下DDoS 的攻击方式。

2. DDoS 攻击

当一个请求从浏览器出发后,要经过网络传输,要与网站服务器建立TCP 连接,最后由网站WEB 服务进行处理,这里面各个环节,都可能被攻击。只要一个环节被攻破,就能使得整个流程跑不通,达到瘫痪服务的目的。

常见的攻击方法可以分为以下三类:

2.1 攻击网络带宽

第一类是攻击网络带宽,网络上数据包的数量达到或者超过上限的时候,会出现网络拥堵、响应缓慢的情况。DDoS就是利用这个原理,发送大量网络数据包,占满被攻击目标的全部带宽,从而造成正常请求无法处理,达到拒绝服务的目的。

常见的有ICMP 洪水攻击、或者UDP洪水攻击,通过发送大量报文,对网络造成拥堵,服务器响应速度变慢。

2.2 攻击系统

第二类是攻击系统,请求创建TCP 连接时,客户端需要与服务器进行三次握手,握手信息通常保存在连接表中,但是表的大小有限,当超过了存储量,服务器就无法创建新的TCP连接了。利用这一点,攻击者会建立大量恶意的TCP连接,占满被攻击目标的连接表,使网站无法接受新的TCP连接请求,达到拒绝服务的目的。

2.3 攻击应用

第三类是攻击应用,现在互联网的主要应用是Web 服务,也就是处理用户请求的地方,这使得它成为分布式拒绝服务攻击的主要目标。

具体实现是,攻击者利用大量的受控主机不断地向Web 服务器发送大量HTTP 请求,要求Web 服务器处理,这些恶意请求会完全耗尽服务器资源,让正常用户的Web 访问得不到处理,导致用户无法访问网站。一旦Web服务受到这种攻击,就会对其承载的业务造成致命的影响。

这种攻击WEB 服务器的方式也叫CC 攻击,CC (Challenge Collapsar),意思是“挑战黑洞”,之所以叫“挑战黑洞”,是由于在互联网早期,有一个叫“黑洞”(Collapsar)的系统能抵御DDoS 攻击,于是骇客只能研究出新的攻击方式,来挑战“黑洞”系统,这种攻击也就被命名为“挑战黑洞”。

阮一峰的博客遭遇的就是CC 攻击,恶意请求像洪水一样涌来,个人网站又没有任何防护,这种流量一来立刻就下线了。

我们再来看看,对于CC 攻击,都有哪些防御方法。

3. DDoS 防御

3.1 备份网站

防范 DDoS 的第一步,就是要有一个备份网站,或者一个临时主页。生产服务器万一下线了,可以立刻切换到备份网站,显示公告,告诉用户,网站出了问题,正在全力抢修。

3.2 拦截请求

第二步是拦截请求,根据请求日志,看下恶意请求是否有特征,如果有,对付起来很简单:直接拦截它就行了。

HTTP 请求的特征一般有两种:IP 地址和 User Agent 字段。比如,恶意请求都是从某个 IP 段发出的,那么把这个 IP 段封掉就行了。或者它们的 User Agent 有特征,像包含某个特定的词语,那就把带有这类 UA 的请求拦截掉。

拦截可以在三个层次做:

  1. 专用硬件:可以在Web 服务器的前面架设硬件防火墙,专门过滤请求。这种效果最好,但是价格也最贵。
  2. 软件防火墙:操作系统都带有软件防火墙,可以用来拦截特定 IP 请求。
  3. 过滤请求:Web 服务器也可以过滤特定请求,nginx 拒绝处理某个IP 的规则是 deny 1.2.3.4

另外nginx 也有专门限制每秒请求数的模块ngx_http_limit_req_module 和限制IP连接数的模块 ngx_http_limit_conn_module

如果想要更精确的控制(比如自动识别并拦截那些频繁请求的 IP 地址),就要用到 WAF。

3.3 带宽扩容

第三步是带宽扩容,拦截HTTP 请求有一个前提,就是请求必须有特征。但是很多时候,DDoS 攻击是没有特征的,它的请求看上去跟正常请求一样,而且来自不同的 IP 地址,所以没法拦截。这也是为什么 DDoS 特别难防的原因。

当然,这样的 DDoS 攻击的成本很高,普通的网站不会有这种待遇。真要遇到了这种攻击怎么办呢?

答案很简单,就是设法把这些请求都消化掉。对于网站来说,就是在短时间内急剧扩容,提供几倍或几十倍的带宽,顶住大流量的请求。

3.4 CDN

还有第四步,就是使用CDN,CDN 可以将网站的静态内容分发到多个服务器,用户就近访问,提升速度。

同时CDN 也是带宽扩容的一种方法,可以用来防御 DDoS 攻击。因为CDN 上面是网站内容的缓存,用户只允许访问 CDN,攻击者的请求也只会请求到CDN 上。这样,只要 CDN 够大,就可以抵御很大的攻击。另外如果CDN 上缓存的内容不存在了,也只有CDN 向源服务器发出请求,大大降低了源服务器的访问压力。

不过,CDN 有一个前提,网站的大部分内容必须可以静态缓存。对于动态内容是不能缓存的。

还有一旦用了 CDN,千万不要泄露源服务器的 IP 地址,否则攻击者可以绕过 CDN 直接攻击源服务器,CDN 也就白费了。现在大部分云服务商都有提供弹性IP 服务,可以动态挂载主机实例,当IP 受到攻击的时候,可以直接换一个IP地址。

安全无小事,DDoS 攻击就介绍到这,你听懂了吗。最后请帮忙关注和转发,这个很重要,多谢。我是好刚,好钢用在刀刃上,我们下期见。

参考资料

XXE 漏洞攻击流程

视频讲解XXE 漏洞的攻击流程以及这次微信支付的漏洞到底出现在哪个环节

你好,我是好刚,在上一讲,我们了解了XXE 漏洞的原理,这一讲我们来看一看XXE 漏洞的攻击流程以及这次微信支付的漏洞到底出现在哪儿。

1. XXE漏洞攻击流程

这里我们也是看一个例子,看看怎样通过XXE 漏洞读取服务器上的文件信息。

对于一次XXE 漏洞攻击,一般有3 个参入方,首先是攻击者,攻击是他发起;然后是被攻击者,一般是一台web 服务器;再就是攻击者服务器,用来接收被攻击者服务器的文件内容。

1.1 漏洞接口

假设被攻击者的web 服务器中存在一个接口: 127.0.0.1/api/pay,这个接口能够接收xml 格式的参数,并且会对xml 进行解析。

1.2 构造请求

针对这个接口,攻击者会构造xml 格式的请求数据,请求的xml 内容如下:

http://127.0.0.1:9000/xxe.dtd 是攻击者服务器中的dtd 文件,内容如下:

1.3 解析请求

然后是第三部分,被攻击的web 服务器收到xml 参数后,会对xml 进行解析:

第一步:读取 file:///etc/password 的内容,作为 % file 实体的值,这里 % 表示这个实体是参数实体,之所以使用参数实体,是因为只有参数实体才可以在DTD 中使用,另外由于参数实体只能在外部引入的DTD 文件中声明实体时使用,所以我们还需要引入一个外部DTD 文件。

第二步:这里xxe.dtd 是攻击者服务器上的DTD 文件,通过 http://127.0.0.1:9000/xxe.dtd 拿到的是恶意DTD 文件。

第三步:解析恶意DTD 文件 xxe.dtd,这里会请求攻击者服务器上的 http://127.0.0.1:9000/attack/%file; ,并且将 /etc/password 文件的内容作为路径参数,这个请求会在攻击者服务器 http://127.0.0.1:9000 中留下访问记录,这样攻击者就能根据请求日志,拿到了 /etc/password 文件的内容。

这个示例里,窃取的是 /etc/password 文件的内容,实际上只要有文件读权限,攻击者可以拿到服务器中任何文件的内容,像代码里面的秘钥,服务器登录密码等等。

这就是一个典型的XXE 漏洞攻击,我们再来看看这次漏洞对微信支付的影响到底是什么样。

2. 支付漏洞是怎么回事

要了解这个漏洞对支付的影响,首先需要了解支付流程,我们来看一个简略版的支付过程。

153115299354760cd

再一次购物支付中,一般会包含三个参入方:用户,商家和支付服务商,流程一般是这样的:

  1. 正常用户选择好商品,请求商家服务器进行下单,商家计算付款金额后显示支付页面,提示用户支付。
  2. 用户会根据支付金额触发微信支付,注意,这个时候用户会进入微信支付的页面,与微信进行交互,并且完成付款。
  3. 微信会将支付完成的消息回调给商家服务器,通知商家,用户已经支付完成,商家确认订单和支付金额没有问题后会将订单状态改为已付款状态。
  4. 然后提示用户付款完成,并且跳转到购买成功的页面

这就是一次购物支付的简单流程,当然实际的支付流程比这复杂得多,感兴趣的同学可以通过下方我给出的参考资料找到相关文档。

这次产生漏洞的位置是在第3 步,用户支付完成后,微信需要请求商家服务器接口,通知商家,用户已经支付。这个接口的代码一般会使用微信提供的SDK 进行开发,而这个SDK 里面有段代码在解析XML 格式的请求数据时,出现了外部实体注入漏洞,这就是这次支付漏洞的由来。

如果用户通过这个漏洞拿到了商家的支付公秘钥,那就可以跳过第2 步支付的过程,直接第3 步的接口发送模拟的通知请求,从而达到不花钱获取商品的目的。

在很多媒体的报道中,也都强调通过这个漏洞,攻击者不花钱就可以获得商品。但是对于大型购物网站,都会有对账系统,这个系统会定时将网站的用户订单数据与微信后台的数据进行对比,一旦出现不一致时会及时报警;而且这个通知接口的地址,一般也只有内部开发人员才知道,所以这个漏洞在这方面的影响可能并没有想象的那么大。

其实除了不花钱获取商品,攻击者更可能造成的危害是:通过这个漏洞获取到服务器上的代码配置和数据,然后再根据这些信息进行下一步的攻击。

3. 漏洞的解决

最后来看下这个漏洞的解决方案,通过上一讲XXE 漏洞的原理以及这一讲攻击流程的介绍,可以看到XXE 漏洞之所以能够存在,本质上在于解析XML 外部实体的时候,可以读取外部文件,才使攻击成为可能。

那解决这个漏洞的办法也非常简单,就是禁止XML 可以解析外部实体。代码上只需要明确调用禁止解析外部实体的函数就行了。

安全无小事,XXE 漏洞原理和攻击流程就介绍到这,你听懂了吗。最后请帮忙关注和转发,让身边的同事也了解一下这个漏洞吧。我是好刚,好钢用在刀刃上,我们下期见。

参考资料


©2019 | 鄂ICP备18002823号-2 |鄂公网安备 42018502000885号