用最通俗的语言讲解 TCP “三次握手,四次挥手”

这篇具有很好参考价值的文章主要介绍了用最通俗的语言讲解 TCP “三次握手,四次挥手”。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

目录

一. 前言

二. TCP 报文的头部结构

三. 三次握手

3.1. 三次握手过程 

3.2. 为什么要三次握手

四. 四次挥手

4.1. 四次挥手过程

4.2. 为什么要四次挥手

五. 大白话说

5.1. 大白话说三次握手

5.2. 大白话说四次挥手

六. 总结


一. 前言

    TCP 是一种面向连接的、可靠的、基于字节流的传输层通信协议,在发送数据前,通信双方必须在彼此间建立一条连接。所谓的“连接”,其实是客户端和服务端保存的一份关于对方的信息,如IP 地址、端口号等。TCP 可以看成是一种字节流,它会处理 IP 层或以下的层的丢包、重复以及错误问题。在连接的建立过程中,双方需要交换一些连接的参数。这些参数可以放在 TCP 头部。一个 TCP 连接由一个4元组构成,分别是两个 IP 地址和两个端口号。一个 TCP 连接通常分为三个阶段:连接、数据传输、退出(关闭)。通过三次握手建立一个链接,通过四次挥手来关闭一个连接。当一个连接被建立或被终止时,交换的报文段只包含 TCP 头部,而没有数据。

    所谓“任 TCP 虐我千百遍,我仍待 TCP 如初恋”。“不管面试 Java 、C/C++、Python 等开发岗位, TCP 的知识点可以说是的必问的了。我们都知道TCP是面向连接的,三次握手就是用来建立连接的,四次挥手就是用来断开连接的。

二. TCP 报文的头部结构

在了解 TCP 连接之前先来了解一下 TCP 报文的头部结构:

用最通俗的语言讲解 TCP “三次握手,四次挥手”,编程开发,tcp/ip,网络,三次握手,四次挥手,TCP报文头
TCP Header

上图中有几个字段需要重点介绍下:
(1)序号:seq 序号,占32位,用来标识从 TCP 源端向目的端发送的字节流,发起方发送数据时对此进行标记。
(2)确认序号:ack 序号,占32位,只有 ACK 标志位为1时,确认序号字段才有效,ack=seq+1。
(3)标志位:共6个,即 URG、ACK、PSH、RST、SYN、FIN 等,具体含义如下:

  1. ACK:确认序号有效。
  2. FIN:释放一个连接。
  3. PSH:接收方应该尽快将这个报文交给应用层。
  4. RST:重置连接。
  5. SYN:发起一个新连接。
  6. URG:紧急指针(urgent pointer)有效。需要注意的是:不要将确认序号 ack 与标志位中的ACK 搞混了。确认方 ack= 发起方 seq+1,两端配对。

三. 三次握手

    三次握手的本质是确认通信双方收发数据的能力。首先,我让信使运输一份信件给对方,对方收到了,那么他就知道了我的发件能力和他的收件能力是可以的。于是他给我回信,我若收到了,我便知道我的发件能力和他的收件能力是可以的,并且他的发件能力和我的收件能力是可以。然而此时,他还不知道他的发件能力和我的收件能力到底可不可以,于是我最后回馈一次,他若收到了,他便清楚了他的发件能力和我的收件能力是可以的。这,就是三次握手。

用最通俗的语言讲解 TCP “三次握手,四次挥手”,编程开发,tcp/ip,网络,三次握手,四次挥手,TCP报文头

3.1. 三次握手过程 

用最通俗的语言讲解 TCP “三次握手,四次挥手”,编程开发,tcp/ip,网络,三次握手,四次挥手,TCP报文头

我们来看一下三次握手的过程:

1. 准备阶段

    一开始,客户端和服务端都处于 CLOSED 状态。客户端主动打开连接,服务端被动打卡连接,结束CLOSED 状态,开始监听,进入 LISTEN 状态。

2. 第一次握手

    客户端会随机初始化序号(client_isn),将此序号置于 TCP 首部的「序号」字段中,同时把 SYN 标志位置为 1 ,表示 SYN 报文。接着把第一个 SYN 报文发送给服务端,表示向服务端发起连接,该报文不包含应用层数据,之后客户端处于 SYN-SENT 状态。

3. 第二次握手

    服务端收到客户端的 SYN 报文后,首先服务端也随机初始化自己的序号(server_isn),将此序号填入 TCP 首部的「序号」字段中,其次把 TCP 首部的「确认应答号」字段填入 client_isn + 1, 接着把 SYN 和 ACK 标志位置为 1。最后把该报文发给客户端,该报文也不包含应用层数据,之后服务端处于 SYN-RCVD 状态。

4. 第三次握手

    客户端收到服务端报文后,还要向服务端回应最后一个应答报文,首先该应答报文 TCP 首部 ACK 标志位置为 1 ,其次「确认应答号」字段填入 server_isn + 1 ,最后把报文发送给服务端,这次报文可以携带客户到服务器的数据,之后客户端处于 ESTABLISHED 状态。

好了,经过三次握手的过程,客户端和服务端之间的确定连接正常,接下来进入 ESTABLISHED 状态,服务端和客户端就可以快乐地通信了。

这里有个动态过程的图示:

用最通俗的语言讲解 TCP “三次握手,四次挥手”,编程开发,tcp/ip,网络,三次握手,四次挥手,TCP报文头

这里有个小细节,第三次握手是可以携带数据的,这是面试常问的点。 

3.2. 为什么要三次握手

为什么要三次握手呢?两次不行吗?

  1. 为了防止服务器端开启一些无用的连接增加服务器开销
  2. 防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误。

由于网络传输是有延时的(要通过网络光纤和各种中间代理服务器),在传输的过程中,比如客户端发起了 SYN=1 的第一次握手。

如果服务器端就直接创建了这个连接并返回包含 SYN、ACK 和 Seq 等内容的数据包给客户端,这个数据包因为网络传输的原因丢失了,丢失之后客户端就一直没有接收到服务器返回的数据包。

如果没有第三次握手告诉服务器端客户端收的到服务器端传输的数据的话,服务器端是不知道客户端有没有接收到服务器端返回的信息的。服务端就认为这个连接是可用的,端口就一直开着,等到客户端因超时重新发出请求时,服务器就会重新开启一个端口连接。 

这样一来,就会有很多无效的连接端口白白地开着,导致资源的浪费。 

这个过程可理解为:

用最通俗的语言讲解 TCP “三次握手,四次挥手”,编程开发,tcp/ip,网络,三次握手,四次挥手,TCP报文头

还有一种情况是:已经失效的客户端发出的请求信息,由于某种原因传输到了服务器端,服务器端以为是客户端发出的有效请求,接收后产生错误:

用最通俗的语言讲解 TCP “三次握手,四次挥手”,编程开发,tcp/ip,网络,三次握手,四次挥手,TCP报文头

所以我们需要“第三次握手”来确认这个过程: 
    通过第三次握手的数据告诉服务端,客户端有没有收到服务器“第二次握手”时传过去的数据,以及这个连接的序号是不是有效的。若发送的这个数据是“收到且没有问题”的信息,接收后服务器就正常建立 TCP 连接,否则建立 TCP 连接失败,服务器关闭连接端口。由此减少服务器开销和接收到失效请求发生的错误。

四. 四次挥手

4.1. 四次挥手过程

还是先上图:

用最通俗的语言讲解 TCP “三次握手,四次挥手”,编程开发,tcp/ip,网络,三次握手,四次挥手,TCP报文头
四次挥手

聚散终有时,TCP 断开连接是通过四次挥手方式。双方都可以主动断开连接,断开连接后主机中的「资源」将被释放。

上图是客户端主动关闭连接:

第一次挥手:

    客户端打算关闭连接,此时会发送一个 TCP 首部 FIN 标志位被置为 1 的报文,也即 FIN 报文,之后客户端进入 FIN_WAIT_1 状态。

第二次挥手:

    服务端收到该报文后,就向客户端发送 ACK 应答报文,接着服务端进入 CLOSED_WAIT 状态。

第三次挥手:

    客户端收到服务端的 ACK 应答报文后,之后进入 FIN_WAIT_2 状态。等待服务端处理完数据后,也向客户端发送 FIN 报文,之后服务端进入 LAST_ACK 状态。

第四次挥手:

1. 客户端收到服务端的 FIN 报文后,回一个 ACK 应答报文,之后进入 TIME_WAIT 状态;
2. 服务器收到了 ACK 应答报文后,就进入了 CLOSED 状态,至此服务端已经完成连接的关闭;
3. 客户端在经过 2MSL 一段时间后,自动进入 CLOSED 状态,至此客户端也完成连接的关闭。

你可以看到,每个方向都需要一个 FIN 和一个 ACK,因此通常被称为四次挥手

4.2. 为什么要四次挥手

为什么要挥手四次?

再来回顾下四次挥手双方发 FIN 包的过程,就能理解为什么需要四次了。

  1. 关闭连接时,客户端向服务端发送 FIN 时,仅仅表示客户端不再发送数据了但是还能接收数据。
  2. 服务器收到客户端的 FIN 报文时,先回一个 ACK 应答报文,而服务端可能还有数据需要处理和发送,等服务端不再发送数据时,才发送 FIN 报文给客户端来表示同意现在关闭连接。

从上面过程可知,服务端通常需要等待完成数据的发送和处理,所以服务端的 ACK 和 FIN 一般都会分开发送,从而比三次握手导致多了一次。

为什么客户端在 TIME-WAIT 阶段要等 2MSL?

    为的是确认服务器端是否收到客户端发出的 ACK 确认报文,当客户端发出最后的 ACK 确认报文时,并不能确定服务器端能够收到该段报文。

所以客户端在发送完 ACK 确认报文之后,会设置一个时长为 2MSL 的计时器。

MSL 指的是 Maximum Segment Lifetime:一段 TCP 报文在传输过程中的最大生命周期。

2MSL 即是服务器端发出为 FIN 报文和客户端发出的 ACK 确认报文所能保持有效的最大时长。

服务器端在 1MSL 内没有收到客户端发出的 ACK 确认报文,就会再次向客户端发出 FIN 报文:

  • 如果客户端在 2MSL 内,再次收到了来自服务器端的 FIN 报文,说明服务器端由于各种原因没有接收到客户端发出的 ACK 确认报文。

客户端再次向服务器端发出 ACK 确认报文,计时器重置,重新开始 2MSL 的计时。

  • 否则客户端在 2MSL 内没有再次收到来自服务器端的 FIN 报文,说明服务器端正常接收了 ACK 确认报文,客户端可以进入 CLOSED 阶段,完成“四次挥手”。 

所以,客户端要经历时长为 2SML 的 TIME-WAIT 阶段;这也是为什么客户端比服务器端晚进入 CLOSED 阶段的原因。 

这里同样有个动态过程的图示:

用最通俗的语言讲解 TCP “三次握手,四次挥手”,编程开发,tcp/ip,网络,三次握手,四次挥手,TCP报文头
四次挥手

五. 大白话说

5.1. 大白话说三次握手

在二十年前的农村,电话没有普及,手机就更不用说了,所以,通信基本靠吼。

老张和老王是邻居,这天老张下地了,结果家里有事,热心的邻居老王赶紧跑到村口,开始叫唤老王:

  1. 老王:老张唉!我是老王,你能听到吗?
  2. 老张一听,是老王的声音:老王老王,我是老张,我能听到,你能听到吗?
  3. 老王一听,嗯,没错,是老张:老张,我听到了,我有事要跟你说。

老王:"你老婆要生了,赶紧回家吧!"

老张风风火火地赶回家,老婆顺利地生了个带把的大胖小子。

握手的故事充满了幸福和美满。

用最通俗的语言讲解 TCP “三次握手,四次挥手”,编程开发,tcp/ip,网络,三次握手,四次挥手,TCP报文头

5.2. 大白话说四次挥手

假如博主有一个女朋友——只是“假如”,该死的,这不争气的眼泪,怎么止不住地滴在键盘上。

由于博主上班九九六,下班肝博客,导致没有时间陪女朋友,女朋友忍无可忍:

  • 女朋友:臭男人,最近你都不理我,你是不是不爱我了?你是不是外面有别的狗子了?我要和你分手?
  • 沙雕博主一愣,怒火攻心:分手就分手,不陪你闹了,等我把东西收拾收拾。

沙雕博主小心翼翼地装起了自己的青轴机械键盘:

  • 哼,蠢女人,我已经收拾完了,我先滚为敬,再见!
  • 女朋友:滚,滚的远远的,越远越好,我一辈子都不想再见到你。 

唉,挥手的故事总充满了悲伤和遗憾!

用最通俗的语言讲解 TCP “三次握手,四次挥手”,编程开发,tcp/ip,网络,三次握手,四次挥手,TCP报文头

六. 总结

    《TCP/IP详解 卷1:协议》有一张TCP状态变迁图,很具有代表性,有助于大家理解三次握手和四次挥手的状态变化。如下图所示,粗的实线箭头表示正常的客户端状态变迁,粗的虚线箭头表示正常的服务器状态变迁。

用最通俗的语言讲解 TCP “三次握手,四次挥手”,编程开发,tcp/ip,网络,三次握手,四次挥手,TCP报文头文章来源地址https://www.toymoban.com/news/detail-797029.html

到了这里,关于用最通俗的语言讲解 TCP “三次握手,四次挥手”的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • TCP的三次握手、四次挥手

    首先我们要知道建立连接的目的是什么,我们是为了可靠的传输数据。那既然是可靠的传输数据,我们必须保证客户端和服务端都能正常的发送和接收数据,如果某一方不能正常的发送或者接收数据,那整个数据的传输就不能成功,也就不可靠。 三次握手 1.第一次握手:第一

    2024年02月10日
    浏览(45)
  • TCP的三次握手,四次挥手

    第一次握手:客户端发送SYN报文,井发送seq为x序列号给服务端,等待服务端的确认 第二次握手:服务端发送SYN+ACK报文,并发送seq为Y的序列号,在确认序列号为x+1 第三次握手:客户端发送ACK报文,并发送seq序列号为z,在确认序列号为y+1 第一次挥手:先由客户端向服务器端发

    2024年01月18日
    浏览(76)
  • TCP 三次握手&四次挥手浅析

    大家都知道传输层中的TCP协议是面向连接的,提供可靠的连接服务,其中最出名的就是三次握手和四次挥手。 三次握手的交互过程如下 喜欢钻牛角尖的我在学习三次握手的时候就想到了几个问题:为什么三次握手是三次?不是一次、两次或者更多?如果是两次或者是一次会

    2024年02月15日
    浏览(92)
  • TCP三次握手四次挥手

    目录 一、基础理论 1、TCP的标志位 2、TCP的状态码 二、TCP连接的建立与释放 1、三次握手 第一次握手: 第二次握手: 第三次握手: 2、四次挥手 第一次挥手: 第二次挥手: 第三次挥手: 第四次挥手: 三、更多面试题参考 标志位 含义 SYN(synchronous) 在建立连接时使用,表示

    2024年02月19日
    浏览(51)
  • TCP的三次握手四次挥手

    TCP的三次握手和四次挥手实质就是TCP通信的连接和断开。 三次握手:为了对每次发送的数据量进行跟踪与协商,确保数据段的发送和接收同步,根据所接收到的数据量而确认数据发送、接收完毕后何时撤消联系,并建立虚连接。 四次挥手:即终止TCP连接,就是指断开一个T

    2024年02月11日
    浏览(46)
  • TCP连接管理(三次握手,四次挥手)

    源端口号 (Source Port):16 位字段,表示发送方的端口号。 目的端口号 (Destination Port):16 位字段,表示接收方的端口号。 序列号 (Sequence Number):32 位字段,表示发送方发送的字节流的序列号。用于实现数据的可靠传输和顺序传递。 确认号 (Acknowledgment Number):32 位字

    2024年02月13日
    浏览(52)
  • TCP三次握手和四次挥手

    序列号:建立连接时计算机随机生成的随机数作为初始值,通过SYN包传给接收端主机,每发送一次数据就累加一次该数据字节数的大小。 用来解决网络包乱序问题 。 确认应答号:指下一次期望收到的数据的序列号,发送端收到这个确认应答以后认为在这个序号以前的数据都

    2023年04月11日
    浏览(92)
  • TCP 三次握手和四次挥手

    1 TCP 三次握手漫画图解 如下图所示,下面的两个机器人通过3次握手 确定了对方能正确接收和发送消息 (图片来源网络)。 简单示意图: 客户端–发送带有 SYN 标志的数据包–一次握手–服务端 服务端–发送带有 SYN/ACK 标志的数据包–二次握手–客户端 客户端–发送带有带有

    2024年02月22日
    浏览(60)
  • 【TCP】三次握手 与 四次挥手 详解

    在正常情况下,TCP 要经过三次握手建立连接,四次挥手断开连接 服务端状态转化: [CLOSED - LISTEN] 服务器端调用 listen 后进入 LISTEN 状态,等待客户端连接; [LISTEN - SYN_RCVD] 一旦监听到连接请求(同步报文段 SYN),就将该连接放入内核等待队列中,并向客户端发送 SYN + ACK 确认

    2024年02月07日
    浏览(43)
  • TCP之三次握手四次挥手

             在前面的文章中我们了解到http是基于TCP/IP协议的,这篇文章我们来了解一下TCP/IP。 1、UDP        基于非连接。类似于写信,不能保证对方能不能接收到,接收到的内容是否完整,顺序是否正确。     优缺点:性能损耗小,占用资源少,稳定弱,速度块。 2、TCP  

    2024年02月10日
    浏览(38)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包