TCP关闭过程
状态迁移
1. SO_LINGER/ SO_REUSEADDR TCP正常的关闭过程如下（四次握手过程）：(FIN_WAIT_1) A ---FIN---> B(CLOSE_WAIT)(FIN_WAIT_2) A <--ACK-- B(CLOSE_WAIT)(TIME_WAIT)A <--FIN---- B(LAST_ACK)(TIME_WAIT)A ---ACK-> B(CLOSED)
? A端首先发送一个FIN请求给B端，要求关闭，发送后A段的TCP状态变更为FIN_WAIT_1，接收到FIN请求后B端的TCP状态变更为CLOSE_WAIT
? B接收到ACK请求后，B回一个ACK给A端，确认接收到的FIN请求，接收到ACK请求后，A端的TCP状态变更为为FIN_WAIT_2。
? B端再发送一个FIN请求给A端，与连接过程的3次握手过程不一样，这个FIN请求之所以并不是与上一个请求一起发送，之所以如此处理，是因为TCP是双 通道的，允许在发送ACK请求后，并不马上发FIN请求，即只关闭A到B端的数据流，仍然允许B端到A端的数据流。这个ACK请求发送之后，B端的TCP状态变更为LAST_ACK，A端的状态变更为TIME_WAIT。
? A端接收到B端的FIN请求后，再回B端一个ACK信息，对上一个FIN请求进行确认，到此时B端状态变更为CLOSED，Socket可以关闭。
?
除了如上正常的关闭（优雅关闭）之外，TCP还提供了另外一种非优雅的关闭方式RST(Reset)
(CLOSED) A ---RST--> B (CLOSED)
? A端发送RST状态之后，TCP进入CLOSED状态，B端接收到RST后，也即可进入CLOSED状态。
在第一种关闭方式上（优雅关闭），非常遗憾，A端在最后发送一个ACK请求后，并不能马上将该Socket回收，因为A并不能确定B一定能够接收到这个ACK请求，因此A端必须对这个Socket维持TIME_WAIT状态2MSL(MSL=Max Segment Lifetime，取决于操作系统和TCP实现，该值为30秒、60秒或2分钟)。如果A端是客户端，这并不会成为问题，但如果A端是服务端，那就很危险了，如果连接的Socket非常多，而又维持如此多的TIME_WAIT状态的话，那么有可能会将Socket耗尽（报Too Many Open File）。
服务端为了解决这个问题，可选择的方式有三种：
? 保证由客户端主动发起关闭（即做为B端）
? 关闭的时候使用RST的方式
? 对处于TIME_WAIT状态的TCP允许重用
一般我们当然最好是选择第一种方式，实在没有办法的时候，我们可以使用SO_LINGER选择第二种方式，使用SO_REUSEADDR选择第三种方式
