在使用海外服务器的时候，经常会发现网速只有十几k，平时不会去关注，会觉得网络带宽不够，或者自己应用的光纤宽带不好。其实很有可能没有这个道理。

在使用海外服务器的时候，经常会发现网速只有十几k，平时不会去关注，会觉得网络带宽不够，或者自己应用的光纤宽带不好。其实很有可能没有这个道理。

由于超快的限制，延迟时间会更高(即使光是直线传播，在中国太平洋往返一次也要100 ms以上)。而且因为距离远，模式路由器跳数大，互联网拥挤。网络丢包经常发生。

对于常用的TCP协议，推送端发出数据包后，协调器会响应ACK，表示已经收到。用这种制度保证可信度。但是，对于高延迟的路由协议，如果每个数据包都被推送并等待回复，大部分时间都是等待数据文件到达，而路由协议是空闲的。所以一般选择推拉窗技术。即在对话框满之前，推送终端不断推送数据包，然后收到回复后，将收到的数据包从对话框中清除。这可以提高路由协议的利用率。

TCP的另一个特点是拥塞控制。当推送端检查到路由协议产生网络丢包时，会主动缩小对话框大小，以减缓推送速率，防止延迟。但是对于跳数较大的路由协议，如果路由器不够稳定导致网络丢包，会被推送端识别为延时，从而危及网络速度。

为了处理网络丢包的问题，最简单直接的方法就是推送两次，也就是推送同一个数据文件的两个副本。那样的话，当网络带宽充裕时，网络丢包会减少一平方米。

在这种方法下，眼前的好处是减少网络丢包，眼前的坏处是消耗两倍的总流量。一些扩大的危险是更容易打开快速修复逻辑，这可以防止网络丢失数据包时对话框收缩过快。一定的水平也可以提高网速。

最近很忙。业余时间做了一个很简单的程序流程，实际效果很好。在一个VPS上测试，发现免费下载在没有打开的时候是并行处理的，ssh流水线速率在十k以上的水平，打开后可以达到平均300KB的速率。实际效果突出。但是对于可以满负荷运行而不加速的类型(多线程下载)，打开后由于总无效流量过大，速率下降。所以这个方案不适合线程同步/高速路由协议。

目前版本号很简单很有逻辑，以后会进行优化(主动启动快修快重传等。)来降低总流量消耗，提高实际效果。

目前程序流被命名为net-speeder，这是相对于改变协议栈而言的，因为后者必须重新升级编译器内核，客户端模式程序流的应用更方便、更可靠、更兼容。缺点是特性的成本比钻石级的可玩性稍差。总的来说，我更适合应用客程序流，尤其是vm虚拟机(OpenVZ、LXC等vm虚拟机不能自定义自己的内核)。