@tool2d
@leido
whois 有频率限制，多查几次 IP 就限速了，DNS 效率更高

每月可能产生数千元 https ，大胆点，每月->每小时

@eason1874 如果是 100%回源，50%下载。会不会出现这样的情况：有些人把每个文件都只下载几个字节就断开连接，然后消耗大量回源资源。

@superrichman 你能精确控制对方的断开时机吗，你开始断的时候对方最后的数据已经在路上了~ 或者 webserver 发送的数据已经进入协议栈缓冲区了，可能最后都没出网络，但也算在流量里了。

@eason1874 协议层的开销应该不算的吧，包重传之类的开销对 web 服务也不可见，例如 nginx 日志里已发送的数据貌似是应用层的

这方案十几年前就普遍使用了

@zhs227 合法的 ACK 值是 8000 或 9000 ，是已发送的 SEQ 中的某一个，而不该是 8700 这个中间值。除非是链路中的设备把原先的包拆分了。

@mikewang cat 一个 MB 级的文件就要等几秒钟，是因为终端要渲染内容，阻塞了管道输出流。纯管道通信是非常快的。
如果直接在 socket 上拦截数据不让渲染，速度应该很快。

@systemcall 可能是你机器负载高的问题，占用了 webshell 进程的资源

@docx 用的人多了肯定会上限制，自己玩玩就可以了

不错，可以用来挖门罗币

@Asmodeus 轻量云 24 一月，一年得几百，而且网络很不稳定

nginx 为什么满足不了？

@gam2046 HTTP 头不过 100 字节，ACK 都有 160KB 了（ 20MB 的文件）

@zhs227 下载速度不敏感的场景可以尝试，比如后台的文件下载任务。如果连接数多，总吞吐反而更高。

@sujin190
@newmlp 目标服务就是 HTTP ，不可控

@laozhoubuluo 其实也不一定。重传再应答，之后对方可能会降低窗口。本来对方一次发 20 个包停止，等我的 ack ，现在可能一次只发 10 个包，就在等我的 ack 。最理想的情况是踩着对方的窗口应答，当然需提前知道对方窗口相关的参数。

小黑子露出鸡脚了吧

@zhuweiyou 几百 KB