注：本文分析基于3.10.107内核版本

其实TIME_WAIT定时器是挺奇怪的，从名字上来看，是在socket进入TIME_WAIT之后工作的，但实际上并不是，或者说不全是，因为在FIN_WAIT2上也会使用TIME_WAIT定时器，正如之前讲述FIN_WAIT2定时器所描述。

下面我们就来谈一谈TIME_WAIT定时器。

其实TIME_WAIT定时器由两个定时器构成，在全局变量tcp_death_row中定义

分别是慢速定时器tw_timer和再生定时器twcal_timer。其他的我们先按下不表，容后道来，我们先看下有哪些情况会使用到TIME_WAIT定时器。

关于TIME_WAIT定时器的触发，一共有5个场景。其实可以通过查询tcp_time_wait()函数的调用就能看到是哪5个场景。

1、在FIN_WAIT2状态下调用close()。但是我不太明白，socket是怎么进入FIN_WAIT2状态的，正常不就是调用close()吗，为什么还能在FIN_WAIT2状态再调用close()?求大神指教。

2、这个场景是比较正常的，在FIN_WAIT2状态下收到对端的FIN报文，发送完最后一个ACK报文之后就进入TIME_WAIT状态。

3、这个场景是在FIN_WAIT2状态下工作的。在接收到对端对FIN报文的回复后，且tcp_fin_timeout的值 TCP_TIMEWAIT_LEN) { //这里便是FIN_WAIT2定时器的激活 inet_csk_reset_keepalive_timer(sk, tmo - TCP_TIMEWAIT_LEN); } else if (th->fin || sock_owned_by_user(sk)) { ... } else { tcp_time_wait(sk, TCP_FIN_WAIT2, tmo);//这里是进入TIME_WAIT定时器了 goto discard; } } } break; ... } } ... }

4、这个场景就是在客户端和服务端同时关闭的时候触发的，双发都进入CLOSING状态，此时收到对端的FIN-ACK报文，就进入TIME_WAIT状态。

5、这个场景就是刚才说的更怪的了，它和FIN_WAIT2定时器一前一后，一起工作。它是在FIN_WAIT2定时器的超时函数里触发，同时要求tcp_fin_timeout的值大于60s。而且，超时时间是(tmo - 60)，和FIN_WAIT2定时器的超时时间一样。也就是同一个超时时间先后在两个定时器里使用。不知道为何这么使用，有何用意，请大伙赐教。

理完这些触发场景，我们来看看tcp_time_wait()到底做了啥。

可以看到，socket进入TIME_WAIT状态后，协议栈生成了一个tw sock代替socket存放在hash表中。tw sock占用空间比socket小，能从一定程度上节约内存空间。而定时器的触发设置都在inet_twsk_schedule()函数。

由上可知，慢速定时器和再生定时器的管理都是一样的，利用循环队列的方式，将tw sock按照超时时间挂在不同超时时间的slot上。不同的地方主要有以下几点：

1、管理的tw sock的超时时间

由上可知，slot和INET_TWDR_RECYCLE_TICK有关，它的定义和系统时钟中断HZ相关，定义如下：

从全局变量tcp_death_row中定义可知，慢速定时器的超时处理函数为inet_twdr_hangman()，再生定时器的超时处理函数为inet_twdr_twcal_tick()。先看慢速定时器的处理。

总体就是每隔7.5s遍历一次slot队列，因为slot的时间间隔也是7.5s，所以定时器超时后，这个slot的tw sock肯定是都已经超时，删除就好。

同样，对于再生定时器操作也差不多，只不多定时器周期不一样。