UDP:
1. 无连接:发送数据前不需要建立连接发送完数据也不需要释放连接
//减少了开销和发送数据之前的时延
2. 尽最大努力交付
//不要维持复杂的连接状态表
3. 面向报文
// 应用层->传输层->网络层
应用程序每次给下层交付一个报文,应用程序需要选择合适的报文尺寸。若报文太小,相对来说使得报文段首部太大,影响传输效率;若报文太大,交给传输层可能要进行分片,也降低效率。
4. 没有拥塞控制,会因为一些网络状况丢失一些数据,不过实时性强
//视频 ip电话 直播等
5. 支持一对一、一对多、多对一以及多对多的交互通信
6. UDP头部开销小 只有8字节
7. 发送方发送一次 接收端也只接收一次 如果一次接收没有完 剩余的就会被丢弃
TCP:
1. 面向连接的运输层协议
//发送数据建立连接 结束释放连接
2. 点对点通信 每一条tcp连接只能是1对1的
3. 可靠交付
//无差错、不丢失、不重复、按序到达
4. 全双工通信
//双方的应用程序随时都可以发送数据,连接的俩端都设有接收和发送缓存区
5. 面向字节流
// 流:流入进程或者流出进程的字节序列
Tcp每次交换的是数据报 大小不一
应用程序交下来的数据块给TCP,但被TCP仅仅看作是一连串的无结构的字节流。
在TCP中,可能会发生发送端多次发送,接收端一次或者接受次数少于发送次数的接收,导致粘包问题:
但是向传输一些二进制等不用考虑粘包问题
1.模拟HTTP的实体首部,给我们发送数据时添加一些信息,比如数据实体的长度大小等(最有效的)
2.发送端:tcp头部push标志,置为1,标识立即将数据发送出去,不用等缓冲区达到一定界限才发送
(不建议)
3.接收端:在编程或者优化方面,一旦有数据就马上接收(不好实现)
4.固定数据包的大小,每次只能发固定的长度的数据。
5.对于个别场景,我们可以在发送前将数据进行结构封装,到了接收端进行拆封装,然后进行合并。
就像解决页面抖动一样:
设计良好的页面置换算法(能设计出来就不会在这里逼逼了)
增大内存
尽可能的减少进程数量
为什么UDP没有粘包问题?
UDP应用程序每执行一次写操作,UDP模块就会将该数据封装起来,发给接收方
如果接收方一次没有接受完数据,但是第二次的数据又发送过来,那么就会发生数据丢失问题,原先的数据将会被丢弃。