2013-08-28 19:24:34 -04:00
[[modules-transport]]
== Transport
The transport module is used for internal communication between nodes
within the cluster. Each call that goes from one node to the other uses
the transport module (for example, when an HTTP GET request is processed
by one node, and should actually be processed by another node that holds
the data).
The transport mechanism is completely asynchronous in nature, meaning
that there is no blocking thread waiting for a response. The benefit of
using asynchronous communication is first solving the
http://en.wikipedia.org/wiki/C10k_problem[C10k problem], as well as
2014-03-07 08:21:45 -05:00
being the ideal solution for scatter (broadcast) / gather operations such
2017-11-29 03:44:25 -05:00
as search in Elasticsearch.
2013-08-28 19:24:34 -04:00
[float]
2018-12-18 15:09:58 -05:00
=== Transport Settings
2013-08-28 19:24:34 -04:00
2018-12-18 15:09:58 -05:00
The internal transport communicates over TCP. You can configure it with the
following settings:
2013-08-28 19:24:34 -04:00
[cols="<,<",options="header",]
|=======================================================================
|Setting |Description
2018-12-18 15:09:58 -05:00
|`transport.port` |A bind port range. Defaults to `9300-9400`.
2013-08-28 19:24:34 -04:00
2014-01-17 15:58:57 -05:00
|`transport.publish_port` |The port that other nodes in the cluster
should use when communicating with this node. Useful when a cluster node
2018-12-18 15:09:58 -05:00
is behind a proxy or firewall and the `transport.port` is not directly
2014-01-17 15:58:57 -05:00
addressable from the outside. Defaults to the actual port assigned via
2018-12-18 15:09:58 -05:00
`transport.port`.
2014-01-17 15:58:57 -05:00
2014-10-17 09:01:21 -04:00
|`transport.bind_host` |The host address to bind the transport service to. Defaults to `transport.host` (if set) or `network.bind_host`.
|`transport.publish_host` |The host address to publish for nodes in the cluster to connect to. Defaults to `transport.host` (if set) or `network.publish_host`.
|`transport.host` |Used to set the `transport.bind_host` and the `transport.publish_host` Defaults to `transport.host` or `network.host`.
2018-12-18 15:09:58 -05:00
|`transport.connect_timeout` |The connect timeout for initiating a new connection (in
2014-01-19 15:29:08 -05:00
time setting format). Defaults to `30s`.
2013-08-28 19:24:34 -04:00
2018-12-18 15:09:58 -05:00
|`transport.compress` |Set to `true` to enable compression (`DEFLATE`) between
all nodes. Defaults to `false`.
2015-09-01 07:43:03 -04:00
2018-06-08 08:36:19 -04:00
|`transport.ping_schedule` | Schedule a regular application-level ping message
to ensure that transport connections between nodes are kept alive. Defaults to
2018-10-31 12:32:53 -04:00
`5s` in the transport client and `-1` (disabled) elsewhere. It is preferable
to correctly configure TCP keep-alives instead of using this feature, because
TCP keep-alives apply to all kinds of long-lived connections and not just to
2018-06-08 08:36:19 -04:00
transport connections.
2015-09-01 07:43:03 -04:00
2013-08-28 19:24:34 -04:00
|=======================================================================
2014-03-07 08:21:45 -05:00
It also uses the common
2013-08-28 19:24:34 -04:00
<<modules-network,network settings>>.
2014-10-17 19:11:38 -04:00
[float]
2018-12-18 15:09:58 -05:00
==== Transport Profiles
2014-10-12 12:30:12 -04:00
2018-07-19 06:33:46 -04:00
Elasticsearch allows you to bind to multiple ports on different interfaces by
the use of transport profiles. See this example configuration
2014-10-12 12:30:12 -04:00
2014-11-02 02:25:45 -05:00
[source,yaml]
--------------
2014-10-12 12:30:12 -04:00
transport.profiles.default.port: 9300-9400
transport.profiles.default.bind_host: 10.0.0.1
transport.profiles.client.port: 9500-9600
transport.profiles.client.bind_host: 192.168.0.1
transport.profiles.dmz.port: 9700-9800
transport.profiles.dmz.bind_host: 172.16.1.2
2014-11-02 02:25:45 -05:00
--------------
2014-10-12 12:30:12 -04:00
2018-07-19 06:33:46 -04:00
The `default` profile is special. It is used as a fallback for any other
profiles, if those do not have a specific configuration setting set, and is how
this node connects to other nodes in the cluster.
2014-10-12 12:30:12 -04:00
2018-07-19 06:33:46 -04:00
The following parameters can be configured on each transport profile, as in the
example above:
2014-10-12 12:30:12 -04:00
* `port`: The port to bind to
* `bind_host`: The host to bind
* `publish_host`: The host which is published in informational APIs
2018-12-18 15:09:58 -05:00
* `tcp.no_delay`: Configures the `TCP_NO_DELAY` option for this socket
* `tcp.keep_alive`: Configures the `SO_KEEPALIVE` option for this socket
* `tcp.reuse_address`: Configures the `SO_REUSEADDR` option for this socket
* `tcp.send_buffer_size`: Configures the send buffer size of the socket
* `tcp.receive_buffer_size`: Configures the receive buffer size of the socket
2014-10-12 12:30:12 -04:00
2018-06-08 08:36:19 -04:00
[float]
==== Long-lived idle connections
Elasticsearch opens a number of long-lived TCP connections between each pair of
nodes in the cluster, and some of these connections may be idle for an extended
period of time. Nonetheless, Elasticsearch requires these connections to remain
open, and it can disrupt the operation of the cluster if any inter-node
connections are closed by an external influence such as a firewall. It is
important to configure your network to preserve long-lived idle connections
2018-12-18 15:09:58 -05:00
between Elasticsearch nodes, for instance by leaving `tcp.keep_alive` enabled
2018-06-08 08:36:19 -04:00
and ensuring that the keepalive interval is shorter than any timeout that might
cause idle connections to be closed, or by setting `transport.ping_schedule` if
keepalives cannot be configured.
2018-12-21 12:14:00 -05:00
[float]
==== Transport Compression
[float]
2019-01-07 08:44:12 -05:00
===== Request Compression
2018-12-21 12:14:00 -05:00
By default, the `transport.compress` setting is `false` and network-level
request compression is disabled between nodes in the cluster. This default
normally makes sense for local cluster communication as compression has a
noticeable CPU cost and local clusters tend to be set up with fast network
connections between nodes.
The `transport.compress` setting always configures local cluster request
compression and is the fallback setting for remote cluster request compression.
If you want to configure remote request compression differently than local
request compression, you can set it on a per-remote cluster basis using the
<<remote-cluster-settings,`cluster.remote.${cluster_alias}.transport.compress` setting>>.
[float]
===== Response Compression
The compression settings do not configure compression for responses. {es} will
compress a response if the inbound request was compressed--even when compression
is not enabled. Similarly, {es} will not compress a response if the inbound
request was uncompressed--even when compression is enabled.
2015-01-08 07:31:28 -05:00
[float]
=== Transport Tracer
The transport module has a dedicated tracer logger which, when activated, logs incoming and out going requests. The log can be dynamically activated
2016-09-14 08:08:49 -04:00
by settings the level of the `org.elasticsearch.transport.TransportService.tracer` logger to `TRACE`:
2015-01-08 07:31:28 -05:00
[source,js]
--------------------------------------------------
2017-02-07 21:06:28 -05:00
PUT _cluster/settings
{
"transient" : {
"logger.org.elasticsearch.transport.TransportService.tracer" : "TRACE"
}
}
2015-01-08 07:31:28 -05:00
--------------------------------------------------
2017-02-07 21:06:28 -05:00
// CONSOLE
2015-01-08 07:31:28 -05:00
You can also control which actions will be traced, using a set of include and exclude wildcard patterns. By default every request will be traced
except for fault detection pings:
[source,js]
--------------------------------------------------
2017-02-07 21:06:28 -05:00
PUT _cluster/settings
{
"transient" : {
"transport.tracer.include" : "*",
2019-03-04 09:51:17 -05:00
"transport.tracer.exclude" : "internal:coordination/fault_detection/*"
2017-02-07 21:06:28 -05:00
}
}
2015-01-08 07:31:28 -05:00
--------------------------------------------------
2017-02-07 21:06:28 -05:00
// CONSOLE
2015-01-08 07:31:28 -05:00