TCP性能测试与问题分析二（进阶）

TCP性能测试与问题分析二（进阶）

对TCPIP协议栈进行性能测试，探索TCP地关键技术理论。

目录

问题6：tcp 抓包出现TCP spurious retransmission

问题7：发送非常顺利，但在某个时刻，戛然而止。

问题8：关于切换发送模式时，会出现误触发，造成多发送一帧

问题9: 关于窗口更新，造成的延迟

 

问题6：tcp 抓包出现TCP spurious retransmission

tcp虚假重传，指实际上并没有超时，但看起来超时了，导致虚假超时重传的原因有很多种：

（1）对于部分移动网络，当网络发生切换时会导致网络延时突增

（2）当网络的可用带宽突然变小时，网络rtt会出现突增的情况，这会导致虚假超时重传

（3）网络丢包（原始和重传的包都有可能丢包）会导致虚假重传超时。

猜测方案：对时间戳进行分析，发现TCP回复ACK后，需要等待约300uS，才能“顺利”进行下一次数据的传输。即要放慢发送传输速度。

通过仿真，找到问题的根本原因所在，如下图中详细分析。因此上面的猜测也是不准确的。

优化后仿真如下，先更新ACK，再回复重传。

测试后，解决上诉问题。真的是，每一步调试都是战战兢兢，所有的细节问题，都要完全面对。

 

问题7：发送非常顺利，但在某个时刻，戛然而止。

如下图，一切接收和发送均正常，抓包中也没出现过任何一个错误。但在347这个ACK帧接收后，就停止了。经再测试，FPGA发送功能已丧失。而接收功能完好，还能继续接收，并能执行fin断开功能。

猜测问题原因：接收状态机是正常的，突然停止，问题肯定出现在发送状态机上。但是这个问题是发送过程中突然出现的，也不是“必定”出现的。所以很难想问题6一样，直接定位问题。这个只有先仔细排查TX状态机，然后多测试，分析情况了。

测试过程：再次连接测试，问题复现如下。所以，可以把状态机插入到TCP数据中输出，查看“死机”时，状态机停在何处，就容易定位问题了。

发送状态插入位置如下。

测试情况：如下，突然停止的现象还是存在。虽然插入了标志位，但是正常传输的时候，分析状态标志信息都是正确的。在戛然而止后，无法再开启回传，因此，也无法判断程序死在哪里！

加入time_out，防止死机判活模块，如下。以确保TCP发送不会死机于其中某个地方。

 

问题8：关于切换发送模式时，会出现误触发，造成多发送一帧，并导致整个状态死机的问题。因此，要先于启动发送数据req_data，更新测试标志open。

 

TCP连发2帧测试。

 

问题9: 关于窗口更新，造成的延迟

这个好像只能改善TCP助手的性能了。添加接收窗口判断功能，当接收窗口过小，减缓发送。

 

Wireshark速率计算。

稳定网络下的测试：

欢迎交流、源码分享见CSDN资源，笔者扣扣：1021100382