今天偶然遇到一个问题，用户端无法登陆，一直登陆失败，使用ping检测网络是正常的，后面通过抓包分析，最终确认了故障原因。
PS： 网络大致可简化为 clinet(192.168.13.201)----clinet 端NAT设备(10.139.25.74)----server(10.136.6.20)
首先看client端报文，直接瞄到异常报文
发现客户端收到一个异常报文，之后发了一个重复确认给服务端，之后客户端直接发RST报文，强制断开连接。怀疑之间有丢包。
仔细查看其传输过程，大致如下：
观察SEQ和ACK匹配关系，发现从第30个包到第31个包出现暴增，SEQ和ACK匹配不上，从而得出结论应是30和31之间有过丢包，并且是服务器发过来的包丢了（此时wireshak将第31个包标记提醒包不完整）。
分析过程如下：
第28个包（clinet ->server）：seq=3909，ack=1859，len=450。那么收到下一个包的seq=1859，ack=3909+450=4350。
第29个包（server->clinet）：seq=1859，ack=4359，len=196。那么收到下一个包的seq=4359，ack=1859+196=2055。
第30个包（clinet->server）：seq=4359，ack=2055，len=0。那么收到下一个包的seq=2055，ack=4359+0=4359。
第31个包（server->clinet）：seq=9255，ack=4359，len=1118。
ACK能够对上，但SEQ却比预计的大了许多，因此初步判定，第30个包到第31个包之间有大量的数据从服务器发过来，而客户端却没有收到，因是网络丢包。（再此留一个疑问，不计算服务器重传，服务器到底共发了多少数据过来？）
为了证实上面结论，取服务器抓包报文分析。
不难发现，服务器发送了之前猜想的包（第30个包：seq=2055,ack=4359），并且随后还继续发送了第32个包，第40个包，而第33个到第39个属于服务器对第30个包的重传，因为没有收到第30个包的确认。在这中间发现客户端能够收到服务器发送的第41个包，对比了下包的长度，发现只要大于1118的客户端都收不到，怀疑是MTU的问题，之后测试发现的确是MTU问题，最后通过修正MTU解决问题。
报文地址：
链接：https://pan.baidu.com/s/1nwi9oa1 密码：0hw1
网友评论