【Linux网络】————详解TCP三次握手四次挥手
作者主页： 作者主页
本篇博客专栏：Linux
创作时间 ：2025年5月14日
一、TCP三次握手四次挥手介绍
TCP使用三次握手来进行建立连接，四次挥手来终止连接，为何连接还要这么麻烦呢，那是因为这样可以确保建立和终止的可靠性，在网络通信中保护数据的完整性和可靠性，后文会有更加详细的解释
二、三个标记位
在学习三次握手和四次挥手之前，我们线连接一下三个标记位：
- SYN：用于建立连接的初始握手，三次握手开始的时候，建立连接的一方会发送SYN报文段给服务器，用于请求建立连接
- ACK：用于确认数据的传输，当成功收到数据之后，接收方会放松一个ACK报文段给发送方，用于表示我已经接收连接请求
- FIN：用于关闭连接。当发送方发送完所有数据后，会发送一个带有FIN标记的报文段，请求关闭连接。接收方在收到FIN报文段后，发送一个带有ACK标记的报文段进行确认，并使用一个定时器在一段时间后关闭连接。
这三个表记为会在TCP的三次握手和四次挥手频繁被用到，我们这里先了解一下其概念和用户，后续会结合实际的三次握手和四次挥手进行再次补充讲解。
三、三次握手和四次挥手的过程详解
3.1三次握手
我们在编写网络代码时，所用到的 connect 函数，就是在建立连接。而这个连接是怎么被建立起来的呢？具体可看下图
我们对上面图中三次握手的过程进行一个详解：
- 第一次握手：第一次握手是客户端向服务器发送一个SYN请求，用于请求建立连接，此时的客户端处于状态
- 第二次握手：是服务器收到SYN请求之后，向客户端发送一个SYN+SAK报文，表明服务器收到了客户端的请求并且同意客户端建立连接的请求，此时服务器处于SYN_RCVD状态
- 第三次握手，也是最后一次握手，是客户端向服务器发送一个ACK报文，表示客户端收到服务器的同意建立连接，并告诉服务器我收到了你的确认，同时此时客户端会处于ESTABLISHED状态。
到此，三次握手全部结束，最后当服务器说到客户端的AKC报文之后，也会处于ESTABLISHED状态
但是你怎么确定客户端和服务端接收到的ACK和SYN报文就是一一对应的呢？不要忘记了还有序号和确认序号！具体如下图：
那么三次握手之后连接就一定建立成功了嘛？
当热是不一定！因为我们可以发现，第一次挥手和第二次挥手都有了对应的确认收到的回应，第三次没有。有没有如下一种可能：前两次握手成功了，到第三次握手发出后，服务端并没有收到响应的报文，也就是丢包了！这时即使三次握手完成，连接也并没有建立成功！
所以真正的建立连接成功的标志是客户端于服务器都处于了ESTABLISHED状态
握手时产生的状态是什么意思
可能你在想：怎么理解这些状态呢？这些状态的意义是什么呢？结合进程的状态（就绪、阻塞、挂起等等），状态就是说明你目前所处于什么阶段，干了什么东西，接下来需要怎么做。我们再看握手时所产生的三个状态（SYN_SENT和SYN_RCVD和ESTABLISHED状态）所代表的含义。
- SYN_SENT(同步已发送)状态：当客户端在建立TCP连接时发送一个SYN(同步)报文段之后，进入SYN_SENT状态，在此状态下，客户端会等待服务器回复确认报文段(ACK)以及确认序号(SYN+1)，这个状态就表明已经发送了连接请求但是还没有收到回复
- SYN_RCVD(同步已接收)状态：服务器在接收到客户端发送的SYN报文段后，会发送回一个SYN+ACK（同步+确认）报文段作为响应，并进入SYN_RCVD状态。在此状态下，服务器会等待这客户端回复最后的(ACK)确认报文段，以完成连接的建立，这个状态表明已经接收到连接请求，但还未收到客户端确认。
- ESTABLISHED(已建立)状态：在TCP连接成功建立之后，双方会同时处于ESTABLISHED状态，在该状态下，双方可以互相发送数据。所以这个状态就表示双方建立成功可以开始传输数据
总结：
1.SYN_SENT状态就是客户端已经向服务器发送建立连接请求，但还未收到服务器的确认
2.SYN_RCVD状态就是服务器已经收到了客户端的连接请求，并且已经向服务器发送同意的报文段，但是还没接收到客户端的确认
3.ESTABLISHED状态就表示服务器与客户端双方已经成功建立连接，可以开始传输数据
为什么是三次握手
一次握手：因为如果只有一次握手的话那么我们无法确定双方的发送和接收能力是否都是正常的，无法确认对方是否能收到自己发送的数据
两次握手：两次握手也是不可以的，因为两次握手之后只有客户端知道对方可以收到自己的数据，可是服务器无法确认客户端是否收到了自己的数据两次握手也无法确认双方的初始序列号是否正确，因为第二次握手没有其对应的确认序列号
所以三次握手就可以规避掉上面的这些不足，所以必须是三次握手
3.2 四次挥手
TCP中的四次挥手是用来关闭连接的。我们平常所写的 close（sock），就是用来关闭连接的。注意：关闭连接是两端的事情，并不是一端的事情。四次挥手的过程如下：
四次挥手的具体过程如下：
- 第一次挥手：客户端向服务器发送一个FIN(断开)请求，表示客户端不会再发送数据，此时客户端会处于FIN_WAIT_1状态
- 第二次挥手：服务器收到请求后，会回复一个ACK响应确认，但这个响应可能还携带为传输完的数据，此时服务器处于CLOSE_WAIT状态，注意在第三次挥手之前，数据还是可以从服务器传向客户端的。
- 第三次挥手：服务器完成数据传输之后，向客户端发送一个FIN请求，表示服务器没有数据再要传输了，此时服务器变为LAST_ACK状态
- 第四次挥手：客户端说到服务器的请求之后，回复服务器一个ACK确认响应，此时服务器会处于TIME_WAIT状态，需要经过一段时间确认服务器收到了自己的应答报文之后，才会进入CLOSED状态。
到这里，四次挥手就结束了，最后，服务器说到AKC应答报文之后，也会关闭连接，处于CLOSED状态
TIME_WAIT状态和CLOSE_WAIT状态
TIME_WAIT状态和CLOSE_WAIT状态是较为重要的两个状态，其中也是有一些细节需要我们去理解的。具体如下：
1.TIME_WAIT状态：
- 发起方(主动关闭连接的一方)在发送最后一个ACK报文包之后，会进入TIME_WAIT状态
- 在TIME_WAIT状态，该连接处于等待状态，以确保网络中任何未完成或延迟的分节可以到达目的地，确保对方已经收到并且处理了FIN包，在这段时间内，该连接会进入TIME_WAIT状态
- TIME_WAIT状态的持续时间通常是2倍的最大保文存活时间MSL
- MSL是指IP数据在网络中的最长寿命，它是任何文段在被丢弃前在网络内的最长时间，超过这个时间这个报文将被丢弃，根据协议的不同，MSL的时间长短也不同
- 进入TIME_WAIT报文段的目的就是确保已经关闭的所有连接的分节在网络中都消失，以防止与新的连接混淆
- 在TIME_WAIT期间，这个套接字不会被新的连接所使用，所以会占用一定的系统资源
2.CLOSE_WAIT状态：
- 当对方(被断开连接的一方)收到关闭连接的请求并发送ACK确认包之后，会处于CLOSE_WAIT状态
- 在CLOSE_WAIT状态期间，目标端继续等待应用程序关闭套接字
- 通常来说，如果被动端意识到应用程序没有正常关闭套接字，他可能会发送一条警告信息来通知应用程序关闭套接字
- 如果被动关闭连接的一方未能正确关闭套接字，CLOSE_WAIT会一直持续下去，导致资源泄露
为什么要存在 TIME_WAIT 状态
TIME_WAIT状态的存在是为了保证网络通信的可靠性和避免出现连接复用问题。以下是一些TIME_WAIT状态的原因：
- 可靠关闭连接：TIME_WAIT状态是为了保证连接被完全关闭而引入的，在TCP的四次握手中，最后一次发送FIN报文之后，需要等待一段时间，以确保对方成功收到并且处理了FIN包，这样可以防止出现半开连接状态，从而避免数据传输混乱
- 避免连接复用：TIME_WAIT同样可以防止因为旧的连接信息仍然存在在网络中而导致的连接复用问题，假设一个新连接使用了与之前相同的源IP、源端口、目标IP和目标端口，如果该连接处于TIME_WAIT状态，那么它能够阻止新连接接收到之前连接的延迟数据包，避免数据包错乱，确保连接的稳定性和可靠性
- 处理网络拥塞：
TIME_WAIT状态还可以帮助处理网络拥塞。当大量连接同时关闭时，TIME_WAIT状态可以将关闭的连接延迟释放，避免短时间内有大量CLOSE_WAIT连接并发导致系统资源过度消耗；同时，TIME_WAIT状态也可以防止新连接的第一次握手和旧连接的最后
为什么有时候连接时端口号被占用
你可能也遇到过这种情况：刚刚还能够正常连接呢，怎么现在突然说端口号被占用了呢？原因就是客户端在进行第四次挥手后，进入了TIME_WAIT 状态，该状态是需要等上一段时间的。在等待的过程中，套接字不会被分配给其他连接使用，其该客户端的端口号依然是被处于使用的状态。
什么情况下会有大量的CLOSE_WAIT状态
在CLOSE_WAIT状态下，被动关闭连接的一方会一直等待对方读取数据或关闭连接。如果长时间处于，可能会导致资源浪费和连接堆积。因此，如果应用程序开发者没有正确处理接收到的数据或关闭连接，可能会导致CLOSE_WAIT状态的积累。 根本原因就是在于被动关闭方没有进行第三次挥手，也就是没有正确关闭自己的套接字（sockfd）。
举个例子：如果我们发现服务器具有大量的close_wait状态的连接的时候。原因是服务器写的有bug，忘了关闭对应的连接sockfd。时间长了服务就可能崩溃了。
为什么等待时间是2MSL
可能会有如下情况：服务器可能没有收到最后一段ACK报文，也就是ACK报文丢包了。此时就会触发超时重传。服务器会再次发送FIN报文。当客户端再次收到FIN报文，客户端就知道刚刚发送的ACK丢失，需要再次发送。
如果在等待TIME_WAIT期间，客户端并没有在收到任何报文，就一定表明回收成功了吗？也不一定。网络的情况很复杂，也有可能网络阻塞等原因，即使服务器触发了超时重传，客户端也不一定能收到，只是概率比较小。等待TIME_WAIT，只是减少出现错误的概率，并不能百分百保证。
setsockopt 函数
在有些情况下，服务器断开连接后是等不了的啊（不希望进行等待）。例如，淘宝的双十一枪货，等待一分钟可是巨大的损失。这时我们可以用到setsockopt 函数。函数原型如下：
int setsockopt(int sockfd, int level, int optname, const void *optval, socklen_t optlen);
- sockfd：套接字描述符，即要设置选项的套接字。
- level：选项所属的协议层。常见的协议层包括SOL_SOCKET（通用套接字选项）、IPPROTO_TCP（TCP选项）、IPPROTO_IP（IP选项）等。
optname：选项的名称或标识符，用来指定要设置的具体选项。例如，对于SOL_SOCKET协议层，可以设置的选项包括SO_REUSEADDR（地址重用）、SO_RCVBUF（接收缓冲区大小）等。
- optval：指向存放选项值的缓冲区的指针。
- optlen：指定optval缓冲区大小的长度。
下面是一些常用的选项和对应的解释（了解）：
SOL_SOCEKT选项：
- SO_REUSEADDR：允许重用本地地址和端口。
- SO_REUSEPORT：允许多个套接字绑定到同一个端口。
- SO_KEEPALIVE：启用对端的活动检测。
- SO_BROADCAST：允许发送广播消息。
- SO_RCVBUF和SO_SNDBUF：设置接收和发送缓冲区大小。
2.IPPROTO_TCP选项：
- TCP_NODELAY：禁止Nagle算法，允许小数据报立即发送。
- TCP_MAXSEG：设置TCP报文段的最大长度。
- TCP_KEEPIDLE、TCP_KEEPINTVL和TCP_KEEPCNT：用于启用和配置TCP的保活功能。
3.IPPROTO_IP选项：
- IP_TOS：设置IP报文的服务类型。
- IP_MULTICAST_TTL：设置组播数据包的TTL值。
最后：
十分感谢你可以耐着性子把它读完和我可以坚持写到这里，送几句话，对你，也对我：
1.一个冷知识：
屏蔽力是一个人最顶级的能力，任何消耗你的人和事，多看一眼都是你的不对。
2.你不用变得很外向，内向挺好的，但需要你发言的时候，一定要勇敢。
正所谓：君子可内敛不可懦弱，面不公可起而论之。
3.成年人的世界，只筛选，不教育。
4.自律不是6点起床，7点准时学习，而是不管别人怎么说怎么看，你也会坚持去做，绝不打乱自己的节奏，是一种自我的恒心。
5.你开始炫耀自己，往往都是灾难的开始，就像老子在《道德经》里写到：光而不耀，静水流深。
最后如果觉得我写的还不错，请不要忘记点赞✌，收藏✌，加关注✌哦(｡･ω･｡)
愿我们一起加油，奔向更美好的未来，愿我们从懵懵懂懂的一枚菜鸟逐渐成为大佬。加油，为自己点赞！
本文地址：https://www.vps345.com/10703.html
