SSL 对于 RESTful API 来说有多贵？
我正在制作一个 RESTful API，并且想知道如果每个请求都使用 SSL 完成，那么服务器的计算成本有多大？它可能很难量化，但与非 SSL 请求进行比较会很有用（例如，1 个 SSL 与 30 个非 SSL 请求一样昂贵）。
我的想法是否正确，要建立 SSL 连接，双方都需要生成公钥和私钥，相互共享，然后开始通信。如果使用 RESTful API 时，每个请求都会发生此过程吗？或者是否有某种缓存可以在给定的时间内重复使用给定主机的密钥（如果是，那么它们过期之前需要多长时间？）。
最后一个问题，我问的原因是因为我正在制作一个使用 facebook connect 的应用程序，并且涉及一些访问令牌，这些访问令牌授予对某人的 facebook 帐户的访问权限，话虽如此，为什么 facebook 允许通过以下方式传输这些访问令牌非加密连接？当然，他们应该像用户名/密码组合一样严格保护访问令牌，并因此强制执行 SSL 连接……但他们没有。
编辑：事实上，每当传输 access_token 时，facebook 都会强制执行 HTTPS 连接。
I am making a RESTful API and am wondering how computationally expensive it is for the server if each request is done using SSL? It's probably hard to quantify, but a comparison to non-SSL requests would be useful (e.g. 1 SSL is as expensive as 30 non-SSL request).
Am I right in thinking that for an SSL connection to be established, both parties need to generate public and private keys, share them with each other, and then start communicating. If when using a RESTful API, does this process happen on each request? Or is there some sort of caching that reuses a key for a given host for a given period of time (if so, how long before they expire?).
And one last question, the reason I am asking is because I am making an app that uses facebook connect, and there are some access tokens involved which grant access to someone's facebook account, having said that, why does facebook allow transmitting these access tokens over non-encrypted connections? Surely they should guard the access tokens as strongly as the username/passwd combos, and as such enforce an SSL connection... yet they don't.
EDIT: facebook does in fact enforce a HTTPS connection whenever the access_token is being transmitted.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
http://www.imperialviolet.org/2010/06/25/超频-ssl.html
http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
SSL 过程大致如下：
服务器（以及可选的客户端）使用证书以及签名质询来提供其（现有的，未生成的）公钥。对方验证签名（其数学有效性、到达 CA 的证书路径、吊销状态……），以确保对方是其声称的身份。
在经过身份验证的各方之间协商秘密会话密钥（例如使用 Diffie Hellman 算法）。
各方切换到加密通信
到目前为止，这是一个昂贵的协议，每次建立套接字时都会发生。您无法缓存有关“谁在另一边”的检查。这就是为什么你应该持久化套接字（使用 REST 的事件）。
SSL process is roughly as follows:
Server (and optionally client) present their (existing, not generated) public key using a certificate, together with a signed challenge. The opposite party verifies the signature (its mathematical validity, the certificate path up to the CA, the revocation status,...) to be sure the opposite party is who it claims to be.
Between the authenticated parties a secret session key is negotiated (for example using the Diffie Hellman algorithm).
The parties switch to encrypted communication
This is an expensive protocol up to here and happens every time a socket is established. You can not cache a check about "who's on the other side". This is why you should persistent sockets (event with REST).
mtraut 描述了 SSL 的工作方式，但他忽略了 TLS 支持会话恢复这一事实。然而，即使协议本身和许多一致的服务器支持会话恢复，客户端实现并不总是支持它。因此，您不应该依赖于恢复，并且最好尽可能保持持久会话。
另一方面，如今 SSL 握手速度相当快（大约十几毫秒），因此在大多数情况下它并不是最大的瓶颈。
mtraut described the way SSL works, yet he omited the fact that TLS supports session resuming. However, even as the session resuming is supported by the protocol itself and many conformant servers, it's not always supported by client-side implementations. So you should not rely on resuming and you better keep a persistent session where possible.
On the other hand, SSL handshake is quite fast (about a dozen of milliseconds) nowadays so it's not the biggest bottleneck in most cases.