2019-07-31Session ID:会话复用压力在服务端
Session Ticket:压力在客户端，客户端不安全所以要频繁换密钥文件
PSK:验证阶段把数据也带上，少一次请求
前两个都是缓存复用的思想，重用之前计算好的结果，达到降低CPU的目的。第三个就是少一次链接减少网络开销。
感觉都可以把开销大的东西缓存起来复用，缓存真个好东西，空间局部命中和时间局部命中定理太牛逼了。不过最关键的还是找性能瓶颈，精确定位性能瓶颈比较重要，然后针对瓶颈优化，空间换时间或者时间换空间。这个时候算法的价值就体现出来了。可惜这些我都不会╯﹏╰展开作者回复: psk实际上是Session Ticket的强化版，本身也是缓存，但它简化了Session Ticket的协商过程，省掉了一次RTT。
多在实践中学，多看些开源项目，就能逐渐掌握了。 1 5
2019-08-011. 你能比较一下“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 发送过去了，减少了握手次数。展开作者回复: 说的挺好，PSK其实就是Session Ticket的强化版，也有ticket，但应用数据随ticket一起发给服务器。
2
2020-01-17session id 把会话信息存在服务端
session ticket 把会话信息存在客户端
psk 在session ticket 的基础上，使用early data顺便再发送一下服务端的数据作者回复: 态度认真、积极，good。
2020-01-16老师，https://www.chrono.com:441/28-1 这个我抓包看到client和server的session-ID不一样，而且每次也都是server发了变更密码规范消息后才发加密的数据，跟您说的不一致？不知什么原因作者回复: 第一次握手肯定是没有会话复用的，到第二次就会会话复用。
第一次后实验环境在浏览器会显示出“reused? false”，这就是没有复用。然后wireshark重新开始抓包，刷新一下页面，会显示为“reused? true”，这个时候再看抓包。
我又做了一次试验，是可以的，你再操作看看。
2020-01-141、相同点：都是会话复用技术
区别：
Seesion ID：会话数据缓存在服务端，如果服务器客户量大，对服务器会造成很大压力
Seeion Ticket：会话数据缓存在客户端
PAK：在Seesion Ticket的基础上，应用数据和Session Ticket一起发送给服务器，省去了中间服务器与客户端的确认步骤
2、暂无展开作者回复: good。
- 2020-01-141、相同点：都是会话复用技术
区别：
Seesion ID：会话数据缓存在服务端，如果服务器客户量大，对服务器会造成很大压力
Seeion Ticket：会话数据缓存在客户端
PAK：在Seesion Ticket的基础上，应用数据和Session Ticket一起发送给服务器，省去了中间服务器与客户端的确认步骤
2、暂无展开作者回复: 好像二连了……
- 2020-01-141、相同点：都是会话复用技术
区别：
Seesion ID：会话数据缓存在服务端，如果服务器客户量大，对服务器会造成很大压力
Seeion Ticket：会话数据缓存在客户端
PAK：在Seesion Ticket的基础上，应用数据和Session Ticket一起发送给服务器，省去了中间服务器与客户端的确认步骤
2、暂无展开作者回复: 居然是三连……
2019-12-21老师，以下问题麻烦请回答一下：
1.客户端有时还会再去访问 CA，下载 CRL 或者 OCSP 数据，这又会产生 DNS 查询、建立连接、收发数据等一系列网络通信，增加好几个 RTT。这个CRL 或者 OCSP是对应到某个网址上面的嘛？客户端根据网址访问？
2.它可以让服务器预先访问 CA 获取 OCSP 响应，然后在握手时随着证书一起发给客户端，免去了客户端连接 CA 服务器查询的时间。这里不是客户端自己去验证的会不会有问题？服务器自己代做了。作者回复:
1.crl和ocsp是一个很大的列表，包含所有过期或者作废的证书序列号，不关联到具体的网址。客户端只要在这个列表里查一下证书序列号是否在这里面就行。而证书里面是包含网址的。
2.ocsp都是经过ca签名的，所以不会被窜改，保证肯定是ca发出的。
2019-10-16PSK 在发送 Ticket 的同时会带上应用数据，免去了 1.2 里面的服务器确认步骤。
这句话有点不太理解，请问老师：
1. 看图上 pre_shared_key 是在 Hello 中发送的，Session Ticket 也是在 Hello 中发送的吗？
2. 带上应用数据是什么数据?
3. 1.2 里面的服务器验证指的是哪个步骤？作者回复:
1.是的，hello消息里有个pre_share_key扩展，就是ticket。
2.在https里应用数据就是http报文了。
3.在tls1.2的会话复用里，必须在服务器发送server hello确认建立加密连接之后才能发送应用数据，而tls1.3就不需要这个确认步骤。
2019-08-30老是，如果使用服务器集群来做专门的加解密运算，建立TSL链接时，客户端将数据发送给服务器集群计算密钥，服务端又是如何安全的将密钥返回？或者是在解密报文时，又如何将解密后的报文安全返回？作者回复: 由于都是内网，所以就不存在外网那么多的威胁，所以可以直接通信，无需其他安全手段。
1
2019-08-18客户端再次访问的时候会携带session ticket，服务器解密后验证有效期，就可以恢复会话，开始加密通信；关于这句话，服务器解密后只是验证ticket的有效期吗？session ticket用于加密会话信息，如果不做其它验证，是怎么确定客户端的身份呢？作者回复: 除了有效期，ticket里还存有加密后的会话密钥，具体的内容在课程里没有详细介绍，你可以参考rfc。
2019-08-02老师好，问下使用了 OCSP Stapling 那客户端是不是就不要去 CA 验证证书了，那会不会导致不安全呢。作者回复: OCSP Stapling实际上是把请求CA验证证书有效性的过程由客户端转移到了服务器，它的本质没有变化，所以仍然是安全的。
至于为什么安全，这就要去细看它的协议和数据格式了，不过一般不用关心这些细节。
2019-07-31老师你好，预共享密钥的0-RTT不是真的0-RTT吧。作者回复: 当然是0-rtt，不过是指在建立tcp连接后的0-rtt，也就是tcp握手之后立即发送应用数据，不需要再次tls握手。
- 2019-07-31老师你好，有什么好办法可以有效监控和调优Https连接建立的具体时间吗？
作者回复: 可以看Chrome的开发者工具，每个uri的timing页里会有详细的延迟分布。
- 2019-07-31你好，有个问题想请教一下，线上的项目，一个是生产环境，一个是测试环境，我在同一个浏览器上进行访问这两个环境，当我从测试上切换到生产上之后，生产环境需要重新进行登录，而且当我从生产上切换到测试上之后也需要进行登录，点击登录之后就报400错误，而且接口调用也改变了
作者回复: 可以先用wireshark抓包看看，传输的数据有什么变化，是不是带上了cookie。
2019-07-31TCP fast open开启算不算优化呢作者回复: 也算，不过属于tcp优化，不属于https优化。