网络原理知识点

最新推荐文章于 2025-07-09 10:11:41 发布

原创最新推荐文章于 2025-07-09 10:11:41 发布 · 82 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#网络 #服务器 #运维

TCP是重点,也是考点

首部长度就是除了数据部分,光看报头的长度,TCP的报头是"变长"的,这里我们用四个比特位表示报头的长度,这个范围是:0->15,这里首部长度的单位不是字节,而是4字节,所以要把数值乘以4才是真正的报头长度,所以TCP报头,最大长度是60字节

咱们说TCP报头是变长的,这个变长体现在选项这里,TCP报头的前20个字节是固定的,所以说TCP报头的最短长度是20字节,选项部分可以有,也可以没有,可以有一个选项,也可以有多个选项

所以说选项存在与否,就影响到了四位首部长度具体是几,换句话说,我们正是需要四位首部长度来知道选项到哪结束,来知道载荷数据从哪里开始

保留六位的意思就是先占着位置,当四位首部长度不够用的时候,再派上用场,保留位就是给未来留下了可以升级扩展的空间(虽然说大概率也不会扩展)

保留六位右边的一堆字母是"六个标志位",每个标志位是1bit,表示非常重要的含义,后面着重解释

TCP核心特性,结合这些特性,进一步地理解这里的报头结构

完整的TCP具体都有哪些设定可以在RFC标准文档=>最权威的资料

TCP特点:有链接,可靠传输(最具代表性),面向字节流,全双工

可靠传输是内核实现的,写代码的时候是感知不到的(这么设计使得用户的感知成本低,使用成本也低了)

确认应答,这是保证"可靠性"最核心的机制

确认应答:我发出一条数据,但是不确定对方收没收到,这时候对方给我一个回应,那我就知道数据发过去了,举个例子就是打电话的时候,我说话,然后对方给予我回应,那就说明他听见了,但是如果他半天不回应,那就是有可能信号不好,他没听到我说话

发短信也是确认应答,我们知道自己有没有发送成功就看对方有没有回应,有回应就是成功,没回应就是不成功

假如我给女神发短信

当连续发多条数据的时候,这多条数据,可能会出现"先发货至"的情况,后发的数据报先到

就变成了这种情况

这样就出现了严重的偏差

为啥会出现后发先至呢?

再举一个例子就是结婚的时候,新郎的车队去女方家里接新娘,如果双方家里距离远,车队的车并不是完完全全走在一起的,有可能前一辆车刚走,到你这里就开始等红灯,也有可能后头的车抄近路,导致后头的车先到了

同理,网络上的数据报也跟车队一样,网络上它的传输路径有很多,另外,每个节点(路由器/交换机)繁忙程度不一样,此时,这样的转发过程,也会存在差异,就和等红灯一样

怎么样能解决后发先至的问题呢?

可以针对数据进行编号

由于TCP是面向字节流的,不是按照"条"为单位来传输的,TCP每次读取的基本单位都是字节,所以这个时候我们就需要针对字节进行编号,所以这里的关键是我们针对每一个字节都进行编号

这里我们可以看到主机A给主机B发了一个数据,这里头就是1字节~1000字节,然后又发了一个数据1001字节~2000字节

我们画的是1~1000,但是这并不是一个整体,虽然我们画是这样画,但是我们不能将其称之为一条,我们也可以这样发

1.针对字节进行编号,而不是针对"条"

2.应答报文也是要和收到的数据的序号相关联的,但是不是"相等",1001表示1001序号之前的的数据我这边都收到了,接下来你应该给我从1001开始发

只需要在TCP报头中,把这一串字节的第一个字节的编号表示出来,再结合报文长度,此时每个字节的编号就确定了

这一串字节的第一个编号在TCP的报头结构中的三十二位序号

确认序号的数值,就是收到的最后一个字节的编号再加一

32位确认序号是给应答报文使用的

我们要如何区分这个报文是普通报文还是确认应答报文呢?

那我们就要看这里面的六个标志位了

我们重点看第二位ACK,如果ACK为0,表示这是一个普通的报文,此时只有32位序号是有效的

ACK为1表示这是一个应答报文,这个报文的序号和确认序号都是有效的(确认报文的序号和正常报文的序号之间是没有关联关系的,各自论各自的)

acknowledge 是应答的意思,所以我们也会使用ACK这个词来指代应答报文

核心就是一句话:确认应答是TCP保证可靠性的最核心机制

超时重传也是TCP可靠性机制的有效补充

我这边发,对面给我一个应答,这是属于一切顺利的情况,但是也会有不顺利的情况,这就是"丢包",网络上很可能出现,发一个数据然后丢了

两台主机之间是由很复杂的一系列联系的,它们中间有一堆路由器和交换机,相当于"交通枢纽",交换机和路由器也连接了许多别的设备,所以结构十分复杂,并且传输的量也是不确定的,这一会传输的数据少,过一会就可能多了,如果当前这里面传输的数据量已经很大了,对于这台机器来说压力太大快顶不住了,再让它传递数据就很容易出错,甚至有可能会出现丢包的情况

网络负载越高,越繁忙,就越容易丢包

如果真的出现丢包,收不到应答,等待了一定的时间,超过一定的时间之后,就要尝试重传,这样的机制就叫做"超时重传"

超时重传,相当于针对确认应答进行的重要补充

这里有超时重传两种可能的情况:

这两种情况再实践中都有可能存在

第一种情况:A给B发了一个消息,这个消息本身丢包了,这个时候是需要进行重传的

第二种情况:A发出消息,B收到以后确认应答,但是应答消息丢包了

发送方不能确认是那种情况,所以就只能都重传

但是如果是第二种情况,重传之后接收方就会收到两次一样的请求,如果这个请求是充值游戏,我本来只想充十块钱,结果变成充二十,这就不太好了,所以说接收方收到数据之后,需要对数据进行去重,把重复的数据丢弃掉,保证应用程序调用inputStream的时候,读到的数据不会出现重复

接下来的问题:如何进行去重?如何高效地判定当前收到的数据是不是重复的?

我们可以使用TCP的序号作为判定依据,TCP在内核中给每个socket对象都安排一个内存空间,相当于一个队列,也称为"接收缓冲区",收到的数据都会被放到缓冲区里,并且按照序号排列好顺序了,此时就可以很容易找到新收的数据是否重复了

有序排列是非常有意义的,这个是一定会等前面的数据到了才会真正进行读,read方法不会因为后面的数据先到而解除阻塞,后发先至问题在这里也解决了,因此应用程序就不必考虑传输的先后顺序问题,后面的数据先到,前面的数据没到,接收方仍然会通过ack继续索要前面的数据

收到数据,接收方的网卡,把数据放到对应的socket的接收缓冲区中(内核中)应用程序调用read就是从这个接收缓冲区消费数据,当数据被read走了,就可以从队列删除掉了(read有两种模式,一种是读了就删除,也可以读了不删除)

为啥重传的时候,就能传过去?重传有没有可能还是传不过去?

丢包本质上是一个概率的问题.假如丢包的概率是10%,那么连续丢包两次的概率是1%,随着重传次数的增加,总体能够传输成功的概率是更大的.但是是否会存在连续重传多次依然丢包呢?当然是存在的,如果当前丢包概率达到100%,比如网线断了,那不管咋重传,都是丢的

等待超时时间,超时时间是等多久呢?

这个不必记忆数值,数值都是可配置的,可变的,重点理解策略,超时时间不是一个固定的值,会随着超时轮次的增加而进一步增加,随着重传轮次的增加,等待时间也会越来越长,这是为什么嘞?因为当前认为,正常情况,第二次重传就有极大的概率重传成功,再不济,第三次重传有更大的概率能成功,结果这几次都没成功,说明当前网络本身的丢包概率已经极高了,网络怕是遇到了一些比较严重等待故障,此时进行频繁的重传也只是白费力气.拉长一些时间间隔,也是在给网络恢复留有一个时间上的余地

超时重传的轮次也不是无限的,重传次数达到一定程度也就放弃了,此时就会尝试"重置"TCP连接,这个涉及到TCP复位报文