首页 » 技术文章 » 网络问题分析之抓包与netstat.md

网络问题分析之抓包与netstat.md

 

一、抓包能解决什么问题

1.1、客户端与服务器网络连接异常的问题

客户端调用connect连接服务器,在程序中进入异常流程,即连接失败。此时可以通过抓包工具来分析是客户端还是服务器的问题。连接建立阶段的抓包交互为:

11:30:27.998097 IP GZ-6CU4172K6K.44775 > 10.20.102.232.http: Flags [S], seq 44374208, win 14600, options [mss 1460,sackOK,TS val 2511054656 ecr 0,nop,wscale 7], length 0
11:30:27.998351 IP 10.20.102.232.http > GZ-6CU4172K6K.44775: Flags [S.], seq 2839180825, ack 44374209, win 28960, options [mss 1460,sackOK,TS val 2490824937 ecr 2511054656,nop,wscale 7], length 0
11:30:27.998400 IP GZ-6CU4172K6K.44775 > 10.20.102.232.http: Flags [.], ack 1, win 115, options [nop,nop,TS val 2511054656 ecr 2490824937], length 0

三次握手的包,在tcpdump中表现是[S] (wireshark中位SYN),如果出现上述三个报文,表明客户端与服务器正常建立了连接。如果未抓到包,表明客户端根本未发起连接;如果服务器未回复[S.]报文,表明服务器未响应连接,此时可能就是服务器存在BUG或者性能瓶颈了。

1.2、客户端与服务器网络连接异常断开的问题

客户端在运行过程中,开始一段时间表现良好,但一段时间后,连接就异常断开了,通过日志排查只能得到部分错误码,但无法完全确定究竟是网络问题还是其它问题,此时我们通过持续抓包也可以确认到问题。正常的网络连接与断开包序如下:

11:30:27.998097 IP GZ-6CU4172K6K.44775 > 10.20.102.232.http: Flags [S], seq 44374208, win 14600, options [mss 1460,sackOK,TS val 2511054656 ecr 0,nop,wscale 7], length 0
11:30:27.998351 IP 10.20.102.232.http > GZ-6CU4172K6K.44775: Flags [S.], seq 2839180825, ack 44374209, win 28960, options [mss 1460,sackOK,TS val 2490824937 ecr 2511054656,nop,wscale 7], length 0
11:30:27.998400 IP GZ-6CU4172K6K.44775 > 10.20.102.232.http: Flags [.], ack 1, win 115, options [nop,nop,TS val 2511054656 ecr 2490824937], length 0
11:31:28.060018 IP 10.20.102.232.http > GZ-6CU4172K6K.44775: Flags [F.], seq 1, ack 1, win 227, options [nop,nop,TS val 2490884998 ecr 2511054656], length 0
11:31:28.060160 IP GZ-6CU4172K6K.44775 > 10.20.102.232.http: Flags [F.], seq 1, ack 2, win 115, options [nop,nop,TS val 2511114718 ecr 2490884998], length 0
11:31:28.060358 IP 10.20.102.232.http > GZ-6CU4172K6K.44775: Flags [.], ack 2, win 227, options [nop,nop,TS val 2490884998 ecr 2511114718], length 0

[F]报文是关闭连接时的报文,wireshark中对应的为[FIN],某个端先发起[F]报文,则是该端主动发起连接关闭操作。如果对于异常断开连接,抓取到的报文为客户端发起的,那可能客户端某个逻辑存在关闭连接的可能,否则,就是服务器主动关闭连接,则可以进一步分析服务器问题。一般来说服务器关闭连接有几种可能:长时间无数据空闲连接回收机制、收到无法处理的数据包认为其连接非法进行关闭、服务器关闭等等情形。

除了正常关闭[F]报文,还存在一种情形来重置TCP连接,那就是[R]报文,在wireshark中使用[RST]报文标识。某些服务器主动关闭连接时,为了避免tcp进入TIME_WAIT状态,会设置linger选项,让连接关闭时也取消发送缓冲区的数据,此时就会发送一个[R]报文直接中断连接,客户端在recv时就会返回-1(正常关闭recv返回0),同时存在一个10053的错误码(windows)。这种情形出现时并非是服务器存在问题,还是服务器有意为之(确实存在部分服务器使用这种逻辑)。

[R]报文出现时,可以深究其原因,下面列出几种可能出现[R]报文的原因:

  • 目标端口未打开;
  • 关闭socket时,socket系统层接收缓冲区中存在部分数据未收取;
  • 部分系统(如windows 2003)在重传多次失败后会发送[R]报文;
  • 服务器设置socket的linger选项;

1.3、通过抓包观察服务器客户端状态

抓包除了分析单个TCP连接的转换之外,还可以分析服务器或客户端的运行时状态。抓包可以观察win(窗口大小),如果服务器回复的报文中win存在下降趋势,并在某一时刻收到服务器的zero window标识的报文,说明服务器存在性能瓶颈,无法及时响应客户端的请求,抑或者整个系统的设计存在缺陷,客户端不应以较快速度向服务器发包。

通过观察网络包重传,也可以分析到客户端与服务器的网络通畅程度。

二、抓包与连接状态查看相结合

2.1、在服务器中通过netstat -na 查看连接状态

在服务器中通过netstat -na查看连接状态,可以看到连接正常、连接断开、TIME_WAIT等等可能状态的TCP连接,若一个系统出现了大量TIME_WAIT状态的连接,说明该服务器经常主动发起连接关闭操作,这也是不可取的。如一个系统频繁出现CLOSE_WAIT状态的连接,说明该系统并未立即处理连接关闭请求,系统也存在缺陷。

同时通过观察netstat -na的send-q和recv-q队列的大小,可以分析系统服务能力,若send-q过大,说明系统发包速度过快以至于连接无法及时将数据发出。若recv-q过大,说明系统未能及时处理外部发来的请求。

通过netstat还可以检测服务器是否能正常处理客户端连接。服务器在调用listen时,会传递backlog参数,该参数未已建立连接但未被程序accept的连接数,内核层会根据/proc/sys/net/core/somaxconn值与传入的backlog值,选择两者中的小值作为已建立连接但未被服务器accept的连接队列长度。netstat -na |grep PORT | grep LISTEN可以查看到监听句柄的recv-q队列大小,如果该值较大升值>=backlog值,说明服务器无法适应当前连接建立速度,不能及时的accept新连接,此时即使服务器内部统计无压力,各种请求处理指标都正常也会影响外部服务,因为新的连接可能会失败(不失败也会等待较长时间才被服务器处理,而此时可能客户端已经超时重连了...一旦发生这种情形就会恶性循环-连接一直建立,但每个连接都失败)。

三、小结

通过抓包工具及网络状态查看命令netstat可以帮助定位客户端、服务端相关网络问题,在日志匮乏或性能统计信息不足以分析服务器问题时,可以辅助分析服务器相关模块性能。

本文作者:马良

原文链接:网络问题分析之抓包与netstat.md,转载请注明来源!

0