记得之前写过一篇文章，详细讲解了TIME_WAIT和CLOSE_WAIT，堪称史上“最详细易懂”的讲解TIME_WAIT的文章，如果你还没有看过，很值得你再次阅读：高性能网络
你所不知道的TIME_WAIT和CLOSE_WAIT
话说，今天就偏偏撞在了这个枪口上。最近两周，一直有产品人员包括开发在抱怨：有时候在公司访问我们的网站，怎么也打不开，页面空白加载很长的时间，但是过段时间，又好了。包括我自己也遇到过两次，开开Chrom的开发工具，发现第一个网络请求connct很久也连接不上，但是关闭再打开，访问又是soso的快。
赶紧去检查了监控，一切正常：CPU正常，内存正常，网络流量以及I/O都是正常。仔细排查了Ngnix的访问日志，里面记录的rsp_tim和upstram_tim也都是毫秒级。心里琢磨着，难道是什么地方死锁了？或者？网络问题？
赶紧把网络切换到手机的4G网络去测试，一次也没遇到打不开的情况。回到公司外的网络，访问一段时间，也很稳定。然后，虽然心里隐约觉得一定是什么地方有问题，但是，另一个潜意识还是引导自己说：绝逼的公司网络问题啊！！！
当你觉得隐约还是有问题的时候，这个问题往往也逃不掉。也就在昨天，另一个项目组的同事给我电话，一个私有部署的环境，在部署了我们的服务以后，QA常常无法打开网站，奇慢无比，但是过一下又好了。
这个现象让我立即重视起这个问题来。就算是公司的网络问题，也要找个证据，把责任推出去呀。然后开始行动，我SSH到服务器上，等待问题重现。当项目组QA有人无法打开的时候，立即