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語言。