WEB end real-time remote connection monitoring method based on RDP protocol

Abstract

A WEB end real-time remote connection monitoring method based on an RDP protocol comprises the following steps that a gateway server is maintained between an RDP client and a server, a firewall is configured, a routing rule is added, and RDP flow is forwarded to a local loopback address; the rear end of the gateway server starts an RDP proxy service, receives the RDP traffic forwarded by the firewall, and creates an independent thread to run a Flask application; after the RDP proxy service receives the RDP data packet, an RDP protocol data unit is analyzed according to a protocol format; establishing connection between the RDP proxy service and the Web front end through WebSocket, defining a corresponding event according to the analyzed PDU data type, and transmitting the event to the Web browser end in real time; and the Web end creates a bitmap cache and canvas cache canvas, and displays a remote picture and key data connected with the RDP on a Web page in real time. The scheme not only can effectively monitor the remote desktop session, but also has the advantages of high bandwidth utilization rate, low resource consumption, convenience in cross-platform deployment and the like.

Description

Technical Field

[0001] The present invention relates to the application technology of the Remote Desktop Protocol (RDP), and specifically relates to a method for real-time remote connection monitoring on the WEB side based on the RDP protocol, involving a technical solution for real-time monitoring, screen playback, and key recording optimization of remote desktop sessions through a Web browser. This technology is applicable to scenarios such as remote operation and maintenance, distance education, and remote assistance, as well as occasions for monitoring and auditing the security of remote connections. Background Art

[0002] The RDP (Remote Desktop Protocol) is a remote desktop protocol developed by Microsoft Corporation and is widely used in fields such as remote office, server management, and cloud computing platforms. Most existing RDP clients and servers rely on local software for implementation. Although the functions are relatively complete, there are certain limitations in cross-platform, lightweight deployment, and remote monitoring.

[0003] However, with the wide application of the RDP protocol, its security issues have become increasingly prominent, such as unauthorized access, data leakage, and malicious operations. Especially in the case where it is difficult for enterprise internal personnel to fully monitor, how to monitor remote connection behaviors in real time, record user inputs, and detect abnormalities in a timely manner has become a difficult problem to be solved urgently.

[0004] In the prior art, the monitoring tools for the RDP protocol mainly exist in the form of client or server software. These tools usually need to be installed on user devices or servers, the deployment process is complex, and the occupation of system resources is relatively high. In addition, most existing tools cannot achieve cross-platform real-time monitoring, and it is difficult for users to view the status and operation records of RDP connections through a simple browser interface at any time and anywhere.

[0005] In recent years, Web technology has developed rapidly. Applications based on Web browsers have received extensive attention due to their cross-platform nature, ease of use, and the need for no additional installation. However, there has not yet been a mature solution that can deeply integrate the real-time monitoring function of the RDP protocol with Web technology, so as to achieve real-time monitoring and management of RDP connections through a Web browser. Summary of the Invention

[0006] The objective of the present invention is to provide a method for real-time remote connection monitoring on the WEB side based on the RDP protocol, aiming to solve the problems of complex deployment, inability to achieve real-time monitoring, and lack of cross-platform support of existing RDP monitoring tools, and to provide an efficient and convenient solution for network security and remote management.

[0007] To achieve the above object, the technical solution adopted by the present invention is: a WEB-side real-time remote connection monitoring method based on the RDP protocol, including the following steps:

[0008] S1: Maintain a gateway server between the RDP client and the server, configure the firewall, add routing rules, and forward all received RDP traffic to the local loopback address (127.0.0.1);

[0009] S2: Start the RDP proxy service at the back end of the gateway server, listen on 0.0.0.0:3389, receive the RDP traffic forwarded by the firewall, and at the same time create an independent thread to run the Flask application, listening for HTTP requests and WebSocket connections;

[0010] S3: After the RDP proxy service receives the RDP data packet, parse the RDP protocol data unit (PDU) according to the protocol format to obtain data such as the server graphics update command and the client keyboard input;

[0011] S4: The RDP proxy service establishes a persistent two-way connection with the Web front end through WebSocket, defines corresponding events according to the parsed PDU data type, and transmits them to the Web browser end in real time;

[0012] S5: The Web side establishes a WebSocket connection with the back end, creates a bitmap cache, and creates a canvas cache canvas, selects corresponding processing methods according to the received different events, and displays the remote screen and key data of the RDP connection on the Web page in real time to achieve real-time monitoring of the RDP connection;

[0013] Further, the firewall policy for configuring the gateway server in step S1 includes the following contents:

[0014] S11: Turn on the IP forwarding function of IPv4 to ensure that the server can forward data packets normally;

[0015] S12: Use the TPROXY rule in the PREROUTING chain of iptables to forward the traffic with the destination of 3389 to the local loopback address and mark it;

[0016] S13: Also mark the return traffic with the source port of 3389 to ensure that the outbound traffic also follows the customized routing policy;

[0017] S14: Create a new routing table in / etc / iproute2 / rt_tables, add a route in the routing table, and forward the data packet to the local loopback address (127.0.0.1);

[0018] S15: Add a routing rule. All packets marked by iptables use the newly created routing table to look up routing information for routing. All marked traffic uses a specific routing table and finally forwards the packets to the local loopback address (127.0.0.1).

[0019] Furthermore, the Flask service in step S2 is started in the following way:

[0020] Create a Flask application instance and a Socket instance in the global scope. Use a daemon thread in the proxy service main program to start the Flask service and listen for HTTP and WebSocket requests. The main thread continues to execute other logic to achieve concurrent operations.

[0021] Furthermore, the steps for the RDP proxy service to parse RDP packets in step S3 are as follows:

[0022] S31: The proxy server listens on the RDP default port 3389, receives the TCP connection request initiated by the client. The TCP layer establishes a connection between the client and the server through three-way handshake, and then data transmission can be carried out. It supports TLS encryption to ensure communication security. After decryption, the data part is passed to the Segmentation layer;

[0023] S32: The Segmentation layer receives a continuous byte stream from the TCP layer, reads the first byte, and determines whether it is 0x03. If so, it is recognized as a TPKT PDU, otherwise it is a Fast-Path PDU, and then it is passed to the corresponding parsing module;

[0024] S33: The TPKT layer reads the TPKT header, calculates the PDU length, extracts the payload according to this length, and passes it to the x224 layer;

[0025] S34: The X224 layer receives the PDU data from the TPKT layer. First, it reads the TPKT header, extracts the length field, confirms the PDU integrity, then reads the x224 header following the TPKT header, extracts the PDU Type field, determines the PDU type according to the PDU Type, and selects the corresponding processing method, processes or forwards;

[0026] S35: The MCS layer receives the PDU data from the X224 layer. First, it reads the TPKT header, extracts the length field, confirms the PDU integrity, then reads the MCS header after the TPKT header, extracts the PDU Type field, determines the PDU type according to the PDU Type, and selects the corresponding processing method, processes or forwards;

[0027] S36: The Security layer receives PDU data from the MCS layer. First, it reads the security header, extracts the flag field, determines the PDU type and security options, and extracts the MAC value for subsequent verification. It calculates the MAC using the shared key and payload, compares the calculated result with the MAC in the PDU to ensure the data has not been tampered with. It decrypts the payload, determines whether the payload is encrypted based on the flag, and if encrypted, decrypts the payload using the negotiated encryption algorithm and key. Finally, it passes the decrypted payload to the upper-layer RDP protocol layer (such as the I / O layer or the virtual channel layer) for processing;

[0028] S37: The RDP layer includes the I / O layer and the virtual channel layer (Virtual Channel layer), both of which need to parse the header fields, extract the PDU type, and select the corresponding processing method according to different types;

[0029] S38: The Fast-Path layer receives the PDU forwarded from the Segmentation layer: reads the header of the PDU, including the length field and the flag field. The length field is used to indicate the size of the entire PDU, and the flag field identifies the data type and whether it is encrypted. If encrypted, it decrypts the data using the negotiated key, checks the MAC signature to ensure the data has not been tampered with, and finally parses out the payload.

[0030] Furthermore, the event types defined in step S4 are as follows:

[0031] The'memblt' event is used to transmit MEMBLT drawing command data;

[0032] The 'bitmap' event is used to transmit CacheBitmapV2 drawing command data;

[0033] The 'frame' event is used to transmit FrameMarker drawing control command data;

[0034] The 'keyboard' event is used to transmit client keyboard input data.

[0035] Furthermore, in step S5, the steps for decompressing the bitmap data are as follows:

[0036] S51: Implement the RLE bitmap decompression algorithm in C language, named rle.c;

[0037] S52: Compile rle.c into a WebAssembly binary file rle.wasm and an rle.js file through the Emscripten compiler;

[0038] S53: Load rle.js in HTML. rle.js will load rle.wasm into the browser environment and provide the Module object;

[0039] S54: Allocate memory using Module._malloc() in JavaScript, create buffers for the input (bitmapdata) and output (decompressed pixel data), call the bitmap decompression function for decompression using Module.ccall(), and finally release the allocated memory using Module._free() to prevent memory leaks.

[0040] The above steps utilize WebAssembly technology to optimize the bitmap decompression process, break through the performance bottleneck of JavaScript, improve the bitmap processing efficiency, and enhance the system performance.

[0041] The technical effect of the present invention is: The present invention provides a method for real-time remote connection monitoring on the WEB side based on the RDP protocol. By configuring the gateway server firewall and routing rules, forward the RDP traffic to the local loopback address, then start the RDP proxy service on the gateway server, listen on this address and receive and parse the RDP data stream, and use WebSocket to transmit the parsed data to the front end in real time to achieve real-time display of the remote desktop screen and key records. This solution can not only effectively monitor remote desktop sessions and improve the enterprise security protection level, but also has advantages such as high bandwidth utilization rate, low resource consumption, and convenient cross-platform deployment, providing an innovative technical implementation method for the remote desktop security monitoring system. Description of the Drawings

[0042] Figure 1 is the flow diagram of the present invention;

[0043] Figure 2 is Figure 1 the flow diagram of step S1 in

[0044] Figure 3 is Figure 1 the flow diagram of the RDP proxy service in step S3 in

[0045] Figure 4 is Figure 1 the flow diagram of the bitmap decompression process in step S5 in Detailed Embodiments

[0046] In order to make the objectives, technical solutions and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0047] As shown Figure 1 in the figure, the present invention proposes a method for real-time remote connection monitoring on the WEB side based on the RDP protocol, including the following steps:

[0048] S1: Maintain a gateway server between the RDP client and the server, configure the firewall, add routing rules, and forward all received RDP traffic to the local loopback address (127.0.0.1).

[0049] Further, as shown Figure 2 in the figure, the firewall policy for configuring the gateway server in step S1 includes the following content:

[0050] S11: Turn on the IP forwarding function of IPv4 to ensure that the server can forward data packets normally.

[0051] S12: Use the TPROXY rule in the PREROUTING chain of iptables to forward the traffic with the destination of 3389 to the local loopback address and mark it.

[0052] S13: Also mark the return traffic with the source port of 3389 to ensure that the outbound traffic also follows the customized routing policy.

[0053] S14: Create a new routing table in / etc / iproute2 / rt_tables, add a route in the routing table, and forward the data packet to the local loopback address (127.0.0.1).

[0054] S15: Add a routing rule that all data packets marked by iptables use the above newly created routing table to find routing information for routing. All marked traffic uses a specific routing table, and finally the data packet is forwarded to the local loopback address (127.0.0.1).

[0055] Specifically, assume that the IP address of the RDP client is 192.168.2.2, the IP address of the RDP server is 192.168.3.2, and the IP addresses of the two network adapters of the gateway server are 192.168.2.1 and 192.168.3.1. Configure the default gateways of the RDP client and the server to be 192.168.2.1 and 192.168.3.1 respectively.

[0056] After the gateway server configures the above firewall policy, when the RDP client connects to the server host with the target IP address of 192.168.3.2, the firewall iptables of the gateway server will perform traffic forwarding, forwarding all RDP traffic (tcp traffic with the destination port and source port being 3389) to the local loopback interface lo (127.0.0.1), which is processed and parsed by the proxy service. After completion, the data is encapsulated and forwarded to the destination address to achieve a remote session.

[0057] S2: Start the RDP proxy service at the back end of the gateway server, listen on 0.0.0.0:3389, receive the RDP traffic forwarded by the firewall, and at the same time create an independent thread to run the Flask application, listening for HTTP requests and WebSocket connections.

[0058] Furthermore, the Flask service in step S2 is started in the following way:

[0059] Create Flask application instances and Socket instances in the global scope.

[0060] Use a daemon thread in the main program of the proxy service to start the Flask service, listening for HTTP and WebSocket requests. The main thread continues to execute other logic to achieve concurrent operations.

[0061] Specifically, the gateway firewall starts the proxy service, listens on the local port 3389, receives the RDP traffic forwarded by the firewall, and at the same time starts a thread to run the Flask service, listening on port 5000. Open the browser at 127.0.0.1 / 5000 to access the monitoring page and wait for the RDP connection. When the RDP client sends a remote connection request to the RDP server, the RDP data packet will be forwarded by the firewall of the gateway server to the local loopback interface lo (127.0.0.1). After being parsed by the proxy service, the data is transmitted to the Web front end through WebSocket. The proxy service then encapsulates it as an RDP data packet according to the protocol stack and sends it to the RDP server. After receiving it, the RDP server responds to this request to achieve a remote connection.

[0062] S3: After the RDP proxy service receives the RDP data packet, it parses the RDP protocol data unit (PDU) according to the protocol format to obtain data such as the server graphics update command and the client keyboard input.

[0063] Furthermore, as Figure 3 shown, the steps for the RDP proxy service in step S3 to parse the RDP data packet are as follows:

[0064] S31: The proxy server listens on the RDP default port 3389, receives the TCP connection request initiated by the client. The TCP layer will establish a connection between the client and the server through three-way handshake, and then data transmission can be carried out. It supports TLS encryption to ensure communication security. After decryption, the data part is passed to the Segmentation layer.

[0065] S32: The Segmentation layer receives a continuous byte stream from the TCP layer, reads the first byte, and determines whether it is 0x03. If so, it is recognized as a TPKT PDU and proceeds to step S33; otherwise, it is a Fast-Path PDU and proceeds to step S38.

[0066] Specifically, the Segmentation layer receives a continuous byte stream from the TCP layer and checks the first byte: if it is 0x03, it is recognized as a TPKT PDU, and the entire PDU (including the header and payload) is passed to the TPKT layer parsing module; if it is other values (such as 0x00, 0x01, etc., which may carry an encryption flag), it is recognized as a Fast-Path PDU, and the PDU is passed to the Fast-Path layer parsing module. In the TCP stream, the data packets may be continuous. After parsing one data packet, move the pointer to the start position of the next data packet and repeat the above steps.

[0067] S33: The TPKT layer reads the TPKT header, calculates the PDU length, extracts the payload according to this length, and passes it to the x224 layer.

[0068] Specifically, the TPKT layer reads the TPKT header, calculates the PDU length, extracts the payload according to this length, and passes it to the x224 layer. By splitting the TCP stream into independent PDUs, it ensures that the upper-layer protocols can accurately receive and process the data. The PDU includes a header, a length field, and a payload. The length field ensures that the receiving end can correctly read the data and is used for connection sequences and special types of PDUs. After processing, the PDU is passed to the X224 layer.

[0069] S34: The X224 layer receives the PDU data from the TPKT layer. First, it reads the TPKT header, extracts the length field, and confirms the PDU integrity. Then it reads the x224 header following the TPKT header, extracts the PDU Type field, determines the PDU type according to the PDU Type, and selects the corresponding processing method, either process or forward.

[0070] Specifically, select the corresponding processing method according to the PDU type. If it is a Connection Request: extract the cookie and protocol information; if it is a Connection Confirm: confirm the successful connection and record the protocol; if it is a Data: extract the payload and forward it; if it is a Disconnect Request: record the reason and disconnect; if it is an Error: record the error and handle it.

[0071] S35: The MCS layer receives PDU data from the X224 layer. First, read the TPKT header, extract the length field, confirm the PDU integrity, then read the MCS header after the TPKT header, extract the PDU Type field, judge the PDU type according to the PDU Type, and select the corresponding processing method to process or forward.

[0072] Specifically, select the corresponding processing method according to the PDU type. If it is a Connect Initial: parse the GCC data and record the connection parameters; if it is an AttachUser Confirm: extract the user ID and create a user object; if it is a Channel Join Confirm: confirm the channel join and create the channel layer; if it is a Send Data Request: extract the channel ID and data and forward them to the Security layer.

[0073] S36: The Security layer receives PDU data from the MCS layer. First, read the security header, extract the flag field, determine the PDU type and security options, extract the MAC value for subsequent verification; calculate the MAC using the shared key and the payload, compare the calculation result with the MAC in the PDU to ensure that the data has not been tampered with; decrypt the payload, judge whether the payload is encrypted according to the flag, and if it is encrypted, decrypt the payload using the negotiated encryption algorithm and key; finally, pass the decrypted payload to the upper-layer RDP protocol layer (such as the I / O layer or the virtual channel layer) for processing.

[0074] S37: The RDP layer includes the I / O layer and the virtual channel layer (Virtual Channel layer), both of which need to parse the header fields, extract the PDU type, and select the corresponding processing method according to different types.

[0075] Specifically, the I / O layer receives PDU data from the Security layer. First, it reads the header content, extracts the PDU type, determines whether the PDU belongs to the input, output, confirmation, or error type, and parses the payload according to the type. The Virtual Channel layer receives PDU data from the Security layer. First, it reads the header, extracts the channel ID and PDU type. According to the channel ID, it routes the PDU to the corresponding virtual channel processing module. Different virtual channels correspond to different functions (such as the clipboard channel, audio channel), and each channel has specific parsing logic. It parses the virtual channel header, reads the channel flag to understand the current state or data transmission attributes of the channel, parses the length field to determine the length of the subsequent payload data, and parses the specific data in the payload according to the type of the virtual channel, and passes the parsed data to the corresponding functional module for processing.

[0076] S38: The Fast-Path layer receives the PDU forwarded from the Segmentation layer: It reads the header of the PDU, including the length field and the flag field. The length field is used to indicate the size of the entire PDU, and the flag field identifies the data type and whether it is encrypted. If it is encrypted, it decrypts the data using the negotiated key, checks the MAC signature to ensure that the data has not been tampered with, and finally parses out the payload.

[0077] Specifically, the Fast-Path layer first needs to read the header of the Fast-Path PDU, which usually includes the length field and the flag field. The length field is used to indicate the size of the entire PDU, helping the parser determine the number of bytes to be read. The flag field identifies the data type (such as input event or updated data) and whether it is encrypted. If encryption is enabled (such as TLS or FIPS), it decrypts the data using the negotiated key, checks the MAC (Message Authentication Code) signature to ensure that the data has not been tampered with, verifies the integrity of the PDU, and finally parses out the payload according to the header information. For the Fast-Path Input Event PDU, it parses the input event (such as keyboard, mouse); for the Fast-Path Update PDU, it parses the image update command.

[0078] S4: The RDP proxy service establishes a persistent bi-directional connection with the Web front-end through WebSocket, defines corresponding events according to the type of the parsed PDU data, and transmits them to the Web browser side in real time.

[0079] Specifically, the event types and event contents defined in step S4 are as follows:

[0080] The'memblt' event is used to transmit MEMBLT drawing command data, which includes: (cacheId, cacheIndex) the bitmap cache ID and index, from which the bitmap data to be drawn can be found; (left, top) the coordinates of the target position on the screen where the bitmap data is to be drawn.

[0081] The 'bitmap' event is used to transmit CacheBitmapV2 drawing command data, which includes: (bitmap data) the actual bitmap data (binary), compressed by RLE; (cacheId, cacheIndex) the bitmap cache ID and index, where the bitmap data is stored in this cache area; (width, height) the width and height of the bitmap, in pixels.

[0082] The 'frame' event is used to transmit FrameMarker drawing control command data, which includes: (action): marking the start and end of a drawing frame, with two marking types: TS_FRAME_BEGIN for the start and TS_FRAME_END for the end.

[0083] The 'keyboard' event is used to transmit client keyboard input data, which includes: (key): the key value, converted from the keyboard scan code (scancode); (isReleased): the action, of bool type, indicating whether this key is a pressed / released action.

[0084] S5: The Web side establishes a WebSocket connection with the backend, creates a bitmap cache, and creates a canvas cache canvas. According to the different events received, it selects the corresponding processing method and displays the remote screen and key data of the RDP connection on the Web page in real time, realizing real-time monitoring of the RDP connection.

[0085] Specifically, the implementation method of the bitmap cache in step S5 is to define a JavaScript class BitmapCache, and define the class variable caches as a two-layer dictionary. The outer layer uses the cacheId as the key, and the inner layer uses the cacheIndex as the key to store and manage the image cache.

[0086] Specifically, the processing methods selected according to the different events received in step S5 are as follows:

[0087] When the 'bitmap' event is received, first decompress the bitmap data using the RLE algorithm, and then convert the decompressed bitmap data into an ImageData object and store it in the cache.

[0088] When the'memblt' event is received, first obtain the ImageData object from the cache according to the cache ID and index, and then call the putImageData() function to draw the ImageData on the cache canvas according to the coordinates of the target position.

[0089] When the 'frame' event is received, if it is the start marker of the drawing frame, clear the cache canvas and wait to receive the'memblt' event for drawing; if it is the end marker of the frame, call the drawImage() function to draw the cache canvas on the main canvas and display it on the browser page.

[0090] When the 'keyboard' event is received, display the key value together with the pressed / released action on the browser page.

[0091] Furthermore, as Figure 4 shown, in step S5, when the 'bitmap' event is received, the steps to decompress the bitmap data are as follows:

[0092] S51: Implement the RLE bitmap decompression algorithm in C language, named rle.c.

[0093] Specifically, rle.c contains multiple functions (such as bitmap_decompress_15, bitmap_decompress_16, etc.) for processing compressed bitmaps with different BPPs.

[0094] S52: Compile rle.c into a WebAssembly binary file rle.wasm and an rle.js file through the Emscripten compiler.

[0095] Specifically, rle.js is the JavaScript glue code generated by Emscripten for initializing the WebAssembly module.

[0096] S53: Load rle.js in HTML. rle.js will load rle.wasm into the browser environment and provide the Module object.

[0097] S54: Allocate memory using Module._malloc() in JavaScript to create buffers for the input (bitmapdata) and output (decompressed pixel data). Call the bitmap decompression function using Module.ccall() for decompression, and finally release the allocated memory using Module._free() to prevent memory leaks.

[0098] The above steps optimize the bitmap decompression process using WebAssembly technology, break through the performance bottleneck of JavaScript, improve the bitmap processing efficiency, and enhance the system performance.

[0099] The present invention provides a WEB-side real-time remote connection monitoring method based on the RDP protocol. By configuring the gateway server firewall and routing rules, the RDP traffic is forwarded to the local loopback address. Then, an RDP proxy service is started on the gateway server to listen to this address and receive and parse the RDP data stream. The parsed data is transmitted to the front end in real time using WebSocket, realizing the real-time display of the remote desktop screen and key records. The present invention can not only effectively monitor remote desktop sessions and improve the enterprise security protection level, but also has the advantages of high bandwidth utilization rate, low resource consumption, and convenient cross-platform deployment, providing an innovative technical implementation method for the remote desktop security monitoring system.

[0100] It should be further noted that the above embodiments and examples are only for understanding the technical solutions of the present invention. Any obvious adjustments and modifications made to the technical solutions of the present invention that belong to the technical concept of the present invention shall also fall within the protection scope of the present invention.

Claims

1. A real-time remote connection monitoring method for the WEB side based on the RDP protocol, characterized in that, It includes the following steps: Step 1: Maintain a gateway server between the RDP client and the server, configure the firewall, add a routing rule, and forward all received RDP traffic to the local loopback address; Step 2: Start the RDP proxy service at the back end of the gateway server, listen on 0.0.0.0:3389, receive the RDP traffic forwarded by the firewall, and at the same time create an independent thread to run the Flask application, listening for HTTP requests and WebSocket connections; Step 3: After the RDP proxy service receives the RDP packet, parse the RDP protocol data unit (PDU) according to the protocol format to obtain data such as the server graphics update command and the client keyboard input; Step 4: The RDP proxy service establishes a persistent two-way connection with the Web front end through WebSocket, defines corresponding events according to the parsed PDU data type, and transmits them to the Web browser side in real time; Step 5: The Web side establishes a WebSocket connection with the back end, creates a bitmap cache, and creates a canvas cache canvas. Selects corresponding processing methods according to the received different events, and displays the remote screen and key data of the RDP connection on the Web page in real time to achieve real-time monitoring of the RDP connection.

2. The real-time remote connection monitoring method for WEB side based on RDP protocol according to claim 1, characterized in that, In Step 1, the configuration content of the gateway server is as follows: S11: Turn on the IP forwarding function of IPv4 to ensure that the server can forward packets normally; S12: Use the TPROXY rule in the PREROUTING chain of iptables to forward the traffic with the destination of 3389 to the local loopback address and mark it; S13: Also mark the return traffic with the source port of 3389 to ensure that the outbound traffic also follows the customized routing policy; S14: Create a new routing table in / etc / iproute2 / rt_tables, add a route in the routing table, and forward the packet to the local loopback address; S15: Add a routing rule that all packets marked by iptables use the routing table created in Step S14 to find routing information for routing.

3. The real-time remote connection monitoring method for the WEB side based on the RDP protocol according to claim 1, characterized in that, In Step 2, the Flask application is started in the following way: Create a Flask application instance and a Socket instance in the global scope, use a daemon thread to start the Flask service in the proxy service main program, listen for HTTP and WebSocket requests, and the main thread continues to execute other logic to achieve concurrent operations.

4. A WEB-side real-time remote connection monitoring method based on the RDP protocol according to claim 1, characterized in that, In Step 3, when the RDP proxy service parses the RDP packet, it will first go through the parsing of the TCP layer and the Segmentation layer. The Segmentation layer will judge the packet type and route it to the TPKT layer or the Fast-Path layer. After the TPKT layer is parsed, it will be parsed by the X224 layer, the MCS layer, the Security layer, and the RDP layer in sequence, and combine with the data obtained after the Fast-Path layer is parsed to obtain data such as the server graphics update command and the client keyboard input.

5. The WEB-side real-time remote connection monitoring method based on the RDP protocol according to claim 4, characterized in that, The steps for the RDP proxy service to parse the RDP packet are as follows: S31: The proxy server listens on the RDP default port 3389, receives the TCP connection request initiated by the client. The TCP layer establishes a connection between the client and the server through three-way handshake, and then conducts data transmission. It supports TLS encryption to ensure communication security. After decryption, the data part is passed to the Segmentation layer; S32: The Segmentation layer receives a continuous byte stream from the TCP layer, reads the first byte, and determines whether it is 0x03. If so, it is recognized as a TPKT PDU and proceeds to step S33; otherwise, it is a Fast-Path PDU and proceeds to step S38; S33: The TPKT layer reads the TPKT header, calculates the PDU length, extracts the payload according to this length, and passes it to the x224 layer; S34: The X224 layer receives the PDU data from the TPKT layer. First, it reads the TPKT header, extracts the length field to confirm the PDU integrity. Then it reads the x224 header following the TPKT header, extracts the PDU Type field, determines the PDU type according to the PDU Type, and selects the corresponding processing method for processing or forwarding; S35: The MCS layer receives the PDU data from the X224 layer. First, it reads the TPKT header, extracts the length field to confirm the PDU integrity. Then it reads the MCS header after the TPKT header, extracts the PDU Type field, determines the PDU type according to the PDU Type, and selects the corresponding processing method for processing or forwarding; S36: The Security layer receives the PDU data from the MCS layer. First, it reads the security header, extracts the flag field to determine the PDU type and security options, and extracts the MAC value for subsequent verification; calculates the MAC using the shared key and the payload, compares the calculated result with the MAC in the PDU to ensure that the data has not been tampered with; Decrypts the payload, determines whether the payload is encrypted according to the flag. If encrypted, uses the negotiated encryption algorithm and key to decrypt the payload; finally passes the decrypted payload to the upper-layer RDP protocol layer for processing; S37: The RDP layer includes an I / O layer and a virtual channel layer, both of which need to parse the header fields, extract the PDU type, and select the corresponding processing method according to different types; S38: The Fast-Path layer receives the PDU forwarded from the Segmentation layer: reads the header of the PDU, including the length field and the flag field. The length field is used to indicate the size of the entire PDU, and the flag field identifies the data type and whether it is encrypted; if encrypted, decrypts the data using the negotiated key, checks the MAC signature to ensure that the data has not been tampered with, and finally parses out the effective payload Payload.

6. The real-time remote connection monitoring method for WEB side based on RDP protocol according to claim 1, characterized in that, The event types and event contents defined in step S4 are as follows: 'memblt' event, used to transmit MEMBLT drawing command data, the content includes: bitmap cache Id and index to find the bitmap data to be drawn; the coordinates of the target position on the screen where the bitmap data is to be drawn; The 'bitmap' event is used to transmit CacheBitmapV2 drawing command data, which includes: the actual bitmap data, compressed by RLE; the bitmap cache ID and index, where the bitmap data is stored in this cache area; the width and height of the bitmap, in pixels. The 'frame' event is used to transmit FrameMarker drawing control command data, which includes: marking the start and end of a drawing frame, with two marker types: TS_FRAME_BEGIN for the start and TS_FRAME_END for the end. The 'keyboard' event is used to transmit client keyboard input data, which includes: the key value, converted from the keyboard scan code; the action, of bool type, indicating whether this key is in the pressed / released action.

7. The WEB-side real-time remote connection monitoring method based on the RDP protocol according to claim 1, characterized in that, In step five, the implementation of the bitmap cache is as follows: define a JavaScript class BitmapCache, and define a class variable caches as a two-layer dictionary. The outer layer uses the cacheId as the key, and the inner layer uses the cacheIndex as the key to store and manage the image cache.

8. The WEB-side real-time remote connection monitoring method based on the RDP protocol according to claim 1, characterized in that, In step five, the processing methods selected according to different received events are as follows: When the 'bitmap' event is received, first decompress the bitmap data using the RLE algorithm, and then convert the decompressed bitmap data into an ImageData object and store it in the cache. When the'memblt' event is received, first obtain the ImageData object from the cache according to the cache ID and index, and then call the putImageData() function to draw the ImageData on the cache canvas according to the coordinates of the target position. When the 'frame' event is received, if it is a drawing frame start marker, clear the cache canvas and wait to receive the'memblt' event for drawing. If it is a frame end marker, call the drawImage() function to draw the cache canvas on the main canvas and display it on the browser page. When the 'keyboard' event is received, display the key value and the pressed / released action on the browser page together.

9. The WEB-side real-time remote connection monitoring method based on the RDP protocol according to claim 8, characterized in that, When the 'bitmap' event is received, the steps to decompress the bitmap data are as follows: S51: Decompress the bitmap using the RLE decompression algorithm implemented in C language. S52: The code file implementing the RLE decompression algorithm is named rle.c. Through the Emscripten compiler, the rle.c file is compiled into a WebAssembly binary file rle.wasm and a rle.js file. S53: Load rle.js in HTML. rle.js loads rle.wasm into the browser environment and provides a Module object. S54: Use Module._malloc() in JavaScript to allocate memory, creating buffers for the input bitmapdata and the output decompressed pixel data; use Module.ccall() to call the bitmap decompression function for decompression, and finally use Module._free() to release the allocated memory to prevent memory leaks.

Images