Socket中SO_REUSEADDR详解

74 阅读 0 评论 49 点赞

我是靠谱客的博主痴情宝贝，最近开发中收集的这篇文章主要介绍Socket中SO_REUSEADDR详解，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

1、一般来说，一个端口释放后会等待两分钟之后才能再被使用，SO_REUSEADDR是让端口释放后立即就可以被再次使用。

SO_REUSEADDR用于对TCP套接字处于TIME_WAIT状态下的socket，才可以重复绑定使用。server程序总是应该在调用bind()之前设置SO_REUSEADDR套接字选项。TCP，先调用close()的一方会进入TIME_WAIT状态

2、SO_REUSEADDR和SO_REUSEPORT

SO_REUSEADDR提供如下四个功能：

SO_REUSEADDR允许启动一个监听服务器并捆绑其众所周知端口，即使以前建立的将此端口用做他们的本地端口的连接仍存在。这通常是重启监听服务器时出现，若不设置此选项，则bind时将出错。

SO_REUSEADDR允许在同一端口上启动同一服务器的多个实例，只要每个实例捆绑一个不同的本地IP地址即可。对于TCP，我们根本不可能启动捆绑相同IP地址和相同端口号的多个服务器。

SO_REUSEADDR允许单个进程捆绑同一端口到多个套接口上，只要每个捆绑指定不同的本地IP地址即可。这一般不用于TCP服务器。

SO_REUSEADDR允许完全重复的捆绑：当一个IP地址和端口绑定到某个套接口上时，还允许此IP地址和端口捆绑到另一个套接口上。一般来说，这个特性仅在支持多播的系统上才有，而且只对UDP套接口而言（TCP不支持多播）。

SO_REUSEPORT选项有如下语义：

此选项允许完全重复捆绑，但仅在想捆绑相同IP地址和端口的套接口都指定了此套接口选项才行。

如果被捆绑的IP地址是一个多播地址，则SO_REUSEADDR和SO_REUSEPORT等效。

使用这两个套接口选项的建议：

在所有TCP服务器中，在调用bind之前设置SO_REUSEADDR套接口选项；

当编写一个同一时刻在同一主机上可运行多次的多播应用程序时，设置SO_REUSEADDR选项，并将本组的多播地址作为本地IP地址捆绑。

if (setsockopt(fd, SOL_SOCKET, SO_REUSEADDR,

(const void *)&nOptval , sizeof(int)) < 0) ...

附

Q:编写 TCP/SOCK_STREAM 服务程序时，SO_REUSEADDR到底什么意思？

A:这个套接字选项通知内核，如果端口忙，但TCP状态位于 TIME_WAIT ，可以重用端口。如果端口忙，而TCP状态位于其他状态，重用端口时依旧得到一个错误信息，指明"地址已经使用中"。如果你的服务程序停止后想立即重启，而新套接字依旧使用同一端口，此时SO_REUSEADDR 选项非常有用。必须意识到，此时任何非期望数据到达，都可能导致服务程序反应混乱，不过这只是一种可能，事实上很不可能。

一个套接字由相关五元组构成，协议、本地地址、本地端口、远程地址、远程端口。SO_REUSEADDR 仅仅表示可以重用本地本地地址、本地端口，整个相关五元组还是唯一确定的。所以，重启后的服务程序有可能收到非期望数据。必须慎重使用SO_REUSEADDR 选项。

我们假设是客户执行主动关闭并进入 TIME_WAIT ，这是正常的情况，因为服务器通常执行被动关闭，不会进入 TIME_WAIT 状态。这暗示如果我们终止一个客户程序，并立即重新启动这个客户程序，则这个新客户程序将不能重用相同的本地端口。这不会带来什么问题，因为客户使用本地端口，而并不关心这个端口号是什么。然而，对于服务器，情况就有所不同，因为服务器使用周知端口。如果我们终止一个已经建立连接的服务器程序，并试图立即重新启动这个服务器程序，服务器程序将不能把它的这个周知端口赋值给它的端点，因为那个端口是处于 2MSL 连接的一部分。在重新启动服务器程序前，它需要在 1~4 分钟。这就是很多网络服务器程序被杀死后不能够马上重新启动的原因（错误提示为“ Address already in use ”）。

int Net::tcp_listen(unsigned short port)
{
int fd, one = 1;
struct sockaddr_in sa_in;

if ((fd = socket(PF_INET, SOCK_STREAM, 0)) < 0)
return -1;
if (setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &one, sizeof(one)) < 0) {
close(fd);
return -1;
}
set_nonblocking(fd, 0);
bzero(&sa_in, sizeof(sa_in));
sa_in.sin_family = AF_INET;
sa_in.sin_port = htons(port);
sa_in.sin_addr.s_addr = INADDR_ANY;
bind(fd, (struct sockaddr *)&sa_in, sizeof(sa_in));
listen(fd, 1024);
global->PRINTF("Listen on port:%d, fd:%dn", port, fd);
return fd;
}

设置SO_REUSEADDR选项

在第11章，"并发客户端服务器"的第一部分中，提供并测试了一个使用fork系统调用设计的服务器。图12.1显示了在一个telnet命令与服务器建立连接之后的三个步骤。
这些步骤如下：
1 启动服务器进程(PID 926)。他监听客户端连接。
2 启动客户端进程(telnet命令)，并且连接到服务器进程(PID 926)。
3 通过fork调用创建服务器子进程，这会保留的原始的父进程(PID 926)并且创建一个新的子进程(PID 927)。
4 连接的客户端套接口由服务器父进程(PID 926)关闭，仅在子进程(PID 927)中保持连接的客户端套接口处理打开状态。
5 telnet命令与服务器子进程(PID 927)随意交互，而独立于父进程(PID 926)。

在步骤5，有两个套接口活动：
服务器(PID 926)监听192.168.0.1：9099
客户端由套接口192.168.0.1：9099进行服务(PID 927)，他连接到客户端地址192.168.0.2：1035

客户端由进程ID 927进行服务。这意味着我们可以杀掉进程ID 926，而客户端仍可以继续被服务。然而，却不会有新的连接连接到服务器，因为并没有服务器监听新的连接(监听服务器PID 926已被杀死)

现在如果我们重启服务器来监听新的连接，就会出现问题。当新的服务器进程试着绑定IP地址192.168.0.1：9099时，bind函数就会返回 EADDRINUSE的错误代码。这个错误代码表明IP已经在9099端口上使用。这是因为进程PID 927仍然在忙于服务一个客户端。地址192.168.0.1：9099仍为这个进程所使用。

这个问题的解决办法就是杀掉进程927,这个关闭套接口并且释放IP地址和端口。然而，如果正在被服务的客户是我们所在公司的CEO，这样的做法似乎不是一个选择。同时，其他的部门也会抱怨我们为什么要重新启动服务器。

这个问题的一个好的解决办法就是使用SO_REUSEADDR套接口选项。所有的服务器都应使用这个选项，除非有一个更好的理由不使用。为了有效的使用这个选项，我们应在监听连接的服务器中执行下面的操作：
1 使用通常的socket函数创建一个监听套接口
2 调用setsockopt函数设置SO_REUSEADDR为TRUE
3 调用bind函数

套接口现在被标记为可重用。如果监听服务器进程因为任何原因终止，我们可以重新启动这个服务器。当一个客户正为另一个服务器进程使用同一个IP和端口号进行服务时尤其如此。

为了有效的使用SO_REUSEADDR选项，需要考虑下面的情况：
在监听模式下并没有同样的IP地址和端口号的其他套接口
所有的同一个IP地址和端口号的套接口必须将SO_REUSEADDR选项设置为TRUE

这就意味着一个指定的IP地址和端口号对上只可以用一个监听器。如果这样的套接口已经存在，那么设置这样的选项将不会达到我们的目的。

只有所有存在的同一个地址和端口号的套接口有这个选项设置，将SO_REUSEADDR设置为TRUE才会有效。如果存在的套接口没有这个选项设置，那么bind函数就会继续并且会返回一个错误号。

下面的代码显示如何将这个选项设置为TRUE：

#define TRUE 1
#define FALSE 0
int z;
int s;
int so_reuseaddr = TRUE;
z = setsockopt(s,SOL_SOCKET,SO_REUSEADDR,
    &so_reuseaddr,
    sizeof(so_reuseaddr));
如果需要SO_REUSEADDR选项可以由getsockopt函数进行查询。

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状态呢？否则每次调试之后，都要巴巴地等上两分钟，再进行下次调试。UNP中第7章就是讲socket选项的。没有找到能关闭掉TIME_WAIT的选项。但是找到了SO_REUSEADDR选项。关于此选项，书上说可以起到上文提到的4个不同的功用。

　　问题正好符合情况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的问题。所以，这样是安全的。不过，最终的服务器版本，还是不要设置为端口可复用的。