let's encrypt 有访问速度限制？

lets encrypt: 这锅不背。

ps: lets encrypt 的限制是申请次数限制。

@SakuraKuma 那我就放心了...

lets encrypt 哭晕在厕所

@johnnie502 我并不理解那个请求证书认证是什么意思。。每次浏览器访问不是都要认证一次证书么？

重度网络基础知识

上面 typo

应该是 *重读

@cankoor
1. 你 HTTPS 速度慢与要加密吃 CPU 等因素有关。
2. 用证书加密本身是离线的(OSCP 查询也和这个没关系)。
3. LE 限制的是证书发放频率。

@xiaopc 懂了懂了，谢谢了

ab -k -n 1000 -c 100

你会发现 let's encrypt 突然良心发现让你变快了

@xiaopc #7 typo: OCSP

Time per request: 3057 ms
你这是有严重的性能问题

@fcten ==...我查了一下 keep alive。那当然了。。。。

@gstqc 我请求的就是一个纯文本。应该是 CPU 的问题吧

@xiaopc 那这样的话，下面的架构，把证书放在 SLB 上的问题就在 SLB 的 CPU 了。


这个问题，我也奇怪过。之前做 Laravel 优化，用 ab 测试带 https，性能报告低到令人发指。后来换了一个 go 的工具，终于 http/https 对比没那么离谱了

```bash
go get -u github.com/rakyll/hey
```

https://github.com/rakyll/hey

@my101du 我试了一下，速度快的让我怀疑是和`ab -k`一样的效果，就是 keep alive 了。

所有说 https 比 http 消耗的高的不多， 都是指 正常的用户访问。
正常的用户访问只有第一次情况是要验证证书，后续只有单纯的需要多花费一些 cpu 的加解密时间。


大多数人 比较的仅仅是：
“ 100 次 http 下载需要的时间与 1 次(证书认证+确认公私钥、加密方法、ssl 加解密)的 https + 99 次(单纯 ssl 加解密)的 https 需要的时间。

而 你比较的是 100 次 http 下载需要的时间与 100 次(证书认证+确认公私钥、加密方法、ssl 加解密)的 https 需要的时间。


对于第一种情况， 交换密钥验证证书所需要的数据量在总数量中占比微乎其微， 而第二种情况如果你请求的文件本身比较小，证书和密钥的数据量有可能都能超过总数据量的一半了。

(看你的 total，http: 50kb 左右，https: 90kb 左右， 单纯的加密数据增长绝对没这么多，至少 1/3 的数据量来自传递证书和公私钥)

另外数值差距大 cpu io 都有可能是瓶颈。

@zpf124 正解，感觉是这样的。对于短时超多用户的涌入，所以基本上就是第二种情况。

@zpf124 赞同。时间消耗主要是在 SSL 握手那里，公钥验证消耗较大。不过，私钥是不会传输的。

@Yanni0507 我脑抽了