IETF透露HTTP over QUIC 将重命名为HTTP/3 协议

周一，IETF透露它将HTTP-over-QUIC实验协议重命名为HTTP / 3。HTTP-over-QUIC是一种HTTP重写，用TCP替换TCP。

如果这看起来有点为时过早，那么它与IETF的历史运作方式并不完全不符。就像TLS 1.3在每个网站甚至已经切换到TLS 1.2之前推出的那样（尽管到8月份绝大多数都有）并且SHA-3已经建立，尽管几年前SHA-2开始使用。因此，尽管事实上只有31.2％的前1000万网站甚至使用HTTP / 2，但HTTP / 3已经出现。

已经有1000万支持QUIC的1.2％。那是大约120,000个网站。

那么，什么是HTTP-over-QUIC - 或者我想现在它是HTTP / 3 - 这个新协议对于 SSL / TLS  行业意味着什么？

什么是HTTP / 3（又名HTTP-over-QUIC）

HTTP-over-QUIC是一种实验性的Google协议，它是一种HTTP重写，它在QUIC中交换传统上位于互联网核心的标准TCP。

TCP是传输控制协议，与IP（互联网协议）一起，它已成为定义互联网多年的基本规则之一。它足够老，它有一个三位数的RFC编号。这是一个IETF的笑话，TCP是在1981年定义的.TCP是一种面向连接的协议，它旨在提供无差错的数据传输，它控制数据如何分解成数据包并传播到连接的另一端。

不幸的是，无差错传输功能是一把双刃剑，因为它可以增加连接的延迟。它必须确保它接收每个数据包，并运行校验和哈希来验证这一点。简而言之，散列是一种单向函数，有助于验证真实性。如果数据全部按预期到达，则校验和产生的哈希值将与已知的哈希值匹配。如果没有，TCP将使连接另一端的一方再次发送它。

QUIC是Quick UDP Internet Connections的首字母缩写。这引出了一个问题，什么是UDP？UDP是用户数据协议。解释这个问题的最好方法是回到我们刚刚与TCP讨论过的无差错传输。UDP是另一种连接协议，但它不提供无差错传输。相反，它促进了一种低延迟的连接（由于它容忍一些数据丢失的事实）。

将它应用于现实生活可能会很有启发性。TCP无处不在，互联网上的绝大多数流量都是TCP。这非常适合数据保真度很重要的情况。当您在YouTube上看到视频缓冲，或者在节目加载时您在Netflix上获得风车 - 这是一个TCP连接。您的设备基本上是在说“我需要在继续之前了解这些数据。”

在UDP优先的情况下，当您需要发送恒定的实时数据流时，延迟是不可接受的。一些明显的背景是IP语音（VoIP），Skype和视频游戏网络等视频消息应用。在这种情况下，UDP只会在连接另一端的聚会上抛出一个恒定的数据流，如果有些数据丢失，数据最终会赶上来。这称为尽力而为。

QUIC是由Google设计的实验性协议。这可能看起来很奇怪，但谷歌的SPDY最终变成了HTTP / 2，所以这也不是前所未有的。QUIC本质上是谷歌重写TCP的尝试，它结合了HTTP / 2，TCP，UDP和传输层安全性（TLS）等。目标是让QUIC替换TCP和UDP。它默认是加密的，这意味着它比它的前辈更快，更安全。这主要是因为它使用TLS 1.3（RFC 8446）并利用其改进的单次往返握手和零往返恢复功能。

来自Google的Chromium博客：

       QUIC的另一个重要收益是改善拥塞控制和丢失恢复。重传数据包时，不会重复使用数据包序列号。这避免了关于已经接收到哪些分组的模糊性并且避免了可怕的重传超时。因此，在网络状况不佳的情况下，QUIC比TCP更胜一筹，为最慢1％的连接缩短了Google搜索页面加载时间。对于像YouTube这样的视频服务，这些好处更加明显。用户在使用QUIC观看视频时报告的重建次数减少了30％。这意味着花在盯着微调器上的时间更少，观看视频的时间也更多。
      

虽然最初只有Google的服务器支持HTTP-over-QUIC，但今年早些时候Facebook也增加了支持。

这对SSL / TLS行业意味着什么？

就如何与当前的SSL / TLS生态系统一起使用而言，它不会对数字证书的使用产生太大的直接影响，因为TLS在协议中被烘焙，并且身份验证仍然需要由可信证书处理当局和PKI。

可能来自HTTP / 3的最大好处是，它将迫使网站更快地支持TLS 1.3。

但是，由于不到三分之一的互联网甚至使用HTTP / 2而且我们仍然有一小部分乱七八糟的人依赖于HTTP（以及一些愿意死在那座山上的人），但这仍然可能暂时不会有一段时间。）。