我们目前正在使用LWIP堆栈在Atmel（Nest）微控制器和ECU之间进行TCP / IP数据传输。作为数据传输的一部分，我们的LWIP仅处理收到的数据包的ACK响应。但是最近我们看到，当我们收到来自ECU的TCP数据包时，如果我们有准备好从嵌套传输的数据包，则LWIP将使用ECU seq编号作为ACK编号并进行传输。我们假设由于在Tx数据包中设置了ACK位，因此Tx帧也被视为ACK帧。但是在连续数据传输过程中，我们已经看到一些来自ECU的数据重新传输说Nest没有提供ACK。但是我们的Tx帧将ECU数据包的Seq编号设置为ACK编号。
数据传输是我们的LWIP做错了吗？我们是否需要对每个帧都进行ACK确认，然后再发送新的发送帧？如果在接收帧序列号为Tx的帧中设置了ACK，可以吗？
我们在数据传输过程中完全与ACK机制混淆。
关于，PraveenKumar。
数据传输是我们的LWIP做错了吗？
根据您的描述，我认为这里没有任何问题。 TCP实现允许主动重传数据包，因此即使没有数据包丢失，也可以预期/正常地进行一些重传。
我们是否需要对每个帧进行ACK，并且应该去新的发送帧，或者如果在接收帧序列号为Tx的帧中设置了ACK，可以吗？
ACK必须在建立连接后发送的每个帧中设置。确认号将始终反映最近接收到的序列号（假设没有重新排序或丢包）。只需记住网络有一定的延迟，因此一端上最近接收到的序列号会稍稍低于另一端上最近发送的序列号。
示例1：考虑使用基于重复ACK的重传的TCP实现。
https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Dupack-based_retransmission
现在假定A侧发送5个有效载荷数据包，而B侧同时发送一个有效载荷数据包。 A侧在B侧的一个数据包到达之前设法发送所有5个数据包。在这种情况下，来自A侧的所有5个数据包将具有相同的ACK编号，但不会反映从B发送的数据包。B将在一行中看到5个ACK编号，它们都相同，并假定其数据包丢失并重新传输。该数据包实际上并没有丢失，因此，A侧将两次接收相同的数据包。这不是问题。 A侧将检测到重复的序列号，并丢弃第二个。
示例2：考虑使用基于超时的重传的TCP实现。网络中的任何瞬时拥塞都会导致数据包到达的时间比预期的要晚得多。 TCP实现将假定延迟的数据包被丢弃并重新传输。一个好的算法最终将“学习”到期望的时延差异（抖动），并将为重传设置更高的阈值，以避免不必要的流量。
[TCP可以实现很多重传和拥塞管理算法，因此尚不清楚为什么在您的情况下发生重传，但是除非重传的数量如此之大，否则不必担心。影响性能。如果存在性能问题，则可能要检查是否可以选择其他重传方法，并查看是否可以解决问题。