| RFC-0109：快速 UDP 套接字 | |
|---|---|
| 状态 | 已接受 |
| 领域 |
|
| 说明 | 使用 zircon 套接字实现网络 UDP 套接字数据传输。 |
| Gerrit 更改 | |
| 作者 | |
| 审核人 |
|
| 提交日期（年-月-日） | 2021-06-17 |
| 审核日期（年-月-日） | 2021-06-25 |
摘要
使用 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 行为。具体而言，客户端希望这些更改适用于尚未收到的所有载荷和已发送的所有载荷。
在当前实现中，可以保证同步行为，原因如下：
- Netstack 负责所有相关的数据包处理。
- 客户端通过同步 FIDL 调用发送和接收负载。
- 客户端通过设置套接字选项来请求对数据包处理进行更改，这些选项也作为同步 FIDL 调用来实现。
通过 zircon 套接字传输将同步 FIDL 调用替换为未确认的 I/O 会破坏这些语义。下面介绍了产生的问题和解决方案。
发送路径
问题
在发送路径上，客户端通过设置套接字选项来修改载荷的处理方式。由于 setsockopt 是通过同步 FIDL 实现的，因此该选项的新值可能会应用于在进行调用前加入队列的数据包。例如：
- 客户端将
IP_TOS设置为某个值 A，同步更新 Netstack 中的状态。 - 客户端调用
sendto，以将载荷加入 zircon 套接字中。 - 客户端将
IP_TOS设置为某个值 B。 - Netstack 会将载荷移出队列并使用
IP_TOS=B将其发送到网络。
解决方案
修改了 FIDL 处理程序，用于设置与发送路径相关的套接字选项，以便阻塞，直到 Netstack 的排队 goroutine 排空 zircon 套接字。之后，处理程序修改相关状态并返回客户端。由于在调用 setsockopt 之前发送的所有载荷都已从 zircon 套接字中移出到 Netstack，因此使用新设置时不会处理其中任何一个。
接收路径
问题
在接收路径上，客户端可以通过设置套接字选项，请求提供有关载荷及其传送的辅助数据的控制消息。同样，由于 setsockopt 是同步的，存在偏差。例如：
- Netstack 将载荷加入 zircon 套接字。
- 客户端设置
IP_RECVTOS。 - 客户端将载荷移出队列，并在没有
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;
}
});
};
在客户端中，按照以下过程，缓存当前请求的控制消息集，并使用 set 来过滤 netstack 通过套接字传递的控制消息状态：
+-----------------------------------------+
| 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 套接字中和从 zircon 套接字中复制出内存时，向每个载荷添加控制消息状态会增加开销。我们认为，这是可以接受的权衡，原因有两个：
- 我们可能支持的控制消息大约能容纳 100 个字节。假设 MTU 为约 1500 个字节，则复制开销小于 10%。
- 绝大多数控制消息状态都是“每个数据包”，这意味着 Netstack 会将其与每个数据包一起保存在内存中，并在数据包加入套接字加入队列后释放该内存。因此，系统的整体内存消耗量不应增加。
此外，我们将使用 Microbenchmark 来跟踪相关指标，并在添加新的控制消息时运行 Microbenchmark。如果结果表明不再值得进行权衡，我们可以还原到慢速路径（我们仍然需要保留该路径以支持 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 |
+--------------+-----------------+----------------------------------+---------+
Netstack：
- 分配一个能够容纳
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 可以放心地假定 RecvMsgMeta 中的所有字段都是已知的，因为 Netstack 本身会序列化该消息。它可以假定 SendMsgMeta 中的所有字段都是已知的，原因如下：
- 客户端的 ABI 修订版本限制了客户端序列化表中所有字段的集合。
- 如果客户端不支持客户端的 ABI 修订版本，平台将拒绝运行该客户端。
- 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;
}
...并更改此行为，以便在参数允许的情况下返回 DatagramSocket（即调用方未请求 ICMP 套接字）。
初始实现应在每个 SendMsgBoardingPass.validity 中提供两个元素：
- 表示路由表的已知状态；由所有套接字共享，并会在路由表发生任何更改时失效。
- 表示特定套接字的已知状态；当套接字发生任何可能更改套接字行为（如调用
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 文档注释外，不需要提供任何文档。
缺点、替代方案和问题
这项提案通过在用户空间中构建机制来解决这一动机。 另一种可能是在内核中构建这种机制。
将其转换为内核的草图：
- 对于每个
zx::socket端点，内核都会维护一个从SocketAdddres到max_size的映射。 - 我们将添加一些
zx_socket_add_route/zx_socket_remove_route系统调用，用于修改对等端点上的该映射。 - 我们将添加一些会使用 / 提供地址的
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 添加一个标志来移除所有路由（无论如何都可能需要），但 netstack 需要对每个套接字发出 zx_socket_remove_route。
我们可以进行超酷的安排，让 zx_socket_add_route 将事件对用于取消，但这样太过巴洛克式了。
在向平台引入另一个协议演变模型方面，将这些结构烘焙到内核的成本也很高；现在，特定 FIDL 类型和系统调用之间的耦合更紧密，系统不会自动保持同步。
未来工作
使用事件对来指示客户端缓存的有效性时，在 send 和 recv 路径上会产生额外的系统调用。可以通过改用 VMO 来指示有效性，从而消除此系统调用。在此类设计中，事件对在逻辑上被替换为映射到客户端地址空间的 VMO 的偏移量。随后，客户端只需读入 VMO 即可检查有效性。
未知
此外，还有关于如何处理 SendControlData 的问题。这可能需要作为 zx_socket_send_to 的一个附加参数，或者操作上的标志。