@OkabeRintaro 想看懂这个？ 首先你需要学习一下 asn.1 编码规则。 然后你需要学习一下 x509 的规范。 （或者你可以在网上找一些教程快速入门），这里附上我觉得比较好的连接：ASN.1 编码规则： http://luca.ntop.org/Teaching/Appunti/asn1.html ，X.509 规范 https://www.rfc-editor.org/rfc/rfc5280 。 这里建议你直接找 wiki 或者教程简单学习就行，这里知识很多

pem 文件通常都是证书或者公钥，私钥。 你这里应该是 base64 编码的 asn.1 数据。 可以使用 asn.1 工具查看，我常用这个 https://lapo.it/asn1js/#。

不抬杠，单纯讨论一下。 “http 本来是不存在安全问题的(因为能通过技术手段避免)”？ 特别好奇你能通过什么技术手段避免？ 难道自己把 tls 中已经实现的数据加密，完整性校验等功能在应用层再重新写一遍？ 再比方说，我有一个需求，我需要往 s3 上备份数据，我的数据需要安全保证，因此我需要数据在公网上安全的传输，此时我想除了 tls 之外没有其他的方案。这里最大的问题在于，你是客户端，服务器是别人写的，你们需要一个协议来确保数据安全的传输。

你对于 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. 不太明白你这个问题什么意思