== Writing TCP servers and clients

Vert.x allows you to easily write non blocking TCP clients and servers.

=== Creating a TCP server

The simplest way to create a TCP server, using all default options is as follows:

[source,js]
----

var server = vertx.createNetServer();

----

=== Configuring a TCP server

If you don't want the default, a server can be configured by passing in a `link:../dataobjects.html#NetServerOptions[NetServerOptions]`
instance when creating it:

[source,js]
----

var options = {
  "port" : 4321
};
var server = vertx.createNetServer(options);

----

=== Start the Server Listening

To tell the server to listen for incoming requests you use one of the `link:../../jsdoc/module-vertx-js_net_server-NetServer.html#listen[listen]`
alternatives.

To tell the server to listen at the host and port as specified in the options:

[source,js]
----

var server = vertx.createNetServer();
server.listen();

----

Or to specify the host and port in the call to listen, ignoring what is configured in the options:

[source,js]
----

var server = vertx.createNetServer();
server.listen(1234, "localhost");

----

The default host is `0.0.0.0` which means 'listen on all available addresses' and the default port is `0`, which is a
special value that instructs the server to find a random unused local port and use that.

The actual bind is asynchronous so the server might not actually be listening until some time *after* the call to
listen has returned.

If you want to be notified when the server is actually listening you can provide a handler to the `listen` call.
For example:

[source,js]
----

var server = vertx.createNetServer();
server.listen(1234, "localhost", function (res, res_err) {
  if (res_err == null) {
    console.log("Server is now listening!");
  } else {
    console.log("Failed to bind!");
  }
});

----

=== Listening on a random port

If `0` is used as the listening port, the server will find an unused random port to listen on.

To find out the real port the server is listening on you can call `link:../../jsdoc/module-vertx-js_net_server-NetServer.html#actualPort[actualPort]`.

[source,js]
----

var server = vertx.createNetServer();
server.listen(0, "localhost", function (res, res_err) {
  if (res_err == null) {
    console.log("Server is now listening on actual port: " + server.actualPort());
  } else {
    console.log("Failed to bind!");
  }
});

----

=== Getting notified of incoming connections

To be notified when a connection is made you need to set a `link:../../jsdoc/module-vertx-js_net_server-NetServer.html#connectHandler[connectHandler]`:

[source,js]
----

var server = vertx.createNetServer();
server.connectHandler(function (socket) {
  // Handle the connection in here
});

----

When a connection is made the handler will be called with an instance of `link:../../jsdoc/module-vertx-js_net_socket-NetSocket.html[NetSocket]`.

This is a socket-like interface to the actual connection, and allows you to read and write data as well as do various
other things like close the socket.

=== Reading data from the socket

To read data from the socket you set the `link:../../jsdoc/module-vertx-js_net_socket-NetSocket.html#handler[handler]` on the
socket.

This handler will be called with an instance of `link:../../jsdoc/module-vertx-js_buffer-Buffer.html[Buffer]` every time data is received on
the socket.

[source,js]
----

var server = vertx.createNetServer();
server.connectHandler(function (socket) {
  socket.handler(function (buffer) {
    console.log("I received some bytes: " + buffer.length());
  });
});

----

=== Writing data to a socket

You write to a socket using one of `link:../../jsdoc/module-vertx-js_net_socket-NetSocket.html#write[write]`.

[source,js]
----
var Buffer = require("vertx-js/buffer");

// Write a buffer
var buffer = Buffer.buffer().appendFloat(12.34).appendInt(123);
socket.write(buffer);

// Write a string in UTF-8 encoding
socket.write("some data");

// Write a string using the specified encoding
socket.write("some data", "UTF-16");



----

Write operations are asynchronous and may not occur until some time after the call to write has returned.

=== Closed handler

If you want to be notified when a socket is closed, you can set a `link:../../jsdoc/module-vertx-js_net_socket-NetSocket.html#closeHandler[closeHandler]`
on it:

[source,js]
----

socket.closeHandler(function (v) {
  console.log("The socket has been closed");
});

----

=== Handling exceptions

You can set an `link:../../jsdoc/module-vertx-js_net_socket-NetSocket.html#exceptionHandler[exceptionHandler]` to receive any
exceptions that happen on the socket.

=== Event bus write handler

Every socket automatically registers a handler on the event bus, and when any buffers are received in this handler,
it writes them to itself.

This enables you to write data to a socket which is potentially in a completely different verticle or even in a
different Vert.x instance by sending the buffer to the address of that handler.

The address of the handler is given by `link:../../jsdoc/module-vertx-js_net_socket-NetSocket.html#writeHandlerID[writeHandlerID]`

=== Local and remote addresses

The local address of a `link:../../jsdoc/module-vertx-js_net_socket-NetSocket.html[NetSocket]` can be retrieved using `link:../../jsdoc/module-vertx-js_net_socket-NetSocket.html#localAddress[localAddress]`.

The remote address, (i.e. the address of the other end of the connection) of a `link:../../jsdoc/module-vertx-js_net_socket-NetSocket.html[NetSocket]`
can be retrieved using `link:../../jsdoc/module-vertx-js_net_socket-NetSocket.html#remoteAddress[remoteAddress]`.

=== Sending files or resources from the classpath

Files and classpath resources can be written to the socket directly using `link:../../jsdoc/module-vertx-js_net_socket-NetSocket.html#sendFile[sendFile]`. This can be a very
efficient way to send files, as it can be handled by the OS kernel directly where supported by the operating system.

Please see the chapter about <<classpath, serving files from the classpath>> for restrictions of the 
classpath resolution or disabling it.

[source,js]
----

socket.sendFile("myfile.dat");

----

=== Streaming sockets

Instances of `link:../../jsdoc/module-vertx-js_net_socket-NetSocket.html[NetSocket]` are also `link:../../jsdoc/module-vertx-js_read_stream-ReadStream.html[ReadStream]` and
`link:../../jsdoc/module-vertx-js_write_stream-WriteStream.html[WriteStream]` instances so they can be used to pump data to or from other
read and write streams.

See the chapter on <<streams, streams and pumps>> for more information.

=== Upgrading connections to SSL/TLS

A non SSL/TLS connection can be upgraded to SSL/TLS using `link:../../jsdoc/module-vertx-js_net_socket-NetSocket.html#upgradeToSsl[upgradeToSsl]`.

The server or client must be configured for SSL/TLS for this to work correctly. Please see the <<ssl, chapter on SSL/TLS>>
for more information.

=== Closing a TCP Server

Call `link:../../jsdoc/module-vertx-js_net_server-NetServer.html#close[close]` to close the server. Closing the server closes any open connections
and releases all server resources.

The close is actually asynchronous and might not complete until some time after the call has returned.
If you want to be notified when the actual close has completed then you can pass in a handler.

This handler will then be called when the close has fully completed.

[source,js]
----

server.close(function (res, res_err) {
  if (res_err == null) {
    console.log("Server is now closed");
  } else {
    console.log("close failed");
  }
});

----

=== Automatic clean-up in verticles

If you're creating TCP servers and clients from inside verticles, those servers and clients will be automatically closed
when the verticle is undeployed.

=== Scaling - sharing TCP servers

The handlers of any TCP server are always executed on the same event loop thread.

This means that if you are running on a server with a lot of cores, and you only have this one instance
deployed then you will have at most one core utilised on your server.

In order to utilise more cores of your server you will need to deploy more instances of the server.

You can instantiate more instances programmatically in your code:

[source,js]
----

// Create a few instances so we can utilise cores

for (var i = 0; i < 10; i++) {
  var server = vertx.createNetServer();
  server.connectHandler(function (socket) {
    socket.handler(function (buffer) {
      // Just echo back the data
      socket.write(buffer);
    });
  });
  server.listen(1234, "localhost");
}

----

or, if you are using verticles you can simply deploy more instances of your server verticle by using the `-instances` option
on the command line:

 vertx run com.mycompany.MyVerticle -instances 10

or when programmatically deploying your verticle

[source,js]
----

var options = {
  "instances" : 10
};
vertx.deployVerticle("com.mycompany.MyVerticle", options);

----

Once you do this you will find the echo server works functionally identically to before, but all your cores on your
server can be utilised and more work can be handled.

At this point you might be asking yourself *'How can you have more than one server listening on the
same host and port? Surely you will get port conflicts as soon as you try and deploy more than one instance?'*

_Vert.x does a little magic here.*_

When you deploy another server on the same host and port as an existing server it doesn't actually try and create a
new server listening on the same host/port.

Instead it internally maintains just a single server, and, as incoming connections arrive it distributes
them in a round-robin fashion to any of the connect handlers.

Consequently Vert.x TCP servers can scale over available cores while each instance remains single threaded.

=== Creating a TCP client

The simplest way to create a TCP client, using all default options is as follows:

[source,js]
----

var client = vertx.createNetClient();

----

=== Configuring a TCP client

If you don't want the default, a client can be configured by passing in a `link:../dataobjects.html#NetClientOptions[NetClientOptions]`
instance when creating it:

[source,js]
----

var options = {
  "connectTimeout" : 10000
};
var client = vertx.createNetClient(options);

----

=== Making connections

To make a connection to a server you use `link:../../jsdoc/module-vertx-js_net_client-NetClient.html#connect[connect]`,
specifying the port and host of the server and a handler that will be called with a result containing the
`link:../../jsdoc/module-vertx-js_net_socket-NetSocket.html[NetSocket]` when connection is successful or with a failure if connection failed.

[source,js]
----

var options = {
  "connectTimeout" : 10000
};
var client = vertx.createNetClient(options);
client.connect(4321, "localhost", function (res, res_err) {
  if (res_err == null) {
    console.log("Connected!");
    var socket = res;
  } else {
    console.log("Failed to connect: " + res_err.getMessage());
  }
});

----

=== Configuring connection attempts

A client can be configured to automatically retry connecting to the server in the event that it cannot connect.
This is configured with `link:../dataobjects.html#NetClientOptions#setReconnectInterval[reconnectInterval]` and
`link:../dataobjects.html#NetClientOptions#setReconnectAttempts[reconnectAttempts]`.

NOTE: Currently Vert.x will not attempt to reconnect if a connection fails, reconnect attempts and interval
only apply to creating initial connections.

[source,js]
----

var options = {
  "reconnectAttempts" : 10,
  "reconnectInterval" : 500
};

var client = vertx.createNetClient(options);

----

By default, multiple connection attempts are disabled.

[[logging_network_activity]]
=== Logging network activity

For debugging purposes, network activity can be logged:

[source,js]
----

var options = {
  "logActivity" : true
};

var server = vertx.createNetServer(options);

----

for the client

[source,js]
----

var options = {
  "logActivity" : true
};

var client = vertx.createNetClient(options);

----

Network activity is logged by Netty with the `DEBUG` level and with the `io.netty.handler.logging.LoggingHandler`
name. When using network activity logging there are a few things to keep in mind:

- logging is not performed by Vert.x logging but by Netty
- this is *not* a production feature

Netty will try to locate the following logger implementations, in the following order:

- Slf4j
- Log4j
- JDK

The presense of the slf4j or log4j classes on the classpath is enough to pick up the logging implementation.

The logger implementation can be forced to a specific implementation by setting Netty's internal logger implementation directly:

[source,java]
----
// Force logging to SLF4J
InternalLoggerFactory.setDefaultFactory(Log4JLoggerFactory.INSTANCE);
----

[[ssl]]
=== Configuring servers and clients to work with SSL/TLS

TCP clients and servers can be configured to use http://en.wikipedia.org/wiki/Transport_Layer_Security[Transport Layer Security]
- earlier versions of TLS were known as SSL.

The APIs of the servers and clients are identical whether or not SSL/TLS is used, and it's enabled by configuring
the `link:../dataobjects.html#NetClientOptions[NetClientOptions]` or `link:../dataobjects.html#NetServerOptions[NetServerOptions]` instances used
to create the servers or clients.

==== Enabling SSL/TLS on the server

SSL/TLS is enabled with  `link:../dataobjects.html#NetServerOptions#setSsl[ssl]`.

By default it is disabled.

==== Specifying key/certificate for the server

SSL/TLS servers usually provide certificates to clients in order verify their identity to clients.

Certificates/keys can be configured for servers in several ways:

The first method is by specifying the location of a Java key-store which contains the certificate and private key.

Java key stores can be managed with the http://docs.oracle.com/javase/6/docs/technotes/tools/solaris/keytool.html[keytool]
utility which ships with the JDK.

The password for the key store should also be provided:

[source,js]
----
var options = {
  "ssl" : true,
  "keyStoreOptions" : {
    "path" : "/path/to/your/server-keystore.jks",
    "password" : "password-of-your-keystore"
  }
};
var server = vertx.createNetServer(options);

----

Alternatively you can read the key store yourself as a buffer and provide that directly:

[source,js]
----
var myKeyStoreAsABuffer = vertx.fileSystem().readFileBlocking("/path/to/your/server-keystore.jks");
var jksOptions = {
  "value" : myKeyStoreAsABuffer,
  "password" : "password-of-your-keystore"
};
var options = {
  "ssl" : true,
  "keyStoreOptions" : jksOptions
};
var server = vertx.createNetServer(options);

----

Key/certificate in PKCS#12 format (http://en.wikipedia.org/wiki/PKCS_12), usually with the `.pfx`  or the `.p12`
extension can also be loaded in a similar fashion than JKS key stores:

[source,js]
----
var options = {
  "ssl" : true,
  "pfxKeyCertOptions" : {
    "path" : "/path/to/your/server-keystore.pfx",
    "password" : "password-of-your-keystore"
  }
};
var server = vertx.createNetServer(options);

----

Buffer configuration is also supported:

[source,js]
----
var myKeyStoreAsABuffer = vertx.fileSystem().readFileBlocking("/path/to/your/server-keystore.pfx");
var pfxOptions = {
  "value" : myKeyStoreAsABuffer,
  "password" : "password-of-your-keystore"
};
var options = {
  "ssl" : true,
  "pfxKeyCertOptions" : pfxOptions
};
var server = vertx.createNetServer(options);

----

Another way of providing server private key and certificate separately using `.pem` files.

[source,js]
----
var options = {
  "ssl" : true,
  "pemKeyCertOptions" : {
    "keyPath" : "/path/to/your/server-key.pem",
    "certPath" : "/path/to/your/server-cert.pem"
  }
};
var server = vertx.createNetServer(options);

----

Buffer configuration is also supported:

[source,js]
----
var myKeyAsABuffer = vertx.fileSystem().readFileBlocking("/path/to/your/server-key.pem");
var myCertAsABuffer = vertx.fileSystem().readFileBlocking("/path/to/your/server-cert.pem");
var pemOptions = {
  "keyValue" : myKeyAsABuffer,
  "certValue" : myCertAsABuffer
};
var options = {
  "ssl" : true,
  "pemKeyCertOptions" : pemOptions
};
var server = vertx.createNetServer(options);

----

Keep in mind that pem configuration, the private key is not crypted.

==== Specifying trust for the server

SSL/TLS servers can use a certificate authority in order to verify the identity of the clients.

Certificate authorities can be configured for servers in several ways:

Java trust stores can be managed with the http://docs.oracle.com/javase/6/docs/technotes/tools/solaris/keytool.html[keytool]
utility which ships with the JDK.

The password for the trust store should also be provided:

[source,js]
----
var options = {
  "ssl" : true,
  "clientAuth" : "REQUIRED",
  "trustStoreOptions" : {
    "path" : "/path/to/your/truststore.jks",
    "password" : "password-of-your-truststore"
  }
};
var server = vertx.createNetServer(options);

----

Alternatively you can read the trust store yourself as a buffer and provide that directly:

[source,js]
----
var myTrustStoreAsABuffer = vertx.fileSystem().readFileBlocking("/path/to/your/truststore.jks");
var options = {
  "ssl" : true,
  "clientAuth" : "REQUIRED",
  "trustStoreOptions" : {
    "value" : myTrustStoreAsABuffer,
    "password" : "password-of-your-truststore"
  }
};
var server = vertx.createNetServer(options);

----

Certificate authority in PKCS#12 format (http://en.wikipedia.org/wiki/PKCS_12), usually with the `.pfx`  or the `.p12`
extension can also be loaded in a similar fashion than JKS trust stores:

[source,js]
----
var options = {
  "ssl" : true,
  "clientAuth" : "REQUIRED",
  "pfxTrustOptions" : {
    "path" : "/path/to/your/truststore.pfx",
    "password" : "password-of-your-truststore"
  }
};
var server = vertx.createNetServer(options);

----

Buffer configuration is also supported:

[source,js]
----
var myTrustStoreAsABuffer = vertx.fileSystem().readFileBlocking("/path/to/your/truststore.pfx");
var options = {
  "ssl" : true,
  "clientAuth" : "REQUIRED",
  "pfxTrustOptions" : {
    "value" : myTrustStoreAsABuffer,
    "password" : "password-of-your-truststore"
  }
};
var server = vertx.createNetServer(options);

----

Another way of providing server certificate authority using a list `.pem` files.

[source,js]
----
var options = {
  "ssl" : true,
  "clientAuth" : "REQUIRED",
  "pemTrustOptions" : {
    "certPaths" : [
      "/path/to/your/server-ca.pem"
    ]
  }
};
var server = vertx.createNetServer(options);

----

Buffer configuration is also supported:

[source,js]
----
var myCaAsABuffer = vertx.fileSystem().readFileBlocking("/path/to/your/server-ca.pfx");
var options = {
  "ssl" : true,
  "clientAuth" : "REQUIRED",
  "pemTrustOptions" : {
    "certValues" : [
      myCaAsABuffer
    ]
  }
};
var server = vertx.createNetServer(options);

----

==== Enabling SSL/TLS on the client

Net Clients can also be easily configured to use SSL. They have the exact same API when using SSL as when using standard sockets.

To enable SSL on a NetClient the function setSSL(true) is called.

==== Client trust configuration

If the `link:../dataobjects.html#ClientOptionsBase#setTrustAll[trustALl]` is set to true on the client, then the client will
trust all server certificates. The connection will still be encrypted but this mode is vulnerable to 'man in the middle' attacks. I.e. you can't
be sure who you are connecting to. Use this with caution. Default value is false.

[source,js]
----
var options = {
  "ssl" : true,
  "trustAll" : true
};
var client = vertx.createNetClient(options);

----

If `link:../dataobjects.html#ClientOptionsBase#setTrustAll[trustAll]` is not set then a client trust store must be
configured and should contain the certificates of the servers that the client trusts.

By default, host verification is disabled on the client.
To enable host verification, set the algorithm to use on your client (only HTTPS and LDAPS is currently supported):


[source,js]
----
var options = {
  "ssl" : true,
  "hostnameVerificationAlgorithm" : "HTTPS"
};
var client = vertx.createNetClient(options);

----

Likewise server configuration, the client trust can be configured in several ways:

The first method is by specifying the location of a Java trust-store which contains the certificate authority.

It is just a standard Java key store, the same as the key stores on the server side. The client
trust store location is set by using the function `link:../dataobjects.html#JksOptions#setPath[path]` on the
`link:../dataobjects.html#JksOptions[jks options]`. If a server presents a certificate during connection which is not
in the client trust store, the connection attempt will not succeed.

[source,js]
----
var options = {
  "ssl" : true,
  "trustStoreOptions" : {
    "path" : "/path/to/your/truststore.jks",
    "password" : "password-of-your-truststore"
  }
};
var client = vertx.createNetClient(options);

----

Buffer configuration is also supported:

[source,js]
----
var myTrustStoreAsABuffer = vertx.fileSystem().readFileBlocking("/path/to/your/truststore.jks");
var options = {
  "ssl" : true,
  "trustStoreOptions" : {
    "value" : myTrustStoreAsABuffer,
    "password" : "password-of-your-truststore"
  }
};
var client = vertx.createNetClient(options);

----

Certificate authority in PKCS#12 format (http://en.wikipedia.org/wiki/PKCS_12), usually with the `.pfx`  or the `.p12`
extension can also be loaded in a similar fashion than JKS trust stores:

[source,js]
----
var options = {
  "ssl" : true,
  "pfxTrustOptions" : {
    "path" : "/path/to/your/truststore.pfx",
    "password" : "password-of-your-truststore"
  }
};
var client = vertx.createNetClient(options);

----

Buffer configuration is also supported:

[source,js]
----
var myTrustStoreAsABuffer = vertx.fileSystem().readFileBlocking("/path/to/your/truststore.pfx");
var options = {
  "ssl" : true,
  "pfxTrustOptions" : {
    "value" : myTrustStoreAsABuffer,
    "password" : "password-of-your-truststore"
  }
};
var client = vertx.createNetClient(options);

----

Another way of providing server certificate authority using a list `.pem` files.

[source,js]
----
var options = {
  "ssl" : true,
  "pemTrustOptions" : {
    "certPaths" : [
      "/path/to/your/ca-cert.pem"
    ]
  }
};
var client = vertx.createNetClient(options);

----

Buffer configuration is also supported:

[source,js]
----
var myTrustStoreAsABuffer = vertx.fileSystem().readFileBlocking("/path/to/your/ca-cert.pem");
var options = {
  "ssl" : true,
  "pemTrustOptions" : {
    "certValues" : [
      myTrustStoreAsABuffer
    ]
  }
};
var client = vertx.createNetClient(options);

----

==== Specifying key/certificate for the client

If the server requires client authentication then the client must present its own certificate to the server when
connecting. The client can be configured in several ways:

The first method is by specifying the location of a Java key-store which contains the key and certificate.
Again it's just a regular Java key store. The client keystore location is set by using the function
`link:../dataobjects.html#JksOptions#setPath[path]` on the
`link:../dataobjects.html#JksOptions[jks options]`.

[source,js]
----
var options = {
  "ssl" : true,
  "keyStoreOptions" : {
    "path" : "/path/to/your/client-keystore.jks",
    "password" : "password-of-your-keystore"
  }
};
var client = vertx.createNetClient(options);

----

Buffer configuration is also supported:

[source,js]
----
var myKeyStoreAsABuffer = vertx.fileSystem().readFileBlocking("/path/to/your/client-keystore.jks");
var jksOptions = {
  "value" : myKeyStoreAsABuffer,
  "password" : "password-of-your-keystore"
};
var options = {
  "ssl" : true,
  "keyStoreOptions" : jksOptions
};
var client = vertx.createNetClient(options);

----

Key/certificate in PKCS#12 format (http://en.wikipedia.org/wiki/PKCS_12), usually with the `.pfx`  or the `.p12`
extension can also be loaded in a similar fashion than JKS key stores:

[source,js]
----
var options = {
  "ssl" : true,
  "pfxKeyCertOptions" : {
    "path" : "/path/to/your/client-keystore.pfx",
    "password" : "password-of-your-keystore"
  }
};
var client = vertx.createNetClient(options);

----

Buffer configuration is also supported:

[source,js]
----
var myKeyStoreAsABuffer = vertx.fileSystem().readFileBlocking("/path/to/your/client-keystore.pfx");
var pfxOptions = {
  "value" : myKeyStoreAsABuffer,
  "password" : "password-of-your-keystore"
};
var options = {
  "ssl" : true,
  "pfxKeyCertOptions" : pfxOptions
};
var client = vertx.createNetClient(options);

----

Another way of providing server private key and certificate separately using `.pem` files.

[source,js]
----
var options = {
  "ssl" : true,
  "pemKeyCertOptions" : {
    "keyPath" : "/path/to/your/client-key.pem",
    "certPath" : "/path/to/your/client-cert.pem"
  }
};
var client = vertx.createNetClient(options);

----

Buffer configuration is also supported:

[source,js]
----
var myKeyAsABuffer = vertx.fileSystem().readFileBlocking("/path/to/your/client-key.pem");
var myCertAsABuffer = vertx.fileSystem().readFileBlocking("/path/to/your/client-cert.pem");
var pemOptions = {
  "keyValue" : myKeyAsABuffer,
  "certValue" : myCertAsABuffer
};
var options = {
  "ssl" : true,
  "pemKeyCertOptions" : pemOptions
};
var client = vertx.createNetClient(options);

----

Keep in mind that pem configuration, the private key is not crypted.

==== Revoking certificate authorities

Trust can be configured to use a certificate revocation list (CRL) for revoked certificates that should no
longer be trusted. The `link:../dataobjects.html#NetClientOptions#addCrlPath[crlPath]` configures
the crl list to use:

[source,js]
----
var options = {
  "ssl" : true,
  "trustStoreOptions" : trustOptions,
  "crlPaths" : [
    "/path/to/your/crl.pem"
  ]
};
var client = vertx.createNetClient(options);

----

Buffer configuration is also supported:

[source,js]
----
var myCrlAsABuffer = vertx.fileSystem().readFileBlocking("/path/to/your/crl.pem");
var options = {
  "ssl" : true,
  "trustStoreOptions" : trustOptions,
  "crlValues" : [
    myCrlAsABuffer
  ]
};
var client = vertx.createNetClient(options);

----

==== Configuring the Cipher suite

By default, the TLS configuration will use the Cipher suite of the JVM running Vert.x. This Cipher suite can be
configured with a suite of enabled ciphers:

[source,js]
----
var options = {
  "ssl" : true,
  "keyStoreOptions" : keyStoreOptions,
  "enabledCipherSuites" : [
    "ECDHE-RSA-AES128-GCM-SHA256",
    "ECDHE-ECDSA-AES128-GCM-SHA256",
    "ECDHE-RSA-AES256-GCM-SHA384",
    "CDHE-ECDSA-AES256-GCM-SHA384"
  ]
};
var server = vertx.createNetServer(options);

----

Cipher suite can be specified on the `link:../dataobjects.html#NetServerOptions[NetServerOptions]` or `link:../dataobjects.html#NetClientOptions[NetClientOptions]` configuration.

==== Configuring TLS protocol versions

By default, the TLS configuration will use the following protocol versions: SSLv2Hello, TLSv1, TLSv1.1 and TLSv1.2. Protocol versions can be
configured by explicitly adding enabled protocols:

[source,js]
----
var options = {
  "ssl" : true,
  "keyStoreOptions" : keyStoreOptions,
  "enabledSecureTransportProtocols" : [
    "TLSv1.1",
    "TLSv1.2"
  ]
};
var server = vertx.createNetServer(options);

----

Protocol versions can be specified on the `link:../dataobjects.html#NetServerOptions[NetServerOptions]` or `link:../dataobjects.html#NetClientOptions[NetClientOptions]` configuration.

==== SSL engine

The engine implementation can be configured to use https://www.openssl.org[OpenSSL] instead of the JDK implementation.
OpenSSL provides better performances and CPU usage than the JDK engine, as well as JDK version independence.

The engine options to use is

- the `link:../dataobjects.html#TCPSSLOptions#getSslEngineOptions[getSslEngineOptions]` options when it is set
- otherwise `link:../dataobjects.html#JdkSSLEngineOptions[JdkSSLEngineOptions]`

[source,js]
----

// Use JDK SSL engine
var options = {
  "ssl" : true,
  "keyStoreOptions" : keyStoreOptions
};

// Use JDK SSL engine explicitly
options = {
  "ssl" : true,
  "keyStoreOptions" : keyStoreOptions,
  "jdkSslEngineOptions" : {
  }
};

// Use OpenSSL engine
options = {
  "ssl" : true,
  "keyStoreOptions" : keyStoreOptions,
  "openSslEngineOptions" : {
  }
};

----

==== Application-Layer Protocol Negotiation

ALPN is a TLS extension for applicationl layer protocol negotitation. It is used by HTTP/2: during the TLS handshake
the client gives the list of application protocols it accepts and the server responds with a protocol it supports.

Java 8 does not supports ALPN out of the box, so ALPN should be enabled by other means:

- _OpenSSL_ support
- _Jetty-ALPN_ support

The engine options to use is

- the `link:../dataobjects.html#TCPSSLOptions#getSslEngineOptions[getSslEngineOptions]` options when it is set
- `link:../dataobjects.html#JdkSSLEngineOptions[JdkSSLEngineOptions]` when ALPN is available for JDK
- `link:../dataobjects.html#OpenSSLEngineOptions[OpenSSLEngineOptions]` when ALPN is available for OpenSSL
- otherwise it fails

===== OpenSSL ALPN support

OpenSSL provides native ALPN support.

OpenSSL requires to configure `link:../dataobjects.html#TCPSSLOptions#setOpenSslEngineOptions[openSslEngineOptions]`
and use http://netty.io/wiki/forked-tomcat-native.html[netty-tcnative] jar on the classpath. Using tcnative may require
OpenSSL to be installed on your OS depending on the tcnative implementation.

OpenSSL restricts the key/certificate configuration to `.pem` files. However it is still possible to use any trust
configuration.

===== Jetty-ALPN support

Jetty-ALPN is a small jar that overrides a few classes of Java 8 distribution to support ALPN.

The JVM must be started with the _alpn-boot-${version}.jar_ in its `bootclasspath`:

----
-Xbootclasspath/p:/path/to/alpn-boot${version}.jar
----

where ${version} depends on the JVM version, e.g. _8.1.7.v20160121_ for _OpenJDK 1.8.0u74_ . The complete
list is available on the http://www.eclipse.org/jetty/documentation/current/alpn-chapter.html[Jetty-ALPN page].

The main drawback is that the version depends on the JVM.

To solve this problem the _https://github.com/jetty-project/jetty-alpn-agent[Jetty ALPN agent]_ can be use instead. The agent is a JVM agent that will chose the correct
ALPN version for the JVM running it:

----
-javaagent:/path/to/alpn/agent
----

=== Using a proxy for client connections

The `link:../../jsdoc/module-vertx-js_net_client-NetClient.html[NetClient]` supports either a HTTP/1.x _CONNECT_, _SOCKS4a_ or _SOCKS5_ proxy.

The proxy can be configured in the `link:../dataobjects.html#NetClientOptions[NetClientOptions]` by setting a
`link:../dataobjects.html#ProxyOptions[ProxyOptions]` object containing proxy type, hostname, port and optionally username and password.

Here's an example:

[source,js]

----
var options = {
  "proxyOptions" : {
    "type" : "SOCKS5",
    "host" : "localhost",
    "port" : 1080,
    "username" : "username",
    "password" : "secret"
  }
};
var client = vertx.createNetClient(options);

----

The DNS resolution is always done on the proxy server, to achieve the functionality of a SOCKS4 client, it is necessary
to resolve the DNS address locally.