Roxy's Library

Back
12 min read
Chinese
计算机网络 /
传输层

新型传输层协议

计算机网络传输层 lecture 5
views | comments

本文内容基于 2025 秋季《计算机网络》课程讲述，如有差错，欢迎指正

传统的 TCP 和 UDP 协议在设计上都很极端：TCP 可靠但过于复杂，UDP 轻量但缺乏控制。 为了弥补这两者之间的空白，以及适应一些新需求，诞生了一系列新型传输层协议。 其中有些得到了实际的大规模应用，有些的话虽然思想很漂亮，但是并没有被成功的部署使用。

DCCP#

DCCP (Datagram Congestion Control Protocol) 是对于UDP 的一个改进，为UDP添加了拥塞控制机制

UDP 因为其不限制发送速率的特性，在流媒体传输等实时应用中得到了广泛应用，但是这个特征在网络状态不好的情况下会导致很大问题： 无法感知拥塞而导致丢包、高延迟、重传等开销，从而影响用户体验。因此与其花更大经历在重传等方面，不如直接对UDP的发送进行限制

协议特性#

为了实现拥塞控制，DCCP 在UDP 基础上添加了序列号和ACK，有以下三个特征

  1. 不可靠的数据报服务：像 UDP 一样，数据包可能丢失、乱序，不提供重传，不含流量控制
  2. 面向连接：像 TCP 一样，需要建立连接和断开连接
  3. 模块化的拥塞控制：应用可以根据需求选择不同的拥塞控制算法

连接建立#

要进行拥塞控制，需要有连接的概念，只有建立连接后，发送方和接收方才能进行协作，并调整发送速率

DCCP的两个主机之间实现了一个全双工连接，实际上相当于由两个方向的半连接组成（两个半连接的配置可以完全不一样），数据传输过程中要求双方要对数据进行反馈

DCCP连接示意图

  • 同一方向的ACK段和Data段可以合并成DataAck报文段

DCCP 建立连接的过程与 TCP 类似，使用三次握手；终止连接请求只能由服务器端发起，也是三次握手

DCCP连接建立与终止

报文格式#

DCCP的报文格式独立于UDP和TCP，整个报文格式比UDP是有了非常大的改变，通常认为它是跟TCP和UDP并列的传输层协议

DCCP报文最特殊的一点是有长短两种序列号，其余字段比较复杂，并不重要，因此这里不做介绍

拥塞控制#

目前DCCP 标准化文档中定义了两种拥塞控制算法（CCID 2和CCID 3），每个半连接可使用不同的算法

TCP-like Congestion Control（CCID2）：

  • 类似TCP的拥塞控制机制
  • 发送方维持一个发送窗口，允许连续地发包，直到没有可用的发送窗口
  • 接收方对收到的包回复ACK报文，包括一段时间内收到的所有包的序号（用于支持SACK机制）
  • 丢包或者ECN标记表示出现拥塞，此时发送端需要将发送窗口减半
  • 收到正常ACK，则发送窗口线性增长

TCP-Friendly Rate Control（CCID3）

  • TCP 友好型拥塞控制
  • 接收方计算丢包率，报告给发送方
  • 发送方根据丢包率计算发送速率，并根据发送速率发包

相比而言，CCID3可以更平滑地调节发包速率

MPTCP#

传统 TCP 仅支持单路径传输，即只能利用终端主机上的一个网络接口传输数据
然而现在具备多个网络接口的网络设备已经越来越普及（比如手机同时支持WiFi，蜂窝网，蓝牙），多路径传输更适合当前的网络环境

因此，MPTCP (Multipath TCP) 被提出，作为 TCP 的一个改进，允许在多个路径上同时传输数据，从而提高带宽利用率和传输的可靠性

MPTCP可在源主机和目的主机的多对网络接口间分别建立TCP连接，并将数据流分配到多条TCP连接上传输。 其仍然使用套接字接口，应用只需做一些配置即可使用。

连接管理#

  • 路径：本地主机与远程主机之间可用于建立连接的一对网络接口称为路径，使用四元组<本地IP地址，本地端口，远程IP地址，远程端口>表示
  • 子流：在单个路径上运行的 TCP 流称为子流

建立连接时，MPTCP 会先建立初始化一条MPTCP连接（与建立常规TCP连接的过程相似），然后将MPTCP的其它子流附加到已经存在的MPTCP连接上

初始化连接建立：

  • 使用与 TCP 相同的三次握手过程建立连接，启用了MP_CAPBLE字段
  • 在握手过程中，双方交换密钥，用于后续的连接管理使用

附加子流：

  • 附加子流需要启用MP_JOIN字段
  • 该子流通过一些验证信息（如密钥和令牌）来关联到已有的 MPTCP 连接上

这中间有复杂的验证过程，这里不做赘述

数据调度与拥塞控制#

为了减少乱序问题的影响，MPTCP会根据拥塞窗口大小及路径延迟，将数据按比例分配给各个子流， 尽力保证数据包按序到达接收端，降低数据乱序到达对网络性能产生的不利影响

MPTCP 不能简单地在每条路径上运行独立的 TCP 拥塞控制，否则会产生不公平（一个应用占用多条TCP的带宽）

  • 假设MPTCP的两个子流与一个常规TCP流共享一个网络瓶颈，则MPTCP两个子流获得的带宽应为瓶颈带宽的1/2，而不是2/3
  • 实际上MPTCP会限制各个子流窗口增长速度的总和，不超过单路径TCP连接的窗口增长速度，保证吞吐量相当

现在MPTCP已经被广泛应用于移动设备和数据中心等场景（比如如果 Wi-Fi 不可用或不可靠，MPTCP 立即在后台切换到蜂窝移动数据网络）

QUIC#

TCP的问题#

  1. TCP 实现在操作系统内核中，应用无法对协议进行修改；且由于操作系统迭代慢，协议更新非常缓慢，难以适应新需求
  2. TCP体系握手时延大
    • TLS(传输层安全性协议)+TCP的体系握手时延很大，影响用户体验
  3. TCP多流复用存在队头阻塞问题
    • 出现丢包时，后面的数据需要等丢失的包重传完成才能使用，这就导致了队头阻塞

QUIC 的核心特性#

QUIC 基于 UDP 实现，运行在用户态，替代TCP、TLS和部分HTTP的功能，有着模块化的拥塞控制算法

QUIC 改进了加密握手，在一个RTT内就可完成连接建立和加密协商，减少了时延

QUIC协议栈

多流复用优化：

QUIC 内部实现了多流（Stream）复用，每个流有独立的序列号和流控；流 A 的丢包只会阻塞流 A，不会影响流 B。

  • 具体实现：数据包由多个数据帧组成，每个数据帧通过 Stream ID 字段，标识属于哪个流

改进的确认机制：

QUIC 分离确认接收与向上层交付数据，分别使用Packet Number和Offset：

  • Packet Number：ACK中确认packet接收
  • Offset：判断数据重复与顺序

QUIC的packet number单调递增，对于重传包也会递增packet number；每个packet number只会出现一次，ACK没有歧义； 避免了TCP中由于分不清重传的数据包的ACK和原数据包的ACK，影响后续操作，如测量RTT的大小等问题

与此同时，QUIC接收端记录收到包与发出ACK之间的时延，并发馈给发送端，方便发送端更准确地测量RTT

连接迁移优化：

不再使用 <源IP, 源端口, 目的IP, 目的端口> 四元组标识连接，而使用 Connection ID (CID) 标识连接。 当手机从 WiFi 切换到移动网络，IP 变了，TCP会断连，需要应用进行处理；但QUIC 可借助 CID 快速恢复

QUIC数据报格式

安全性：

除了极少部分头部（如 Flags），几乎所有报文内容（包括头部的大部分）都是加密的，中间设备无法窥探，也无法干预，保障了隐私

新型传输层协议
https://astro-pure.js.org/blog/csnet_trans_chap5
Author GreyRat
Published at December 12, 2025
Copyright CC BY-NC-SA 4.0
Buy me a cup of coffee ☕.

网络层基本概念、路由器

新型拥塞控制
Comment seems to stuck. Try to refresh?✨