Page 440 - 《软件学报》2024年第4期
P. 440

2018                                                       软件学报  2024  年第  35  卷第  4  期


                 化应用, 还需要寻求对应的最优的确认机制.
                    因此, 传输控制中的确认机制值得进一步广泛深入的研究, 未来研究方向可以从以下几个方面展开.
                    (1) 确认机制的兼容性
                    不同的网络环境, 可能需要不同的确认机制; 同一个连接内, 不同的时刻也可能需要不同的确认机制. 因此, 需
                 要设计协商机制, 使数据收发双方之间实现兼容. 在经典                 TCP  中, 支持通过选项区域扩展, 实现确认机制的协商.
                 例如, 可以在   TCP  选项区域新增加    TACK-Permitted 选项字段. 在建连过程中, TCP    的  SYN  报文携带  TACK-Permitted
                 选项用于指明     SYN  报文的发送方支持      TACK  机制  [30] . 在  QUIC  中, 通过传输参数在收发双方之间进行参数的协
                 商. 因此, 可以复用传输参数在收发双方之间进行             ACK  机制的协商. 具体地, 定义一个新的传输参数字段            tack-support.
                 发送方在帧中携带       tack-support, 表明发送方支持  TACK  机制, 接收方接收到这个携带        tack-support 字段的帧后, 如
                 果支持, 则在后续的传输过程中, 采用          TACK  机制.
                    (2) 确认机制的模块化
                    根据确认机制“类型-触发条件-信息”三要素, 确认机制的模块化必须实现                      ACK  类型识别、ACK     频率更新和
                 ACK  信息解析等功能的模块化. 在经典          TCP  中, 支持通过选项区域扩展指示        ACK  类型. 例如, 可以在   TCP  选项区
                 域新增加   ACK-Type 选项字段. 当    ACK-Type 值为  0x01  时表示  TACK  报文, 0x02–0xff 表示不同类型的   IACK  报
                 文  [30] . 相比  TCP, 在  QUIC  中进行扩展更加容易, 因为  QUIC  天然地支持通过帧的类型直接指示不同的            ACK  类型.
                 同时, Iyengar 等人  [35] 提出在  QUIC  中新增  ACK-FREQUENCY 帧类型. 数据发送方可以通过向接收方发送            ACK-
                 FREQUENCY 帧, 通知接收方更新       ACK  频率. 相比  ACK  类型识别和    ACK  频率更新, ACK   信息解析的模块化工
                 作目前进展缓慢, 有待进一步地研究和完善.
                    (3) 统一的确认机制测试平台
                    不同的确认机制对传输控制的影响各不相同, 给定一种网络环境和应用需求, 要评价哪种机制最优, 则需要将
                 不同的机制放在一起对比测试. 另一方面, 按需确认追求发送的每个                     ACK  报文都正好是传输控制所必需的, 如何
                 评价每个   ACK  报文产生的作用, 也需要设计对应的评判标准. 当前, 业界存在一些传输协议测试平台, 如                       Pantheon .
                                                                                                      [45]
                 然而, 这些平台仅支持将整个传输协议作为测试对象, 无法通过控制变量的方式将确认机制作为独立的测试对象
                 进行评估. 这种情况下, 传输协议中除确认机制以外的其他所有模块可能不同, 违背了控制变量法, 从而引入评估
                 偏差. 因此, 一个新的研究方向, 是开发一套统一的确认机制测试平台, 研发人员只需要提供修改确认机制三要素
                 中的部分或者全部算法, 则可以进行统一评估, 综合对比各种机制在不同参数下的性能, 从而为不同的网络条件和
                 应用需求寻求最优的确认机制提供依据.
                    (4) 面向  QoE  的确认机制
                    当前针对确认机制的研究和设计, 都是建立在网络数据传输的速率、时延、丢包等基本的性能指标上的. 然
                 而, 用户通常愿意为蓝光、4K、VR 体验买单, 但不一定愿意为 10 Mb/s、20 Mb/s 和                100 Mb/s 的数字买单. 用户
                 体验  (QoE) 是主观感受, 并不能简单地用传输速率来评价, 但用户体验也一定是可定义、可衡量、可管理的. 因
                 此, 针对  QoE  设计按需的确认机制, 是未来的一个重要研究方向.
                    (5) 基于  AI 的确认机制
                    人工智能    (AI) 具有强大的自适应性和自学习能力, 可以为一些复杂网络条件情况下的决策提供解决方案, 近
                 年来引起了业界广泛关注. 当前          AI 和传输控制相结合, 主要集中在拥塞控制算法层面, 如                Remy [20]  、Indigo [21]  、
                 PCC [46]  和  PCC Vivace [47]  等. 然而, 基于  AI 的确认机制方面的研究则相对较少. 未来的一个研究方向, 可以是将
                 AI 和确认机制的设计相结合, 需要根据网络条件的动态变化, 自适应地在                     ACK  类型、ACK    频率和  ACK  携带的
                 信息等层面进行实时决策, 从而有可能真正意义上地实现传输控制过程中的按需确认.
                  6   结 论

                    数据爆炸性增长, 新型应用持续涌现, 分布式系统之间的数据传输控制, 对数据中心网络、广域网和无线局域
                 网等提出了更高的差异化需求, 同时, 多种网络特征的差异性也为设计专用的、高效的传输控制确认机制, 提供了
   435   436   437   438   439   440   441   442   443   444   445