UDP

UDP 在传输端点之间携带独立数据报，八字节首部包含来源端口、目的端口、长度和校验和字段。它不会加入 TCP 的可靠有序字节流或拥塞控制行为，让应用可以选择自己的交付策略，但不承诺所有负载下延迟都更低。应用确实需要某条内容时，丢失的数据报可能比建立连接的开销更昂贵，必须按完整请求过程评估。 原文发送 A、BC 和空数据报，得到长度 1、2、0。八字节 abcdefgh 用三字节缓冲区接收，得到 abc 与 MSG_TRUNC；defgh 被丢弃，下次读取超时，新发的 next 数据报仍能收到。刻意编写的中继把 1、2、3 改成 3、1、1；集合去重只留下 3、1，没有恢复 2 或原始顺序。 原有实验示意，本轮未重跑；中继属于故障注入，不是网络丢包统计或延迟保证。 坏掉的样子 发送成功不证明目标应用已经收到或处理消息。UDP 没有内建确认、重传、去重或顺序保证，因此超时不能告诉支付客户端操作是否发生。允许重试时，应用需要能够处理重复请求和结果不确定的协议，不能把没有响应直接解释成业务失败。消息是否到达、动作是否执行、结果是否持久化，也应具有不同含义。 ...

EDNS 通过 OPT 伪记录扩展 DNS，其中一项作用是让请求发送方宣告自己准备接收的 UDP 载荷大小，从而允许回答超过传统五百一十二字节 DNS 限制。这是 DNS 交换中的容量宣告，不是网络路径 MTU 发现协议，也不承诺所有中间设备都会交付相同大小的数据报。理解这一区别，才能准确解释大回答为何仍可能失败。 图中数值来自文章明确的回环配置与记录的 DNS 消息长度，不是统一默认值或路径 MTU 测量。OPT 宣告容量，客户端仍须理解 TC 并保留 TCP 访问。 坏掉的样子 客户端宣告四千零九十六字节，不会强迫服务器发送同样大小的响应。服务器可以实施更小的发送上限；需要的回答放不下时，可以返回 TC，客户端仍需可工作的 TCP 路径。增加客户端数字，不能修复服务器有意采用较小预算的策略。应查看两端实际配置与返回内容，而不是把请求里出现的大数值当成双方已承诺一定使用的大小。 ...