@EarthChild 那还是不太对，正确设置的话应该能保证你同时上传下载的时候，上传至少有 100M 以上才对

@EarthChild 你这个千兆宽带上传带宽限制是多少？

不是性能问题，qos 策略和硬件性能没有太大关系

你这个问题在客户端设备上不好解决，路由器的 qos 算法不行。想办法在路由器上启用 qos ，要么换软路由用 fq_codel 或者更先进的 cake https://man7.org/linux/man-pages/man8/tc-cake.8.html

@shawndev 嗯，之前研究 AEAD 的时候还没有这个东西

s/Icebox/Icy Box/g

另外还有一款是 USB 3.1 Gen 2 10Gbps 的，和 YouTube 上有人测评过的 Icebox 应该是同款，我没试过行不行

https://item.jd.com/30803423181.html

我在用铁威马的 D4-300 ，Linux 上可以开启 UAS ，不过四盘同时读速度不超过 300MB/s 。

YottaMaster 那款 PS500U3 五盘位的也买了试过，JMS567 芯片组，Linux 上无法开启 UAS （ JMicron 的大部分 USB-SATA 芯片都在内核的 UAS 黑名单上），只能用 USB Mass Storage 协议，同时读的速度不超过 200MB/s 。

上面第二段「大多数」后面漏了一行字：「大多数场合下甚至不太需要过度考虑 re-key 问题，可以直接用。」

先不考虑任何实现问题，光从理论上 C20P1350 提供 256-bit 安全，AES-128-GCM 只有 128-bit 安全，答案是显而易见的。所以更加公平的比较是 C20P1305 和 AES-256-GCM 。 [AES-192-GCM 过于罕见就先不提了]

具体构造上，C20P1305 留出的安全边际也高得多，大多数，详见 `libsodium` AEAD 的文档： https://libsodium.gitbook.io/doc/secret-key_cryptography/aead#limitations

最后，AES-GCM 的高效、安全实现依赖于 AES 硬件指令，纯软件实现很难同时满足高效和安全。即便是在具备 AES 硬件指令的处理器上，由于操作系统和 API 的限制，很多时候也没法方便的调用专门的 AES 指令，比如 iOS 平台上就存在这个尴尬，需要使用苹果私有 API 才行。

而 C20P1305 没有类似障碍，可以直接在大多数 CPU （无论是否具备 AES 指令集）上高效安全实现，是更加通用的方案。

@rio iOS 也可以用，非常强大易用

Mac 上的话必须是 Soulver https://soulver.app

@acbot 机器数量不多的话，后缀可以静态指定（比如 ::1 ）；数量多的话可以 DHCPv6 。PD 的前缀也需要通过路由器 RA，所以路由器上直接跑 DDNS 也完全可行。

@sephinh 我蠢了，才找到那个开关……

但是 app 里面这种基础操作都不支持也太说不过去了😂

@domosekai 对哦，那就是如果我把内网设备 passthrough 过去这一段 /64 的话，就只能依靠运营商设备的 NDP 来发现我了😂

@domosekai 比如深圳联通 RA 给我的是 2408:8256:3075:BEEF::/64 我从其中随机选一个地址用，那么局端的上级路由表应该是写的啥呢？

@domosekai 我其实在想……RA 给我的那个 /64，应该没有别人了吧？我刚看了个运营商部署 IPv6 的最佳实践，似乎 RA 给 CPE 单独的 /64 是个推荐做法？ https://www.ripe.net/publications/docs/ripe-690

@dreamage 哪里的运营商这么好？😄

@tia 能 PD 还是尽量 PD 吧，NDP 毕竟是个 hack…