标签归档:udp

HTTP / 3用UDP替换TCP以提高网络速度,可靠性

为站点和服务获得HTTP / 2的性能和安全性优势意味着进行体系结构更改,因为它颠覆了用于提高网站性能的分片等原则; 这可能就是为什么只有大约35%的网站目前使用HTTP / 2。

HTTP / 3加倍,提供非常相似的功能,但用UDP替换TCP。这一次可能需要对网络基础设施进行更根本的改变,以便利用比较差的连接和移动网络更好的性能,但对于大多数开发人员来说,这种改变将是透明的。

HTTP / 3是该协议的第三个主要版本,它包括TLS 1.3和一种称为QUIC(Quick UDP Internet Connection)的新传输协议; 根据最初由Google设计的2013协议,现在有多个贡献者和公司通过互联网工程任务组(IETF)参与其中

不可靠是一个机会

放弃HTTP一直用于UDP的TCP连接并不像看起来那么奇怪。U有时会扩展为“不可靠”而不是用户数据报协议,因为它不保证消息传递或数据包顺序。但是对于今天的网络,这实际上是一个提高HTTP / 2引入的多路复用连接性能的机会。“凭借HTTP / 3,我们将在同一个旧的不可靠互联网之上构建一个新的可靠协议,” Cloudflare首席技术官John Graham-Cumming告诉New Stack。

HTTP / 2通过在同一连接上发送多个HTTP请求,允许应用程序同时处理请求,从而更好地利用网络带宽。但只有在网络运行良好时才能实现这些收益。“你可以最大限度地提高吞吐量和带宽,因为TCP可以达到它可以达到的最大速度,并且所有并行连接都能以最快的速度运行,”Graham-Cumming说。

这很好,直到网络连接出现打嗝,例如网络拥塞或移动网络上从一个小区移动到另一个小区并且数据包丢失。“TCP保证发送数据包的顺序是应用程序接收的顺序 – 所以如果你错过了,那么一切都必须停止,直到特定数据包被重新传输。如果将多个请求复用到单个TCP连接上,则所有这些请求都必须停止并等待,即使丢失的数据包可能只影响其中一个。

Graham-Cumming解释说,这种“线路阻塞问题”是TCP固有的问题,使用UDP通过允许应用程序控制数据包的重传来修复它。“它可以说’数据包丢失,但它只影响这一个数据流,而其他数据流可以继续运行’。”这使得QUIC 在恶劣的网络条件下更加强大

HTTP / 3的连接迁移提议可以扩展在不同网络之间移动的稳健性,例如从Wi-Fi到移动宽带,这通常会因为IP地址的变化而破坏网络连接。“通过此提议,您和服务器之间的标识符将不是IP地址,而是协议本身内的标识符。这样您就可以在新网络上自动重启整个连接,这样您就可以无缝地从Wi-Fi转移到移动连接。原始互联网的一些假设是,存在相当固定的连接,我们现在正在进入一个非常移动的异构世界。“

Graham-Cumming解释说,HTTP / 3还直接集成了TLS,QUIC对数据包传输的额外控制也具有优势。“当事情通过互联网发送时,它们会被分解成数据包; 在TLS中,有一个传输数据缓冲区的概念。如果你想要真正有效率,你想要把所有这些事情排好; 这是一个请求,我将对它进行加密并通过互联网进行传输,以便一次性收到所有这些请求,并且不会分成较小的数据包,其中一些不会被延迟。如果您控制所有级别,如果您只是假设互联网是一种不可靠的发送数据包的方式,那么您可以控制发送内容的顺序,您可以控制加密它们的方式以及这些加密块如何传输。“

与HTTP服务器的初始连接将更快,因为HTTP / 3取出了通常需要建立连接的往返之一安全解释说,Mozilla首席工程师Martin Thomson是QUIC规范的编辑之一。

“使用TCP和TLS,连接设置以TCP握手开始:客户端发送SYN,服务器响应SYN + ACK,客户端使用ACK完成。然后在发送任何请求之前有一个TLS握手 – 它需要另一个类似的三个消息交换。QUIC在大多数情况下将其压缩到单个交换。一个关键特性是0-RTT,允许客户端立即发送请求; 这是TCP和TLS的一个选项,但你仍然需要等待TCP握手完成。“

默认安全

集成TLS还可以提高安全性,因为身份验证和加密是由网络协议提供的,而不是像TLS这样的高级协议提供的 – 而且在HTTP / 3中内置了TLS,使用它也不是可选的。Graham-Cumming指出:“业界正试图在默认情况下保证一切安全。” 当站点使用HTTPS时,浏览器现在会在站点没有加密连接时向您发出警告,而不是显示锁定HTTP / 3和QUIC是这个方向的另一个举措。

“更多的QUIC是加密的,”汤姆森解释道。这包括攻击者可能尝试使用的元数据。“除了一些有助于将数据包识别为QUIC数据包的比特之外,未加密的QUIC数据包的唯一部分是连接的不透明标识符。这包括TCP和TLS无法保护的内容,例如确认(’我从你那里得到5个字节’)。“

Thomson还认为加密实际上将简化部署QUIC。将新协议部署到需要更新的防火墙,路由器,NAT和其他网络设备上的复杂性阻碍了在浏览器中  创建新的,更有效的传输协议和延迟采用TLS 1.3的努力“这是部署QUIC的可能性的一部分。互联网往往会干扰新的协议,加密将保护QUIC免受干扰。“

他坚持认为,这是UDP是一个不错的选择的另一个原因。“新的协议不能直接部署在IP之上,如TCP或UDP,因为这需要更新的互联网。考虑更换或升级每个想要使用此新协议的房屋中的每个路由器的前景。UDP在这种情况下是理想的,因为它做得很少。它非常轻巧,因此我们可以在顶部构建所有必要的部件。UDP的主要缺点是已经显示阻止或降级UDP的少量网络。在极少数情况下,我们有HTTP / 2可以依靠。“

当用户访问站点时,他们的初始连接将通过HTTP或HTTP / 2,服务器将提供HTTP / 3作为替代; 了解提供该连接的标头的浏览器将记住它以供下次访问,但较旧的浏览器和设备将继续使用旧协议。格雷厄姆 – 卡明预测说:“我们预计HTTP / 2和1.1将会存在很长时间。”

网络变化

HTTP / 3可能有它的名字,但它仍在开发中; Graham-Cumming表示,情况稳定前几个月。尽管有一些HTTP / 3端点可用于测试Cloudflare等服务,但Facebook和Litespeed 已经证明了  2018年11月的HTTP / 3实现之间的互操作性,浏览器和Web服务器还没有支持HTTP / 3(Chrome的实验支持除外)对于谷歌的原始版本的QUIC)。

一旦他们这样做,服务提供商和托管公司将遵循,但可能需要更新旧的网络设备。“对于UDP的NAT遍历并不像TCP那样发达,一些家庭路由设备会假设UDP用于流媒体视频,而不是网络,”Graham-Cumming说。

Thomson说,如果你托管自己的网络服务器,你还有更多工作要做。“服务器管理员会发现QUIC需要的不仅仅是软件升级。启用UDP将需要网络和负载平衡基础架构的新支持。“网络运营商可能需要研究可以在软件中实现的更智能的第4层负载平衡解决方案,如Facebook的Katran项目

但由于HTTP / 3旨在解决HTTP / 2的问题,因此对HTTP / 2进行的优化(如域分片的更改)将在可用时自动应用。如果是这样的话,Graham-Cumming希望它能够推动网络的发展。“我们希望的是更快的网络下载和API。它应该使互联网更加可靠和快速,并且希望对于开发者来说,我们可以获得更丰富的API和Web应用程序,因为我们可以通过这种新协议更多地依赖互联网。

https://thenewstack.io/http-3-replaces-tcp-with-udp-to-boost-network-speed-reliability/

UDP Jitter测试

UDP Jitter测试是以UDP报文为承载,通过记录在报文中的时间戳信息来统计时延、抖动、单向丢包的一种测试方法。Jitter(抖动时间)是指相邻两个报文的接收时间间隔减去这两个报文的发送时间间隔的差值。

图1 UDP Jitter测试原理图 

图1所示,UDP Jitter测试的过程如下:

  1. 源端(ME60A)向目的端(ME60B)发送数据包。发送时,在报文中记录时间戳t1。

  2. 目的端(ME60B)收到报文后,在报文中记录时间戳t1’。

  3. 目的端(ME60B)将收到的报文发回到源端,在报文中记录时间戳t2’。

  4. 源端(ME60A)收到报文,在报文中记录时间戳t2。

从源端接收到的信息中计算出:

  • 数据包从源端到目的端和从目的端到源端的最大抖动时间、最小抖动时间及平均抖动时间。

  • 从目的端到源端或从源端到目的端的最大单向延时。

从而清晰的反映出网络状况。

双向时延:RTT=(t2-t1)-(t2′- t1’)

当双向时延>用户配置的超时时间时,表示网络不畅通。此时,报文将被统计为丢包。

丢包率=丢包个数/发送报文总数

UDP Jitter测试可以测试2个方向的抖动(Jitter)值:

  • SD(源到目的)方向:Jitter=(t3’-t1’)-(t3-t1)

    计算出来的结果,如果大于0,则统计为正向抖动值;如果小于0,则统计为负向抖动值。

  • DS(目的到源)方向:Jitter=(t4-t2)-(t4’-t2’)

    计算出来的结果,如果大于0,则统计为正向抖动值;如果小于0,则统计为负向抖动值。

UDP Jitter测试例还支持统计单向丢包。

图2 UDP Jitter测试统计单向丢包原理图 

图2所示,在Server(ME60B)端会统计收到报文的个数,当Client(ME60A)端口收到的报文个数与从报文中获取的Server(ME60B)端收到报文的个数不同时,会自动发起单向丢包查询,获取Server(ME60B)端接收报文的个数:

Packet Loss SD是源到目的的丢包

Packet Loss SD=Client(ME60A)端发送的报文个数-Server(ME60B)接收报文个数

Packet Loss DS是目的到源的丢包

Packet Loss DS=Server(ME60B)接收报文的个数-Client(ME60A)接收报文的个数

Client(ME60A)端收不到查询报文时,会将丢包记录到Packet Loss Unknown。