对于加密安全关机，双方必须通过调用shutdown() 或async_shutdown() 并运行io_service 对boost::asio::ssl::stream 执行关机操作。如果操作以没有SSL category 的error_code 完成，并且在部分关闭可能发生之前未取消，则连接已安全关闭，并且可以重用或关闭底层传输。简单地关闭最低层可能会使会话容易受到truncation attack 的攻击。
协议和 Boost.Asio API
在标准化的TLS 协议和非标准化的SSLv3 协议中，安全关闭涉及各方交换close_notify 消息。在Boost.Asio API方面，任何一方都可以通过调用shutdown()或async_shutdown()来发起关机，导致向对方发送close_notify消息，通知接收方发起者不会再发送更多消息在 SSL 连接上。根据规范，收件人必须回复close_notify 消息。 Boost.Asio 不会自动执行此行为，需要收件人显式调用shutdown() 或async_shutdown()。
规范允许关闭的发起者在收到close_notify 响应之前关闭其读取端的连接。这用于应用程序协议不希望重用底层协议的情况。不幸的是，Boost.Asio 目前 (1.56) 不直接支持此功能。在 Boost.Asio 中，shutdown() 操作在发生错误或当事方已发送并接收到 close_notify 消息时被视为完成。操作完成后，应用程序可以重用底层协议或关闭它。
场景和错误代码
一旦建立 SSL 连接，关机时会出现以下错误代码：
- 一方发起关闭，另一方关闭或已经关闭底层传输但未关闭协议：
- 发起者的
shutdown() 操作将失败并出现 SSL 短读取错误。
- 一方发起关闭并等待远程方关闭协议：
- 启动器的关闭操作将完成，错误值为
boost::asio::error::eof。
- 远程方的
shutdown()操作成功完成。
- 一方启动关闭，然后关闭底层协议，而不等待远程方关闭协议：
- 发起者的
shutdown()操作将被取消，导致boost::asio::error::operation_aborted的错误。这是以下详细信息中提到的解决方法的结果。
- 远程方的
shutdown()操作成功完成。
下面详细介绍了这些不同的场景。每个场景都用一个类似游泳线的图表来说明，表明每一方在完全相同的时间点做什么。
PartyA 在 PartyB 关闭连接后调用shutdown() 而不协商关闭。
在这种情况下，PartyB 违反了关闭过程，即在未先在流上调用 shutdown() 的情况下关闭底层传输。一旦底层传输关闭，PartyA 会尝试发起shutdown()。
PartyA | PartyB
-------------------------------------+----------------------------------------
ssl_stream.handshake(...); | ssl_stream.handshake(...);
... | ssl_stream.lowest_layer().close();
ssl_stream.shutdown(); |
PartyA 将尝试发送close_notify 消息，但写入底层传输将失败并显示boost::asio::error::eof。 Boost.Asio 将 explicitly map 底层传输的 eof 错误转换为 SSL 短读取错误，因为 PartyB 违反了 SSL 关闭程序。
if ((error.category() == boost::asio::error::get_ssl_category())
&& (ERR_GET_REASON(error.value()) == SSL_R_SHORT_READ))
{
// Remote peer failed to send a close_notify message.
}
PartyA 调用shutdown() 然后PartyB 关闭连接而不协商关闭。
在这种情况下，PartyA 启动关闭。然而，当 PartyB 收到 close_notify 消息时，PartyB 在关闭底层传输之前从未明确响应 shutdown()，从而违反了关闭程序。
PartyA | PartyB
-------------------------------------+---------------------------------------
ssl_stream.handshake(...); | ssl_stream.handshake(...);
ssl_stream.shutdown(); | ...
| ssl_stream.lowest_layer().close();
由于 Boost.Asio 的 shutdown() 操作在 close_notify 已发送和接收或发生错误时被视为完成，因此 PartyA 将发送 close_notify 然后等待响应。 PartyB 关闭底层传输而不发送close_notify，违反了 SSL 协议。 PartyA 的读取将失败并显示 boost::asio::error::eof，Boost.Asio 会将其映射到 SSL 短读取错误。
PartyA 发起shutdown() 并等待PartyB 回复shutdown()。
在这种情况下，PartyA 将启动关闭并等待 PartyB 响应关闭。
PartyA | PartyB
-------------------------------------+----------------------------------------
ssl_stream.handshake(...); | ssl_stream.handshake(...);
ssl_stream.shutdown(); | ...
... | ssl_stream.shutdown();
这是一个相当基本的关闭，双方发送和接收close_notify 消息。一旦双方协商关闭，底层传输可能会被重用或关闭。
-
甲方的关机操作将完成，错误值为
boost::asio::error::eof。
-
PartyB 的关机操作将成功完成。
PartyA 发起shutdown() 但不等待PartyB 响应。
在这种情况下，PartyA 将启动关闭，然后在发送close_notify 后立即关闭底层传输。 PartyA 不会等待 PartyB 回复 close_notify 消息。规范允许这种类型的协商关闭，并且在实现中相当普遍。
如上所述，Boost.Asio 不直接支持这种类型的关闭。 Boost.Asio 的shutdown() 操作将等待远程对等方发送其close_notify。但是，可以在仍然遵守规范的情况下实施变通方法。
PartyA | PartyB
-------------------------------------+---------------------------------------
ssl_stream.handshake(...); | ssl_stream.handshake(...)
ssl_stream.async_shutdown(...); | ...
const char buffer[] = ""; | ...
async_write(ssl_stream, buffer, | ...
[](...) { ssl_stream.close(); }) | ...
io_service.run(); | ...
... | ssl_stream.shutdown();
PartyA会先发起异步关机操作，然后再发起异步写操作。用于写入的缓冲区必须是非零长度（上面使用空字符）；否则，Boost.Asio 会将写入优化为无操作。当shutdown()操作运行时，会向PartyB发送close_notify，导致SSL关闭PartyA的SSL流的写端，然后异步等待PartyB 的close_notify。但是，由于 PartyA 的 SSL 流的写入端已关闭，async_write() 操作将失败并显示 SSL 错误，指示协议已关闭。
if ((error.category() == boost::asio::error::get_ssl_category())
&& (SSL_R_PROTOCOL_IS_SHUTDOWN == ERR_GET_REASON(error.value())))
{
ssl_stream.lowest_layer().close();
}
失败的async_write() 操作将显式关闭底层传输，导致正在等待PartyB 的close_notify 的async_shutdown() 操作被取消。
- 虽然 PartyA 执行了 SSL 规范允许的关闭过程，但当底层传输关闭时，
shutdown() 操作被显式取消。因此，shutdown() 操作的错误代码将具有 boost::asio::error::operation_aborted 的值。
-
PartyB 的关机操作将成功完成。
总的来说，Boost.Asio 的 SSL 关闭操作有点棘手。在正确关闭期间发起方和远程对等方的错误代码之间的不一致可能会使处理有点尴尬。作为一般规则，只要错误代码的类别不是 SSL 类别，协议就会被安全关闭。