非无极变速的TCP代理

TCP自己本身具有流控拥控功能，也就是说TCP可以自适应网络状况，网络好的话，那就快点发，反之就慢点发，对方接收不及了，同样会减慢发送速度，这种控制是在两个方向分别进行的，因为TCP是全双工的。你可以把TCP看成一个无极变速的传送带，其速率由网络状态(主要反映在丢包率)以及端点状态(主要反映在收发缓冲区空闲状态)共同决定。
       TCP代理，它由两条对接的TCP连接首尾相连而成，它也想做到无极变速就不是那么简单了。首先，那就是一条TCP反映的网络状况如何反馈到另一条连接上，其次就是即使可以反馈，如何实现它。
       一个TCP代理的实现，典型的就是从一个TCP连接读取数据，然后发到另一个TCP连接，反过来也一样。关键是怎么一个实现方式，一般来讲，有两种方法：
无极变速法：这种方式比较好，维护一个环形缓冲区，从一个TCP连接读取数据到环形缓冲区的既有数据之后，最大读取空闲空间大小，然后从环形缓冲区的头部开始非阻塞写到另一个连接，按照成功写入的数量前移环形缓冲区的剩余数据。
速度保持法：所谓的速度保持法，就是两个TCP连接默认对方的环境是和自己一样的，实际操作就是，从一个TCP连接读取一个最大长度的数据，然后等待这些所有数据阻塞写入到另一个TCP连接后才开始读取新的数据，同样是尽可能多得读取。在前后两个连接的网络状况，缓冲区状况确实一致的情况下，这确实可以得到最大的吞吐量，可是如果前端的网络条件恶劣或者终端性能恶劣，就会导致不对称，即，从后端总是能快速读取到满缓冲区的数据，然而这么大的数据却很难写入到前端连接，导致后端的接收窗口瞬间为0！这会带来两点影响。
       首先，一次写入恶劣网络大量的数据，其成功率远低于N次写入恶劣网络1/N如此量的数据，这是因为TCP是按照按序到达的最后一个来ACK的，数据量越多，越容易乱序，丢包的后果越严重，一旦发生3次重复ACK，就会进入快速重传，窗口猛缩。比如，一次写4个字节，丢掉了第3字节，和一次写4000字节，丢掉了第3字节(这还不考虑丢掉了其它的...)，影响分别是什么？
       另外，后端TCP连接的接收窗口变为0的话，会影响另一端的TCP程序判断，从而可能reset掉该条连接，或者导致本端由于持续不能写入成功而超时。超时超时超时超时超时超时超时超时超时超时超时超时...
       好的驾驶员都会无极变速之术，乘客乘坐得也更加舒适，反之，新手一般都是猛刹车，猛油门，当然，只要不是过于频繁，这也没有什么不好，比如在只有你一辆车的高速公路上。
       要不是在最近的工作中遇到了这个问题，还是个Apache的问题，才不去折腾这呢，Apache不是我主业，TCP代理也非我之强项，开源软件一般缺乏文档，代码的注释充满了诗兴，没有任何成型的东西，除了代码本身！你必然要花很多的时间和精力来揣摩当时作者写这段代码的意图。