在 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，并直接使用它。