双向分流FIN标记、TCB服务逻辑与TCP断开连接流程介绍

阶段里有超时没收到发送数据 (没实际数据发也有固定的心跳报文保障有发)的ACK回复 $阶段里超时收不到发送数据,可能是对方主动发数据选择暂时歇会了,不能被动判断为异常,但也可以应用层干预写成如果超时太久而主动判断为异常;但是ACK是对方被动收到数据后得立即回的,如果阶段里超时收不到ACK,那就能被动判断为异常$ ，++就被动判断出现了异常,并通常只能判排在范围中++

2.1.1.1 $只检ACK超时异常$

默认的传输层TCB对每阶段的发送数据没有超时的时间限制，只对每阶段的接收ACK数据有超时的时间限制,超时等待收不到后就关闭TCB

（对比：发送分流的发送通道可以关闭，接收分流的接收通道永不关闭,只能划结尾）

2.1.1.1.1ACK有超时异常检测&可靠传输有重传的截止

收到我方FIN的ACK前

对方即使收到了我方的FIN：知道我方的发送数据发完,发送通道关闭了、他收完了我方的发送数据,他划出了我方发送分流的接收结尾，
但是在我方收到,确认FIN送到对方的ACK前：还是一直认为对方的接收通道没有划结尾,仍在接收数据，就还在进行：

对发送了的数据,计时等收,对方接收后会被动返ACK,多次超时重传还收不到,而判断有异常的检测，把就算对方能收到FIN后,也可能存在的,返回ACK时出现的对方发送/我方接收/通信道路也纳入检测，使得ACK异常检测全程完整
仍在进行,我方没收到ACK的发送数据的重传，即使对方已经收到FIN,收完我方所有的发送数据,划了接收通道结尾,只是ACK返回丢失,我方事实过头的数据重传造成了重复浪费，但是过头地就能保障到,我方发送数据的到达完整

2.1.1.2(心跳包补成全局检测)

如果是我方发送出现异常或我方无实际数据要发时，心跳包的固定会发送让这段时间也是正常的,在计时收ACK,依旧能通过收ACK判断是否有异常

2.2应用层

应用层用自己写的，

2.2.1主动判断

能否主动测查出其一异常并修复
能否主动判断出双向数据还有无需求,都已无到达服务完地

2.2.2调整尽成

在本应用层,调整扶持继续服务或尽力完成结束服务

2.2.3干预调改

往下传输层,干预调改TCB的应对处理，比如：

异常已测查出并修复，TCB就继续服务不去关闭了
异常无法解决要关闭TCB时，让TCB在应用层尽成服务完,它管的数据需求与到达服务后,再关闭
让TCB超时等待收不到ACK而关闭的时间,按实际情况与性能需求缩短一点
覆盖用应用层自己实现快周期发的心跳包,选择用更频繁的报文消耗量换取更短时间的等待判断性能

2.1.2直接关闭

传输层默认已写用不管知不知道,不管还有无漏数据到达&需求都直接关闭TCB
（可被应用层干预地调改成其它的处理）

3.具体异常情况的判理过程(例)

3.1我方主机掉电

(1)我方的传输层，没有被动判断异常
(2)我方的应用层，没有主动测查异常与判断数据的需求&到达服务、没有调整与尽成地服务被中断、没有向下干预调改 TCB的处理
(3)我方的传输层，TCB中断地被关

$1$ 对方的传输层，超时收不到ACK,被动判断出有异常
$2$ 对方的应用层，主动测查异常与判断数据的需求&到达服务、调整无果后尽成地结束服务、向下干预调改TCB的处理
$3$ 我方的传输层，在尽成服务完后再异常关闭TCB

3.2我方延迟调用close

3.2.1危害

调用close异常或忘记调用close 而延迟的时间，

会使本方多开了一段,无发数据的发送通道开启,浪费一段TCB的发送干耗维护
会使对方多开一段,无收数据的接收通道开启,浪费一段TCB的接收干耗维护

3.2.2判理

延迟的这段时间里，

3.2.2.1传输层无能

我方：
传输层对每阶段发送数据(调用close发送FIN数据),本身没有超时限制,不能被动检出异常；
不管对方是否已发FIN发送通道关闭、FIN是否传到我方使我方划出接收结尾、收到我方返回的ACK而结束ACK超时异常的检测，我方始终还未发送FIN关闭发送通道、对方始终是还没收到我方还未发的FIN,接收通道就仍没划结尾地在收、我方也还没收到自己还未发的FIN的ACK而结束ACK的异常检测，因此我方还有数据发送过去,对方也还有收地会返ACK回来，所以如果只是我方调用close出现异常,我方无法触发ACK超时判断到有异常

对方：
即使在对方FIN还没发,对方发送通道没关、我方没收FIN没划接收通道、我方没返ACK,对方没收ACK而还有超时ACK的异常检测前，对方发送数据过来,我方接收通道还没划结尾,收了就会返ACK，所以ACK无法超时而检测出,只是我方调用close的异常，一直到后面对方发了FIN并收到返回的ACK,结束超时ACK的异常检测

3.2.2.2仅靠应用层

所以close异常延迟的这段时间里，对方与我方的传输层都无法被动判断出有异常，而双方干耗着维护这段延迟时间内的TCB，会累积这段延迟时间的CLOSED_WAIT，此时就靠双方的应用层写有的,观察到大量CLOSED_WAIT而主动测查出,有调用close延迟的异常

四、情况的判断处理

1.视角受限

每方处在相比上帝全局视角下的单方受限且不同视角下，每一方判断的数据需求与到达服务 ++与事实、与对方 是独立的,且能差异在无法判断++：

全局视角下，在双向FIN到达前的TCB关闭,都是异常关闭的；
单方视角下，没有判断确认到双向FIN到达而视为的异常关闭，实际上可能双向FIN已到达的正常关闭

1.1传输层的被动判断

传输层原生已写好的被动判断，异常的判排范围小、判排出有异常后,在传输层是设计成保底的,直接去关闭TCB的,没去写数据需求与到达服务的判断(交给在应用层进一步处理写了)

1.2应用层的主动判断

应用层自己增去写的主动判断，扩增有测查异常的判排范围、增有查用当现情况地判断,数据需求与到达服务

2.异常的种类时机

2.1可能不定异常的范围种类

收不到ACK的异常，不定的范围种类可以是：

对方发送出现问题
对方接收出现问题
我方发送出现问题
我方接收出现问题
通信道路出现问题

2.2可能不定异常的出现时机

收不到ACK的异常，不定的出现时机可以在：

完成哪个方向数据需求的前
完成哪个方向数据需求的后
完成哪个方向数据到达的前
完成哪个方向数据到达的后
完成哪个TCB服务的前
完成哪个TCB服务的后

3.处理法则

来自我方,环境,对方的，能判断到精确情况的就针对处理，仅判断到范围情况的就囊括处理

3.1无法判断,囊括处理的事与愿及(例)

3.1.1对方发送出现问题时

如果是对方发送出现问题,接收没有问题，我方收不到ACK判断异常,也无法修复，就尽成把我方TCB的所有要发送数据与RST报文发完后,再异常关闭TCB：

我方可以判断确认对方的发送数据没有全到达我方,我方TCB没有完成接收到达服务、对方的发送数据还有发送与接收需求
虽然我方无法判断确认我方的发送数据是否全部已经到达,我方TCB是否完成发送到达服务、我方的发送数据是否还有发送与接收需求

但是如果出在对方发送出题问题的这种异常情况下,囊括处理后的事实是我方的所有发送数据与RST报文都已到达了对方,我方TCB完成了发送到达服务、我方的发送数据都已无发送与接收需求，这样我方的TCB的异常关闭,其中它管的也就只漏掉了对方发送数据的接收需求与接收到达服务

3.1.2仅剩收对方ACK时通信道路出现问题

如果在对方已经发完它方的所有发送数据并收完它们的ACK、收完我方所有的发送数据后,返回ACK时，通信道路此时出现异常，对方会已完成双FIN送达地正常关闭它的TCB，我方收不到ACK判断异常：

我方里面可以判断确认对方的发送数据已全部到达我方,我方TCB完成了接收到达服务、对方的发送数据已无发送与接收需求(我方返回的ACK是不知道对方有没有收到,而无法知道在对方的视角下的对方的发送数据是否还有发送需求，但那是在对方视角里的判断,与我方视角里的对方发送数据已无发送需求的判断是无关独立的)
我方无法判断确认我方的发送数据是否已全部送达对方,我方TCB是否完成发送到达服务、我方的发送数据是否还有发送与接收需求地异常关闭TCB

但如果是在对方收完所有数据返回ACK时出现的异常，囊括处理后的事实是我方的所有发送数据都已全部送达,我方TCB也完成发送到达服务、我方的发送数据也都已无发送与接收需求，这样无法判断确认的看似异常的TCB关闭,实则上可能也是完成双FIN的正常关闭

3.1.3只是最后一个FIN没收到

如果我方收对方发送数据就只是最后一个FIN没收到，然后发送的数据出现超时ACK,传输层被动判断有异常：
应用层主动判断数据需求与到达服务时，对于里面的对方发送数据,可以自己灵活写的主动判断为此时对方所有的发送数据都已到达,我方TCB完成了接收到达服务and对方TCB完成了发送到达服务、对方发送数据已无发送与接收需求的实际事实

3.1.4ACK传输延时的信息差

我方发送FIN,一直到收到它的ACK前，都无法判断确认对方的接收通道是否已经关闭，而事实是在我方发送的FIN到达对方时,对方的接收通道就已经关闭了，还需要到后面ACK传输返回到时,我方才已知道

五、四次挥手的顺序与挥完

1.先后挥顺序

1.1先挥先断

双方的close可以互不关联地按各自节奏发，先挥方的定义是FIN先达对方者为FIN1(先发FIN2的可能后到达对方,后发FIN1的可能先到达对方),会先完成单断：

1、如果对方的FIN2较返回的ACK1先到达我方：

那么我方会先收到对方的FIN2，最后等的是先到达对方FIN1的ACK1
与此同时后挥方会先收到更早到的FIN1，最后等的是后到达我方FIN2的ACK2

所以相比后挥方最后收ACK2，先挥方会更早收到最后ACK1，先完成单挥

2、如果对方的FIN2较返回的ACK1后到达我方(通常就是Socket.hasNext嵌套Socket.close判断条件写法下,必须先收FIN1先返ACK1后,再进入判断里去执行close后发FIN2,导致的)：

那么我方会先收到先到达对方FIN1的ACK1，最后等的是后到达我方的FIN2
与此同时后挥方会先收到更早到的FIN1，最后等的是后到达我方FIN2的ACK2

所以先挥方会先收到最后的FIN2,先完成单挥，接着后挥方再收到最后的,先挥方最后收到FIN2后返回的ACK2,后完成单挥

1.2不同进序

四次挥手双方有先有后地参与进流程,双方展开的报文收发顺序会不同，导致：

先挥者在收到对方FIN后,确认到双FIN送达,正常关闭TCB
后挥者在收到回复ACK后,确认到双FIN送达,正常关闭TCB

2.挥不挥得完

关闭TCB释放连接状态有两种方式：

2.1挥得完

正常,有序用FIN关闭：
完整四次地挥完手，每方都是有作FIN划定好预剩发送数据、确认双向数据都已无对已方TCB需求、确认双向数据FIN都已到达对方,完成己方TCB服务地正常关闭TCB

2.1.1正常完整四次挥完的过程

能不超时收ACK异常地完整四次挥完,两端正常地关闭TCB,释放连接状态的过程

A
ESTABLISHED

B
ESTABLISHED

close()
↓
FIN1发到流---------------->

FIN_WAIT_1：我端的预剩发送数据已经全部发到流里了，我也就把我这端发送分流的发送通道关闭了

收到FIN1，确认到对方的所有发送数据全部到达我方，也就给接收分流划上了接收结尾
<----------------回ACK1

CLOSE_WAIT：我端可能还没调用close,FIN2可能还没做也就还没划预剩发送数据,或者已做划了预剩发送数据,但在发送缓冲区里没发完，现在就没关发送通道地,继续从发送缓冲区源放数据到发送分流头,没断头地发送数据

收到ACK1
FIN_WAIT2：确认到我方的FIN1到达对方,我端的所有发送数据全部到达对方

B应用层什么时候决定关闭close()
↓
<----------------FIN2发到流
LAST_ACK：我端的所有发送数据也已经全部发到发送分流里了，我也把我这端发送分流的发送通道关闭了

收到FIN2
回ACK2------------------------->
TIME_WAIT：收到FIN2，确认到对方的所有发送数据全部到达我方，也就给接收分流划上了接收结尾

【到此时我方就确认到双FIN都已到达,双方的所有发送数据都全部到达对方，就确定双向数据都已无对本端TCB需求、双向数据全已到达,完成了本端TCB的服务地正常关闭本端的TCB】

等待2MSL
↓
CLOSED

收到ACK2，确认到我方的FIN2到达对方,我端的所有发送数据全部到达对方

【到此时我方就确认到双FIN都已到达,双方的所有发送数据都全部到达对方，就确定双向数据都已无对本端TCB需求、双向数据全已到达,完成了本端TCB的服务地正常关闭本端的TCB】
↓
CLOSED

2.2挥不完

异常,立即用RST中止：
超时ACK四次挥手无法挥完的，至少有一方判断有异常,它的应用层与传输层调整无果,尽力服务完后，无法判断全,它管的双向数据对它的需求、双向数据是否已到达,它的服务是否完成地结束TCB服务,异常关闭TCB

双向分流FIN标记、TCB服务逻辑与TCP断开连接流程介绍

一、TCP双向分流里的FIN

1.FIN信息

1.1放置FIN

1.1.1处前预剩发

1.1.2处后被遗漏

1.2发送FIN

1.2.1剩余已发完

1.2.2独立仍接收

1.3接收FIN

1.3.1现在已收完

1.3.2独立仍在发

二、数据的需求与TCB的服务

1.数据需求TCB的发收服务

1.1需本端TCB可靠发送

1.2需对端TCB持续接收

2.TCB服务数据的发收到达

2.1正常完成

2.2异常续/断

3.数据需求与到达服务之间的关系

三、TCB对关闭的判断处理

1.正常关闭判理

2.异常关闭判理

2.1传输层

2.1.1被动判断

2.1.1.1只检ACK超时异常