调研套接字server bind 失败的原因？——Address already in use

最近我们学习了套接字，知道了怎么使用套接字来编写一个服务器，但是最近有一个新的问题产生了。

当服务器还有客户端在访问的时候，在此时Ctrl +C挂掉服务器进程之后，服务器不能够立刻重启，这是什么原因造成的呢？

想知道的话，那就往下看吧！

1、服务器挂掉之后不能立刻重启的原因

最近写的套接字实现的服务器中，当还有客户端访问之时，挂掉服务器之后，服务器不能立刻重启，还有下面的报错：



上面显示的报错是bind函数报错 ，显示的是服务器地址仍然在使用。看到这里我们就知道是这段代码出现了错误：

if(bind(sockfd,(struct  sockaddr *)&addr,sizeof(addr)) <  0)
{
perror("bind");
exit(3);
}

但是我们的服务器进程已经结束了，为什么还是不能使用呢？

原因解释起来也是很好理解的。。。

我们都知道的是Tcp的通信是面向连接的，我们需要经过三次握手，四次挥手才能建立链接与释放连接。

当我们在还有客户端连接的情况下，如果在此时关闭服务器的话，

服务器的一方会与客户端断开连接，发送FIN信号给客户端，客户端给一个确认ACK信号返回给服务器。

但是连接是两边的事情，此时客户端一方的连接开没有断开，四次挥手还没有完成，所以连接还有断开。

此时的这个连接状态叫做是TIME_WAIT状态，该状态在套接字关闭后约保留 2 到 4 分钟。在 TIME_WAIT 状态退出之后，套接字被删除，该地址才能被重新绑定而不出问题。

2、解释TIME_WAIT的原理 

TIME_WAIT状态原理

----------------------------

通信双方建立TCP连接后，主动关闭连接的一方就会进入TIME_WAIT状态。

客户端主动关闭连接时，会发送最后一个ack后，然后会进入TIME_WAIT状态，再停留2个MSL时间(后有MSL的解释)，进入CLOSED状态。

下图是以服务器端主动关闭连接为例，说明这一过程的。

TIME_WAIT状态存在的理由

----------------------------
TCP/IP协议就是这样设计的，是不可避免的。主要有两个原因:
1）可靠地实现TCP全双工连接的终止
TCP协议在关闭连接的四次握手过程中，最终的ACK是由主动关闭连接的一端（后面统称A端）发出的，如果这个ACK丢失，对方（后面统称B端）将重发出最终的FIN，因此A端必须维护状态信息（TIME_WAIT）允许它重发最终的ACK。如果A端不维持TIME_WAIT状态，而是处于CLOSED 状态，那么A端将响应RST分节，B端收到后将此分节解释成一个错误（在java中会抛出connection reset的SocketException)。
因而，要实现TCP全双工连接的正常终止，必须处理终止过程中四个分节任何一个分节的丢失情况，主动关闭连接的A端必须维持TIME_WAIT状态 。
2）允许老的重复分节在网络中消逝
TCP分节可能由于路由器异常而“迷途”，在迷途期间，TCP发送端可能因确认超时而重发这个分节，迷途的分节在路由器修复后也会被送到最终目的地，这个迟到的迷途分节到达时可能会引起问题。在关闭“前一个连接”之后，马上又重新建立起一个相同的IP和端口之间的“新连接”，“前一个连接”的迷途重复分组在“前一个连接”终止后到达，而被“新连接”收到了。为了避免这个情况，TCP协议不允许处于TIME_WAIT状态的连接启动一个新的可用连接，因为TIME_WAIT状态持续2MSL，就可以保证当成功建立一个新TCP连接的时候，来自旧连接重复分组已经在网络中消逝

MSL时间

----------------------------

MSL就是maximum segment lifetime(最大分节生命期），这是一个IP数据包能在互联网上生存的最长时间，超过这个时间IP数据包将在网络中消失 。MSL在RFC 1122上建议是2分钟，而源自berkeley的TCP实现传统上使用30秒。

TIME_WAIT状态维持时间

----------------------------

TIME_WAIT状态维持时间是两个MSL时间长度，也就是在1-4分钟。Windows操作系统就是4分钟

3、我们要怎么解决TIME_WAIT这个问题呢？

我们都知道，服务器的服务是一对多的，我们需要与很多的客户端来进行通信，要是服务器挂上两到四分钟的话，访问量要少上很多，所以在一般的公司是不允许服务器出现挂掉的情况，如果出现了，也要立刻重启。才不会造成影响。

在这里我们提供一种方法：[b]在bind设置SO_REUSEADDR套接字选项。[/b]

怎么设置呢？我们这里有一个函数可以实现setsockopt函数；函数原型如下：

#include <sys/types.h>          /* See NOTES */
#include <sys/socket.h>
int setsockopt(int sockfd, int level, int optname,
const void *optval, socklen_t optlen);

函数调用方式：

socket函数之后

const int on=1;
setsockopt(listenfd,SOL_SOCKET,SO_REUSEADDR,&on,sizeof(on)); 

bind函数之前

SO_REUSEADDR选项

SO_REUSEADDR选项的用途有多中，我们只讨论这里使用到的功能。先来看看UNP V1对这种情况的描述。

SO_REUSEADDR允许启动一个监听服务器并捆绑其众所周知端口，即使以前建立的将该端口用作它们的本地的连接仍存在。这个条件通常是这样碰到的：

(1) 启动一个监听服务器；

(2) 连接请求到达，派生一个子进程来处理这个客户；

(3) 监听服务器终止，但子进程继续为现有连接上的客户提供服务；

(4) 重启监听服务器。

默认情况下，当监听服务器在步骤(4)中通过调用socket、bind和listen重新启动时，由于它试图捆绑一个现有连接（即正由早先派生的那个子进程处理着的连接）上的端口，从而bind调用会失败。但如果该服务器在socket和bind中间调用设置了SO_REUSEADDR选项，那么bind将成功。                                         ——以上摘自UNP V1

下面对比我们这里遇到的情况，server1主动关闭后进入TIME_WAIT状态，此时对server1来说原有连接没有彻底终止，当重启server1时，就试图bind一个现有的连接，所以造成bind失败。所以一般TCP服务端都要设置SO_REUSEADDR选项，以便可以快速重启。