采取TCP时，应用层需要超时重传吗

采用TCP时，应用层需要超时重传吗？
    工作需要给第三方通信，采用tcp协议，文档中要求在发送消息一定时间内，未收到对方回复，需要重发。tcp本身是提供这种机制的额，为什么还需要应用层超时重发？如果之前一条消息在指定时间内未收到回复，重传了，但之前那条消息后来又被对方收到了，岂不是一条消息被发送了2次？
------解决思路----------------------
tcp本身是提供这种机制的额，为什么还需要应用层超时重发？

这个是跟网络层的实现有关的，不知道你的网络层是自己写的，还是用的写好，或者是第三方的。
tcp相对于你的网络层保证不丢包，不代表网络层相对于你的应用层保证不丢包。
这个和具体的网络实现有关

重传了，但之前那条消息后来又被对方收到了，岂不是一条消息被发送了2次？ 

确实会存在这种情况，但是这个不是发送方需要考虑的问题，而是接收方需要考虑的.
解决办法：比如需要在消息里面加上sessionid，一个逻辑包对应一个唯一的sessionid，重发时不改变这个sessionid，接收端收到重复的sessionid就不处理。


------解决思路----------------------
用 TCP 的话，是超时后链接断开了，你重新建立了链接，才需要重新发送之前发送的数据。
如果链接没有出现异常， TCP 会一直重试你放到发送缓冲区中的数据，直到收到对方确认或是重试次数太多失败后在链接上返回异常。
------解决思路----------------------

引用:

网络层也是我自己写，如果网络层相对于应用层丢包，说明程序存在bug，即使提供了重转，不一样会被丢掉？

首先lz需要明白的是，send的返回OK != 数据被对方成功收到 ，且，数据被对方成功受到 != 数据被对方逻辑成功处理

举个极端的例子：
对方收到包，但是还没来的及处理，程序崩掉了，这个时候你的网络层显示的显然是对方收到了（确实也是对方收到了），但是对方并没有正确处理这个包，这个时候从逻辑上讲，你应该需要重发的，保证对方正确处理完毕。