微信号:gh_34977e8f8c68

介绍:私有云数据库平台的分享!

抓包,只为让DBA过的更开心

2016-07-02 22:32 yangting


小伙伴说每每看到开发同事在排查问题时,在邮件往来各种tcp包分析,觉得超级牛逼,我个人觉得不仅仅是牛逼,其实还是很装逼的哦,本文介绍几个现实发生的案例,供大家娱乐!

1

温习一下tcp流程

盗用网上的图


首先:了解到正常的tcp数据传输永远逃脱不了图中的3个流程,

1
创建链接的3次握手过程
2
数据传输(每次传输都需要ack)
3
 断开链接的四次挥手过程


在我们的数据库访问中,如果哪个tcp过程违反了以上过程,业务基本就会出现报错等不正常状态;

其次,通过上图,我们能了解到tcp的状态,每一个tcp操作后,都会处于一个tcp状态,例如:我们在业务前端机器经常通过netstat –an|grep tcp看到的大量的TIME_WAIT状态,就是处于四次挥手接触发送ack后的最后一个终结状态;

这里盗用一张更全的图来说明tcp状态机(最早出现在tcp/ip详解中 卷一:182页),值得参考


2抓包与分析包的工作

1

作为一个Linux使用者,我觉得初级tcpdump使用应该是有必要熟悉的,我使用的tcpdump命令非常简单:例如经常用的tcpdump –i eth0 port 6671 and host ip –nn –w 6671.pcap(参数就不过多解释)

2

 Wireshark:用它来解析tcpdump,简直爽的没有话说,非常的方便。如果不会用,建议查看Wireshark数据包分析实战这本书(http://item.jd.com/11195407.html)

3分析下实际的3个例子


1、  某白银同学发出有问题的邮件(由于篇幅有限,只截图很少一部分,案例为Redis问题排查),说redis server有问题,请快速解决,并贴出如下抓包的截图,如下:



我们分析一下上面的tcp过程(源:10.*.*.186[client] 目:10.*.*.23[server]

1
 前面3个tcp包属于tcp握手过程,时间非常短,一切看起来是完美;
2
 第4个 tcp包传数据,第5个包,server回复ack,看起来也很正常;
3

  第6—9 个tcp包:4次挥手;


乍一看,好像并没有问题,符合上面tcp流程,但是仔细思考一下,觉得这里有一个有问题的,因为在(2)过程中,我们只有client发送了请求,但是server只回复了ack,并没有传输任何数据,就直接进入了4次挥手过程,正常的redis访问肯定不是这样的,redis一个最简单的连接过程是:连接—auth—认证OK—退出,在我们的案例中,好像redis server并没有回复认证的OK的数据包,client就直接断开了连接了,那这里肯定是有问题的。通过第一列的时间,我们发现,每次client断开连接,都距离上次ack 3s中,经过与业务沟通,业务代码里确实有这样的配置,如果server 不返回数据,就会主动断开连接,最后,我们把问题就直接定位到redis server为什么3s都不认证通过呢?他到底在干嘛?这里我们联想到redis server是单线程处理流程,当redis server上有比较慢的command执行的时候,就会阻塞其他连接,到这就很好定位了,直接查看slow log定位是哪个command 执行3s以上,这里我们就是很温柔的说明问题所在,请业务速速解决这些command 慢的问题,此问题至此解决;


2、  某业务给我们打电话说他的业务偶尔会报错,请帮排查数据库是不是有问题(案例为mysql)


我们就利用dba正常的排查方式,初步排查了一下,觉得我们是没有问题的,但是这样并不能让业务信服,我们在mysql服务器尝试抓包分析,竟然意外发现如下异常的包,截图如下


找到如上的包,我们看到tcp 3次握手并不友好,在server端回复(SYN|ACK)包进入等待ack过程中,client竟然3s后重传了SYN包,也就是说,client  3s之后认为上次的SYN丢了,而在我们对其他client抓包发现,并没有这个问题,那我们基本可以说,这肯定不是数据库问题,请自查这台前端client机器;


3、  某业务在聊天中抱怨说,他们的业务偶尔慢,不知道哪有问题,能否帮看看数据库端是否有问题


我们也是正规排查,后来找不到任何异常,然后抓包试试看看,最后分析如下图的结果,【SYN】包与【SYN ACK】之间竟然间隔了0.5s,这是一个非常非常不正常从状态,后果断让业务自查;



以上是我们抓包过程中比较经典的3个案例,后面2个案例,我并没有去询问业务最后怎么解决的,只要证明不是我数据库问题,让我们安安心心快乐生活就足够了。


从上面的分析包过程中,其实可以断言:任何不符合tcp规则的情况(包的状态、传输包的时间、包的传输流程)都会影响业务!


这里,叮嘱天下所有的DBA 同学,一定要记住,数据库尤其是mysql、redis 这2个,本身是比较稳定的,为了保护自己,请学习抓包、分析包的这些技能;尽管分析包是一个体力活。

最后推荐wireshark的一个牛逼功能,如下图:在对错误包进行分析,非常有用;


 
dba流浪猫 更多文章 greenplum使用场景 为什么redis内存不宜过大 Atlas支持mysql的prepare特性吗 MySQL for update 死锁案例 pt-osc改表导致数据不一致案例分析
猜您喜欢 2015上海互联网创业峰会 心灵鸡汤:坚持好习惯,你需要的不是意志力,而是正确的方法 数据库集群技术漫谈 R语言词云终极解决方案—wordcloud2包 java终成弃子 6年坚持打水漂~