在TCP领域，过去十年似乎没有太大变化。TCP的内部机制（拥塞控制）有一些细微的改进，主要是速率增加和降低过程中细节上的改进，但没有改变这个协议的基本行为。TCP仍然倾向于使用分组丢失作为拥塞的信号并且基于“加法增加，乘法减少”(Additive Increase Multiplicative Decrease，AIMD)[23]的规则在较低速率和能够触发丢失的较高速率之间振荡其流速。
在过去十年中一个与TCP协议密切相关的协议，多路径TCP(Multipath TCP, MPTCP)在IETF(Internet Engineering Task Force)被提出[24-25]并且逐渐的正在被标准化[26]。如图2所示，它主要有两个应用场景，一个是数据中心网络，还有一个是多种无线接入网络。在这两个场景中端到端之间存在多条路径，即端到端之间存在多个带宽来源，但是TCP协议只能够让端系统的一个连接使用一条路径。
图2 MPTCP的应用场景
多路径TCP则可以满足这个需求，MPTCP重新定义了连接的概念，一个连接不再是一个四元组组成，而是由一组四元组组成。每一个四元组定义了一条子流，一个连接的数据可以使用所有的子流进行传输。对于网络层，每一个子流就像是一个传统的TCP连接一样。在数据中心网络中，MPTCP可以和ECMP(Equal-Cost Multi-Path)同时使用，ECMP会把每个子流当成传统的TCP连接进行负载均衡，这样一个连接的数据就能够在多个路径上传输，从而实现一个连接可以同时使用多条路径。在多种无线接入的场景中，一个连接不再唯一的绑定一个IP地址。一个具有多个网卡的移动设备，可以使用所有的网卡获取IP地址与远端服务器建立若干个子流的连接。
多路径TCP的拥塞控制算法得到了重新的设计并且它有以下三个目标[27]：
提高吞吐率：多路径的流的吞吐量应当至少达到，在最好的路径上一条单流（TCP流）能达到的吞吐量。
公平性：多路径的流在任意一条共享链路上占用的带宽不会超过传统 TCP模式占用的带宽。这样就保证了多路径TCP不会过度影响到其他的流。
平衡拥塞：多路径的流应当尽可能的把数据从拥塞的路径上移开。
遵循这些原则，目前已经有若干个多路径TCP拥塞控制算法被设计出来(LIA[28]，OLIA[29]，BALIA[30], wVegas[31]。)并被实现到了Linux网络协议栈中。
2.3.2 BBR
近年来，谷歌公司提出了新的拥塞控制算法：Bottleneck Bandwidth and Round-trip time control algorithm(BBR)[32]。BBR与现有的TCP拥塞控制算法很不相同。BBR试图保持恰好位于发送方和接收方之间的端到端路径的带宽延迟积的速度。通过这种方式，它试图避免网络中数据缓冲的累积（当发送速率超过路径容量时），并且还试图避免在网络中留下空闲时间（发送速率小于路径容量）。BBR能够显著提高传输层使用端到端之间带宽的效率。
TCP的标准拥塞控制算法Reno[33]以及Linux使用的拥塞控制算法Cubic[34]有一个共同的特点。它们都会试图不停的提高发送速率，直到路径上出现丢包。丢包的出现是因为路径上的分组队列的长度超过了设备能够提供的存储空间，而队列的出现是由于对应设备出网口处的带宽资源小于进入流量的总速度。Reno和Cubic不停地增大拥塞控制窗口，直到瓶颈链路排队然后丢包。与此不同的是，BBR尝试的估计端到端的带宽延迟积，尽可能的不去排队。
BBR将周期性地在一个RTT间隔的时间内，发送一定量的数据，数据量是带宽延迟乘积的1.25倍（增益因子）。这个速率不是非常具有侵略性，但是在RTT间隔内足以完全占用链路并使之进入排队的状态。如果可用的瓶颈带宽没有改变，那么增加的发送速率将导致在瓶颈处形成队列。这将导致ACK显示RTT被增大，但瓶颈带宽估计不变。如果是这种情况，则发送方随后将在一个RTT内以降低的发送速率发送数据，从而使得瓶颈队列耗尽。如果由于此探测而可用的瓶颈带宽估计已增加，则发送方将根据此新的瓶颈带宽估计进行操作。
BBR连续的带宽探测操作将继续以相同的增益因子增加发送速率，直到由于这些探测而估计的瓶颈带宽不再变化。这种通过定期的探测路径以揭示路径特征的变化是从基于丢弃的拥塞控制算法借用的技术。拥塞控制算法通过每8个RTT间隔将数据发送速率提高25％，在路径上增加流量压力。如果这导致相应的排队负载，如增加的RTT，则算法将降低速率使得队列能够耗尽。然后在估计的路径带宽和延迟处以稳定状态发送数据。