socket服务器开发中的SO_REUSEADDR选项与让人心烦的TIME_WAIT

本文有更新，请移步个人我的博客：https://blog.andyqiao.top/article/15/

1 发现问题　　

　　我在开发一个socket服务器程序并反复调试的时候，发现了一个让人无比心烦的状况：每次kill掉该服务器进程并从新启动的时候，都会出现bind错误：error:98，Address already in use。然而再kill掉该进程，再次从新启动的时候，就bind成功了。真让人摸不着头脑。难道必定要尝试两次才显得真诚？这不科学！

　　个人第一反应是kill进程的时候，并无彻底释放掉socket资源，倒致第二次启动的时候，bind失败。那么第三次怎么又成功了呢？

　　查资料：有人说是TIME_WAIT在捣鬼。

　　回想一下，Linux下的TIME_WAIT大概是2分钟，这样也合情合理。那么没有释放掉的资源是什么呢，是端口吗？机智的我马上决定作实验找出答案。启动服务器程序，在与客户创建链接以后，kill掉服务器。飞快地在terminal里输入命令：netstat -an|grep 9877。这里9877是我服务器打算绑定的端口。果真：

　　

　　结果显示9877端口正在被使用，并处于TCP中的TIME_WAIT状态。再过两分钟，我再执行命令netstat -an|grep 9877，世界清静了，什么都没有。

　　终于找到了答案：果真是TIME_WAIT在捣鬼。

2 解决问题

　　问题找到了，但是怎么解决问题呢。如何才能结束掉这个TIME_WAIT状态呢？不然每次调试以后，都要巴巴地等上两分钟，再进行下次调试。这太蠢了！想了很久，也没想出解决办法。那TCP中有没有能关闭掉TIME_WAIT的选项呢？翻书！UNP中第7章就是讲socket选项的。还真没有找到。可是，我找到了SO_REUSEADDR选项。关于此选项，书上说能够起到如下4个不一样的功用：

　　（1）SO_REUSEADDR容许启动一个监听服务器并捆绑其众所周知的端口，即便之前创建的将该端口用做他们的本地端口的链接仍存在。

　　（2）容许在同一端口上启动同一服务器的多个实例，只要每一个实例捆绑一个不一样的本地IP地址便可。

　　（3）SO_REUSEADDR 容许单个进程捆绑同一端口到多个套接字上，只要每次捆绑指定不一样的本地IP地址便可。

　　（4）SO_REUSEADDR容许彻底重复的捆绑：当一个IP地址和端口号已绑定到某个套接字上时，若是传输协议支持，一样的IP地址和端口还能够捆绑到另外一个套接字上。通常来讲本特性仅支持UDP套接字。

　　我遇到的状况正好符合状况1，而且书上说了：“全部TCP服务器都应该指定本套接字选项，以容许服务器在这种情形下被从新启动。”那么试试看喽。

　　

      上面两行代码，把此套接字listenFd设置为容许地址重用（on=1,若是on=0就是不容许重用了）。这样每次bind的时候，若是此端口正在使用的话，bind就会把端口“抢”过来。就不会报错了。完美解决问题。

3 察漏补缺

　　既然TIME_WAIT这么讨厌，那它的存在有什么意义呢？毕竟服务器端已经中断掉链接了呀。记得以前在看UNP的时候，上面好像有提到过，继续翻书：

　　书上说，TIME_WAIT状态有两个存在的理由：

　　（1）可靠地实现TCP全双工链接的终止；

　　（2）容许老的重复分节在网络中消逝。

　　原来如此，解释一下，上个图：

　　

　　（1）若是服务器最后发送的ACK由于某种缘由丢失了，那么客户必定会从新发送FIN，这样由于有TIME_WAIT的存在，服务器会从新发送ACK给客户，若是没有TIME_WAIT，那么不管客户有没有收到ACK，服务器都已经关掉链接了，此时客户从新发送FIN，服务器将不会发送ACK，而是RST，从而使客户端报错。也就是说，TIME_WAIT有助于可靠地实现TCP全双工链接的终止。

　　（2）若是没有TIME_WAIT，咱们能够在最后一个ACK还未到达客户的时候，就创建一个新的链接。那么此时，若是客户收到了这个ACK的话，就乱套了，必须保证这个ACK彻底死掉以后，才能创建新的链接。也就是说，TIME_WAIT容许老的重复分节在网络中消逝。

　　回到咱们的问题，因为我并非正常地通过四次断开的方式中断链接，因此并不会存在最后一个ACK的问题。因此，这样是安全的。不过，最终的服务器版本，仍是不要设置为端口可复用的。切记。

　　加油加油。好好学习，每天向上。

　　另外：UNP是本好书，要好好看呀。