This TransportProtocolsends OPC UA Connection Protocol messages over WebSockets.

WebSockets is a bi-directional protocol for communication via a web server which is commonly used by browser based applications to allow the web server to asynchronously send information to the client. WebSockets uses the same default port as HTTP or HTTPS and initiates communication with an HTTP request. This makes it very useful in environments where firewalls limit traffic to the ports used by HTTP or HTTPS.

WebSockets use HTTP, however, in practice a WebSocket connection is only initiated with a HTTP GET request and the web server provides an HTTP response. After that exchange, all traffic uses the binary framing protocol defined by RFC 6455.

A Serverthat supports the WebSockets transport shall publish one or more Endpointswith the scheme ‘opc.wss’. The TransportProfileUrishall be one of the URIs for WebSockets transports defined in OPC 10000-7. The TransportProfileUri specifies the encoding and security protocol used to construct the OPC UA messages sent via the WebSocket.

The SecurityModeand SecurityPolicyUriof the Endpointcontrol the security applied to the messages sent via the WebSocket. This allows the messages to be secure even if the WebSocket connection is established via untrusted HTTPS proxies.

Figure 20summarizes the complete process for establishing communication over a WebSocket.


Figure 20– Setting up Communication over a WebSocket

Figure 20assumes the opcua+uacp protocol mapping (see 7.5.2).

The WebSocket protocol allows clients to request that servers use specific sub-protocols with the “Sec-WebSocket-Protocol” header in the WebSocket handshake defined in RFC 6455. The protocols defined by this document are shown in Table 71.

Table 71– WebSocket Protocols Mappings




Each WebSocket frame is a MessageChunkas defined in 6.7.2. After the WebSocket is created, the handshake described in 7.1.3is used to negotiate the maximum size of the MessageChunk. The maximum size for a buffer needed to receive a WebSocket frame is the maximum length of a MessageChunk plus the maximum size for the WebSocket frame header.

When using this protocol the payload in each frame is binary (OpCode 0x2 in RFC 6455).


Each WebSocket frame is a Messageencoded using the JSON encoding described in 5.4.9. There is no mechanism to negotiate the maximum frame size. If the receiver encounters a frame that exceeds its internal limits it shall close the WebSocket connection and provide a 1009 status code as described in RFC 6455.

When using this protocol the payload in each frame is text (OpCode 0x1 in RFC 6455).

Each WebSocket protocol mapping defined has a TransportProfileUridefined in OPC 10000-7.

The Clientshall request a protocol. If the Serverdoes not support the protocol requested by the Client,the Clientshall close the connection and report an error.

WebSockets requires that the Serverhave a Certificate, however, the Clientmay have a Certificate. The Server Certificateshould have the domain name as the common name component of the subject name however, Clientsthat are able to override the Certificatevalidation procedure can choose to accept Certificateswith a domain mismatch.

When using the WebSockets transport from a web browser the browser environment may impose additional restrictions. For example, the web browser may require the Serverhave a valid TLS Certificatethat is issued by CA that is installed in the Trust Listfor the web browser. To support these Clients,a Servermay use a TLS Certificatethat does not conform to the requirements for an ApplicationInstance Certificate. In these cases, the TLS Certificateis only used for TLS negotiation and the Servershall use a valid ApplicationInstance Certificate for other interactions that require one. Serversshall allow adminstrators to specify a Certificatefor use with TLS that is different from the ApplicationInstance Certificate.

Clientsrunning in a browser environment specify the ‘Origin’ HTTP header during the WebSocketupgrade handshake. Serversshould return the ‘Access-Control-Allow-Origin’ to indicate that the connection is allowed.

Any Clientthat does not run in a web browser environment and supports the WebSockets transport shall accept OPC UA Application Instance Certificateas the TLS Certificateprovided the correct domain is specified in the subjectAltNamefield.

A Clientmay use its Application Instance Certificate as the TLS Certificateand Serversshall accept those Certificatesif they are valid according to the OPC UA Certificatevalidation rules.

Some operating systems will not give the application any control over the set of algorithms that TLS will negotiate. In some cases, this set will be based on the needs of web browsers and will not be appropriate for the needs of an OPC UA Application. If this is a concern, applications should use OPC UA Secure Conversation in addition to TLS.

Clients that support the WebSocket transport shall support explicit configuration of an HTTPS proxy. When using an HTTPS proxy the Clientshall first send an HTTP CONNECT message (see HTTP) before starting the WebSocket protocol handshake. Note that explicit HTTPS proxies allow for man-in-the-middle attacks. This threat may be mitigated by using OPC UA Secure Conversation in addition to TLS.