QUIC（快速UDP Internet Connections）是一种新的默认加密的Internet传输协议，它提供了许多改进，旨在加速HTTP通信并使其更安全，其目标是最终取代web上的TCP和TLS。在这篇博文中，我们将概述QUIC的一些关键特性，以及它们如何为web带来好处，以及支持这个激进的新协议所面临的一些挑战。事实上，有两个协议同名："Google QUIC"（简称gQUIC），是Google工程师几年前设计的原始协议，经过多年的试验，现在已经被IETF（互联网工程任务组）采用进行标准化。"IETF-QUIC"（从现在起就是"QUIC"）已经与gQUIC有相当大的分歧，因此可以将其视为一个单独的协议。从数据包的有线格式，到握手和HTTP映射，QUIC改进了最初的gQUIC设计，这得益于许多组织和个人的开放协作，共同的目标是使互联网更快、更安全。那么，QUIC提供了哪些改进？内置安全性（和性能）QUIC与现在受人尊敬的TCP的一个更根本的偏差是，它的设计目标是提供一个默认的安全传输协议。QUIC通过提供安全特性来实现这一点，比如身份验证和加密，这些特性通常由传输协议本身的更高层协议（如TLS）处理。初始QUIC握手结合了TCP的典型三方握手和tls1.3握手，后者提供了端点的身份验证和密码参数的协商。对于那些熟悉TLS协议的人，QUIC用自己的帧格式替换TLS记录层，同时保持相同的TLS握手消息。这不仅可以确保连接始终经过身份验证和加密，而且还可以加快初始连接的建立：与TCP和TLS 1.3握手组合起来所需的两次往返相比，典型的QUIC握手只需在客户端和服务器之间进行一次往返。但QUIC更进一步，它还加密了额外的连接元数据，这些元数据可能被中间盒滥用来干扰连接。例如，当使用连接迁移时，被动路径攻击者可使用数据包编号关联多个网络路径上的用户活动（见下文）。通过加密数据包编号，QUIC确保除了连接中的端点之外，任何实体都不能使用它们来关联活动。加密也可以是对僵化的一种有效的补救措施，它使得协议中内置的灵活性（例如能够协商该协议的不同版本）由于实现中的错误假设而无法在实践中使用（Oscification是延迟TLS 1.3部署的长期原因，这只有在几次修改后才可能实现，这些修改旨在防止僵化的中间盒错误地阻塞TLS协议的新修订。线路阻塞头HTTP/2的主要改进之一是能够将不同的HTTP请求多路传输到同一个TCP连接上。这允许HTTP/2应用程序并发地处理请求，并更好地利用可用的网络带宽。与当时的现状相比，这是一个很大的改进，即如果应用程序希望同时处理多个HTTP/1.1请求，则需要启动多个TCP+TLS连接（例如，当浏览器需要同时获取CSS和Javascript资产来呈现网页时）。创建新的连接需要多次重复初始握手，以及经历初始拥塞窗口的上升，这意味着web页面的呈现速度减慢。多路传输HTTP交换避免了所有这些。然而，这也有一个缺点：由于多个请求/响应是通过同一个TCP连接传输的，因此它们都会受到数据包丢失（例如，由于网络拥塞）的影响，即使丢失的数据只涉及单个请求。这被称为"线路头阻塞"。QUIC更深入一点，为多路复用提供一流的支持，这样不同的HTTP流可以映射到不同的QUIC传输流，但是，尽管它们仍然共享相同的QUIC连接，因此不需要额外的握手和共享拥塞状态，但是QUIC流是独立交付的，这样在大多数情况下，影响一个流的包丢失不会影响其他流。例如，这可以显著减少呈现完整网页（使用CSS、Javascript、图像和其他类型的资产）所需的时间，尤其是在穿越高度拥挤的网络、具有高数据包丢失率的网络时。这么简单，呃？为了实现它的承诺，QUIC协议需要打破许多网络应用程序认为理所当然的一些假设，这可能会使QUIC的实现和部署更加困难。QUIC被设计为在UDP数据报之上交付，以便于部署，并避免来自网络设备的问题，这些设备从未知协议丢弃数据包，因为大多数设备已经支持UDP。这也允许QUIC实现在用户空间中生存，因此，例如，浏览器将能够实现新的协议特性并将其发送给用户，而不必等待操作系统的更新。然而，尽管预期的目标是避免破坏，但它也使得防止滥用和正确地将数据包路由到正确的端点更具挑战性。一个纳特把他们都带来，在黑暗中捆绑他们典型的NAT路由器可以使用传统的4元组（源IP地址和端口、目的IP地址和端口）来跟踪经过它们的TCP连接，并通过观察在网络上传输的TCP SYN、ACK和FIN包，来检测新连接何时建立和何时终止。这使它们能够精确地管理NAT绑定的生存期，内部IP地址和端口之间的关联，以及外部IP地址和端口之间的关联。对于QUIC，这还不可能，因为现在部署在野外的NAT路由器还不了解QUIC，所以它们通常会退回到UDP流的默认和不太精确的处理，这通常涉及使用任意的，有时非常短的超时，这可能会影响长时间运行的连接。当NAT重新绑定发生时（例如由于超时），NAT外围外部的端点将看到来自不同源端口的数据包，而不是最初建立连接时观察到的源端口，这使得仅使用4元组无法跟踪连接。不仅仅是纳特！"迁移IP地址和将要迁移的IP地址在一个不同的路径"被称为"允许在一个不同的连接点上迁移"的特征。例如，当已知的WiFi网络可用时（比如当用户进入他们最喜欢的咖啡店时），移动客户端将能够在蜂窝数据网络和WiFi之间迁移QUIC连接。QUIC试图通过引入连接ID的概念来解决这个问题：一个由QUIC包携带的可变长度的不透明blob，可以用来标识连接。端点可以使用这个ID来跟踪它们负责的连接，而不需要检查4元组（实际上，可能有多个ID标识同一个连接，例如，在使用连接迁移时，为了避免链接不同的路径，但是这种行为由端点而不是中间的框控制）。然而，这也给使用选播寻址和ECMP路由的网络运营商带来了一个问题，在这些网络运营商中，一个目的地IP地址可能识别数百甚至数千个服务器。由于这些网络使用的边缘路由器还不知道如何处理QUIC流量，因此可能会发生属于同一QUIC连接（即具有相同连接ID）但具有不同4元组（由于NAT重新绑定或连接迁移）的UDP数据包可能最终被路由到不同的服务器，从而中断了连接。为了解决这一问题，网络运营商可能需要采用更智能的第4层负载平衡解决方案，这种解决方案可以在软件中实现，并且无需接触边缘路由器即可部署（例如，请参见Facebook的Katran项目）。Q包HTTP/2引入的另一个好处是报头压缩（或HPACK），它允许HTTP/2端点通过删除HTTP请求和响应中的冗余来减少通过网络传输的数据量。特别是，在其他技术中，HPACK使用动态表，其中填充了从以前的HTTP请求（或响应）发送（或接收）的头，允许端点在新的请求（或响应）中引用以前遇到的头，而不必重新传输它们。HPACK的动态表需要在编码器（发送HTTP请求或响应的一方）和解码器（接收它们的一方）之间同步，否则解码器将无法解码它接收到的内容。对于TCP上的HTTP/2，这种同步是透明的，因为传输层（TCP）负责以发送HTTP请求和响应的相同顺序发送它们，更新表的指令可以由编码器作为请求（或响应）本身的一部分发送，从而使编码非常简单。但对魁克来说，这更复杂。QUIC可以在不同的流上独立地传递多个HTTP请求（或响应），这意味着，尽管它负责按单流的顺序传递数据，但在多个流之间没有排序保证。例如，如果客户机通过QUIC流a发送HTTP请求a，并通过流B发送请求B，则可能