1、TCP有限状态机
其中各状态的含义：
| 状态 | 含义 |
| closed | 初始状态 |
| listen | 被动打开一方——监听状态 |
| syn_sent | 主动打开一方——连接建立已发送 |
| syn_rcvd | 被动打开一方——连接建立已接收 |
| established | 双方——连接已经建立 |
| fin_wait1 | 主动关闭一方——FIN已发送，等待确认 |
| fin_wait2 | 主动关闭一方——确认已收到，等待对方关闭请求 |
| time_wait | 主动关闭一方——最后的确认已经发送，需要等待2MSL |
| close_wait | 被动关闭一方——询问我方进程是否还有数据要发送，没有也要发送FIN进行关闭 |
| last_ack | 被动关闭一方——我方的fin已经发送，想要收到你的最后的确认 |
| closing | 主动关闭一方——在发送完FIN之后没有收到确认但是收到了对端的FIN （场景：同时发送的FIN） |
2、为什么需要三次握手
1）合并了连接确认和连接请求，如图上的2
2）最后一次的ACK，防止了已失效的连接请求报文
（client向server发送了SYN连接请求报文，但是由于链路问题，滞留很久，client认为这个报文丢失于是又重传了一次；而在新连接过
程中，server收到了这个消失很久的报文，如果没有三次握手，server就认为这是一个新连接，于是连接建立，server会向这个新连接
发送的数据都不会被client处理，server这样就浪费了很多资源）
3、为什么需要四次挥手
1）FIN报文和ACK报文是成对的，并且可以允许有半关闭的情况；一方关闭了自己的发送方向，不在发送数据；但是另外一方还有数据想要发送，这个时候是可以不发送FIN报文，继续发送数据到对端，对端只不过是关闭了发送方向，接收方向依然可以接收数据
4、time_wait必须等待2MSL时间的理由
1）为了保证主动关闭一方发送的最后一个ACK报文能过到达被动关闭的一方
（因为这个报文有可能丢失，所以被动关闭的一方有可能重传FIN报文，然后主动一方在2MSL中能收到这个重传的报文，A在确认一次
并重启2MSL）
2）防止“已失效的连接请求报文”，和上面的三次握手中最后一个ACK必须有的那种情况一样，如果在2MSL中那个连接请求报文到了，我们不对这个迟到的报文做处理，让其消失；不会让这次释放连接完成后，还有旧的连接请求存在。