Linux 性能优化实战
倪朋飞
资深 Linux 专家,Kubernetes 项目维护者
87257 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 65 讲
结束语 (1讲)
Linux 性能优化实战
15
15
1.0x
00:00/00:00
登录|注册

40 | 案例篇:网络请求延迟变大了,我该怎么办?

分享和讨论
网络延迟分析方法总结
优化后测试
tcp_nodelay 设置
Nagle 算法
Wireshark 分析
tcpdump 抓包
wrk 并发测试
hping3 测试延迟
Nginx 容器启动
工具安装
机器配置
strace 观察
Wireshark 分析
tcpdump 抓包
traceroute 测试
wrk 测试
hping3 测试
往返延迟
含义
traceroute 测试
ping 测试
单向延迟 vs. 往返延迟
含义
思考
小结
案例分析
案例准备
网络延迟分析方法
应用程序延迟
网络延迟
网络延迟问题分析

该思维导图由 AI 生成,仅供参考

你好,我是倪朋飞。
上一节,我们学习了碰到分布式拒绝服务(DDoS)的缓解方法。简单回顾一下,DDoS 利用大量的伪造请求,导致目标服务要耗费大量资源,来处理这些无效请求,进而无法正常响应正常用户的请求。
由于 DDoS 的分布式、大流量、难追踪等特点,目前确实还没有方法,能够完全防御 DDoS 带来的问题,我们只能设法缓解 DDoS 带来的影响。
比如,你可以购买专业的流量清洗设备和网络防火墙,在网络入口处阻断恶意流量,只保留正常流量进入数据中心的服务器。
在 Linux 服务器中,你可以通过内核调优、DPDK、XDP 等多种方法,增大服务器的抗攻击能力,降低 DDoS 对正常服务的影响。而在应用程序中,你可以利用各级缓存、 WAF、CDN 等方式,缓解 DDoS 对应用程序的影响。
不过要注意,如果 DDoS 的流量,已经到了 Linux 服务器中,那么,即使应用层做了各种优化,网络服务的延迟一般还是会比正常情况大很多。
所以,在实际应用中,我们通常要让 Linux 服务器,配合专业的流量清洗以及网络防火墙设备,一起来缓解这一问题。
除了 DDoS 会带来网络延迟增大外,我想,你肯定见到过不少其他原因导致的网络延迟,比如
网络传输慢,导致延迟;
Linux 内核协议栈报文处理慢,导致延迟;
应用程序数据处理慢,导致延迟等等。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入探讨了网络请求延迟的原因和解决方法,重点介绍了分布式拒绝服务(DDoS)攻击对网络请求延迟的影响以及缓解方法。文章详细介绍了网络延迟的含义和常用指标,并提供了使用工具如ping、traceroute和hping3来测试网络延迟的方法。通过案例分析了网络延迟增大的影响和分析思路,展示了如何定位网络延迟的根源。通过实际案例和工具的使用,帮助读者了解了网络请求延迟的原因和解决方法,对网络运维和性能优化有一定的参考意义。文章还提出了在发现网络延迟增大后的分析方法,包括使用traceroute、hping3、tcpdump、Wireshark、strace等多种工具来定位网络中的潜在问题。总之,本文内容丰富,涵盖了网络延迟的各个方面,为读者提供了全面的了解和分析网络延迟的方法。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《Linux 性能优化实战》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(39)

  • 最新
  • 精选
  • 我来也
    [D40打卡] 我之前理解的网络延迟分三部分:客户端到服务端,服务端逻辑处理,服务端到客户端到耗时。 其中服务端逻辑处理的耗时是跟自身程序有关的,另外两个耗时跟宽带服务提供商有关,想更短的耗时就得加钱:选更优的线路或者在靠近客户端的地方加入口。 目前我们线上程序是可以推算出单次响应的时间的,因为在出入口的地方有记录。不管中间经过了多少服务的处理,都可以算出总的耗时。 我们在客户端中也加了汇报功能,在客户端的某些消息中会汇报 客户端实际发送请求->收到服务端响应 的时间差。这样便于我们确认客户端的网络状况。 从本文中,第一次见到了 Nagle 算法。也知道了服务端关闭icmp时怎么用tcp/udp测试网络延迟。 文中的内容也是跌宕起伏,分析着怎么还是客户端的问题,客户端访问另外一个服务还是好的。原来是服务端程序也有问题,一个巴掌拍不响。😂

    作者回复: 😊谢谢分享你的经验

    2019-02-22
    17
  • 青石
    网上查了Nagle算法的定义:任意时刻,最多只能有一个未被确认的小段。所谓“小段”,指的是小于MSS尺寸的数据块,所谓“未被确认”,是指一个数据块发送出去后,没有收到对方发送的ACK确认该数据已收到。 对比80端口和8080端口的报文,80端口的报文中,响应消息再发送完header后立刻发送body部分;8080端口的报文,响应消息再发送完header后,需要获得ACK响应后,才会发送body部分。 8080端口报文中server端在获得到ACK响应后才发送body部分,就是因为Nagle算法必须确认这个数据块被收到的原因。client在40ms后发送ACK是因为客户端没有开启TCP_QUICKACK的缘故。 请问老师,这样理解,对吗?

    作者回复: 嗯

    2019-03-19
    10
  • 大坏狐狸
    额 第二次居然curl不通了。。18.04 的防火墙是ufw ,需要ufw allow 80/tcp

    作者回复: 👍 谢谢分享

    2019-05-27
    6
  • 你好,我在网络编程中遇到一个问题, 我们用go语言做的服务调用其他HTTP服务器,发现HTTP请求中卡住,概率非常低。 然后我看了发现write,返回eagain,然后就等待epoll通知描述符是否可用,这个时候发现等了很久很久都不可用。netstata看了下,TCP写buffer有数据但是没有满,等了很久也貌似发生不出去,有重传,但是还是传不出去。直接达到rto次数内核中断连接。 我们只能将rto改很小让内核中断连接。 请问这种情况一般都是由什么原因引起的呢?

    作者回复: 这个因素比较多,RTO超时说明已经发生来重传,根源上还是要看为什么会发生重传,比如是否有丢包、是否超出了内核中的资源限制或者对端是否有类似的问题等等。这些最好两端抓包对比分析

    2019-02-28
    6
  • 小虾米
    我记得之前碰到的延迟ack是200ms,这个是可以配置的吗?

    作者回复: 看系统的,据我所知,只有RHEL可以通过/proc/sys/net/ipv4/tcp_delack_min修改(默认40ms),而其他发行版都不支持。

    2019-02-22
    5
  • Linuxer
    案例中能设置客户端的TCP_QUICKACK解决吗?

    作者回复: 嗯,只是客户端有可能在用户那儿,可能无法控制这些选项

    2019-02-22
    3
  • 阳光梦
    您好,请教下。我通过客户端直接访问服务器,平均响应延迟是30ms,经过nginx代理响应延迟是200ms,我使用的ngx+lua,业务逻辑是先查询worker进程的缓存,没有再查redis,再没有查mysql,现在lua层面可以优化的已经优化了,平均响应延迟还是170ms,不知道通过什么工具能定位具体哪里导致响应延迟慢呢?谢谢!

    作者回复: 试试动态追踪(专栏第50、51篇)怎么样?

    2019-06-24
    2
  • Maxwell
    为什么执行strace -f wrk --latency -c 100 -t 2 --timeout 2 http://192.168.126.136:8080/,输出结果中并没有TCP_NODELAY配置选项呢?

    作者回复: 是不是还有其他报错?

    2019-03-24
    2
  • Linuxer
    同一套环境碰到一个低并发高延时,高并发低延时得的问题,请问倪老师像这种问题该如何排查?

    作者回复: 思路是一样的,只是在抓包后要按应用过滤(比如端口号),然后再分别进行分析

    2019-02-22
    2
  • 怀特
    traceroute 会在路由的每一跳发送三个包,并在收到响应后,输出往返延时。如果无响应或者响应超时(默认 5s),就会输出一个星号。 ----这个地方,还有些不明白,希望老师能在这里再解释几句

    作者回复: 就是说星号表示没有收到这一跳的响应

    2019-02-22
    2
    2
收起评论
显示
设置
留言
39
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部