TCP的三次握手和四次挥手

三次握手

握手的最终目的是主机之间建立连接

首先要有两个预备知识点

1. 三次握手建立连接不一定会成功，其中最担心的就是最后一次握手失败，不过会有配套的解决方案
2. 建立好连接后是需要被操作系统统一管理起来的。也就是说连接不是随便一连就完事了，操作系统会经过描述组织后管理起来每一次的连接，又因为维护是需要成本的因而连接并不是建立多少个都可以的

对现实生活来说，都是客户端主动去向服务端请求连接。

1. 第一次握手：客户端向服务端发送连接请求，TCP报文是有类型的，请求建立连接则TCP报头的SYN置1，也就是发送SYN类型的报文，代表申请连接。当客户端发出请求后，此时的状态为SYN_SENT
2. 第二次握手：服务端接收到请求，由于应答机制则会返回应答，且应答中有着同意连接的响应，因而服务端返回的报文类型为SYN和ACK。当客户端接收到应答时，注意此时的客户端就已经认为连接成功了，但是服务端并没有认为连接成功，对于TCP而言两端是独立的。当服务端发出应答后，状态为SYN_REVD
3. 第三次握手：客户端接收到应答后，再向服务端返回一次应答。当服务端接收到应答之后，才会认为连接成功了

那么问题来了，既然三次握手可以建立连接，那么一次，两次，四次等可不可以呢

1. 对于一次和两次而言：上述提到了建立连接后操作系统需要对每个连接维护起来，那么维护需要成本。如果只有一次握手，那么客户端每一次发送请求后，服务端一收到就建立连接成功了。那么如果有很多客户端都发来请求，那么服务端就会承受不住这么多连接了，这就会出现安全问题导致SYN洪水问题。并且一次两次握手都只能单向的建立连接，不能确保可靠性。一次握手时，客户端没有收到服务端的应答，就不知道服务端收到了请求并已经建立好连接了。两次握手时，服务端没有收到客户端的应答，就不知道客户端已经收到了响应并建立好了连接
2. 那么对于三次以上：其实三次以上的握手都是可以的，因为都能确保双向收到应答确保可靠性。但是这样建立连接的效率不高，时间会更长，因为网络通信是需要成本的。

因此，三次握手是可以用最小的成本验证是否建立好连接，并且可以有效的防止单机进行对服务器的攻击

四次挥手

挥手的最终目的是：为了断开主机间的连接

1. 第一次挥手：主动断开连接端向被动断开连接端发送FIN类型报文，代表不再发送数据，需要断开连接。
2. 第二次挥手：被动断开连接端收到主动断开连接端的请求，返回应答，此时被动断开端为CLOSE_WAIT状态。
3. 第三次挥手：被动断开端向主动端发送FIN类型报文，代表不再发送数据，断开连接。此时被动端为LAST_ACK状态
4. 第四次挥手：主动段收到报文后，向被动端发送应答。主动端此时为TIME_WAIT状态。被动端收到应答后，至此四次挥手完成，连接全部断开

注意上述的不再发送数据，这里的数据指的是用户数据，也就是报文中的有效载荷。因为底层还是会交互管理的报文，只不过是上层会关闭掉套接字文件

主动断开连接端挥手的最终的状态为TIME_WAIT。被动断开连接段两次挥手后会变为CLOSE_WAIT状态

和双方谁是客户端谁是服务端没有关系，在TCP看来两端的地位是平等的

TIME_WAIT

主动断开连接端在挥手完成后需要保持一段时间的TIME_WAIT状态，为什么呢？

1. 为了尽量确保最后一次的ACK被对方收到
2. IME_WAIT状态允许操作系统完全释放与TCP连接相关的资源，比如可以在释放该连接的所有相关资源之前确保该连接在网络中的所有数据已经被删除
3. 如果一个新的TCP连接想要使用与之前CLOSED状态的连接相同的源IP地址和源端口号，而且该连接的目的IP地址和目的端口号与刚关闭的连接相同，那么TIME_WAIT状态可以防止旧连接的数据干扰新连接的数据。

TIME_WAIT状态一般会维持 2 * MSL的时间

MSL：报文的最大寿命，以防止TCP报文在网络中循环传递，避免网络拥塞或因网络故障导致报文无法到达目的地。根据操作系统的 不同值不同，在Centos7中默认为60s。

因此如果是服务器在连接过程中关闭了进程，那么就是服务器主动断开连接，此时是不能够立即重启该端口的。但是也有办法可以立即重启

调用setsockopt接口，设置socket描述符的选项SO_REUSEADDR为1， 表示允许创建端口号相同但IP地址不同的多个socket描述符

#include           /* See NOTES */
#include 

int setsockopt(int sockfd, int level, int optname,
              const void *optval, socklen_t optlen);

CLOSE_WAIT

CLOSE_WAIT状态的维持是非常短暂的，只要被动断开端发出断开请求后，这个状态就没有了，也就是第三次挥手。

如果服务器中出现大量的CLOSE_WAIT，这种情况可能是因为

1. 出现bug，没有做出关闭套接字文件描述符
2. 服务器压力太大，可能一直在给客户端推送数据，来不及关闭文件

如果这个状态出现的太久，可能会导致资源浪费和连接数量上限的问题。

使用wireshark观察

首先观察握手过程

再看看挥手过程

为什么会只出现3次挥手呢?

实际上是因为TCP具有捎带应答机制，导致第二和第三次挥手重叠在一起了。