在本章中，我们对特定的Internet传输协议的讨论主要集中在UDP和TCP——Internet传输层的两个“work horses（主力）”。然而，正如我们所看到的，使用这两种协议三十年的经验已经确定了这两种协议都不适合的情况，因此传输层功能的设计和实现一直在不断发展。<br />在过去的十年中，我们已经看到了TCP使用的丰富演变。在3.7.1节和3.7.2节中，我们了解到除了TCP的“经典”版本，如TCP Tahoe和Reno，现在有几个新的TCP版本已经被开发、实现、部署，并在今天被广泛使用。**其中包括TCP CUBIC、DCTCP、CTCP、BBR等。事实上，[Yang 2014]的测量表明CUBIC(及其前身BIC [Xu 2004])和CTCP在Web服务器上的部署比传统TCP Reno更广泛;我们还看到BBR被部署在谷歌的内部B4网络，以及谷歌的许多面向公众的服务器上。**<br />还有很多(很多!)更多的TCP版本!有一些版本的TCP是专门为使用无线链路、使用大型RTT的高带宽路径、使用包重新排序的路径以及严格在数据中心内的短路径而设计的。有些版本的TCP在瓶颈链路上竞争带宽的TCP连接之间实现了不同的优先级，对于并行地通过不同源-目的路径发送段的TCP连接也有不同的优先级。处理数据包确认和TCP会话建立/关闭的TCP变体也与我们在章节3.5.6中研究的不同。**事实上，用“TCP”协议来指代它可能已经不正确了;也许这些协议唯一的共同特征是它们使用TCP段格式，我们在图3.29中研究过，并且它们应该在面对网络拥塞时“公平”地相互竞争!关于TCP的多种类型的调查，参见[Afanasyev 2010]和[Narayan 2018]。**
QUIC: 快速UDP互联网连接 Quick UDP Internet Connections
如果应用程序需要的传输服务不太适合UDP或TCP服务模型——也许应用程序需要比UDP提供的服务更多的服务，但不需要TCP提供的所有特定功能，或者可能需要与TCP提供的服务不同的服务——应用程序设计人员总是可以在应用层“roll their own（开发他们自己的）”协议。这是QUIC(Quick UDP Internet Connections)协议[Langley 2017, QUIC 2020]中采用的方法。具体来说，QUIC是一种全新的应用层协议，旨在提高安全HTTP的传输层服务的性能。QUIC已经被广泛部署，尽管仍处于作为互联网RFC (QUIC 2020)的标准化过程中。谷歌已经在其许多面向公众的网络服务器上部署了QUIC，在其移动视频流YouTube应用程序中，在其Chrome浏览器中，在Android的谷歌搜索应用程序中。现在超过7%的互联网流量是QUIC [Langley 2017]，我们想要进一步了解。我们对QUIC的研究也将成为我们对传输层研究的一个很好的高潮，因为QUIC使用了许多方法来实现可靠的数据传输、拥塞控制和连接管理，这些我们在本章中已经学习过了。
如图3.58所示，QUIC是一个应用层协议，使用UDP作为它的底层传输层协议，并且专门用于与HTTP/2的简化但进化版本的接口。在不久的将来，HTTP/3将原生地包含QUIC [HTTP/3 2020]。QUIC的一些主要特点包括:
- 面向连接和安全（Connection-Oriented and Secure）。与TCP一样，QUIC是两个端点之间的面向连接的协议。这需要在端点之间进行握手，以设置QUIC连接状态。两个连接状态是源连接ID和目标连接ID。所有QUIC数据包都是加密的，如图3.58所示，QUIC将建立连接状态所需的握手与认证和加密所需的握手(我们将在第8章中研究的传输层安全主题)相结合，从而比图3.58(a)中的协议栈更快地建立起来。其中需要多个RTT首先建立TCP连接，然后在TCP连接上建立TLS连接。
Figure 3.58 ♦ (a) traditional secure HTTP protocol stack, and the (b) secure QUIC-based HTTP/3 protocol stack
图3.58 ♦ (a)传统安全HTTP协议栈和(b)基于QUIC的安全HTTP/3协议栈
- 流（Streams）。QUIC允许多个不同的应用程序级“流”通过单个QUIC连接复用，一旦建立了QUIC连接，就可以快速添加新的流。流是两个QUIC端点之间可靠的、按顺序的双向数据交付的抽象。在HTTP/3的内容中，Web页面中的每个对象都有不同的流。每个连接都有一个连接ID，连接中的每个流都有一个流ID;这两个ID都包含在QUIC包的首部中(以及其他首部信息)。来自多个流的数据可能包含在一个QUIC段中，这是通过UDP进行的。流控制传输协议(Stream Control Transmission Protocol，SCTP) [RFC 4960, RFC 3286]是一个较早的可靠的、面向报文的协议，它首创了通过单个SCTP连接多应用程序级“流”的概念。我们将在第7章中看到SCTP用于4G/5G蜂窝无线网络的控制平面协议（control plane protocols）。
- 可靠的，TCP友好的拥塞控制的数据传输（Reliable, TCP-friendly congestion-controlled data transfer）。如图3.59(b)所示，QUIC分别向每个QUIC流提供可靠的数据传输。图3.59(a)显示了HTTP/1.1通过一个TCP连接发送多个HTTP请求的情况。由于TCP提供了可靠的、按顺序的字节传递，这意味着多个HTTP请求必须在目标HTTP服务器上按顺序传递。因此，如果一个HTTP请求的字节丢失了，其余的HTTP请求将不能被发送，直到这些丢失的字节被TCP在HTTP服务器上正确地接收到——我们在前面的章节2.2.5中遇到的所谓的HOL阻塞问题。由于QUIC在每个流的基础上提供了一个可靠的顺序交付，一个丢失的UDP段只影响那些在该段中携带数据的流;其他流中的HTTP报文可以继续接收并传递给应用程序。QUIC使用与TCP类似的确认机制提供可靠的数据传输，如[RFC 5681]中所述。
Figure 3.59 ♦ (a) HTTP/1.1: a single-connection client and server using application-level TLS encryption over TCP’s reliable data transfer (RDT) and congestion control (CC) (b) HTTP/3: a multi-stream client and server using QUIC’s encryption, reliable data transfer and congestion control over UDP’s unreliable datagram service
图3.59♦HTTP/1.1:在TCP的可靠数据传输(RDT)和拥塞控制(CC)上使用应用级TLS加密的单连接客户端和服务器(b) HTTP/3:多流客户端和服务器使用QUIC加密、可靠数据传输和拥塞控制UDP的不可靠数据报服务
QUIC的拥塞控制基于TCP NewReno [RFC 6582]，这是对我们在第3.7.1节中研究的TCP Reno协议的轻微修改。QUIC的草案规范[QUIC-recovery 2020]指出:“熟悉TCP的丢失检测和拥塞控制的读者会发现这里的算法与众所周知的TCP算法并行。”既然我们已经在第3.7.1节中仔细研究了TCP的拥塞控制，我们就可以在家里阅读QUIC的拥塞控制算法规范草案的细节了!
最后，值得再次强调的是QUIC是一种应用层协议，在两个端点之间提供可靠的、受拥塞控制的数据传输。QUIC [Langley 2017]的作者强调，这意味着QUIC可以在“应用程序更新时间尺度”上进行更改，也就是说，比TCP或UDP更新时间尺度快得多。
若有收获，就点个赞吧
0 人点赞
