money1991

@OrionRies 搞个生词本吧，一个页面标出那么多生词，我想把觉得重要的单词以及当前的句子上下文都给我加到生词本里，我有空了再单独加强复习下，这样就更好了

有用

开启 bbr 试试，也许有奇效。对于高延迟、高丢包的网络环境能大大优化 tcp 的传输稳定性和速率。缺点是流量会略多消耗一点。

设置 u 盘启动就行。移动硬盘没插，系统会自动选择其他的

@sodulty 没搞 ov ，我用的是 http 代理，只对有必要的应用才走代理，嫌弃 ov 全局流量，太重了。

你可以试试 scp 或者 http 等服务能否跑满，能跑满说明是 ov 问题，去排查 ov 。否则还是 bbr 没生效。

你的 ov 是 tcp 协议吧，udp 跑不满那没啥好办法，运营商好像对 udp 有限制

bbr 工作在 tcp 协议栈，爱快做内网到公网的端口映射时，只是简单的 nat 转发，不参与 tcp 协议栈相关参数协商控制，bbr 应该是无法发挥作用的。结论：爱快开了 bbr 只能对爱快自身的一些服务起作用，对只做端口映射的那种服务没用，up 看看你的 ov 是不是部署在爱快里。

这就是典型的多线程多连接能跑满，单线程单连接跑不满。
你 ov 客户端到服务器相当于单线程单连接跑不满很正常。即使客户端 iperf 多线程模式，但底层的 ov 到服务器还是单连接，在客户端侧也肯定无法跑满。
解决办法就是出口服务器上一下 bbr 。家里有没有 Linux 设备？开一下 bbr ，然后 nginx 弄个反向代理，把 ov 以及其他服务的出口都从这台开了 bbr 的设备端口映射到公网。
我之前搞的 nas 也遇到这个问题，发现所有设备只要过了 bbr ，单线程就可以跑满了，非常爽。