2022年写了不少c++代码，除了搬砖之外，作为一名WebRTC的爱好者，今年的个人成长上面主要集中在对RTC的QoS算法的理解上，更准确的说，是带宽估计方法和网络拥塞处理的理解上。首先，梳理了弱网的主要原因如下：
- 信道问题：信号弱导致的带宽限制，主要策略是限制带宽。
- 带宽抢占：其他信道的网络流量抢带宽，主要策略为应用内控制优先级，应用之间先退避，再逐渐抢占的策略。
- 总带宽少：isp限速或者交换机缓冲小，现象是延迟变大后丢包明显，策略先退避，再逐渐抢占的策略。
- 网络故障：城域网或者骨干网拥堵，现象是出现于带宽无关的随机丢包，策略是服务端多线部署，智能路由，专线等，策略也是先退避，再逐渐抢占恢复，靠抗丢包来抗。
据这一年的经验看，1和2出现在无线环境下较多，由于BBR的拥塞控制算法是自计时（self-clock）的，比较敏感，所以更合适，同时竞争能力也可以与tcp cubic平衡；而3和4出现在有线环境较多，信道较好，由于GCC的带宽探测抗干扰能力较强，所以基于带宽探测（rate-base）的拥塞控制算法更合适。
然后，理清了拥塞控制算法的3个小目标：
- 网络变化时，调整要快速
- 网络稳定时，带宽要稳定
- 无论哪种情况，竞争性要强
再之后，融入社区，找到了一个叫rmcat工作组,全称是 RTP Media Congestion Avoidance Techniques 实时通信媒体拥塞避免技术工作组，了解了rmcat工作组的三个草案，GCC，NADA和SCReAM，学习到了丢包、相对时延、BDP的计算和Padding包等概念，悟道了未来无线wifi/5g环境越来越普及，那么未来的算法一定要基于BBR来做。
最后，针对BBR的自计时的拥塞控制算法中，吸取GCC的带宽探测的经验，并对测量最大带宽的带宽上下探做了优化；在实时通信场景下，把排空网络测量最小时延的部分，也做了优化，得到了一个相对不错的带宽探测和拥塞控制的实时通信的网络模块，算是2022年一个比较大的收获吧。
