cURL SSL PUT/POST 的延迟响应 (php)（NSS 与 OpenSSL）
我有两个基于 Fedora 的 apache Web 服务器，使用 php/cURL 进行相同的 SSL PUT/POST 调用。一个工作正常，但另一个调用成功，但需要很长时间才能返回响应（约 10 分钟）。 （GET 似乎不受影响）
工作服务器的 cURL 使用 OpenSSL for SSL，而非工作版本使用更高版本的 cURL，该版本使用 NSS for SSL
我对 SSL 实现或其对 cURL 的影响一无所知。什么会导致 SSL PUT/POST 响应出现如此显着的延迟？
任何建议表示赞赏 - 谢谢 -
I have two Fedora-based apache webservers making the same SSL PUT/POST calls with php/cURL. One works fine, but with the other the call succeeds but takes a VERY long time to return a response (~10 min). (GETs don't seem affected)
The working server's cURL uses OpenSSL for SSL, while the non-working version uses a later version of cURL that uses NSS for SSL
I know nothing about SSL implementations or their effect on cURL. What would cause such a significant delay in SSL PUT/POST responses?
Any suggestions appreciated- Thanks--
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我只能猜测，但某些 SSL 实现最终会尝试进行不必要的反向 DNS 查找，而这些查找可能需要很长时间才能超时。
I can only guess, but some SSL implementations end up trying to do unnecessary reverse DNS lookups and these can take a long time to time out.
是的，我敢打赌 DNS 问题。
尝试从根运行跟踪路由并获取一些连接数据。
在两台机器上执行此操作，以便您可以在调试中看到问题首先出现在哪里。
Yes, i would bet on a DNS issue along the lines.
Try run a trace route from root and get some connection figures.
Do it on both machines so you can see where there issues is first showing up in the Debug.
我不知道答案。 DNS 建议总是好的。其他想法包括 MTU 发现、服务器不提供中间证书，因此客户端可能会尝试下载丢失的中介或尝试检查 CA 恢复列表。
下载wireshark，您应该能够更好地了解客户端之间的行为差异。
I don't know the answer. DNS recommendations are always good. Other ideas include MTU discovery, server not providing intermediate certs so the clients may be trying to download missing intermediaries or an attempt to check the CAs recovation list.
Download wireshark and you should be able to get a better idea of the difference in behavior between clients.
你检查过 httpd.conf 中的 KeepAlive 选项吗，它应该是 On。
请参考http://www.debian-administration.org/articles/188
Have you check your KeepAlive options in httpd.conf, it should be On.
Please refer to http://www.debian-administration.org/articles/188