CN114448652A

CN114448652A - Method, apparatus, device and storage medium for encrypted communication

Info

Publication number: CN114448652A
Application number: CN202011111131.9A
Authority: CN
Inventors: 杨文婷; 张少华; 史玉帅; 艾鑫; 苏仲谋; 贺俊凯; 马永涛; 周承浩; 易劲飞
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2020-10-16
Filing date: 2020-10-16
Publication date: 2022-05-06
Anticipated expiration: 2040-10-16
Also published as: CN114448652B

Abstract

Embodiments of the present invention relate to methods, apparatuses, computing devices and computer-readable storage media at a client for encrypted communication with a server. The method comprises the following steps: retrieving an encrypted protocol file, wherein the encrypted protocol file is obtained by encrypting a plain text protocol file, wherein the operations of encrypting comprise format conversion and packaging obfuscation, and wherein the plain text protocol file defines transmission rules for communication data; requesting a key to the server to restore the encrypted protocol file; and processing communication data to be sent to the server based on the transmission rule, or processing communication data received from the server for utilization by the client based on the transmission rule. By adopting the method of the invention, the security of the sending and receiving processes of the communication data between the client and the server can be ensured by encrypting the protocol file defining the communication transmission rule.

Description

Method, device, equipment and storage medium for encrypted communication

Technical Field

Embodiments of the present invention relate to communication security, and in particular, embodiments of the present invention relate to a method, apparatus, computing device, and computer-readable storage medium for encrypted communication with a server at a client.

Background

In the traditional communication process between the client and the server realized based on the Web technology, in order to solve the problem of unidirectional transmission of http, bidirectional communication between the client and the server based on the Websocket protocol is developed, so that the communication can not be initiated only by the client in a unidirectional way any more, and the server can actively send data to the client. At present, a WebSocket protocol is widely adopted in the industry, communication data are transmitted according to a protocol file in a plaintext format, and a third party can directly read the protocol file used for defining a transmission rule of the communication data, so that the protocol file is exposed to an external network.

On the premise of realizing the above efficient bidirectional communication, the communication security is also an important index for measuring the communication performance. Especially in the current diversified network application environment, the network client and the server need to communicate frequently to transfer various network data such as instant message, video on demand, service update, etc., and thus the communication security problem becomes increasingly significant.

Therefore, it is a technical problem to be solved by those skilled in the art to ensure efficient bidirectional communication between a client and a server, and to prevent protocol files from being exposed to an external network, so as to further prevent the server and its users from being attacked maliciously, thereby ensuring the security of communication.

Disclosure of Invention

In view of the above, embodiments of the present invention provide a method, an apparatus, a computing device and a computer-readable storage medium for performing encrypted communication with a server at a client to solve the above technical problems.

According to an aspect of the invention, there is provided a method at a client for encrypted communication with a server, the method comprising: calling an encrypted protocol file, wherein the encrypted protocol file is obtained by encrypting a plaintext protocol file, and the plaintext protocol file defines a transmission rule of communication data; requesting a key to the server to restore the encrypted protocol file; and processing communication data to be sent to the server based on the transmission rule, or processing communication data received from the server for utilization by the client based on the transmission rule.

In some embodiments, the encrypted protocol file is obtained by performing the following steps on the plain-text protocol file: carrying out format conversion on the protocol file of the plaintext; and packaging and confusing the protocol file after format conversion to obtain the encrypted protocol file.

In some embodiments, the step of performing format conversion comprises: js library is quoted to convert the Protocol file of the plaintext from the Protocol Buffer format into the js format.

In some embodiments, the step of performing package obfuscation comprises: carrying out character shifting on the protocol file after format conversion; and calling a Webpack tool to compress and pack the protocol file after the character shifting and the project file.

In some embodiments, invoking the Webpack tool for compression packaging comprises: performing parameter analysis on the protocol file after the character shifting; loading a compression plug-in; and performing the compiling and outputting the compiled code.

In some embodiments, processing communication data to be sent to the server based on the transmission rule comprises: generating communication data in a first data format according to the transmission rule; encoding the communication data in the first data format into communication data in a second data format according to the transmission rule; and sending the communication data in the second data format to the server.

In some embodiments, processing the communication data received from the server based on the transmission rule comprises: receiving communication data in a second data format from the server; decoding the communication data in the second data format into communication data in the first data format according to the transmission rule for utilization by the client.

In some embodiments, the communication data of the first data format is JSON data, and the communication data of the second data format is Protocol Buffer data.

In some embodiments, a protobuf. js library is referenced to process the communication data according to the transmission rule.

In some embodiments, prior to encrypted communication with the server, sending a connection request to the server to establish a communication channel, wherein the communication channel is based on a WebSocket transport protocol, and wherein the WebSocket transport protocol comprises any one of a WS protocol and a WSs protocol.

In some embodiments, when the communication channel is based on the WSS protocol, the communication channel is encrypted using Transport Layer Security (TLS).

According to another aspect of the present invention, there is provided an apparatus at a client for encrypted communication with a server, the apparatus comprising: a transceiver module for transmitting and receiving communication data to and from the server; the calling module is used for calling the encrypted protocol file, wherein the encrypted protocol file is obtained by encrypting a plaintext protocol file, and the plaintext protocol file defines the transmission rule of communication data; the request module is used for requesting the server to obtain a key so as to restore the encrypted protocol file; and the processing module is used for processing the communication data to be sent to the server based on the transmission rule or processing the communication data received from the server based on the transmission rule for the client to utilize.

In some embodiments, the processing module comprises: a generating unit configured to generate communication data in a first data format according to the transmission rule; and the encoding unit is used for encoding the communication data in the first data format into communication data in a second data format according to the transmission rule, wherein the transceiver module sends the communication data in the second data format to the server.

In some embodiments, the processing module comprises: a decoding unit, configured to decode, according to the transmission rule, communication data in a second data format into communication data in a first data format for the client to use, where the transceiver module receives the communication data in the second data format from the server.

In some embodiments, the apparatus further includes an initialization module configured to send, through the transceiving module, a connection request to the server to establish a communication channel before performing encrypted communication with the server, where the communication channel is based on a WebSocket transport protocol, and where the WebSocket transport protocol includes any one of a WS protocol and a WSs protocol.

According to yet another aspect of the present invention, there is provided a computing device comprising: a memory for storing a computer executable program; and a processor configured to execute the computer executable program stored on the memory to implement the method as described above.

According to yet another aspect of the present invention, there is provided a computer-readable storage medium having stored therein a computer-executable program, which is loadable and executable by a processor to implement a method as described above.

By implementing the technical scheme of the invention, the following beneficial technical effects can be obtained.

The embodiment of the invention adopts a mode of pre-encrypting the protocol file to carry out bidirectional encryption communication between the server and the client. Because the unencrypted protocol file has the potential safety hazard of leakage, the protocol file is subjected to format conversion and packaging confusion according to the embodiment of the invention, so that the protocol file is prevented from being directly exposed to an external network and intercepted by a third party. Meanwhile, the difficulty of the protocol file restored by a third party is greatly increased after the protocol file is packaged and confused, so that the encryption in the communication process of a user and the safety of a protocol are met.

The embodiment of the invention ensures that the client application program can run with high performance, meets the requirement of communication data transmission with large concurrency, and simultaneously effectively keeps the security of the transmission protocol, thereby avoiding the server and the user thereof from being attacked by a third party.

Drawings

Further details, features and advantages of the present invention will be disclosed in the following description of exemplary embodiments with reference to the accompanying drawings, in which:

FIG. 1 shows a schematic diagram of an application scenario according to an embodiment of the invention;

FIG. 2 illustrates a signaling flow diagram for establishing two-way communication between a client and a server in accordance with an embodiment of the present invention;

FIG. 3a shows a process flow diagram for sending data at a client to a server in accordance with an embodiment of the invention;

FIG. 3b illustrates a process flow diagram for receiving data at a client from a server in accordance with an embodiment of the present invention;

FIG. 4 is a schematic diagram illustrating serialization and deserialization of communication data between a client and a server in accordance with an embodiment of the present invention;

FIG. 5 illustrates a process flow diagram for encrypting and restoring a protocol file according to an embodiment of the invention;

FIG. 6 illustrates a comparison of encrypted communications at a client and server versus attacker and server communications, according to an embodiment of the invention;

FIG. 7 illustrates an application scenario of a client according to an embodiment of the present invention;

FIG. 8 illustrates a flow chart of a method at a client for encrypted communication with a server in accordance with an embodiment of the present invention;

FIG. 9 illustrates a block diagram of an example apparatus at a client for encrypted communication with a server, according to an embodiment of the invention;

FIG. 10 shows a schematic block diagram of a computing device according to an embodiment of the invention.

Detailed Description

The technical solution in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. It is to be understood that the described embodiments are merely exemplary of the invention, and not restrictive of the full scope of the invention. All other embodiments, which can be obtained by a person skilled in the art without any inventive step based on the embodiments of the present invention, are within the scope of the present invention.

It should be noted that the terms "first," "second," and "third," etc. in the description and claims of the present invention and the above-described drawings are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the terms so used are interchangeable under appropriate circumstances such that the embodiments of the invention described herein are, for example, capable of operation in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, apparatus, article, or device that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or device.

In order to make the objects, technical solutions and advantages disclosed in the embodiments of the present invention more clearly apparent, the embodiments of the present invention are described in further detail below with reference to the accompanying drawings and the embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the embodiments of the invention and are not intended to limit the embodiments of the invention. First, the embodiments of the present invention explain the following concepts.

HTTP is a communication protocol that can acquire network resources such as HTML. It is the basis for data exchange over the Web and is a client-server protocol, i.e., requests are typically initiated by a recipient, such as a client (e.g., a browser). A complete Web document is usually composed of different sub-documents, such as text, layout descriptions, pictures, video, scripts, etc. HTTP is an application layer protocol, sent over a TCP or TLS encrypted TCP connection. Because HTTP has good extensibility, it is used not only to transmit hypertext documents, but also to transmit pictures, videos, or to send information such as HTML forms to a server. In addition, HTTP can update a Web page by only obtaining a portion of the content of the Web document, as needed by the Web page.

WebSocket: is a network transport protocol that enables full duplex communication over a single TCP connection and is located at the application layer of the OSI model. The WebSocket protocol is standardized by IETF to RFC 6455 in 2011 and then supplemented by RFC 7936. WebSocket makes data exchange between a client and a server simpler, because it allows the server to actively push data to the client. In the WebSocket API, the browser and the server only need to complete one handshake, and persistent connection can be established between the browser and the server, and bidirectional data transmission is carried out.

WS protocol and WSS protocol: are all branches of the WebSocket protocol, and are both uniform resource identifiers, similar to the HTTP protocol and the HTTPs protocol. The difference is that the former is non-secure and the latter is secure. Since the WS protocol has no certificates, whereas the WSs protocol requires SSL (secure sockets layer) certificates. SSL is developed by Netscape and used for guaranteeing the safety of data transmission in a network, and mainly adopts a data encryption technology to prevent data from being stolen or monitored in the transmission process. Where WSS denotes WebSocket on top of TLS (transport layer security). WS generally defaults to 80 ports and WSs defaults to 443 ports, which are the 80 and 433 ports used by most websites. The incarnations of WS and WSS are TCP + WS and TCP + TLS + WS, respectively.

JavaScript: the method is a lightweight, interpretative or just-in-time compiling programming language with function priority, and belongs to a scripting language of a network. JavaScript has been widely used in Web application development, and is often used to add various dynamic functions to a Web page, so as to provide a smoother and more beautiful browsing effect for a user. Usually, JavaScript scripts are embedded in HTML to implement their functions.

JSON is a lightweight data exchange language that is based on easily readable text for transmitting data objects consisting of attribute values or sequential values. Although JSON is a subset of JavaScript, JSON is a language independent text format and employs some conventions similar to the C language family. The JSON data format is language independent. Even though it is derived from JavaScript, many programming languages currently support the generation and parsing of JSON-formatted data. The official MIME type of JSON is application/JSON and the file extension is JSON.

Protocol Buffer: is a protocol for serializing data structures suitable for program development for communicating through pipeline (pipeline) or storage data. The program development includes an interface description language for describing specific data structures and providing programming tools for generating code based on the descriptions and for generating or parsing data streams based on the data structures.

Js: the third party's a library for the JS environment for compiling Protocol Buffer Protocol files, which can be compiled into JS files or json files, or vice versa. The system supports two languages of JavaScript and TypeScript and can run in a Node environment and a browser.

Js: the JavaScript operating environment is capable of enabling the JavaScript to run away from the browser.

Webpack: is an open source front end packaging tool. Webpack provides a modular development approach lacking in front-end development, treats various static resources as modules, and generates optimized code from it. Webpack can set functions from the terminal, or change Webpack. Node. js needs to be pre-installed before Webpack is used. Webpack converts resources into modules by using a loader. Developers can customize the sequence and format of the loader to meet the requirements of the development project.

The present invention recognizes that an important aspect in communication security is securing protocol files used to transfer data. The protocol file defines an interface of a transmission process and relevant parameters of the interface, and defines a compiling rule of transmission data so that the client and the server can effectively identify information transmitted by the two parties. However, if the protocol file is intercepted by a malicious third party, the protocol file can send the message caused by the attack code to the server or other clients directly according to the rules in the protocol file, so that various forms of malicious attacks on the server or other clients can be realized. For example, a third party that obtains the protocol file may forge a huge amount of invalid information into a legitimate message to be sent to the server, causing congestion on the server side, and thus breaking down the entire transmission process. Therefore, the invention provides a technical scheme for encrypting the protocol file so as to prevent the clear protocol file from being exposed to an external network and intercepted by a third party, thereby improving the secure two-way communication between the client and the server. Detailed embodiments will be provided below with reference to the accompanying drawings.

Fig. 1 is a schematic diagram illustrating an application scenario according to an embodiment of the present invention. As shown in fig. 1, this application scenario involves the following example: a local terminal 110, a remote server 120, which is connected to the local terminal 110 by wire and/or wirelessly, and remote terminals 130-1, 130-2, … …, 130-N, which are connected to the remote server 120 in the same manner or in different manners, respectively, and are each other's counterpart. In one or more embodiments, local terminal 110 may communicate in real time with one or more remote terminals 130 via remote server 120.

In various embodiments, terminals 110 and 130 may assume a variety of different configurations. For example, the terminals 110 and 130 may be implemented as computer-like devices including personal computers, desktop computers, multi-screen computers, laptop computers, netbooks, and so forth. The terminals 110 and 130 may also be implemented as mobile device-like devices including mobile devices such as mobile phones, portable music players, portable game devices, tablet computers, multi-screen computers, and the like. Terminals 110 and 130 may also be implemented as television-like devices that include or are connected to devices having, or generally larger screens in casual viewing environments. These devices include televisions, set-top boxes, game consoles, and the like.

The techniques described herein may be supported by various configurations of terminals 110 and 130 and are not limited to specific examples of the techniques described herein. Terminals 110 and 130 may also interact with a variety of servers 120. In one embodiment, the server 120 may be implemented as a stand-alone server or a server cluster comprised of multiple servers. In another embodiment, the server 120 may be deployed as a cloud to execute applications and/or data that may be used in computer processing. Server 120 may connect terminals 110 and 130 and other computing devices with abstract resources and functions.

According to one or more embodiments of the present invention, under the support of the WebSocket protocol, when the local terminal 110 opens the continuous communication channel with the remote server 120, not only the local terminal 110 may actively send a message to the remote server 120, but also the remote server 120 may actively send a message or forward a message from the remote terminal 130 to the local terminal 110, thereby implementing bidirectional communication between the local terminal 110 and the remote server 120, and further implementing communication between multiple users (i.e., the local terminal and the multiple remote terminals) with a large amount of concurrency.

By using the techniques provided by embodiments of the present invention, the client running on the local terminal 110 may act as an administrator and a receiver to ensure that the protocol file is not exposed, so as to secure the communication between the local terminal 110 and the remote server 120.

The communication method implemented by the client running on the local terminal 110 and the embodied project code are further illustrated in fig. 2-4 (in one embodiment of the invention, the project code is saved in a js file format). The protocol file (in one embodiment of the present invention, the proto file format is embodied in the form of plaintext) defining the above communication transmission rule is converted into a js file format, and is packed and obfuscated together with the item code after being shifted by characters (the packing and obfuscating process is further illustrated in fig. 5), and then is issued to the external network in the form of an installation package for each user (i.e., client) to download and install.

The protocol file defining the communication transmission rule may contain a plurality of interface parameters, and various communication data may be processed according to different interface parameters. In one or more embodiments, the plurality of interface parameters may include, but are not limited to: server type, server domain name, server ID, server IP address, server port, server name, server latency, server packet loss rate, etc.

In one or more embodiments, a user downloads the client's installation package locally over the network and installs it. However, the protocol files in the installation package are encrypted by the developer before being released (i.e., format conversion and package confusion), so that the encrypted protocol files are just a string of unrecognizable characters for each user and cannot be deciphered or decompiled. That is, the user cannot see the protocol file in the clear through the installation package of the client, cannot know the interface parameters therein (i.e., a series of transmission rules of the communication data to be sent to and/or received from the server are invisible to the user or a third party), and thus exposure of the protocol file is prevented. Only when the installation package of the application program is executed on the client, the encrypted protocol file is called from the inside of the program, so that the interface parameters in the protocol file can be analyzed, the bidirectional communication between the client and the server is realized according to the interface parameters, and the safety of the bidirectional communication process is further ensured. Because an attacker cannot decipher the protocol file even if the attacker downloads the installation package of the client from the internet, the identity of the legal user cannot be forged to communicate with the server, and therefore, the interface security of the server and the information security of other users are further guaranteed.

Fig. 2 shows a signaling flow diagram for establishing bidirectional communication between a client and a server based on the WebSocket protocol according to an embodiment of the present invention. First, a client application is initialized at a client. Specifically, a client initiates a connection request to a server. In one embodiment, initiating a connection request may initiate a connection by way of a domain name ("WSS:// www.xx.com") under WSS protocol conditions. After receiving the connection request of the client, the server sends a confirmation response message of successful connection to the client, so that the two parties realize first two-way handshake, and a two-way connection communication channel is successfully established. In another embodiment, if the client does not successfully receive the acknowledgement response message of successful connection transmitted by the server, the client may resend the connection request until successful connection.

After the initialization is completed, the client establishes a successful bidirectional connection with the server, and at the moment, the server can actively send a message to the client, and the client can also actively send a message to the server. In accordance with one or more embodiments, during two-way communication between a client and a server, an encrypted two-way communication channel is established using TLS encryption techniques based on the WSS protocol, wherein messages are transmitted in the encrypted two-way communication channel.

An example of code used in establishing two-way communication between a client and a server is given below. It is to be understood that the present invention is not limited to the specific form of the following example, and the communication establishment procedure described above may be implemented by other code forms, especially for communication establishment procedures based on other communication protocols (e.g., WS protocol).

1) Newly building a WebSocket and connecting a server:

ws = new WebSocket(_domain);

where domain refers to a domain name that when the client application is initialized, a connection request is initiated by the client to the server, connecting under the wss transport protocol in the manner of a domain name (e.g., "wss:// www.xx.com").

2) The monitoring connection successfully sends the Hello packet to keep being connected all the time:

ws.onopen = () => {

sendHello();

};

as described above, after a two-way communication channel is established between a client and a server, the communication channel remains active, such as by sending a Hello packet when the client is idle to maintain communication connectivity between the two parties. According to one or more embodiments of the invention, the communication between the client and the server is based on a Protocol Buffer transmission process, wherein data is transmitted in binary form. According to one or more embodiments of the invention, the server may also end communication with the client in response to a connection termination request of the client.

Fig. 3a shows a flowchart of a process implemented at a client for sending data to a server, according to an embodiment of the invention. According to one or more embodiments of the present invention, bidirectional communication is implemented between the client and the server based on a Protocol Buffer transmission process, so that before data is sent to the server, the client needs to encode the data to be transmitted based on a Protocol Buffer transmission Protocol.

Before sending communication data to the server, the client first writes a data format meeting the requirements according to the rules formulated by the protocol file in step 301 a. Specifically, communication data meeting the transmission requirement is generated according to the data transmission rule formulated by the protocol file by calling the packed and confused encrypted transmission protocol file. In an embodiment of the present invention, the communication data may be JSON data. Js library by calling create function in protocol to generate the data format required by the protocol file according to the protocol rule.

According to an embodiment of the present invention, in step 302a, after generating the data format to be transmitted specified by the protocol file, the client further converts the data into a binary data format based on the protocol rule. In an embodiment of the invention, the data to be transmitted is converted into binary data through a serialization process by calling an encode function in a protobuf. The serialization of the transmitted data will be explained in further detail in fig. 4 of the present invention.

According to an embodiment of the invention, at step 303a, the converted binary data is transmitted from the client to the server. Specifically, under the WebSocket transport protocol, data is transmitted to the server through an encrypted communication channel.

An example of code implemented at a client for a process of sending data to a server is given below. It is to be understood that the present invention is not limited to the specific form of the following example, and the above data transmission process may be implemented by other code forms, especially for communication processes based on other communication protocols (such as WS protocol).

1) And (2) quoting a protobuf.js library to convert the proto protocol file into a js protocol file and calling:

pbjs -t static-module -w commonjs -o proto.js CSMsg.proto

import protoRoot from "../api/proto";

import RegExpExec from "es-abstract/2015/RegExpExec";

2) calling a callback function:

const sendToServer = (params: any) => {

if (params.callback) {

callbackFunc = params.callback;

}

};

3) writing a data format according to a protocol:

let reqData = {

Head: {

MsgID: (protoRoot as any).CSMSGID[params.msgId],

Uin: hostUin,

Token: token,

},

MsgPara: params.data,

};

4) converting data into binary data:

let WSMessage = (protoRoot as any).CSMsg;

let wsmessage = WSMessage.create(reqData);

let buffer = WSMessage.encode(wsmessage).finish();

5) and (3) transmitting by using a Websocket transmission protocol:

try {

ws.send(buffer);

} catch (error) {

if (error.indexOf('Still is CONNECTING') > -1) {

console.log(error);

clearInterval(networkErrorTimer);

clearInterval(reconnectTimer);

} else {

console.log(error);

onNetworkDown();

}

FIG. 3b illustrates a flowchart of a process implemented at a client for receiving data from a server, according to an embodiment of the invention. In step 301b, the client receives data from the server. In one or more embodiments of the invention, the communication between the client and the server is based on a Protocol Buffer data transmission process, wherein data is transmitted in binary form. The client cannot directly use the binary data, and thus further parsing of the received binary data is required.

In step 302b, the client parses the received binary data into data recognizable by the client, such as JSON data format. And in the analysis process, calling the protobuf.js library and the Web API again, and performing deserialization on the binary data to generate data which can be identified by the client. The process of deserializing binary data will be discussed in further detail in FIG. 4 of the present invention.

According to an embodiment of the invention, after receiving data transmitted by a server, a client creates a FileReader object, reads a binary file by using a readAsArrayBuffer API contained in the FileReader, and analyzes the binary data into object data which can be identified and operated by the client through a decode function of protobuf. Specifically, the process may be implemented by example code forms as shown below:

ws.onmessage = function (event: any) {

let serverRes = (protoRoot as any).CSMsg;

let reader: any = new FileReader();

reader.readAsArrayBuffer(event.data);

reader.onload = function (e: any) {

let buf = new Uint8Array(reader.result);

let resData = serverRes.decode(buf);

}

it is to be understood that the present invention is not limited to the specific form illustrated above, and the data parsing process described above can be implemented by other code forms, especially for communication processes based on other communication protocols (such as WS protocol).

FIG. 4 illustrates a schematic diagram of performing serialization and deserialization of communication data between a client and a server in accordance with an embodiment of the present invention. According to one or more embodiments of the invention, the data is converted into binary data before the client transmits to the server, and this process can be implemented in the invention by performing the following serialization on the data. Specifically, the serialization process of the communication data is realized by performing the following operations on the data meeting the protocol requirements obtained in step 301 a:

1) selecting a data transmission interface:

let WSMessage = (protoRoot as any).CSMsg;

2) newly building an interface object:

let wsmessage = WSMessage.create(reqData);

3) encoding data:

let buffer = WSMessage.encode(wsmessage).finish();

the specific encoding mode can be realized by the following codes:

CSMsgHead.encode = function encode(message, writer) {

v/declare read variable

if (!writer)

writer = $Writer.create();

V/convert decimal MsgID value to binary format, add MsgID field required for server request

writer.uint32(/* id 1, wireType 0 =*/8).uint32(message.MsgID);

V/convert decimal Uin value to binary format, add Uin field required by server request

writer.uint32(/* id 2, wireType 0 =*/16).uint32(message.Uin);

if (message.Token != null && Object.hasOwnProperty.call(message, "Token"))

Converting decimal Token value into binary format, adding Token field required by server request

writer.uint32(/* id 3, wireType 0 =*/24).uint32(message.Token);

if (message.TraceID != null && Object.hasOwnProperty.call(message, "TraceID"))

V/convert the decimal TraceID value to binary format, add the TraceID field required by the server request

writer.uint32(/* id 4, wireType 2 =*/34).string(message.TraceID);

return writer;

4) Transmitting the serialized binary data to a server through WebSocket communication and carrying out error processing:

try {

ws.send(buffer);

} catch (error) {

if (error.indexOf('Still is CONNECTING') > -1) {

console.log(error);

clearInterval(networkErrorTimer);

clearInterval(reconnectTimer);

} else {

console.log(error);

onNetworkDown();

}

accordingly, when the client receives the binary data transmitted from the server, a corresponding parsing process is also performed to obtain data, such as JSON data, that the client can recognize and operate on. Specifically, the parsing process is implemented by performing the following deserialization on the binary data received from step 301 b:

1) selecting a data transmission interface:

let serverRes = (protoRoot as any).CSMsg;

2) reading binary data by utilizing JavaScript FileReader API

let reader: any = new FileReader();

reader.readAsArrayBuffer(event.data);

3) Converting binary data into JSON data

reader.onload = function (e: any) {

let buf = new Uint8Array(reader.result);

let resData = serverRes.decode(buf);

}

It should be understood that the above is only an example of code for implementing data serialization and deserialization, and the present invention should not be limited to the specific form of code described above, but various equivalent forms of code may be selected according to a specific application environment.

Fig. 5 shows a process flow diagram for encrypting and restoring a protocol file according to an embodiment of the invention. Wherein, fig. 5a shows the encryption process of the protocol file in the development phase; FIG. 5b shows further details of the encryption process; fig. 5c shows the restore process of the encrypted protocol file when executed by the client.

In fig. 5a, at step 510, a protocol file may be format converted. Generally, Protocol files are transmitted in a Protocol Buffer data format consisting of binary data in the case of bidirectional communication using the Websocket Protocol. Because other files of the development project basically adopt js format, the files are not suitable for being packed into a compressed installation package together with Protocol files in Protocol Buffer data format, so that the Protocol files need to be firstly converted into js format to keep the format of the project files uniform. Js library may preferably be referenced for format conversion. Since the js-formatted protocol file contains source code of the script language and is not subjected to a compilation process, anyone can read out information of the interface parameters directly from the source code. To prevent the protocol file from being exposed to an untrusted third party for security and privacy concerns, the source code may be subject to packaging obfuscation at step 520, which includes substep 530 character shifting and substep 540 compression packaging.

Specifically, in sub-step 530, a script based on a Kaiser algorithm may be executed to character shift the protocol file to compile it into a preliminary obfuscated file. The script based on the Kaiser algorithm is shown by the following code:

var result = "";

// declare shift results

for(var i=0;i<str.length;i++)

{

var ChCode = str.charCodeAt(i);

V/serializing the code in the protocol file

if ( ChCode < 65 || ChCode > 90)

{

result+=str.charAt(i);

Character shifting for content not exceeding character scope

}

else{

result+=String.fromCharCode(((ChCode-65+26-step)%26)+65);

// character shifting content beyond character scope

}

return result;

// returning results after character shifting

Step refers to a key representing the number of shift steps, the key is stored in the server, and the client may request the server to obtain the key when executing packaging the obfuscated file, so as to restore the protocol file (the restoring process will be further explained in fig. 5 c). It is to be understood that the present invention is not limited to the specific form illustrated above, and that the encryption and restoration of the protocol file may be implemented by other code forms.

Next, at step 540, the character-shifted protocol file may be packed and compressed along with other files of the development project. Preferably, a Webpack tool can be invoked for the packing compression.

Fig. 5b shows a configuration process of the Webpack tool, which specifically includes: in step 541, other files (including the client project codes of the code examples of fig. 2-4) and the protocol file of the development project can be read according to the path address where the client project code file is located, and parameter resolution is performed on the files, so that each file in the development project is modularized; at step 542, a package compression plug-in may be loaded, which involves defining a configuration file, which is a simple js-formatted module in which all information related to package compression may be placed; in step 543, the configuration file is run to compile the project file; and at step 544, the compiled code is output.

The above Webpack configuration process compresses the client project code file and the (character shifted) protocol file on which it depends into an execution file. The size of the processed file is reduced, and the confusion of the code in the file is not readable any more, so that the whole process of packaging and confusion is completed, namely the final encryption of the protocol file is completed.

It is to be understood that the present invention is not limited to the specific form of the following example, and the above-described encryption process may be implemented by other code forms.

The profile contents of the Webpack tool are shown below:

// deconote plug-in

const UglifyJsPlugin = require('uglifyjs-webpack-plugin');

// gzip compression plug-in

const CompressionWebpackPlugin = require('compression-webpack-plugin');

module.exports = {

publicPath: '',

outputDir: process.env.outputDir,

// webpack plug-in configuration

configureWebpack: config => {

let plugin = [

new UglifyJsPlugin({

uglifyOptions: {

compress: {

warnings: false,

drop_debugger: true,

drop_console: true,

mangle: true,

beautify: false

}

},

sourceMap: false,

parallel: true

}),

new CompressionWebpackPlugin({

filename: '[path].gz[query]',

algorithm: 'gzip',

test: new RegExp('\\.(' + ['js', 'css'].join('|') + ')s'),

threshold: 0,

minRatio: 0.8

})

]

if (process.env.NODE_ENV != 'development') {

config.plugins = [...config.plugins, ...plugins]

}

The part of the project file after being mixed by packaging is compiled and displayed as follows:

as shown above, the packaged and obfuscated code is no longer readable, for example, the original parameters, names, etc. in the protocol file are obfuscated into code fields with names and formats that are messy, so that it is difficult for an untrusted third party to decipher the original content and architecture of the restored code, and thus there is no decompiling way for the packaged and obfuscated protocol file. Therefore, the security and confidentiality of the protocol file and the interface parameters thereof at the client can be ensured by the packaging obfuscation operation according to the embodiment of the invention.

Fig. 5c shows the process of restoring the protocol file at the client. As described above with respect to the encryption process for the protocol file, other files in the client project code and the character shifted protocol file are packed into one execution file. The size of the processed file is reduced, and the confusion generated by the code in the file is not readable any more, so that the encrypted protocol file can be called from the inside only for the execution of the client.

In step 550, the client executes a packed compressed execution file containing a packed obfuscated project file obtained by packing and compressing a character-shifted protocol file together with other files of the project file using a Webpack tool, which makes it difficult to restore the internal protocol file by other means (e.g., decompression or decompilation) than is executed by the client. In step 560, the client retrieves the obfuscated protocol file (i.e., the character-shifted protocol file) by executing the execution file.

However, since the protocol file is character-shifted by a specific key in the development stage, the client cannot accurately read the contents even if the protocol file is obtained, so that the client needs to request the key from the server to restore the protocol file in step 570.

In one embodiment, the key may be set by the developer during the development phase to initially encrypt the protocol file and upload the key to the server. The client can prove that the client is legally trusted to the server through the account password uploaded by the user, so that the key of the protocol file is obtained through the authorization of the server. In another embodiment, the key may be randomly generated by the server rather than set by the developer, so that both character shifting the protocol file during the development phase and restoring the protocol file at the client require a key to be requested from the server for encryption and restoration of the protocol file.

In step 580, the client may restore the character-shifted protocol file based on the retrieved key. The restore script is represented by the following code:

var result = "";

// declare the result of the restore

for(var i=0;i<str.length;i++)

{

var ChCode = str.charCodeAt(i);

if ( ChCode < 65 || ChCode > 90)

{

result+=str.charAt(i);

}

else{

result+=String.fromCharCode(((ChCode-65+26+step)%26)+65);

V/character reverse shift based on step number step defined by Kaiser algorithm

}

return result;

// return the reduction result

Step refers to the above encryption key for character shifting of the protocol file.

According to the embodiment of the present invention, the restoration of the complete protocol file needs to pass through a double threshold: (1) the step of restoring the packed and compressed execution file into the project file before packing and compressing is almost difficult to achieve, because codes in the packed and compressed file are difficult to read and understand for a third party, but the code can be called out only by executing without reading for a client; (2) the step of requesting the key from the server to restore the obfuscated protocol file to the original protocol file increases the difficulty of restoring the obfuscated protocol file to the original protocol file in the case that the client is not trusted by the server.

FIG. 6 illustrates a comparison of encrypted communications at a legitimate client and server versus communication of an attacker client and server, according to an embodiment of the invention. As shown, the valid client 601 may refer to a client provided according to one or more embodiments of the present invention running on the local terminal 110 and the remote terminal 130 in fig. 1, and may also refer to a client implemented according to the technology provided in one or more embodiments of the present invention throughout this document; server 602 may refer to remote server 120 shown in fig. 1, or may refer to a server that communicates throughout this document with clients implemented in accordance with techniques provided in one or more embodiments of the present invention; attacker client 603 may refer to an untrusted third party client, which may be a client manipulated by a hacker, or any client attempting to communicate with a server without using the techniques provided in accordance with one or more embodiments of the invention.

Generally, if two-way communication between a client and a server is to be achieved, when the client is developed, updated or maintained, a clear text protocol file containing interface parameters for the server is typically packaged and published together with client project files to an extranet for users to download, install and execute on their respective terminals. In this case, there may be a risk that the protocol file is exposed in the release. An attacker may communicate with the server by deciphering the interface parameter information in the protocol file, forging a client or otherwise forging the identity of a legitimate user. In one aspect, an attacker may attack a server in a variety of attack ways, including but not limited to: DDoS attacks (such as bandwidth congestion type attacks like SYN Flood and UDP Flood) are applied to the target server, which not only causes network congestion, but also reduces the response speed and hit rate of other users accessing the server; sending a small number of HTTP requests to the target server causes the server to return a large file (e.g., an image, a video file, etc.), or causes the server to run some complex script programs (e.g., complex data processing, cryptographic calculation and verification, etc.), thereby achieving the purpose of exhausting the resources (e.g., CPU, memory, Socket, etc.) of the target server, and leaving the target server in a vulnerable and unprotected state. On the other hand, the attacker can attack other legitimate users in various ways, for example, obtain and utilize data of other legitimate users, thereby threatening the security and privacy of other legitimate users.

In one or more embodiments of the present invention, by encrypting the protocol file, an attacker cannot decompile or crack the protocol file, and thus cannot obtain the interface parameters or the communication data transmission rules for communicating with the target server. As shown by the solid arrows in fig. 6, the normal client 601, according to the embodiment of the present invention, can effectively perform encrypted communication with the server 602, thereby implementing secure and high-performance bidirectional data transmission. However, the attacker client 603 cannot obtain any valid information in the protocol file because it cannot retrieve and parse the encrypted protocol file, and therefore cannot establish valid communication with the server 602. Specifically, as shown by the dashed arrows in fig. 6, in one embodiment, on one hand, the attacker client 603 cannot generate valid header information for the communication data to be transmitted because it cannot obtain the interface parameters specified by the transmission protocol, and cannot generate a legal communication data message to be transmitted to the server 602; on the other hand, due to the lack of data format conversion rules in the protocol file, even if having a complete communication data message, it cannot be encoded into a binary data format that can be transmitted over the communication channel established between the client and the server. Also, as shown by the dashed arrows in fig. 6, in another embodiment, the attacker client 603 is unable to decode the communication data into data content that can be recognized and/or manipulated even though it may successfully receive it from the server 602 due to missing data format conversion rules in the protocol file during the receiving process.

Fig. 7 illustrates an application scenario of a client according to an embodiment of the present invention. It should be understood that the client according to the embodiment of the present invention has various application scenarios, and is not limited to the examples in the drawings.

In the exemplary application scenario shown in fig. 7, the client may be a standalone Web client executing on the terminal, or may be a Web client 701 mounted on a third-party client (e.g., game client 702). In one embodiment, the Web client 701 is a communication tool mounted on a game client for realizing online chat of users, and can realize that one or more players send messages on the same channel, and other players can see the messages in real time.

The client according to the embodiment of the present invention can be applied to scenes requiring security and high real-time, such as social chat, barrage, multi-player games, collaborative editing, real-time quotation of stock funds, live sports update, video conference/chat, location-based applications, online education, smart home, and the like.

Fig. 8 shows a flow diagram of a method at a client for encrypted communication with a server according to an embodiment of the invention. The following describes a specific implementation procedure for encrypted communication at a server at a client according to one or more embodiments of the present invention.

Step 801, optionally, a connection request is sent to a server to establish a communication channel, wherein the communication channel is based on a WebSocket transport protocol.

In one example, the WebSocket transport protocol uses the WS protocol. In another example, the WebSocket transport protocol WSS protocol. In the example using the WSS protocol, the established communication channel is encrypted using Transport Layer Security (TLS).

Step 802, optionally, determines whether a communication channel between the client and the server is successfully established to prepare for continuous two-way communication. If so, proceed to step 803; if not, the process returns to step 801 to resend the connection request to the server.

In step 803a, an encrypted protocol file is retrieved, where the encrypted protocol file is obtained by encrypting a plaintext protocol file that defines transmission rules of communication data. In one or more embodiments, the encrypted protocol file is obtained by performing the following operations on the clear protocol file: carrying out format conversion on the protocol file of the plaintext; and packing and confusing the protocol file after format conversion. In one specific example, encrypting the clear protocol file includes: js library is quoted to convert plain protocol files from proto format files into js format files; and calling a Webpack packaging tool to package and confuse the protocol file in the js format.

In one or more embodiments, the step of performing package obfuscation comprises: carrying out character shifting on the js format protocol file; and calling a Webpack tool to compress and pack the protocol file after the character shifting and the project file. In detail, the operation of calling the Webpack tool to perform compression packaging comprises the following steps: performing parameter analysis on the protocol file after the character shifting; loading a compression plug-in; and performing the compiling and outputting the compiled code.

Step 803b, requesting the server to obtain a key to restore the encrypted protocol file. In one example, the key may be set by a developer during a development phase to initially encrypt the protocol file and upload the key to the server. The client can prove that the client is legally trusted to the server through the account password uploaded by the user, so that the key of the protocol file is obtained through the authorization of the server. In another example, the key may be randomly generated by the server rather than set by the developer, whereby character shifting the protocol file during the development phase and restoring the protocol file at the client require a key to be requested from the server for encryption and restoration of the protocol file.

Next, two processes of transmission and reception are described separately. Wherein, the sending process comprises step 804, step 805, and step 806, and the receiving process comprises step 807 and step 808.

It should be understood that the sending process and the receiving process may occur sequentially, may occur separately, or may occur simultaneously. The occurrence of both is not limited to the transmission before reception, but may be the reception before transmission after transmission, or may be the transmission without reception or the reception without transmission.

Step 804, generating communication data in a first data format according to the transmission rule. In one or more examples, the first data format is JSON.

At step 805, the communication data in the first data format is encoded into communication data in the second data format according to the transmission rule. In one or more examples, the second data format is binary data of Protocol Buffer.

Step 806, sending the communication data in the second data format to the server

The above transmission process can be summarized as follows: the communication data to be transmitted is processed based on the transmission rule of the communication data to be transmitted to the server.

In step 807, communication data in a second data format is received from the server.

And 808, decoding the communication data in the second data format into the communication data in the first data format according to the transmission rule for the client to identify and/or operate.

The above receiving process can be summarized as follows: and processing the communication data received from the server based on the transmission rule of the communication data for utilization by the client.

In one or more examples, a protobuf.js library may be referenced to process communication data according to transmission rules, the processing of communication data including generating communication data, encoding and/or decoding communication data. In one example, when the first data format is JSON and the second data format is binary, encoding may be understood as serialization and decoding may be understood as deserialization.

Fig. 9 illustrates a block diagram of an example apparatus 900 at a client for encrypted communication with a server in accordance with an embodiment of the present invention. The solid line blocks in fig. 9 represent functional blocks and the dashed line blocks represent elements or components related to, but not necessarily present with a processing module, which may be in the form of software, hardware, firmware or a combination thereof.

As shown in fig. 9, the example apparatus 900 includes the following modules: an initialization module 901, a calling module 902, a processing module 903 and a transceiver module 904.

The general functions of each module will be briefly described below, and it should be understood that the order of arrangement of each module and the necessity exist are not limited thereto. For example, certain module(s) may not necessarily be present, or the functionality of certain module(s) may be implemented instead by other module(s).

A transceiver module 904 for sending messages to and/or receiving messages from the server at the client.

An initialization module 901, configured to send a connection request to the server through the transceiver module 904 to establish a communication channel before the client communicates with the server.

Wherein the communication channel may be based on a WebSocket transport protocol, and the WebSocket transport protocol may include any one of a WS protocol and a WSs protocol.

In one or more embodiments, when the communication channel is based on the WSS protocol, the communication channel may be encrypted using Transport Layer Security (TLS).

And a calling module 902, configured to call the encrypted protocol file.

Wherein the encrypted protocol file is obtained by encrypting a plain protocol file, and wherein the plain protocol file defines transmission rules of the communication data.

In one or more embodiments, the encrypted protocol file may be obtained by encrypting a plaintext protocol file by: carrying out format conversion on a protocol file of a plaintext; and packaging and confusing the protocol file after format conversion to obtain an encrypted protocol file.

Optionally, the step of converting the format of the plaintext protocol file may include: js library is referenced to convert the plain-text Protocol file from Protocol Buffer format to js format.

Optionally, the step of performing package obfuscation includes: carrying out character shifting on the protocol file after format conversion; and calling a Webpack tool to compress and pack the protocol file after the character shifting and the project file. In detail, the operation of calling the Webpack tool to perform compression packaging comprises the following steps: performing parameter analysis on the protocol file after the character shifting; loading a compression plug-in; and performing the compiling and outputting the compiled code.

A request module 905, configured to request the server to obtain a key to restore the encrypted protocol file. In one embodiment, the key may be set by the developer during the development phase to initially encrypt the protocol file and upload the key to the server. The client can prove that the client is legally trusted to the server through the account password uploaded by the user, so that the key of the protocol file is obtained through the authorization of the server. In another embodiment, the key may be randomly generated by the server rather than set by the developer, whereby character shifting the protocol file during the development phase and restoring the protocol file at the client require a key to be requested from the server for encryption and restoration of the protocol file.

A processing module 903, configured to process communication data to be sent to the server based on a transmission rule of the communication data, or process communication data received from the server for the client to utilize based on a transmission rule of the communication data, where the encrypted protocol file is obtained by performing the following operations on the plaintext protocol file: carrying out format conversion on the protocol file of the plaintext; and packing and confusing the protocol file after format conversion.

Specifically, the processing module 903 includes: a generating unit 913, an encoding unit 923, and a decoding unit 933.

A generating unit 913 for generating communication data of the first data format according to the transmission rule

An encoding unit 923, configured to encode the communication data in the first data format into communication data in a second data format according to a transmission rule, where the transceiver module 904 sends the communication data in the second data format to the server.

A decoding unit 933, configured to decode, according to the transmission rule, the communication data in the second data format into the communication data in the first data format for the client to utilize, where the transceiver module 904 receives the communication data in the second data format from the server.

In one or more embodiments, the communication data of the first data format may be JSON data, which may be recognized and operated at the client, and the communication data of the second data format may be Protocol Buffer data, which may not be directly used by the client as binary data, but may improve performance and efficiency of transmission due to light weight on the server.

Js library is optionally referenced to process the communication data according to the transmission rules. In one or more embodiments, processing the communication data may include: generating, encoding, and decoding.

FIG. 10 shows a schematic block diagram of a computing device 1000 in accordance with an embodiment of the invention. The computing device 1000 may represent the local terminal 110 of fig. 1. It will also be appreciated that remote terminals 130-1, 130-2, … …, 130-N in FIG. 1 may also take the form of computing device 1000.

Computing device 1000 may be a variety of different types of devices, such as a client device, a server computer, a system-on-chip, and/or any other suitable computing device or computing system.

Computing device 1000 may include at least one processor 1002, memory 1004, communication interface(s) 1006, display device 1008, other input/output (I/O) devices 1010, and one or more mass storage devices 1012, capable of communicating with each other, such as through system bus 1014 or other appropriate connection.

The processor 1002 may be a single processing unit or multiple processing units, all of which may include single or multiple computing units or multiple cores. The processor 1002 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitry, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor 1002 can be configured to retrieve and execute computer readable instructions, such as program code for an operating system 1016, program code for an application 1018, program code for other programs 1020, etc., stored in the memory 1004, mass storage 1012, or other computer readable medium to implement the methods provided by embodiments of the present invention.

The memory 1004 and mass storage devices 1012 are examples of computer storage media for storing instructions that are executed by the processor 1002 to implement the various functions described above. By way of example, the memory 1004 may generally include both volatile and nonvolatile memory (e.g., RAM, ROM, and the like). In addition, mass storage devices 1012 may generally include hard disk drives, solid state drives, removable media, including external and removable drives, memory cards, flash memory, floppy disks, optical disks (e.g., CDs, DVDs), storage arrays, network attached storage, storage area networks, and the like. Memory 1004 and mass storage 1012 may both be referred to herein collectively as memory or computer storage media, and may be non-transitory media capable of storing computer-readable, processor-executable program instructions as computer program code that may be executed by processor 1002 as a particular machine configured to implement the operations and functions described in the examples herein.

A number of program modules may be stored on the mass storage device 1012. These programs include an operating system 1016, one or more application programs 1018, other programs 1020, and program data 1022, and can be loaded into memory 1004 for execution. Examples of such applications or program modules may include, for instance, computer program logic (e.g., computer program code or instructions) for implementing the techniques provided herein: an initialization module 901, a calling module 902, a processing module 903 (including a generating unit 913, an encoding unit 923, a decoding unit 933), and a transceiving module 904. Also, the program modules may be distributed over different physical locations to achieve the corresponding functionality.

Although illustrated in fig. 10 as being stored in memory 1004 of computing device 1000,

various components

1016, 1018, 1020, and 1022, or portions thereof, in memory 1004 can be implemented using any form of computer-readable media that is accessible by computing device 1000. As used herein, "computer-readable media" includes at least two types of computer-readable media, namely computer storage media and communication media.

Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computing device.

In contrast, communication media may embody computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism. Computer storage media, as defined herein, does not include communication media.

Computing device 1000 may also include one or more communication interfaces 1006 for exchanging data with other devices, such as over a network, direct connection, and so forth. Communication interface 1006 may facilitate communications within a variety of networks and protocol types, including wired networks (e.g., LAN, cable, etc.) and wireless networks (e.g., WLAN, cellular, satellite, etc.), the Internet, and so forth. Communication interface 1006 may also provide for communication with external storage devices (not shown), such as in a storage array, network attached storage, storage area network, or the like.

In some examples, a display device 1008, such as a monitor, may be included for displaying information and images. Other I/O devices 1010 may be devices that receive various inputs from a user and provide various outputs to the user, and may include touch input devices, gesture input devices, cameras, keyboards, remote controls, mice, printers, audio input/output devices, and so forth.

Variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed subject matter, from a study of the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

1. A method at a client for encrypted communication with a server, the method comprising:

retrieving an encrypted protocol file, wherein the encrypted protocol file is obtained by encrypting a plaintext protocol file that defines transmission rules for communication data, and wherein the encrypted protocol file is obtained by performing the following operations on the plaintext protocol file:

carrying out format conversion on the protocol file of the plaintext; and

packing and obfuscating the protocol file after format conversion,

requesting a key to the server to restore the encrypted protocol file; and

and processing communication data to be sent to the server based on the transmission rule, or processing communication data received from the server for utilization by the client based on the transmission rule.

2. The method of claim 1, wherein performing format conversion comprises:

js library is quoted to convert the Protocol file of the plaintext from the Protocol Buffer format into the js format.

3. The method of claim 1, wherein performing a packing obfuscation operation comprises:

carrying out character shifting on the protocol file after format conversion;

and calling a Webpack tool to compress and pack the protocol file after the character shifting and the project file.

4. The method of claim 3, wherein invoking the Webpack tool for compression packaging comprises:

performing parameter analysis on the protocol file after the character shifting;

loading a compression plug-in; and

performing the compilation and outputting the compiled code.

5. The method of claim 1, wherein processing communication data to be sent to the server based on the transmission rules comprises:

generating communication data in a first data format according to the transmission rule;

encoding the communication data in the first data format into communication data in a second data format according to the transmission rule;

and sending the communication data in the second data format to the server.

6. The method of claim 1, wherein processing communication data received from the server based on the transmission rule comprises:

receiving communication data in a second data format from the server;

decoding the communication data in the second data format into communication data in the first data format according to the transmission rule for utilization by the client.

7. The method according to claim 5 or 6, characterized in that:

the communication data of the first data format is JSON data, and the communication data of the second data format is Protocol Buffer data.

8. The method according to claim 5 or 6, characterized in that:

js library is referred to process the communication data according to the transmission rule.

9. The method of any of claims 1-6, wherein a connection request is sent to the server to establish a communication channel prior to encrypted communication with the server, wherein the communication channel is based on a WebSocket transport protocol, and wherein the WebSocket transport protocol comprises any of a WS protocol and a WSS protocol.

10. The method of claim 9, wherein the communication channel is encrypted using transport layer security when the communication channel is based on the WSS protocol.

11. An apparatus at a client for encrypted communication with a server, the apparatus comprising:

a transceiver module for transmitting and receiving communication data to and from the server;

a retrieving module for retrieving an encrypted protocol file, wherein the encrypted protocol file is obtained by encrypting a plaintext protocol file, the plaintext protocol file defining transmission rules of communication data, and wherein the encrypted protocol file is obtained by performing the following operations on the plaintext protocol file:

carrying out format conversion on the protocol file of the plaintext; and

packing and obfuscating the protocol file after format conversion,

the request module is used for requesting the server to obtain a key so as to restore the encrypted protocol file; and

and the processing module is used for processing the communication data to be sent to the server based on the transmission rule or processing the communication data received from the server based on the transmission rule for the client to utilize.

12. A computing device, wherein the computing device comprises:

a memory for storing a computer executable program; and

a processor configured to execute the computer-executable program stored on the memory to implement the method of any of claims 1-10.

13. A computer-readable storage medium, having stored thereon a computer-executable program, which is loadable and executable by a processor to implement the method according to any of claims 1-10.