文章目录一、TCP双向分流里的FIN1.FIN信息1.1放置FIN1.1.1处前预剩发1.1.2处后被遗漏1.2发送FIN1.2.1剩余已发完1.2.2独立仍接收1.3接收FIN1.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我方延迟调用close3.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双向分流里的FINTCP连接是全双工的一条连接里有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发送FIN1.2.1剩余已发完之前我方不想发数据了就调用close后,就造出FIN放在发送缓冲区,就划定了它前面的都是此端的预剩数据把FIN前面的发送缓冲区剩余数据发到流完后,FIN也就发到了流里,就在发送分流末尾放置划出了结束标记,就关闭发送通道1.2.2独立仍接收仍然接收对方发送分流发来的数据,直到收到对方的FIN发送分流终点标记,也划接收结尾地收完了1.3接收FIN1.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回复就能被动判断双向数据都已无需求,已到达服务完就能确定不漏数据的需求到达服务 地关闭此方的TCB2.异常关闭判理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]我方的传输层在尽成服务完后再异常关闭TCB3.2我方延迟调用close3.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送达,正常关闭TCB2.挥不挥得完关闭TCB释放连接状态有两种方式2.1挥得完正常,有序用FIN关闭完整四次地挥完手每方都是 有作FIN划定好预剩发送数据、确认双向数据都已无对已方TCB需求、确认双向数据FIN都已到达对方,完成己方TCB服务地 正常关闭TCB2.1.1正常完整四次挥完的过程能不超时收ACK异常地完整四次挥完,两端正常地关闭TCB,释放连接状态的过程AESTABLISHEDBESTABLISHEDclose()↓FIN1发到流----------------FIN_WAIT_1我端的预剩发送数据已经全部发到流里了我也就把我这端发送分流的发送通道关闭了收到FIN1确认到对方的所有发送数据全部到达我方也就给接收分流划上了接收结尾----------------回ACK1CLOSE_WAIT我端可能还没调用close,FIN2可能还没做也就还没划预剩发送数据,或者已做划了预剩发送数据,但在发送缓冲区里没发完现在就没关发送通道地,继续从发送缓冲区源放数据到发送分流头,没断头地发送数据收到ACK1FIN_WAIT2确认到我方的FIN1到达对方,我端的所有发送数据全部到达对方B应用层什么时候决定关闭close()↓----------------FIN2发到流LAST_ACK我端的所有发送数据也已经全部发到发送分流里了我也把我这端发送分流的发送通道关闭了收到FIN2回ACK2-------------------------TIME_WAIT收到FIN2确认到对方的所有发送数据全部到达我方也就给接收分流划上了接收结尾【到此时我方就确认到 双FIN都已到达,双方的所有发送数据都全部到达对方就确定双向数据都已无对本端TCB需求、双向数据全已到达,完成了本端TCB的服务 地正常关闭本端的TCB】等待2MSL↓CLOSED收到ACK2确认到我方的FIN2到达对方,我端的所有发送数据全部到达对方【到此时我方就确认到 双FIN都已到达,双方的所有发送数据都全部到达对方就确定双向数据都已无对本端TCB需求、双向数据全已到达,完成了本端TCB的服务 地正常关闭本端的TCB】↓CLOSED2.2挥不完异常,立即用RST中止超时ACK四次挥手无法挥完的至少有一方判断有异常,它的应用层与传输层调整无果,尽力服务完后无法判断全,它管的 双向数据对它的需求、双向数据是否已到达,它的服务是否完成 地结束TCB服务,异常关闭TCB