multithreading - 来自多个线程的 OpenSSL SSL_read 和 SSL_write

Question

我知道在 OpenSSL API 中禁止在同一 SSL 上下文中从两个不同的线程调用 SSL_read 和 SSL_write，但它是在我的应用程序中重要的是要有安全的全双工通信。我想到了一些解决方案，但没有一个是我真正喜欢的:

1. 每个连接使用两个 SSL 上下文。我不喜欢这样，因为它使用了更多资源，并且会使我的实现变得复杂。但是，如果我可以“复制”现有的 SSL 上下文而不是从头开始创建全新的连接，我会很好地使用它。
2. 使用带有互斥体的非阻塞套接字来控制对 SSL 上下文的访问。这将需要占用资源的轮询，而且我听说非阻塞实现不是很好。

这似乎是一件很常见的事情，那么这个问题的公认解决方案是什么？

Answer 1

Use non-blocking sockets with a mutex controlling access to an SSL context.

在单线程内使用非阻塞套接字，您将不需要互斥锁，因为您只能读取或写入(因为单线程)。

This would require resource-hogging polling, ...

您不需要“占用资源”的轮询。我假设您在这里的意思是忙于轮询，而不是使用系统的常用功能(如 select)等待(而不是循环)直到数据可用或可以发送数据。但是与普通套接字上的读/写相反，SSL 套接字如果想写就需要读，如果想读就需要写，即使套接字不可读，它们也可能在里面有数据。留意 SSL_WANT_READ、SSL_WANT_WRITE 和 SSL_pending。

...and I heard the non-blocking implementation is just not very good.

如果你习惯使用线程，它看起来更复杂。但是你有没有想过为什么像nginx这样的高性能服务器不用线程而是用非阻塞I/O呢？这是因为它需要更少的资源，并且没有与线程相关的问题，比如需要在关键部分(开销)周围互斥，并且在忘记互斥某些东西时会出现奇怪的和零星的错误。 nginx 还使用具有非阻塞 I/O 的 openssl。

我个人一直使用非阻塞 I/O，虽然由于协议(protocol)本身而不是 OpenSSL 实现而很难正确使用 SSL，但它是可行且快速的。

这意味着，单线程内的非阻塞 I/O 是您可以解决问题的一种方式。另一种方法是让 SSL 只使用内存 BIO 而不是真正的文件描述符，并自己完成所有的读写操作。但这可能比非阻塞 I/O 更复杂。

顺便说一句，通常 SSL context 表示 SSL_CTX 对象，它可以在多个 SSL 连接之间共享，并且在多线程中可能没有问题。您的意思是，不应从多个线程使用相同的 SSL 连接(SSL 对象)。