zwy100e72

@bmpidev2019 没关系，交流也是提升的一部分，您已经比我做的更好了，因为你写了这样的总结

看了你的总结，我也对泛型这个玩法有了更清晰的认识，这要感谢您

如果您希望在公开宣传之前减少瑕疵的话，可以先找身边的同行帮忙审校一下（英语中应该对应是 proof-reading ）

我认为 Generic Programming 应该翻译为 “泛型”，而不是“范型”。Generic programming 是对具有相同性质的数据做通用的处理，其面向的数据类型是“宽泛”的，因此称为“泛型”是更合适的。

可以从几个方向排查

1. DNS： 楼主这 1s 时间中有包含 DNS 查询时间吗？如果有的话，通过 dig 命令确认 DNS 响应时间是不是过大，如果 DNS 延迟较高，可通过更换其他 DNS 或者本地 DNS 缓存的方式来降低 DNS 的影响

2. 连接时的开销：请求 alipay.com 时会涉及到 TCP 连接、301 跳转、TCP 重连、TLS 协商等流程，可通过抓包分析是否这个阶段开销过高，通过优化连接时参数来降低影响；也可以通过连接复用降低影响

3. 楼主的目标：楼主需要明确需求，是“单次连接时长小于 N ms”，还是 “多次连接，p50 / p90 / p99 延迟指标小于 N ms”。

4. 程序本身的开销：如果连接时 CPU 占用过高，可以用相关 profiler 工具分析热点，尝试通过更换效率更高的框架来降低开销

最后，当你在讨论 “1s” 这个指标时，有可能不是带宽瓶颈。如果带宽不是瓶颈，那么再增加带宽也是无法加速连接的。

@acbot 不经过 GFW 的话有特征也没问题吧？貌似这种情况没人管

如果使用 Tailscale 的 DERP 服务器的话可能不符合相关法律要求（两端都在中国境内的话流量不允许经过国外），可以通过自建 DERP 并关闭官方 DERP 实现；貌似也没人管

我认为有中间商的问题可以通过部署 HeadScale 来规避，或者自己组件 Wireguard 网络；只是方便程度逐渐下降了

Steam 的解决办法可以参考这个视频 （封面貌似就是软件架构图）

?t=199

我之前遇到了一样的问题，我最后的选择是直接交给 Tailscale ；

Wireguard 不通的问题，我猜你 ping 等小流量的应用是通的，传输大包的时候就不通了；现在我想应该是 MTU 的问题，Wireguard 的 MTU 要减掉 PPPoE 消息头等开销，或者学 Tailscale 用 1280 Byte 以保证绝大多数情况都可以通过

熊猫吃短信 +1

山西人不在山西