有没有一种支持多线程传输的 proxy,多线程传送给你,再在你的终端拼接成流?

This topic created in 4312 days ago, the information mentioned may be changed or developed.

很多时候访问一台很远异地的服务器的时候,比如在线看视频,速度很慢,但如果使用多线程下载那个视频,则速度能够提高不少

有没有一种proxy,比如一般正常情况下
你 => proxy => 目标视频

proxy读取目标视频很快,但传送给你的时候很慢,你只有读完了比如proxy里100k的数据,proxy才会下载另100k的数据,这样proxy总是在等你读取完

有没有一种可能,proxy读尽可能多的数据放在缓冲里,而你从proxy读过来的时候采用多线程下载这一块的缓冲,然后再在你的终端拼接出流?

有没有什么现成的开源产品可以实现我想的这个思路?v2ex上能不能给点思路?

proxy

读取

100k

13 replies • 2014-09-07 15:57:03 +08:00

Seikinmeid

Jul 25, 2014

我也想知道，在这等答案~

yangqi

Jul 25, 2014

squid

stevenyou

Jul 25, 2014

aria2 ?

imn1

Jul 25, 2014

你说的其实是两个问题，因为流传送和流播放是两码事
实现你的这个目标要先达到几个可能：
1.知道视频真是url
2.服务器对该文件支持断点续传
3.能把本地文件模拟为前面的url
4.视频文件头及前段必须先传
5.播放器支持流式播放，至少正在播放的文件能边读边写入
所以能完成你所说的，基本上网上需求最大的两块就已经解决——去除广告、下载视频

mengskysama

Jul 25, 2014

楼主说的不是L7代理，和URL什么的无关。核心思想是把sock数据同时用多个链接来传输来达到加速的效果。一般对比较保守的拥塞控制TCP用多链接的确能加速。现在好像没有人这么做过。要自己实现也没难度（关键是要讨论下会不会链接之前相互抢占，有没有必要重新设计多链接的分发策略了。

hedaode

Jul 25, 2014

如果ISP不对单连接做速度限制，理想情况下单线程一样能跑满带宽。

但是如果网络丢包率很高，使用传统的TCP拥塞控制算法，对单线程单连接来说确实无法最大限度利用带宽（频繁掉包导致频繁慢启动）。这种情况下如果用多线程确实能减少慢启动带来的带宽浪费，从而提高速度。

因此要提高速度最好还是找一套更好的TCP拥塞控制算法，而不是用多线程。可以试试锐速这个TCP加速产品。

mhycy

Jul 25, 2014

有一个GoTunnel...

mhycy

Jul 25, 2014

GoTunnel一个缺点就是大流量的时候会造成新请求响应过慢
造成这事的原因是在有限的互联管道内新的请求必须等待目标数据拼接完毕后才可能成功发送，而且这个过程两端交互会产生更多的标记数据，使得带宽利用率进一步下降。
高速率的时候拼接时候后来包产生的延迟足以占用大量的内存。

polythene

Jul 25, 2014

以前在学校里看视频时受不了校园网的龟速，所以就写了这么一个工具，https://github.com/polyrabbit/http-booster 具体思路跟LZ的差不多，LZ可以参考一下。当然，这是很粗糙的一个实现，有很多bug和todo，有空我会再refine一下，也欢迎LZ的参与！

mengskysama

Jul 25, 2014

锐速简直可怕，他的丢包预判机制有时候会多发1倍的数据包来达到加速的效果。

20150517

Jul 25, 2014

@hedaode 试了下锐速,确实是TCP拥塞问题,准备在高峰时候再试试,谢谢了,非常有用

20150517

Jul 25, 2014

@mengskysama 嗯试了下,原来300KB的速度用了后貌似500KB了,但现在不是高峰情况,准备试丢包多的时候看看,另外购买锐速的话,有优惠什么吗?

@hedaode

jedihy

Sep 7, 2014

@hedaode 跑满是可以，但是不能保证能在短时间内跑满，因为RTT比较大。

@20150517 可以自己DIY一个锐速的，它的算法好不到哪里去，只要把内核里面TCP窗口增窗改激进，剪窗尽量少剪就可以达到，甚至轻松超过锐速。