@3dwelcome
不让炒，又不是没被炒。NFT 现在没找到什么特别好的场景，现阶段还是靠炒作。
就跟 2020 年的时候国家也不让炒作口罩，但是也有一帮人炒作高价口罩一样。

@murmur 是的，没有去中心化的区块链可信度很低，自己控制 51% 以上就没有可信度。某个企业自己运营的链基本上不具备安全性。

@aguesuka 这个倒好说吧。有旁路由的话挖矿机器指向旁路由，完了旁路由负责打包发境外，套了一层梯子了就不会被识别了。另外还听说过一些代理软件，原理和旁路由类似。

1. 如果没有公网 IP 的话先拿到公网 IP 。
2. 1000Mbps 的话一般需要换 10G PON 的猫，没换的话可以要求运营商换掉。

另外上海电信可以改桥接的。

@Wdafff 这种也可以，不过量不够的厂商应该是拿不到专用通道用来发反向上行短信的吧。

1. APP 层面能做的很多啊。比如上报一些终端信息之类的做风控，大量重复的异常终端直接干掉。再比如用户行为分析的数据，进来直接点注册需要更严格的审核，比如需要先验证邮箱才行。如果上述太难也可以有一些暴力的缓解手段，比如注册账号之后才能发短信验证，短信的手机号码不支持修改等等。
2. 即使不考虑这些，也可以做一些验证码策略。例如国内运营商普遍采用万号段进行治理，万号段内超过一定阈值比如 50 就会告警甚至拉黑所有来自这个万号段的短信。另外也可以针对地域设置策略，例如估计 +1 的注册用户一般每天不超过 500 ，那么一天发往这个群组的短信超过 1000 或者单小时触发 200 就直接停掉后续发送。

目前最长支持期限也就是 10 年了，如果必须要在支持期限内的话必须要考虑这个问题。对于外包项目来说这个升级当然是作为付费服务给客户，客户不接受的话那就接着跑。而且 Docker 化封装之后也几乎没什么依赖问题，升完级之后直接就可以跑。
另外 CentOS 7 维护也就在 2024-06-30 停止了，还不如 Ubuntu 20.04 来得好，起码后者实打实的能到 2025 年。

@JoeoooLAI 2003 升级 2019 肯定要换硬件了，相当于应用程序搬家呗。

@chotow Windows 支持根证书自动更新功能，除非这个功能被手动关闭或者 Windows Update 被关闭否则都会自动下载 ISRG 根。

理论来说可以，但实际上双方能展开的合作很有限。一般还是行业上下游（同行业不同层级）在一起合作会比较好，能更好的实现一个或具体或模糊的目标，比如校企，集成商和设备商，电池厂商和手机厂商等等。

不同行业的同层级供应商就没有这个效果，比如安全设备厂商和网络设备厂商虽然都串在网络内，按理说适用于您这个模式。但是从销售的角度来说其实是各接各的订单，相互之间没有什么订单可以合作的。从技术的角度来说大家都按标准来就能相互兼容，而且网络设备厂商往往话语权更强，实际一般是安全设备来适配网络设备的功能，也不存在什么合作的基础。

原则上还是要上 Debian 11 的，毕竟根据官方文档 https://wiki.debian.org/DebianReleases ，Debian 10 距离结束主流支持（ 2022.8 ）不远了，虽然还有 2 年的 LTS 以及后续由第三方提供的 ELTS 但是还是建议直接上新版本。

另外手册建议看对应架构的，如 AMD64 为 https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.zh-cn.html

@slomo 您说的会更智能，不过一年跑一两次的话，看下流量曲线就能知道大致的低峰期了，完了在大致的低峰期内按照合适的频率给接口打请求或者塞到消息队列里完事。比如一般的业务 2-5 点低峰，那就 2:00-3:00 完成按最后登录或者什么其他指标排序的前 1/6 ，3:00 - 5:00 完成 2/3 ，5:00-6:00 完成最后 1/6 。

@slomo 如果是这样的需求的话，不如考虑给用户等级查询这块改一下，存储的时候用户等级伴随有效期，读取的时候判断是否有效，无效的话按照新规则重算。

举例：用户 A 的数据在去年 12.31 23:59:59 失效，01.01 00:00:00 时用户 A 请求用户等级接口的时候，服务判断 2021 年数据为脏数据之后自动调用规则判断 2021 年全年消费数据生成新规则并写入，有效期到今年年底。另外安排一个服务在低峰期对未调用接口的用户主动进行重算，避免有些直接取数据库的地方有误差（例如数仓）。

@hackfly 没有证据证明比市场价稍低的东西就是洗钱（话费补贴套现、回收充值卡之类的合法方式也可能这么搞），更何况电话费的成本很难衡量。

没看懂是增量数据应用新规则还是全量数据应用新规则。

我感觉可以在节点维护一个数据结构用来表示当前版本的规则数据，考虑到规则数据需要提前运算可能需要下发 Redis 库 IP 之类的信息。
改完之后相当于下发时间和切换时间解耦了，下发时间可以任意（比如 10 分钟后生效），节点到点切换规则就可以。

当然这么玩需要下面的机器配置 NTP 服务器保证时钟基本一致，否则还得清理脏数据。

建议还是主要谷歌翻译，特殊情况下慢慢理解原文，毕竟想不卡得长时间读英文原文，语言类的东西短期搞定不现实。

当然如果您学习语言能力还尚可以那建议多学习英语，毕竟个人觉得在本行业能流畅阅读英文内容是很强的竞争优势。相当于您的技术节奏永远比国内快好几拍，退可在新技术上超越他人，进可以搞 C2C ，怎么都不亏。

好诶，做免费 CA 的厂家越多越好

@xuanbg
@ZE3kr
@ruixue
@lakehylia
@jobmailcn

1. 实现这个在 C/S 框架下也是要改服务端的。另外要注意一个安全问题，如果是两层 hash 的模式下攻击者不拥有用户的明文密码而拥有 内层 hash(password) ，那么攻击者也可以构造一个合法登录请求，让服务器无法分辨用户是否知道密码明文，这么改相当于额外构成了一个安全隐患，本来泄露的是 hash 过的密文结果能登您这个网站了。

2. 另外按照 1 这么改的话实际上密码是不能加盐或者盐必须直接发给客户端，这样的话又拉低了密码的安全系数，所以还不如明文传输完了让服务器那边能安全的给密码加盐，加盐可以提升脱裤场景下的攻击难度，而且由于盐不一样导致泄露的 hash 是无法直接复用到其他网站的。而且当前的最佳实践是哈希算法+一个密码对应一个盐。如果不用哈希算法的话那更没意义，毕竟攻击者拿到密钥或者私钥直接就能拿到密码明文了，安全性不如当前最佳实践。

3. 如果必须要做二次加密的话，合理的方式是使用 RSA 等非对称算法，服务器发公钥给客户端，客户端用公钥加密密码、OTP 等需要加密的数据之后再传给服务器，服务器用私钥解密。这个流程相当于 TLS 握手，所以意义很小。费这么半天劲只解决了低概率的 CDN 以及开发者错误记录（正常实现是绝对不会记录的，而且如果他恶意投毒的话是没意义的，因为不管是 CDN 还是开发者都可以直接在网页里面插入自己的代码从而直接把用户输入拿到），是一个成本极高收益极低的安全防护手段。

这个最早是有国内 CDN 的，后来因为内容违规，挂靠备案没了。

@spacezip 您测试的是 4K 直播频道还是点播 4K 资源。我不太确定现在歌华 4K 点播是走的 IPQAM 还是直接机顶盒拉网址。如果测试的是 4K 直播肯定没问题，毕竟这个是单独频点广播的。

DOCSIS 确实会出这个问题。简单来说就是理论来说带宽够，但是同轴上要去掉广播的电视频道以及数据资源也就不太够用了。另外即使不考虑电视频道和数据资源传输，那每个频点都开 DOCSIS 业务的话头端成本也压不住。

如果如装维所说是墙内线的问题，试试直接从家里拉一条超五类线直接捅到楼下交换机对应接口呢？

不过一般 LAN 接入基本上都伴随着设备老化，不是简单换个线的问题。