SUFT vs 锐速 100MB 传输测试

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 3180 天前的主题，其中的信息可能已经有所发展或是发生改变。

之前已经介绍过 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.

suft

锐速

流量

log

25 条回复 • 2016-03-11 15:54:11 +08:00

Strikeactor

2016-03-10 22:05:04 +08:00

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

spance

2016-03-10 22:13:26 +08:00

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

oplang

2016-03-10 22:19:48 +08:00

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

kozora

2016-03-10 22:27:12 +08:00

支持

spance

2016-03-10 22:27:58 +08:00

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

mhycy

2016-03-10 22:31:42 +08:00

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

tyhunter

2016-03-10 22:32:34 +08:00

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

spance

2016-03-10 22:39:33 +08:00

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

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

Devin

2016-03-10 22:51:15 +08:00 via iPhone

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

spance

2016-03-10 22:56:49 +08:00

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

mhycy

2016-03-10 22:56:58 +08:00

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

Devin

2016-03-10 23:01:37 +08:00 via iPhone

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

spance

2016-03-10 23:02:32 +08:00

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

nbndco

2016-03-10 23:02:43 +08:00 via iPhone

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

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

spance

2016-03-10 23:07:34 +08:00

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

mhycy

2016-03-10 23:10:27 +08:00

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

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