了解 HTTPS 连接设置开销
我正在构建一个基于 Web 的聊天应用程序，该应用程序需要对发送或接收的每条消息发出 AJAX 请求。我希望对数据进行加密，并且倾向于通过 HTTPS 运行 AJAX（带有长轮询）。
然而，由于这里的请求频率比基本的网页浏览要高得多，我想更好地了解为每个请求设置加密连接的开销（网络使用情况、时间、服务器 CPU、客户端 CPU） HTTPS 请求。
除了任何一般信息/建议之外，我很好奇：
- 作为一个非常粗略的近似值，与 HTTP 相比，HTTPS 请求需要多花多少时间？假设内容长度为 1 字节且为普通 PC。
- 第一个 AJAX 请求之后的每个 AJAX 请求都会缓存一些重要的内容，以便更快地建立连接吗？如果是的话，要快多少？
先感谢您 ：-）
I'm building a web-based chat app which will need to make an AJAX request for every message sent or received. I'd like the data to be encrypted and am leaning towards running AJAX (with long-polling) over HTTPS.
However, since the frequency of requests here is a lot higher than with basic web browsing, I'd like to get a better understanding of the overhead (network usage, time, server CPU, client CPU) in setting up the encrypted connection for each HTTPS request.
Aside from any general info/advice, I'm curious about:
- As a very rough approximation, how much extra time does an HTTPS request take compared to HTTP? Assume content length of 1 byte and an average PC.
- Will every AJAX request after the first have anything significant cached, allowing it to establish the connection quicker? If so, how much quicker?
Thank you in advance :-)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
HTTPS 中的所有内容都比较慢。个人信息不应该被缓存，两端都有加密，而且 SSL 握手相对较慢。
长轮询会有帮助。长期保持活力是有好处的。在服务器上启用 SSL 会话也可以避免大量开销。
真正的技巧是进行负载平衡或任何类型的合法缓存。作为聊天服务器，不确定它会在您的系统中发挥多大作用，但这是需要考虑的事情。
Everything in HTTPS is slower. Personal information shouldn't be cached, you have encryption on both ends, and an SSL handshake is relatively slow.
Long-polling will help. Long keep-alives are good. Enabling SSL sessions on your server will avoid a lot of the overhead as well.
The real trick is going to be doing load-balancing or any sort of legitimate caching. Not sure how much that will come into play in your system, being a chat server, but it's something to consider.
您可以从本文中获取更多信息。
大部分开销都在握手中（交换证书、检查证书吊销……）。会话恢复和最近的错误启动扩展在这方面有所帮助。
根据我的经验，最糟糕的情况发生在使用客户端证书身份验证并广告太多 CA 时 (服务器发送的
CertificateRequest消息甚至可能变得太大）；这种情况非常罕见，因为在实践中，当您使用客户端证书身份验证时，您只会接受来自有限数量的 CA 的客户端证书。如果您正确配置服务器（针对适合的资源），您还可以使用
Cache-Control: public为通过 HTTPS 提供的资源启用浏览器缓存。You'll get more information from this article.
Most of the overhead is in the handshake (exchanging certificates, checking for their revocation, ...). Session resumption and the recent false start extension helps in that respect.
In my experience, the worse case scenario happens when using client-certificate authentication and advertising too many CAs (the
CertificateRequestmessage sent by the server can even become too big); this is quite rare since in practice, when you use client-certificate authentication, you would only accept client-certificates from a limited number of CAs.If you configure your server properly (for resources for which it's appropriate), you can also enable browser caching for resources served over HTTPS, using
Cache-Control: public.