我正在开发一个在 Windows PC 上运行的应用程序。该应用程序能够连接到局域网内的某种设备。它可以创建到它所连接的设备的多个 TCP 连接。我想用 TLS/SSL 保护每一个 TCP 连接。
天真的解决方案是对我的应用程序和另一端设备之间的每个 TCP 连接使用 TLS/SSL。但是我不确定这会产生多少开销，因为每个 TCP 连接都必须经过整个 TLS/SSL 协商/身份验证过程。我认为没有必要这样做，因为应用程序/PC 只需要协商/验证。然后所有 TCP 连接将使用相同的加密。我想使用的设备上还有一个 FTP 服务器（我正在考虑基于 SSL 的 FTP）。
是否可以创建从我的 PC 到设备的单个 TLS/SSL 连接，然后通过此隧道转发我的所有 TCP/FTP 数据？这是正确的解决方案，还是为我打算在我的应用程序和设备之间建立的每个连接创建单个 TLS/SSL 连接会更好？
您应该使用多个 TLS 连接。但是，您应该确保您的应用程序使用 TLS 缩写握手和会话恢复（可能使用会话票证）打开多个连接。
使用简短的握手和会话恢复允许您的应用程序重用之前完整握手的加密参数和主密钥，从而大大降低建立新 TLS 连接的成本。完整的 TLS 握手需要多次往返来协商 TLS 版本、密码和主密钥，并且涉及昂贵的 RSA 证书操作来验证证书链；与只是一次往返和便宜的对称加密操作的缩写握手相比。
此外，如果您的基础架构支持，您可能还想尝试使用 TLS False Start。TLS False Start 允许您更早地开始发送数据，从而进一步减少第一个字节的时间。
这听起来就像您正在寻找 VPN 但希望 TLS 提供安全性（而不是例如 IPSec）。如果您不关心平台兼容性，那么 Microsoft 开发了一种使用这种 SSL-VPN 方案的安全套接字隧道协议。
如果您所说的“某种设备”也是基于 Windows 的，那么您甚至可能不需要额外的软件来实现 SSTP。
我没有更多关于 SSTP 的知识，但 Wikipedia 链接和上述 Wikipedia 文章中链接的 MSDN 资源应该提供所有需要的信息。
另一种选择是 OpenVPN，它也可以使用 TLS 作为底层连接协议，支持服务器端和客户端证书进行身份验证。
这取决于您拥有的流量类型，或者换句话说，取决于您的应用程序需求。
新通信的延迟是一个关键点吗？然后，您可能希望保持该 TCP 连接处于打开状态，并通过同一个 SSL 会话对所有内容进行隧道传输。或者您可能需要传输大量数据并且可以并行化？然后肯定会在顶部使用自己的 SSL 层进行多个 TCP 连接。
如果您喜欢占用带宽，那么同时使用多个 TLS/SSL 就可以了。另一方面，如果你想保存连接撕裂/设置，那么使用一个是要走的路。
这就提出了一个问题，如何以最少的麻烦来做到这一点。您可以设计自己的协议，或者使用某种连接代理......等等。简而言之，这意味着，您必须弄清楚您是否处于早期优化循环中，您可能在哪里过度设计解决方案。