一个被忽视的带宽问题

我们开发的远程访问系统软件（主要用于运维人员在局域网中通过WEB及命令行远程访问客户局域网中的IP设备），第一个软件版本在试用的时候，有用户反馈很少概率下页面有时打不开、打开慢的问题。

力争完美是我们的追求：我们将软件进行了大幅的优化，争取取得一个大家能满意的效果。

第二个版本，在实验室测试的时候，通过系统下载/上传的速度，最高可接近2MB/s，效果令人满意，访问体验明显优于第一个版本，即使在10%的丢包率下，用户使用体验也没有太明显的差异。

基于此，我们将系统架设到公网，进行了内部测试。

发现，系统一旦到了公网，迅捷的身影不灵验了。

如果只是访问非常简单的设备页面，速度杠杠的；但一旦访问复杂的，需要下载大量资源的WEB页面，就会经常出现打不开及打开慢的问题。

怪了，10%的丢包都扛得住，这个居然就挂了！而使用第一个版本，反而不出问题。

因为这次优化的代码，改动非常大，开始判断是不是修改的代码有问题，新设计的机制是不是有缺陷，头疼了好一阵子。后来经过分析，恍然大悟，问题原来出在局域网的出口带宽上。

因为这次大幅优化了速度及效率，系统的传输速度一开始设定的比较高，如果局域网的出口带宽太小，那么瞬间报文的冲击将导致大面积的丢包，大面积的丢包又导致系统的QoS重传机制生效，从而引发雪崩效应。

而我们系统的第一个版本，最开始的考虑是保证传输到达率，没有过多考虑传输效率问题，带宽占用小，反倒没有多大问题。

现在需要考虑的问题是，局域网的出口带宽，你永远无法确定，即使你知道用户使用的带宽是多大的，也无法预测局域网中的网络行为，比如，有人看网页，有人看视频，你无法确定系统最终能够占到多大的带宽用于通信。

找到问题就好办，速度设计带宽自适应算法，根据传输的效率及反馈，自动调整传输速率，既保证尽可能利用带宽，又保证传输质量。

2天内完成设计、编码到测试，效果非常明显。

开发中的一点小干货，分享出来，希望能够给技术人员带来一点启发。