Google 有一个关于全站 HTTPS 的定量性能分析，CPU 负载上升 2%，内存消耗上升 2kb/per conn，结论：现代计算机的处理能力完全有能力处理基于 HTTPS 的 heavy trafic。随便写点烂代码都远比这点性能负担要损耗更多。
对 B/S 结构应用来说 SSL 的另外一个问题是数次 handshake 导致加载速度变慢，但也有 False Start 等技术来减小开销。 随着 HTTP2（SPDY）的推进，全站 HTTPS 是大势所趋。对于性能方面不要固守旧的认识，做点定量分析。 On Friday, October 24, 2014, Ben <[email protected]> wrote: > https 根本就是为了你这样的情况而设计的，你还嫌它不好，要另外找路，不知道说你什么好... > > 3）假设使用 https > - 客户端与服务器交互的次数多 比较耗费服务器资源 > （必须的额外花费） > - 有可能会提示不安全的站点 > （跟 CA 買 cert） > > > 4）关于使用证书，这种方式不利于用户体验，所以放弃掉。 > （这个不是https么？） > > > > Ben Lin > http://benincampus.blogspot.com > > 2014-08-25 4:46 GMT-07:00 Yuan Chao <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>>: > >> 老實說，現在檯面上的加密方式(這裡只討論對稱型)如AES之類的，都是經過很多驗證考驗過的， >> 在key不洩漏的情況下，應該是不需要擔心被破解的問題。(也就是除非用暴力以大量的時間/CPU去試解) >> 要自己實作一個加密方式，通常的結果只會是容易有未知的弱點。非對稱型如數位憑證之類的， >> 通常因為效能的關係，只用來交換session key，然後把這key用AES之類的對稱型來加密使用。 >> 這裡是不是透過browser其實沒多大差別。W3C能有現成的API當然會是件好事，最佳化也不用另外做。 >> >> >> >> 2014-08-25 18:58 GMT+08:00 John Hax <[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>>: >> >>> 安全性的基本原则就是不可依赖于加密方法（算法）是否公开。所有的加密算法要做的事情都是确保安全性是建立在密钥的秘密性而不是其他因素上。 >>> >>> 所以无论CS还是BS架构，最困难的部分其实就是 key 的管理（特别是对于对称加密算法来说）。 >>> >>> >>> 2014-08-07 15:52 GMT+08:00 "Yuan Xulei(袁徐磊)" <[email protected] >>> <javascript:_e(%7B%7D,'cvml','[email protected]');>>: >>> >>> 如果需要隐藏加解密算法，可以混淆代码，混淆的方式有很多种，这里不具体介绍。 >>>> 另外mozilla提供了一种将C/C++代码编译为js后运行于浏览器端的技术 - Emscripten[1]. >>>> >>>> 编译后的js代码接近与汇编代码，难以逆向，而且在支持asm.js的浏览器(Firefox, Chrome) 性能接近原来的代码。 >>>> 我这有一个编译好的js裤示例[2]供大家参考。 >>>> >>>> [1] http://kripken.github.io/emscripten-site/ >>>> [2] >>>> https://github.com/yxl/emscripten-zinnia/blob/1ac5c09221a48aa669364fdfb79674f7432e2194/emscripten/demo/js/emscripten_zinnia.js#L7194 >>>> On 08/06/2014 09:25 AM, Yang.Lyu wrote: >>>> >>>> Dear All： >>>> >>>> 大家好，刚接触前端不太久。心里存 在很多莫名其妙的疑问。 >>>> 请教大家一个关于前端数据加密的问 题。 >>>> >>>> 我在印象里，C/S结构的应用可以 通过加解密数据与服务器之间通讯，但是B/S类型的应用如何处理呢？ >>>> 所有的加解密手段不是都暴露出去了 吗？ >>>> 比如AES加密方式，当然证书与 Https类型不考虑，对于用户而言似乎不太友好。 >>>> >>>> 所以，请教大家，有更好的办法吗？ >>>> >>>> W3c似乎有一个Web Cryptography API草案，大家怎么看呢？ >>>> >>>> >>>> — >>>> 蜜圈项目经理 吕阳 >>>> 185-0285-3025 >>>> >>>> >>>> >>> >> >> >> -- >> Best regards, >> Yuan Chao >> > > -- Sent from Gmail Mobile
