你对于 QoS 2 的理解是对的。 作为服务器肯定会保证 QoS 2 不会丢失（通常会将消息持久化到数据库或者文件系统中，以确保数据不会丢失）。 但是作为客户端，通常没有这样的机制，对于没有成功发送的数据一般只能报一个错误给上层应用程序，此时重发的任务就留给上层应用程序了。你需要自己在应用程序层面重新发送没有发送成功的消息。

举个例子，如果你把一条 QoS 2 的消息成功发送到了服务器，另外一个监听同样 topic 的客户端接收到了消息，但是还没有回复相应的 ack 或者说 ack 没有成功的到达服务器，此时服务器是需要在将来一个合适的时刻重新将这条消息发送给这个监听者的。

但是如果你的客户端在发送消息时断网，或者消息没有成功达到服务器（此时客户端还没有收到来自服务器的 ack ），那么这条失败的消息是需要发送消息的客户端自己保存，在将来某个时刻重新发给服务器的。这里你是不能依赖服务器的。

其实个人建议如果说性能的时候，尽量数据，环境，测试 case 都提一下，要不然直接上来提升一倍，很难让人接收

@brader 就像是写程序一样，如果一段代码太烂，bug 太多，你不能总是想着打补丁，而应该丢弃这段代码或者重写

我的 win10 也有同样的问题。 重启网卡之后会好一阵子，后边又坏了，但是不影响上网，只是显示不对而已

如果以会不会编程语言的高级特性来判断一个程序员的水平，那未免有些草率啊。 我称得上是老古董了，从来不适用高级特性，就是使用最简单的 while ，for ，if. 因此，我无论 写 java ，还是 c++，感觉都一样。

按照代码行数考核的集合一下

如果是那种过期了也可以很容易刷新的 token ， 只需要记录下 token 和对应的 token 过期时间就行。每次使用 token 之前判断一下是否过期，过期了就刷新一下就好。 轮询，按时刷新都太费了，过日子吗，就是要省:-)

@snoopyhai 这大兄弟估计想开车？:)

1. 这里常用的协议是 pkcs#11. 这套规范中提供了如何操作密钥的 api ，然后和 pkcs#11 兼容的硬件需要实现这样的类库。但是这里的密钥是无法导出的，如果支持导出，那么如果保证安全性呢。
2. yubikey 自身实现了加密解密，签名，验证签名的功能。 通过于 pkcs#11 兼容的类库暴露出来。（购买 yubikey 的时候应该会附带这个类库）
3. 不太明白你这个问题什么意思