本文详细对比了HTTPS与HTTP在服务器资源消耗方面的差异，重点分析了SSL握手过程带来的额外开销，包括网络延迟与加密解密操作。此外，还探讨了通过优化SSL会话管理减轻服务器负担的方法。
一些国际网站，比如维基百科，在其中https前先会考虑自己计算能力是否可以承载https。请问，https要比http多用多少服务器资源？
https其实就是建构在 ssl 层之上的 http协议，所以要比较https比http多用多少服务器资源，主要看 ssl 本身消耗多少服务器资源。
http使用TCP 三次握手建立连接，客户端和服务器需要交换3个包，https除了 TCP 的三个包，还要加上 ssl握手需要的9个包，所以一共是12个包。http 建立连接，按照下面链接中针对 Computer Science House的测试，是114毫秒；https建立连接，耗费436毫秒。ssl 部分花费322毫秒，包括网络延时和ssl 本身加解密的开销（服务器根据客户端的信息确定是否需要生成新的主密钥；服务器回复该主密钥，并返回给客户端一个用主密钥认证的信息；服务器向客户端请求数字签名和公开密钥）。
SSL handshake latency and HTTPS optimizations. :: semicomplete.com
当SSL 连接建立后，之后的加密方式就变成了3DES等对于 CPU 负荷较轻的对称加密方式。相对前面 SSL 建立连接时的非对称加密方式，对称加密方式对 CPU 的负荷基本可以忽略不记，所以问题就来了，如果频繁的重建 ssl 的session，对于服务器性能的影响将会是致命的，尽管打开https 保活可以缓解单个连接的性能问题，但是对于并发访问用户数极多的大型网站，基于负荷分担的独立的SSL termination proxy就显得必不可少了，Web 服务放在SSL termination proxy之后。SSL termination proxy既可以是基于硬件的，譬如F5；也可以是基于软件的，譬如维基百科用到的就是 Nginx，参见下面的链接说明：
SSL termination proxy
--------------------------------------------------------------------
可能看了上面的描述，有些概念过于专业，所以想讲一个故事让大家比较好理解：从前山上有座庙，庙里有个和尚......，别胡闹了，老和尚来了。小和尚问老和尚：ssl为什么会让http安全？老和尚答道：譬如你我都有一个同样的密码，我发信给你时用这个密码加密，你收到我发的信，用这个密码解密，就能知道我信的内容，其他的闲杂人等，就算偷偷拿到了信，由于不知道这个密码，也只能望信兴叹，这个密码就叫做对称密码。ssl使用对称密码对http内容进行加解密，所以让http安全了，常用的加解密算法主要有3DES和AES等。小和尚摸摸脑袋问老和尚：师傅，如果我们两人选择“和尚”作为密码，再创造一个和尚算法，我们俩之间的通信不就高枕无忧了？老和尚当头给了小和尚一戒尺：那我要给山下的小花写情书，还得用“和尚”这个密码不成？想了想又给了小和尚一戒尺：虽然我们是和尚，不是码农，也不能自己造轮子，当初一堆牛人码农造出了Wifi的安全算法WEP，后来发现是一绣花枕头，在安全界传为笑谈；况且小花只知道3DES和AES，哪知道和尚算法？小和尚问到：那师傅何解？老和尚：我每次给小花写情书的密码都不一样，关键是我和小花都要知道每封信的密码。呵呵，这里我用到了江湖中秘传的非对称密码。老和尚我现在手头有两个密码，一个叫“公钥”，一个叫“密钥”，公钥小花是知道的，江湖上好多人也知道，她每次给我写信，都要我的公钥加密她的密码，单独写一张密码纸，然后用她的密码加密她的信件，这样我用我的密钥可以解出这个密码，再用这个密码来解密她的信件。老和尚顿了顿：可惜她用的密码老是“和尚为什么写情书”这一类，我希望的是“风花”“雪月”什么的。可有一次出意外了，山下的张屠夫给了小花他自己的公钥，谎称是我的，小花后面给我的信的密码都用这个加密，然后张屠夫用他自己的密钥解开信件后，仿造我给小花发了很多下流的信，同时用小花的密码给我发来了绝交信，直到三个月之后才真相大白，可惜一切已无法挽回。之后我发布到江湖的公钥，上面都有嵩山少林寺的火印，没有火印的公钥，大家不再相信是我的，可是从此之后，我在江湖已经没有名声，也再没有收到过情书
。
http使用TCP 三次握手建立连接，客户端和服务器需要交换3个包，https除了 TCP 的三个包，还要加上 ssl握手需要的9个包，所以一共是12个包。http 建立连接，按照下面链接中针对 Computer Science House的测试，是114毫秒；https建立连接，耗费436毫秒。ssl 部分花费322毫秒，包括网络延时和ssl 本身加解密的开销（服务器根据客户端的信息确定是否需要生成新的主密钥；服务器回复该主密钥，并返回给客户端一个用主密钥认证的信息；服务器向客户端请求数字签名和公开密钥）。
SSL handshake latency and HTTPS optimizations. :: semicomplete.com
当SSL 连接建立后，之后的加密方式就变成了3DES等对于 CPU 负荷较轻的对称加密方式。相对前面 SSL 建立连接时的非对称加密方式，对称加密方式对 CPU 的负荷基本可以忽略不记，所以问题就来了，如果频繁的重建 ssl 的session，对于服务器性能的影响将会是致命的，尽管打开https 保活可以缓解单个连接的性能问题，但是对于并发访问用户数极多的大型网站，基于负荷分担的独立的SSL termination proxy就显得必不可少了，Web 服务放在SSL termination proxy之后。SSL termination proxy既可以是基于硬件的，譬如F5；也可以是基于软件的，譬如维基百科用到的就是 Nginx，参见下面的链接说明：
SSL termination proxy
--------------------------------------------------------------------
可能看了上面的描述，有些概念过于专业，所以想讲一个故事让大家比较好理解：从前山上有座庙，庙里有个和尚......，别胡闹了，老和尚来了。小和尚问老和尚：ssl为什么会让http安全？老和尚答道：譬如你我都有一个同样的密码，我发信给你时用这个密码加密，你收到我发的信，用这个密码解密，就能知道我信的内容，其他的闲杂人等，就算偷偷拿到了信，由于不知道这个密码，也只能望信兴叹，这个密码就叫做对称密码。ssl使用对称密码对http内容进行加解密，所以让http安全了，常用的加解密算法主要有3DES和AES等。小和尚摸摸脑袋问老和尚：师傅，如果我们两人选择“和尚”作为密码，再创造一个和尚算法，我们俩之间的通信不就高枕无忧了？老和尚当头给了小和尚一戒尺：那我要给山下的小花写情书，还得用“和尚”这个密码不成？想了想又给了小和尚一戒尺：虽然我们是和尚，不是码农，也不能自己造轮子，当初一堆牛人码农造出了Wifi的安全算法WEP，后来发现是一绣花枕头，在安全界传为笑谈；况且小花只知道3DES和AES，哪知道和尚算法？小和尚问到：那师傅何解？老和尚：我每次给小花写情书的密码都不一样，关键是我和小花都要知道每封信的密码。呵呵，这里我用到了江湖中秘传的非对称密码。老和尚我现在手头有两个密码，一个叫“公钥”，一个叫“密钥”，公钥小花是知道的，江湖上好多人也知道，她每次给我写信，都要我的公钥加密她的密码，单独写一张密码纸，然后用她的密码加密她的信件，这样我用我的密钥可以解出这个密码，再用这个密码来解密她的信件。老和尚顿了顿：可惜她用的密码老是“和尚为什么写情书”这一类，我希望的是“风花”“雪月”什么的。可有一次出意外了，山下的张屠夫给了小花他自己的公钥，谎称是我的，小花后面给我的信的密码都用这个加密，然后张屠夫用他自己的密钥解开信件后，仿造我给小花发了很多下流的信，同时用小花的密码给我发来了绝交信，直到三个月之后才真相大白，可惜一切已无法挽回。之后我发布到江湖的公钥，上面都有嵩山少林寺的火印，没有火印的公钥，大家不再相信是我的，可是从此之后，我在江湖已经没有名声，也再没有收到过情书
。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
