@jybox 确实， 有人专门杀熟， 有人是杀生，点对点的历史信用不具备可参考性

SSL/TLS 现在推荐使用类似 secp256k1 这类基于椭圆曲线的非对称密钥对系统就是因为 EC 系统通过 ECDH 来实现零知识证明的密钥分发 是天然抵御中间人攻击的。简单的来说， 假设有 2 个人，Alice 和 Bob， 各持有一个密钥对，Alice 的公钥给 Bob，Bob 的公钥给 Alice， 现在互相要发消息给对方， 假设 Alice 要发给 Bob， 那么 Alice 只需要用自己的私钥和 Bob 的公钥就能计算出一个密钥， 用这个密钥通过对称加密比如 AES 加密数据后发给 Bob，Bob 获取后， 通过自己的私钥和 Alice 的公钥就能同样计算出和 Alice 一样的密钥， 就能解开密文得到原始数据了。

非对称加密的话， 均是 公钥加密， 私钥解密， 私钥签名， 公钥验签， 把握住这个 4x4 的四字箴言就不会搞错了

你这种学习叫死记硬背似的学习， 其实根本没有理解面向对象的实质

@lance86 有社会工程学的存在，把你物理按住， 啥都憋说了

有我的存在， 电报已经不是最匿名且安全的 IM 了

@westoy 机房里做专业存储就没法简单的 RAID 来抗了， 这是常识， 比如我给朋友公司部署的整套 openstack 群集， 存储用了 20 台物理机做的 ceph 群集，200 块磁盘， 所有数据 1 备 5。这算是小规模的了， 毕竟只是家小公司。我们现在讨论的是个人家用。 我有个想法是用 10 块 2G 的树莓派 4，每个插一块 4T 的 HDD 硬盘 组一个 ceph 群集来做存储， 上万的成本， 等我练好挨打的功夫不怕被老婆打了就开始干。

@Maskeney RAID1， 除非 2 块一起挂

耶稣说他要打你左脸， 你就把右脸也伸过去让他打。 保证他就怕了， 你直接放个行军床在工位后头， 带上牙刷毛巾洗漱全套到公司，一连搞几晚上， 最好号召所有人一起这么干， 保证领导智商正常的话一定怕，要是不怕， 你就准备换工作吧， 领导智商有问题

个人觉得， 没有 RAID，就别叫 NAS，RAID 应该是 NAS 的基本配备。
自从单盘的垃圾群晖在停电的时候挂掉我 2T 的小姐姐的时候， 我就觉悟了， 没有 RAID 别谈 NAS

你这样子想是很危险的，骚年

背景调查， 工作经历算不算你的背景？

@yamedie verify 的目地是防篡改， 数据库对比字符串本身就防篡改了，这是其一， 验签是 CPU 开销而读数据库（或者是 redis ）是 iO 开销，CPU 开销不容易优化，而 IO 开销一旦异步的话很容易优化。但是 jwt 的签名只不过是排列一下字符串重新 sha1 一次再判断是否相等， 对于 java 来说开销可以忽略。
有一个原则可以思考一下， 如果前端的 webserver 很多，且可以扩展，就尽量考虑让前端的 server 多耗点 CPU，降低 IO。 如果前端机器少， 那么就考虑省点 CPU， 用 IO 来换。系统的任何优化都是要有数据指标的，你的整个系统内的 CPU 核数， 决定了系统的总处理能力， 而分布式系统内带宽是有限的，总 IO 处理能力是有限的，是耗 CPU 还是耗 IO， 应该由系统的结构和业务类型来决定， 而不是仅仅针对单个功能点来看。

要什么评论，看着不闹心么，哈哈

楼主那位前同事应该只是复用了原来写好的鉴权部分的代码而已， 估计整个项目的代码框架都是直接用了之前的项目模板， 甚至直接老项目删删就直接拿来用了， 外包嘛， 最求成本效益最大化，谁管你代码质量， 安全性效率什么的

@douchebag 你居然带妹子去电影院是为了看电影......

哈哈哈， 这个问题就跟著名的空档滑行省油还是带档滑行省油问题一个样子， 新技术遇到了不思进取的老司机。用起来大致上是没有差了， 但是失去了 stateless 的意义， 把 Webserver 校验的压力转嫁给了数据库。

@abcbuzhiming jwt 的安全性并不是低， 签名能够防止篡改了，也就无法跨域脚本攻击了

@xuanbg 你对安全的理解有误， 直接存数据库然后对比 jwt 的 token 并没有安全上的问题， 因为你如果改了任何一个部分字符串就变了， 数据库判断就通不过了，如何篡改？这么做安全上没问题， 只是失去了 jwt 的意义而已

回头写 Java 会不会很想屎啊？节哀