TCP古董TIME_WAIT：为何被动关闭的一方不须要TIME_WAIT傻等呢，彷佛人人都了然了

TIME_WAIT，是网络高手们的必经之路，有不少文章可参考，随便给一个我以为写得颇有经验的文章：你所不知道的TIME_WAIT和CLOSE_WAIT - 老男孩教育博客。

用本身的话说，大体就是，

主动关闭链接的那一方呢，虽然也收到了对方的分手信号，能够说是顺利的完成了分手手续了，但是，它但仍是担忧对方有什么迟延数据等会儿会乱来，因此等几十几百秒。

• ####有道理啊，可是很傻，特别是对于Web Server这样的被动服务来讲是很傻。

反正现状是，几乎全部的Web Server在建立时socket server时都指定了SO_REUSEADDR标记了，部分缘由就是为了克服这个破TIME_WAIT时不让侦听的毛病。不然铁定被人投诉。同理，NodeJS之类的工具里也是这样处理了。

若是没有这个标记，那常常在Debug时手动中止或者不当心死了（反正都会引起这个TIME_WAIT）后，再次启动Web Server时，就会爆“地址有人在用了”，那谁能忍受啊。

Web Server：想开点，对本身好点，别扣着破标准了，我主动关闭了链接后，既然也收到了对方的结束信号了，那后面来的什么迟延数据关我啥事儿啊，发现乱数据我就回个RST，就算是出事儿也是对方那边出事儿。

因此呢，这么多年过来，也没人说Web Server和NodeJS这么有什么问题，那么多高手都盯着呢。

固然，这些大白话都不是什么严谨的话，扣字眼就没完没了了。

• ####而对于客户端，路由器，这些东西上面的TIME_WAIT仍是不能简单无视的，这在上面的连接文章里有例子。

---

• ####我好奇的是，为何被动关闭链接的那一方，当顺利的完成了分手手续后，不进入那该死的几十几百秒等待状态呢？

为何文档上不明确添加个说明呢，光给出个状态图硬说：就是这样的状态迁移，你爱接受不接受。

随便给个连接：CLOSE_WAIT

猜想一下，那是由于TCP是排序处理数据的，既然都收到了主动方发出的FIN信号(就是主动方发了一堆数据后单独发了个FIN代表完了)，那就说明主动方的全部数据都已经接收到了，不存在什么迟到的数据的事儿了。以后一旦收到了主动方的ACK，那就OK了，干干净净分手。

猜想是猜想，可这东西又很差作实验，不找个100%确定的文章我是不放心的，这是强迫症。

例如，若是主动方发来的FIN比以前的数据还早来，那分手以后，岂不是仍是有可能对方的数据迟迟而来？不过幸亏，TCP是检查顺序的，来早的FIN应该会被cache起来，并不马上当真处理的。

这就是我要确认的内容，理论上显然是没错的，可实际上谁知道呢，我须要一个有经验的人的话才安心。

硬翻那协议说明的话，老是隔靴挠痒，不贴心，我就想要个人问题的答案。

还好，找到了有人明确这样说了，我就罢休了。 TCP数据流稳定性－－TCP分片,重组及乱序 - 晓风残梦 - 博客园

TCP协议规定，对于收到的乱序报文并不丢弃，而是缓存下来(这样作是为了减小更多的重传)，当即发送但愿接受的报文确认。例如：发送端A发送了如下几个包：第一个：1001－1100，第二个1101－1200，第三个FIN包(序列号是1201，一个虚字节)。

1）第二个包在传输的过程当中丢失了，接收端收到第三个包后并不丢弃，而是缓存下来，而后，当即发送一个ACK，确认号是1101（这样作的目的是没必要等到发送端A的第二个包超时后重传，发送端A收到3个一样的ACK后当即重传，这是快速重传的概念）。