2

HTTP 3.0彻底放弃TCP,TCP到底做错了什么?

 1 year ago
source link: https://network.51cto.com/article/713077.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

HTTP 3.0彻底放弃TCP,TCP到底做错了什么?-51CTO.COM

HTTP 3.0彻底放弃TCP,TCP到底做错了什么?
作者:Hollis 2022-07-04 09:32:44
基于上面我们提到的两个问题,有人提出来说:既然TCP存在这些问题,并且我们也知道这些问题的存在,甚至解决方案也不难想到,为什么不能对协议本身做一次升级,解决这些问题呢?

​从HTTP/1.0开始,一直到HTTP/2,不管应用层协议如何改进,TCP一直以来都是HTTP协议的基础,主要是因为他能提供可靠连接。

但是,从HTTP 3.0开始,这个情况就有所变化了。

因为,在最新推出的HTTP 3.0中,已经彻底启用TCP协议了。

TCP队头阻塞

我们知道,TCP传输过程中会把数据拆分为一个个**按照顺序**排列的数据包,这些数据包通过网络传输到了接收端,接收端再**按照顺序**将这些数据包组合成原始数据,这样就完成了数据传输。

但是如果其中的某一个数据包没有按照顺序到达,接收端会一直保持连接等待数据包返回,这时候就会阻塞后续请求。这就发生了**TCP队头阻塞。**

HTTP/1.1的管道化持久连接也是使得同一个TCP链接可以被多个HTTP使用,但是HTTP/1.1中规定一个域名可以有6个TCP连接。而HTTP/2中,同一个域名只是用一个TCP连接。

所以,在HTTP/2中,TCP队头阻塞造成的影响会更大,因为HTTP/2的多路复用技术使得多个请求其实是基于同一个TCP连接的,那如果某一个请求造成了TCP队头阻塞,那么多个请求都会受到影响。

TCP握手时长

我们都知道TCP的可靠连接是基于三次握手与四次挥手实现的。但是问题是三次握手是需要消耗时间的。

TCP三次握手的过程客户端和服务器之间需要交互三次,那么也就是说需要额外消耗1.5 RTT。

> RTT:网络延迟(Round Trip Time)。他是指一个请求从客户端浏览器发送一个请求数据包到服务器,再从服务器得到响应数据包的这段时间。RTT 是反映网络性能的一个重要指标。

在客户端和服务端距离比较远的情况下,如果一个RTT达到300-400ms,那么我握手过程就会显得很”慢”了。

升级TCP

基于上面我们提到的两个问题,有人提出来说:既然TCP存在这些问题,并且我们也知道这些问题的存在,甚至解决方案也不难想到,为什么不能对协议本身做一次升级,解决这些问题呢?

其实,这就涉及到一个”协议僵化“的问题。

这样讲,我们在互联网上浏览数据的时候,数据的传输过程其实是极其复杂的。

我们知道的,想要在家里使用网络有几个前提,首先我们要通过运行商开通网络,并且需要使用路由器,而路由器就是网络传输过程中的一个中间设备。

中间设备是指插入在数据终端和信号转换设备之间,完成调制前或解调后某些附加功能的辅助设备。例如集线器、交换机和无线接入点、路由器、安全解调器、通信服务器等都是中间设备。

在我们看不到的地方,这种中间设备还有很多很多,一个网络需要经过无数个中间设备的转发才能到达终端用户。

如果TCP协议需要升级,那么意味着需要这些中间设备都能支持新的特性,我们知道路由器我们可以重新换一个,但是其他的那些中间设备呢?尤其是那些比较大型的设备呢?更换起来的成本是巨大的。

而且,除了中间设备之外,操作系统也是一个重要的因素,因为TCP协议需要通过操作系统内核来实现,而操作系统的更新也是非常滞后的。

所以,这种问题就被称之为”中间设备僵化”,也是导致”协议僵化”的重要原因。这也是限制着TCP协议更新的一个重要原因。

所以,近些年来,由IETF标准化的许多TCP新特性都因缺乏广泛支持而没有得到广泛的部署或使用!

所以,摆在HTTP/3.0面前的就只有一条路,那就是放弃TCP。

于是,HTTP/3.0在基于UDP+迪菲赫尔曼算法(Diffie–Hellman)之上实现了QUIC协议(Quick UDP Internet Connections)。

QUIC协议有以下特点:

基于UDP的传输层协议:它使用UDP端口号来识别指定机器上的特定服务器。

可靠性:虽然UDP是不可靠传输协议,但是QUIC在UDP的基础上做了些改造,使得他提供了和TCP类似的可靠性。它提供了数据包重传、拥塞控制、调整传输节奏以及其他一些TCP中存在的特性。

 实现了无序、并发字节流:QUIC的单个数据流可以保证有序交付,但多个数据流之间可能乱序,这意味着单个数据流的传输是按序的,但是多个数据流中接收方收到的顺序可能与发送方的发送顺序不同!

快速握手:QUIC提供0-RTT和1-RTT的连接建立

使用TLS 1.3传输层安全协议:与更早的TLS版本相比,TLS 1.3有着很多优点,但使用它的最主要原因是其握手所花费的往返次数更低,从而能降低协议的延迟。

以上,我们介绍了很多QUIC的相比较于TCP的优点,可以说这种协议相比较于TCP确实要优秀一些。

因为他是基于UDP的,并没有改变UDP协议本身,只是做了一些增强,虽然可以避开中间设备僵化的问题,但是,在推广上面也不是完全没有问题的。

首先,很多企业、运营商和组织对53端口(DNS)以外的UDP流量会进行拦截或者限流,因为这些流量近来常被滥用于攻击。

特别是一些现有的UDP协议和实现易受放大攻击(amplification attack)威胁,攻击者可以控制无辜的主机向受害者投放发送大量的流量。

所以,基于UDP的QUIC协议的传输可能会受到屏蔽。

另外,因为UDP一直以来定位都是不可靠连接,所以有很多中间设备对于他的支持和优化程度并不高,所以,出现丢包的可能性还是有的。。。

但是不管怎么样,HTTP/3.0的时代一定会到来的,QUIC协议全面代替TCP的时代也会到来的,让我们拭目以待吧。​


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK