28 | 连接太慢该怎么办：HTTPS的优化

Session ID:会话复用压力在服务端 Session Ticket:压力在客户端，客户端不安全所以要频繁换密钥文件 PSK:验证阶段把数据也带上，少一次请求 前两个都是缓存复用的思想，重用之前计算好的结果，达到降低CPU的目的。第三个就是少一次链接减少网络开销。 感觉都可以把开销大的东西缓存起来复用，缓存真个好东西，空间局部命中和时间局部命中定理太牛逼了。不过最关键的还是找性能瓶颈，精确定位性能瓶颈比较重要，然后针对瓶颈优化，空间换时间或者时间换空间。这个时候算法的价值就体现出来了。可惜这些我都不会╯﹏╰

session id 把会话信息存在服务端 session ticket 把会话信息存在客户端 psk 在session ticket 的基础上，使用early data顺便再发送一下服务端的数据

1. 你能比较一下“Session ID”“Session Ticket”“PSK”这三种会话复用手段的异同吗？ 答： （1）Session ID 类似网站开发中用来验证用户的 cookie，服务器会保存 Session ID对应的主密钥，需要用到服务器的存储空间。 （2）Session Ticket 貌似有点类似网站开发中的 JWT（JSON Web Token），JWT的做法是服务器将必要的信息（主密钥和过期时间）加上密钥进行 HMAC 加密，然后将生成的密文和原文相连得到 JWT 字符串，交给客户端。当客户端发送 JWT 给服务端后，服务器会取出其中的原文和自己的密钥进行 HMAC 运算，如果得到的结果和 JWT 中的密文一样，就说明是服务端颁发的 JWT，服务器就会认为 JWT 存储 的主密钥和有效时间是有效的。另外，JWT 中不应该存放用户的敏感信息，明文部分任何人可见（不知道 Session Ticket 的实现是不是也是这样？） （3）PSK 不是很懂，貌似是在 tcp 握手的时候，就直接给出了 Ticket（可是这样 Ticket 好像没有加密呢）。 总的来说，Session ID 需要服务器来存储会话；而 Session Ticket 则不需要服务器使用存储空间，但要保护好密钥。另外为了做到“前向安全”，需要经常更换密钥。PSK相比 Session Tick，直接在第一次握手时，就将 ticket 发送过去了，减少了握手次数。

1、相同点：都是会话复用技术 区别： Seesion ID：会话数据缓存在服务端，如果服务器客户量大，对服务器会造成很大压力 Seeion Ticket：会话数据缓存在客户端 PAK：在Seesion Ticket的基础上，应用数据和Session Ticket一起发送给服务器，省去了中间服务器与客户端的确认步骤 2、暂无

1.抓包看了下 442 ，复用会话时 Client Hello session_ticket 确实有数据，Sessioin Id 好像也还会复用。 Transport Layer Security TLSv1.2 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 512 Handshake Protocol: Client Hello ... Random: 9474888cafdce89fd32eac247a8b464f842efbac706d8930… Session ID Length: 32 Session ID: a4a0caef10dee7a6f44aa522a35f6c799101d5eced01eb32… # Session ID ... Extension: session_ticket (len=192) # session_ticket Type: session_ticket (35) Length: 192 Data (192 bytes) ... Transport Layer Security TLSv1.2 Record Layer: Handshake Protocol: Server Hello Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 100 Handshake Protocol: Server Hello ... Random: e82519e9e8bfcbd40e1da7a202bd50ff993d5ef0cbc33378… Session ID Length: 32 Session ID: a4a0caef10dee7a6f44aa522a35f6c799101d5eced01eb32… # Session ID Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ... TLSv1.2 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec TLSv1.2 Record Layer: Handshake Protocol: Finished 2.有个疑问：会话复用技术，保存会话数据的一端使用对端传过来的 Sessin Id 查询到之前的 master secret，但它如何安全的把这个 master secret 传递给对端（对端应该只有 Sessin Id 吧）？ 3.抓包过程用 Chrome 发请求，前三次 Client Hello, Server Hello 握手过程都因为 Alert (Level: Fatal, Description: Certificate Unknown) 失败了，第四次才成功。 而使用 FireFox 发请则不会出现。这是因为 Chrome 内置的证书更少吗？

老师，以下问题麻烦请回答一下： 1.客户端有时还会再去访问 CA，下载 CRL 或者 OCSP 数据，这又会产生 DNS 查询、建立连接、收发数据等一系列网络通信，增加好几个 RTT。这个CRL 或者 OCSP是对应到某个网址上面的嘛？客户端根据网址访问？ 2.它可以让服务器预先访问 CA 获取 OCSP 响应，然后在握手时随着证书一起发给客户端，免去了客户端连接 CA 服务器查询的时间。这里不是客户端自己去验证的会不会有问题？服务器自己代做了。

good good study，day day up.

老师，文章里说，这后一次握手的重点是算出主密钥“Master Secret”，而主密钥每次连接都要重新计算，未免有点太浪费了。难道每次连接的主密钥是一样的？不是每次连接的ecdhe的公钥私钥都是不同的吗？怎么还可以缓存呢？

1：你能比较一下“Session ID”“Session Ticket”“PSK”这三种会话复用手段的异同吗？ 1-1：回话复用 核心是缓存主密钥，为啥要缓存？因为计算出主密钥比较费劲，如果能重复利用，重复计算的活就免了，这是在拿空间换时间。 1-2：Session ID 可以认为是缓存主密钥的key，在客户端和服务器都有存储，通过传递这个key来获取和重用主密钥。 缺点是太费服务器的村村资源，因为每一个客户端的回话数据都需要保存，如果客户端有百万甚至千万基本，那存储空间使用的就有些多啦！ 1-3：Session ticket 这个方案可以解决服务器存储空间压力山大的问题，核心是把信息放在客户端存储，当然是加密后的信息，服务器侧需要解码后再使用。 1-44：PSK 和Session ticket类似，为了效率加大了一些安全风险，ticket中带上了应用数据的信息，这样能省去服务器的确认步骤。为了加强安全性，使用上做了一些限制。 有此可见，没有完美的解决方案，具体想要什么需要自己权衡对待。想要实现多快好省，那要么是一句口号，要么必须付出其他的代价。 2：你觉得哪些优化手段是你在实际工作中能用到的？应该怎样去用？ 软件优化这个估计最常用，也能用到，一些安全漏洞或性能优化常这么玩。

PSK 在发送 Ticket 的同时会带上应用数据，免去了 1.2 里面的服务器确认步骤。 这句话有点不太理解，请问老师： 1. 看图上 pre_shared_key 是在 Hello 中发送的，Session Ticket 也是在 Hello 中发送的吗？ 2. 带上应用数据是什么数据? 3. 1.2 里面的服务器验证指的是哪个步骤？