【三次握手、四次挥手】TCP建立连接和断开连接的过程、为什么需要三次握手,为什么需要四次挥手、TCP的可靠传输如何保证、为什么需要等待2MSL等重点知识汇总

目录

三次握手

为什么握手需要三次

四次挥手

为什么挥手需要四次

TCP的可靠传输如何保证

TIME_WAIT等待的时间是2MSL


三次握手

三次握手其实就是指建立一个TCP连接。进行三次握手的主要作用就是为了确认双方的接收能力和发送能力是否正常、指定自己的初始化序列号为后面的可靠性传送做准备。

  • 一开始,客户端和服务端都处于 CLOSE 状态。先是服务端主动监听某个端口,处于 LISTEN 状态
  • 客户端会随机初始化序号(client_isn),将此序号置于 TCP 首部的「序号」字段中,同时把 SYN 标志位置为 1,表示 SYN 报文。接着把第一个 SYN 报文发送给服务端,表示向服务端发起连接,该报文不包含应用层数据,之后客户端处于 SYN-SENT 状态
  • 服务端收到客户端的 SYN 报文后,首先服务端也随机初始化自己的序号(server_isn),将此序号填入 TCP 首部的「序号」字段中,其次把 TCP 首部的「确认应答号」字段填入 client_isn + 1, 接着把 SYN 和 ACK 标志位置为 1。最后把该报文发给客户端,该报文也不包含应用层数据,之后服务端处于 SYN-RCVD 状态
  • 客户端收到服务端报文后,还要向服务端回应最后一个应答报文,首先该应答报文 TCP 首部 ACK 标志位置为 1 ,其次「确认应答号」字段填入 server_isn + 1 ,最后把报文发送给服务端,这次报文可以携带客户到服务端的数据,之后客户端处于 ESTABLISHED 状态
  • 服务端收到客户端的应答报文后,也进入 ESTABLISHED 状态

从上面的过程可以发现第三次握手是可以携带数据的,前两次握手是不可以携带数据的,这也是面试常问的题。

一旦完成三次握手,双方都处于 ESTABLISHED 状态,此时连接就已建立完成,客户端和服务端就可以相互发送数据了。

为什么握手需要三次

相信大家比较常回答的是:“因为三次握手才能保证双方具有接收和发送的能力。”

这回答是没问题,但这回答是片面的,并没有说出主要的原因。

接下来,以三个方面分析三次握手的原因:

  • TCP 使用三次握手建立连接的最主要原因是防止「历史连接」初始化了连接
  • 三次握手才可以同步双方的初始序列号
  • 三次握手才可以避免资源浪费

原因一:避免历史连接

简单来说,三次握手的首要原因是为了防止旧的重复连接初始化造成混乱。

我们考虑一个场景,客户端先发送了 SYN(seq = 90)报文,然后客户端宕机了,而且这个 SYN 报文还被网络阻塞了,服务端并没有收到,接着客户端重启后,又重新向服务端建立连接,发送了 SYN(seq = 100)报文(注意!不是重传 SYN,重传的 SYN 的序列号是一样的)。

客户端连续发送多次 SYN(都是同一个四元组)建立连接的报文,在网络拥堵情况下:

  • 一个「旧 SYN 报文」比「最新的 SYN」 报文早到达了服务端,那么此时服务端就会回一个 SYN + ACK 报文给客户端,此报文中的确认号是 91(90+1)。
  • 客户端收到后,发现自己期望收到的确认号应该是 100 + 1,而不是 90 + 1,于是就会回 RST 报文。
  • 服务端收到 RST 报文后,就会释放连接。
  • 后续最新的 SYN 抵达了服务端后,客户端与服务端就可以正常的完成三次握手了。

上述中的「旧 SYN 报文」称为历史连接,TCP 使用三次握手建立连接的最主要原因就是防止「历史连接」初始化了连接

如果采用两次握手建立 TCP 连接的场景下,服务端在向客户端发送数据前,并没有阻止掉历史连接,导致服务端建立了一个历史连接,又白白发送了数据,妥妥地浪费了服务端的资源。

因此,要解决这种现象,最好就是在服务端发送数据前,也就是建立连接之前,要阻止掉历史连接,这样就不会造成资源浪费,而要实现这个功能,就需要三次握手

所以,TCP 使用三次握手建立连接的最主要原因是防止「历史连接」初始化了连接。

原因二:同步双方初始序列号

TCP 协议的通信双方, 都必须维护一个「序列号」, 序列号是可靠传输的一个关键因素,它的作用:

  • 接收方可以去除重复的数据;
  • 接收方可以根据数据包的序列号按序接收;
  • 可以标识发送出去的数据包中, 哪些是已经被对方收到的(通过 ACK 报文中的序列号知道);

可见,序列号在 TCP 连接中占据着非常重要的作用,所以当客户端发送携带「初始序列号」的 SYN 报文的时候,需要服务端回一个 ACK 应答报文,表示客户端的 SYN 报文已被服务端成功接收,那当服务端发送「初始序列号」给客户端的时候,依然也要得到客户端的应答回应,这样一来一回,才能确保双方的初始序列号能被可靠的同步。

四次握手其实也能够可靠的同步双方的初始化序号,但由于第二步和第三步可以优化成一步,所以就成了「三次握手」。

而两次握手只保证了一方的初始序列号能被对方成功接收,没办法保证双方的初始序列号都能被确认接收。

原因三:避免资源浪费

如果只有「两次握手」,如果客户端发送的 SYN 报文在网络中阻塞了,重复发送多次 SYN 报文,那么服务端在收到请求后就会建立多个冗余的无效链接,造成不必要的资源浪费。

即两次握手会造成消息滞留情况下,服务端重复接受无用的连接请求 SYN 报文,而造成重复分配资源。

小结

TCP 建立连接时,通过三次握手能防止历史连接的建立,能减少双方不必要的资源开销,能帮助双方同步初始化序列号。序列号能够保证数据包不重复、不丢弃和按序传输。

不使用「两次握手」和「四次握手」的原因:

  • 「两次握手」:无法防止历史连接的建立,会造成双方资源的浪费,也无法可靠的同步双方序列号;
  • 「四次握手」:三次握手就已经理论上最少可靠连接建立,所以不需要使用更多的通信次数。

四次挥手

双方都可以主动断开连接,断开连接后主机中的「资源」将被释放,四次挥手的过程如下图:

刚开始双方都处于 ESTABLISHED 状态,假如是客户端先发起关闭请求。四次挥手的过程如下:

  • 客户端打算关闭连接,此时会发送一个 TCP 首部 FIN 标志位被置为 1 的报文,也即 FIN 报文,之后客户端进入 FIN_WAIT_1 状态
  • 服务端收到该报文后,就向客户端发送 ACK 应答报文,接着服务端进入 CLOSE_WAIT 状态
  • 客户端收到服务端的 ACK 应答报文后,之后进入 FIN_WAIT_2 状态
  • 等待服务端处理完数据后,也向客户端发送 FIN 报文,之后服务端进入 LAST_ACK 状态
  • 客户端收到服务端的 FIN 报文后,回一个 ACK 应答报文,之后进入 TIME_WAIT 状态
  • 服务端收到了 ACK 应答报文后,就进入了 CLOSE 状态,至此服务端已经完成连接的关闭。
  • 客户端在经过 2MSL 一段时间后,自动进入 CLOSE 状态,至此客户端也完成连接的关闭。

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

这里一点需要注意是:主动关闭连接的,才有 TIME_WAIT 状态。

为什么挥手需要四次

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

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

从上面过程可知,服务端通常需要等待完成数据的发送和处理,所以服务端的 ACK 和 FIN 一般都会分开发送,因此是需要四次挥手。

TCP的可靠传输如何保证

TCP是通过一些机制来保证可靠传输的。

校验和
TCP每一段报文都有校验和,这保证了报文不被破坏或篡改,如果收到的报文在校验过程中有差错,TCP 将丢弃这个报文段和不确认收到此报文段。

序列号与确认应答
TCP发送的每一个包都有一个序列号,这可以让接收方知道自己已经接收到了那些包,哪些包丢失了,重复的包也可以根据序号丢弃,并且根据序号将包排序,同时每一个发送的包都会返回一个确认应答消息,来确保消息被接收。

重传机制

TCP 实现可靠传输的方式之一,是通过序列号与确认应答,当发送端的数据到达接收主机时,接收端主机会返回一个确认应答消息,表示已收到消息,如果数据包丢失了,就会用重传机制解决。
重传机制分为超时重传、快速重传

超时重传 :在发送数据时,设定一个定时器,当超过指定的时间后,没有收到对方的 ACK 确认应答报文,就会重发该数据。超时时间被称为RTO,一般略大于RTT,不过RTO是一个动态值。如果重传的包又超时了,即每当遇到一次超时重传的时候,都会将下一次超时时间间隔设为先前值的两倍。两次超时,就说明网络环境差,不宜频繁反复发送。

快速重传 :超时重传的问题是要等超时时间后才会重传。快速重传不以时间为驱动,而是以数据驱动重传,服务器如果收到乱序的包,也给客户端回复 ACK,比如收到乱序的包 6,7,8,9 时,服务器全都发 ACK = 5,这样客户端就知道5丢失了,当客户端收到三个相同的 ACK 报文时,会在超时之前,重传丢失的报文段,而不需要等到计时器超时。

滑动窗口

窗口大小就是指无需等待确认应答,而可以继续发送数据的最大值。
TCP 是每发送一个数据,就需要等待对方进行ACK确认应答,这显然会极大的影响传输的速率。在发送数据的时候,最好的方式是一下将所有的数据全部发送出去,然后一起确认。

于是就引入了窗口的概念,这个所谓的窗口实际上是操作系统开辟的一个缓存空间,发送方在等到确认应答返回之前,必须在缓冲区中保留已发送的数据。如果按期收到确认应答后,此时数据就可以从缓存区清除,同样接收方接收数据后也是放在这个缓存区中的,那么接收方缓存区还能接收多少数据,这个就是决定窗口大小的因素。

所以,通常窗口的大小是由接收方的窗口大小来决定的。发送方发送的数据大小不能超过接收方的窗口大小,否则接收方就无法正常接收到数据。

流量控制
发送方不能无限制的发数据给接收方,也要考虑接收方的处理能力,如果一直无限制的发数据给对方,但对方处理不过来,那么就会导致触发重发机制,从而导致网络流量的无端的浪费。

为了解决这种现象发生,TCP 提供一种机制可以让「发送方」根据「接收方」的实际接收能力控制发送的数据量,这就是所谓的流量控制TCP使用滑动窗口来实现流量控制。滑动窗口既保证了分组无差错、有序接收,也实现了流量控制。主要的方式就是接收方返回的 ACK 中会包含自己的接收窗口的大小,并且利用大小来控制发送方的数据发送。

拥塞控制

有了流量控制为什么还需要拥塞控制?

流量控制是针对接收者的,它是控制发送者的发送速度从而使接收者来得及接收,防止分组丢失的。即防止发送方的数据填满接收方的缓存区。

拥塞控制:拥塞控制是作用于网络的,它是防止过多的数据注入到网络中,避免出现网络负载过大的情况。即防止发送方的数据填满整个网络

在网络出现拥堵时减少数据包的发送,网络恢复后它又会增加数据包的发送,这就是拥塞控制。

拥塞控制算法:

慢启动:TCP 在刚建立连接完成后并不知道网络情况,它会一点一点的提高发送数据包的数量来试探网络的情况,它的主要原理就是:当发送方每收到一个 ACK,拥塞窗口 cwnd 的大小就会加 1。当然也不可能无限制的增加拥塞窗口 cwnd 的大小,有一个叫慢启动门限 ssthresh (slow start threshold)状态变量,当cwnd 小于该值时就增加,大于等于该值时就会启动拥塞避免算法。慢开始算法只是在TCP连接建立时和网络出现超时时才使用

拥塞避免算法:进入拥塞避免算法后,它的规则是:每当收到一个 ACK 时,拥塞窗口cwnd 增加 1/cwnd,假设cwnd现在是8,那么进入拥塞避免算法后,收到ACK时,它增加了1/8。也就是说增长变的缓慢了,即使缓慢的增长,它也是无限制的,这样网络就会慢慢进入了拥塞的状况,当出现包丢失,触发重传机制的时候,就进入了拥塞发生算法。

拥塞发生算法:当网络出现拥塞,也就是会发生数据包重传,触发重传机制,前面我们知道重传机制分为超时重传和快速重传两种情况,当发生了超时重传时才会使用拥塞发生算法,此时它会将ssthresh 设置为cwnd/2 ,并将cwnd 重置为初始值。接着,就重新开始慢启动,慢启动是会突然减少数据流的。这种方式太激进会造成网络卡顿。当发生快速重传时,TCP 认为这种情况不严重,因为大部分没丢,只丢了一小部分,则 ssthresh 和 cwnd 变化如下,cwnd = cwnd/2 ,也就是设置为原来的一半;ssthresh = cwnd。进入快速恢复算法

快速恢复算法: 快速重传和快速恢复算法一般同时使用,进入快速恢复算法后,拥塞窗口 cwnd = ssthresh + 3,重传丢失的数据包。快速恢复是针对拥塞发生后对慢启动的优化。

TIME_WAIT等待的时间是2MSL

MSL 报文最大生存时间,它是任何报文在网络上存在的最长时间,超过这个时间报文将被丢弃。

为了保证客户端发送的最后一个ACK报文段能够到达服务器。因为这个ACK有可能丢失,从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。服务器会超时重传这个FIN-ACK,接着客户端再重传一次确认,重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待2MSL,而是在发送完ACK之后直接释放关闭,一但这个ACK丢失的话,服务器就无法正常的进入关闭连接状态。

TIME_WAIT 等待 2 倍的 MSL,比较合理的解释是: 网络中可能存在来自发送方的数据包,当这些发送方的数据包被接收方处理后又会向对方发送响应,所以一来一回需要等待 2 倍的时间

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.rhkb.cn/news/143336.html

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

IOTE 2023国际物联网展直击:芯与物发布全新定位芯片,助力多领域智能化发展

IOTE 2023国际物联网展,作为全球物联网领域的盛会,于9月20日在中国深圳拉开帷幕。北斗星通集团应邀参展,旗下专业从事物联网、消费类GNSS芯片研发设计的芯与物公司也随其亮相本届盛会。 展会上,芯与物展示了一系列创新的GNSS定位…

Spring 学习(四)注解实现自动装配及注解开发

1. 注解实现自动装配 JDK 1.5 开始支持注解&#xff0c;Spring 2.5 开始支持注解。 使用须知 导入约束 配置注解的支持&#xff08; <context:annotation-config/> &#xff09; <?xml version"1.0" encoding"UTF-8"?> <beans xmlns&qu…

在pandas中使matplotlib动态画子图的两种方法【推荐gridspec】

先上对比图&#xff0c; 第一种方法&#xff0c;这里仅展示1个大区&#xff0c;多个的话需要加一层循环就可以了&#xff0c;主要是看子图的画法 当大区下面的国家为1个或2个时&#xff0c;会进行报错 # 获取非洲国家列表 african_countries df[df[大区] 南亚大区][进口国…

flink中不同序列化器性能对比

背景 flink有多种序列化方式&#xff0c;包括flink内置的以及fallback到kryo的&#xff0c;那么他们之间有多大的性能差距呢&#xff0c;本文就从https://flink.apache.org/2020/04/15/flink-serialization-tuning-vol.-1-choosing-your-serializer-if-you-can/这篇文章里摘录…

【李沐深度学习笔记】线性代数实现

课程地址和说明 线性代数实现p2 本系列文章是我学习李沐老师深度学习系列课程的学习笔记&#xff0c;可能会对李沐老师上课没讲到的进行补充。 这节就算之前内容的复习&#xff0c;后面以截图形式呈现 标量由只有一个元素的张量表示 import torch x torch.tensor([3.0]) y …

华为云云耀云服务器L实例评测|搭建CounterStrike Source Delicated Server(CS起源游戏服务器)

华为云云耀云服务器L实例评测&#xff5c;搭建CounterStrike Source Delicated Server&#xff08;CS起源游戏服务器&#xff09; #【有奖征文】华为云云服务器焕新上线&#xff0c;快来亲身感受评测吧&#xff01;# ⭐️ CounterStrikeSource&#xff08;CS起源是Valve的一款…

【Vue简介+搭建Vue开发环境+Hello小案例】

Vue简介搭建Vue开发环境Hello小案例 1 Vue简介2 搭建Vue开发环境3 Hello小案例 1 Vue简介 Vue是一套用于构建用户界面的渐进式JavaScript框架。&#xff08;渐进式&#xff1a;Vue可以自底向上逐层的应用<简单应用&#xff1a;只需要一个轻量小巧的核心库><复杂应用&…

tp8 Editor.md

Editor.md - 开源在线 Markdown 编辑器 放于public文件夹下 html代码&#xff1a; <div class"layui-col-md12" id"content"><textarea name"content" placeholder"详情" class"layui-textarea">{notempty nam…

05-Zookeeper典型使用场景实战

上一篇&#xff1a;04-Zookeeper集群详解 1. Zookeeper 分布式锁加锁原理 如上实现方式在并发问题比较严重的情况下&#xff0c;性能会下降的比较厉害&#xff0c;主要原因是&#xff0c;所有的连接都在对同一个节点进行监听&#xff0c;当服务器检测到删除事件时&#xff0c…

目标追踪学习经验总结

标题目标追踪算法学习经验总结   最近对目标追踪算法进行了学习&#xff0c;以下是我的学习经验&#xff0c;如有不对之处&#xff0c;欢迎大家指正。 1、简介 1.1 定义 目标跟踪是通过分析视频图片序列&#xff0c;对检测出的各个候选目标区域实施匹配&#xff0c;定位出这…

nat综合实验

路漫漫其修远兮,吾将上下而求索。 实验目的如图 实验思路&#xff1a;配置内网&#xff0c;再配置外网&#xff0c;再做nat clien1配置 clien2配置 pc3配置 lsw1配置 sysname lsw1 # vlan batch 10 20 30 # interface MEth0/0/1 # interface Eth-Trunk1port link-type trunkp…

数据结构——排序

排序算法 前言一、认识排序排序的概念常见的排序算法排序实现的接口 二、常见排序算法的实现插入排序直接插入排序希尔排序 选择排序直接选择排序堆排序 交换排序冒泡排序 三、各个排序的效率比较四、完整代码演示&#xff1a;shell_insert.hshell_insert.ctest.c 总结 前言 来…

怎样在CSDN插入代码块 怎么变色?

添加代码块&#xff0c;通常有三种方式&#xff1a; 文章目录 ①点击 工具栏中的代码块 代码块 </>&#xff0c;② 快捷键 ctrlshiftk③ 先粘贴上代码&#xff0c;在选中 ctrlshiftk4 如果代码没有变彩色 ①点击 工具栏中的代码块 代码块 </>&#xff0c; 例如 选…

Docker版部署RocketMQ开启ACL验证

一、拉取镜像 docker pull apache/rocketmq:latest 二、准备挂载目录 mkdir /usr/local/rocketmq/data mkdir /usr/local/rocketmq/conf 三、运行 docker run \ -d \ -p 9876:9876 \ -v /usr/local/rocketmq/data/logs:/home/rocketmq/logs \ -v /usr/local/rocketmq/data…

Redis之zset类型

文章目录 Redis之zset类型1. 添加元素/获取集合中元素的数量2. 按照元素分数从小到大的顺序返回索引从start到stop之间的所有元素3. 获取元素的分数4. 删除元素5. 获取指定分数范围的元素6. 增加某个元素的分数7. 获得指定分数范围内的元素个数8. 获取元素的排名9. 按照排名范围…

Hive【Hive(二)DML】

启动 hive 命令行&#xff1a; hive DML 数据操作 1、数据导入 1.1、向表中装载数据&#xff08;load&#xff09; 语法&#xff1a; hive> load data [local] inpath 数据的path [overwrite] into table student [partition (partcol1val1,…)];&#xff08;1&#x…

轻松上手Docker:学习如何创建和运行自己的Docker容器

文章目录 轻松上手Docker&#xff1a;学习如何创建和运行自己的Docker容器容器的介绍Docker的技术架构容器的工作机制&#xff08;Docker&#xff09;容器的关键技术 - NamespaceNamespace隔离说明 容器的关键技术 - CgroupDocker环境搭建1&#xff09;安装基础软件包2&#xf…

十四,间接漫反射用到球体中

间接光照分为间接漫反射和间接镜面反射。 辐照度图是用来适用于间接漫反射的。 直射光也有漫反射&#xff0c;对比下两者。 直接光kD * albedo / PI * radiance * NdotL&#xff1b;其中radiance * NdotL是光照, 间接光&#xff1a; kD * texture(irradianceMap, N).rgb* al…

SD-MTSP:萤火虫算法(FA)求解单仓库多旅行商问题MATLAB(可更改数据集,旅行商的数量和起点)

一、萤火虫算法&#xff08;FA&#xff09;简介 萤火虫算法(Firefly Algorithm&#xff0c;FA)是Yang等人于2009年提出的一种仿生优化算法。 参考文献&#xff1a;田梦楚, 薄煜明, 陈志敏, et al. 萤火虫算法智能优化粒子滤波[J]. 自动化学报, 2016, 42(001):89-97. 二、单仓…

八大排序详解

目录 1.排序的概念及应用 1.1 排序的概念 1.2 排序的应用 1.3 常见的排序算法 2.常见排序算法的实现 2.1 直接插入排序 2.1.1 基本思想 2.1.2 动图解析 2.1.3 排序步骤&#xff08;默认升序&#xff09; 2.1.4 代码实现 2.1.5 特性总结 2.2 希尔排序 2.2.1 基本思…