https vs http 性能

1.       HTTPS 一定要有明确的选择理由.

a)         HTTPS 实际上是SSL用于HTTP.

b)        主要解决了两部分的问题.

                         i.              1. 信任主机的问题. 采用https 的server 必须从CA 申请一个用于证明服务器用途类型的证书. 改证书只有用于对应的server 的时候,客户度才信任次主机. 所以目前所有的银行系统网站,关键部分应用都是https 的. 客户通过信任该证书,从而信任了该主机. 其实这样做效率很低,但是银行更侧重安全. 这一点对我们没有任何意义,我们的server ,采用的证书不管自己issue 还是从公众的地方issue, 客户端都是自己人,所以我们也就肯定信任该server.

                       ii.              2. 通讯过程中的数据的泄密和被窜改. 这里有两个层次

1.         一般意义上的https, 就是 server 有一个证书.

a)         主要目的是保证server 就是他声称的server. 这个跟低一点一样.

b)        服务端和客户端中件的所有通讯,都是加密的.

                                                                   i.              具体讲,是客户端产生一个对称的密钥,通过server 的证书来交换密钥. 一般意义上的握手过程.

                                            ii.               加下来所有的信息往来就都是加密的 . 第三方即使截获 , 也没有任何意义 . 因为他没  有                          有密钥 . 当然窜改也就没有什么意义了 .

2.         少许对客户端有要求的情况下,会要求客户端也必须有一个证书.

a)         这里客户端证书,其实就类似表示个人信息的时候,除了用户名/密码, 还有一个CA 认证过的身份. 应为个人证书一般来说上别人无法模拟的,所有这样能够更深的确认自己的身份.

b)        目前少数个人银行的专业版是这种做法,具体证书可能是拿U盘作为一个备份的载体.

2.       HTTPS 一定是expensive的.

a)         本来简单的http协议,一个 get 一个response. 由于https 要还密钥和确认加密算法的需要.单握手就需要6/7 个往返.

                         i.              任何应用中,过多的round trip 肯定影响性能.

b)        接下来才是具体的http协议,每一次响应或者请求, 都要求客户端和服务端对会话的内容做加密/解密.

                         i.              尽管对称加密/解密效率比较高,可是仍然要消耗过多的CPU,为此有专门的SSL 芯片. 如果CPU 信能比较低的话,肯定会降低性能,从而不能serve 更多的请求.

                ii.               加密后数据量的影响 .

1.         这个我用128bit 的RC2 测试了一下,加密后数量跟加密前基本相同.

3.       HTTP VS HTTPS 的性能

a)         这个由于很多人测试的背景不一样,由于时间太紧,我没有写出了一个类似 ACT 一样测试web https 的压力工具. 看了一下别人的观点.

b)        有些人说https 的性能是 http 的 40 % , 有些人说可能80%.

c)        我的观点.

                         i.              https 的关键性能影响是 CPU 和往返. 如果CPU 很强的话, 性能可能就是有人讲的80%. 如果cpu 是瓶颈的话, 有人讲原来可以server 330-500个请求每秒,现在只有30-50%

                       ii.              不需要用https 的地方,就尽量不要用.

1.         考虑前面提到的权衡

 

iii.              微软在设计高性能的web 应用程序中这么讲:

Segregate Secure and Non-Secure Content[1]

When you design the folder structure of your Web site, clearly differentiate between the publicly accessible areas and restricted areas that require authenticated access and Secure Sockets Layer (SSL). Use separate subfolders beneath the virtual root folder of your application to hold restricted pages such as forms logon pages, checkout pages, and any other pages that users transmit sensitive information to that needs to be secured by using HTTPS. By doing so, you can use HTTPS for specific pages without incurring the SSL performance overhead across your entire site.

Only Use SSL for Pages That Require It

Using SSL is expensive. Only use SSL for pages that require it. This includes pages that contain or capture sensitive data, such as pages that accept credit card numbers and passwords. Use SSL only if the following conditions are true:

·                     You want to encrypt the page data.

·                     You want to guarantee that the server to which you send the data is the server that you expect.

For pages where you must use SSL, follow these guidelines:

·                     Make the page size as small as possible.

·                     Avoid using graphics that have large file sizes. If you use graphics, use graphics that have smaller file sizes and resolution. Or, use graphics from a site that is not secure. However, when you use graphics from a site that is not secure, Web browsers display a dialog box that asks the user if the user wants to display the content from the site that is not secure