使用 Raw Socket 实现 HTTP 客户端，提前发送 ACK 包可行吗？

[myqoo]

使用 Raw Socket 或 libpcap 自己实现 TCP 协议，下载一个比较大的 HTTP 文件，如果窗口大小固定的话，下一个应答给服务器的 ACK 值是可预测的，我在数据收到之前发出 ACK 包，服务器会接受这个包吗，可不可以加快下一份数据的发送？

[pagxir]

你能保证网络永远不掉包不乱序？否则凭啥说 ACK 可以预测

[rebackhua]

为啥要自己实现 TCP，如果你要自己实现确认机制，那还不如用 UDP

[hjc4869]

如果一个包还没收到你就回了 ack，那万一这个包丢了……

[johnniang]

至少接收方得提供一种让发送放重传的机制。因为并不能保证 ACK 的序号的前面一个窗口一定能够正常到达。

[Juszoe]

我也有这个想法，能否疯狂发 ACK 包达到消耗流量的目的，等大佬解答

[AlexaZhou]

这个攻击思路很有意思，理论上是可行的，Raw Socket 可以直接构建二层包，如果怕 ack 序号不一致，可以一次多发送几个，并不断的根据服务器发过来的包进行修正

[liuminghao233]

可以
这种应该可以更多的消耗服务器流量
但对方只要做一下限速就好了
你这样做只是降低了攻击的成本

[myqoo]

@liuminghao233 单个服务器的话限速还行，但是多个就不一定管用了。我同时刷 CDN 全国各地的服务器节点，这样总流量仍然很大。按照现在 CDN 流量每 GB 几毛钱算的话，估计一晚上就可以刷到对方欠费😂

[est]

万一 ack 之后没收到怎么办。岂不是很尴尬。。

我觉得不如直接协商一个很大的 cwnd。。。这样就避免小包各种密集 ack。。

[1423]

单向数据流场景确实是可行的，有些游戏服务器的预防措施可能就是把所有流量封装在请求必须带响应的小包里面

[liuminghao233]

@myqoo
国内的话可以刷人家流量，但人家也预了这种情况的了
国外的话，谁脑子进水会去搞 cloudflare ？

[jedihy]

不行

1. 你下载一个文件假设 1G 大小，服务器发再快也就是发 1G 数据。有什么区别？
2. 你伪造的 ACK 确认的是还未发送的数据，RFC793 规定是丢弃这个包的。在我所知的所有实现里面都是丢弃这个 ACK。

[jedihy]

就算你伪造的 ACK 在发送窗口里面，服务器也不会多发任何数据。我不明白这有什么意义。

[fatedier]

服务器回给你的包你的机器网卡不需要收吗？还是会占用带宽吧，这样不是起不到攻击的效果吗，除非你有足够高带宽的客户端。

[yankebupt]

如果是由 协商 window 大小 X RTT 公式制作出来的尤其针对远距离通信的限流，这么做确实能提高速度。
但实际上当今已经没有这么原始的限流方式了，要么发送端程序写死了，要么包丢在了中间节点的带宽限制上。
对于包丢了的情况，强行 ack 没收到的包然后重传的话只会让速度更慢……

要说有没有人尝试改进也是有的，有针对较差线路质量改进 tcp 重传调度算法的，也有耍流氓多倍发包拼概率抢带宽的，各取所需好了。

[picone]

那为啥不用 udp

[dawnh]

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

[wcsjtu]

单条 TCP 连接的吞吐量， 最大就是窗口大小 /rtt 了。在网络状态良好的情况下， 现在的 TCP 实现跑不到这个值吗？

[myqoo]

@Juszoe
@AlexaZhou
@liuminghao233
@est
@liuminghao233
@jedihy
@fatedier
@dawnh

搜了下论文发现十多年前就有人想到了。。。https://www.cs.umd.edu/~capveg/optack/optack-extended.pdf