mayli

关联讨论 https://www.reddit.com/r/ipad/comments/1d5txz8/im_following_up_with_my_last_post_about_the_lower/

计算一下你的租售比，如果现在出手看看能省多少利息，租房就完事.

如果你只是想最简单的解法（不考虑最高效率或者多机并发）可以试试 sort+uniq

sort 是可以排序比内存大的文件的: https://vkundeti.blogspot.com/2008/03/tech-algorithmic-details-of-unix-sort.html
然后排序后的 uniq 是不怎么吃内存

不过我看有个需求是要保持文件顺序的话，你可以用 uniq --repeated 来找到重复行，如果你重复行不多，那搞个脚本直接过滤一遍源文件就好，也是线性的。

推荐 rye

@BurYiA 最后发现我的需求大概 maas.io 可以覆盖，先 pxe 无盘启动扫描硬件，配置 bmc ，然后自动化装个 ubuntu ，需要啥再后面装。

反正有了系统后面就容易多了。

@newtonMiku 教育网一般有 iptv 具体怎么做的不大清楚

内网搞个电视直播（ IPTV 那种）

限速打开吧，到峰值再 QoS ，开个开源镜像站。

搞个集群跑 PCDN

其实利用率不高没啥问题，就两端 iperf 24/7 压测呗

一般来说，业界会使用成熟的加密算法和方法来进行验证，也就是不会自行发明轮子。例如安全密码验证会使用类似 bcrypt 和 salt 之类，为了增加安全性引入 2fa 。这种经过验证的安全性技术，用起来一般都不容易出现安全性问题。

对于题主的不信任 https ，进而选择在客户端进行“加密”，在安全性分析逻辑上其实属于“混淆”。因为客户端代码和逻辑都是可以被逆向和检查的，从传统的安全性上来说，基本上属于事倍功半的行为，而且一般情况下，系统的复杂度与漏洞数成正比，可以说系统越复杂存在的漏洞就会越多。引入一个这种技术，大概率是面向 KPI 的 feature ，而不是真的传统意义上的安全。比如说，你如果是客户端实现加密，是否需要引入 salt 或者 key ，那么这个 secret 是否也会通过所谓不安全的 https 通道传输到服务器，这个 secret 服务器需要明文还是可以进一步 hash ，这些都是当造轮子时需要考虑的问题。

当然，另一角度也可以说，我这是特别强力的混淆，就像 D 加密那样，没人可以逆向。这么说也行，不过对于实际场景来说，解决明文用户名密码泄漏的 2fa 技术已经足够流行和有效。即使在 http 情况下，也能一定程度避免 replay attack ，所以大部分公司没有必要投入资源去实现客户端加密。

所以和大部分计算机系统一样，当一个方案已经足够好，另一个方案没有明显优势的情况下，就不会被替换。

另外关于第三方的论点

> 重要的是，各个流程链条上，各自尽量做好自己环节的事情，三方厂商做好自己这一层，出了问题它是要赔钱的，我们不能确保三方一定不出问题，所以自己方负责的链条也做得安全强度更高，有错吗？

“我们不能确保三方一定不出问题”这个思路倒是正确的，但是大部分工业场景是妥协的结果，也就是预算情况下的最廉价解决方案。比如 TCP 本身已经保证不会丢包和乱序，在 tcp 初期，这个 tcp 第三方因为不被信任所以好多程序会自己发明个网络协议。但是 2024 年，不会有程序在 tcp 层上面再去检测乱序或者丢包，大多数情况下，文件传输后，算一下整体的 hash 就够了。妥协的结果就是，大部分的底层结构已经足够可信，对于登陆安全性方面，fidelity 用的明文，chase 用的混淆，我觉得都可以接受。