@tmado #4 流媒体也就是最近十年的事，iTunes Store 时代的 iTunes，甚至 CD 时代的各种软件 /硬件播放器就已经是分开的了。

认证和加密靠 PGP/GPG 可以实现，然而最大的问题就是如何可靠地、可信地交换证书，以及正确地信任证书与现实身份 /真实身份的映射关系。

因为这两个功能本来就是分开的啊，做到一起有五种组合（不计单曲随机这种无意义组合），点起来累死了。

非互联网行业，大量使用商业产品和专有软件，一般看厂商的官方博客。

@Orciorc #10 是的，常说的“软交换”要么是指那种淘宝上卖的工控机软路由 /部分工作在透明桥接模式的低端防火墙 /虚拟化服务器中的虚拟交换机，使用 CPU 在两个被软件定义成二层桥接口的网卡接口之间转发流量；要么其实是指“软路由”——部分低端三层交换机（弱三层）使用 CPU/通用处理器执行 FIB 查表和解包重封包路由转发工作。

因为无论是是燃油车还是新能源，一般都不习惯首先使用刹车来减速。

又一说一，买个 iOS 设备，专门用来装 Microsoft Authenticator，我的还没崩过。专用的 iOS 设备，这也算是单独的硬件了。

1. 软负载分担很吃 CPU，这和聚合本身没关系。所以交换机有专门的处理器 /电路（可能是 LPU 、SFU 等）做负载分担。

2. 源 /目的 MAC/IP 四元组参数全部一致的情况下，哈希也是一样的，在操作 key 稳定的情况下，流量将永远被分担至相同的端口。

部分 -SI/-EI/-HI 的型号 /框式 /数据中心产品 /路由器 /防火墙支持基于传输层端口的负载分担或 per-packet 负载分担，除此以外还有基于 MPLS 标签的 /基于入接口的 /基于协议号的 /flexible 等。per-packet 负载分担基本就等同于 balance-rr，可以实现逐包负载分担，也就是让同一个 TCP 连接走不同的出接口。

但是越复杂、越上层的负载分担，对设备的处理负担也就越大。在低端设备上，我们真的需要粒度如此精细、如此接近绝对均衡的负载分担吗？在许多时延 /抖动敏感的应用上，多径大带宽的 TCP 传输效果真的比单一路径小带宽要好吗？跨框双归属 /M-LAG 的场景下，本地优先转发更是会优先于负载分担，让归属到非本地设备的链路直接不参与负载分担。

都是硬交换，成品交换芯片方案成本低得很。

还有就是这么大量的路由引入建议用 BGP 做，OSPF 这么用资源开销太大了。

Huawei 的 USG 可以通过 CSV 导入运营商地址库，然后做 ISP 选路。

@zhaorunze #10 我这边随便一个高校的财务数据库都是 Oracle 的。

好家伙，20 路的服务器我还真没摸过，至强铂金也才最多 8 路啊。

好家伙，干脆直接电源挖矿得了，以 kW 为算力单位，配合前段时间那个电车电桩挖矿的，薅资本主义羊毛。

DiskGenius.

静态地址专线？ Windows 的话及时更新+强密码+远程桌面就挺好的。

换个油车 +1

@joeyv2 #3 震惊，CDN 还有这么用的（没有说这样用不对的意思，只是这个需求比较奇怪）。楼主想要保全搜索引擎 SEO 就肯定要统一入口域名，这样一来感觉只能缩短记录 TTL 值，然后根据资源调度入口域名的去往的后端记录值了。

搜索引擎不关心 123. 前缀子域，它只关心人类用户能在浏览器地址栏看到的 abc. 前缀子域。
「没流量的时候走原站」啥意思看不懂。