也不知道 lz 的意图到底是加速下载还是如同上面某些回答的歪到攻击思路去了。不过无论怎样，提前预测 ACK 序列号于这两者恐怕都没有实际应用价值。
窗口固定，但是一次发送中未确认的也就是一个窗口大小的数据而已，你提前确认了，你预测了确认的 ACK，并确实发送到达了服务器，那服务器开始下一个数据发送，然而你完全无视是否接受继续预测 ACK，此时服务器还不一定发完数据就受到 ACK，那服务器的行为恐怕是忽略，或者直接 RST 了。具体看实现。
按窗口的极限算是 65535 字节也就是 64K。也就是说你基本上能骗服务器发一个 64K，基本上下一个 64K 就很难预测准了。这对于下载加速来说基本达不到目的，可能对于攻击有点作用？不知道 64K 算不算放大攻击了。不过要达成这个攻击自己也要完成三次握手并发送实际请求，至少也要 1K 左右的数据发送吧。

简单搜索了一下连接里的代码，似乎是直接调用.net core 的 UseRequestLocalization()，那在 startup()设置一下应该就好了吧，直接贴.net core 的样例麻烦自己改吧：

var supportedCultures = new[]
{
new CultureInfo("en-US"),
new CultureInfo("fr"),
};

app.UseRequestLocalization(new RequestLocalizationOptions
{
DefaultRequestCulture = new RequestCulture("en-US"),
// Formatting numbers, dates, etc.
SupportedCultures = supportedCultures,
// UI strings that we have localized.
SupportedUICultures = supportedCultures
});

app.UseStaticFiles();
// To configure external authentication,
// see: http://go.microsoft.com/fwlink/?LinkID=532715
app.UseAuthentication();
app.UseMvcWithDefaultRoute();
来自： https://docs.microsoft.com/en-us/aspnet/core/fundamentals/localization?view=aspnetcore-2.2

且不论这个智能组网的路由器如何，新的光猫可以改桥接吗？

没写用什么技术保证干净，叫人不敢有用你的理由啊。
服务器在国内，如何解决上游的污染？
卖点是干净，如何应对 ISP 的污染？