在 2.7 版本中，我们重构了主进程与远程代理之间通信的多个区域。这些更改属于“幕后”改进，旨在解决某些场景或高负载设置中使用分布式索引和远程节点时出现的问题。

异步 DNS

这在使用云基础设施的用户中尤其成为一个问题。在 Linux 系统上，如果可用，守护进程将使用 getaddrinfo_a() 进行异步 DNS 解析。这意味着我们不需要主动等待答案，而是安排任务，当（如果）DNS 返回答案时继续处理，或在一段时间后通过超时中止。在 getaddrinfo_a 不可用的系统上，我们会启动一个专门用于 DNS 解析的新线程（这也以异步方式工作）。

远程代理网络线程

当查询到达包含远程代理的分布式索引时，我们之前会启动许多线程来连接并发送查询，然后 等待 所有线程完成才能进入下一步。这里的问题是，如果某个节点响应缓慢，可能会减缓整个过程。相反，现在每个连接从开始到终止独立运行，它们的执行部分不会受到可能较慢节点的影响。与此相关，在之前的版本中，第一步是真正将黑洞代理与普通代理解耦，因为过去主进程虽然不需要等待黑洞代理的响应，但仍需要等待其初始响应，而有问题的黑洞代理可能会减慢整个查询。

API 协议

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

主节点的 TFO

最后的改进是关于 TCP 快速打开（TFO）——在之前的版本中，我们添加了客户端在连接到搜索守护进程时使用 TFO 连接的可能性。现在，TFO 连接也可以在主节点与远程代理之间的分布式索引中使用。无需更改配置，守护进程将检测主机系统是否支持 TFO，并直接使用它。