1.上百万TCP连接的网络服务,其编程的难度、程序复杂度、调试难度、服务器运维成本、网络成本等都远远高于UDP。
2.现在的移动端IM、推送系统,既面对移动互联网的不确定性,又面对智能终端频繁的系统休眠、网络切换,还要考虑服务端的承载成本,对于在线服务而言UDP是比TCP更适合的方式。但是由于数据完整性、安全性的需要,又不应完全放弃TCP的可靠与安全。
3.粘包:
只有TCP有粘包现象,UDP永远不会粘包!
why?UDP发送的时候 是可以按照一个一个数据包去发送的 一个数据包就是一个明确的边界,面向报文形式
1.TCP并没有数据包的概念 是完全流式的 他会开辟一个缓冲区 发送端往其中写入数据 过一段时间就发送出去 然后接收 端接收到这些数据 是并不是说我发送了一次数据就肯定发送出去了 数据会在缓冲区中 可能后续发送的数据和之前发送 的数据同时存在缓冲区中随后一起发送
2.接受端取的时候也会发现同1的情况
3.比如填充缓冲区到一半缓冲区满了直接发送了 但是其实那个包还没填充完全 这个就是不完整的粘包了 剩余数据会在下 次发送的时候补上就是粘包
解决方案:
1. 循环使用的大缓冲队列;
2. 定义数据头。
2.现在的移动端IM、推送系统,既面对移动互联网的不确定性,又面对智能终端频繁的系统休眠、网络切换,还要考虑服务端的承载成本,对于在线服务而言UDP是比TCP更适合的方式。但是由于数据完整性、安全性的需要,又不应完全放弃TCP的可靠与安全。
3.粘包:
只有TCP有粘包现象,UDP永远不会粘包!
why?UDP发送的时候 是可以按照一个一个数据包去发送的 一个数据包就是一个明确的边界,面向报文形式
1.TCP并没有数据包的概念 是完全流式的 他会开辟一个缓冲区 发送端往其中写入数据 过一段时间就发送出去 然后接收 端接收到这些数据 是并不是说我发送了一次数据就肯定发送出去了 数据会在缓冲区中 可能后续发送的数据和之前发送 的数据同时存在缓冲区中随后一起发送
2.接受端取的时候也会发现同1的情况
3.比如填充缓冲区到一半缓冲区满了直接发送了 但是其实那个包还没填充完全 这个就是不完整的粘包了 剩余数据会在下 次发送的时候补上就是粘包
解决方案:
1. 循环使用的大缓冲队列;
2. 定义数据头。