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

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

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

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

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

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

    作者回复: 赞👍

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

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

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

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

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

    
     2
  • 且听风吟
    2019-02-20
    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服务器内部调用。希望老师能给解决问题的思路。
    展开

    作者回复: 嗯，后面有的

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

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

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

    抓包被攻击主机
    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-06-10
    您好，请问系统closed飙高，占用大量句柄的原因是什么呢，有解决方案么？
    
    
  • zshanjun
    2019-04-12
    我这里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-11
    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访问
    
    
  • z.l
    2019-04-09
    请问老师今天讲的三个tcp内核参数调优能否作为通用的提高服务器抗并发能力的优化手段？

    作者回复: 嗯 是的

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

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

    
    
  • 青石
    2019-03-17
    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没有任何回应，直接丢弃

    
    
  • we
    2019-03-13
    老师，如果把tcp 改为sctp 协议，是不是就不会再发生DDos 攻击了？

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

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

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

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

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

    
    
我们在线，来聊聊吧