常见协议UDP和TCP详解

UDP报文格式

在这里插入图片描述

上图可如,此处报文长度是两个字节范围是0-65535即0-64k。无法表示一个较大的数据包,如果需要穿一个比较大的数据有两个方法:

下策:在应用层针对大的数据包进行分包,然后再通过多个UDP数据包分别发送,这个时候接收方再根据收到的几个包重新进行拼接成完整的数据。问题就是太玛法写起来非常复杂,要考虑到很多情况,比如丢包或者包的顺序错了等等。
上策:改成TCP,TCP没有长度限制。

校验和

用来验证网络传输这个数据是否是正确的。网络上传递的数据本质是光信号和电信号,但是如果有一却外界干扰磁场之类的就可能会导致一些传递信息发生改变,校验和就能帮助我们发现数据中的错误。比如使用01的个数来作为校验和,校验和正确不能保证数据100%就是正确的,但是校验和不正确数据一定就是有问题的。虽然能如此校验和仍然广泛使用,因为成本低效果好。当然校验和也不一定单纯就是使用“个数”。还可以使用数据内容参与运算,如果是基于数据内容得到的校验和识别错误的概率是很高的。

描述网络数据的单位:

传输层的数据通常叫做段“segment”
网络层数据通常叫做包/报“packet”
数据链路层通常叫做帧“frame”

TCP报文格式

在这里插入图片描述
在这里插入图片描述

TCP核心机制

1.确认应答

目的

保证可靠传输的核心机制(可靠性:发送方发出数据后,能够知道对方有没有收到)

方法

对消息进行编号,在接收方收到消息之后,针对消息编号给发送方返回一个应答报文(ACK,acknowlegdege),表示自己已经收到了。

32位序号:消息的编号,TCP的针对消息的序号还有说法,并不是按照“消息条数”来进行编号的,而是按照字节来编号的。
32位确认序号:表示当前这个应答报文是针对哪个消息进行的确认应答。

在这里插入图片描述
在这里插入图片描述

2.超时重传

定义

相当于对确认应答进行了补充,确认应答是网络一切正常的时候,通过ACK通知发送方我收到了,如果出现了丢包的情况,超时重传机制就要起到效果了。

例子:
当我发出消息后,一直没有ACK可能会出现的情况,1是确实发丢了对方没有收到,我这里肯定也没有办法收到ACK,2是对方的ACK丢了,虽然对方收到了我的消息但是我收不到ACK。
解决方法:
对于发送方来说,发送方无法区分是哪种原因大致的没有收到ACK,但是最坏情况下是对方没有收到那我就重新再发一次。这里的重发也不是立即就重发,而是等一会。等到超出等待时间就进行重传。正常情况下,连续发丢两次的概率是比较低的。当然重传的数据也不一定会成功,如果是网络遭受到了严重伤害可能没那么容易恢复,重传也成功不了,在这种情况下也不会一直进行重传,重传的时间间隔也会逐渐变大。

问题:
如果是对方ACK丢了,此处触发了超时重传就会导致接收方收到了重复的消息。
解决方法:

TCP内部就会有一个去重操作,接收方收到的数据会先放到操作系统内核的“接收缓冲区”中,接收缓冲区可以视为是一个内存空间,也可以视为是一个阻塞队列。
收到新的数据,TCP就会根据序号,检查数据是不是在接收缓冲区中已经存在了。如果不存在就放进去,如果存在就直接丢弃。保证应用程序调用socket api拿到的这个数据一定是不重复的。应用程序是感知不到超时重传的过程的。

3.连接管理(经典面试题)

目的

也是TCP保证可靠性的一个机制

1)如何建立连接

三次握手,客户端

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值