time_wait
timewait先发起close的一端的第二阶段：
a fin b，b ack a，b fin a 此时a收到b的fin之后，a处于time_wait，a无法确定自己接下来的ack of fin是否被b收到，所以time_wait还是会持续一段时间。接着可能发生两件事情：
- 收到b的fin重传（因为b没有收到ack）
- 相当长一段时间——2MSL，都没有收到b的fin重传
第一种，那么a可以确定第一次的ack没有及时到达b，继续发送ack，直到发生第二种。此时a可以关闭连接，因为在第一个MSL内，a收到的最后一次fin包发送之前的数据包都已经从网络消失，因为这些数据包到此时已经超过了MSL；又继续等待第二个MSL，确保a发送的ack消失之前重发的fin都没有到达a，而且在ack消失的同时对方重发的fin也已经消失——那么说明网络状态要么足够差，重发这么多fin都没有被a收到，要么a的ack已经被b接收。
理解为什么是2MSL的原因：假设网络状态极好，fin的ack立即被对方b接收到，对方立即close，那么此时a应该等待1MSL，因为只有等待这么久才能确保对方close之前的包都已经在网络中超时消失。但是如果ack有延迟T才到达b，那么a应该等待T+MSL；ack实际上最大的延迟是MSL，所以TIME_WAI应该等待2MSL再变成close。
保持2MSL并不是为了解决所有问题，只是为了防止一个问题，那就是防止对方真的close后，还有包在网络中传递，并不是为了确保对方连重传的fin包都消失，实际上应该假设对方重传的fin包一定会被a收到。
再看b的close，应用层在socketclose之后，可能已经进程退出了，只不过内核还有socket的状态在维护，当然进程可能没有退出。