RFC-0109：快速 UDP 套接字

RFC-0109：快速 UDP 套接字
状态已接受
区域
  • Netstack
说明

使用 zircon 套接字实现网络 UDP 套接字数据传输。
Gerrit 更改
作者
审核人
提交日期（年-月-日）2021-06-17
审核日期（年-月-日）2021-06-25

修改此 RFC

修改 RFC 元数据

摘要

使用 zircon 套接字实现网络数据报套接字数据传输。 使用客户端缓存的网络状态实现客户端参数验证。

设计初衷

提高数据报套接字吞吐量并降低 CPU 利用率。

在 https://fxbug.dev/42094952 之前，数据报网络套接字是使用 zircon 套接字实现的；客户端会使用 zx_socket_write 发送数据，使用 zx_socket_read 接收数据。使用了最小协议来传输元数据（例如调用应用提供的目标地址）。

由于在某些情况下无法向调用方提供错误信号，因此我们放弃了这种方法。假设某个应用希望将载荷发送到网络堆栈没有路由的远程位置；为了符合以 Linux 为目标平台的第三方软件的预期，实现必须返回一个错误，以指示未代表调用方执行任何操作。

当前实现在 fuchsia.posix.socket/DatagramSocket.{Recv,Send}Msg 中定义。由于需要支持 FIDL 响应，因此发送和接收数据都需要多次上下文切换。忽略 FIDL 序列化：

+-----------------------------+-------------------------+
| Client                      | Netstack                |
+-----------------------------+-------------------------+
| `zx_channel_call(...)`      |                         |
|                             |                         |
|                             | `zx_channel_read(...)`  |
|                             | `zx_channel_write(...)` |
|                             |                         |
| (`zx_channel_call` returns) |                         |
+-----------------------------+-------------------------+

相反（接收数据）的过程也大同小异。将其与未确认的 I/O 进行比较：

+-------------------------+------------------------+
| Client                  | Netstack               |
+-------------------------+------------------------+
| `zx_channel_write(...)` |                        |
+-------------------------+------------------------+
| `zx_channel_write(...)` | `zx_channel_read(...)` |
+-------------------------+------------------------+

虽然 zircon 通道和 FIDL 支持未确认 I/O，但它不提供回压，并且可能会导致内存增长失控。因此，我们建议使用 zircon 套接字：

+------------------------+-----------------------+
| Client                 | Netstack              |
+------------------------+-----------------------+
| `zx_socket_write(...)` |                       |
+------------------------+-----------------------+
| `zx_socket_write(...)` | `zx_socket_read(...)` |
+------------------------+-----------------------+

设计

元数据验证

使用未确认的 I/O 的前提是，数据报套接字元数据（例如目标地址）可以在本地机器上完全验证，而无需与网络交互，并且此验证结果可以在与套接字的多次交互中缓存（以便摊销验证开销）。

请注意，这一假设显然不适用于 IPPROTO_ICMP 套接字（其载荷会被检查是否有效），因此在性能不是关键且需要进行深度验证的情况下，系统会保留并使用现有的基于 FIDL 的协议。

从要重复使用的现有类型中提取 FIDL，并重命名 DatagramSocket 以提高清晰度：

protocol BaseDatagramSocket {
  compose BaseSocket;

  /// Retrieves creation information from the socket.
  GetInfo() -> (Domain domain, DatagramSocketProtocol proto) error fuchsia.posix.Errno;
}

protocol SynchronousDatagramSocket {
  compose BaseDatagramSocket;

  /// Receives a message from the socket.
  RecvMsg(bool want_addr, uint32 data_len, bool want_control, RecvMsgFlags flags) -> (fuchsia.net.SocketAddress? addr, bytes data, RecvControlData control, uint32 truncated) error fuchsia.posix.Errno;
  /// Sends a message on the socket.
  SendMsg(fuchsia.net.SocketAddress? addr, bytes:MAX data, SendControlData control, SendMsgFlags flags) -> (int64 len) error fuchsia.posix.Errno;
}

使用验证函数定义新的 FIDL 协议：

/// Matches the definition in //zircon/system/public/zircon/types.h.
const uint32 ZX_WAIT_MANY_MAX_ITEMS = 64;

/// Describes an intent to send data.
type SendMsgArguments = table {
  /// The destination address.
  ///
  /// If absent, interpreted as the method receiver's connected address and
  /// causes the connected address to be returned in [`SendMsgBoardingPass.to`].
  ///
  /// Required if the method receiver is not connected.
  1: to fuchsia.net.SocketAddress;
}

/// Describes a granted approval to send data.
type SendMsgBoardingPass = resource table {
  /// The validated destination address.
  ///
  /// Present only in response to an unset
  /// [`SendMsgArguments.to`].
  1: to fuchsia.net.SocketAddress;
  /// Represents the validity of this structure.
  ///
  /// The structure is invalid if any of the elements' peer is closed.
  /// Datagrams sent to the associated destination after invalidation will be
  /// silently dropped.
  2: validity vector<zx.handle:<EVENTPAIR, zx.RIGHTS_BASIC>>:ZX_WAIT_MANY_MAX_ITEMS;
  /// The maximum datagram size that can be sent.
  ///
  /// Datagrams exceeding this will be silently dropped.
  3: maximum_size uint32;
}

protocol DatagramSocket {
  compose BaseDatagramSocket;

  /// Validates that data can be sent.
  ///
  /// + request `args` the requested disposition of data to be sent.
  /// - response `pass` the constraints sent data must satisfy.
  /// * error the error code indicating the reason for validation failure.
  SendMsgPreflight(SendMsgArguments args) -> (SendMsgBoardingPass pass) error fuchsia.posix.Errno;
};

定义要在 zircon 套接字上发送的 FIDL 结构：

/// A datagram received on a network socket, along with its metadata.
type RecvMsgPayload = table {
  1: from fuchsia.net.SocketAddress;
  2: control RecvControlData;
  3: datagram bytes:MAX;
};

/// A datagram to be sent on a network socket, along with its metadata.
type SendMsgPayload = table {
  1: args SendMsgArguments;
  2: control SendControlData;
  3: datagram bytes:MAX;
};

尝试发送数据的客户端会遵循下图（水平压缩）所示的流程：

+--------------------------------+               +---------------------------+               +----------------+
| cache.getSendMsgBoardingPass() | - Present ->  | checkPeerClosed(validity) |   +- ZX_OK -> | Return success |
+--------------------------------+               +---------------------------+   |           +----------------+
 |    ^                                            ^                     |  |    |
 |    |                                            |                     |  |  +------------------------------+
 |  +------+                  +----------------------------------+       |  |  | socket.write(SendMsgPayload) | - != ZX_OK -----+
 |  | Send |    +- Success -> | cache.storeSendMsgBoardingPass() |       |  |  +------------------------------+                 |
 |  +------+    |             +----------------------------------+       |  |                         ^                         |
 |            +--------------------+                                     |  |                         |                         |
 +- Absent -> | SendMsgPreflight() |  +- (ZX_OK, ZX_SIGNAL_PEER_CLOSED) -+  +- (ZX_ERR_TIMED_OUT) -+  |                         |
              +--------------------+  |                                                            |  +- No -+                  |
                |                ^    |   +-----------------------------------+                    |         |                  |
                |                |    +-> | cache.removeSendMsgBoardingPass() |                    |   +---------------------+  |
                |                |        +-----------------------------------+                    +-> | size > maximum_size |  |
                |                |          |                                                          +---------------------+  |
                |                |          |  +--------------+                                              |                  |
                |                +----------+  |              | <-------------------------------------- Yes -+                  |
                |                              | Return error |                                                                 |
                +- Failure ------------------> |              | <---------------------------------------------------------------+
                                               +--------------+

客户端的 cache“实现”SendMsgPreflight；它大致是从 fuchsia.net.SocketAddress 到 (vector<zx::eventpair>, maximum_size) 的映射。

请注意，此策略形成的缓存最终会保持一致；失效可能会使客户端的有效性检查与到达网络堆栈的载荷交错。对于传送语义为“尽力”的数据报套接字，这种情况是可以接受的。

保证同步行为

背景

根据 POSIX 语义，客户端希望系统针对客户端发起的其他传入/传出数据包处理更改提供同步 send 和 recv 行为。具体而言，客户希望这些更改应用于尚未收到的所有载荷，并且不应用于已发送的任何载荷。

在当前实现中，同步行为有保证，因为：

  1. Netstack 负责所有相关的数据包处理。
  2. 客户端通过同步 FIDL 调用发送和接收载荷。
  3. 客户端通过设置套接字选项（也作为同步 FIDL 调用实现）来请求更改数据包处理。

将同步 FIDL 调用替换为通过 Zircon 套接字传输的未确认 I/O 会破坏这些语义。下面介绍了由此产生的问题和解决方法。

发送路径

问题

在发送路径上，客户端可以通过设置套接字选项来修改载荷的处理方式。由于 setsockopt 是通过同步 FIDL 实现的，因此该选项的新值可能会应用于在调用之前加入队列的数据包。例如：

  1. 客户端将 IP_TOS 设置为某个值 A，同步更新 Netstack 中的状态。
  2. 客户端调用 sendto，后者会在 zircon 套接字中加入载荷。
  3. 客户端将 IP_TOS 设置为某个值 B。
  4. Netstack 会从队列中移除载荷，并使用 IP_TOS=B 将其发送到网络。
解决方案

修改了用于设置与发送路径相关的套接字选项的 FIDL 处理脚本，使其阻塞，直到 Netstack 的取消队列 goroutine 耗尽 zircon 套接字。之后，处理脚本会修改相关状态并返回给客户端。由于在调用 setsockopt 之前发送的所有载荷都已从 zircon 套接字移出队列并进入了 Netstack，因此所有这些载荷都不会使用新设置进行处理。

Recv 路径

问题

在 Recv Path 上，客户端可以请求控制消息，通过设置套接字选项来提供有关载荷及其传送的辅助数据。同样，由于 setsockopt 是同步的，因此存在偏差的可能性。例如：

  1. Netstack 将载荷加入 zircon 套接字队列。
  2. 客户端设置 IP_RECVTOS。
  3. 客户端从队列中移除载荷，并将其返回给用户，但不包含 IP_TOS 控制消息。
解决方案

在 Netstack 中，将每个载荷以及派生任何受支持的控制消息所需的最低状态加入队列。

定义一个 FIDL 方法来检索当前请求的一组控制消息：

protocol DatagramSocket {
  compose BaseDatagramSocket;

  /// Returns the set of requested control messages.
  ///
  /// - response `cmsg_set` the set of currently requested control messages.
  RecvMsgPostflight() -> (struct {
    cmsg_set @generated_name("RequestedCmsgSet") table {
      /// Represents the validity of this structure.
      ///
      /// The structure is invalid if the peer is closed.
      1: validity zx.handle:<EVENTPAIR, zx.RIGHTS_BASIC>;
      /// Identifies whether the `IP_RECVTOS` control message is requested.
      2: ip_recvtos bool;
    }
  });
};

在客户端中，缓存当前请求的一组控制消息，并使用该组消息过滤网栈通过套接字传递的控制消息状态，具体步骤如下：

+-----------------------------------------+
| socket.read() -> (Payload, RecvMsgMeta) | -----------> ZX_OK
+-----------------------------------------+                |
  |                                                        |
  |                    +-----------------------------+     |
  |                    | cache.getRequestedCmsgSet() | <---+
  |                    +-----------------------------+
  |                               |    |
  |                               |    |
  |                               |    |
  |  Absent  <--------------------+    +-----------------------------> Present
  |    |                                                                   |
  |    |  +-----------------------+                                        |
  |    |  | Return Payload, cmsgs |     +---------------------------+      |
  |    |  +-----------------------+     | checkPeerClosed(validity) |<-----+
  |    |           ^                    +---------------------------+
  |    |           |                      |          |         ^
  |    |           |                      |          |         |
  |    |   (ZX_ERR_TIMED_OUT) <-----------+          |         |
  |    |                                             |         |
  |    |                                             |         |
  |    |     +--(ZX_OK, ZX_SIGNAL_PEER_CLOSED) <-----+         |
  |    |     |                                                 |
  |    |     |                                                 |
  |    |     |      +--------------------------------+         |
  |    |     +--->  | cache.removeRequestedCmsgSet() |         |
  |    |            +--------------------------------+         |
  |    |                                 |                     |
  |    |                                 |                     |
  |    |    +---------------------+      |                     |
  |    +--> | RecvMsgPostflight() |  <---+                     |
  |         +---------------------+                            |
  |                     |      |                               |
  |                     |      |                +------------------------------+
  |  +-------Failure <--+      +--> Success --> | cache.storeRequestedCmsgSet()|
  |  |                                          +------------------------------+
  |  |
  |  |
  |  |    +--------------+
  |  +--> |              |
  |       | Return error |
  +-----> |              |
          +--------------+

向每个载荷添加控制消息状态会增加将内存复制到 zircon 套接字和从中复制出内存的开销。我们认为这是一个可以接受的权衡，原因有两个：

  1. 我们可能支持的控制消息可容纳约 100 字节。假设 MTU 约为 1500 字节，则复制开销小于 10%。
  2. 大多数控制消息状态都是“按数据包”的，这意味着 Netstack 会将其与每个数据包一起存储在内存中，并在数据包加入到套接字队列后释放该内存。因此，系统的总内存用量不应增加。

此外，我们将使用微基准来跟踪相关指标，并在每次添加新控制消息时运行该基准。如果结果表明不再值得进行这种权衡，我们可以改回慢速路径（无论如何，我们都需要保留该路径，以支持 ICMP 数据报）。

序列化协议

通过 Zircon 套接字执行 I/O 的最简单方法是定义一个单个 FIDL 表来存储 UDP 载荷及其元数据，并使用静态 FIDL 对其进行序列化。此方法的缺点是，它会强制发送方和接收方将载荷和元数据序列化到临时缓冲区，从而保证这两者的至少一个副本。

由于向量化套接字读写功能可能很快就会推出，因此最好构建一个协议，利用向量化 API 来避免进行此复制。

协议

为 send 和 recv 元数据定义 FIDL 表：

/// Metadata used when receiving a datagram payload.
type RecvMsgMeta = table {
  1: fuchsia.net.SocketAddress from;
  2: RecvControlData control;
};

/// Metadata used when sending a datagram payload.
type SendMsgMeta = table {
  1: SendMsgArguments args;
  2: SendControlData control;
};

在 Describe 中返回给客户端的 fuchsia.io/NodeInfo 中，指定用于接收包含序列化元数据表的字节的缓冲区的大小：

type NodeInfo = strict resource union {
  // Other variants omitted.
  9: datagram_socket resource struct {
    /// See [`fuchsia.posix.socket.DatagramSocket`] for details.
    socket zx.handle:<SOCKET, zx.rights.TRANSFER | zx.RIGHTS_IO | zx.rights.WAIT | zx.rights.INSPECT>;
    /// Size of the buffer used to receive Tx metadata.
    tx_meta_buf_size uint64;
    /// Size of the buffer used to receive Rx metadata.
    rx_meta_buf_size uint64;
  };
};

设：

tx_meta_bytes = fidl_at_rest::serialize(SendMsgMeta)
tx_meta_size = len(tx_meta_bytes)

发送载荷时，客户端会构建并加入队列以下缓冲区：

      ( 2 )       (tx_meta_size)   (tx_meta_buf_size - tx_meta_size)
+--------------+-----------------+----------------------------------+---------+
| tx_meta_size |  tx_meta_bytes  |             Padding              | Payload |
+--------------+-----------------+----------------------------------+---------+

网络栈：

  • 分配一个可容纳 2 + tx_meta_buf_size + max_payload_size 字节的缓冲区，并将消息从队列中移出到该缓冲区。
  • 将前两个字节解读为 uint16，用于标识存储序列化元数据的缓冲区区域的大小（以字节为单位）。
  • 使用静态状态下的 FIDL 反序列化 SendMsgMeta。

接收路径的工作方式完全对称。

uint32_t tx_meta_buf_size = fidl::MaxSizeInChannel<fuchsia_posix_socket::wire::SendMsgMeta, fidl::MessageDirection::kSending>();

该函数会计算发送方向的消息大小上限，假设不存在未知字段。由于 Netstack 本身会对该消息进行序列化，因此 Netstack 可以安全地假设 RecvMsgMeta 中的所有字段都是已知的。它可以假定 SendMsgMeta 中的所有字段都是已知的，因为：

  1. 客户端的 ABI 修订版本限定了客户端序列化表中的所有字段集。
  2. 如果平台不支持客户端的 ABI 修订版，则会拒绝运行该客户端。
  3. Netstack 始终会与平台一起构建。整个现有系统一直默认依赖于此假设。在这里，我们明确指出这一点。

实现

将新实现添加到 fuchsia.io/NodeInfo：

resource union NodeInfo {
    /// The connection composes [`fuchsia.posix.socket/DatagramSocket`].
    N: DatagramSocket datagram_socket;
};

/// A [`NodeInfo`] variant.
// TODO(https://fxbug.dev/42154392): replace with an anonymous struct inline.
resource struct DatagramSocket {
    zx.handle:<SOCKET, zx.RIGHTS_BASIC | zx.RIGHTS_IO> socket;
};

将 fuchsia.posix.socket/Provider.DatagramSocket 的返回类型更改为变体：

/// Contains a datagram socket implementation.
resource union DatagramSocketImpl {
    1: DatagramSocket datagram_socket;
    2: SynchronousDatagramSocket synchronous_datagram_socket;
}

...并更改行为，以便在参数允许时（即调用方未请求 ICMP 套接字）返回 DatagramSocket。

初始实现预计会在每个 SendMsgBoardingPass.validity 中提供两个元素：

  1. 表示路由表的已知状态；由所有套接字共享，并会在路由表发生任何更改时失效。
  2. 表示特定套接字的已知状态；如果套接字发生任何可能更改套接字行为的更改（例如对 bind、connect、setsockopt(..., SO_BROADCAST, ...)、setsockopt(..., SO_BINDTODEVICE, ...) 等的调用），则失效。

性能

SOCK_DGRAM 套接字的吞吐量预计会大约翻倍；此估算值基于 https://fxbug.dev/42094952 后出现的性能回归。

CPU 利用率预计会显著下降，但幅度未知。

工效学设计

这项更改对人体工学没有实质性影响，因为下游用户不会直接使用此处介绍的接口。

向后兼容性

通过最初保持 fuchsia.posix.socket/Provider.DatagramSocket 不变并将新功能实现为 DatagramSocket2，从而保持 ABI 兼容性。完成必要的 ABI 转换后，将 DatagramSocket2 重命名为 DatagramSocket，并移除之前的实现。在进行另一次 ABI 转换后，移除了 DatagramSocket2。

安全注意事项

此提案对安全性没有影响。

隐私注意事项

此提案对隐私权没有影响。

测试

现有单元测试涵盖受影响的功能。

文档

除了此处介绍的 FIDL 文档注释之外，无需提供任何文档。

缺点、替代方案和未知情况

此提案通过在用户空间中构建机器来解决此动机。另一种可能的方法是在内核中构建此机制。

用于将其转换为内核的草图：

  1. 对于每个 zx::socket 端点，内核都会维护一个从 SocketAdddres 到 max_size 的映射。
  2. 我们会添加一些 zx_socket_add_route / zx_socket_remove_route 系统调用，以便在对等端点上修改该映射。
  3. 我们添加了一些会使用 / 提供地址的 zx_socket_send_to/zx_socket_receive_from 系统调用。

如果用户空间使用不在映射中的地址调用 zx_socket_send_to，则操作将失败，并且用户空间需要向网络堆栈发送同步消息，以请求将该路由添加到 zx::socket。如果该请求失败，则地址操作会失败并显示错误。

优点

在内核方法中，发送 UDP 数据包（在快速情况下）是一次系统调用 (zx_socket_send_to)，而不是两次系统调用 (zx_object_wait_many、zx_socket_write)。

由于用户空间方法可能进行了优化，因此这可能不是专业版。我们意识到，我们始终使用 time::infinite_past 进行 zx_object_wait_many，因此可以优化该操作，使其无需系统调用即可执行工作，前提是使用原子操作来维护必要的状态。这可能还需要将句柄表也放在 vDSO 中，但这可能并非如此，也可能无法实现。

对于具有运行时的客户端，一种替代方法是使用 zx_object_wait_async（而非 wait_many）来维护本地缓存，以允许快速路径避免额外的系统调用。

我们还避免了对休眠状态下的 FIDL 的依赖，以及避免了 FIDL 固有的额外数据复制，因为消息载荷已嵌入到系统调用中，系统调用可以直接将载荷复制到最终目的地。

缺点

在内核方法中，在路由表发生变化时，没有明显的方法可以执行 O(1) 路由取消。如前所述，我们可以向 zx_socket_remove_route 添加一个用于移除所有路由的标志（无论如何，这可能都是可取的），但网络堆栈需要对每个套接字发出 zx_socket_remove_route。

我们可以使用非常复杂的方法，让 zx_socket_add_route 接受取消事件对，但这样做会很繁琐。

将这些结构嵌入内核也会带来成本，因为这会向平台引入另一种协议演变模型；现在，特定 FIDL 类型与系统调用之间的耦合更紧密，它们不会自动保持同步。

后续工作

使用 eventpair 来指示客户端缓存的有效性会导致在 send 和 recv 路径上产生额外的系统调用。您可以改用 VMO 来发送有效性信号，从而消除此系统调用。在这种设计中，eventpair 在逻辑上会被替换为映射到客户端地址空间的 VMO 中的偏移量。随后，客户端可以通过简单地读取 VMO 来检查有效性。

未知

还有一个问题是如何处理 SendControlData。这可能需要是 zx_socket_send_to 的额外参数，或者是操作上的标志。