为什么不要使用TLS连接数据库，而用WireGuard替代？
目录
这是我的高吞吐http2服务器优化经验分享系列 第二篇博客。
上一篇博客提到不要使用TLS连接数据库，可以使用WireGuard替代，本文详细介绍为什么这样。
配置次数
TLS工作在应用层，WireGuard工作在网络层，造成配置差异。
在应用层意味着，每个数据库实例都要修改配置文件来配置，在网络层，意味着仅需数据库在主机配置。
所以，如果使用了n个数据库，m个数据库主机，使用TLS需要做n乘m次配置；使用WireGuard只需要m次配置。
以使用mysql+redis为例，如果有5台主机，意味着使用TLS要配置10次，使用WireGuard只用5次。
而且，使用TLS，生产环境通常自建CA，自签发证书，配置证书自动更新等更会复杂。
量子安全性
目前标准的TLS1.3并不提供量子安全性，无论RSA还是ECC都是量子不安全的。
虽然像go1.24开始提供ML-KEM混合X25519这种量子安全的密钥交换算法，但目前在主流的数据库TLS中，尚不支持此类算法。
虽然WireGuard使用的Curve25519也不提供量子安全性，但WireGuard支持PSK，通过提供一个256位随机生成的密钥，即使攻击者能破解Curve25519（例如通过量子计算机），仍需破解PSK才能解密流量，类似AES256足够量子安全，对称密钥本身是量子安全的。最终使得带PSK的WireGuard具有量子安全性。
抗入侵分析
现在通过数据库部署在云服务器，使用WireGuard，可以数据库完全在内网，不暴露在公网，减少攻击面。
WireGuard已经提供了加密，可以替代TLS。现实中生产环境，通过每个客户端到数据库专用点对点路由配置，专用的用户名密码和权限分配，可以达到有效认证。
如果一个使用数据库的节点被攻陷监听内网流量，也可以盗取TLS客户证书当场冒充客户端。
所以使用WireGuard带配套措施，和使用TLS连接数据库，同样具有良好的抗入侵性。
可扩展性
在节点数量多的情况，比如有几百甚至更多节点连接数据库，WireGuard带配套措施的运维成本更高，因为要分配ip，设置专用的用户名密码和权限分配等等，每加一个节点就要重复一次，特别是每次加节点都要修改数据库的WireGuard配置文件。
而TLS可以通过自建CA和完善工具链，可以高度自动化的分配和更新证书，实现节点动态增加。
建议
在小规模时WireGuard带配套措施，连接数据库是个更好的选择。
随着节点的增大，使用TLS的运维成本会因为规模被均摊，因为使得这个方案变得合适。
结合WireGuard和TLS始终是可以的，只是注意引入了更多出错降低可用性的机会，在小规模时不太值得。