文章

弱网环境下的数据传输

Q: 弱网环境下网络数据传输选择什么

  1. QUIC(Quick UDP Internet Connections)协议

    • 背景和特点:它是谷歌开发的一种基于 UDP 的传输层协议。QUIC 在弱网环境下表现出色,因为它具有快速连接建立的特性。与传统的 TCP 协议相比,QUIC 通过使用 UDP,减少了连接建立过程中的延迟。例如,在 TCP 建立连接时,需要进行三次握手,而 QUIC 可以在第一次通信时就携带数据,从而节省了往返时间。

    • 工作原理:它在应用层模拟了 TCP 的可靠性功能,如拥塞控制、重传机制等。并且,QUIC 协议的头部信息经过优化,采用了变长的头部结构,减少了不必要的网络开销。此外,QUIC 还支持多路复用,一个 QUIC 连接可以同时处理多个数据流,这样可以避免队头阻塞(Head - of - Line Blocking)问题,在弱网环境下,当一个数据流出现丢包或延迟时,不会影响其他数据流的传输。

  2. HTTP/3 协议

    • 与 QUIC 的关系:HTTP/3 是基于 QUIC 协议构建的超文本传输协议。它继承了 QUIC 的许多优点,在弱网环境中能够有效提升网络传输性能。

    • 性能优势:由于其底层是 QUIC,所以同样具有快速连接建立和多路复用的特性。在网页浏览场景下,当需要同时加载多个资源(如图片、脚本、样式表等)时,HTTP/3 可以利用多路复用快速地获取这些资源,减少页面加载时间。例如,在移动网络等弱网环境中,能够使网页内容更快地呈现给用户。

  3. MQTT(Message Queuing Telemetry Transport)协议

    • 应用场景和特点:这是一种轻量级的消息传输协议,专为物联网设备设计。在弱网环境下,它的优势明显。例如,在一些网络带宽有限、信号不稳定的物联网应用场景中,如远程传感器数据传输,MQTT 通过发布 / 订阅模式来传递消息。它的协议头非常小,最小的固定头部只有 2 个字节,这使得它在网络传输中占用较少的带宽。

    • 工作机制:它采用异步通信方式,设备可以在网络条件允许时发送消息,消息中间件会负责存储和转发这些消息。例如,一个位于偏远山区、网络信号弱的气象监测传感器,通过 MQTT 协议,可以在网络连接恢复瞬间将之前采集的数据发送出去,而不需要一直保持稳定连接等待发送。

  4. CoAP(Constrained Application Protocol)协议

    • 适用范围和特点:这是一种用于物联网受限网络中的应用层协议。它也是基于 UDP 协议,适用于低功耗、低带宽的网络环境,如智能家庭设备之间的通信。在弱网环境下,CoAP 采用类似于 HTTP 的请求 - 响应模式,但是更加轻量级。

    • 性能优势:它的消息格式简洁,头部信息和传输开销较小。例如,在智能家居系统中,当通过弱网连接控制智能灯泡的开关时,CoAP 协议可以快速地传输控制指令,而不会占用过多的网络资源,减少了网络拥塞的可能性。

其中MQTT是基于TCP的,但是其特点是协议占用带宽少。

TCP & UDP

TCP(Transmission Control Protocol,传输控制协议)和 UDP(User Datagram Protocol,用户数据报协议)是两种常见的传输层协议,它们有以下区别:

  1. 连接方式

    • TCP:是一种面向连接的协议。在数据传输之前,通信双方必须先建立连接,通过三次握手的过程来确保连接的可靠性。这就好比在打电话之前,先拨通号码,等待对方接听,双方确认可以通信后才开始对话。例如,当浏览器访问一个网页时,它和服务器之间先建立 TCP 连接,然后才能传输数据。

    • UDP:是无连接协议。发送方可以随时发送数据报,不需要事先与接收方建立连接。这类似于发送短信,发送方不需要确认接收方是否准备好接收就可以发送消息。在一些实时性要求高的应用场景中,如视频直播、在线游戏,UDP 的无连接特性使得数据可以快速发送出去。

  2. 可靠性

    • TCP:提供可靠的数据传输服务。它通过序列号、确认应答、重传机制等来保证数据的完整性和顺序性。如果发送的数据在传输过程中丢失或损坏,接收方没有收到正确的数据,发送方会在一定时间内重传丢失的数据。例如,在文件传输过程中,TCP 会确保文件的每一个字节都能正确地从发送端传输到接收端。

    • UDP:不保证数据传输的可靠性。数据报在网络中传输时可能会丢失、重复或者乱序,UDP 不会对这些情况进行额外的处理。接收方接收到的数据报可能是不完整的或者顺序错乱的,应用程序需要自己处理这些问题。比如在一些对实时性要求极高的情况下,如实时视频会议,少量的数据丢失可能比延迟更能被接受,所以可以使用 UDP。

  3. 传输效率

    • TCP:由于其可靠性机制,需要进行大量的额外操作,如建立连接、维护连接状态、确认应答和重传等,这些操作会增加数据传输的开销,降低传输效率。在网络带宽有限或者对实时性要求高的场景下,TCP 的这些额外开销可能会影响性能。

    • UDP:没有复杂的连接建立和维护过程,也没有重传等机制,数据报的格式简单,头部开销小,所以传输效率相对较高。这使得 UDP 在一些对实时性要求高、对数据丢失不太敏感的场景下,能够快速地将数据发送出去。

  4. 数据顺序

    • TCP:保证数据按照发送的顺序到达接收端。它通过序列号对数据进行编号,接收方按照序列号的顺序将数据组装起来,确保数据的顺序性。这种特性对于文件传输、邮件传输等应用非常重要,因为这些应用需要保证数据的完整性和正确的顺序。

    • UDP:不保证数据的顺序,数据报在网络中传输的路径可能不同,到达接收端的时间和顺序也可能不同。应用程序如果需要按照特定的顺序处理数据,需要自己对数据进行排序和处理。

  5. 应用场景

    • TCP:适用于对可靠性要求高、数据传输完整性和顺序性要求严格的应用场景,如文件传输(FTP)、电子邮件(SMTP、POP3)、网页浏览(HTTP/HTTPS)等。这些应用需要确保数据准确无误地传输,即使牺牲一定的传输速度。

    • UDP:适合于对实时性要求高、对数据丢失有一定容忍度的场景,如视频直播、音频通话、在线游戏等。这些应用更关注数据能够快速地发送和接收,而不是数据的绝对完整性。

QUIC

QUIC(Quick UDP Internet Connections)是一种基于 UDP 的低时延互联网传输层协议1。以下是关于 QUIC 的详细介绍:

  1. 发展历程

    • 最初由 Google 的 Jim Roskind 设计,2012 年实现并部署,2013 年公开发布。

    • 2015 年 6 月,QUIC 规范的互联网草案提交给 IETF 进行标准化。

    • 2016 年,成立了 QUIC 工作组。

    • 2018 年 10 月,IETF 的 HTTP 工作组和 QUIC 工作组共同决定将 QUIC 上的 HTTP 映射称为 "HTTP/3"。

    • 2021 年 5 月,IETF 正式发布 QUIC 的标准化版本 RFC9000。

  2. 主要目标和优势1

    • 减少连接延迟:在连接建立方面,相比传统的 TCP 协议需要三次握手,QUIC 可以更快地建立连接,尤其对于短连接场景优势明显。例如在移动端的网络应用中,用户频繁切换页面或发起新的网络请求,QUIC 能够快速响应,减少等待时间。

    • 提高网络应用性能:QUIC 支持多路复用连接,允许多个数据流独立到达所有端点,避免了 TCP 协议中因单个数据包丢失而导致的队头阻塞问题,极大地提高了数据传输的效率。

    • 增强安全性:在设计之初就考虑了安全因素,将传输层安全性(TLS)的功能集成到协议中,在连接建立时就进行加密协商,为数据传输提供了可靠的安全保障。

    • 灵活的拥塞控制:拥塞控制算法移到了两个端点的用户空间,而不是内核空间,这使得应用程序可以更灵活地选择和调整拥塞控制算法,以适应不同的网络环境。并且它支持多种拥塞控制算法,如 CUBIC、BBR 等,可以根据网络状况进行切换。

    • 连接迁移:在网络切换场景中,例如用户从 Wi-Fi 热点切换到移动网络时,QUIC 可以通过连接标识符快速重新建立连接,而无需像 TCP 那样经历冗长的超时和重新连接过程,保持了连接的稳定性和连续性。

  3. 工作原理

    • 基于 UDP 传输:QUIC 选择 UDP 作为基础传输协议,避免了 TCP 连接建立的复杂性和延迟。UDP 是一种无连接的协议,数据报的发送不需要事先建立连接,这使得 QUIC 可以更快地开始数据传输。

    • 握手过程:在连接建立时,QUIC 进行快速的握手协商,客户端向服务器发送请求,服务器返回包含加密数据等信息的响应,完成密钥协商和初始参数设置。在后续的连接中,如果之前已经建立过连接,还可以实现 0-RTT(Round-Trip Time)连接,即无需额外的往返时间就能发送数据,进一步降低了延迟。

    • 数据传输和重传:QUIC 中的每个数据流都是单独控制的,如果一个流中的数据包丢失,协议栈可以在不影响其他流的情况下进行重传。同时,它还支持前向纠错(FEC)技术,通过发送冗余数据来提高数据传输的可靠性,减少重传的次数。

  4. 应用场景

    • 网页浏览:能够加快网页的加载速度,提升用户的浏览体验。特别是对于包含大量图片、视频等多媒体内容的网页,QUIC 的多路复用和高效传输特性可以更快地将数据传输到用户端2

    • 视频直播和在线游戏:这些应用对实时性要求极高,QUIC 的低延迟和可靠传输特性可以确保视频的流畅播放和游戏的实时交互,减少卡顿和延迟。

    • 移动应用:在移动网络环境下,网络状况复杂多变,QUIC 的连接迁移和灵活的拥塞控制功能可以更好地适应这种环境,为移动应用提供稳定、高效的网络连接。

HTTP1 HTTP1.1 HTTP2.0 HTTP3.0

协议版本

主要区别

HTTP1.0

- 每次请求 - 响应都需要建立一个新的 TCP 连接,效率较低。
- 没有 Host 头字段,无法区分同一 IP 地址下的不同主机。
- 缓存机制相对简单,主要通过 Expires 和 Last - Modified 等字段来控制。

HTTP1.1

- 支持持久连接,一个 TCP 连接可以用于多次请求 - 响应,减少了建立连接的开销。
- 引入 Host 头字段,使得在同一 IP 地址上可以区分不同的主机。
- 缓存策略更加丰富,新增了 Cache - Control 等字段,能够更灵活地控制缓存。
- 支持管道化(Pipelining),可以在同一个 TCP 连接里连续发送多个请求,不过管道化的响应需要按照请求的顺序返回,容易出现队头阻塞(Head - of - Line Blocking)。

HTTP2.0

- 基于二进制分帧层(Binary Framing Layer),将 HTTP 消息分解为更小的帧进行传输,提高了传输效率。
- 采用多路复用(Multiplexing)技术,一个连接可以同时处理多个请求和响应,避免了 HTTP1.1 管道化中容易出现的队头阻塞问题,多个请求的响应可以乱序返回。
- 支持头部压缩(Header Compression),通过 HPACK 算法对请求和响应头部进行压缩,减少了头部数据量,节省了带宽。
- 服务器推送(Server Push),服务器可以主动向客户端推送资源,例如,在客户端请求 HTML 页面时,服务器可以预先推送该页面可能需要的 CSS、JavaScript 等文件,加快资源加载速度。

HTTP3.0

- 传输层协议从 TCP 换成了 QUIC,利用 QUIC 的快速连接建立、多路复用、0 - RTT(Round - Trip Time)连接等特性,进一步减少延迟。
- 继承了 HTTP2.0 的多路复用、头部压缩和服务器推送等功能,在弱网和移动环境下性能更优。
- 由于 QUIC 是基于 UDP 的协议,在网络切换(如从 Wi - Fi 切换到移动数据)场景下,能够更好地保持连接,避免重新建立连接导致的延迟。

当前我们开发的是HTTP几?如何升级到最新

  1. 默认支持 HTTP/1.1

    • Spring Boot Web 应用在默认情况下主要使用 HTTP/1.1。因为 Java 的基础网络库(如java.net.Socket)和大多数 Web 容器(如 Tomcat、Jetty 等,它们是 Spring Boot 默认支持的 Web 服务器)对 HTTP/1.1 有很好的支持。

    • HTTP/1.1 的特点如持久连接(keep - alive)在 Spring Boot Web 应用中得到利用。例如,在一个简单的 RESTful API 服务中,当客户端多次请求不同的资源端点时,通过 HTTP/1.1 的持久连接,不需要为每次请求重新建立 TCP 连接,从而减少了连接建立的开销,提高了性能。

  2. 可以支持 HTTP/2.0

    • 配置方式:如果要使用 HTTP/2.0,需要在支持 HTTP/2.0 的 Web 服务器(如 Tomcat 9 以上版本、Jetty 9 以上版本等)上进行配置。以 Tomcat 为例,在 Spring Boot 应用中,需要在application.propertiesapplication.yml文件中配置服务器的协议为 HTTP/2.0 相关的属性。例如,在application.properties中可以设置server.http2.enabled = true(具体配置可能因版本和服务器而略有不同)。

    • 性能提升:当应用支持 HTTP/2.0 后,会带来性能上的提升。HTTP/2.0 的二进制分帧和多路复用技术可以更好地处理多个并发请求。比如,在一个包含大量图片、CSS 和 JavaScript 文件的 Web 页面加载场景中,HTTP/2.0 可以同时发送多个请求,这些请求的响应可以乱序返回,并且不会出现 HTTP/1.1 管道化中容易出现的队头阻塞问题,从而大大加快了页面的加载速度。

  3. 对 HTTP/3.0 的支持

    • 目前 Java 生态系统对 HTTP/3.0 的支持仍在发展中。Spring Boot 本身没有原生的 HTTP/3.0 支持,但随着技术的发展和相关库的成熟,未来有望通过集成支持 QUIC 协议的服务器和客户端库来实现 HTTP/3.0 功能。例如,一些第三方的 Java 库正在探索如何将 QUIC 和 HTTP/3.0 集成到 Spring Boot 应用中,以利用 HTTP/3.0 基于 QUIC 的快速连接建立、在弱网环境下更好的性能等优势。

采用Nginx升级到HTTP3

详情baidu、google。了解到配置实现不是很复杂。