当前位置: 首页 > news >正文

一文大白话讲清楚TCP连接的三次握手和断开连接的四次挥手的原理

文章目录

  • 一文大白话讲清楚TCP连接的三次握手和断开连接的四次挥手的原理
  • 1.TCP建立连接需要3次握手
    • 1.1 先讲个你兄弟的故事
    • 1.2 TCP 3次握手
    • 1.2 TCP 3次握手8件事
    • 1.3 TCP握手能不能是两次
  • 2. TCP 断开连接要4次挥手
    • 2.1 还回到你兄弟的故事上
    • 2.2 TCP 4次挥手
    • 2.2 TCP4次挥手4件事
    • 2.3 TIME_WAIT的作用是啥,为什么不能直接进入CLOSED状态
    • 2.4 为什么TIME_WAIT要过2MSL才能进入CLOSEd状态
    • 2.5 tcp连接管理中的保活机制

一文大白话讲清楚TCP连接的三次握手和断开连接的四次挥手的原理

  • TCP是面向连接的协议,在传输前必须要知道接收方存在还是不存在,所以在传输数据前后要经过3次握手和4次挥手

1.TCP建立连接需要3次握手

1.1 先讲个你兄弟的故事

  • 先来个场景大白话讲一下
  • 你有一块些黄金,要卖给你的好兄弟,然后你的好兄弟收到黄金后把现金寄给你。但因为太贵重了,你们不知道对方在不在家,能不能收到
  • 所以在寄快递前,你两确认了一下
  • 第一步,你给你的好兄弟先接了一封信,问问他在不在家(这时候信寄出去以后,你处于等对方的回信)
  • 第二步,你的好兄弟给你回了一封信,告诉你他在家,但这个时候他不知道你已经知道他在家(他把信寄给你了,你处于等待回信的状态)
  • 第三步,所以你又给你的好兄弟协议了一封信,告诉他,我收到你的信了,我知道你在家了,你准备好接收。(这时候你知道他在家了,他也知道你知道他在家了)
  • 第四步,那既然都知道,就寄黄金呗。
  • 这样一来一回,你们一共发了三封信,目的就是为了明确对方在不在,要干啥。这就是TCP的两个主机之间的三次握手。只不过你是寄黄金,TCP是发数据

1.2 TCP 3次握手

  • 讲了上面的故事,相信大家应该明白了,接下来讲细节,就是我怎么寄的信,信里面有什么,你怎么回的信,信里面有什么
  1. 第一次握手,客户端给服务端发一个SYN(Synchronize Sequence Numbers:同步序列编号),并指明客户端的初始序列号ISN(Initial Sequence Number:初始序列号),此时客户端处于SYN_SENT状态
  2. 第二握手:服务器收到客户端的SYN报文后,会将自己的SYN报文发送给客户端,同时为了确认客户端的SYN,将客户端的ISN+1作为ACK(Acknowledgment character:确认字符)的值发送给客户端,此时服务端处于SYN_RCVD状态
  3. 客户端收到服务端的SYN报文后,会发送一个ACK报文,ACK的值为服务器的ISN+1.此时客户端处于ESTABLISHED状态。服务端收到ACK报文之后,也处于ESTABLISHED状态。此时,双方建立了链接
  • 上图

在这里插入图片描述

1.2 TCP 3次握手8件事

  • 说白了,如果要进行通讯,服务端要知道:自己和客户端的发送和接收能力正常;客户端要知道自己和服务端的发送和接收能力正常
  • 也就是要确定下列几件事
  1. 客户端知道自己发送能力正常
  2. 客户端知道自己接受能力正常
  3. 客户端知道服务器发送能力正常
  4. 客户端知道服务器接收能力正常
  5. 服务器知道自己发送能力正常
  6. 服务器知道自己接受能力正常
  7. 服务器知道客户端发送能力正常
  8. 服务器知道客户端接接收能力正常
  • 也就是说,通过三次握手,我们要确定这8件事
  • 那么接下来看看每次握手的作用和完成的事情
  • 一. 第一次握手,客户端发送数据包,服务端收到了;
    • 得到的结论:服务端知道客户端的发送能力正常,即7完成,服务端知道自己的接收能力正常,即6完成(67)
  • 二. 第二次握手,服务端发送数据包,客户端收到了
    • 得到的结论:在第一次握手结论的基础上,客户端知道服务端的发送能力正常,即3完成,客户端知道服务端的接收能力正常,即4完成,客户端知道客户端的接收能力正常,即2完成;客户端知道自己的发送能力正常,即1完成(123467)
  • 三. 第三次握手,客户端发送网络数据包,服务端收到了
    • 得到的结论:在第二次结论的基础上,服务端知道自己的发送能力正常,即5完成,服务端知道客户端的接收能力正常,即8完成(12345678)
      通过3次握手,确定了8件事,即确定了双方的发送和接受能力,而且确定了对方知道彼此的接收和发送能力正常;
  • 那就可以开始传输数据了

1.3 TCP握手能不能是两次

  • 通过上面的8件事我们知道,如果少一次握手,哪个第五件事和第8件事,也就是服务端无法确定客户端的接受能力正常,服务端也无法确定自己的发送能力正常。那就有可能, 服务端认为自己发了,但是客户端收不到。

2. TCP 断开连接要4次挥手

2.1 还回到你兄弟的故事上

  • 通过上面TCP连接后,你两现在一个可以把黄金一批批的寄过去了,另一个可以一批一批地把现金寄过来了。但问题是,你这边黄金总有寄完的时候吧。如果寄完了,你是不是得告诉你兄弟一声,让他知道,然后他也把剩下的钱寄给你。寄给你以后,你两两清了,就不用再来回邮寄了。
  • 那这时候咱们分析一下
  • 第一步,你这边黄金发完了,没得发了。所以你给你兄弟写了一封信,好兄弟,以后没黄金了,咱两可以不用再联系了。
  • 第二步,你兄弟收到你的来信了,知道你没黄金了,以后也不寄了,但是还差最后一批黄金的钱没给你。于是你兄弟干了两件事。先是给你回了一封信,好的兄弟我知道了。但是还有一笔没给你结,稍后我给你寄过来。如果你收到这边钱了,给我说一声。咱两就断联。于是第一件事,信寄出去了。接着第二件事,把钱寄出去
  • 第三步,你收到你兄弟最后一笔寄来的钱了,给他写信说,好兄弟我收到钱了,咱们断联。
  • 这时,如果你兄弟收到钱了,就知道你两车企两清了,不用来回邮寄了。
  • 这样一来一回,你发两封信,你兄弟发两封信,一共4封信,目的就是清算,挥手告别。所以这就是TCP的4次挥手断连

2.2 TCP 4次挥手

  • 讲了上面的故事,接下来讲细节,看看写信的时候都具体说了啥
  1. 第一次挥手:客户端发送一个FIN报文,报文中指定一个序列号。此时客户端处于FIN_WAIT1状态,就是停止发送,等待服务端确认
  2. 第二次挥手,服务端收到FIN报文后,会发送ACK报文,且把客户端的序列号+1作为ACK报文的序列号,表明已经收到客户端的报文了,此时服务端处于CLOSE_WAIT状态
  3. 第三次挥手:如果服务端发送完数据了,也会发给客户端一个FIN报文,且制定一个序列号,此时服务端处于LAST_ACK状态
  4. 第四次挥手,客户端收到FIN之后,一样发送一个ACK报文,并把服务端的序列号+1作为序列号,此时客户端处于TIME_WAIT状态、需要过一整子,确保服务端收到自己的ACK报文后才会进入CLOSED状态,服务端收到ACK报文后,就处于关闭连接,进入CLOSEd状态
  • 上图
    在这里插入图片描述

2.2 TCP4次挥手4件事

  • 说白了,告别就是在数据发完的前提下,互相知道不再发送,所以需要干完这4件事
  1. 客户端知道自己不再发送请求了
  2. 客户端知道服务器不再发送数据了
  3. 服务端知道客户端不再发送请求了
  4. 服务端知道自己不再发送数据了
  • 那么接下来看4次挥手怎么完成的这些事
  • 一,第一次挥手,客户端告诉服务器,我不在发送请求了
    • 得出结论:客户端知道自己不再发送请求了,即1完成;服务端知道客户端不再发送请求了,即3完成(13)
  • 二,第二次挥手,服务器告诉客户端,我知道你不再发送请求了,但是我可能还有数据要,等我也不发了,我再另外给你通知
    • 得出结论,客户端知道服务端知道客户端不再发送请求了
  • 三,第三次挥手,服务器告诉客户端,我不再发送数据了
    • 得出结论,客户端知道服务端不再发送数据了,即2完成;服务端知道自己不再发送数据了,即4完成(1234)
  • 四,第四次挥手,客户端告诉服务端,我收到你不再发送消息的通知了,我等你差不多收到消息(2MSL后)我就关闭了
    • 得出结论,大家都可以关闭了
  • OK,咱们断连,不再发送数据了

2.3 TIME_WAIT的作用是啥,为什么不能直接进入CLOSED状态

  • 如果没有TIME_WAIT,状态,则服务器的FIN包没有得到最后的ack确认,超时后会重传。这样会下次的新链接产生影响,可能会刚打开就收到一个重传的包,或者客户端相同的服务端发送SKY连接请求但服务器处于LAST_ACK状态,要求收到的是ack而不是SYN,因此会发送RST重新建立请求

2.4 为什么TIME_WAIT要过2MSL才能进入CLOSEd状态

  • 首先MSL是指网络中最大生存时间。
  • 为什么要等2MSL,是因为客户端发送了对服务端的FIN确认包ASK后,不能确保ACK被接收到。如果接收不到,服务器端如果接收不到ACK包就会重新发送FIN包,所以客户端发送后等2MSL的时间,如果这个时间内没有收到重新的FIN包,说明收到了,那可以关闭了。

2.5 tcp连接管理中的保活机制

  • TCP通信中,如果双方长时间没有数据往来,服务器会周期性向客户端发送探测数据报,要求客户端回复,如果连续多次没有收到响应,救人位连接已经断开。
  • 周期为75s,如果连续超过9次,则认为断开
  • 长时间未发送数据值得是超过7200s
http://www.lryc.cn/news/515346.html

相关文章:

  • CSS——1.优缺点
  • TIM——编码器测速
  • 抢先体验:人大金仓数据库管理系统KingbaseES V9 最新版本 CentOS 7.9 部署体验
  • 供应链系统设计-供应链中台系统设计(七)- 商品中心设计篇
  • Power BI如何连接Azure Databricks数据源?
  • 【HarmonyOS】鸿蒙应用如何进行页面横竖屏切换以及注意事项,自动切换横竖屏,监听横竖屏
  • 编译 C++ 程序:分离与保留调试信息以支持 GDB 对 Core 文件的调试
  • 009:传统计算机视觉之边缘检测
  • JAVA创建绘图板JAVA构建主窗口鼠标拖动来绘制线条
  • 机器人对物体重定向操作的发展简述
  • 自动驾驶三维重建
  • 30分钟学会css
  • vue路由模式面试题
  • Python 开发框架搭建简单博客系统:代码实践与应用
  • 如何在 VSCode 中配置 C++ 开发环境:详细教程
  • 三甲医院等级评审八维数据分析应用(一)--组织、制度、管理可视化篇
  • 2024 年度总结|勇敢去探索~
  • 2024年, Milvus 社区的那些事
  • vue代理问题
  • Git快速入门(三)·远程仓库GitHub以及Gitee的使用
  • [开源]C++代码分享
  • CSS3——3. 书写格式二
  • PHP语言的计算机基础
  • 第 23 章 JSON
  • Java 正则表达式入门与应用(详细版)
  • 洛谷:P1540 [NOIP2010 提高组] 机器翻译
  • 基于AT89C51单片机的可暂停八路抢答器设计
  • 面试题解,Java中的“对象”剖析
  • 行为模式3.迭代器模式
  • 第8章 DMA控制器