• TCP三次握手四次分手不一样的解释


    前言

    关于这个问题,网上有很多教程和博客,都大同小异。但我看了之后,并不认同。那些复杂的解释给我一种“看着答案推过程”的牵强感觉,经不住推敲。

    一,连接为什么是三次握手,而不是两次握手

    一次就不讨论了,连一个来回都没走,根本就验证不了两个方向的通路
    我的解释:不是三次握手,而是四次握手
    只不过是第二次和第三次 因为是同一个方向,合并了。所以呈现出三次的结果。
    目的就是:我问你答,你问我答,保证两个方向的“来回”都是通的。
    注意:是来回,也就4次。即便是同一个方向,也要双方都走一遍才算通。就像是一条简单的路,给路痴去走,他就可能走不通。
    在这里插入图片描述

    而按照网上那些猜疑链的复杂说法,那得“无数次”握手(大家仔细想想是不是)

    二,断开为什么是四次(断开和开启有什么区别)

    我的解释:逻辑上,连接是瞬时的,(服务器)断开是一段时间。
    为什么?有人就不认同了,如果说断开需要清理各种资源,那开启连接还需要创建各种资源的,时间上可能比断开还要更长呢。
    没错,连接确实可能比断开时间还要更长。但连接和断开有个逻辑上的区别:触发连接之后,无论是客户端还是服务端“都是活的”,两边有能力有时间处理任何异常。 但断开就不一样了,自己断开,就相当于“自行了断”。
    如果你想记录自己“自行了断”的全过程是,是不可能的。因为你没了,后面什么事也做不了了。保证开启,我们理论上有“无限大好时光”可以利用。但保证关闭,就得精心设计,来保证全程不会出现任何差池。
    所以从逻辑上说,
    开启:双方给个信号 提示一下,只要能确定路通了就行。
    关闭:双方(主要是复杂的服务端)必须要全程处于另一方的监控之下完成,而客户端很简单,不太需要另一个人监控完着成断开(两个人总有一个先挂,另一个人最后孤零零的走)。
    下面给一个时间分配图:
    在这里插入图片描述
    如果这一条长柱看成整个tcp的时间段的话,那么开启连接的过程就是那一条绿线,黄色的是大段的传输过程,蓝色是断开的过程。
    这里把“开启”和“连接”作为一个意思,是因为:所谓开启,就是连接上,就是把开启的信息告知对方,就是打个电话告诉对方,我接下来要干什么事了。所以“打电话”相对于全过程,可以抽象为“一个时间点”。tcp断开之前也是要先连接上,告知对方我要断开了。断开这段蓝色的时间,就是服务器分两次回应的时间段。

    下面说网上解释的不合理

    服务端接受到客户端端关闭消息之后,可能还还有数据要传输,所以先给个回应,确认没问题了 再次给个确认。

    那我就不明白了:你还有shi没拉完,刚才怎么不说,就不能在第一个回应里就一并说了,还非要分两步。
    而且大家有没有想过这个问题:客户端是什么时机选择的发送“断开连接”但请求的。它是脑子一热就跟服务器说拜拜?当然不是。就好像你拉shi拉一半,马桶突然告诉你 我要下班了,怎么可能。肯定是你说我拉完了,然后马桶才会给你发出准备关门的消息。在计算机世界里,能一步完成的事情,绝不会多此一举分成两步(通过消息长度判断,传输完成 是双方都已经知道的事情)。

    服务器之所以先给个回应,然后再给个回应。那是因为在这两个回应之间是服务器关闭资源的时间(关闭的时间也许比较长)。第二个回应之后,服务器彻底安全关闭。这个过程相当于全程被客户端监控着。
    反过来想想:如果服务器还没完全关闭,就给了回应,客户端就信了,然后也关门走人了。结果服务器没关上,客户端此时早已人去楼空,只剩下服务器这边孤立无援。
    但这种情况在开启的时候就不会出现:服务器如果没开启成功,但客户端就站在那里。哪怕它在发送数据的时候发现 其实服务器根本没开启成功。那又如何,再重新请求一次呗。反正人在这里就好,有问题都可以解决。一旦另一方人走了,那服务器就彻底凉凉。 这就我前面为什么说:开启可以抽象为“一个瞬时的点”(因为开启的过程,理论上可以融入传输数据的过程中),而关闭是一段时间,必须安全完整处理。

  • 相关阅读:
    【pytorch笔记】第一篇 环境搭建(Windows10)
    JavaWeb篇_07——Tomcat组件介绍
    排序算法之基数排序
    通用分页02
    vsphere 中 win虚拟机创建
    极智AI | 昇腾 CANN ATC 模型转换
    基于JavaSwing开发学生管理系统(登录增删改查)+论文报告 课程设计 大作业
    函数指针详解和简单使用
    python 学习积累
    PostgreSQL的学习心得和知识总结(八十五)|深入理解PostgreSQL数据库开源扩展pg_backtrace的使用场景和实现原理
  • 原文地址:https://blog.csdn.net/yunduanyou/article/details/126804942