Page 314 - Web性能权威指南

总之，SCTP 会给每个数据块增加 28 字节开销：12 字节的公共首部和 16
字节的数据块首部，然后才是应用净荷。

SCTP 怎么协商关联的初始参数呢？每个 SCTP 连接都需要经历与 TCP 类似的握手
过程！类似地，SCTP 也实现了 TCP 友好的流量和拥塞控制机制：两个协议使用相
同的初始拥塞窗口大小，实现了与拥塞预防阶段类似的增减拥塞窗口的逻辑。

要回顾一下 TCP 握手延迟、慢启动和流量控制，请参考第 2 章。WebRTC
中使用的 SCTP 握手以及拥塞和流量控制算法不一样，但目的相同，而且
在性能方面的开销也类似。

到现在为止，差不多已经能够满足 WebRTC 的所有要求了。然而可惜的是，就算有
了这么多功能，还是欠缺几个关键的特性。

(1) 基础的 SCTP 标准（RFC 4960）提供了乱序交付消息的机制，但不支持通过配
置实现可靠性。为解决这个问题，WebRTC 客户端必须另外求助“Partial Reliability
Extension”（RFC 3758），也就是对 SCTP 的扩展，为的是支持发信端实现自定义的
交付保证，而这个可靠性是 DataChannel 的关键特性。
(2) SCTP 不支持对流的优先级安排，协议没有规定用于保存优先级的字段。因此，
这个功能必须由更高层协议来实现。
简言之，SCTP 与 TCP 提供类似服务，因为它运行于 UDP 之上，而且由 WebRTC
客户端实现，所以它的 API 必须更强大：有序和乱序交付、部分可靠性、面向消息
的 API，等等。同时，SCTP 也有握手延迟、慢启动以及流量和拥塞控制，这些都
是在考量 DataChannel API 性能时不能忽略的关键因素。

“裸 SCTP”的挑战
使用面向消息的 API 让 SCTP 避免了 TCP 这种面向流的协议无法避免的队首阻塞
问题（参见 2.4 节“队首阻塞”）。类似地，同样的机制也让 SCTP 得以按配置交
付：有序和乱序、可靠和部分可靠。
既然如此，为什么不直接在 IP 协议上运行 SCTP，然后通过它实现所有数据交换
呢？这样做就不需要 UDP 了，而且也能解决将来通过 TCP 交付 HTTP 2.0 的问题
（参见 12.3.5 节中的“丢包、高 RTT 连接和 HTTP 2.0 性能”）。事实上，SCTP 可
以解决 HTTP 2.0 解决的大多数问题，也能让我们大幅度简化 HTTP 协议！
只可惜现有的路由器和 NAT 设备不能正确处理 SCTP，因而几乎不可能在公共互
联网上将 SCTP 用作“裸传输协议”。WebRTC 这才在 UDP 和 DTLS 之上架设起
SCTP，而且在 WebRTC 客户端中，SCTP 是在“用户空间”中实现的。

304 ｜ 第 18 章