V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
myqoo
V2EX  ›  程序员

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

  •  
  •   myqoo · 2019-10-06 15:52:06 +08:00 · 4105 次点击
    这是一个创建于 1635 天前的主题,其中的信息可能已经有所发展或是发生改变。
    使用 Raw Socket 或 libpcap 自己实现 TCP 协议,下载一个比较大的 HTTP 文件,如果窗口大小固定的话,下一个应答给服务器的 ACK 值是可预测的,我在数据收到之前发出 ACK 包,服务器会接受这个包吗,可不可以加快下一份数据的发送?
    第 1 条附言  ·  2019-10-06 17:47:36 +08:00
    数据包能不能完整收到并不在意。。。刚刚想到一种能消耗服务器上行流量的攻击方式。

    之前听说有攻击者仅仅使用家庭带宽(估计大几百 M )不断访问 CDN 大文件,导致流量欠费。不过这种方式只能 1:1 的耗流量。

    在想假如客户端能提前发送 ACK 应答包,让服务器觉得延时很低从而加快发送。而客户端这边,只要上行和下行带宽是隔离的,就算下行被挤满也不影响上行 ACK 发送。如果思路没问题的话,应该可以远超 1:1 的消耗吧
    第 2 条附言  ·  2019-10-08 15:36:52 +08:00
    思路可行~ 已成功试验。
    19 条回复    2019-10-09 16:48:10 +08:00
    pagxir
        1
    pagxir  
       2019-10-06 16:18:32 +08:00 via Android
    你能保证网络永远不掉包不乱序?否则凭啥说 ACK 可以预测
    rebackhua
        2
    rebackhua  
       2019-10-06 17:22:48 +08:00
    为啥要自己实现 TCP,如果你要自己实现确认机制,那还不如用 UDP
    hjc4869
        3
    hjc4869  
       2019-10-06 17:34:57 +08:00 via Android
    如果一个包还没收到你就回了 ack,那万一这个包丢了……
    johnniang
        4
    johnniang  
       2019-10-06 17:51:39 +08:00 via Android
    至少接收方得提供一种让发送放重传的机制。因为并不能保证 ACK 的序号的前面一个窗口一定能够正常到达。
    Juszoe
        5
    Juszoe  
       2019-10-06 19:35:53 +08:00
    我也有这个想法,能否疯狂发 ACK 包达到消耗流量的目的,等大佬解答
    AlexaZhou
        6
    AlexaZhou  
       2019-10-06 19:35:59 +08:00
    这个攻击思路很有意思,理论上是可行的,Raw Socket 可以直接构建二层包,如果怕 ack 序号不一致,可以一次多发送几个,并不断的根据服务器发过来的包进行修正
    liuminghao233
        7
    liuminghao233  
       2019-10-06 19:53:38 +08:00 via iPhone
    可以
    这种应该可以更多的消耗服务器流量
    但对方只要做一下限速就好了
    你这样做只是降低了攻击的成本
    myqoo
        8
    myqoo  
    OP
       2019-10-06 20:29:25 +08:00
    @liuminghao233 单个服务器的话限速还行,但是多个就不一定管用了。我同时刷 CDN 全国各地的服务器节点,这样总流量仍然很大。按照现在 CDN 流量每 GB 几毛钱算的话,估计一晚上就可以刷到对方欠费😂
    est
        9
    est  
       2019-10-06 20:47:36 +08:00
    万一 ack 之后没收到怎么办。岂不是很尴尬。。

    我觉得不如直接协商一个很大的 cwnd。。。这样就避免小包各种密集 ack。。
    1423
        10
    1423  
       2019-10-06 22:50:45 +08:00 via Android
    单向数据流场景确实是可行的,有些游戏服务器的预防措施可能就是把所有流量封装在请求必须带响应的小包里面
    liuminghao233
        11
    liuminghao233  
       2019-10-07 07:47:33 +08:00 via iPhone
    @myqoo
    国内的话可以刷人家流量,但人家也预了这种情况的了
    国外的话,谁脑子进水会去搞 cloudflare ?
    jedihy
        12
    jedihy  
       2019-10-07 10:48:47 +08:00 via iPhone
    不行

    1. 你下载一个文件假设 1G 大小,服务器发再快也就是发 1G 数据。有什么区别?
    2. 你伪造的 ACK 确认的是还未发送的数据,RFC793 规定是丢弃这个包的。在我所知的所有实现里面都是丢弃这个 ACK。
    jedihy
        13
    jedihy  
       2019-10-07 10:52:56 +08:00 via iPhone
    就算你伪造的 ACK 在发送窗口里面,服务器也不会多发任何数据。我不明白这有什么意义。
    fatedier
        14
    fatedier  
       2019-10-07 14:22:01 +08:00
    服务器回给你的包你的机器网卡不需要收吗?还是会占用带宽吧,这样不是起不到攻击的效果吗,除非你有足够高带宽的客户端。
    yankebupt
        15
    yankebupt  
       2019-10-07 17:26:19 +08:00
    如果是由 协商 window 大小 X RTT 公式制作出来的尤其针对远距离通信的限流,这么做确实能提高速度。
    但实际上当今已经没有这么原始的限流方式了,要么发送端程序写死了,要么包丢在了中间节点的带宽限制上。
    对于包丢了的情况,强行 ack 没收到的包然后重传的话只会让速度更慢……

    要说有没有人尝试改进也是有的,有针对较差线路质量改进 tcp 重传调度算法的,也有耍流氓多倍发包拼概率抢带宽的,各取所需好了。
    picone
        16
    picone  
       2019-10-07 23:24:41 +08:00
    那为啥不用 udp
    dawnh
        17
    dawnh  
       2019-10-08 11:00:39 +08:00
    也不知道 lz 的意图到底是加速下载还是如同上面某些回答的歪到攻击思路去了。不过无论怎样,提前预测 ACK 序列号于这两者恐怕都没有实际应用价值。
    窗口固定,但是一次发送中未确认的也就是一个窗口大小的数据而已,你提前确认了,你预测了确认的 ACK,并确实发送到达了服务器,那服务器开始下一个数据发送,然而你完全无视是否接受继续预测 ACK,此时服务器还不一定发完数据就受到 ACK,那服务器的行为恐怕是忽略,或者直接 RST 了。具体看实现。
    按窗口的极限算是 65535 字节也就是 64K。也就是说你基本上能骗服务器发一个 64K,基本上下一个 64K 就很难预测准了。这对于下载加速来说基本达不到目的,可能对于攻击有点作用?不知道 64K 算不算放大攻击了。不过要达成这个攻击自己也要完成三次握手并发送实际请求,至少也要 1K 左右的数据发送吧。
    wcsjtu
        18
    wcsjtu  
       2019-10-08 13:34:51 +08:00
    单条 TCP 连接的吞吐量, 最大就是窗口大小 /rtt 了。在网络状态良好的情况下, 现在的 TCP 实现跑不到这个值吗?
    myqoo
        19
    myqoo  
    OP
       2019-10-09 16:48:10 +08:00
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   956 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 21:47 · PVG 05:47 · LAX 14:47 · JFK 17:47
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.