性能还是一致性？

     在握手式国密通讯的机制中，正常逻辑如流程一所示：

     上述流程中，服务端来判断 token 是否有效，如果失效会告知客户端，客户端需重新握手协商工作秘钥，并重发请求三。 屹通认为重发是一种性能浪费，于是做了如下流程二的“优化”：

     这里可能存在如下问题：

     服务端在反馈了握手请求之后重新 ntp 或者客户端手动修改时间导致客户端与服务端的时间戳不一致的问题；

     服务端意外删除缓存起来的 token 对应的工作秘钥，但是客户端并不知道。

     总结起来，是这么一回事：

     客户端跟服务端通信之前，应该跟服务端协商一些信息，接下来的通信，客户端将依赖于协商的这些信息（实际上就是工作秘钥）进行。但是为了安全性，这些信息是会周期性更换的。正常情况下，应该是客户端走某次与服务器通讯的过程中，由服务端告知客户端这些信息失效了，然后触发重新协商的过程，协商完毕，重新建立上次中断的请求。

     协商的信息中，服务端会返回一些辅助类字段，例如时间戳。然后屹通，根据这个时间戳，在客户端的网络框架去自行计算协商信息的有效期，而不是根据服务端的实际反馈。理由是多了一次业务请求，性能上由浪费。

     重试重发，在各种各样的场景中（例如 JOB 调度，RPC 请求），都是非常常规的做法，并不是非要避免。并且现在，功能都不对了（例如客户端由于网络分区或者用户手动修改手机时间，会导致本地时间戳和服务端时间戳不一致），空谈性能，有什么用。