我给 opnsense 仓库提交了 issue ，接下来就看他们会不会处理
https://github.com/opnsense/core/issues/5847

忘了说，还有编写网络安全软件的，也会用到 C++（当然了，需要懂的还不止 C++）。这样一来，单单理解各种异步网络库绝对不够。就比如专门针对某某 CVE 漏洞报告制作出扫描软件或测试软件，需要的基础知识远超“异步网络库”。

研究下 Kali Linux 各种内置工具就很好地理解我在说什么了。

网络设施方向的前景啊……
跟互联网行业相比的话，它有 1 个特点：稳定。也许还有“低”薪。(注意我加了双引号）

网络设备在目前这个时代已经成了基础设施，需求量相对稳定，人员需求也相对稳定，大变化大需求当然也会有（比如未来推行 6G 、7G ，或者有人发展出了新的路由协议），但远不如互联网龙头行业来得频繁、变动那么大。

同样的还有网络安全，它一直都不可或缺，并且越来越重要。但有一个缺点，这个方向属于“运维”这一块，部分公司要求 7×24 轮班，换句话说，会有通宵夜班。虽然没有什么 996 、007 ，但通宵夜班肯定跑不掉的。

网络通信、网络编程的范围非常大，除了前面大家都提到的，其实还有 OSI 第一层和第二层的部分。

例如网卡驱动，不但牵涉到 OSI 第一层和第二层，还涉及系统内核编程（不管是 Windows 还是 Linux 或 BSD ，写驱动都要跟内核打交道，绕不开的）。这可不是简单的事情。

还有 VPN 软件，需要熟悉 OSI 第二层和第三层，因为很大可能需要手动处理 IP 路由分派部分，以及对二层⟷三层的解包 /打包。而 IP 协议还分为 IPv4 和 IPv6 ，相关知识点并不会少。

既然都提到 IP 路由了，那么还可以提一提各种路由协议。假如以后会进入到网络设备公司干编程的活，那就很有可能需要维护各种路由协议相关的源码，这种情况下路由协议必定需要学，就算不精，也得“知道这个协议是干什么、怎么用的”。
说起网络设备，那就很大可能需要再学一学 SCTP 。目前有部分较新的路由器（不是指“网关”的那种）、基站不但已经支持 SCTP ，而且还依赖 SCTP 来传输数据（主要是信令）。了解 TCP 和 UDP 的人多得是，但了解 SCTP 的相对较少。万一需要维护 SCTP 相关的源码，那就必须先把 SCTP 搞明白。

@vvzero V2EX 自身就有不少境内 UDP 限速的讨论贴。

例如这个： https://www.v2ex.com/t/819841
有两个现成的案例，第一个是佛山电信到广州移动专线，有丢包。
另一个是从北京联通向深圳的朋友转发数据，每 30 秒闪断一次。

还有一个： https://www.v2ex.com/t/843860
同城的移动和联通用 UDP 组网，丢包率严重。

说到打游戏都卡，还真的有现成的例子，玩游戏 UDP 丢包：
https://www.txrjy.com/thread-1208022-1-1.html

@Laitinlok 我的宽带是双栈双公网，无论是 IPv4 还是 IPv6 ，这种 UDP 丢包都同时存在。IPv4 的 UDP 正在丢包，同时去测 IPv6 的话，会发现有一样的情况。

可以先 traceroute 看看路由节点，也许是流量穿透的出口不同，而刚好这两个穿透出口的带宽差异很大。

甚至不排除专门跟 IDC 、云厂有合作（我没用过天威，这是单纯的猜测，很有可能会猜错）。

@gfwuzer
@yulon
广东电信家宽，也有同样的现象。

开着 BT 软件，同时启用了 TCP 和 UDP (uTP)，下载／上传着热门 BT 种子。此时的国内连接，无论是 TCP 还是 UDP ，都很顺畅。然而国际连接就出了问题，UDP 丢包率极高，基本上也是 3 分钟内 UDP 全丢，接着恢复十几秒，然后又继续丢包。同一时间，国际方向的 TCP 倒是不怎么受影响，丢包率没什么变化。

可以确定这跟是否占满带宽无关，即使我在 BT 软件内设了限速，上传和下载都只是半满，上述的丢包依旧存在。

如果你用过 wireguard 和 OpenVPN 之类的虚拟网卡 VPN ，并且在这些 VPN 连接完成后看过路由表，就会发现他们的做法跟你的一样，专门针对远程服务器 IP 单独设一条路由，走原先的路径。断开连接后，再恢复回去。
每切换一次远程节点，都要更新一次路由表。

所以，既然选择了虚拟网卡的方式，那么更新路由表并没什么不妥。

要不试试双显示器

1L 的办法很稳、可靠，我也是那样的布局方式

4K + DPI 200%，效果：
https://telegra.ph/Windows-10%E4%BB%BB%E5%8A%A1%E6%A0%8FQuick-Launch-06-17

小图标模式会继续使用 1080p 版本的大小，大图标模式可解，无文字+大图标可以完美对齐。

用高校的镜像站，速度快很多。
特别是清华大学，几乎是最快的

那就用以前梯子那套玩法，kcptun --mod fast3 --tcp ，即暴力发包 + TCP 欺骗

这排版看得有点绕……

重新整理了下：

1 、PC1-2.5G 交换机-爱快-光猫 890M
2 、PC1-2.5G 交换机-openwrt 网关-爱快-光猫 890M
3 、PC1-2.5G 交换机-openwrt iperf3 测试 上下行单线程都跑满 2.37G
4 、PC1-光猫直拨 890M
5 、PC1-K2P-光猫 890M
6 、PC1-2.5G 交换机-PC2 iperf3 940M
7 、替换成千兆交换机结果差不多
8 、PC2 重复上面测试结果与 PC1 差不多
9 、一加 9PRO-XDR5480-2.5G 交换机-爱快-光猫，940+m
10 、一加 9PRO-XDR5480-2.5G 交换机-openwrt 网关-爱快-光猫，940+m
11 、一加 9PRO-XDR5480-2.5G 交换机-openwrt iperf3 1.6G
12 、一加 9PRO-XDR5480-2.5G 交换机-PC1 1.6G


看起来是以太帧大小的原因。PC1 和 PC2 试下开启巨型帧(Jumbo Frame)，速度应该可以再多几十 M 。
从测速结果来看，中间的路由器和光猫应该已经默认开启了巨型帧，但 PC 没启用。
标准帧 1.5KB ，巨型帧 9KB ，标准帧的“损耗”相对会多一点。

具体的效率可以看这里： https://shorturl.at/kyCP3
里面说标准帧效率 94.93%，巨型帧效率 99.14%
所以从表面上来看，似乎是以太帧大小的原因

造成无法访问的原因是双重 NAT ，换句话说，是因为双重内网。

所以解决办法也很简单，在 pfsense 那里打开端口映射，把 NAS 映射到某个端口上，然后 VPN 回家时访问 NAS 就使用映射的端口。按照你的情况，那就是连回家后访问 192.168.1.x:port 。x 是 pfsense 在 RouterOS 侧获得的 IP 地址，port 是映射后的端口。

还有另一个解决办法，那就是扔掉 RouterOS 这个节点。pfsense 本身就可以拨号，也能开启 wireguard ，让 pfsense 全盘接管就行了。

@sunnysab 服务器端默认支持 http/3 的有 LiteSpeed （ 2021 年开始支持）和最新版 IIS （自 Windows Server 2022 起），Cloudflare 也提供了 http3 支持，再加上 Google 自己就在用，覆盖范围不小。
小提示：不少虚拟主机商（托管网站的那种，不是指 VPS ）默认 Web 服务程序用的是 LiteSpeed 而不是 nginx 。

现在的 Firefox 是支持 HTTP3 的，已经默认开启，至少 Windows 版本是这样。

我见过还有这样的：Dev / UAT / Pre-Prod / Prod

@cnbatch Vultr 自己说是 outbound ports 屏蔽，但实测下来表现为双向，估计他们的做法是，这几个端口的出站包全都一律丢掉，于是无论主动发起还是被动连接，这条连接都无法建立起来。