快速UDP网络连接（QUIC）的管理控制机制技术要求

■制定 □修订

□IDT □MOD □NEQ

□FTP

33.040.40

中国互联网络信息中心

暨南大学,中国电信集团有限公司

DNS(domain name system，域名系统)等应用层协议运行在UDP、TCP等传输层协议之上，DNS原始协议中数据在互联网上以明文方式进行传输，不能对服务数据内容提供隐私加密、认证、数据完整性等安全保证；近年来针对域名系统的网络安全事件层出不穷，加强DNS的隐私保护对维护整个域名系统的稳定安全运行具有重要的意义。 但是应用层的高性能、安全、隐私等特性升级需要从整体协议架构上进行设计。传输层协议已在网络中广泛部署并使用了几十年，TCP在不可靠的信道上实现了可靠的网络传输。并实现了基本的分组错误检测与纠正、按序交付、丢包重发，以及保证网络高效率的流量控制、拥塞控制，让TCP成为大多数网络应用中最常见的传输协议。UDP提供的则是不可靠、无连接的服务。 TCP是由操作系统在内核协议栈层面实现，应用程序只能使用，不能直接修改。无论在移动端、PC端还是服务器端，相较于应用程序的更新迭代，操作系统的升级都相对保守和缓慢，因此在TCP协议基础上进行的特性更新很难快速推广。同时经过几十年的广泛应用，网络生态中各种中间设备如防火墙、NAT网关等在消息传输格式、允许的端口号等方面已达成广泛共识，协议内容的修改很容易因中间设备的干扰而失败。此外，HTTPS等使用TCP进行传输并由TLS协议进行安全认证的应用层协议需要经过TCP的三次握手和TLS的握手过程才能建立起数据传输连接，在一些应用场景中，握手延迟影响较大。同时由于在单路传输下实现按序交付和可靠交付，TCP存在队头阻塞等问题。 随着移动互联网快速发展以及物联网的逐步兴起，网络交互的场景越来越丰富，网络传输的内容也越来越庞大，用户对网络传输效率和WEB响应速度的要求也越来越高。基于以上原因，如果继续在现有的TCP协议之上实现一个全新的应用层协议或基于TCP进行协议升级，依赖于操作系统、中间设备还有用户的支持，部署成本很高，广泛推广的阻力很大。因此需要新的传输协议解决TCP存在的一些问题并能快速迭代更新，以更好的支持复杂的网络应用场景。

本文件规定了QUIC的管理控制机制技术要求。 本文件适用于基于QUIC的DNS系统、HTTP/3及其它需要QUIC提供性能优化、隐私安全增强的应用场景。 本文件主要技术内容包括流的定义、优先级和支持的操作，流的发送、接收状态、请求状态转换、允许的帧类型，连接支持的操作，数据包和连接的匹配，以及不同状态下针对连接和流的流量控制具体要求。

2013年Google发布了gQUIC，gQUIC是一套相对独立的传输层协议，它同时保障了数据传输的可靠性和安全性，包括Chrome、IE、Safari、Firefox等在内的主流浏览器及Google的网站服务器和云服务器都支持gQUIC。后续IETF开始进行QUIC协议的设计工作，并发布了IETF版本的QUIC。本文件的相关参考标准包括RFC9000 QUIC: A UDP-Based Multiplexed and Secure Transport等国际标准。