分享刚做的一个块传输加速软件

[zhouheyang0919]

https://github.com/losfair/AlphaTrans
最近做了一个使用 udp+tcp 的块传输加速软件。（一个上午写的，代码自带混淆）
服务端监听在 UDP port 6789 和 TCP port 6789 上， UDP port 接收数据， TCP port 同步控制信息。
客户端连接到服务端后主动推送数据。
实测从 Vultr (New York) 传输 10MB 数据到我电脑上（电信普通宽带， 20M ，非 CN2 ）约需 9s.
丢包重传算法耗费时间较多( 时间随文件拆分的数据包数量增加，高于线性 )，待优化。
服务端用法： ./server_recv 不需要参数，接收到的数据保存在 received.data 中
客户端用法： ./client_send [file_name] [server_ip]
编译直接 make 即可。
欢迎测试和 PR :)

[fcicq]

能证明你的方法和 TCP Reno 相容吗?

[yexm0]

windows 版有不？

[imxieke]

资瓷.

[zhouheyang0919]

@fcicq 数据传输通过 UDP 进行， TCP 连接仅用于状态同步。
传输流程大致是这样的：
发送端与接收端之间建立 TCP 连接和 UDP mapping -> 发送端通过 TCP 发送数据总长度，两端分别计算传输所需的 block 数量 -> 发送端以恒定速率发包 (udp)， 然后传输一定量的带有特殊标志 (0x1fffffff) 的包，以填充丢包造成的数据包数量小于预测数量，期间接收端无任何返回（这一步有待改进） -> 接收端将缺失的 block ID 通过 tcp 传输给发送端，发送端重复上一步过程（但只发送缺失的包），重复这两步直到缺失的 block 数量为 0 -> Done

[fcicq]

@zhouheyang0919 没有减速逻辑的话必然不相容了.

[ryd994]

讲真，除非有明确的拥塞控制的数学模型，所谓的加速绝大多数都是无脑发包
你们知道要是写出新拥塞算法可以发 CS 论文么？

[luohaha]

研究生想做 tcp 加速方面的研究，被导师说太 low 了，好久之前的研究方向了。。

[vinsoncou]

这个与 TsunamiUDP 相比有什么优势呢？

[mengzhuo]

呃…不能做流控岂不就是无脑发

[fzinfz]

看用法貌似目前只支持文件加速。 LZ 有兴趣发展成支持 proxy 的版本么？
JAVA 版参考: https://github.com/d1sm/finalspeed/tree/fileshare

[zhouheyang0919]

@fcicq
@ryd994
@mengzhuo
正在写拥塞控制算法

[zhouheyang0919]

@fzinfz 处理流加速比块加速更复杂。不过有这个打算

[bkjzs]

可以看看 kcp

[zhouheyang0919]

@bkjzs kcp 是为双向的流传输设计的，在单向大容量传输上表现并不突出

[zhouheyang0919]

@bkjzs 峰值速率很高，但在延时较大的网络下速率不稳定

[bkjzs]

@zhouheyang0919 我自己用西雅图的服务器测试 kcp ，多线程传输大文件，可以稳定在 3mb/s ，显示使用了 50M 的带宽。
用这种软件比不用好太多，直接传输可能只有 200kb/s

[Actrace]

使用 TCP 进行状态同步的话， TCP 丢包影响很大吧？

[zhouheyang0919]

@Actrace TCP 传输的流量不到总流量的 1/500. 因此影响很小。

[Thiece]

有最新进展吗？