@SingeeKing 咦，问下 ALPN 可以直接发现吗？

走 NAT 的话可以

@vk42 试试招行，我索尼港版系统可以

opns

@qwerthhusn C 、Python 等语言可以不用加号，实际被当作一个完整的字符串字面量：
"abc" \
"def"
或者，在不产生歧义的情况下可以不加反斜杠
("abc"
"def")

@mosfet 草，时隔一年重新捡起奥德赛玩玩正痛苦不堪……

Win7 已经不再能合理获取正版了（
想了想，确实你想说的应该是指原版。

@ferock 所以说瓶颈在 HDD 上，不是 usb 也不是千兆网。上面我也说了 CrystalDiskMark 看了下，我的硬盘读取速度 120Mbps 左右。
这就是我说的 jones 原因分析错了，实际上解决了他的 “问题” 的，不是 NAS 而是 RAID 或者没有 RAID 分盘分区，存放在不同盘上。
读取时序问题基本只有在读取速度非常接近硬盘读取速度的情况下会发生，是个 SATA 协议任务队列长度和 “旋转磁盘” 的问题。打个比方，你有三个进程同时进行大量读取 0 1 2 三个扇区的活动，结果任务队列不是 012012012 而是 000222111，那一旦 000222 的读取总量超过 HDD 缓存，中间读取 1 扇区的机会会被跳过，直接导致 1 “卡了”。
拖动进度条不是顺序读取，根本不要讨论，就是直接播放。

场景论：哦这没毛病，我举双手同意，你继续。

我知道这个是什么问题了
光的双缝干涉实验 ✘
单光子双缝干涉实验 ✔

你说的是放上检测设备干涉条纹就消失的那个实验吧，注意，这里有“单光子”这个关键词……
顺便，电子也是可以做同样的实验的。

@RingSunKaiya 我记得官网有句话，pyd 就是一个 dll，只不过改了个后缀名让它更容易被辨识，但并不影响它确实是个 dll

开放世界？唯一指定开放世界游戏 kenshi 了解一下。

范畴论（ Category Theory ）中的 协变 与 逆变
吐槽下：面向对象的数学原理就是范畴论，但目前没有任何一门语言完全按照范畴论来设计面向对象架构，因为一个核心就是只能有 obj = obj.metaphor(field=new_value) ，不能有 obj.field=new_value，那就很不直观了。

剩下的 #2 讲得挺清楚的。

@ferock 你这个 4k 原盘有缩水吧…… 4k@24Hz 通常有 35-45Mbps，不过也就你的两倍
问下你的 RAID 情况？这个是重点。 @jones2000 的问题显然是出在机械硬盘读取速度上。我顺便测了下我的盘，顺序读取约 120Mbps，是根本吃不住 45Mbps *3 的。（ HDD 理想情况是 150Mbps ）
顺便 ZFS 的 ARC / L2ARC 能够对顺序读取进行预测，会抹去读取安排不正确（比如三个进程分别同时向 SATA 协议的硬盘三个不同扇区持续请求数据而不等待前一数据返回，会导致队列长度的竞态条件，读取时序是不均匀的）和时域码率波动导致的卡顿。

哦这没毛病，你继续。

F12 看下，请求的 Remote IP 是多少？
如果确实走了代理，那么 Chromium 不记得了，Firefox 应当显示代理服务器的 IP:port

看上去四则运算不分优先级保持左结合的话，运算结果是对的……

@ferock 我作这么个假设你看怎么样：
1. 松鼠症晚期，无脑收大量 4k 原盘
2. 然后一测试，就是不用走网络共享，一台电脑开三个 4k 原盘一看，哇，卡了
3. 然后他就觉得“哦这不行，得来个 NAS”

压力测试加上了从未能达到的压力，导致在服务器配置上面花费了多余不必要的开销，代码优化上花费了不必要的精力。
这也不是什么从未发生过的事情，所以为什么现在都喜欢强调“横向可扩展”，就是因为压力测试很难把握实际情况下的压力。
这算是典型问题了，还不至于让你盯这么紧吧

他身上更严重的问题是，压力测试通不过，分析原因分析得不对。那句话怎么说
Premature optimization is the root of all evils.
没进行实际的分析，就拍脑袋想方法解决。还好大部分组 NAS 的不会去搞纯 RAID1，不然速度还是一样，那他就得开始说 NAS 不行没有任何意义了。