在 2.7 中，我们重构了主守护进程与远程代理之间的多个通信区域。这些更改是“在后台”进行的，解决了在某些场景或使用分布式索引与远程节点的高负载设置中造成影响的问题。

异步 DNS

这对使用云基础设施的用户来说一直是一个问题。在 Linux 上，守护进程将使用 getaddrinfo_a()（如果可用）进行异步 DNS。这意味着我们不必主动等待答案，而是调度任务，当（如果）DNS 回答时我们继续 - 或者在一段时间后通过超时中止。在 getaddrinfo_a 不可用的系统上，我们会发出一个新的线程专门用于 DNS 解析（这同样是异步工作的）。

远程代理网络线程

当查询到达带有远程代理的分布式索引时，我们会启动多个线程来连接并发送查询，然后 等待 所有线程完成，以便进入下一个阶段。这里的问题是，如果一个节点响应缓慢，它可能会拖慢整个过程。与其为每个响应的节点发送查询，它们必须等到每个人都准备好。总体而言，这可能意味着宝贵的时间在闲置，增加整个查询响应时间。现在，每个连接从开始到终止都是独立工作的，它们在执行中的部分不受可能较慢的连接的影响（阻塞）。与此相关，之前版本的第一步是将黑洞代理与正常代理真正解耦，因为在过去，虽然主节点不必等待黑洞代理的响应，但它仍然在等待来自它的初始响应 - 而一个有问题的黑洞可能会拖慢整个查询。

API proto

关于网络的第三个改进是关于 API proto。在之前的版本中，主节点与远程代理之间的连接以“握手”开始 - 一个包含 API 版本的小数据包。另一端会以其版本进行回应，如果一切正常，查询就开始了。这个握手的设置是基于代理的地址/端口可能错误的想法，以避免在这种情况下发送更大的数据包。然而，我们认为这是一种浪费时间（考虑到网络延迟）和带宽的做法，仅仅是检查用户是否正确设置了内容。这种情况发生的可能性较小，即使发生，也可以由用户修复。现在，这个“握手”与查询一起在一个数据包中发送，减少了查询远程节点所花费的总时间。如果远程主机确实错误，我们只是白白发送了一个数据包，但用户可以注意到并纠正它 - 我们不必总是检查这个。这个 proto 更改保持与旧 proto 的兼容性，因此如果主节点升级到 2.7+，它仍然能够与 < 2.7 的远程代理进行通信。

主节点的 TFO

最后一个改进是关于 TCP Fast Open - 在之前的版本中，我们增加了客户端在连接到搜索守护进程时使用 tfo 连接的可能性。现在，TFO 连接也可以在主节点与远程代理之间的分布式索引中使用。无需更改配置，守护进程将检测主机系统上是否可用 TFO 并直接使用它。