SUFT vs 锐速 100MB 传输测试

[spance]

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

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

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

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

服务端日志：

tcp 传输时，接收侧流量图：

suft 传输时，接收侧流量图：

数据已经给出，我们来分析 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.

[Strikeactor]

感觉 3M 流量消耗的优势抵消不了双边加速需要客户端的劣势。。不过还是支持楼主

[spance]

@Strikeactor 专用协议有特定的场景需要并不是来替代 tcp 的，保存高吞吐还要节省流量外加大延迟+丢包，能取得 3M 流量的节省已属十分不易。有兴趣希望多参与测试和一起改进。

[oplang]

还没能力 new full request 的持续关注中

[kozora]

支持

[spance]

@oplang 多参与测试也是一种改进贡献啊。

[mhycy]

一直没想通一件事，既然是丢包不敏感的算法，那么如何保证公平性呢？

[tyhunter]

是和锐速一样单边加速还是需要客户端（ Finalspeed 之类的）

[spance]

@mhycy 指定传输带宽， ARQ 自动平衡发送速度，不会每逢丢包就退让带宽，但也不过度抢占平衡口以外的带宽，相比 tcp 而言公平性要差一些。

@tyhunter 目前还在协议改进优化期，还未开始投入应用。如果应用，专用协议需要 c/s 两端都支持 suft 。

[Devin]

还是比较偏爱单边加速，不觉得 net-speeder 有很大改进空间吗？虽然很多人不喜欢双倍发包，但把这作为改进方向不是很好吗？

[spance]

@Devin 双倍发包，重发率=100%，发送量=200%，实际能享受的有效吞吐大约 50%，也是公平性最差的方法，迅速的塞满各级路由器队列或者被丢掉，还能有比双倍更差的方法么？

[mhycy]

@spance
但是这样的结果就是对链路不敏感。
新增加一个流会推高丢包率，现在的设计在这会能适应么？
另外也有个疑问，低速长延时链路在对端计算速率的时候不会遇到问题么？

[Devin]

@spance 所以要改进发包机制，减少重发包率

[spance]

@mhycy 设计上延迟和丢包都不会吞吐有很多的影响，而延迟大抖动和丢包率畸变会带来一些影响。
如果两路或者多路 suft 流都在瞬时并发，可能会出现发送速度突发高峰，这个已经在考虑中，有兴趣的话希望来参与进来。

[nbndco]

没看代码，也没找到规范的说明，但是看到 readme ，有两点建议：
1. tcp 的 sequence number 是循环的，因为 window 的大小不会超过 2^31 ，这样可以传送无限数据
2. 既然已经放弃了兼容 tcp ，为何还要对数据基于字节做编号？实现难度会显著增加，并且很难做到针对丢失的数据包的重发（只能重发全部），应当针对数据包编号。

我最近也是想设计一个协议，现有协议都是国际化协议，不适合特色社会主义

[spance]

@nbndco tcp 使用随机起点和循环编号，而 suft 使用连续编号，从 0 到 u32 最大，而且暂时不准备实现编号循环。
没有基于字节编号，基于包的编号，并且 suft 的 sack 实现更能有利于实现准确的重传。

[mhycy]

@nbndco
协议本身不是事，问题是在特色主义框架下必须考虑的问题太多

就例如现在 @spance 的设计，平稳的延迟和丢包可以保证绝对不会有问题，
但是飘忽变动的延迟、丢包率、包到达顺序，都会有很大的影响。
如果是多路并发的状态，对于丢包不敏感的算法，将会严重影响链路公平性。
（考虑到特色国情， RTT 就不可能是一个相对稳定的数字）
这也是这类算法设计的难点。

[messyidea]

希望以后能多一些应用的例子。前几天尝试了一下把曲径那个 qtunnel 的 local 到 remote 的部分换成 suft ，传输好像是可以了，就是不知道怎么传输完后断开，所以一段时间之后会造成 too many filediscrption 。主要是现在不太熟悉 go 的语法（ 之后有空再看看

[spance]

@mhycy 这些问题都是要继续测试改进的或者已经解决的，相比公平性而言吞吐是主要考虑的问题，希望多来测试和改进。

@messyidea 多多关注，有问题的话多交流。

[mhycy]

@spance
不考虑公平性在现有国情环境下总觉得会被滥用
就像现在的 net-speeder 和 Finalspeed....

是个问题。。囧
以后慢慢改善吧

[yexm0]

没办法,运营商对于网络的干预太严重了,电信 163 或者联通要上各种暴力发包的软件才能让网络体验稍微好些,而电信 cn2 或者移动 /铁通就根本不用安装任何软件都能有个非常优秀的网络体验.