基于TCP的通信为什么需要RETRY
2015-06-14 17:01
507 查看
TCP协议本身是可靠的,它的重传机制保证了消息的可送达性(如果没有收到对端的ACK确认,它会在等待一定时间后,尝试再次发送,且这是一个循环过程,上限是9分钟。超过9分钟,则认为连接已经断开,关闭socket)。
虽然有了TCP的可靠性保证,但是很多基于TCP的应用间通信依然会采用RETRY机制:发送消息后,如果在一定时间内没有收到对端的确认消息,则重发消息。明明TCP已经可以保证消息的可送达,为什么还要在应用层加这么一层实现呢?
1. 有些服务进程,基于性能或是内存容量方面的考虑,使用了限长的消息队列:如果收到的瞬时消息过多,超过了消息队列的可处理个数,所有超出的消息会被它丢弃。注意,在这种情况下,TCP确实是将消息成功送达了,只是应用层不接受而已。客户进程等待一小段时间,尝试再次发送,有可能此时服务端的处理压力已经降下来了,消息就能被处理了。
2. 进入了弱网环境的移动应用,发送超时往往意味着已经断连。此时的RETRY,在底层意味着重新连接,然后再次发送消息。
其他:进入了弱网环境的移动应用,可能会给用户带来不大顺畅的使用体验。当用户发送了一条消息,与其让用户等待9分钟才得知消息未能送达,不如在应用层设置超时重传,一旦超过规定时间(比如20s),则直接告知用户,当前网络状况不佳,不妨晚些时候再尝试发送。
虽然有了TCP的可靠性保证,但是很多基于TCP的应用间通信依然会采用RETRY机制:发送消息后,如果在一定时间内没有收到对端的确认消息,则重发消息。明明TCP已经可以保证消息的可送达,为什么还要在应用层加这么一层实现呢?
1. 有些服务进程,基于性能或是内存容量方面的考虑,使用了限长的消息队列:如果收到的瞬时消息过多,超过了消息队列的可处理个数,所有超出的消息会被它丢弃。注意,在这种情况下,TCP确实是将消息成功送达了,只是应用层不接受而已。客户进程等待一小段时间,尝试再次发送,有可能此时服务端的处理压力已经降下来了,消息就能被处理了。
2. 进入了弱网环境的移动应用,发送超时往往意味着已经断连。此时的RETRY,在底层意味着重新连接,然后再次发送消息。
其他:进入了弱网环境的移动应用,可能会给用户带来不大顺畅的使用体验。当用户发送了一条消息,与其让用户等待9分钟才得知消息未能送达,不如在应用层设置超时重传,一旦超过规定时间(比如20s),则直接告知用户,当前网络状况不佳,不妨晚些时候再尝试发送。
相关文章推荐
- TCP版backshell的VBS脚本代码
- JavaScript Archive Network 集合
- TCP Wrappers防火墙介绍与封锁IP地址的方法
- c语言多进程tcp服务器示例
- win2003连接限制TCP连接限制
- PowerShell脚本开发之收发TCP消息包
- Android TCP 文件客户端与服务器DEMO介绍
- Android中实现TCP和UDP传输实例
- python实现可将字符转换成大写的tcp服务器实例
- php实现TCP端口检测的方法
- Java实现Socket的TCP传输实例
- 实现了基于TCP的Java Socket编程实例代码
- Java基于Tcp协议的socket编程实例
- python实现TCP服务器端与客户端的方法详解
- python检测远程服务器tcp端口的方法
- python实现简单的TCP代理服务器
- python网络编程之TCP通信实例和socketserver框架使用例子
- GO语言实现简单TCP服务的方法
- IEEE/ACM ASONAM 2014 Industry Track Call for Paper
- linux系统调优-Network