我现在想知道我们是否可以在 Linux 环境下基于以下策略/方案制作某种 SSL 服务器。
(1)对于初始请求，应该是在父服务器进程中传入的。在建立 SSL 连接并处理请求的初始解析后，请求（套接字）将被转发到请求处理进程以进行进一步处理。
(2) 请求处理过程将是应该预先运行的东西。从这个意义上说，我们不会在这里使用任何基于 fork-exec-pipe 的方案。
(3) 对于父服务器进程和请求处理进程之间的通信，已经建立了一些IPC，以便使用sendmsg() - SCM_RIGHTS技术将打开的套接字描述符从父服务器进程复制到请求处理进程。
(4) 在 SSL 功能方面，我们应该使用 OpenSSL (libssl)。
(5) 在请求处理过程中，我们应该利用父服务器进程的共享套接字描述符来创建新的 SSL 套接字。
关键是我不想浪费在服务器和请求处理过程之间传输数据的任何性能。我也不想根据请求生成请求处理过程。所以我想提前生成请求处理过程。
虽然我不确定我在这里所做的是否对你有意义，但如果你们中的任何人能给我一些关于上述方法是否可行的提示，我将不胜感激。
目前尚不清楚您到底在寻找什么，尤其是您想在哪里进行 SSL 加密/解密。
您想在请求处理程序进程中进行加密/解密吗？
这似乎是更有可能的解释。但是，您谈到在主进程中进行一些请求解析。在主进程中解析的数据是否已经是 SSL 会话的一部分？如果是这样，您必须在主进程中进行 SSL 握手（初始化和密钥交换）才能访问加密数据。如果您随后将原始套接字传递给另一个进程，它将无法访问父进程的 SSL 状态，因此它将无法继续解密父进程停止的地方。如果它试图重新初始化套接字上的 SSL，就好像它是一个干净的连接一样，客户端可能（正确地）将连接中间的未经请求的握手视为协议错误并终止连接。如果没有，它会出现一个安全漏洞，因为它可能是恶意重定向客户端网络流量的攻击者，而不是强制重新初始化的请求处理过程。通常不可能将初始化的 SSL 会话传递给不同的进程，而不通知它们 OpenSSL 的完整内部状态（交换的密钥、一些序列号等），如果不是不可能的话，这将是困难的。
如果您不需要接触父进程中的 SSL 会话，并且只解析在实际 SSL 会话开始之前出现的一些未加密数据（类似于 IMAP 中的 STARTTLS 命令），那么您的想法将毫无问题地发挥作用。只需阅读您需要阅读的内容，直至 SSL 交换应该开始的位置，然后使用 SCM_RIGHTS 将套接字传递给后端进程（参见cmsg(3)或此站点中的示例）。还有一些库可以为您完成工作，即libancillary。
还是您希望主进程为请求处理程序进程执行 SSL 加密/解密？
在这种情况下，将原始套接字传递给请求处理程序进程是没有意义的，因为他们从中得到的唯一东西就是加密数据。在这种情况下，您必须打开与后端进程的新连接，因为它将携带不同的数据（已解密）。然后主进程将从网络套接字读取加密数据，对其进行解密并将结果写入请求处理程序的新套接字。类似地在另一个方向。
注意：如果您只是希望您的请求处理过程根本不担心 SSL，我建议让他们在环回接口上侦听并使用类似stud的东西来完成 SSL/TLS 脏工作。
简而言之，您必须选择上述之一。不可能同时做到这两点。