协议

一.UDP协议

1.UDP协议是无连接的,发送数据之前不需要建立连接,减少了开销和发送数据之前的时延

2.UDP使用仅最大努力交付,主机不需要维护复杂的链接状态表

3.UDP是面向报文的。发送方的UDP对应用程序交下来的报文,添加首部后交给IP层,UDP对应用层交下来的报文,既不合并,也不拆分,而是保留这些报文的边界。也就是说,不管应用层交给UDP多长的报文,UDP照样发送,即一次发送一个报文。因此,应用程序必须选择合适大小的报文。若报文太长,UDP把它交给IP层后,IP层在传送时可能要进行分片,会降低IP层的效率,反之,报文太短,UDP把它交给IP层后,会使IP数据报的首部的相对长度太大,也降低了IP层的效率

4.UDP没有拥塞控制,网络出现拥塞时,不会使源主机的发送速率降低,适用于某些实时性要求高的应用

5.UDP支持一对一,一对多,多对一,多对多的交互通信

6.UDP首部开销相对TCP来说较小


二.TCP协议

1.TCP是面向连接的运输层协议,建立连接,释放连接不可缺少

2.每一条TCP连接只能有两个端点,每一条TCP连接是点对点的

3.TCP提供可靠交付服务,通过TCP连接传送的数据,无差错,不丢失,不重复,并且按次序到达

4.TCP提供全双工通信,TCP连接两端都设有发送缓存和接受缓存,用来临时存放双向通信的数据。在发送时,应用程序把数据传送给TCP的缓存后,就可以做自己的事情,TCP在合适的时候把数据发送出去。在接收时,TCP把收到的数据放入缓存,上层的应用进程在合适的时候读取缓存中的数据

5.面向字节流。面向字节流的含义是:虽然应用程序和TCP的交互是一次一个数据块,但TCP把应用程序交下来的数据看成仅仅是一连串的无结构字节流,TCP并不知道所传送的字节流的含义,TCP不保证接受方应用程序所收到的数据块和发送方应用程序所发出的数据块具有大小对应的关系

6.TCP对应用进程一次把多长的报文发送到TCP的缓存中是不关心的,TCP根据通信对方给出的窗口值和当前网络的拥塞程度决定一个报文段应该包含多少字节(UDP发送的报文长度是应用进程给出的),如果应用进程传送到TCP缓存的数据块太长,TCP就可以把它划分短一些再传送。如果应用进程一次只发来一个字节,TCP也可以等待积累有足够多的字节后再构成报文段发送出去


 三.链路层协议

网络层的IP数据报传送到数据链路层就成为帧的数据部分。在帧的数据部分的前面和后面分别添加上首部和尾部,就构成了一个完整的帧。因此,帧的长度等于数据部分的长度加上帧首部和帧尾部的长度,而首部和尾部的一个重要作用就是进行帧定界(即确定帧的界限),此外,首部和尾部还包括许多必要的控制信息。显然,为了提高帧的传输侠侣,应当使帧的数据部分长度尽可能地大于首部和尾部的长度。但是, 每一种链路层协议都规定了帧的数据部分的长度上限——最大传送单元MTU,那么,实际上MTU就是网络层传送下来的IP数据报的最大长度。
数据链路层的校验可以实现无比特差错,但是要实现“可靠传输”,需要两方面内容,一是无比特差错,二是无传输差错,传输差错一般来说就是帧丢失、帧重复或帧失序,数据链路层使用CRC校验,能够实现无比特差错的传输,但这还不是可靠传输。
我们知道,OSI的观点就是必须把数据链路层做成是可靠传输的。因此在CRC校验的基础上,增加了帧编号、确认和重传机制。收到正确的帧就要向发送端发送确认。发送端在一定期限内若没有收到对方的确认,就认为出现了差错,因而就进行重传,直到收到对方的确认为止。这种方法在历史上曾经起到很好的作用。但现在的通信线路的质量已经大大提高了,由线路质量不好引起的差错的概率已经大大降低。因此, 因特网广泛使用的数据链路层协议都不使用确认和重传机制,即不要求数据链路层向上提供可靠传输服务(因为这样付出的代价太高,不合算)。如果在数据链路层传输数据时出现了差错并且需要进行改正,那么改正差错的任务就由上层协议(例如,运输层的TCP协议)来完成。实践证明,这样做确实可以提高通信效率!
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值