TCP传输异常

1. 系统说明

一个局域网中有一个ARM（firefly-rk3399）和一个PC，ARM是ubuntu系统，PC是windows系统，ARM和PC通过交换机相连。

PC上运行一个服务端程序，ARM上运行一个客户端程序。ARM通过TCP连接PC并发送数据。ARM发送的数据是周期性的，每隔8秒左右会发送一堆2~3M的数据。

1. 问题描述

PC端收不到ARM发送的数据了，但ARM应用层显示自己还在正常发送数据。

PC会持续15分钟接收不到数据，而在此期间，ARM没有显示任何异常。15分钟后，ARM端提示TCP状态改变，ARM放弃了该TCP连接，重新建立一个新的TCP连接，PC能接收到该新连接的数据。

PC接收不到数据时，ARM和PC的网络都是正常的，ARM和PC能互相ping通。

更换不同的PC，ARM，交换机，问题都会存在。

对于同一套系统，该问题出现的频率基本均匀，有时平均1小时出现一次，有时半小时一次，有时半天才一次。

把PC端的程序换成网口助手，仍然有这样的问题。

1. 网口抓包

在ARM端和PC端进行抓包，ARM端使用tcpdump，PC使用wareshark，多次抓包查看数据，情况都是一致的的。抓包情况如下，图中ip为41的是ARM，ip为2的是PC：

异常刚出现时：

ARM会收到PC发来的一个DUP ACK，然后ARM立刻应答了一个Fast Retransmission，该快速重传帧在上图中被wireshark识别为 out-of-order。（我逐字节对比过out-of-order帧和Fast Retransmission帧，二者完全一样。）

然后PC就一直发DUP ACK，ARM也会应答 Fast Retransmission，如下图：

持续一段时间后，ARM不再发送Fast Retransmission，转而发送 TCP Retransmission，但PC没有任何响应，如下图：

最后，ARM放弃该连接，重新建立了一个TCP连接，即上图中的SYN。

 

但并不是每次DUP ACK都会造成这种异常，如下图：

出现DUP ACK后，通讯能恢复正常。

 

PC端的抓包结果和ARM端的抓包结果一致，即ARM发送出的数据包，PC都能收到。

将ARM端程序改为以下简单的发送程序，server端使用网口助手，仍然有相同的问题：

抓包结果如下，ARM的ip为15，PC的ip为65:

最后的FIN是PC端关闭程序了。

 

疑惑:

为何PC不能正确处理Fast Retransmission？

为何最后的TCP Retransmission都没有响应？

如果说是网络的问题，那为何PC端的wireshark能抓取到所有数据包？

同样的程序,在ubuntu PC上运行就没有问题.