在应用海外服务器的时候，经常发现网速只有十几k，平时我也不怎么关注。我觉得是网络带宽不够，还是自己申请的光纤宽带不好。其实很有可能不是这样。
在应用海外服务器的时候，经常发现网速只有十几k，平时我也不怎么关注。我觉得是网络带宽不够，还是自己申请的光纤宽带不好。其实很有可能不是这样。
因为超快的限制，延迟时间会很高(即使光是直线传播，在中国的太平洋上往返一次也要100 ms以上)。而且距离远，路由器跳数多，上网拥挤。网络丢包的情况经常发生。
对于TCP协议，这是最常用的协议，当一个包从推送端发出时，协调器会响应ACK，表示已经收到。用这种系统来保证可信度。然而，对于高延迟的路由协议，如果每个推送包都在等待回复，那么大多数时间它都在等待数据文件到达，而路由协议是空闲的。所以一般采用滑动窗口技术。也就是直到对话框满了，推送端一直推送包，然后收到回复后，会从对话框中清除确认包。这样可以提高路由协议的利用率。
TCP的另一个特性是拥塞控制。当推送端检测到路由协议导致网络丢包时，会主动缩小对话框大小，以减缓推送速率，防止延迟。但对于跳数较多的路由协议，如果一个路由器平滑网络丢包失败，就会被推送端识别为时间延迟，从而危及网速。
为了处理网络丢包问题，最简单直接的方法就是两次推送，即推送同一数据文件的两份拷贝。那样的话，在网络带宽充裕的情况下，网络丢包会减少平方米。
在这种方法下，眼前的好处是减少网络丢包，眼前的坏处是消耗两倍的总流量。一些扩大的危害是更容易打开快速修复的逻辑，防止网络丢包时对话框收缩过快。一定级别也可以提高网速。
最近，我很忙。空我在业余时间做过一个很简单的程序流程，实际效果很好。在一个VPS上测试后发现，免费下载在不打开的情况下可以并行处理，ssh管道速率在十几K级别。开通后可以达到平均300KB的速率。实际效果突出。而对于可以满网络带宽运行不提速(多线程下载)的类型，因为开启后总的流量损失，速率下降。因此，这种方案不适合线程同步/高速路由协议。
目前版本号很简单，也很符合逻辑。未来会优化(主动启动快修，快速重传等。)降低总流量消耗，提高实际效果。
目前程序流命名为net-speeder，这是相对于改变协议栈而言的。因为后一种必须重新升级编译器核心，所以部署应用客户端程序流程更方便，可靠性更高，兼容模式更强。缺点是特色成本略高于金刚，可玩性受损。总的来说，更适合我应用客户端程序进程，尤其是在vm虚拟机中(比如OpenVZ，LXC等vm虚拟机无法自定义自己的内核)。
