这是一个创建于 3395 天前的主题，其中的信息可能已经有所发展或是发生改变。
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 206-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