closesocket, shutdown, tcp::socket.close()

最新推荐文章于 2023-06-23 10:21:04 发布

Beyond_cn

最新推荐文章于 2023-06-23 10:21:04 发布

阅读量2k

点赞数

分类专栏：网络编程文章标签： tcp socket descriptor system exchange

网络编程专栏收录该内容

47 篇文章 2 订阅

订阅专栏

closesocket, shutdown, tcp::socket.close()

tcp关闭连接有2种方式，一种是关闭端发送FIN，对方回应FINACK，关闭端再回ACK，这是优雅的关闭连接。双方可以保证所有数据都发送接收完成了。另一种是硬关闭，关闭方直接发送RSET。对方收到后立刻断开连接。

首先应该了解win32 api closesocket，这里只说msdn文档中叙述不够清晰的地方。

首先说缺省情况：l_onoff为0，closesocket立刻返回，但底层依然在持续发包，并且试图优雅关闭连接。这种情况下对于应用程序来说，该连接已经关闭，但底层socket的相关资源还没有释放，且不知道要等待多长时间。该方法对于一般程序来说没有问题，对于服务器来说，因为有可能有非常多的socket（超过100k），这样处理可能会导致系统可用的socket资源不足。

其次说l_onoff不为0的情况，此时取决于l_linger的值，系统会尽可能的优雅的关闭连接，如果在l_linger的时间内还无法关闭连接，则硬关闭。也就是说，此时如果l_linger为0，则肯定硬关闭，且closesocket立刻返回，同时释放所有资源。如果l_linger不为0，则尽可能优雅关闭并返回，释放所有资源，如果超时，则硬关闭，closesocket返回，释放所有资源。注意此种情况下closesocket可能是同步的。

shutdown有2个作用。首先禁止后续的send或者recv，但注意它不会影响底层，也就是说，此前发出的异步send/recv不会返回。其次，在所有发送的包被对方确认后，会发送FIN包给对方，试图优雅的关闭连接。但shutdown本身并不影响任何底层的东西，因此，shutdown并且优雅关闭了连接之后，该socket以及其所关联的资源依然存在，必须调用closesocket才能释放。

以上是msdn文档的说明。但实际过程中发现并非完全如此。测试程序使用asio实现了一个tcp server，在handle_send，也即一个包已经异步返回表明发送成功（成功发送到了系统缓冲区），这时候调用socket_.close，结果发现该包并没有真正发送（也可能发送了），系统发出了一个RSET而不是FIN。如果在socket_.close之前调用一次socket_.shutdown(both)，则发出FIN包。此处颇有些奇怪，实验平台是windows 20008和windows xp。实验时用socket_.get_option检查了l_onoff和l_linger的值，的确为缺省值。

因为许多时候都存在这样的需求，也即client或者server在发出最后一个包之后就关闭连接，一般来说是在发出最后一个包之后就调用socket_.close，或者不再发出任何异步调用让socket_自动进入析构函数。这样很可能有问题。在发完最后一个包之后先调用一次shutdown在网速快的情况下可能有一定帮助。但有2个缺点，一方面是网速未必快，那个包未必很快就发出，由于shutdown根本不影响前面已经发出的包，所以FIN未必能发出，另一个缺点是随后的closesocket并不真正意味着资源已释放。

综上述，好的做法是在handle_send里面，如果是最后一个包，那么设置一个标志，shutdown，然后启动一个1s的deadline_timer:

socket_.shutdown(boost::asio::ip::tcp::socket::shutdown_both, boost::system::error_code());

if(!graceful_close_)

{

handle_hard_close(boost::system::error_code());

}

else

{

timer_hard_close_.expires_from_now(boost::posix_time::seconds(1));

timer_hard_close_.async_wait(

strand_.wrap(boost::bind(

&tcp_client::handle_hard_close,

shared_from_this(),

boost::asio::placeholders::error)));

}

然后

void handle_hard_close(const boost::system::error_code& error)

{

if(!error)

{

boost::asio::socket_base::linger option(true, 0);

socket_.set_option(option);

socket_.close();

}

附录：

asio的部分源代码：

tcp::socket的析构函数：

win_iocp_socket_service.hpp

void close_for_destruction(implementation_type& impl)

{

if (is_open(impl))

{

// Check if the reactor was created, in which case we need to close the

// socket on the reactor as well to cancel any operations that might be

// running there.

reactor_type* reactor = static_cast<reactor_type*>(

interlocked_compare_exchange_pointer(

reinterpret_cast<void**>(&reactor_), 0, 0));

if (reactor)

reactor->close_descriptor(impl.socket_, impl.reactor_data_);

// The socket destructor must not block. If the user has changed the

// linger option to block in the foreground, we will change it back to the

// default so that the closure is performed in the background.

if (impl.flags_ & implementation_type::close_might_block)

{

::linger opt;

opt.l_onoff = 0;

opt.l_linger = 0;

boost::system::error_code ignored_ec;

socket_ops::setsockopt(impl.socket_,

SOL_SOCKET, SO_LINGER, &opt, sizeof(opt), ignored_ec);

}

boost::system::error_code ignored_ec;

socket_ops::close(impl.socket_, ignored_ec);

impl.socket_ = invalid_socket;

impl.flags_ = 0;

impl.cancel_token_.reset();

#if defined(BOOST_ASIO_ENABLE_CANCELIO)

impl.safe_cancellation_thread_id_ = 0;

#endif // defined(BOOST_ASIO_ENABLE_CANCELIO)

}

tcp::socket.close

win_iocp_socket_service.hpp

boost::system::error_code close(implementation_type& impl,

boost::system::error_code& ec)

{

if (is_open(impl))

{

// Check if the reactor was created, in which case we need to close the

// socket on the reactor as well to cancel any operations that might be

// running there.

reactor_type* reactor = static_cast<reactor_type*>(

interlocked_compare_exchange_pointer(

reinterpret_cast<void**>(&reactor_), 0, 0));

if (reactor)

reactor->close_descriptor(impl.socket_, impl.reactor_data_);

if (socket_ops::close(impl.socket_, ec) == socket_error_retval)

return ec;

impl.socket_ = invalid_socket;

impl.flags_ = 0;

impl.cancel_token_.reset();

#if defined(BOOST_ASIO_ENABLE_CANCELIO)

impl.safe_cancellation_thread_id_ = 0;

#endif // defined(BOOST_ASIO_ENABLE_CANCELIO)

}

ec = boost::system::error_code();

return ec;

}

以上代码很清晰的说明了asio的实现。

首先如果是析构，那么不管此前是否设置过setsockopt，asio都把socket设置回缺省状态，也即不可预测时间的优雅关闭连接。如果socket.close，那么直接调用closesocket。

另一个值得注意的地方是，这两个函数都把socket设置为了invalid_socket，从而避免了多次关闭的问题。

多次关闭的问题是这样：首先假定socket a = 0x1234，调用closesocket关闭了这个socket，然后再次createsocket得到一个socket b也为0x1234，而代码（可能是另一个thread或者iocp得到一个错误返回）试图再此关闭socket a，结果把socket b关闭了。这种情况在windows平台下很常见，也即socket b很可能也为0x1234。

===============================================

CP连接断开的时候调用closesocket函数，已经讨论过有优雅的断开和强制断开，那么如何设置断开连接的方式呢？是通过设置socket描述符一个linger结构体属性。

linger结构体数据结构如下：

struct linger

{

int l_onoff;

int l_linger;

};

有三种组合方式：

第一种

l_onoff = 0;

l_linger忽略

这种方式下，就是在closesocket的时候立刻返回，底层会将未发送完的数据发送完成后再释放资源，也就是优雅的退出。

第二种

l_onoff非零

l_linger = 0;

这种方式下，在调用closesocket的时候同样会立刻返回，但不会发送未发送完成的数据，而是通过一个REST包强制的关闭socket描述符，也就是强制的退出。

第三种

l_onoff非零

l_linger > 0

这种方式下，在调用closesocket的时候不会立刻返回，内核会延迟一段时间，这个时间就由l_linger得值来决定。如果超时时间到达之前，发送完未发送的数据(包括FIN包)并得到另一端的确认，closesocket会返回正确，socket描述符优雅性退出。否则，closesocket会直接返回错误值，未发送数据丢失，socket描述符被强制性退出。需要注意的时，如果socket描述符被设置为非堵塞型，则closesocket会直接返回值。

http://hi.baidu.com/pur_e/blog/item/1bcdbd0247e03f97d43f7c93.html