V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
spance
V2EX  ›  宽带症候群

SUFT vs 锐速 100MB 传输测试

  •  
  •   spance · 2016-03-10 21:51:53 +08:00 · 5050 次点击
    这是一个创建于 2970 天前的主题,其中的信息可能已经有所发展或是发生改变。

    之前已经介绍过 suft 一些,在这里 /t/258503

    今天做一个对比测试,服务端 digitalocean sfo 512m 1cpu ,客户端某电信机房服务器。

    现在 sfo 上打开锐速,启动一个 http 流测试服务,在电信机器上 wget 下载 100m 流,客户端 bmon 观察流量,服务端用 ip -s 取流量数据。

    紧接着,启动 suft-nc 测试服务端并输出 100m 文件,在电信机器上启动 suft-nc 客户端接收,客户端 bmon 观察流量,服务端用 ip -s 取流量数据。

    服务端日志:

    server log

    tcp 传输时,接收侧流量图:

    server log

    suft 传输时,接收侧流量图:

    server log

    数据已经给出,我们来分析 2 点:
    1 、 传输速度,依然很明显
    2 、 重发率比较:
    tcp: (4150338202-4034687892)/1024/1024.0 = 110.2919921875 MB
    suft: (4262815617-4150340893)/1024/1024.0 = 107.263671875 MB
    在吞吐优势下,依然相比锐速 节省了 3M 的流量消耗。

    https://github.com/spance/suft

    suft 还在不断完善和继续开发,欢迎有兴趣的同学一起来改进和壮大 suft.

    25 条回复    2016-03-11 15:54:11 +08:00
    Strikeactor
        1
    Strikeactor  
       2016-03-10 22:05:04 +08:00   ❤️ 1
    感觉 3M 流量消耗的优势抵消不了双边加速需要客户端的劣势。。不过还是支持楼主
    spance
        2
    spance  
    OP
       2016-03-10 22:13:26 +08:00
    @Strikeactor 专用协议有特定的场景需要并不是来替代 tcp 的,保存高吞吐还要节省流量外加大延迟+丢包,能取得 3M 流量的节省已属十分不易。有兴趣希望多参与测试和一起改进。
    oplang
        3
    oplang  
       2016-03-10 22:19:48 +08:00
    还没能力 new full request 的持续关注中
    kozora
        4
    kozora  
       2016-03-10 22:27:12 +08:00
    支持
    spance
        5
    spance  
    OP
       2016-03-10 22:27:58 +08:00
    @oplang 多参与测试也是一种改进贡献啊。
    mhycy
        6
    mhycy  
       2016-03-10 22:31:42 +08:00
    一直没想通一件事,既然是丢包不敏感的算法,那么如何保证公平性呢?
    tyhunter
        7
    tyhunter  
       2016-03-10 22:32:34 +08:00
    是和锐速一样单边加速还是需要客户端( Finalspeed 之类的)
    spance
        8
    spance  
    OP
       2016-03-10 22:39:33 +08:00
    @mhycy 指定传输带宽, ARQ 自动平衡发送速度,不会每逢丢包就退让带宽,但也不过度抢占平衡口以外的带宽,相比 tcp 而言公平性要差一些。

    @tyhunter 目前还在协议改进优化期,还未开始投入应用。如果应用,专用协议需要 c/s 两端都支持 suft 。
    Devin
        9
    Devin  
       2016-03-10 22:51:15 +08:00 via iPhone
    还是比较偏爱单边加速,不觉得 net-speeder 有很大改进空间吗?虽然很多人不喜欢双倍发包,但把这作为改进方向不是很好吗?
    spance
        10
    spance  
    OP
       2016-03-10 22:56:49 +08:00
    @Devin 双倍发包,重发率=100%,发送量=200%,实际能享受的有效吞吐大约 50%,也是公平性最差的方法,迅速的塞满各级路由器队列或者被丢掉,还能有比双倍更差的方法么?
    mhycy
        11
    mhycy  
       2016-03-10 22:56:58 +08:00
    @spance
    但是这样的结果就是对链路不敏感。
    新增加一个流会推高丢包率,现在的设计在这会能适应么?
    另外也有个疑问,低速长延时链路在对端计算速率的时候不会遇到问题么?
    Devin
        12
    Devin  
       2016-03-10 23:01:37 +08:00 via iPhone
    @spance 所以要改进发包机制,减少重发包率
    spance
        13
    spance  
    OP
       2016-03-10 23:02:32 +08:00
    @mhycy 设计上延迟和丢包都不会吞吐有很多的影响,而延迟大抖动和丢包率畸变会带来一些影响。
    如果两路或者多路 suft 流都在瞬时并发,可能会出现发送速度突发高峰,这个已经在考虑中,有兴趣的话希望来参与进来。
    nbndco
        14
    nbndco  
       2016-03-10 23:02:43 +08:00 via iPhone
    没看代码,也没找到规范的说明,但是看到 readme ,有两点建议:
    1. tcp 的 sequence number 是循环的,因为 window 的大小不会超过 2^31 ,这样可以传送无限数据
    2. 既然已经放弃了兼容 tcp ,为何还要对数据基于字节做编号?实现难度会显著增加,并且很难做到针对丢失的数据包的重发(只能重发全部),应当针对数据包编号。

    我最近也是想设计一个协议,现有协议都是国际化协议,不适合特色社会主义
    spance
        15
    spance  
    OP
       2016-03-10 23:07:34 +08:00
    @nbndco tcp 使用随机起点和循环编号,而 suft 使用连续编号,从 0 到 u32 最大,而且暂时不准备实现编号循环。
    没有基于字节编号,基于包的编号,并且 suft 的 sack 实现更能有利于实现准确的重传。
    mhycy
        16
    mhycy  
       2016-03-10 23:10:27 +08:00
    @nbndco
    协议本身不是事,问题是在特色主义框架下必须考虑的问题太多

    就例如现在 @spance 的设计,平稳的延迟和丢包可以保证绝对不会有问题,
    但是飘忽变动的延迟、丢包率、包到达顺序,都会有很大的影响。
    如果是多路并发的状态,对于丢包不敏感的算法,将会严重影响链路公平性。
    (考虑到特色国情, RTT 就不可能是一个相对稳定的数字)
    这也是这类算法设计的难点。
    messyidea
        17
    messyidea  
       2016-03-10 23:13:04 +08:00
    希望以后能多一些应用的例子。前几天尝试了一下把曲径那个 qtunnel 的 local 到 remote 的部分换成 suft ,传输好像是可以了,就是不知道怎么传输完后断开,所以一段时间之后会造成 too many filediscrption 。主要是现在不太熟悉 go 的语法( 之后有空再看看
    spance
        18
    spance  
    OP
       2016-03-10 23:18:57 +08:00
    @mhycy 这些问题都是要继续测试改进的或者已经解决的,相比公平性而言吞吐是主要考虑的问题,希望多来测试和改进。

    @messyidea 多多关注,有问题的话多交流。
    mhycy
        19
    mhycy  
       2016-03-10 23:21:38 +08:00
    @spance
    不考虑公平性在现有国情环境下总觉得会被滥用
    就像现在的 net-speeder 和 Finalspeed....

    是个问题。。囧
    以后慢慢改善吧
    yexm0
        20
    yexm0  
       2016-03-10 23:32:25 +08:00
    没办法,运营商对于网络的干预太严重了,电信 163 或者联通要上各种暴力发包的软件才能让网络体验稍微好些,而电信 cn2 或者移动 /铁通就根本不用安装任何软件都能有个非常优秀的网络体验.
    20150517
        21
    20150517  
       2016-03-11 00:01:22 +08:00
    请问你最后两张流量图是怎么显示出来的?是啥软件啊
    sadscv
        22
    sadscv  
       2016-03-11 00:59:55 +08:00
    这个东东和 finalspeed 的区别在哪里啊?小白求教。
    spance
        23
    spance  
    OP
       2016-03-11 10:38:52 +08:00
    @20150517 文章开始就有介绍,服务端 bmon 观察流量。是字体不够大么。。。

    @sadscv 效果相似但不一样,一个是反向代理加速的产品,一个是负责传输流的协议。
    一台发动机装在汽车上可以跑,装在发电机上可以发电,装在起重机上可以吊东西,就是这个意思。
    yjd
        24
    yjd  
       2016-03-11 11:01:56 +08:00
    有没有 win 版本的。最近锐速竟然把免费版关了。没得用了。。说好的免费想关就关。
    better0332
        25
    better0332  
       2016-03-11 15:54:11 +08:00
    某些运营商对 udp QOS
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5384 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 36ms · UTC 09:12 · PVG 17:12 · LAX 02:12 · JFK 05:12
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.