本节我们来介绍TCP连接的建立和断开。我们主要介绍两个过程、两个状态。

两个过程即三次握手和四次挥手；两个状态指TIME_WAIT和COLSE_WAIT状态。

我们本节，会始终围绕着这张图来展开：

三次握手

我们还是按照列点是来分析，这样会使得条理比较清晰：

1、当客户端向服务器发起第一次请求（SYN）时，其自身就会处于一种SYN_SEND的状态（即等待发送）

2、处于listen状态的服务器接收到客户端发起的请求之后，会进入SYN_RCVD状态（即等待接收）

3、服务器向客户端发出SYN+ACK，服务器收到之后，由原来的SYN_SEND状态变为ESTABLISED（连接）状态。

4、当服务器收到这个ACK之后，便同样会进入到ESTABLISED状态

过程比较简单，就是上述那样。

【注意】

链接本身是有成本的：耗费空间+时间，而TCP是面向连接的，即三次握手成功之后，需要client和server共同维护

注意到，我们这里的ACK和SYN有一次压缩起来了，所以如果硬要说的话，是四次握手，但是其默认都是压缩起来了，所以我们就按照三次握手来说。

a.那为啥是要有三次握手？一次、两次、四次不行？

首先一次肯定是不行的，为什么呢？如果发出去一个SYN就算建立连接了，那这和udp有什么区别呢，即便服务器没有拿到这个SYN请求，我的客户端已经认为建立连接了？况且服务器连接的维护是需要成本的。如果一次就建立连接的话，如果一个恶意软件在短时间内对我进行大量的SYN，那我的服务器不就崩掉了？

b.那两次呢？

如果是这样的话，那服务器发回去一个ACK之后，它就直接认为自己建立连接了。这本质上和一次握手并没有什么差别。

一次和两次握手极容易收到SYN洪水攻击：无条件的发SYN就建立连接的话，那我大量的发SYN，服务器就直接挂掉了。

c.那为什么要三次呢？

我们说TCP是全双工的，所以，双方在通信之前，需要讲信道的状况验证一下是否通畅。即客户端和服务器都至少有一次收、有一次发。  故：用最小的成本验证全双工。

如果是四次握手的话，那前三次的报文丢失我们不怕，但是第四次的报文我们还是害怕丢失的，多这个一次就没有意义了。更多的也是一样的道理。（并且不要让服务器出现连接建立误判的清空，从而减少服务器的资源浪费）

我们再来说说四次挥手

四次挥手

首先，为什么要四次挥手？理由很简单：

TCP是全双工的，即服务器和客户端二者是双向的，地位是对等的。那么二者都要断开连接，客户端关闭后，服务器给个ACK，服务器关闭后，客户端再给个ACK。

即我们双方达成共识之后才可以断开连接。（一定是双方都断开了连接）

【四次挥手的状态变化】

1、当我将断开连接的FIN发出去之后，我就进入了FIN_WAIT_1状态。

2、服务器返回ACK（这里的ACK还是可以携带数据的），然后服务器进入CLOSE_WAIT状态。（关闭等待）

此时，我们认为客户端向服务器的通信信道关闭了，即客户端就不会再给服务器发送数据了。即在客户都应用层表现为close(sock)。

3、客户端在收到服务器的ACK后，就处于FIN_WAIT_2状态。

4、紧接着，服务器给客户端又发了一个FIN，表示服务器也要关闭自己到客户端的信道。这个时候，服务器进入到LAST_ACK状态。

5、在客户端收到服务器的FIN之后，再次向服务器发送ACK，此时，客户端进入TIME_WAIT状态。

6、当客户端经历了一段时间之后，由TIME_WAIT状态进入CLOSE状态

我们来重点说说两个状态：CLOSE_WAIT和TIME_WAIT

主动断开的一方会最终进入TIME_WAIT状态，而另一方如果不关闭连接，则会处于CLOSE_WAIT状态。

【CLOSE_WAIT】

为什么会进入到CLOSE_WAIT状态？本质上就是因为你的代码有bug——没有把使用完的套接字关掉。这样会浪费大量的系统资源

（半关闭问题）

就是服务器先退出了。但是客户端还没有退出。

解决方法：很简单，把你的socket文件描述符close掉就行了。

【TIME_WAIT】

对于最后一个ACK，其也是有可能丢失的。

可是在发送完ACK后，假如没有这个TIME_WAIT，客户端会认为连接已经断开，然后释放连接资源。那这个ACK丢失了怎么办？我们的服务器会进行超时重传。可是这个时候客户端已经把连接关了。那么这个服务器会一直挂在LAST_ACK的状态，就会浪费服务器的资源。

所以就衍生出了TIME_WAIT。就是客户端（主动断开连接的一方）先等等，等待的意义：

（1）防止最后一个ACK丢失，进而尽快释放服务器的资源；（2）等待历史数据在网络上消散，即有可能通信结束的报文优先收到，之前还有数据（历史数据）没有被客户端收到。

（等待的时间是通信一个来回最多花费的时间：2MSL）

如果服务器重传了若干次都没有响应，那其也就强行关闭了。（但是这种情况是比较小的）

在server的TCP连接没有完全断开之前不允许重新监听, 某些情况下可能是不合理的：

1、服务器需要处理非常大量的客户端的连接(每个连接的生存时间可能很短, 但是每秒都有很大数量的客户端来请求).

2、这个时候如果由服务器端主动关闭连接(比如某些客户端不活跃, 就需要被服务器端主动清理掉), 就会产生大量TIME_WAIT连接.

3、由于我们的请求量很大, 就可能导致TIME_WAIT的连接数很多, 每个连接都会占用一个通信五元组(源ip,源端口, 目的ip, 目的端口, 协议). 其中服务器的ip和端口和协议是固定的. 如果新来的客户端连接的ip和端口号和TIME_WAIT占用的链接重复了, 就会出现问题

使用setsockopt()设置socket描述符的 选项SO_REUSEADDR为1即可, 表示允许创建端口号相同但IP地址不同的多个socket描述符