# Device communication protocols
Amazon IoT Core supports devices and clients that use the MQTT and the MQTT over WebSocket Secure (WSS) protocols to publish and subscribe to messages, and devices and clients that use the HTTPS protocol to publish messages. All protocols support IPv4 and IPv6. This section describes the different connection options for devices and clients.
## TLS protocol versions
Amazon IoT Core uses [TLS](https://en.wikipedia.org/wiki/Transport_Layer_Security) [version 1.2](https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.2) and [TLS version 1.3](https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.3) to encrypt all communication. You can configure additional TLS policy versions for your endpoint by [configuring TLS settings in domain configurations](https://docs.amazonaws.cn//iot/latest/developerguide/iot-endpoints-tls-config.html). When connecting devices to Amazon IoT Core, clients can send the [Server Name Indication (SNI) extension](https://tools.ietf.org/html/rfc3546#section-3.1), which is required for features such as [multi-account registration](https://docs.amazonaws.cn//iot/latest/developerguide/x509-client-certs.html#multiple-account-cert), [configurable endpoints](https://docs.amazonaws.cn//iot/latest/developerguide/iot-custom-endpoints-configurable.html), [custom domains](https://docs.amazonaws.cn//iot/latest/developerguide/iot-custom-endpoints-configurable-custom.html), and [VPC endpoints](https://docs.amazonaws.cn//iot/latest/developerguide/IoTCore-VPC.html). For more information, see [Transport Security in Amazon IoT](transport-security.html).
The [Amazon IoT Device SDKs](iot-connect-devices.md#iot-connect-device-sdks) support MQTT and MQTT over WSS and support the security requirements of client connections. We recommend using the [Amazon IoT Device SDKs](iot-connect-devices.md#iot-connect-device-sdks) to connect clients to Amazon IoT.
## Protocols, port mappings, and authentication
How a device or client connects to the message broker is configurable using an [authentication type](#connection-protocol-auth-mode). By default or when no SNI extension is sent, authentication method is based on application protocol, port, and Application Layer Protocol Negotiation (ALPN) TLS extension that devices use. The following table lists the authentication expected based on port, port, and ALPN.
**Protocols, authentication, and port mappings**
| Protocol | Operations supported | Authentication | Port | ALPN protocol name |
| --- | --- | --- | --- | --- |
| MQTT over WebSocket | Publish, Subscribe | Signature Version 4 | 443 | N/A |
| MQTT over WebSocket | Publish, Subscribe | Custom authentication | 443 | N/A |
| MQTT | Publish, Subscribe | X.509 client certificate | 443† | `x-amzn-mqtt-ca` |
| MQTT | Publish, Subscribe | X.509 client certificate | 8883 | N/A |
| MQTT | Publish, Subscribe | Custom authentication | 443† | `mqtt` |
| HTTPS | Publish only | Signature Version 4 | 443 | N/A |
| HTTPS | Publish only | X.509 client certificate | 443† | `x-amzn-http-ca` |
| HTTPS | Publish only | X.509 client certificate | 8443 | N/A |
| HTTPS | Publish only | Custom authentication | 443 | N/A |
**Application Layer Protocol Negotiation (ALPN)**
†When using default endpoint configurations, clients that connect on port 443 with X.509 client certificate authentication must implement the [Application Layer Protocol Negotiation (ALPN)](https://tools.ietf.org/html/rfc7301) TLS extension and use the [ALPN protocol name](https://tools.ietf.org/html/rfc7301#section-3.1) listed in the ALPN ProtocolNameList sent by the client as part of the `ClientHello` message.
On port 443, the [IoT:Data-ATS](iot-connect-devices.md#iot-connect-device-endpoint-table) endpoint supports ALPN x-amzn-http-ca HTTP, but the [IoT:Jobs](iot-connect-devices.md#iot-connect-device-endpoint-table) endpoint does not.
On port 8443 HTTPS and port 443 MQTT with ALPN x-amzn-mqtt-ca, [custom authentication](custom-authentication.md) can't be used.
Clients connect to their Amazon Web Services account's device endpoints. See [Amazon IoT device data and service endpoints](iot-connect-devices.md#iot-connect-device-endpoints) for information about how to find your account's device endpoints.
**Note**
Amazon SDKs don't require the entire URL. They only require the endpoint hostname such as the [`pubsub.py` sample for Amazon IoT Device SDK for Python on GitHub](https://github.com/aws/aws-iot-device-sdk-python-v2/blob/master/samples/pubsub.py#L100). Passing the entire URL as provided in the following table can generate an error such as invalid hostname.
**Connecting to Amazon IoT Core**
| Protocol | Endpoint or URL |
| --- | --- |
| MQTT | `iot-endpoint` |
| MQTT over WSS | `wss://iot-endpoint/mqtt` |
| HTTPS | `https://iot-endpoint/topics` |
## Choosing an application protocol for your device communication
For most IoT device communication through the device endpoints, you'll want to use the Secure MQTT or MQTT over WebSocket Secure (WSS) protocols; however, the device endpoints also support HTTPS.
The following table compares how Amazon IoT Core uses the two high-level protocols (MQTT and HTTPS) for device communication.
**Amazon IoT device protocols (MQTT and HTTPS) side-by-side**
| Feature | [MQTT](mqtt.md) | [HTTPS](http.md) |
| --- | --- | --- |
| Publish/Subscribe support | Publish and subscribe | Publish only |
| SDK support | [Amazon Device SDKs](iot-connect-devices.md#iot-connect-device-sdks) support MQTT and WSS protocols | No SDK support, but you can use language-specific methods to make HTTPS requests |
| Quality of Service support | [MQTT QoS levels 0 and 1](mqtt.md#mqtt-qos) | QoS is supported by passing a query string parameter ?qos=qos where the value can be 0 or 1. You can add this query string to publish a message with the QoS value you want. |
| Can receive messages be missed while device was offline | Yes | No |
| `clientId` field support | Yes | No |
| Device disconnection detection | Yes | No |
| Secure communications | Yes. See [Protocols, port mappings, and authentication](#protocol-mapping) | Yes. See [Protocols, port mappings, and authentication](#protocol-mapping) |
| Topic definitions | Application defined | Application defined |
| Message data format | Application defined | Application defined |
| Protocol overhead | Lower | Higher |
| Power consumption | Lower | Higher |
## Choosing an authentication type for your device communication
You can configure authentication type for your IoT endpoint using configurable endpoints. Alternatively, use default configuration and determine how your devices authenticate with application protocol, port, and ALPN TLS extension combination. The authentication type you choose determines how your devices will authenticate when connecting to Amazon IoT Core. There are five authentication types:
**X.509 certificate**
Authenticate devices using [X.509 client certificates](https://docs.amazonaws.cn//iot/latest/developerguide/x509-client-certs.html), which Amazon IoT Core validates to authenticate the device. This authentication type works with Secure MQTT (MQTT over TLS) and HTTPS protocols.
**X.509 certificate with custom authorizer**
Authenticate devices using [X.509 client certificates](https://docs.amazonaws.cn//iot/latest/developerguide/x509-client-certs.html) and perform additional authentication actions using a [custom authorizer](https://docs.amazonaws.cn//iot/latest/developerguide/config-custom-auth.html), which will receive X.509 client certificate information. This authentication type works with Secure MQTT (MQTT over TLS) and HTTPS protocols. This authentication type is only possible using configurable endpoints with X.509 custom authentication. There is no ALPN option.
**Amazon Signature Version 4 (SigV4)**
Authenticate devices using Cognito or your backend service, supporting social and enterprise federation. This authentication type works with MQTT over WebSocket Secure (WSS) and HTTPS protocols.
**Custom authorizer**
Authenticate devices by configuring a Lambda function to process custom authentication information sent to Amazon IoT Core. This authentication type works with Secure MQTT (MQTT over TLS) , HTTPS, and MQTT over WebSocket Secure (WSS) protocols.
**Default**
Authenticate devices based on the port and/or application layer protocol negotiation (ALPN) extension that devices use. Some additional authentication options are not supported. For more information, see [Protocols, port mappings, and authentication](#protocol-mapping).
The table below shows all the supported combinations of authentication types and application protocols.
**Supported combinations of authentication types and application protocols**
| Authentication type | Secure MQTT (MQTT over TLS) | MQTT over WebSocket Secure (WSS) | HTTPS | Default |
| --- | --- | --- | --- | --- |
| X.509 certificate | ✓ | | ✓ | |
| X.509 certificate with custom authorizer | ✓ | | ✓ | |
| Amazon Signature Version 4 (SigV4) | | ✓ | ✓ | |
| Custom authorizer | ✓ | ✓ | ✓ | |
| Default | | | | ✓ |
## Connection duration limits
HTTPS connections aren't guaranteed to last any longer than the time it takes to receive and respond to requests.
MQTT connection duration depends on the authentication feature that you use. The following table lists the maximum connection duration under ideal conditions for each feature.
**MQTT connection duration by authentication feature**
| Feature | Maximum duration \$1 |
| --- | --- |
| X.509 client certificate | 1–2 weeks |
| Custom authentication | 1–2 weeks |
| Signature Version 4 | Up to 24 hours |
\$1 Not guaranteed
With X.509 certificates and custom authentication, connection duration has no hard limit, but it can be as short as a few minutes. Connection interruptions can occur for various reasons. The following list contains some of the most common reasons.
+ Wi-Fi availability interruptions
+ Internet service provider (ISP) connection interruptions
+ Service patches
+ Service deployments
+ Service auto scaling
+ Unavailable service host
+ Load balancer issues and updates
+ Client-side errors
Your devices must implement strategies for detecting disconnections and reconnecting. For information about disconnect events and guidance on how to handle them, see [Connect/Disconnect events](life-cycle-events.md#connect-disconnect) in [Lifecycle events](life-cycle-events.md).