SO_LINGER和优雅关闭连接以及短链接TIME_WAIT问题解决方法
SO_LINGER和优雅关闭连接以及短链接TIME_WAIT问题解决方法
Linux网络编程中,socket的选项很多.其中几个比较重要的选项就包括SO_LINGER。
在默认情况下,当调用close关闭socke的使用,close会立即返回,但是,如果send buffer中还有数据,系统会试着先把send buffer中的数据发送出去， SO_LINGER选项则是用来修改这种默认操作的。SO_LINGER是一个socket选项，可以通过setsockopt API进行设置，使用起来比较简单，但其实现机制比较复杂，且字面意思上比较难理解。SO_LINGER的值用如下数据结构表示：
#include
struct linger {
int l_onoff //0=off, nonzero=on(开关)
int l_linger //linger time(延迟时间)
}
注释：l_linger的单位依赖于实现: 4.4BSD假设其单位是时钟滴答（百分之一秒），但Posix .1g规定单位为秒
| l_onoff | l_linger | closesocket行为 | 发送队列 | 底层行为 |
| 零 | 忽略 | 立即返回。 | 保持直至发送完成。 | 系统接管套接字并保证将数据发送至对端。（就是正常的close） |
| 非零 | 零 | 立即返回。 | 立即放弃。 | 直接发送RST包，自身立即复位，不用经过2MSL状态。对端收到复位错误号。 |
| 非零 | 非零 | 阻塞直到l_linger时间超时或数据发送完成。(套接字必须设置为阻塞zhuan) | 在超时时间段内保持尝试发送，若超时则立即放弃。 | 超时则同第二种情况，若发送完成则皆大欢喜。 |
其取值和处理如下：
1、设置 l_onoff为0，则该选项关闭，l_linger的值被忽略，等于内核缺省情况，close调用会立即返回给调用者，如果可能将会传输任何未发送的数据；
2、设置 l_onoff为非0，l_linger为0，当调用close的时候,TCP连接会立即断开.send buffer中未被发送的数据将被丢弃,并向对方发送一个RST信息.值得注意的是，由于这种方式，不是以4次握手方式结束TCP链接，所以，TCP连接将不会进入TIME_WAIT状态，这样会导致新建立的可能和就连接的数据造成混乱。这种关闭方式称为“强制”或“失效”关闭。
3、设置 l_onoff 为非0，l_linger为非0，在这种情况下，回事的close返回得到延迟。调用close去关闭socket的时候，内核将会延迟。也就是说，如果send buffer中还有数据尚未发送，该进程将会被休眠直到一下任何一种情况发生：
a. send buffer中的所有数据都被发送并且得到对方TCP的应答消息（这种应答并不是意味着对方应用程序已经接收到数据，在后面shutdown将会具体讲道）
b.延迟时间消耗完。在延迟时间被消耗完之后，send buffer中的所有数据都将会被丢弃。
这种关闭称为“优雅的”关闭。
上面a、b两种情况中，如果socket被设置为O_NONBLOCK状态，程序将不会等待close返回，send buffer中的所有数据都将会被丢弃。所以，需要我们判断
close的返回值。在send buffer中的所有数据都被发送之前并且延迟时间没有消耗完，close返回的话，close将会返回一个EWOULDBLOCK的error.
第一种情况其实和不设置没有区别，第二种情况可以用于避免TIME_WAIT状态，但在Linux上测试的时候，并未发现发送了RST选项，而是正常进行了四步关闭流程，初步推断是“只有在丢弃数据的时候才发送RST”，如果没有丢弃数据，则走正常的关闭流程。
注意：从原理上来说，这个选项有一定的危险性，可能导致丢数据，使用的时候要小心一些
在说到TIME_WAIT状态之前，我们应该明确TIME_WAIT状态的作用：
1、防止上一次连接中的数据包(或称数据分节)迷路后重新出现,影响新连接(TIME_WAIT状态持续2MSL(MSL是数据分节在网络中存活的最长时间),经过2MSL,上一次连接中所有的重复包都会消失)
2、可靠的关闭TCP连接
在主动关闭方发送的最后一个 ack(fin) ，有可能丢失，这时被动方会重新发
fin, 如果这时主动方处于 CLOSED 状态 ，就会响应 rst 而不是 ack。所以
主动方要处于 TIME_WAIT 状态，而不能是 CLOSED 。
TIME_WAIT状态的存在是有利的，但有时也会给我们带来麻烦。在短连接中，主动关闭端容易产生大量的TIME_WAIT状态的链接，占用大量的系统资源，譬如端口、系统内存等，避免TIME_WAIT状态的方法有两种：
a、设置SO_REUSEADDR，使端口可以被重用
setsockopt(fd,SOL_SOCKET,SO_REUSEADDR,(void *)&nOptval , sizeof(int))
注意：一般在调用bind之前设置SO_REUSEADDR套接口选项
Question:编写 TCP/SOCK_STREAM 服务程序时，SO_REUSEADDR到底什么意思？
Ask:这个套接字选项通知内核，如果端口忙，但TCP状态位于 TIME_WAIT ，可以重用端口。如果端口忙，而TCP状态位于其他状态，重用端口时依旧得到一个错误信息，指明"地址已经使用中"。如果你的服务程序停止后想立即重启，而新套接字依旧使用同一端口，此时SO_REUSEADDR 选项非常有用。必须意识到，此时任何非期望数据到达，都可能导致服务程序反应混乱，不过这只是一种可能，事实上很不可能。
一个套接字由相关五元组构成，协议、本地地址、本地端口、远程地址、远程端口。SO_REUSEADDR 仅仅表示可以重用本地本地地址、本地端口，整个相关五元组还是唯一确定的。所以，重启后的服务程序有可能收到非期望数据。必须慎重使用 SO_REUSEADDR 选项。
SO_REUSEADDR可以用在以下四种情况下(摘自《Unix网络编程》卷一，即UNPv1):
1、当有一个有相同本地地址和端口的socket1处于TIME_WAIT状态时，而你启动的程序的socket2要占用该地址和端口，你的程序就要用到该选项。
2、SO_REUSEADDR允许同一port上启动同一服务器的多个实例(多个进程)。但每个实例绑定的IP地址是不能相同的。在有多块网卡或用IP Alias技术的机器可以测试这种情况。
3、SO_REUSEADDR允许单个进程绑定相同的端口到多个socket上，但每个socket绑定的ip地址不同。这和2很相似，区别请看UNPv1。
4、SO_REUSEADDR允许完全相同的地址和端口的重复绑定。但这只用于UDP的多播，不用于TCP。
b、设置SO_LINGER，可以避免TIME_WAIT状态:
struct linger ling;
ling.l_onoff = 1;
ling.l_linger = 0;
Setsockopt(sockfd, SOL_SOCKET, SO_LINGER, &ling, sizeof(ling));
注意: SO_LINGER选项需要谨慎使用，尤其是强制式关闭，会丢失服务器发给客户端的最后一部分数据。