网络（二）——三次握手、四次挥手过程

最新推荐文章于 2023-03-23 17:37:54 发布

中都

最新推荐文章于 2023-03-23 17:37:54 发布

阅读量993

点赞数 1

分类专栏：网络文章标签：三次握手、四次挥手过程为什么需要三次握手，两次为什么不行为什么需要四次挥手三次挥手可以吗

本文链接：https://blog.csdn.net/QQ2899349953/article/details/83868145

版权

网络专栏收录该内容

7 篇文章 0 订阅

订阅专栏

TCP/IP的三次握手，四次挥手

ACK：确认序号有效
RST：重置连接
SYN：发起了一个新连接
FIN：释放一个连接

三次握手的过程（客户端用A表示，服务器端用B表示）

前提：A主动打开，B被动打开
在这里插入图片描述

在建立连接之前，B先创建TCB（传输控制块），准备接受客户进程的连接请求，处于LISTEN（监听）状态
第一次握手：A首先创建TCB，然后向B发出连接请求，SYN置1，同时选择初始序号seq=x，进入SYN-SEND（同步已发送）状态
第二次握手：B收到连接请求后向A发送确认，SYN置1，ACK置1，同时产生一个确认序号ack=x+1。同时随机选择初始序号seq=y，进入SYN-RCVD（同步收到）状态
第三次握手：A收到确认连接请求后，ACK置1，确认号ack=y+1，seq=x+1，进入到ESTABLISHED（已建立连接）状态。向B发出确认连接，最后B也进入到ESTABLISHED（已建立连接）状态。

简单来说，就是

建立连接时，客户端发送SYN包（SYN=i）到服务器，并进入到SYN-SEND状态，等待服务器确认
服务器收到SYN包，必须确认客户的SYN（ack=i+1）,同时自己也发送一个SYN包（SYN=k）,即SYN+ACK包，此时服务器进入SYN-RECV状态
客户端收到服务器的SYN+ACK包，向服务器发送确认报ACK（ack=k+1）,此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手

注意：
在此穿插一个知识点就是SYN攻击，那么什么是SYN攻击？发生的条件是什么？怎么避免？

在三次握手过程中，第二阶段Server发送SYN-ACK之后，收到Client的ACK之前的TCP连接称为半连接（half-open connect），此时Server处于SYN_RCVD状态，当收到ACK后，Server转入ESTABLISHED状态。SYN攻击就是 Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server回复确认包，并等待Client的确认，由于源地址是不存在的，因此，Server需要不断重发直至超时，这些伪造的SYN包将产时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络堵塞甚至系统瘫痪。SYN攻击时一种典型的DDOS攻击，检测SYN攻击的方式非常简单，即当Server上有大量半连接状态且源IP地址是随机的，则可以断定遭到SYN攻击了，使用如下命令可以让之现行：

#netstat -nap | grep SYN_RECV

为什么要三次握手

使得通信双方都做好通讯的准备；
告诉对端本端通信所选用的报文标识号
防止已失效的请求报文段又突然传递到了服务端，从而产生错误；

三次握手确认双发都可以正常通信：

第一次握手客户端向服务端发送请求，这个时候客户端不知道自己这边的的发送信息功能和接收信息功能是否是正常的，它需要等服务端的回复；
第二次握手客户端收到服务端返回的数据，于是客户端知道自己这边的信息发送能力和接收能力都没问题，所以自己就进入到了建立连接的状态，而对于服务端来说，它能接收到客户端的请求说明它这边的接收信息能力没问题，但它发送的信息还没有得到客户端的回应，所以自己这边还不知道自己的信息发送能力如何；
第三次握手，客户端回应服务端，那么服务端就知道自己的信息发送能力也没有问题，于是这次握手之后对于客户端和服务端来说它们都知道了自己的信息发送能力和接收能力都没有问题，于是都进入到建立连接状态，可以接收或发送消息了；

为什么需要三次握手？两次握手为什么不行？

不行，举个反例：

客户端发出的第一个连接请求报文段并没有丢失，而是在某个网络节点滞留了，以至延误到连接释放以后的某个时间才到达服务器，本来这是一个早已失效的报文段，但服务器收到此连接报文段以后，就会误认为这是服务端再次发送的新的连接请求，于是向客户端发出确认报文段，同意建立连接，假设不采用三次握手，那么只要服务端发送回确认报文段，新的连接就建立了，由于此时客户端并没有发出新的建立连接的请求，因此它不会理睬服务端的确认，也不会向服务端发送数据，但服务端却以为新的连接已经建立，并一直等待客户端发来数据，这样服务端的资源其实就被白白浪费掉了；

采用三次握手可以防止这种现象的发生，因为需要三次交互，服务端收不到来自客户端的确认信号，就不会建立连接一直等待，浪费自己的资源；

四次分手的过程（客户端用A表示，服务器端用B表示）

由于TCP连接时是全双工的，因此每个方向都必须单独进行关闭。这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的链接。收到一个FIN只是意味着这一方向上没有数据流动，既不会在收到数据，但是在这个TCP连接上仍然能够发送数据，直到这一方向也发送了FIN，首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭。

前提：A主动关闭，B被动关闭
在这里插入图片描述

为什么需要四次挥手

有人可能会问，为什么连接的时候是三次握手，而断开连接的时候需要四次挥手？

这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN 报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。