wireshark 抓包实践记录

本文记录了一次业务服务访问Redis出现偶发超时的问题排查过程,通过抓包分析定位到网络延迟导致的超时,并调整超时时间解决了问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

背景

一个业务服务访问Redis机器总是偶发超时,业务访问量并不大,需要排查一下是在链路的哪个部分耗时过长或者丢包了

过程

在业务服务器和Redis服务器分别进行抓包,指定抓的是往Redis服务进程端口的包
对抓包结果执行过滤:tcp.flags.reset==1 (reset表示连接异常终止)
过滤完之后确实发现有部分连接异常终止了,过滤获得其中的某个端口:tcp.port=36376
发现该端口在一次发包之后等待200ms都没有收到Redis服务器的回包,导致超时应用层关闭连接,发送了FIN包给Redis服务器
Redis服务器收到超时包的时间间隔确实大于了200ms,也就是说从发出包到Redis服务器接收到包中间就花了200ms。

解决方案

将超时时间调整为500ms,解决了这个问题。后面需要排查一下,是网络问题还是Redis服务器网卡问题,导致包到达TCP协议栈晚了200ms。

相关知识

我们知道,TCP是有超时重传机制的。只不过Linux设置的超时时间一般都是大于1S的。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值