mirror of
https://github.com/open62541/open62541.git
synced 2025-06-03 04:00:21 +00:00
137 lines
7.1 KiB
ReStructuredText
137 lines
7.1 KiB
ReStructuredText
.. _protocol:
|
|
|
|
Protocol
|
|
========
|
|
|
|
In this section, we give an overview on the OPC UA binary protocol. We focus on
|
|
binary since that is what has been implemented in open62541. The TCP-based
|
|
binary protocol is by far the most common transport layer for OPC UA. The
|
|
general concepts also translate to HTTP and SOAP-based communication defined in
|
|
the standard. Communication in OPC UA is best understood by starting with the
|
|
following key principles:
|
|
|
|
Request / Response
|
|
All communication is based on the Request/Response pattern. Only clients can
|
|
send a request to a server. And servers can only send responses to a request.
|
|
Usually, the server is hosted on the (physical) device, such as a sensor or a
|
|
machine tool.
|
|
|
|
Asynchronous Responses
|
|
A server does not have to immediately respond to requests and responses may be
|
|
sent in a different order. This keeps the server responsive when it takes time
|
|
until a specific request has been processed (e.g. a method call or when
|
|
reading from a sensor with delay). Furthermore, Subscriptions (aka
|
|
push-notifications) are implemented via special requests where the response is
|
|
delayed until a notification is generated.
|
|
|
|
Establishing a Connection
|
|
-------------------------
|
|
|
|
A client-server connection in OPC UA consists of three nested levels: The raw
|
|
connection, a SecureChannel and the Session. For full details, see Part 6 of the
|
|
OPC UA standard.
|
|
|
|
Raw Connection
|
|
The raw connection is created by opening a TCP connection to the corresponding
|
|
hostname and port and an initial HEL/ACK handshake. The handshake establishes
|
|
the basic settings of the connection, such as the maximum message length.
|
|
|
|
SecureChannel
|
|
SecureChannels are created on top of the raw TCP connection. A SecureChannel
|
|
is established with an *OpenSecureChannel* request and response message pair.
|
|
**Attention!** Even though a SecureChannel is mandatory, encryption might
|
|
still be disabled. The *SecurityMode* of a SecureChannel can be either
|
|
``None``, ``Sign``, or ``SignAndEncrypt``. As of version 0.2 of open62541,
|
|
message signing and encryption is still under ongoing development.
|
|
|
|
With message signing or encryption enabled, the *OpenSecureChannel* messages
|
|
are encrypted using an asymmetric encryption algorithm (public-key
|
|
cryptography) [#key-mgmnt]_. As part of the *OpenSecureChannel* messages,
|
|
client and server establish a common secret over an initially unsecure
|
|
channel. For subsequent messages, the common secret is used for symmetric
|
|
encryption, which has the advantage of being much faster.
|
|
|
|
Different *SecurityPolicies* -- defined in part 7 of the OPC UA standard --
|
|
specify the algorithms for asymmetric and symmetric encryption, encryption key
|
|
lengths, hash functions for message signing, and so on. Example
|
|
SecurityPolicies are ``None`` for transmission of cleartext and
|
|
``Basic256Sha256`` which mandates a variant of RSA with SHA256 certificate
|
|
hashing for asymmetric encryption and AES256 for symmetric encryption.
|
|
|
|
The possible SecurityPolicies of a server are described with a list of
|
|
*Endpoints*. An endpoint jointly defines the SecurityMode, SecurityPolicy and
|
|
means for authenticating a session (discussed in the next section) in order to
|
|
connect to a certain server. The *GetEndpoints* service returns a list of
|
|
available endpoints. This service can usually be invoked without a session and
|
|
from an unencrypted SecureChannel. This allows clients to first discover
|
|
available endpoints and then use an appropriate SecurityPolicy that might be
|
|
required to open a session.
|
|
|
|
Session
|
|
Sessions are created on top of a SecureChannel. This ensures that users may
|
|
authenticate without sending their credentials, such as username and password,
|
|
in cleartext. Currently defined authentication mechanisms are anonymous login,
|
|
username/password, Kerberos and x509 certificates. The latter requires that
|
|
the request message is accompanied by a signature to prove that the sender is
|
|
in possession of the private key with which the certificate was created.
|
|
|
|
There are two message exchanges required to establish a session:
|
|
*CreateSession* and *ActicateSession*. The ActivateSession service can be used
|
|
to switch an existing session to a different SecureChannel. This is important,
|
|
for example when the connection broke down and the existing session is
|
|
reused with a new SecureChannel.
|
|
|
|
.. [#key-mgmnt] This entails that the client and server exchange so-called
|
|
public keys. The public keys might come with a certificate from a key-signing
|
|
authority or be verified against an external key repository. But we will not
|
|
discuss certificate management in detail in this section.
|
|
|
|
Structure of a protocol message
|
|
-------------------------------
|
|
|
|
For the following introduction to the structure of OPC UA protocol messages,
|
|
consider the example OPC UA binary conversation, recorded and displayed with the
|
|
`Wireshark <https://www.wireshark.org/>`_ tool, shown in :numref:`ua-wireshark`.
|
|
|
|
.. _ua-wireshark:
|
|
|
|
.. figure:: ua-wireshark.png
|
|
:figwidth: 100 %
|
|
:alt: OPC UA conversation in Wireshark
|
|
|
|
OPC UA conversation displayed in Wireshark
|
|
|
|
The top part of the Wireshark window shows the messages from the conversation in
|
|
order. The green line contains the applied filter. Here, we want to see the OPC
|
|
UA protocol messages only. The first messages (from TCP packets 49 to 56) show
|
|
the client opening an unencrypted SecureChannel and retrieving the server's
|
|
endpoints. Then, starting with packet 63, a new connection and SecureChannel are
|
|
created in conformance with one of the endpoints. On top of this SecureChannel,
|
|
the client can then create and activate a session. The following *ReadRequest*
|
|
message is selected and covered in more detail in the bottom windows.
|
|
|
|
The bottom left window shows the structure of the selected *ReadRequest*
|
|
message. The purpose of the message is invoking the *Read* :ref:`service
|
|
<services>`. The message is structured into a header and a message body. Note
|
|
that we do not consider encryption or signing of messages here.
|
|
|
|
Message Header
|
|
As stated before, OPC UA defines an asynchronous protocol. So responses may be
|
|
out of order. The message header contains some basic information, such as the
|
|
length of the message, as well as necessary information to relate messages to
|
|
a SecureChannel and each request to the corresponding response. "Chunking"
|
|
refers to the splitting and reassembling of messages that are longer than the
|
|
maximum network packet size.
|
|
|
|
Message Body
|
|
Every OPC UA :ref:`service <services>` has a signature in the form of a
|
|
request and response data structure. These are defined according to the OPC UA
|
|
protocol :ref:`type system <types>`. See especially the :ref:`auto-generated
|
|
type definitions<generated-types>` for the data types corresponding to service
|
|
requests and responses. The message body begins with the identifier of the
|
|
following data type. Then, the main payload of the message follows.
|
|
|
|
The bottom right window shows the binary payload of the selected *ReadRequest*
|
|
message. The message header is highlighted in light-grey. The message body in
|
|
blue highlighting shows the encoded *ReadRequest* data structure.
|