最近在看TCP相关的知识,学到了很多,但是也有一些疑惑,主要就是关于TCP关闭状态中的close_wait,这个状态比较有趣,这个状态之所有存在的两个原因我这里就不再赘述了,但是这里想讲一下如果一个套接字处于close_wait状态,会有什么有趣的事情发生.
当一个套接字处于close_wait状态,在默认情况下,我们是无法再使用这个套接字对应的网卡(网卡可以是实际的也可以是虚拟的)的对应的端口
上面的话可能听起来不那么容易理解,下面我会给出一些例子.
这个例子使用的是TCP的默认设置,没有设置SO_REUSEADDR选项,服务器监听在192.168.1.100:9999,我们使用在同一局域网下的另外一台电脑连接上服务端,同时发送数据"hello server",从服务端的输出可以看到服务端确实已经和客户端建立了连接,同时收到了来自客户端的消息,这个时候我们直接杀死服务器,让服务端主动关闭连接,因为time_wait状态只有在主动关闭tcp连接的一方才会出现,然后我们使用
netstat -anp | grep 9999
来查看端口情况,然后再尝试重启服务端
./simple_tcp_server 192.168.1.100 9999
结果图如下:
这里可以看到,地址为127.0.0.1:9999是处于time_wait状态的,这个时候我们企图再次重启服务端,报错是bind error: Address already in use,这个倒是在我们的意料之中,因为9999端口是处于time_wait状态的,端口无法被复用属于正常.但是我们这里尝试换个ip来看看是否能够重启服务端.结果图如下:
这里的结果就比较有意思了,当我们试图绑定127.0.0.1这个ip地址的时候,我们启动服务器是成功的,而当我们试图使用localhost为ip地址来启动服务端的时候,我们得到了bind: Address already in use的错误,这个是什么原因呢.
这里我简单从个人的角度来解释一下,首先第一个问题,为什么以127.0.0.1为ip地址来启动服务端是能够成功的,我的个人理解以及查阅资料得到的结论是,端口是相对于网口而言的(或者说是相对ip地址而言的),因此127.0.0.1和192.168.1.100对应的不同的网卡,也就是说端口是互不影响的,所以我们之前启动的是192.168.1.100网卡上的9999端口,对127.0.0.1这块网卡上的9999端口毫无影响,所以我们启动服务端成功了.
第二个问题在明白了第一个问题之后就变得简单了,这里稍微比较唬人的是localhost,实际上localhost对应的地址是0.0.0.0,而0.0.0.0这个ip地址实际上是通配地址,也就是说和*是等同的,我们希望绑定服务端绑定的ip地址是0.0.0.0,也就意味着是绑定的通配地址,也就意味着对于一台计算机的所有ip地址都需要绑定,而192.168.1.100对应的网卡的9999端口处于time_wait状态,所以显然会绑定失败,导致绑定localhost这个操作失败.还是比较好理解的.
下面我们继续讲下SO_REUSEADDR选项,这个选项允许复用处于time_wait状态的地址,增加了这个选项,让我们再来试试.
很明显可以看到虽然192.168.1.100:9999是处于time_wait状态,但是我们仍然可以启动绑定各个ip的服务端,顺利启动,没有遇到任何问题.
最后让我们来测试一个有趣的问题,当一个套接字处于time_wait状态的时候,这个套接字是否已经被回收了,这个问题我们就不能直接杀死服务端了,而是需要服务端主动断开连接.
首先我们启动服务端,然后通过ps命令查看服务端进程的pid,然后查看这个进程打开的所有文件描述符,首先我们看到,前三个是标准输入,输出和标准错误输出,3对应的是监听套接字,4对应的epoll文件描述符,这个时候我们启动一个客户端去连接服务器,
这里我在客户端向服务端发送数据之后,服务端sleep5秒钟就直接关掉这个描述符,所以是服务端主动断开连接,看图可以确定在建立连接的过程中确实多占用了一个文件描述符,也就是5对应的文件描述符(因为这个时候服务端处于sleep状态,这个tcp连接仍然存在),但是当服务端sleep结束,服务端就会主动关闭这个连接,有趣的是之前连接虽然还处于time_wait状态但是套接字却已经被回收了,也就是说虽然一个套接字处于time_wait状态,但是实际上这个套接字是已经被回收的.(更严谨的证明是再使用一个新的客户端来连接服务端,保证之前那个套接字仍然处于time_wait的情况下,查看新的客户端连接对应的文件描述符,如果确实和之前那个连接的文件描述符相同,说明这个描述符的确能被复用,我在我自己电脑上测试了确实是这样的,这里就不再贴图了)
总结:个人总结,对于一个tcp服务端,在启动的时候是一定要增加SO_REUSEADDR选项的,另外time_wait状态实际上对服务端的影响并不是很大,除非是使用不当导致的问题,否则因为实际上处于time_wait的套接字是已经被回收了,所以起码并不会占用进程的文件描述符数量而只是占用少量的资源,除非是特别高并发的情况,但是这种情况下与其不断优化不如考虑增加机器(笑).