The rise of cloud native (Cloud Native) , service-oriented architecture ( Service-Oriented Architecture, SOA ), microservice ( Microservice) , container ( Container ) and other related concepts and technologies are gradually affecting the architecture design and development of CAx ( CAD / CAE / CAM ) software .

In cloud-native CAx software, it is first necessary to divide the system into different service units according to functions , and then complete the integration of various services ( Enterprise Application Integration , EAI ) according to business processes . Web Services and Microservice are common ways to convert applications into services, and most of these technologies are actually based on HTTP .

Therefore, it is very necessary to summarize the basic knowledge of HTTP concepts and principles in order to better design and develop cloud-native CAx software .

Note 1: Limited to the research level, the analysis is inevitably inappropriate, criticism and correction are welcome .

Note 2: The content of the article will be updated from time to time .

1. HTTP basics

HTTP ( HyperText Transfer Protocol , Hypertext Transfer Protocol ) is an application layer protocol that adopts the " request-response " communication mode and runs on top of the TCP protocol. It was mainly used in HTML data transmission between Web servers and clients in the early days.

Ref. from Hypertext Transfer Protocol -- HTTP/1.1

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.

1.1 Working principle of HTTP

HTTP adopts the request-response communication mode, which is generally used for network communication between HTTP Client and HTTP Server in B/S architecture.

Ref. from HTTP/1.1 Overall Operation

The HTTP protocol is a request/response protocol. A client sends a request to the server in the form of a request method, URI, and protocol version, followed by a MIME-like message containing request modifiers, client information, and possible body content over a connection with a server. The server responds with a status line, including the message's protocol version and a success or error code, followed by a MIME-like message containing server information, entity metainformation, and possible entity-body content.

One or more intermediaries are present in the request/response chain. There are three common forms of intermediary: proxy, gateway, and tunnel.A proxy is a forwarding agent, receiving requests for a URI in its absolute form, rewriting all or part of the message, and forwarding the reformatted request toward the server identified by the URI. A gateway is a receiving agent, acting as a layer above some other server(s) and, if necessary, translating the requests to the underlying server's protocol. A tunnel acts as a relay point between two connections without changing the messages; tunnels are used when the communication needs to pass through an intermediary (such as a firewall) even when the intermediary cannot understand the contents of the messages.

First, the HTTP Client (usually a browser) creates a TCP connection to the specified port of the HTTP Server (port 80 by default), and then the HTTP Client sends an HTTP request message to the HTTP Server.

After the HTTP server receives the HTTP request message, it completes the analysis of the HTTP request message data message, executes the corresponding business logic, and then writes the status code and processing results into an HTTP response message, and returns the HTTP response message to the HTTP Client.

After the HTTP Client receives the HTTP response message, it completes the display, data storage and other work according to the return status and processing results.

1.2 HTTP data message

The HTTP request message consists of four parts: request line, request header, blank line, and request data.

The HTTP response message consists of four parts: status line, message header, blank line, and response body.

1.3 Browser Architecture

1.4 HTTP session persistence

The HTTP protocol itself is stateless . For browsers, generally one connection processes one request , and the connection is generally disconnected after completing a " request - response ". To the server, requests are independent of each other , and the server has no way of knowing the correlation between requests.

Ref. from HTTP/1.1 Connections

A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior of any HTTP connection. That is, unless otherwise indicated, the client SHOULD assume that the server will maintain a persistent connection, even after error responses from the server.

Cookie, Session and Token are commonly used session maintenance technologies.

For the content of this part, please pay attention to the author's blog post: Cloud native CAx software: multi-tenant certification

2. Realization and Derivation

2.1 Boost

Module	Description	Scenario
Beast	Portable HTTP, WebSocket, and network operations using only C++11 and Boost.Asio

2.2 Qt

Module	Description	Scenario
Qt Network	Classes to make network programming easier and more portable. Currently HTTP, FTP and local file URLs are supported for uploading and downloading.	It encapsulates sockets and implements common network protocols such as HTTP and FTP
Qt WebSockets	Provides WebSocket communication compliant with RFC 6455. It provides an implementation for the WebSocket protocol, which is offered by IETF (Internet Engineering Task Force) as a better alternative for bidirectional communication using the existing web infrastructure.	The server actively pushes data to the client
Qt WebChannel	Provides access to QObject or QML objects from HTML clients for seamless integration of Qt applications with HTML/JavaScript clients.	Qt-based Server application
Qt WebKit	The QtWebKit module provides a web browser engine as well as classes to render and interact with web content	In Qt5, replaced by Qt WebEngine
Qt WebEngine	Classes and functions for embedding web content in applications using the Chromium browser project.	As a Qt WebEngine replacement, display web content in the application
Qt WebView	Displays web content in a QML application by using APIs native to the platform, without the need to include a full web browser stack.	Display web content in a QML program
Qt for WebAssembly	A platform target to compile Qt applications for the web browsers using WebAssembly.	Embed Qt application into web page

2.3 MIME

2.4 DIME

2.5 WebSocket

Ref. from The WebSocket Protocol

The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections.

The protocol has two parts: a handshake and the data transfer.

The handshake from the client looks as follows:
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
The handshake from the server looks as follows:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat
After a successful handshake, clients and servers transfer data back and forth in conceptual units referred to in this specification as "messages". On the wire, a message is composed of one or more frames. The WebSocket message does not necessarily correspond to a particular network layer framing, as a fragmented message may be coalesced or split by an intermediary.
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len |    Extended payload length    |
|I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
|N|V|V|V|       |S|             |   (if payload len==126/127)   |
| |1|2|3|       |K|             |                               |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
|     Extended payload length continued, if payload len == 127  |
+ - - - - - - - - - - - - - - - +-------------------------------+
|                               |Masking-key, if MASK set to 1  |
+-------------------------------+-------------------------------+
| Masking-key (continued)       |          Payload Data         |
+-------------------------------- - - - - - - - - - - - - - - - +
:                     Payload Data continued ...                :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|                     Payload Data continued ...                |
+---------------------------------------------------------------+