我也没什么专业知识来分析这个问题，只好给你一些宽泛的建议（我用的 Archlinux ，下面以 ArchWiki 为主）：

1. 这里给出了一些硬件视频加速的 tips ，可以看下自己机器的硬件加速是否正确 https://wiki.archlinux.org/title/Hardware_video_acceleration
2. 考虑用 mpv ，并且在开启 / 关闭 硬件加速的情况下测试 https://wiki.archlinux.org/title/Mpv
3. 考虑制作一个 Windows-To-Go USB （虽然官方应该是不支持了但是 Rufus 还可以，可以通过 Windows 虚拟机直通 U 盘的玩法搞一个 WTG https://rufus.ie/en/ ）然后在 Windows 下测试一遍

按照我的理解，Tailscale 等工具会全面接管网络，每个网络包都会过 Tailscale 的 Network Extension ，所以不存在“全程不使用”的情况。
个人认为这种工具耗电是可以接受的；有一个问题是 iOS / Android 上同类工具不能同时开

sudo -- sh -c "echo 1 > /proc/sys/vm/drop_caches && echo 1 > /proc/sys/vm/compact_memory"

Memory Reclaim in the Windows Subsystem for Linux 2
https://devblogs.microsoft.com/commandline/memory-reclaim-in-the-windows-subsystem-for-linux-2/

@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 的解决办法可以参考这个视频 （封面貌似就是软件架构图）

https://youtu.be/EosEZqf9IA8?t=199

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

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

熊猫吃短信 +1

山西人不在山西

先搭建 本机 - A 的隧道（ SSH / VPN 均可）
再通过隧道连接其他机器

@hxy100 如 @lostberryzz 所说，中国区 cdn 需要备案+Enterprise Plan，由于不可描述的网站一般无法备案，所以不会用到中国区 cdn

@lsylsy2 20 年 4 月宣布和京东云合作 https://blog.cloudflare.com/cloudflare-partners-with-jd-cloud/

这次升级的应该不是递归 DNS，而是权威 dns - 开通中国业务的客户会有中国区 dns + cdn 支持，降低延迟

ssr (server side render): （个人理解）狭义的 SSR 指可以做客户端渲染的 js 框架部署在服务端做预渲染；广义上也可以指传统的服务端模板引擎+填充数据形式生成最终页面

@tctc4869 动态页面我理解是 服务端直接生成最终网页；页面之间的跳转通过网页跳转实现。

这种情况下 js & css 这类文件最好还是放在 Nginx 或者 CDN 上。页面服务器 通常用模板引擎+直接填充内容的方式搭建。

仔细看了下你的问题，我认为你可以考虑 ASP.NET core 作为服务端，加上 Vue / React / jQuery 等做客户端框架。（据个人浅薄的知识）服务端用 Node.js 可能需要和浏览器 js 不一样的玩法

也有服务器渲染 + 客户端渲染的玩法，这种情况下服务端负责首次加载时的渲染，后续内容交给客户端完成、服务端仅提供 API

（以下是个人一点外行角度的看法）

前后端分离，我理解为客户端渲染，服务端只提供静态页面 + API 。这种情况下静态页面用什么都可以，API 部分当然要用支持动态返回的服务器。

请求量较小时静态页面可以直接用 API 服务器提供，量较大时推荐用 Nginx 等静态服务器返回本地文件；请求量更大的情况下静态文件通常都缓存在 CDN 上。