SSL_shutdown崩溃Broken pipe

问题

static inline void SSL_free_(SSL *&ssl) {
    if (ssl) {
      ::SSL_shutdown(ssl);  // crash
      ::SSL_free(ssl);
      ssl = nullptr;
    }
}

写了个性能测试工具，每 20毫秒启动一个协程 ，进行TCP连接和SSL握手，然后关闭。

服务端运行过程中，程序有时在SSL_shutdown处崩溃，如果降低客户端连接频率，该问题不出现。

解决方式

根据：socket编程—— 服务器遇到Broken Pipe崩溃，是因为对一个对端已经关闭的socket调用两次write，第二次将会生成SIGPIPE信号, 该信号默认结束进程。

解决方法：捕获SIG_IGN信号，以避免进程退出

signal(SIGPIPE, SIG_IGN);

这样， 第二次调用write方法时，会返回-1，同时errno置为SIGPIPE，程序便能知道对端已经关闭。

原理

引用socket编程—— 服务器遇到Broken Pipe崩溃：

具体的分析可以结合TCP的"四次握手"，TCP是全双工的信道，可以看作两条单工信道，TCP连接两端的两个端点各负责一条。当对端调用close时，虽然本意是关闭整个两条信道，但本端只是收到FIN包。按照TCP协议的语义，表示对端只是关闭了其所负责的那一条单工信道，仍然可以继续接收数据。也就是说，因为TCP协议的限制，一个端点无法获知对端的socket是调用了close还是shutdown。

对一个已经收到FIN包的socket调用read方法，如果接收缓冲已空，则返回0，这就是常说的表示连接关闭。 但第一次对其调用write方法时，如果发送缓冲没问题，会返回正确写入(发送)。但发送的报文会导致对端发送RST报文，因为对端的socket已经调用了close，完全关闭，既不发送，也不接收数据。所以，第二次调用write方法(假设在收到RST之后)，会生成SIGPIPE信号，导致进程退出。

参考：
socket编程—— 服务器遇到Broken Pipe崩溃