使用 cURL、HTTPS POST 进行服务器到服务器通信
我正在实现服务器到服务器的通信，应该（可能）如下所示：
客户端（网络浏览器）<--> （网络应用）服务器（服务客户端）<--> （服务应用）中央服务器
一些客户端请求在本地处理，一些作为远程服务调用（而不是 RPC）执行。向中央服务器的请求格式为HTTPS POST，然后使用cURL发送；服务器回复适当的 JSON 消息。
问题是，我使用的是 HTTPS，每次执行服务查询时都需要一些额外的时间来进行证书验证。可以重复使用 cURL 句柄并发送“保持活动”连接标头，但是..在当前的 MVC 实现中，每个新的客户端请求都会生成 Web 应用程序的新实例（以及相应的服务客户端） - 这意味着，句柄会重新生成初始化并重新建立 https 连接。
因此，出现了以下问题：
- 是否有某种方法可以加速此类 HTTPS 请求？例如，在第一次成功连接后以某种方式绕过验证？
- 我可以放弃 HTTPS（特别是其耗时的证书检查过程）并结合某些授权方法（Diffie-Hellman）自行加密/解密 POST 和 JSON（例如，使用 mcrypt）吗？
- 我是否正在做一些完全错误的事情并且应该立即停止？
谢谢你！
I'm implementing server to server communications that should (probably) look like this:
client (web browser) <--> (web app) server (service client) <--> (service app) central server
Some of the client requests are processed locally and some are performed as remote service calls (not RPC). Request to central server is formatted as HTTPS POST and then sent using cURL; server replies with appropriate JSON message.
Problem is, I'm using HTTPS and it takes some additional time for certificate verification, each time service query is performed. It's possible to re-use cURL handle and send 'keep-alive' connection header, but.. In current MVC implementation, each new client request results in new instance of web app (and corresponding service client) - meaning, handle is re-initialized and https connection is established anew.
So, the following questions arise:
- Is there some way to speed-up such HTTPS requests? E.g., somehow bypass verification after first successful connection?
- May I forgo HTTPS (specifically, its time-consuming certificate check procedure) and encrypt/decrypt POST and JSON on my own (for example, using mcrypt) in conjunction with some authorization method (Diffie-Hellman)?
- Am I doing something completely wrong and should immediately stop?
Thank you!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您测量过 HTTPS 连接的开销吗？这真的很重要吗？
如果您想避免为每个请求进行握手，您可以尝试在服务器和中央服务器之间建立持久的安全连接。
您可以使用 SSH 隧道、VPN 等来做到这一点。
编辑：在中央服务器上保持保持活动连接的本地反向 HTTP 代理也是一种选择。
Did you measured the overhead of the HTTPS connection ? Is it really significant ?
If you would like to avoid doing the handshake for each request, you could try setting up a persistent secured connection between the server and the central server.
You could do that with a SSH tunnel, a VPN, etc.
Edit: A local reverse HTTP proxy that maintains a keep-alive connection on the central server would be an option too.