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

通俗易懂理解三次握手、四次挥手(TCP)

文章目录

  • 1、通俗语言理解
    • 1.1 三次握手
    • 1.2 四次挥手
  • 2、进一步理解三次握手和四次挥手
    • 2.1 三次握手
    • 2.2 四次挥手

1、通俗语言理解

1.1 三次握手

C:客户端 S:服务器端

第一次握手:
C:在吗?我要和你建立连接。

第二次握手:
S:在的呢!来吧,确定要连接吗?

第三次握手:
C:非常确定!咱们建立连接吧。

为什么要三次握手?好麻烦!两次握手不就可以了吗?我想知道为什么。

:如果是;两次握手,S告诉C你来吧,同时S就打开了一个连接,这个时候如果C已经挂了,那S一直等C同时还开启了一个连接。
就像你和你朋友约会,你给他准备了一个惊喜,但是他却没来。

1.2 四次挥手

C:客户端 S:服务器端

第一次挥手:
C:我的数据已经传完了,我想和你断开连接。

第二次挥手:
S:好的,我知道了,但是我这边还有数据给你,你先不要和我断开。

第三次挥手:
S:我的数据已经传送完了,你可以和我断开连接了!

第四次挥手:
C:我已经收到你的让我断开连接的信息了,可以断开了。

为什么要四次挥手?好麻烦!三次挥手不就可以了吗?我想知道为什么。

:当S端收到断开连接的信息时,S端可能还有数据要乡C端发送,使用确认状态(ACK)和结束状态(FIN)要分开发送


2、进一步理解三次握手和四次挥手

2.1 三次握手

首先很多人会先讲下握手的过程:

1、第一次握手:客户端给服务器发送一个 SYN 报文。

2、第二次握手:服务器收到 SYN 报文之后,会应答一个 SYN+ACK 报文。

3、第三次握手:客户端收到 SYN+ACK 报文之后,会回应一个 ACK 报文。

4、服务器收到 ACK 报文之后,三次握手建立完成。

作用是为了确认双方的接收与发送能力是否正常。

这里解释一下为啥只有三次握手才能确认双方的接受与发送能力是否正常,而两次却不可以:

  • 第一次握手:客户端发送网络包,服务端收到了。这样服务端就能得出结论:客户端的发送能力、服务端的接收能力是正常的
  • 第二次握手:服务端发包,客户端收到了。这样客户端就能得出结论:服务端的接收、发送能力,客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常
  • 第三次握手:客户端发包,服务端收到了。这样服务端就能得出结论:客户端的接收、发送能力正常,服务器自己的发送、接收能力也正常

因此,需要三次握手才能确认双方的接收与发送能力是否正常。

这个过程的我们应该要描述的更详细一点,因为三次握手的过程中,双方是由很多状态的改变的,而这些状态,也是面试官可能会问的点。所以我觉得在回答三次握手的时候,我们应该要描述的详细一点,而且描述的详细一点意味着可以扯久一点。加分的描述我觉得应该是这样:

刚开始客户端处于 closed 的状态,服务端处于 listen 状态。然后

  • 1、第一次握手:客户端给服务端发一个 SYN 报文,并指明客户端的初始化序列号 ISN(c)。此时客户端处于 SYN_Send 状态。

  • 2、第二次握手:服务器收到客户端的 SYN 报文之后,会以自己的 SYN 报文作为应答,并且也是指定了自己的初始化序列号 ISN(s),同时会把客户端的 ISN + 1 作为 ACK 的值,表示自己已经收到了客户端的 SYN,此时服务器处于 SYN_REVD 的状态。

  • 3、第三次握手:客户端收到 SYN 报文之后,会发送一个 ACK 报文,当然,也是一样把服务器的 ISN + 1 作为 ACK 的值,表示已经收到了服务端的 SYN 报文,此时客户端处于 establised 状态。

  • 4、服务器收到 ACK 报文之后,也处于 establised 状态,此时,双方以建立起了链接。

模型参考1
在这里插入图片描述
模型参考2
在这里插入图片描述

提示:

  • (1) SYN=1 表示该报文不携带数据,但消耗一个序号 seq=x,seq=x是客户端的初始化序列号,因为tcp是面向字节流的
  • (2) SYN=1 表示该报文不携带数据,但消耗一个序号 seq=y,seq=y是服务器的初始化序列号,ACK=1是一个确认号
    ack=x+1,表示服务器下次接收到的序号希望是x+1。然后服务器进入到SYN-RCVD等待的状态
  • (3) ACK=1是一个确认号,seq=x+1是上一次服务器回应的序号要求,ack=y+1表示客户下一次接收到的序号希望是y+1

2.2 四次挥手

  • 1、第一次挥手:客户端发送一个 FIN 报文,报文中会指定一个序列号。此时客户端处于FIN_WAIT1状态。

  • 2、第二次握手:服务端收到 FIN 之后,会发送 ACK 报文,且把客户端的序列号值 + 1 作为 ACK 报文的序列号值,表明已经收到客户端的报文了,此时服务端处于 CLOSE_WAIT状态。

  • 3、第三次挥手:如果服务端也想断开连接了,和客户端的第一次挥手一样,发给 FIN 报文,且指定一个序列号。此时服务端处于 LAST_ACK 的状态。

  • 4、第四次挥手:客户端收到 FIN 之后,一样发送一个 ACK 报文作为应答,且把服务端的序列号值 + 1 作为自己 ACK 报文的序列号值,此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态

  • 5、服务端收到 ACK 报文之后,就处于关闭连接了,处于 CLOSED 状态。

模型参考1
在这里插入图片描述

模型参考2
在这里插入图片描述

这里特别需要主要的就是TIME_WAIT这个状态了,这个是面试的高频考点,就是要理解,为什么客户端发送 ACK 之后不直接关闭,而是要等一阵子才关闭。这其中的原因就是,要确保服务器是否已经收到了我们的 ACK 报文,如果没有收到的话,服务器会重新发 FIN 报文给客户端,客户端再次收到 ACK 报文之后,就知道之前的 ACK 报文丢失了,然后再次发送 ACK 报文。
至于 TIME_WAIT 持续的时间至少是一个报文的来回时间。一般会设置一个计时,如果过了这个计时没有再次收到 FIN 报文,则代表对方成功就是 ACK 报文,此时处于 CLOSED 状态。

参考资料:三次握手和四次挥手(面试必问)

http://www.lryc.cn/news/9926.html

相关文章:

  • 1.1 什么是并发
  • 万字讲解你写的代码是如何跑起来的?
  • 034.Solidity入门——21不可变量
  • Vulnhub 渗透练习(四)—— Acid
  • C++ 在线工具
  • 使用MMDetection进行目标检测、实例和全景分割
  • 使用ThreadLocal实现当前登录信息的存取
  • 高通平台开发系列讲解(Android篇)AudioTrack音频流数据传输
  • BUUCTF-firmware1
  • 【C++之容器篇】二叉搜索树的理论与使用
  • 爬虫神级解析工具之XPath:用法详解及实战
  • Markdown编辑器
  • 数据结构<堆>
  • Linux下Socket编程利用多进程实现一台服务器与多台客户端并发通信
  • 【MySQL】数据库基础
  • Microsoft Office 2021 / 2019 Direct Download Links
  • XX 系统oracle RAC+ADG 数据库高可用容灾演练记录
  • JSP与Servlet
  • C++之迭代器
  • 2023-02-16:干活小计
  • Linux上安装LaTeX
  • webpack -- 无法将“webpack”项识别为 cmdlet
  • 对齐与非对齐访问
  • 基于感知动作循环的层次推理用于视觉问答
  • python中的.nc文件处理 | 05 NetCDF数据的进一步分析
  • GGX发布全新路线图,揭示具备 Layer0 特性且可编程的跨链基建生态
  • taro+vue3 搭建一套框架,适用于微信小程序和H5
  • C++:模板初阶(泛型编程、函数模板、类模板)
  • 把数组排成最小的数 AcWing(JAVA)
  • 4.3 PBR