在互联网技术高速发展的当代，各种互联网应用层出不穷，随着人们需求的提高和互联网应用功能更加丰富，人们对美好生活的渴望上升到了一个新高度。但这些所有都建立在良好的基础设施上，对于互联网则是网络带宽。比如根据计算，要按照H265编码标准传输4K视频，流畅播放的带宽需求约为12~40Mbps。
但是，现在校园网提供的带宽只有14Mbps。实际上在B站看4K视频时，虽然能正常播放，但拖动进度条是就要缓存许久了，体验上非常不佳。因此，在校园网内实现多线负载是一个好的选择，能大大提高各种网络体验。理想下，14Mbps，叠加一次就是28Mbps，加一个帐号就是56Mbps，再加两个人就能达到112Mbps！一百兆的速度，4人使用，肯定够了！
基础知识
首先要注意这里的负载均衡和Nginx/Apache等应用层的负载均衡不一样，那些是基于HTTP协议的负载均衡，且是将传入的主动连接进行负载均衡，具有主动权；而我们是在网络层进行负载均衡，要处理的是一个个IP数据包，且我们要尽量讨好校园网/ISP网关，不能让它们误以为这些拆分的连接是不完整的数据包而被丢弃，是被动的。
Linux下有多种负载均衡方案，这里列举出我想到的几种思路。我们可以思考，要将多条线路合并起来，可以从OSI网络模型的每一层来尝试。
物理层的负载均衡
这个是最有效的方法，但也是最难以实现的方法。就像将两条四芯电缆合并成一条八芯电缆，网速就能从一百兆上升到一千兆一样；亦或将空中的电磁波合并，实现类似于WiFi 6的技术那样，也能提高传输速度。但这种多线负载一般仅仅用于突破传输速度极限，并不适用于限速情况。且我们也不可能改变学校机房的电口为光口，难以实现。
链路层的负载均衡-bonding
在链路层就开始有大量应用了，机房中常常将两个10G光口合并，来获得20Gbps的速度。在Linux下实现也很简单，只需将两个二层网卡做bonding，即可叠加带宽。但是这种方案在校园网或家宽条件下显然无法直接应用。
于是有一个迂回方案，既然我们有多条线路，运营商那边不可能接受bonding拆分的数据，那我们就在远程构建一个路由器将bonding数据合并就可以了嘛。现在方案就出来了：首先在远端搭建一个VPN服务器，对于本地的路由器，在每一条出口线路上都建立对远端的连接，再对每个虚拟出来的网卡做bonding，就可以提高带宽。
这个迂回方案有几个限制：首先由于bonding只对二层网卡有效，所以一般使用OpenVPN的TAP模式（二层隧道）。对于Wireguard这种三层隧道协议来说，则还需再在TUN内建立GRE/vxlan隧道，就会出现“套娃”，可能会降低带宽利用率，延迟也会大一些。其次，对于带宽的限制，远端服务器必须有高上传下载带宽，本地的下载速度既取决于本地的叠加下载带宽，也取决于远端的上传带宽。第三，对于家宽，ISP不同可能导致到远端的延迟不一致，可能需要更多处理（比如在远端主动等待另一线路的数据包），否则可能出现大量重传。
网络层的负载均衡
网络层的负载均衡看似简单，但会带来非常大的问题。简单是因为只需要把每个IP数据包往不同上游送就好了，但问题是我们毕竟处于一个“弱势”的地位，这种拆分的数据包往往会因为不完整而被ISP和服务器“双重打击”，被丢弃。
比如说，当内网要向外网服务器建立一个TCP连接，根据TCP三次握手流程，在握手阶段，假设内网设备第一次握手从线路1发出，服务器从线路1回应，但如果内网设备从线路2发出握手，就会出问题。首先防火墙会认为这个数据包没有经过第一次握手就尝试开始第二次握手，怀疑在攻击服务器（SYN Flood），就会丢弃这个数据包。如果没有防火墙，也不能成功，因为对于每个连接，都需要确定客户端的IP地址和端口，而负载均衡后，要么是IP地址不一致，要么是端口不一致（如果路由器有公网IP，则IP地址不同；如果路由器在运营商NAT后，则NAT后端口不一致），所以根本无法建立网络层之上的连接。
传输层的负载均衡
对于我们的网络环境，传输层的负载均衡才是通用的解法。区别于上面网络层，传输层拆分得没有那么彻底，而是使用conntrack，识别不同连接，将不同连接送往不同上游，保持了连接的完整性的同时实现了负载均衡。
但这也有一个缺点：每个连接还是限速的，对于单个连接并不能实现负载均衡。比如说看视频时。但又有一个好处是一些视频网站视频和音频数据是分开传输的（比如B站），能缓和一部分带宽压力。（但在B站实际测试时，播放确实顺畅了，这个就不知道是为什么了，也许是使用了多连接？）
具体的传输层负载均衡方法可以参考以下博客：
最后还要提一点，就是负载均衡的普遍缺点：网络质量完全由质量差的那一条线路决定，或者说完全遵循“木桶效应”吧。