Webhook 发布方发送的事件通知在接收数据前需要完成 DNS 解析、TCP 连接和 TLS 握手。这些握手过程的往返时间（RTT）是远距离接收方的主要网络开销。发布方对响应设定严格的超时限制，部分提供针对投递失败的重试机制。本文考察各握手步骤的成本，并探讨 BGP Anycast 如何缩短路径。同时，文章也讨论了 TCP Fast Open（TFO）和 TLS 1.3 0-RTT 的优缺点。单播（Unicast）投递将所有流量发送至单一端点位置，与发送方距离无关。相反，BGP Anycast 使用多个存在点（PoP），并通告相同的 IP 前缀，使发送方能连接到拓扑上更近的站点。Anycast 中的“最近”指的是网络路径，而非地理距离。Anycast 的稳定性可能受路由策略影响，但对于短生命周期的 Webhook 请求，路由翻转通常非常短暂。从健康的 Anycast 存在点撤回路由至关重要，以防止流量黑洞。这可以通过监控服务健康状态，并使用如 ExaBGP 等工具来管理路由通告实现自动化。TCP Fast Open 允许客户端在重复连接时，在初始 SYN 包中发送数据，从而节省一次往返。然而，其有效性取决于发送方支持、潜在的中继设备干扰，以及应用程序处理重复数据的能力。TLS 1.3 在一次往返中完成握手，而 0-RTT 允许在后续连接的初始 ClientHello 中发送应用数据。由于 0-RTT 存在重放风险，除非处理程序严格幂等，否则不建议用于 Webhook POST 请求。若接受 0-RTT，则必须通过事件 ID 进行去重，并使用共享存储以防御重放攻击。将 Anycast 与 TFO 及 TLS 1.3 0-RTT 相结合可显著降低延迟。Anycast 缩短了基础的往返时间，而 TFO 和 0-RTT 则减少了连接建立和数据传输所需的往返次数。即使在最优化场景中，仍会存在部分往返开销。通过 HTTP Keep-Alive 复用连接，也能大幅降低向同一主机进行后续投递时的握手成本。