文章目录
一、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超时异常]
2.1.1.1.1ACK有超时异常检测&可靠传输有重传的截止
2.1.1.2(心跳包补成全局检测)
2.2应用层
2.2.1主动判断
2.2.2调整尽成
2.2.3干预调改
2.1.2直接关闭
3.具体异常情况的判理过程(例)
3.1我方主机掉电
3.2我方延迟调用close
3.2.1危害
3.2.2判理
3.2.2.1传输层无能
3.2.2.2仅靠应用层
四、情况的判断处理
1.视角受限
1.1传输层的被动判断
1.2应用层的主动判断
2.异常的种类时机
2.1可能不定异常的范围种类
2.2可能不定异常的出现时机
3.处理法则
3.1无法判断,囊括处理的事与愿及(例)
3.1.1对方发送出现问题时
3.1.2仅剩收对方ACK时通信道路出现问题
3.1.3只是最后一个FIN没收到
3.1.4ACK传输延时的信息差
五、四次挥手的顺序与挥完
1.先后挥顺序
1.1先挥先断
1.2不同进序
2.挥不挥得完
2.1挥得完
2.1.1正常完整四次挥完的过程
2.2挥不完
一、TCP双向分流里的FIN
TCP连接是全双工的，一条连接里有：
- 2条发送分流:(每方发向另方流)*2，发送分流与接收分流是共同的一条,A的发送分流=B的接收分流、B的发送分流=A的接收分流
- 4个缓冲区:(每方接收+发送区)*2
发送分流的发送通道可以关闭，接收分流的接收通道永不关闭,只能划结尾
1.FIN信息
每一方的FIN都是排在本方所有发送数据末尾的最后一个序号的报文：
FIN从己方发送缓冲区发到发送分流时划发送结尾，传到对方接收缓冲区时在接收分流划接收结尾，此端的所有发送数据就是全部地到达对方了
1.1放置FIN
调用close放FIN到传输层的发送缓冲区后，
1.1.1处前预剩发
放FIN前已放的预剩发送数据,包括还在发送缓冲区未发与已经发在发送流中未达的数据，后面就是继续按TCP可靠机制传输的
1.1.2处后被遗漏
放FIN后,当时还放在应用层用户态缓冲区的数据,即使后面接着把它们放到发送缓冲区,也已经固定会排在FIN后了，就没划为此端的预剩发送数据：后面我方的发送通道关闭后才运到通道口前,就不能发出、就算发出去了,对方的接收通道关闭后,最多才送到通道口前,就不能收到，就是定为已被遗漏的数据了
1.2发送FIN
1.2.1剩余已发完
之前我方不想发数据了就调用close后,就造出FIN放在发送缓冲区,就划定了它前面的都是此端的预剩数据，把FIN前面的发送缓冲区剩余数据发到流完后,FIN也就发到了流里,就在发送分流末尾放置划出了结束标记,就关闭发送通道
1.2.2独立仍接收
仍然接收对方发送分流发来的数据,直到收到对方的FIN发送分流终点标记,也划接收结尾地收完了
1.3接收FIN
1.3.1现在已收完
接收缓冲区从接收分流收到FIN终点标记,就划出了接收分流的结尾,就知道传输层接收缓冲区已经收完了所有对方发来的数据了，后面应用层往传输层的接收缓冲区取完,到FIN终点标记后再取,应用层就会得到EOF,就知道取完了接收缓冲区
1.3.2独立仍在发
没想结束发送而调用close前,发送缓冲区就不放FIN也没划预剩数据,发送通道就会一直开着，等到后面自己不想发了调用close再放FIN划了预剩数据，发完发送缓冲区的FIN剩余数据,才关闭了发送通道
二、数据的需求与TCB的服务
1.数据需求TCB的发收服务
每端所有发送数据即单FIN,到达对方前 需要 本端+对端的双TCB分别的发送,接收的服务：
1.1需本端TCB可靠发送
发送FIN,就把发送缓冲区里的预剩数据全部发到流上了,随即关闭发送流的发送通道，还在发送分流上还未到达对方接收缓冲区的路上所有剩余的发送数据，需要 我方的TCB开着保持发送服务,继续一路重传保证它们的可靠传输,直到全部传到对方、
1.2需对端TCB持续接收
需要 对方的TCB开着保持接收服务,持续到我方的发送数据所有都接收完为止
2.TCB服务数据的发收到达
每端TCB要服务 本端+对端的所有发送数据即双FIN分别的发送,接收的到达：
服务 我方所有数据即FIN到达对方的可靠发送+对方所有数据即FIN到达我方的状态接收
2.1正常完成
- 收到FIN报文，就是确认收完对方所有发送数据的标志
- 收到FIN的ACK报文，就是确认对方收完我方所有发送数据的标志
收到一FIN与另FIN的ACK，就是确认双FIN到达 完成服务
2.2异常续/断
超时收不到ACK判断有异常后，靠应用层的调整上限与传输层的关闭下限 继续/中断服务
3.数据需求与到达服务之间的关系
- 一个TCB完成一向数据的单个发送/接收到达服务<->
- 同时另个TCB的此向数据对应的接收/发送服务也完成了<->
- 同时此向数据的发送与接收需求都已完成了
三、TCB对关闭的判断处理
1.正常关闭判理
连续正常限时内地收完 对方发送数据与我方发送数据的ACK回复，就能被动判断双向数据都已无需求,已到达服务完，就能确定不漏数据的需求&到达服务 地关闭此方的TCB
2.异常关闭判理
2.1传输层
2.1.1被动判断
阶段里有超时没收到 发送数据(没实际数据发也有固定的心跳报文保障有发)的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