Linux性能优化实战
倪朋飞
微软资深工程师,Kubernetes项目维护者
立即订阅
23325 人已学习
课程目录
已完结 64 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (2讲)
开篇词 | 别再让Linux性能问题成为你的绊脚石
免费
01 | 如何学习Linux性能优化?
CPU 性能篇 (13讲)
02 | 基础篇:到底应该怎么理解“平均负载”?
03 | 基础篇:经常说的 CPU 上下文切换是什么意思?(上)
04 | 基础篇:经常说的 CPU 上下文切换是什么意思?(下)
05 | 基础篇:某个应用的CPU使用率居然达到100%,我该怎么办?
06 | 案例篇:系统的 CPU 使用率很高,但为啥却找不到高 CPU 的应用?
07 | 案例篇:系统中出现大量不可中断进程和僵尸进程怎么办?(上)
08 | 案例篇:系统中出现大量不可中断进程和僵尸进程怎么办?(下)
09 | 基础篇:怎么理解Linux软中断?
10 | 案例篇:系统的软中断CPU使用率升高,我该怎么办?
11 | 套路篇:如何迅速分析出系统CPU的瓶颈在哪里?
12 | 套路篇:CPU 性能优化的几个思路
13 | 答疑(一):无法模拟出 RES 中断的问题,怎么办?
14 | 答疑(二):如何用perf工具分析Java程序?
内存性能篇 (8讲)
15 | 基础篇:Linux内存是怎么工作的?
16 | 基础篇:怎么理解内存中的Buffer和Cache?
17 | 案例篇:如何利用系统缓存优化程序的运行效率?
18 | 案例篇:内存泄漏了,我该如何定位和处理?
19 | 案例篇:为什么系统的Swap变高了(上)
20 | 案例篇:为什么系统的Swap变高了?(下)
21 | 套路篇:如何“快准狠”找到系统内存的问题?
22 | 答疑(三):文件系统与磁盘的区别是什么?
I/O 性能篇 (10讲)
23 | 基础篇:Linux 文件系统是怎么工作的?
24 | 基础篇:Linux 磁盘I/O是怎么工作的(上)
25 | 基础篇:Linux 磁盘I/O是怎么工作的(下)
26 | 案例篇:如何找出狂打日志的“内鬼”?
27 | 案例篇:为什么我的磁盘I/O延迟很高?
28 | 案例篇:一个SQL查询要15秒,这是怎么回事?
29 | 案例篇:Redis响应严重延迟,如何解决?
30 | 套路篇:如何迅速分析出系统I/O的瓶颈在哪里?
31 | 套路篇:磁盘 I/O 性能优化的几个思路
32 | 答疑(四):阻塞、非阻塞 I/O 与同步、异步 I/O 的区别和联系
网络性能篇 (13讲)
33 | 关于 Linux 网络,你必须知道这些(上)
34 | 关于 Linux 网络,你必须知道这些(下)
35 | 基础篇:C10K 和 C1000K 回顾
36 | 套路篇:怎么评估系统的网络性能?
37 | 案例篇:DNS 解析时快时慢,我该怎么办?
38 | 案例篇:怎么使用 tcpdump 和 Wireshark 分析网络流量?
39 | 案例篇:怎么缓解 DDoS 攻击带来的性能下降问题?
40 | 案例篇:网络请求延迟变大了,我该怎么办?
41 | 案例篇:如何优化 NAT 性能?(上)
42 | 案例篇:如何优化 NAT 性能?(下)
43 | 套路篇:网络性能优化的几个思路(上)
44 | 套路篇:网络性能优化的几个思路(下)
45 | 答疑(五):网络收发过程中,缓冲区位置在哪里?
综合实战篇 (13讲)
46 | 案例篇:为什么应用容器化后,启动慢了很多?
47 | 案例篇:服务器总是时不时丢包,我该怎么办?(上)
48 | 案例篇:服务器总是时不时丢包,我该怎么办?(下)
49 | 案例篇:内核线程 CPU 利用率太高,我该怎么办?
50 | 案例篇:动态追踪怎么用?(上)
51 | 案例篇:动态追踪怎么用?(下)
52 | 案例篇:服务吞吐量下降很厉害,怎么分析?
53 | 套路篇:系统监控的综合思路
54 | 套路篇:应用监控的一般思路
55 | 套路篇:分析性能问题的一般步骤
56 | 套路篇:优化性能问题的一般方法
57 | 套路篇:Linux 性能工具速查
58 | 答疑(六):容器冷启动如何性能分析?
加餐篇 (4讲)
加餐(一) | 书单推荐:性能优化和Linux 系统原理
加餐(二) | 书单推荐:网络原理和 Linux 内核实现
用户故事 | “半路出家 ”,也要顺利拿下性能优化!
用户故事 | 运维和开发工程师们怎么说?
结束语 (1讲)
结束语 | 愿你攻克性能难关
Linux性能优化实战
登录|注册

39 | 案例篇:怎么缓解 DDoS 攻击带来的性能下降问题?

倪朋飞 2019-02-20
你好,我是倪朋飞。
上一节,我带你学习了 tcpdump 和 Wireshark 的使用方法,并通过几个案例,带你用这两个工具实际分析了网络的收发过程。碰到网络性能问题,不要忘记可以用 tcpdump 和 Wireshark 这两个大杀器,抓取实际传输的网络包,排查潜在的性能问题。
今天,我们一起来看另外一个问题,怎么缓解 DDoS(Distributed Denial of Service)带来的性能下降问题。

DDoS 简介

DDoS 的前身是 DoS(Denail of Service),即拒绝服务攻击,指利用大量的合理请求,来占用过多的目标资源,从而使目标服务无法响应正常请求。
DDoS(Distributed Denial of Service) 则是在 DoS 的基础上,采用了分布式架构,利用多台主机同时攻击目标主机。这样,即使目标服务部署了网络防御设备,面对大量网络请求时,还是无力应对。
比如,目前已知的最大流量攻击,正是去年 Github 遭受的 DDoS 攻击,其峰值流量已经达到了 1.35Tbps,PPS 更是超过了 1.2 亿(126.9 million)。
从攻击的原理上来看,DDoS 可以分为下面几种类型。
第一种,耗尽带宽。无论是服务器还是路由器、交换机等网络设备,带宽都有固定的上限。带宽耗尽后,就会发生网络拥堵,从而无法传输其他正常的网络报文。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《Linux性能优化实战》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(28)

  • 怀特
    这个专栏太超值,我跟追剧一样的追到现在,收获已经巨大!
    谢谢倪工的分享。
    更谢谢倪工对留言一丝不苟的回复---这份对听众的耐心,其他专栏的作者没有一个能比得上的。
    继续追剧!

    作者回复: 哈哈,谢谢热心回复和支持

    2019-02-21
    12
  • ichiro
    最近服务会出现干核现象,一个单进程程序发现把一个cpu耗尽,用top发现一个cpu的,软中断很高,通过watch -d cat /proc/softireq,发现网络中断很高,然后配置多网卡队列,把中断分散到是他cpu,缓解了进程cpu的压力,但同时带来担忧,配置多网卡队列绑定,会不会带来cpu切换,缓存失效等负面影响?另外,老师还有别的建议吗?

    作者回复: 会的,实际上优化网络都会占用更多的cpu和内存。所以还要看优化是不是值得,是不是最需要优化的瓶颈

    2019-02-27
    5
  • 李燕平²⁰¹⁸
    服务器插上网线就像开车上路。

    DDoS攻击可以理解为撞车,提升汽车本身的安全系数会有用。
    大量DDoS攻击可以理解为撞上大货车,需要护卫车队来保护主车。

    作者回复: 赞👍

    2019-02-20
    5
  • Christmas
    Sysc backlog并不是在配置了sync cookie之后就失效了吧,netstat -s 看到的listen状态的recv 和send不是分别表示连接队列配置和当前活跃队列长度吗,比如监听某个端口的进程不响应了,那么这里的recv队列就会慢慢变长然后溢出。溢出之后,linux可以选择drop掉什么也不做,或者返回connection reset通知客户端

    作者回复: 请参考 syn cookie 和 netstat 的文档,这些配置和字段的含义都有明确的说明

    2019-03-01
    2
  • 明翼
    检测DDOS攻击,我没有什么这方面经验想了下:
    1、既然攻击,肯定不是正常业务,所以在sar -n DEV 4 命令看运行包的时候,不光要注意收到的包的大小,还要注意平时在监控业务的时候观察正常的业务的收包量,做一个横向比较,确定异常流量;还有一点特别重要,我觉得tcp连接交互基本都是双向的,那么回包数量和发包的数量不能相差太大,如果太大了可能有问题。

    2、至于查看源IP,除了tcpdump外,是不是可以通过netstat 结合wc 统计下各类状态的连接数,如果连接数超过平时的连接数就要注意,关注状态一致的连接数,这里面也有ip信息,当然也可以判断来源。

    作者回复: 嗯,sar和netstat都是最常用的工具

    2019-02-20
    2
  • 且听风吟
    net.ipv4.tcp_max_tw_buckets
    net.ipv4.tcp_tw_reuse
    net.ipv4.tcp_tw_recycle
    net.ipv4.tcp_keepalive_time
    net.ipv4.tcp_timestamps
    期待结合生产环境对这几个内核参数的讲解。目前生产环境下php服务器time_wait特别多,网络包的流程: NGINX代理<——>PHP服务器——>redis/mysql..
    高峰时期php服务器一共50k+的连接。49k+的time_wait., 主要来源是php作为客户端的角色时连接redis、mysql、给代理NGINX回包、php服务器内部调用。希望老师能给解决问题的思路。

    作者回复: 嗯,后面有的

    2019-02-20
    2
  • dancer
    重新开追,前两天着重看了cpu调优,正好线上压测发现了cpu.user飙高的问题,通过perf和pprof查明了是一个复杂json结构解析导致的,学以致用下来印象更深了!这两天开始看网络,后面再看io和内存相关,感谢!

    作者回复: 赞,很高兴也看到学以致用

    2019-03-06
    1
  • Geek_ea21df
    老师,咨询个问题,当半连接队列被占满后,客户端继续发syn,这时服务器端还会返回syn+ack吗?由于没有收到客户端返回的ack,半连接队列里面的连接会被踢出吗?
    2019-10-17
  • 辉晖
    --rand-source
    用tcpdump抓包看到的还是同样的IP呀,没有出现随机
    2019-10-15
  • 乖,摸摸头

    抓包被攻击主机
    17:15:09.834282 IP 172.17.0.17.http > 39.105.27.73.25213: Flags [S.], seq 3104982810, ack 1682132320, win 64240, options [mss 1460], length 0
    17:15:09.834577 IP 39.105.27.73.25180 > 172.17.0.17.http: Flags [R], seq 1552097248, win 0, length 0
    17:15:09.835241 IP 39.105.27.73.25219 > 172.17.0.17.http: Flags [S], seq 1495946800, win 512, length 0
    17:15:09.835258 IP 172.17.0.17.http > 39.105.27.73.25219: Flags [S.], seq 4115155724, ack 1495946801, win 64240, options [mss 1460], length 0
    17:15:09.835319 IP 39.105.27.73.25215 > 172.17.0.17.http: Flags [S], seq 472764723, win 512, length 0
    17:15:09.835333 IP 172.17.0.17.http > 39.105.27.73.25215: Flags [S.], seq 3536954741, ack 472764724, win 64240, options [mss 1460], length 0
    17:15:09.837205 IP 39.105.27.73.25190 > 172.17.0.17.http: Flags [R], seq 1357800982, win 0, length 0

    抓包发起攻击的主机 好多发起得是[R]
    抓包发起攻击的主机

    17:17:36.904992 IP 172.17.115.106.5941 > 49.234.232.49.http: Flags [S], seq 399367614, win 512, length 0
    17:17:36.906033 IP 172.17.115.106.5942 > 49.234.232.49.http: Flags [S], seq 591134454, win 512, length 0
    17:17:36.907112 IP 172.17.115.106.5943 > 49.234.232.49.http: Flags [S], seq 1780793513, win 512, length 0
    17:17:36.908170 IP 172.17.115.106.5944 > 49.234.232.49.http: Flags [S], seq 1999407364, win 512, length 0
    17:17:36.908471 IP 49.234.232.49.http > 172.17.115.106.5914: Flags [S.], seq 3104468759, ack 1898840089, win 64240, options [mss 1424], length 0
    17:17:36.908485 IP 172.17.115.106.5914 > 49.234.232.49.http: Flags [R], seq 1898840089, win 0, length 0

    我这个好多都是发起的[R]攻击
    2019-10-01
  • 峰回
    您好,请问系统closed飙高,占用大量句柄的原因是什么呢,有解决方案么?
    2019-06-10
  • zshanjun
    我这里dos攻击没有什么效果,我查看了一下被攻击主机的tcp连接状态发现根本就没有多少SYN_REC的状态。
    然后通过抓包发现,是攻击主机主动发了【R】,导致被攻击主机的tcp的SYN_REC没有堆积起来:
    06:38:15.452913 IP 192.168.38.4.15651 > 192.168.38.5.80: Flags [S], seq 1206198085, win 512, length 0
    06:38:15.452930 IP 192.168.38.5.80 > 192.168.38.4.15651: Flags [S.], seq 1729577211, ack 1206198086, win 29200, options [mss 1460], length 0
    06:38:15.453009 IP 192.168.38.4.15652 > 192.168.38.5.80: Flags [S], seq 1185838297, win 512, length 0
    06:38:15.453033 IP 192.168.38.5.80 > 192.168.38.4.15652: Flags [S.], seq 1389286866, ack 1185838298, win 29200, options [mss 1460], length 0
    06:38:15.453132 IP 192.168.38.4.15651 > 192.168.38.5.80: Flags [R], seq 1206198086, win 0, length 0
    06:38:15.453141 IP 192.168.38.4.15652 > 192.168.38.5.80: Flags [R], seq 1185838298, win 0, length 0
    06:38:15.453384 IP 192.168.38.4.15653 > 192.168.38.5.80: Flags [S], seq 1851454908, win 512, length 0
    06:38:15.453406 IP 192.168.38.5.80 > 192.168.38.4.15653: Flags [S.], seq 128486955, ack 1851454909, win 29200, options [mss 1460], length 0
    06:38:15.453479 IP 192.168.38.4.15653 > 192.168.38.5.80: Flags [R], seq 1851454909, win 0, length 0
    06:38:15.453719 IP 192.168.38.4.15654 > 192.168.38.5.80: Flags [S], seq 700664781, win 512, length 0
    06:38:15.453743 IP 192.168.38.5.80 > 192.168.38.4.15654: Flags [S.], seq 3877145682, ack 700664782, win 29200, options [mss 1460], length 0
    06:38:15.454017 IP 192.168.38.4.15654 > 192.168.38.5.80: Flags [R], seq 700664782, win 0, length 0
    06:38:15.454961 IP 192.168.38.4.15655 > 192.168.38.5.80: Flags [S], seq 1751493720, win 512, length 0
    06:38:15.454993 IP 192.168.38.5.80 > 192.168.38.4.15655: Flags [S.], seq 1257904630, ack 1751493721, win 29200, options [mss 1460], length 0

    请问这种情况是hping3工具的问题吗?

    作者回复: 看起来像是被攻击主机配置了防DoS策略

    2019-04-12
  • 大坏狐狸
    1 增大队列SYN最大半连接数sysctl -w et.ipv4.tcp_max_syn_backlog=3000
    2 减少超时值:通过减少超时重传次数,sysctl -w net.ipv4.tcp_synack_retries=1
    3 SYN_COOKIE : 开启cookie echo "1" > / proc/sys/net/ipv4/tcp_syncookies (原本对cookie有误解,看了本文才清楚,谢谢老师)
    4 过滤可疑IP地址: iptables -I INPUT -s 192.168.0.2 -p tcp -j REJECT 禁止 0.2访问
    2019-04-11
  • z.l
    请问老师今天讲的三个tcp内核参数调优能否作为通用的提高服务器抗并发能力的优化手段?

    作者回复: 嗯 是的

    2019-04-09
  • 如果
    DAY39,打卡
    2019-04-03
  • Maxwell
    压测过程中,使用多线程向服务器施压,也算是DDOS攻击吧?

    作者回复: 看请求量了,很多情况下也算的

    2019-03-24
  • 青石
    REJECT攻击IP所有报文,接口响应没什么变化,还是127秒,DROP报文后响应时间才恢复正常,查了REJECT和DROP的区别,REJECT会返回个ICMP包给源IP,有点不太理解为什么一个ICMP包导致这么大的差异。

    # hping3命令, u10效果不明显,所以改成了u1测试
    $ hping3 -S -p 80 172.30.81.136 -I eno1 -i u1

    # 调整内核参数测试结果,接口响应时间为127秒
    $ curl -s -w 'Http code: %{http_code}\nTotal time:%{time_total}s\n' -o /dev/null http://172.30.81.136/
    Http code: 000
    Total time:127.109s

    # 调整内核参数、iptables限制syn并发的测试结果,接口响应时间为127秒
    $ curl -s -w 'Http code: %{http_code}\nTotal time:%{time_total}s\n' -o /dev/null http://172.30.81.136/
    Http code: 000
    Total time:127.106s

    # 调整内核参数、iptables限制syn并发、单IP连接数的测试结果,接口响应时间为127秒
    $ curl -s -w 'Http code: %{http_code}\nTotal time:%{time_total}s\n' -o /dev/null http://172.30.81.136/
    Http code: 000
    Total time:127.097s

    # 调整内核参数、iptables限制syn并发、单IP连接数、DROP攻击IP所有报文的测试结果,接口响应时间为127秒
    $ curl -s -w 'Http code: %{http_code}\nTotal time:%{time_total}s\n' -o /dev/null http://172.30.81.136/
    Http code: 200
    Total time:0.001s

    作者回复: REJECT还会给攻击源发送响应,这也是消耗网络资源的;而DROP没有任何回应,直接丢弃

    2019-03-17
  • we
    老师,如果把tcp 改为sctp 协议,是不是就不会再发生DDos 攻击了?

    作者回复: 只对SYN Flood有效,但很多针对应用层的DoS应该还是无效的

    2019-03-13
  • Brown羊羊
    net.ipv4.tcp_max_syn_backlog = 256 改成1024 这个对DDoS攻击无效吧,也不差这几百个连接

    作者回复: 嗯嗯,对流量型无效;但是可以缓解针对业务的攻击(这种一般请求小但响应大或者处理耗时)

    2019-03-10
  • wj
    我也按上面的情况去模拟了,但是没有达到能够把服务器刷死的那种效果,请求时间没什么变化

    作者回复: 我设置的请求数比较保守(虚机性能不是特别好),加大请求试试

    2019-03-06
收起评论
28
返回
顶部