采用TCP时，应用层需要超时重传吗？
需要，原因如下：
1 tcp的超时控制不是你能设置的，所有的tcp超时都是用系统的时间设定，而且这个时间很长，超时的结果就是断开连接。和你应用要达到的目的显然差很远
2 send的返回OK != 数据被对方成功收到 ，且，数据被对方成功受到 != 数据被对方逻辑成功处理
举个极端的例子：
对方收到包，但是还没来的及处理，程序崩掉了，这个时候你的网络层显示的显然是对方收到了（确实也是对方收到了），但是对方并没有正确处理这个包，这个时候从逻辑上讲，你应该需要重发的，保证对方正确处理完毕。
3 如果底层通信质量不好，TCP可能会断链重连，或者序号检测发现异常重置序号。这些情况下TCP层都会丢帧，应用层如果有重要的消息还是要自己做重传。
TCP协议本身是可靠的，它的重传机制保证了消息的可送达性（如果没有收到对端的ACK确认，它会在等待一定时间后，尝试再次发送，且这是一个循环过程，上限是9分钟。超过9分钟，则认为连接已经断开，关闭socket）。
虽然有了TCP的可靠性保证，但是很多基于TCP的应用间通信依然会采用RETRY机制：发送消息后，如果在一定时间内没有收到对端的确认消息，则重发消息。明明TCP已经可以保证消息的可送达，为什么还要在应用层加这么一层实现呢？
1. 有些服务进程，基于性能或是内存容量方面的考虑，使用了限长的消息队列：如果收到的瞬时消息过多，超过了消息队列的可处理个数，所有超出的消息会被它丢弃。注意，在这种情况下，TCP确实是将消息成功送达了，只是应用层不接受而已。客户进程等待一小段时间，尝试再次发送，有可能此时服务端的处理压力已经降下来了，消息就能被处理了。
2. 进入了弱网环境的移动应用，发送超时往往意味着已经断连。此时的RETRY，在底层意味着重新连接，然后再次发送消息。
其他：进入了弱网环境的移动应用，可能会给用户带来不大顺畅的使用体验。当用户发送了一条消息，与其让用户等待9分钟才得知消息未能送达，不如在应用层设置超时重传，一旦超过规定时间（比如20s），则直接告知用户，当前网络状况不佳，不妨晚些时候再尝试发送。