基于TCP的通信为什么需要RETRY

TCP协议本身是可靠的，它的重传机制保证了消息的可送达性（如果没有收到对端的ACK确认，它会在等待一定时间后，尝试再次发送，且这是一个循环过程，上限是9分钟。超过9分钟，则认为连接已经断开，关闭socket）。
虽然有了TCP的可靠性保证，但是很多基于TCP的应用间通信依然会采用RETRY机制：发送消息后，如果在一定时间内没有收到对端的确认消息，则重发消息。明明TCP已经可以保证消息的可送达，为什么还要在应用层加这么一层实现呢？


1. 有些服务进程，基于性能或是内存容量方面的考虑，使用了限长的消息队列：如果收到的瞬时消息过多，超过了消息队列的可处理个数，所有超出的消息会被它丢弃。注意，在这种情况下，TCP确实是将消息成功送达了，只是应用层不接受而已。客户进程等待一小段时间，尝试再次发送，有可能此时服务端的处理压力已经降下来了，消息就能被处理了。

2. 进入了弱网环境的移动应用，发送超时往往意味着已经断连。此时的RETRY，在底层意味着重新连接，然后再次发送消息。

其他：进入了弱网环境的移动应用，可能会给用户带来不大顺畅的使用体验。当用户发送了一条消息，与其让用户等待9分钟才得知消息未能送达，不如在应用层设置超时重传，一旦超过规定时间（比如20s），则直接告知用户，当前网络状况不佳，不妨晚些时候再尝试发送。