关于SO_REUSEADDR选项的作用

关于使用端口复用我们已经很熟悉了，但是有一些细节是未必大家都知道的。

最近在网上看见大家对端口复用的一些争论，现在来总结一下，如有错误请大家指出：

int setsockopt(int sockfd, int level, int optname,
                      const void *optval, socklen_t optlen);

上面这个函数大家都很熟悉的，在其中我们可以用

setsockopt(listenfd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));

使得这个监听的端口变成可以复用的。

那么复用真正是什么意义呢？这个我们可以看看TCP/IP里面TCP建立和断开链接的方法。

我们知道，在TCP断开链接的时候我们需要四次握手来断开，而且当两端都关闭了read/write通道以后我们还是要等待一个TIME_WAIT时间。

这就是SO_REUSEADDR的作用所在.

其实这个选项就是告诉OS如果一个端口处于TIME_WAIT状态, 那么我们就不用等待直接进入使用模式, 不需要继续等待这个时间结束.

那这样我们肯定要问,那为什么我们需要有这个TIME_WAIT时间啊?

看看TCP/IP协议组我们就知道,这样做是为了让在网络中残余的TCP包消失, 也就是说, 如果我们没有等到这个时间就让OS把这个端口释放给其他的进程使用,别的进程很有可能就会收到上一个会话的残余TCP包,这样就会出现一系列的不可预知的错误.

一、保证TCP协议的全双工连接能够可靠关闭
二、保证这次连接的重复数据段从网络中消失

那么什么时候我们可以用这个选项以加快我们进程的速度减小等待时间呢?

这里有一些例子:

SO_REUSEADDR可以用在以下四种情况下。
(摘自《Unix网络编程》卷一，即UNPv1)
1、当有一个有相同本地地址和端口的socket1处于TIME_WAIT状态时，而你启
动的程序的socket2要占用该地址和端口，你的程序就要用到该选项。
2、SO_REUSEADDR允许同一port上启动同一服务器的多个实例(多个进程)。但
每个实例绑定的IP地址是不能相同的。在有多块网卡或用IP Alias技术的机器可
以测试这种情况。
3、SO_REUSEADDR允许单个进程绑定相同的端口到多个socket上，但每个soc
ket绑定的ip地址不同。这和2很相似，区别请看UNPv1。
4、SO_REUSEADDR允许完全相同的地址和端口的重复绑定。但这只用于UDP的
多播，不用于TCP。

也就是说,不是所有的情况我们都可以使用这个选项的,请参阅这篇淘宝的案例:

http://rdc.taobao.com/blog/cs/?p=1195

 

这里是比较官方的对于这个option的解释:

What exactly does SO_REUSEADDR do?

  This socket option tells the kernel that even if this port is busy (in
  the TIME_WAIT state), go ahead and reuse it anyway.  If it is busy,
  but with another state, you will still get an address already in use
  error.  It is useful if your server has been shut down, and then
  restarted right away while sockets are still active on its port.  You
  should be aware that if any unexpected data comes in, it may confuse
  your server, but while this is possible, it is not likely.

  It has been pointed out that "A socket is a 5 tuple (proto, local
  addr, local port, remote addr, remote port).  SO_REUSEADDR just says
  that you can reuse local addresses.  The 5 tuple still must be
  unique!" by Michael Hunter (mphunter@qnx.com).  This is true, and this
  is why it is very unlikely that unexpected data will ever be seen by
  your server.  The danger is that such a 5 tuple is still floating
  around on the net, and while it is bouncing around, a new connection
  from the same client, on the same system, happens to get the same
  remote port.  This is explained by Richard Stevens in ``2.7 Please
  explain the TIME_WAIT state.''.