TCP/IP协议栈设计—TCP设计实现(优化)

TCP/IP协议栈设计—TCP设计实现(优化)

针对实现的初步TCP协议栈,对其细节地方进行优化,尽可能排除BUG。加入用户自定义数据测试,加入超时重传功能。

目录:

1,第一帧的ACK回复IP长度错误问题

2,关于发送奇数字节,调试助手未正确接收ACK问题

3TCP数据接收解析与自定义数据发送设计

4,对TCP超时重传的设计与仿真

5,完成上述优化后,对整体效果的测试

 

1,第一帧的ACK回复IP长度错误问题。

如下图,第一帧ACK回复的IP长度应该为40,但却为80,把data 长度加上了。需要程序找出BUG。

TCP/IP协议栈设计—TCP设计实现(优化)

仔细查找原因。因为错误很明确,所以查起来定位很快,原因在于,send_flag提前reply_ack到,所以在组IP首部的时候,长度错误组成是SEND数据的长了。开始相依最简洁的方式实现,即再增加一个标志位,进行区分。但是实际测试后,效果不好。又分析了仿真,就是按自己设计来的。所以一时很费解。这个“小”问题,不知不觉就困扰了我一上午。

中午休息之后,打算还是以状态机的形式给出SEND标志吧。添加如下程序。

TCP/IP协议栈设计—TCP设计实现(优化)

进过上述的发送限定后,再测试,得到如下结果。此时,第一次回复的ACK就正确了。到此,总算解决了这个问题。

TCP/IP协议栈设计—TCP设计实现(优化)

 

2,关于发送奇数字节,调试助手未正确接收ACK问题

如下,仔细分析了FPGA回复的ACK,是正确的。但助手却还是执行了重传。

TCP/IP协议栈设计—TCP设计实现(优化)

这个问题很可能是助手这边的问题。当我发送双字节的数据就正常,奇数字节的数据,就不能接收了。这个问题后面再想想吧,现在不像管这个了。

总之的话,后面加入超时重传等,现在的发送控制部分,都要重新设计的。

问题原因:校验和没计算对。

接收校验和正确的计算如下,要仔细分析奇数字节时的情况。

TCP/IP协议栈设计—TCP设计实现(优化)

 

3,TCP数据接收解析与自定义数据发送设计。

实现对接收到的TCP数据解析,根据不同的TCP数据命令,进行不同的用户数据发送。用户数据先由本地生产,后期可换成采集的数据等。

该子模块的顶层接口如下。

TCP/IP协议栈设计—TCP设计实现(优化)

对于用户数据的校验和,计算过程有点变化,程序如下。

TCP/IP协议栈设计—TCP设计实现(优化)

对其奇数字节的仿真,下图给出正确的计算结果。

TCP/IP协议栈设计—TCP设计实现(优化)

 

4,对超时重传的设计与仿真

设计采用TCPIP详解卷介绍,使用标准模式,见下图。模块顶层接口。

TCP/IP协议栈设计—TCP设计实现(优化)

超时重传的设计关键在于RTT(往返时间)的测量,程序中采用:发送数据开始计数,收到ACK并确认的时间,为RTTs测量时间。

TCP/IP协议栈设计—TCP设计实现(优化)

下图为RTO计算过程的仿真。

TCP/IP协议栈设计—TCP设计实现(优化)

 

5,完成上述优化后,对整体效果的测试

(1)对回传模式的测试,如下。建立连接后,发送BB帧头的数据,便开始回传。发送非BB帧头时,FPGA只接收,回复ACK,但不回传数据。

TCP/IP协议栈设计—TCP设计实现(优化)

更改发送字节长度,变为奇数字节,测试接收结果如下。接收正常。

TCP/IP协议栈设计—TCP设计实现(优化)

(2)下面测试用户数据回传模式。用户数据是可变的,且在程序中,数据段加入了IP_ID,RTT和RTO的实时值,用于观察和计算。

用户回传模式测试如下,图中进行了详细的分析。

TCP/IP协议栈设计—TCP设计实现(优化)

继续测试,分析接收数据的结果,如下。下图作了详细分析。

TCP/IP协议栈设计—TCP设计实现(优化)

最后,就是断开连接测试了,如下。断开正常。

TCP/IP协议栈设计—TCP设计实现(优化)

经过如上测试,验证了该版本程序的功能完整性,TCP程序版本更新为tcpip_stack_v2。

 

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