使用 Raw Socket 或 libpcap 自己实现 TCP 协议，下载一个比较大的 HTTP 文件，如果窗口大小固定的话，下一个应答给服务器的 ACK 值是可预测的，我在数据收到之前发出 ACK 包，服务器会接受这个包吗，可不可以加快下一份数据的发送？
请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 2410 days ago, the information mentioned may be changed or developed.
Supplement 1 Oct 6, 2019
数据包能不能完整收到并不在意。。。刚刚想到一种能消耗服务器上行流量的攻击方式。
之前听说有攻击者仅仅使用家庭带宽（估计大几百 M ）不断访问 CDN 大文件，导致流量欠费。不过这种方式只能 1:1 的耗流量。
在想假如客户端能提前发送 ACK 应答包，让服务器觉得延时低从而加快发送。而客户端这边，只要上行和下行带宽是隔离的，就算下行被挤满也不影响上行 ACK 发送。如果思路没问题的话，应该可以远超 1:1 的消耗吧
之前听说有攻击者仅仅使用家庭带宽（估计大几百 M ）不断访问 CDN 大文件，导致流量欠费。不过这种方式只能 1:1 的耗流量。
在想假如客户端能提前发送 ACK 应答包，让服务器觉得延时低从而加快发送。而客户端这边，只要上行和下行带宽是隔离的，就算下行被挤满也不影响上行 ACK 发送。如果思路没问题的话，应该可以远超 1:1 的消耗吧
Supplement 2 Oct 8, 2019
思路可行~ 已成功试验。
 | 1 pagxir Oct 6, 2019 via Android 你能保证网络永远不掉包不乱序？否则凭啥说 ACK 可以预测 |
 | 2 rebackhua Oct 6, 2019 为啥要自己实现 TCP，如果你要自己实现确认机制，那还不如用 UDP |
 | 3 hjc4869 Oct 6, 2019 via Android 如果一个包还没收到你就回了 ack，那万一这个包丢了…… |
 | 4 johnniang Oct 6, 2019 via Android 至少接收方得提供一种让发送放重传的机制。因为并不能保证 ACK 的序号的前面一个窗口一定能够正常到达。 |
 | 5 Juszoe Oct 6, 2019 我也有这个想法，能否疯狂发 ACK 包达到消耗流量的目的，等大佬解答 |
 | 6 AlexaZhou Oct 6, 2019 这个攻击思路很有意思，理论上是可行的，Raw Socket 可以直接构建二层包，如果怕 ack 序号不一致，可以一次多发送几个，并不断的根据服务器发过来的包进行修正 |
 | 7 liuminghao233 Oct 6, 2019 via iPhone 可以 这种应该可以更多的消耗服务器流量 但对方只要做一下限速就好了 你这样做只是降低了攻击的成本 |
 | 8 myqoo OP @liuminghao233 单个服务器的话限速还行，但是多个就不一定管用了。我同时刷 CDN 全国各地的服务器节点，这样总流量仍然很大。按照现在 CDN 流量每 GB 几毛钱算的话，估计一晚上就可以刷到对方欠费 |
 | 9 est Oct 6, 2019 万一 ack 之后没收到怎么办。岂不是很尴尬。。 我觉得不如直接协商一个很大的 cwnd。。。这样就避免小包各种密集 ack。。 |
 | 10 slowman Oct 6, 2019 via Android 单向数据流场景确实是可行的，有些游戏服务器的预防措施可能就是把所有流量封装在请求必须带响应的小包里面 |
| 11 liuminghao233 Oct 7, 2019 via iPhone |
 | 12 jedihy Oct 7, 2019 via iPhone 不行 1. 你下载一个文件假设 1G 大小，服务器发再快也就是发 1G 数据。有什么区别？ 2. 你伪造的 ACK 确认的是还未发送的数据，RFC793 规定是丢弃这个包的。在我所知的所有实现里面都是丢弃这个 ACK。 |
| 13 jedihy Oct 7, 2019 via iPhone 就算你伪造的 ACK 在发送窗口里面，服务器也不会多发任何数据。我不明白这有什么意义。 |
 | 14 fatedier Oct 7, 2019 服务器回给你的包你的机器网卡不需要收吗？还是会占用带宽吧，这样不是起不到攻击的效果吗，除非你有足够高带宽的客户端。 |
 | 15 yankebupt Oct 7, 2019 如果是由 协商 window 大小 X RTT 公式制作出来的尤其针对远距离通信的限流，这么做确实能提高速度。 但实际上当今已经没有这么原始的限流方式了，要么发送端程序写死了，要么包丢在了中间节点的带宽限制上。 对于包丢了的情况，强行 ack 没收到的包然后重传的话只会让速度更慢…… 要说有没有人尝试改进也是有的，有针对较差线路质量改进 tcp 重传调度算法的，也有耍流氓多倍发包拼概率抢带宽的，各取所需好了。 |
 | 16 picone Oct 7, 2019 那为啥不用 udp |
 | 17 dawnh Oct 8, 2019 也不知道 lz 的意图到底是加速下载还是如同上面某些回答的歪到攻击思路去了。不过无论怎样，提前预测 ACK 序列号于这两者恐怕都没有实际应用价值。 窗口固定，但是一次发送中未确认的也就是一个窗口大小的数据而已，你提前确认了，你预测了确认的 ACK，并确实发送到达了服务器，那服务器开始下一个数据发送，然而你完全无视是否接受继续预测 ACK，此时服务器还不一定发完数据就受到 ACK，那服务器的行为恐怕是忽略，或者直接 RST 了。具体看实现。 按窗口的极限算是 65535 字节也就是 64K。也就是说你基本上能骗服务器发一个 64K，基本上下一个 64K 就很难预测准了。这对于下载加速来说基本达不到目的，可能对于攻击有点作用？不知道 64K 算不算放大攻击了。不过要达成这个攻击自己也要完成三次握手并发送实际请求，至少也要 1K 左右的数据发送吧。 |
 | 18 wcsjtu Oct 8, 2019 单条 TCP 连接的吞吐量， 最大就是窗口大小 /rtt 了。在网络状态良好的情况下， 现在的 TCP 实现跑不到这个值吗？ |
| 19 myqoo OP @Juszoe @AlexaZhou @liuminghao233 @est @liuminghao233 @jedihy @fatedier @dawnh 搜了下论文发现十多年前就有人想到了。。。https://www.cs.umd.edu/~capveg/optack/optack-extended.pdf |
Select Language