网络原理 -TCP/IP --传输层(TCP)

T04BF
👋专栏: 算法|JAVA|MySQL|C语言
🫵 今天你敲代码了吗

这个队列是怎么知道数据曾经在队列里面存在过??

实际上接受缓冲区除了去重之外,还有一个非常重要的功能,就是针对收到的数据进行排序

我们前面说过网络传输会先发后至,但是很多时候我们希望发送出去的消息能够有序的到达接收方

在接收缓冲区里面就会对接受到的数据进行排序,即使接受到的是乱序的,也会让序号小的在前面,序号大的在后面,并且数据和数据之间的序号始终是连续的

这样的话,假设队首元素的序号是1000,那么说明比1000小的数据都read过了

那么此时再收到<1000的数据,就可以认为是重复数据了

但是实际上,丢包本身就是一个"概率性事件"

假设网络的丢包率是 10%,一次传输丢包的概率就是10%,触发重传后,重传也丢包的概率就是1%,此时就说明99%的概率是传输成功的

如果连续重传几次后都发现丢包,那么就说明网络是发生严重故障了

因此我们前面提到的等待超时重传的时间,实际上是动态变化的,会随着重传轮次的增加,变得越来越长

假设第一次传输数据,等待50ms,就会触发重传,那么重传之后就会等待100ms...(超时时间的间隔会越来越长,不一定是线性),换而言之,就是重传的概率会越来越低

这样设定实际上就是因为,出现重传多次的情况,大概率就是网络出现严重故障了,重传成功的可能性也比较低

那么此时就降低重传的时间间隔,如果是设定重传越来越快,非但得不到好的结果,而且会浪费很多系统资源

如果是网络出现了严重故障,重传若干次还是不成功,到达一定的次数阈值,就会尝试"重置连接"

就会触发一个"复位报文",尝试重置连接,相当于连接重新开始

当网络出现严重故障的时候,RST报文也是无法顺利完成的,此时重置也是失败了,就只能断开连接了

超时重传是确认应答的重要补充
TCP的可靠传输,全靠确认应答和超时重传这两个机制支撑起来

连接管理(三次握手和四次挥手)

建立连接的过程:三次握手

断开连接的流程:四次挥手

三次握手

指的是两个机器一见面,就进行"打招呼","打招呼"的过程中,没有实际上的数据交互,只是为了打招呼而传输一些数据

即无论是握手还是挥手,传输的网络数据报,不携带任何业务上的数据

建立连接,就是通信双方各自保存对端的信息,而具体完成上述的过程,需要经过三次网络交互

三次握手的第一次,一定是客户端先发起的

此时这个数据报是不携带任何业务数据的,即载荷部分是空着的,只有TCP报头,这个TCP报头6个标志位中SYN这一位为1

三次握手的流程就是

上述流程,客户端和服务器各自给对方发送syn,再各自给对方回一个ack,其实是4次交互

关键在于,中间的交互ACK和SYN可以合并成一个网络数据

ACK是6个标志位的第二位,SYN是6个标志位的第5位.所谓合并,就是让这一个TCP数据报的报头中,同时将两个比特位都设置为1

3次交互实际是比4次交互的效率更高的

三次握手的时候,实际上就相当于双方各自让对方保存自己的信息,得是双方都把对方的信息保存好,连接才算是建立完成

我们写socket代码的时候,客户端new Socket对象,就在系统底层触发syn等三次握手的过程,而调用accept其实是三次握手已经完成了,应用程序将操作系统内核里面搞好的连接信息给取出来了

那么三次握手的意义是什么?? 解决的是什么问题??

(1)相当于是投石问路,在正式传输业务数据的之前,先确认一下人通信链路是否畅通(实际上也是可靠传输的一种保证)

(2)通过三次握手,来确认通信双方的发送能力和接收能力都是正常的

就很像我们平时打电话

那么试想一下,三次握手变成两次握手是否可行??

实际上是肯定不行的,因为如果只有前两次没有第三次,那么此时服务器这边对于发送能力以及客户端的接受能力的认知是不完整的,需要第三次交互,把客户端掌握的情况告知给服务器

(3)三次握手的过程中,还需要协商一些必要的参数

此时需要通信双方共同商量一下,有的参数不是单方面就能够确定,需要双方共同来确定

我们在上面讲过的 TCP通信时使用的序号,就是在这个阶段协商出来的

也就是说,序号不是单纯的从0/1开始

而第一次连接和第二次连接,协商出来的起始序号,是不一样的,往往差异很大

这里这么设定,是TCP考虑到一个情况,就是避免出现"前朝的剑,斩本朝的官".我们考虑一种场景:

此时就是通信双方先建立连接,进行若干次通信之后,断开连接,过一会后,又重新建立连接进行若干通信

但是可能会出现一种情况,就是在前一次连接的过程中,某一次数据报走了一个非常绕远的路线(不是丢包),等到这个数据报到达对方之后,此时已经断开连接了.是一个新的连接

那么服务器收到这个数据报,应该是直接丢弃还是按照正常逻辑来处理??

答案是直接丢弃,因为新的连接对应的服务器进程都可能不是同一个程序了

那么既然要丢弃,服务器是如何区分当前来的数据报,是否是"前朝的数据报"??

实际上通过序号就可以区分出来

每一次连接都是从一个新的数字开始作为起始的序号的,并且本次连接的数据之间的序号一定是沿着这个起始序号开始往下的序号(不会差别很大)

如果此时突然收到了一个数据报,序号与当前连接的起始序号相差很大,就可以认为是"前朝的数据"了

实际上这样设定的目的就是防止不同连接的数据互相干扰

我们在上面画的是三次握手的示意图实际上是一个草图,我们来看看详图

详图相比简图,就是多了,在应用层方面,三次握手对应的代码调用的原生api是哪些,以及tcp对应的状态变化

我们重点理解的是几个状态变化:

listen:是服务器出现的状态,当服务器绑定端口成功之后,就会进入到listen状态,此时就意味着,就随时可以有客户端连接上来了

established:表示建立完成,可以进行后续通信了

四次挥手

四次挥手是断开连接的过程

我们之前说过,三次握手,一定是客户端先发起的第一次请求

但四次挥手则不一定,客户端和服务器之间都可以主动发起.我们此处以客户端主动退出为例,即客户端代码里面调用socket.close方法或者客户端进程结束

FIN是finish的缩写,是6个标志位的最后一位

四次挥手的过程为:

断开连接就是,通信双方都把之前保存的对方的信息都删了.在TCP中就是希望达成的效果是:双方互删

那么四次挥手的过程中,能否像三次握手那样,将中间两次合并??

答案是常规情况下是不能合并的,特殊情况下是可以合并的

为什么不能合并??

实际上,我们在三次握手的过程中,ack和syn都是系统内核自动控制发送的,是同一时机

但是在我们四次挥手的过程中,就不一样了

此时中间ack和fin数据报的发送操作,不一定是同一时机,而是中间会隔很久

当服务器发现scanner没有next的时候,就结束循环了,就会进入close操作,客户端调用close / 客户端进程退出,此时fin数据报过来之后,服务器就能感知到scanner没有next了

但是实际上我们当前的服务器写的很简单,感知到scanner没有next就立即结束循环调用close了

但是如果代码更加复杂,在没有next 和 close之间,又写了很多代码??甚至都没有调用close

此时就指不定,close要什么时候执行了

由于这两个数据报发送触发的是不同的时机,因此就很难合并

但是在特殊情况下,上述两个操作是可以合并的

在TCP协议中还有一个机制,延时应答,即回复ack的时候不是马上,而是稍等一会,在这种情况下就能够合并

但是终究,上述的合并的情况是属于一种特殊情况,对于一般情况是不能合并的,所以还是将断开连接称为 "四次挥手"

同样,我们也来看看四次挥手的详图

CLOSE_WAIT:被动一方进入的状态,表示等待代码调用close

当代码调用close得越及时,这里的状态就不越容易被看到

有的时候,可能会在服务器这边见到大量的CLOSE_WAIT => 说明代码大概率就有bug了,即代码很可能就忘记调用 close 或者close调用的不及时

TIME_WAIT:存在的意义就是为了应对最后一个ACK丢包这样的情况

客户端在收到服务器返回的fin之后,不能立即释放tcp连接(如果立即释放了,后续一旦对端重传的fin,此时客户端就不能应对,即无法返回ack了)

那么此时在客户端这边,就需要有一个特殊的状态,来应对可能到来的重传的fin数据报

而TINE_WAIT状态不是持续的,而是有一定时间.在一定时间内,如果没有收到重传的fin,潜台词就是,最后一个ack已经被对方收到了,就不会重传fin,此时time_wait就可以释放了

那么也出现一种小概率的极端情况,就是对端一直不发剩下的fin,可能是bug / 对端没有调用close,那么等待一定时间之后,自己就会单方面将保存B的信息删掉

注意:服务器调用close后不是真正的断开连接了,真正将对端信息互删是在4次挥手完了之后,才断开连接

那么如果有时候发现服务器端出现大量的time_wait,如何处理??

出现大量的time_wait,说明服务器这边触发了大量的主动断开TCP连接的操作,

这样的情况对于服务器来说是很不科学的,因为一般都是客户端主动断开的连接

总结:close_wait不一定是服务器处于的状态,time_wait也不一定是客户端处于的状态而是:close_wait是被动接受断开连接的一方,time_wait是主动发起断开连接的一方

滑动窗口

我们前面讲过,确认应答,超市重传,连接管理,都保障了TCP的可靠传输

但是TCP在保证可靠传输的同时,也要考虑效率问题,也希望能够尽可能高效的完成数据传输

滑动窗口就是一种提高效率的机制

如果不引入滑动窗口,那么数据的传输过程就是这样的

就是A每收到一个ACK,才发送下一个数据

实际上这样是比较低效的,大量的时间都花费在等待ack上面

当引入滑动窗口

此时就是从之前的一条数据一条数据发送 => 批量发送

那么此时就可以将等待时间重叠了

所谓滑动窗口,窗口就是表示,不等待ack,批量发送是多少数据,这个数据的量就是窗口大小

如图所示,白色区域就是表示,当前批量发送了多这四组数据 ,等待这4组数据的ack

当收到了确认序号为2001的ack,此时就代表1000 - 2001的数据得到了确认,标记成灰色了;于此同时,也发送了新的数据(5001 - 6000)

此时还是继续等待4组数据的ack

引入滑动窗口后,批量发了4组数据之后,不是等待4组数据的ack都收到才发送新的数据,而是收到一个ack,就往后发一个新的,就类似于窗口的滑动

那么在滑动窗口的情况下,出现丢包了怎么办

情况1:数据已经到达了,但是返回的ACK丢了

如图所示,此时序号为1001的ack丢了,但是实际上不需要做任何处理

下一个2001的ack实际上就是告诉发送方,当发送方收到2001的数据时候,此时2001之前的所有数据都已经收到了

同样,尽管3001 和 4001 的ack丢包了,但是当发送方收到5001的ack后,表示前面的3001 - 4000 4001 - 5000的数据也收到了

此时ack确认序号的规则,巧妙的解决了这里ack丢包的问题

情况2:数据报直接丢了

如图所示,虽然1001-2000的数据丢了,但是此时主机A还是仍然给B发送数据

但是接下来的每个数据,B返回的ack都是在索要 1001-2000这些数据

当A这边连续收到若干个1001这样的ack后,就明白了1001 - 2000数据报丢包了,就会重发这个数据报

此时重发1001 -2000被接受之后,B就是直接索要7001 - 8000的数据报

当某一处存在某个缺口的时候,返回的ack确认序号就是一直在索要缺口的数据

此时一旦缺口被补上,那么就直接从队列的最后一个数据的序号继续往后索要

上述针对丢包的处理实际上,整个过程是非常高效的

(1)对于ack丢失,不做任何处理

(2)对于数据丢失,只需要将缺失的数据重发即可,其他数据不必重传

这就是滑动窗口之下,搭配的丢包处理机制:快速重传

那么超时重传和快速重传,好像是两个不一样的重传机制??会不会出现冲突?

实际上不会.这两种机制实际上是不同情况下,采取的重传策略

可以认为,快速重传是超时重传在滑动窗口下的特殊变种

因为如果你的tcp传输的数据较少,不频繁,此时就不会触发滑动窗口,得是你短时间内传输大量的数据,超能触发滑动窗口

如果没有触发滑动窗口,那么此时还是按照超时重传的传统方式来解决丢包问题

一旦触发了滑动窗口,此时才触发快速重传,按照ack反馈的次数来解决丢包问题

总的来说,滑动窗口,说是提升效率的机制.更加准确的说,是亡羊补牢的机制

因为TCP为了保证可靠传输,是牺牲了很多效率的复杂引入滑动窗口,就是为了让效率牺牲更小一点,但是还是存在牺牲的,同时也让协议变得更加复杂

再怎么使用滑动窗口,速度还是不可能比UDP这种没有可靠传输的机制快的

流量控制

在滑动窗口里面,我们涉及到一个关键概念,就是窗口的大小

实际上,这里的窗口大小是可以设定的

也就是说,我们可以通过改变窗口的大小,来控制发送方的发送速度

那么窗口越大,单位时间内传输的数据就越多,效率就越高

反之就越低

通常情况下,我们肯定是希望尽可能高效的传输

但是高效的前提一定是保可靠性

如果发送太快,接收方可能处理不过来,此时如果引起丢包,那更加得不偿失

那么接收方就要根据自身的处理能力,反向制约发送方的速度,使双方达到一个平衡

那么具体是怎么衡量接收方的处理速度呢??

实际上是通过接受方的接受缓冲区(阻塞队列)来判断的

实际上就是以空闲空间大小(未使用的空间大小)作为发送方发送数据的窗口大小

那么接受方就需要将这个空间的大小告诉发送方

在接收方给发送方返的ack报文里面,在报头里面就存在16位窗口大小

这个东西只会在ack报文里面生效,含义就是接收方缓冲区里面空闲的空间大小

那么既然是16位,是否就意味着,最大的就是 64kb呢??

答案是否定的

在选项里面实际就包含有一个特殊属性,"窗口拓展因子"

有这个选项之后,此时的窗口大小就是窗口大小 >> 窗口拓展因子

此时发送方就可以根据上述窗口大小,来决定下一轮数据发送的窗口大小了

在上图中,实际上没有考虑B应用程序消耗数据的过程.但是实际上B的应用程序,也在不停的消耗数据,使剩余空间变大

一旦缓冲区满了,就会告诉发送方,暂停发送

如果A暂停发送,B也就不会发对应的ack了,但是如果此时B缓冲区发生改变(应用程序消耗了一部分数据),那么如何告知A??

实际上当收到缓冲区满了的信号之后,此时A就会周期性的发送"窗口探测报文",也是不携带业务数据载荷的tcp数据报,主要目的就是为了触发ack,从而知道,B这边的缓冲区的情况

拥塞控制

与流量控制类型,都是和滑动窗口搭配的机制

流量控制是站在接收方的角度,影响发送方的速度

但实际上发送方发数据给接收方,中途会遇到很多的路由器和交换机,我们还是要考虑这些设备的性能瓶颈

链路上的任何一个节点,性能瓶颈都会制约发送方的发送速度

但流量控制,很容易就能够定量的来衡量接受缓冲区的剩余空间大小,用这个来作为发送窗口的大小

但是考虑中间节点就比较复杂,实际上中间有多少设备是不清楚的,更何况每次走的路径不一样,每个设备的处理能力,繁忙程度也不一样

实际上处理方法是,任凭你中间有多复杂,tcp都把他们视为一个整体,然后通过实验的方式来找到一个适合的窗口大小

刚开始,按照比较小的速度,小的窗口来发送速度,如果没有出现丢包,说明中间链路非常畅通,此时就可以增加速度,增加窗口大小

如果还是没有出现丢包,仍然很畅通,中间路径都是可以抗住的,那就继续增加速度,继续增加窗口大小

增加到一定程度,发送速度非常快了,此时可能某个设备就会达到瓶颈,出现丢包了

此时发送方立即减小窗口大小,继续尝试增加

如果还是丢包,就继续尝试减

不丢包就继续尝试加

这样就能找到一个合适的窗口大小的值,就可以不出现丢包,并且还能以比较快的速度来玩笑传输

那么在复杂的网络里面,就能够按照上述的方式来动态调整,随时应对,适应网络中的变化,达到动态平衡

那么拥堵控制这里的窗口,影响发送速度,流量控制这里窗口,也是影响发送速度的

那么听谁的?? 实际上就是这两个窗口谁小,就听谁的

那么究竟拥塞控制,窗口的大小是如何变化的?? 是否有规律??

规律就是:

(1)刚开始以较小的窗口来传输数据(主要是因为刚开始不知道网络是否拥堵,先试试看)

(2)接着按照指数的方式来扩大窗口(*2)

(3)指数增长的过程中,达到某个阈值,就会变成线程增长(+n,这里的n也是可配置的)

(4)线性增长后,速度越来越快,增长到一定程度,就会出现丢包

此时发送方就大概知道,网络的大概能力是什么水平,此时就会立即将窗口变小

缩小有两种方式:

①直接缩小到低,回到的最初的慢启动的时候,接下来还是指数增长,线性增长

现在这种方式已经废弃了

②缩小出现丢包情况的窗口大小的一半,接下来线性增长

这是目前tcp使用的方式

①这个方式比②方式更加低效,一下子缩得过火

延时应答

指的是,ack不会立即返回,而是等一会再返回

那么为什么要延时??

核心目的就是为了提高传输的效率

我们在前面说过,决定传输速度最关键的因素就在于窗口大小

我们希望在接收能够承受的前提下,尽可能的提高窗口大小

通过延时,就能够使窗口大小得到提升

延时,就是为了给应用程序腾出更多的消费数据的时间

如图所示,假设收到1kb的数据之后,缓冲区的空间还剩下4kb,如果立即返回ack,那么ack指定的窗口大小就是4kb

但是如果延时一会再返回ack,此时在延时的时间里面,应用程序很可能就消费了刚刚1kb里面的一部分数据,那么此时的窗口大小就会对应变大

实际上这里的变大,其实也是和应用程序的处理能力直接相关的,是在合理范围内的变大

这里的延时,就有两种方式

(1)按照一定的时间来指定延时

(2)按照收到的数据量来指定延时

在实际上tcp连接中,这两策略实际上是结合使用的

捎带应答

这是建立在延时应答的基础之上,提升效率的机制

在日常开发中的通信,通常是"一问一答"这样的模型

正常来说,ack是内核接受请求之后,自动返回的

而响应数据,是应用程序代码,执行一段逻辑之后,返回的

那么由于延时应答的存在,ack不一定立即返回,在ack稍等一会之后,正好就要返回响应数据

此时就在响应数据里面,tcp报头中ack这一位设置上,将确认序号以及窗口大小都设置上

这样的效果也是为了提升效率,将两次传输,合并成了一次

面向字节流

在字节流读写数据的场景中,就会涉及到一个比较关键的问题:粘包问题

那么当服务器调用read来读取请求,由于字节流的特点,读的时候,怎么读都行,一次可以读一个字节,也可以若干个字节

在这个场景中,服务器就无法分辨,从哪里到哪里是一个完整的单词

在实际上,此处粘包粘的就是应用层的数据包

主要是需要区分,从哪里到哪里是一个完整的应用层数据包,就需要我们明确包之间的界限

(1)使用分隔符

可以定义任意字符,只要字符在请求数据中不存在

(2)约定包的长度

就是类似于达到这样的效果,这样服务器就知道一次需要读多少长度的数据了

异常情况

(1)网络连接时,其中某一个进程崩溃了

实际上进程崩溃也好,正常结束也好,操作系统都能够回收对应的pcb,就可以释放里面的文件描述符表,此时也就相当于调用了close

此时人仍然会与对方进行正常的4次挥手操作

(2)某一个主机被关机(正常流程的关机)

对于这种正常流程的关机,操作系统会先尝试结束所有的用户进程,然后再进入关机流程

这个过程也会和第一种情况一样,进行4次挥手

但是与上面不同的是

第一种的4次挥手可以挥完,虽然进程不在,但是操作系统仍然管理这着tcp的连接,可以顺利的和对方挥手挥完

但是对于第二种,就可能挥完了.也可能挥不完

即这个掉电的主机A主动触发了fin,但是之后的流程还没走完,系统就关机了

此时B收到了fin之后,就会返回ACK,再返回fin

但是由于A已经关机,那么这个fin就会反复重传几次,还是没有ack,此时还是会把A给删了,至于A都关机了,自然就会将保存B的信息删掉

(3)某个主机电源掉电

假设A和B之间通信,突然之间A就掉电了(不能做出任何反应),但是此时B还以为A还存在

就会分成两种情况:

(a)B是数据发送方

那么接下来B发送的数据就都不会有ack了,就会触发超时重传,重传几次之后,还是没有响应,就会发送复位报文(RST),RST也没有响应,就会单方面删除保存的A的信息

(b)B是接收方

接收方,是无法知道对方啥时候给他发数据的

有时候当A沉默一会,B也不知道A是挂了还是暂时暂停一会

实际上,B在一定时间之内没收到A的数据之后,就会触发 "心跳包"

心跳的特点就是有周期,并且表示没有心跳就挂了

可以认为是一个没有载荷的数据报,只是为了触发对方的ACK

B给A发了一个心跳包,如果A响应了ACK,那么A就是正常的

如果A挂了,B不会收到任何回应

连续发了若干次后,A都没有响应,这时候B就认为 A挂了,就会单方面释放连接

实际上,虽然tcp里面内置了心跳包,但是这个心跳包的周期比较长,指望通过这个心跳发现对方挂了,往往需要分钟级别这样的时间

而在实际开发中,经常会实现应用层的心跳包,用更高频率,短周期(秒级/毫秒级别)的时去发送心跳包(ping - pong)

此时一旦某个设备挂了,就可以快速的发现问题

(4)网线断开

本质上就是第三种情况,A和B之间建立TCP连接,突然某一方网线断开了
感谢您的访问!!期待您的关注!!!

T04BF
🫵 今天记得敲代码