简体繁体 English

使用cURL，HTTPS POST进行服务器到服务器通信

[英]Server-to-server communications using cURL, HTTPS POST

原文 2011-08-29 13:02:38 7 2 php/ curl/ https/ security

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 客户端 （ Web浏览器 ）< - >（ Web应用程序 ） 服务器 （ 服务客户端 ）< - >（ 服务应用程序 ） 中央服务器

Some of the client requests are processed locally and some are performed as remote service calls (not RPC). 一些客户端请求在本地处理，一些客户端请求作为远程服务调用（而不是RPC）执行。 Request to central server is formatted as HTTPS POST and then sent using cURL; 对中央服务器的请求格式为HTTPS POST，然后使用cURL发送; server replies with appropriate JSON message. 服务器回复适当的JSON消息。

Problem is, I'm using HTTPS and it takes some additional time for certificate verification, each time service query is performed. 问题是，我正在使用HTTPS，每次执行服务查询时都需要一些额外的时间进行证书验证。 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. 可以重用cURL句柄并发送'keep-alive'连接头，但是..在当前的MVC实现中，每个新的客户端请求都会产生新的web应用实例（和相应的服务客户端） - 意思是，句柄是初始化和https连接重新建立。

So, the following questions arise: 因此，出现以下问题：

Is there some way to speed-up such HTTPS requests? 有没有办法加速这样的HTTPS请求？ Eg, 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)? 我可以放弃HTTPS（特别是它耗时的证书检查程序）并自己加密/解密POST和JSON（例如，使用mcrypt）和一些授权方法（Diffie-Hellman）吗？
Am I doing something completely wrong and should immediately stop? 我做错了什么，应该立即停止？

Thank you! 谢谢！

2 个解决方案

Did you measured the overhead of the HTTPS connection ? 您是否测量过HTTPS连接的开销？ 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. 你可以用SSH隧道，VPN等来做到这一点。

Edit : A local reverse HTTP proxy that maintains a keep-alive connection on the central server would be an option too. 编辑：在中央服务器上维护保持活动连接的本地反向HTTP代理也是一个选项。

Batch the requests up in a queue and send them x number at a time if it is possible 将请求批量放入队列中，如果可能，一次发送x号码
You could send an authorisation key with the request that only the server and central server could possibly know how to assemble. 您可以发送一个授权密钥，其中只有服务器和中央服务器可能知道如何组装。 But that would leave your actual data in plain sight, which may or may not be a problem. 但这会使您的实际数据显而易见，这可能是也可能不是问题。
Not that I can immediately see 不是我能立刻看到的