这是一个创建于 3060 天前的主题，其中的信息可能已经有所发展或是发生改变。
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 :)
最近做了一个使用 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 :)
第 1 条附言 · 2016-07-02 19:32:51 +08:00
现在加入了简单的拥塞控制。
数据分块传输，提升大文件的传输速度。
命令行参数格式调整为：
服务端： ./server_recv > [output_file_name]
客户端： ./client_send [server_ip] < [input_file_name]
便于与其他程序进行集成。
目前的问题：
1. 貌似墙学习了 UDP 流量的特征。。含 Flag 的包 200 个只能到达几个。可能需要添加混淆。
2. 分块传输离流传输更近了一步，但是尚未实现真正的流传输，需要发送端填满一个 block 或者读完输入，接收端才有输出。
数据分块传输，提升大文件的传输速度。
命令行参数格式调整为：
服务端： ./server_recv > [output_file_name]
客户端： ./client_send [server_ip] < [input_file_name]
便于与其他程序进行集成。
目前的问题：
1. 貌似墙学习了 UDP 流量的特征。。含 Flag 的包 200 个只能到达几个。可能需要添加混淆。
2. 分块传输离流传输更近了一步，但是尚未实现真正的流传输，需要发送端填满一个 block 或者读完输入，接收端才有输出。
 |
1
fcicq 2016-07-01 15:56:37 +08:00
能证明你的方法和 TCP Reno 相容吗?
|
 |
2
yexm0 2016-07-01 16:04:39 +08:00 via Android
windows 版有不？
|
 |
3
imxieke 2016-07-01 16:14:13 +08:00 via Android
资瓷.
|
 |
4
zhouheyang0919 OP @fcicq 数据传输通过 UDP 进行， TCP 连接仅用于状态同步。
传输流程大致是这样的： 发送端与接收端之间建立 TCP 连接和 UDP mapping -> 发送端通过 TCP 发送数据总长度，两端分别计算传输所需的 block 数量 -> 发送端以恒定速率发包 (udp)， 然后传输一定量的带有特殊标志 (0x1fffffff) 的包，以填充丢包造成的数据包数量小于预测数量，期间接收端无任何返回（这一步有待改进） -> 接收端将缺失的 block ID 通过 tcp 传输给发送端，发送端重复上一步过程（但只发送缺失的包），重复这两步直到缺失的 block 数量为 0 -> Done |
|
5
fcicq 2016-07-01 18:08:11 +08:00
@zhouheyang0919 没有减速逻辑的话必然不相容了.
|
 |
6
ryd994 2016-07-01 19:42:39 +08:00 via Android
讲真，除非有明确的拥塞控制的数学模型，所谓的加速绝大多数都是无脑发包
你们知道要是写出新拥塞算法可以发 CS 论文么？ |
 |
7
luohaha 2016-07-01 20:55:06 +08:00
研究生想做 tcp 加速方面的研究，被导师说太 low 了，好久之前的研究方向了。。
|
 |
8
vinsoncou 2016-07-01 23:09:21 +08:00
这个与 TsunamiUDP 相比有什么优势呢？
|
 |
9
mengzhuo 2016-07-02 00:55:56 +08:00 via iPhone
呃…不能做流控岂不就是无脑发
|
 |
10
fzinfz 2016-07-02 01:03:04 +08:00
看用法貌似目前只支持文件加速。 LZ 有兴趣发展成支持 proxy 的版本么？
JAVA 版参考: https://github.com/d1sm/finalspeed/tree/fileshare |
|
11
zhouheyang0919 OP |
|
12
zhouheyang0919 OP  1
@fzinfz 处理流加速比块加速更复杂。不过有这个打算
|
 |
13
bkjzs 2016-07-02 12:28:28 +08:00 via Android
可以看看 kcp
|
|
14
zhouheyang0919 OP @bkjzs kcp 是为双向的流传输设计的，在单向大容量传输上表现并不突出
|
|
15
zhouheyang0919 OP @bkjzs 峰值速率很高，但在延时较大的网络下速率不稳定
|
|
16
bkjzs 2016-07-02 22:38:27 +08:00 via Android
@zhouheyang0919 我自己用西雅图的服务器测试 kcp ，多线程传输大文件，可以稳定在 3mb/s ，显示使用了 50M 的带宽。
用这种软件比不用好太多，直接传输可能只有 200kb/s |
 |
17
Actrace 2016-07-03 16:44:19 +08:00
使用 TCP 进行状态同步的话， TCP 丢包影响很大吧？
|
|
18
zhouheyang0919 OP @Actrace TCP 传输的流量不到总流量的 1/500. 因此影响很小。
|
 |
19
Thiece 2016-07-08 11:44:51 +08:00
有最新进展吗？
|
Select Language