elasticsearch支持两种协议：

http协议。

Native Elasticsearch binary protocol（本地elasticsearch二进制协议）：elasticsearch自主研发的节点间通信的协议。

还可以通过使用插件来扩展支持的协议。有一些官方的插件。

java之外的语言不推荐使用第二种方式，因为第二种方式需要很多自定义序列化。

支持的客户端

Transport

Transport是连接到Elasticsearch的本地方法之一。它是官方Elasticsearch分发的一部分，因此需要客户端用Java编写（或至少在JVM上运行）。 它非常快，在JVM上本机运行。序列化是有效的，发送到/从Elasticsearch实例的消息和操作中几乎没有开销。它需要保持Elasticsearch服务器和客户端版本有些同步。在Elasticsearch 1.0之前，将需要完全相同的版本，但较新的版本（1.0和更高版本）支持版本之间的交互。由于异常序列化和更新之间的其他潜在细微差异，在客户端和服务器上运行相同的JVM更新版本也是有益的。 目前不支持加密或身份验证，但是宣布不久会满足这些需求。要在Found.no托管集群上使用传输客户端，可以使用elasticsearch自定义传输模块，该模块负责加密，身份验证和保持活动。

Node Client

Node客户端与transport client非常相似：它是官方Elasticsearch发行版的一部分，需要客户端运行Java等，但也有一些显着的差异。 如果群集对传输客户端是否已连接到群集中的某个节点非常不感兴趣，那么节点客户端将被视为群集的一部分。这意味着节点客户端的存在被存储在群集状态，并且群集中的所有其他节点将尝试建立到客户端的几个tcp连接。如果群集很大或使用多个客户端，这可能是一个显着的缺点。 这可能看起来有点荒谬，但是目前需要它，以便使服务器节点能够将对集群状态的更改传播到客户端。其最终结果是，节点客户端始终具有最新的集群状态和与Elasticsearch集群中每个其他节点的连接，这使得它能够在本地执行操作路由，是其自身请求的协调器等等。这会为每个请求跳过网络跳转，并导致集群中其余节点的工作量减少。

HTTP客户端

HTTP在大多数编程语言中得到很好的支持，这是连接到Elasticsearch的最常见的方法。如果要使用HTTP，还有一个重要的选择：使用一个现有的Elasticsearch基于HTTP的库，或者只是创建一个小的包装器，需要使用HTTP客户端的操作。 由于HTTP是一个通用协议，并支持各种各样的用例，一些重要的事情需要由客户端实现：连接池和保持活动。需要连接池以避免必须支付每个请求的TCP连接建立成本。更重要的，如果它使用HTTPS，这带来额外的加密握手成本。连接池经常需要保持活动支持，因为我们希望避免连接由于空闲而中断。 虽然最初显而易见的是，连接建立实际上是重要的，但是考虑建立TCP连接需要三次握手。简单地说，使用50毫秒的ping时间，除了获取和释放本地资源（处理客户端端口，连接管理等）所花费的时间之外，建立连接需要大约75毫秒 - 这个没有考虑在两端处理请求/响应（例如，串行化）所花费的时间。没有连接池，这个时间被添加在每个请求的顶部。对于我们建议用于安全和隐私的HTTPS，连接建立开销有时可以以秒为单位测量，这甚至更显着。考虑到最终用户的响应时间必须在100毫秒以下才能被观察为“即时”的基本建议，即使非加密的开销也使得这种限制几乎不可能保持在内。 由Elasticsearch编写和支持的官方（非Java）客户端都使用HTTP底层与Elasticsearch进行通信。一般建议是使用封装HTTP API的正式客户端，因为他们负责处理所有这些细节。 HTTP客户端实现可能相当快，其中一些甚至与本机协议的速度竞争。 Elasticsearch的HTTP API被广泛使用，并且具有相当多的社区支持。然而，性能取决于客户端库，并且通常需要进行配置或调整才能最大化。

结论

使用一个高性能的HTTP客户端，很容易和官方语言绑定。

使用Java，一般通过transport优于node，除非使用节点客户端的性能增益足够大，以保证额外的网络复杂性。使用基准来验证性能提升。

当使用其他非基于Java JVM的语言（例如Scala，Clojure，Groovy，JRuby等）时，需要衡量能用在node和transport两种客户端的native语言。

elasticsearch客户端连接选择