有限状态机&Time_wait的解读

一、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）

二、为何须要三次握手

1）合并了链接确认和链接请求，如图上的2

2）最后一次的ACK，防止了已失效的链接请求报文

   （client向server发送了SYN链接请求报文，可是因为链路问题，滞留好久，client认为这个报文丢失因而又重传了一次；而在新链接过 

      程中，server收到了这个消失好久的报文，若是没有三次握手，server就认为这是一个新链接，因而链接创建，server会向这个新链接

      发送的数据都不会被client处理，server这样就浪费了不少资源）

三、为何须要四次挥手

1）FIN报文和ACK报文是成对的，而且能够容许有半关闭的状况；一方关闭了本身的发送方向，不在发送数据；可是另一方还有数据想要发送，这个时候是能够不发送FIN报文，继续发送数据到对端，对端只不过是关闭了发送方向，接收方向依然能够接收数据

四、time_wait必须等待2MSL时间的理由

1）为了保证主动关闭一方发送的最后一个ACK报文能过到达被动关闭的一方

    （由于这个报文有可能丢失，因此被动关闭的一方有可能重传FIN报文，而后主动一方在2MSL中能收到这个重传的报文，A在确认一次

       并重启2MSL）

2）防止“已失效的链接请求报文”，和上面的三次握手中最后一个ACK必须有的那种状况同样，若是在2MSL中那个链接请求报文到了，咱们不对这个迟到的报文作处理，让其消失；不会让此次释放链接完成后，还有旧的链接请求存在。