F5上面，这样的好处是内网流量http传输，加快性能，也方便分析统计等
还有一个，就是服务器和客户端算法的选择，因为在ssl初始阶段，会选择双方都支持的算法进行加密，据我们测算，不同算法间差异挺大的，可以到30%的性能
1，https后带来的性能损失问题，具体损失多少需要实际测试，看是否需要扩容2，https后带来的对于运维的影响，比如之前能抓明文流量分析，现在不行了等等3，https中对于第三方域名下的resource的https化的问题，这个我在别的帖子里介绍了一个办法，如果嫌麻烦，也可以使用我司现有产品，来解决m...
有一定影响，但不会太大，经过合理优化后，可以控制在个数倍数内
网上有很多关于ssl对比性能的测试，我这随便给一个，http://www.cs.nyu.edu/artg/research/comparison/comparison.html，这些测试跟你的优化、服务器性能、选择的算法，以及客户端的情况都有很大关系，根据以往经验，https是会稍微慢一些，但不会慢一个数量级，你可以按照2-8倍的大概进...
1，hsts可以解决；2，全站https是趋势，为了减少加解密次数，建议同站点，减少域名；启用ssl session 复用；3，选择证书链短的服务商、启用false start；4，硬件加速；另外http2、sessions复用等都有助于加速，可以去ssl lab下载作者的书...
本人亲历的一个经验教训是确保证书可以在线更新，因为证书是有过期时间的，之前出过问题，证书是固定在硬件内，导致过期后，用户的访问出了很大问题
https分为两个阶段，非对称加密和对称加密，非对称加密确实会慢一些，但对称加密几乎没有什么性能损失，因为算法是线性的。经过优化后，不会差太多，你可以理解不会差一个数量级以上，网上有一些性能对比，可以参考，http://www.cs.nyu.edu/artg/research/comparison/comparison.html...
目前能想到的，就是别把服务端压的cpu太高，其他的从客户端讲没什么区别
