TCP的三次握手和四次挥手

最新推荐文章于 2022-07-10 16:28:08 发布

小熙同学-

最新推荐文章于 2022-07-10 16:28:08 发布

阅读量244

点赞数

分类专栏：网络

本文链接：https://blog.youkuaiyun.com/wzt888_/article/details/83616382

版权

网络专栏收录该内容

8 篇文章

订阅专栏

本文详细介绍了TCP协议中建立连接的三次握手过程和断开连接的四次挥手机制，包括为何需要三次握手和四次挥手，以及在挥手过程中可能出现的问题和状态转换。同时探讨了TIME_WAIT状态的作用以及TCP与UDP协议的区别。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

1.三次握手

概念：所谓“三次握手”就是TCP连接建立的过程，即需要客户端与服务端总共发送三个包，以确认连接的建立。

意义：通过“三次握手”保证了客户端与服务器建立的是双工连接，而可靠性是更多是通过重发机制实现的。

其它：在Socket编程中，这一过程由客户端执行connect来触发。

在这里插入图片描述

 (1) 第一次握手：建立连接时，客户端A发送SYN包(SYN=j)到服务器B，并进入SYN_SEND（请求连接）状态，等待服务器B确认。

 (2) 第二次握手：服务器B收到SYN包，必须确认客户A的SYN(ACK=j+1)，同时自己也发送一个SYN包(SYN=k)，即SYN+ACK包，此时服务器B进入SYN_RECV状态。

 (3) 第三次握手：客户端A收到服务器B的SYN＋ACK包，向服务器B发送确认包ACK(ACK=k+1)，此包发送完毕，客户端A和服务器B进入ESTABLISHED状态，完成三次握手。

完成三次握手，客户端与服务器开始传送数据。

2.四次挥手

概念：所谓“四次挥手”就是关闭TCP连接的过程，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认双方连接的断开。

意义：同样是保证TCP连接的全双工连接。

其它：在socket编程中，这一过程由客户端或服务端任一方执行close来触发。

1、第一次挥手：客户端发送一个FIN包（FIN=1，随机产生一个值给seg，seg=u）给服务器端，用来关闭客服端到服务器端的数据传输，客户端进入FIN_WAIT_1状态。

2、第二次挥手：服务器端收到FIN包后，发送一个ACK包（ACK=1，ack=u+1，在随机产生一个值给seg，seg=v）给客户端，客户端进入CLOSE_WAIT状态。

3、第三次挥手：服务器端发送一个FIN包（FIN=1，ACK=1，ack=u+1，在随机产生一个值给seg，seg=w）给客户端，用来关闭服务器端到客户端的数据传输，服务器端进入LAST_ACK状态。

4、第四次挥手：客户端接收FIN包，然后进入TIME_WAIT状态，接着发送一个ACK包（ACK=1，seq=u+1，ack=w+1）给服务器端，服务器端确认序号，进入CLOSED状态，完成四次挥手。

在这里插入图片描述
上述挥手过程是一方主动，另一方被动，然而有一定可能性是，双方同时主动申请关闭连接，这种情况流程图如下：

3. 其它问题

1.为什么不能用两次握手进行连接？

  我们知道，3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要
允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
  现在把三次握手改成仅需要两次握手，死锁是可能发生的。比如，计算机S和C之间的通信，假定C给S发送一个
连接请求分组，S收到了这个分组，并发送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，
可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建
立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S
发来的任何数据分组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

2.为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？

  这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它可以把ACK和SYN（ACK起应答作用
，而SYN起同步作用）放在一个报文里来发送。但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没
有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭SOCKET,也即你可能
还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报
文和FIN报文多数情况下都是分开发送的.

3．为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？

这是因为虽然双方都同意关闭连接了，而且握手的4个报文也都协调和发送完毕，按理可以直接回到CLOSED状态（就好比从SYN_SEND状态到ESTABLISH状态那样）；但是因为我们必须要假想网络是不可靠的，你无法保证你最后发送的ACK报文会一定被对方收到，因此对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文，而重发FIN报文，所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。

4.tcp/IP协议和UDP协议的区别是什么

  TCP协议是有连接的，有连接的意思是开始传输实际数据之前TCP的客户端和服务器端必须通过三次握手建立连接，会话结束之后也要结束连接。而UDP是无连接的
  TCP协议保证数据按序发送，按序到达，提供超时重传来保证可靠性，但是UDP不保证按序到达，甚至不保证到达，只是努力交付，即便是按序发送的序列，也不保证按序送到。
  TCP协议所需资源多，TCP首部需20个字节（不算可选项），UDP首部字段只需8个字节。
  TCP有流量控制和拥塞控制，UDP没有，网络拥堵不会影响发送端的发送速率
  TCP是一对一的连接，而UDP则可以支持一对一，多对多，一对多的通信。
  TCP面向的是字节流的服务，UDP面向的是报文的服务。

5.三次握手建立连接时，发送方再次发送确认的必要性？

  主要是为了防止已失效的连接请求报文段突然又传到了B,因而产生错误。假定出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某些网络结 点长时间滞留了，一直延迟到连接释放以后的某个时间才到
达B，本来这是一个早已失效的报文段。但B收到此失效的连接请求报文段后，就误认为是A又发出一次新的连接请
求，于是就向A发出确认报文段，同意建立连接。假定不采用三次握手，那么只要B发出确认，新的连接就建立了，
这样一直等待A发来数据，B的许多 资源就这样白白浪费了。

6.四次挥手释放连接时，等待2MSL的意义？

  第一，为了保证A发送的最有一个ACK报文段能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态
的B收不到对已发送的FIN和ACK 报文段的确认。B会超时重传这个FIN和ACK报文段，而A就能在2MSL时间内收到
这个重传的ACK+FIN报文段。接着A重传一次确认。
  第二，就是防止上面提到的已失效的连接请求报文段出现在本连接中，A在发送完最有一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。

4. 状态

CLOSED：初始状态。
 
LISTEN：表示服务器端的某个SOCKET处于监听状态，可以接受连接了。

SYN_SENT：表示请求连接，当你要访问其它的计算机的服务时首先要发个同步信号给该端口，此时状态为SYN_SENT，如果连接成功了就变为ESTABLISHED，此时SYN_SENT状态非常短暂。

SYN_RECV：是指服务端被动打开后,接收到了客户端的SYN并且发送了ACK时的状态。再进一步接收到客户端的ACK就进入ESTABLISHED状态。

SYN_RCVD： 这个状态表示接受到了SYN报文，在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态，很短暂，基本 上用netstat你是很难看到这种状态的，除非你特意写了一个客户端测试程序，故意将三次TCP握手过程中最后一个ACK报文不予发送。因此这种状态 时，当收到客户端的ACK报文后，它会进入到ESTABLISHED状态。
 
SYN_SENT： 这个状态与SYN_RCVD遥想呼应，当客户端SOCKET执行CONNECT连接时，它首先发送SYN报文，因此也随即它会进入到了SYN_SENT状态，并等待服务端的发送三次握手中的第2个报文。SYN_SENT状态表示客户端已发送SYN报文。
 
ESTABLISHED：表示连接已经建立了。
 
FIN_WAIT_1： FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。
而这两种状态的区别 是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即 进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马 上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。


FIN_WAIT_2：FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你，稍后再关闭连接。



TIME_WAIT： 表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。


CLOSING：这是一种比较罕见的例外状态。正常情况下，当你发送FIN报文后，按理来说是应该先收到（或同时收到）对方的 ACK报文，再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什 么情况下会出现此种情况呢？其实细想一下，也不难得出结论：那就是如果双方几乎在同时close一个SOCKET的话，那么就出现了双方同时发送FIN报 文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。


CLOSE_WAIT： 这种状态的含义其实是表示在等待关闭。当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对 方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以 close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。


LAST_ACK： 它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。

原文：https://blog.youkuaiyun.com/zhangliangzi/article/details/50695611
原文：https://www.cnblogs.com/zmlctt/p/3690998.html