An online packet-level traffic simulation method, system and storage medium for website fingerprint defense

Abstract

The application provides an online packet-level traffic simulation method, system and storage medium for website fingerprint defense, which comprises the following steps: step 1: a traffic simulation execution module specifies a simulation target traffic sequence; step 2: the traffic simulation execution module acquires communication data; step 3: a custom data packet format is defined, which at least comprises a header field, a security metadata field, a padding field and a data body field; step 4: for the i-th simulation step in the target sequence, a target packet size is read, the effective payload length carried thereby is calculated according to the fixed header length, the original application byte stream is split, the split data segments are written into the data body field, and the data body is encrypted; step 5: a client and a relay node are respectively provided with a direction synchronization module, and the same target direction sequence and a local step number counter are maintained; and step 6: the original communication data is recovered and forwarded. The application has the beneficial effect of improving the pertinence of website fingerprint defense.

Description

Technical Field

[0001] This invention relates to the field of computer network security technology, and in particular to an online message-level traffic simulation method, system, and storage medium for website fingerprinting defense. Background Technology

[0002] With the widespread adoption of encrypted communication protocols such as HTTPS, TLS, QUIC, and VPN, traditional network behavior identification methods based on plaintext payload content are no longer directly applicable. However, encrypted communication does not completely hide external behavioral characteristics during the communication process. Passive observers located along the communication path, such as internet service providers, enterprise gateways, wireless access points, and backbone routing nodes, can still observe metadata such as packet size, packet direction, sending order, inter-packet time intervals, and burst patterns without decrypting the communication content, and infer the type of website or service accessed by the user based on this. In website fingerprinting attack scenarios, attackers typically collect encrypted traffic samples from known websites, train machine learning or deep learning classifiers, and then match and identify newly observed user access traffic. Existing research shows that packet direction can reflect the request-response interaction relationship between the browser and the server, and packet size can reflect protocol encapsulation, content fragmentation, and page resource loading characteristics. These two factors and their temporal relationship together constitute important discrimination criteria for current website fingerprint classifiers.

[0003] To address the aforementioned issues, existing website fingerprinting defense methods primarily include traffic obfuscation, traffic splitting, and traffic simulation. Traffic obfuscation methods typically disrupt the original traffic characteristics through padding, fake packet injection, fixed-rate transmission, or random delays. However, these methods often incur high bandwidth and latency overhead, and fixed perturbation rules can easily create new defense fingerprints, which attackers can relearn through retraining. Traffic splitting methods divide complete traffic into multiple sub-streams through multi-path transmission or proxy forwarding, reducing the amount of information obtainable from a single observation point. However, they rely on multi-path networks, proxy nodes, or end-device collaborative deployment, resulting in high deployment requirements in real-world network environments. Furthermore, their effectiveness decreases when attackers possess multi-point observation or sub-stream correlation capabilities. Traffic simulation methods attempt to make protected traffic approximate the traffic characteristics of the target website or target category, potentially misleading classifiers. However, existing methods mostly remain at the burst level or statistical distribution level of simulation, unable to control packet size, direction, and order on a packet-by-packet basis during real online communication, and also struggle to simultaneously meet the requirements of real-time execution, transparent deployment, and low overhead.

[0004] Further analysis reveals that while existing defense patents have attempted to weaken website fingerprinting and encrypted traffic analysis capabilities from different angles, they still have their limitations. Patent CN115361221B, "A Website Fingerprinting Defense System and Method Based on Data Poisoning," generates triggers through a data poisoning model, and the client agent and defense agent collaborate to inject these triggers into the traffic trace to mislead the website fingerprint classifier. However, this method primarily relies on trigger injection to influence the classifier's decisions, making it susceptible to being learned by the classification adversarial model. CN118713900B, "A Dynamic Low-Overhead Traffic Obfuscation Method Based on Packet Length Distribution," uses packet length distribution mapping, segmentation, stacking, and length modification to make packets approximate the target length distribution, reducing the overhead of traditional padding. However, this method mainly addresses packet length distribution obfuscation and does not solve the problem of joint identification of packet direction, packet sequence, and bidirectional interaction structure by the website fingerprint classifier. CN118890210A, "A Website Fingerprint Defense Method Based on Adversarial Generative Networks," utilizes adversarial generative networks to generate website traffic patterns and constructs defense targets around traffic bursts and burst intervals. It adds virtual data packets through a dynamic bandwidth mechanism to make the original traffic approximate the target traffic pattern. However, this method primarily focuses on generative shaping at the burst-level traffic pattern and interval level, failing to achieve synchronized control of packet size, direction, and sequence at the message level.

[0005] Therefore, existing technologies lack a defense method that can perform bidirectional, message-level, and targeted simulation of real online communication traffic without modifying the server, kernel, or application logic. In particular, there is a lack of a technical solution that can simultaneously control packet size, packet direction, and packet sequence order.

[0006] The information disclosed in this background section is intended only to enhance understanding of the overall background of the invention and should not be construed as an admission or in any way implying that the information constitutes prior art known to those skilled in the art. Summary of the Invention

[0007] The purpose of this invention is to provide an online packet-level traffic simulation method for website fingerprinting defense. By constructing a packet-level behavior sequence of the target website and coordinating the size and direction of the data packets of the protected traffic during the communication process, the method makes the traffic pattern of the specified target website appear in the externally observable characteristics. This reduces the ability of the website fingerprint classifier to identify the real accessing website and achieves a controllable balance between defense effectiveness, communication overhead and deployment convenience.

[0008] This invention discloses an online packet-level traffic simulation method for website fingerprinting defense, comprising: Step 1, Construct the simulated target sequence: Specify the simulated target traffic sequence through the traffic simulation execution module. The target traffic sequence describes the packet-level behavioral characteristics of the target website or target category to be simulated; the target traffic sequence includes a target packet size sequence and a target packet direction sequence. Step 2, Obtain Communication Data: The traffic simulation execution module obtains communication data, which includes: raw communication data generated by the client's local application and data returned to the client by the real target server; Step 3, Construct a custom data packet format: The system defines a custom data packet format, which includes at least a header field, a security metadata field, a padding field, and a data body field. The header field stores control information required for data packet parsing and flow management. The security metadata field stores encryption-related information. The padding field is used to pad the target length when the actual payload is insufficient. The data body field carries the encrypted original application data. Step 4, Perform packet size simulation: For the i-th simulation step in the target sequence, the system reads the target length of the i-th packet in the target traffic sequence. And according to the fixed head length Calculate the payload length that this data packet can carry: ,in, This represents the available length of the data volume for the i-th simulation step. Indicates the length of the custom header and necessary control fields; the system follows... The original application byte stream is segmented, the segmented data fragments are written into the data body field, and the data body is encrypted. Step 5, Perform packet direction synchronization: The client and the cooperative relay node each deploy a direction synchronization module and maintain the same target direction sequence and local step number counter. In each simulation step, the direction synchronization module reads the current target direction. The direction synchronization module determines whether it should send a data packet or wait to receive a data packet based on the direction. When the current direction requires the local end to send a data packet, the direction synchronization module checks the local end's pending transmission queue. When the current direction requires the local end to receive a data packet, the direction synchronization module waits for the data packet sent by the peer end. Step 6, Restore and forward the original communication data: The collaborative relay node receives and restores the simulated data packets from the client, and then forwards the restored data to the real target server; the collaborative relay node receives the data returned from the real target server, reshapes the data into data packets that conform to the target sequence, and then forwards them to the client.

[0009] As a further improvement of the present invention, in step 1, the target flow sequence is represented as: ,in, Represents the target packet size sequence. Indicates the target length of the i-th data packet in the target traffic sequence; Indicates the target packet direction sequence. Where +1 indicates that the traffic is sent from the client to the collaborative relay node, and -1 indicates that the traffic is sent from the collaborative relay node to the client; the target traffic sequence is derived from real website traffic collected in advance, or from typical traffic templates generated or selected according to the target category.

[0010] As a further improvement of the present invention, in step 2, the original communication data enters the encrypted transmission channel between the client and the cooperative relay node, and is re-encapsulated into data packets conforming to the target traffic sequence within the encrypted transmission channel; after receiving the tunnel data, the cooperative relay node is responsible for decapsulating, decrypting, reassembling and forwarding to the next hop or the real target server; for the data returned by the real target server, the cooperative relay node sends the returned data to the traffic simulation execution module to perform the traffic simulation process before returning it to the client.

[0011] As a further improvement of the present invention, in step 3, the header field includes packet type, protocol type, packet number, number of fragments, fragment offset, and synchronization step number. The packet type is used to distinguish between real packets and pseudo packets. The protocol type is used to indicate the type of the upper-layer protocol being encapsulated. The packet number is used to identify the packet order. The number of fragments and the fragment offset are used to support fragmentation and reassembly during cross-packet transmission. The synchronization step number is used to support directional synchronization between the client and the relay node. The security metadata field includes session identifier, random number, or parameters required for key derivation.

[0012] As a further improvement of the present invention, in step 4, in order to ensure that encryption does not change the data length, the system adopts a length-preserving encryption method.

[0013] As a further improvement of the present invention, in step 4, when the currently available application data is not empty but its length is less than the target length, the system appends random padding bytes after the encrypted data, so that the length of the final generated data packet reaches the target length. When a data packet needs to be sent in the current simulation step but the application layer has not yet generated valid data, the system generates a fake data packet. The fake data packet adopts the same or compatible data packet format as the real data packet and is identified by the data packet type field. After the receiving end identifies the fake data packet, it does not participate in the reassembly as real application data, but instead performs discarding or protocol response processing.

[0014] As a further improvement of the present invention, in step 5, if there is a data packet in the queue to be sent that has already completed size simulation, then the data packet at the head of the queue is retrieved, and the next synchronization number is written into its header field. It is sent through an encrypted overlay tunnel; if the queue to be sent is empty, a pseudo data packet that meets the current target length requirement is generated, the next step synchronization number is written into its header and then sent; after the sending is completed, the local step number advances to the next step; In step 5, the receiving end parses the synchronization number in the header of the data packet. If the synchronization number is greater than the local current step number, the local step number is updated to the synchronization number. For real data packets, the receiving end puts them into the receiving queue and reassembles them according to the information, which includes: number of fragments, fragment offset, and data packet number. For fake data packets, the receiving end discards them or performs only protocol-level processing according to the data packet type field.

[0015] As a further improvement of the present invention, step 6 further includes: After receiving a simulated data packet from the client, the collaborative relay node first determines whether it is a real data packet or a fake data packet based on the header field of the data packet. For fake data packets, the collaborative relay node either discards them directly or performs protocol-level processing. For real data packets, the collaborative relay node caches, sorts, and reassembles them according to the fragmentation information, and decrypts the data body to recover the original application byte stream. The recovered uplink data is then forwarded by the collaborative relay node to the real target server. For the downlink data returned by the real target server, the cooperative relay node, as the peer, performs the same encapsulation, size simulation, and direction synchronization process, reshaping the real target server's response data into a data packet that conforms to the target sequence before sending it to the client; after receiving it, the client decrypts, reassembles, and restores the data, and delivers the restored data to the local application.

[0016] The present invention also discloses an online message-level traffic simulation system for website fingerprinting defense, comprising: a memory, a processor, and a computer program stored in the memory, wherein the computer program is configured to implement the steps of the method described in the present invention when invoked by the processor.

[0017] The present invention also discloses a computer-readable storage medium storing a computer program configured to implement the steps of the method described in the present invention when invoked by a processor.

[0018] Key protection points of this invention: 1. Existing technologies often employ methods such as random padding, packet length distribution adjustment, packet rate perturbation, burst-level traffic generation, or trigger injection. Their main purpose is to disrupt the original traffic characteristics or alter the statistical distribution of the traffic. This invention, however, pre-defines a target traffic sequence and reshapes the protected traffic packet by packet according to this target sequence during actual communication, making the externally observable data packet size, direction, and transmission order approximate the target traffic. The difference lies in the fact that existing technologies primarily obfuscate or perturb the original traffic, while this invention uses the target traffic as a template for online, packet-by-packet, targeted simulation.

[0019] 2. Existing technologies typically target only a single dimension for defense, such as adjusting packet length distribution, changing packet transmission rate, or adding virtual packets at the burst level. These methods struggle to simultaneously disrupt the packet length, direction, and bidirectional interaction sequence structure upon which website fingerprint classifiers rely. This invention considers both target packet size and direction in each simulation step. On one hand, it ensures packet length conforms to the target sequence through fragmentation, encapsulation, encryption, padding, and pseudo-packet generation. On the other hand, it controls the transmission direction to ensure the bidirectional packet order conforms to the target sequence. The difference lies in the fact that existing technologies often focus on local feature processing, while this invention directly simulates the packet-level joint features used by the classifier.

[0020] 3. Existing defense methods mostly perform padding, delaying, or injection operations at one end, making it difficult for the single end to determine the direction and order of data packet transmission in a complete bidirectional communication flow. This invention maintains the target direction sequence and synchronization step number jointly at both the client and the cooperative relay node. The sending end writes the next synchronization number in the data packet header, and the receiving end parses this number and updates its local state, thus enabling both parties to advance synchronously according to the same target direction sequence. The difference lies in the fact that existing technologies struggle to precisely control the bidirectional packet sequence, while this invention achieves controllable simulation of the direction and order of bidirectional data packets through two-end cooperation.

[0021] The method of this invention addresses network communication security issues such as encrypted traffic privacy protection, website fingerprint attack defense, traffic obfuscation, and traffic simulation, achieving the following beneficial effects: 1. Improve the targeting of website fingerprinting defense: This invention reshapes the data packet size, data packet direction and sending order of the protected traffic online, so that the traffic characteristics observed externally are close to the target traffic, thereby weakening the website fingerprint classifier's ability to identify real websites. 2. Overcoming the problem of coarse granularity in existing methods: Existing defense methods mostly focus on packet length distribution adjustment, burst-level traffic shaping, or trigger injection, making it difficult to control packet-by-packet behavior in real communication processes. This invention directly acts on the message-level sequence, enabling simultaneous control of data packet size and direction, and more effectively disrupting the packet-level joint features that classifiers rely on.

[0022] 3. Improved feasibility of actual deployment: This invention can be executed between the client and the collaborative relay node without requiring the cooperation of the remote server or modification of the operating system kernel or application logic. It can complete traffic simulation while maintaining the correctness of the original communication semantics, reducing deployment complexity and improving practicality. Attached Figure Description

[0023] Figure 1 This is a diagram of the overall architecture of the method of this invention; Figure 2 This is a flowchart simulating the data packet size of the method of the present invention; Figure 3 This is a flowchart of the data packet direction synchronization method of the present invention. Detailed Implementation

[0024] The specific embodiments of the present invention will now be described in detail with reference to the accompanying drawings, but it should be understood that the scope of protection of the present invention is not limited to the specific embodiments.

[0025] Unless otherwise expressly stated, throughout the specification and claims, the term "comprising" or its variations such as "including" or "comprises" shall be understood to include the stated elements or components without excluding other elements or other components.

[0026] This invention discloses an online packet-level traffic simulation method for website fingerprinting defense. This method pre-specifies a target traffic sequence and reshapes the packet size, direction, and sending order of the protected traffic online during actual user communication. This makes the traffic characteristics seen by an external passive observer approximate the target traffic sequence, thereby reducing the ability of the website fingerprint classifier to identify genuinely accessed websites. This invention mainly includes a traffic simulation execution module and a data recovery and forwarding module, with the overall architecture as follows: Figure 1 The traffic simulation execution module is used to fragment, encapsulate, encrypt, pad, and generate pseudo-packets of the original communication data according to the target traffic sequence between the client and the cooperative relay node, and controls the sending direction and order of data packets through a dual-end synchronization mechanism. The data recovery and forwarding module is used to decapsulate, decrypt, and reassemble the received real data packets, and forward the recovered original communication data to the real target server or deliver it to the local application. The implementation process of this invention mainly includes: constructing a simulated target sequence, obtaining the original communication data, performing data packet size simulation, performing data packet direction synchronization, and recovering and forwarding the original communication data.

[0027] This invention discloses an online packet-level traffic simulation method for website fingerprinting defense, comprising: Step 1, Construct the simulated target sequence: The traffic simulation execution module first specifies a target traffic sequence for simulation. This target traffic sequence describes the packet-level behavioral characteristics of the target website or target category to be simulated. The target traffic sequence includes a target packet size sequence and a target packet direction sequence, represented as follows: .

[0028] in, Represents the target packet size sequence. This represents the target length of the i-th data packet in the target traffic sequence. Indicates the target packet direction sequence. Here, +1 indicates that the traffic is sent from the client to the collaborative relay node, and -1 indicates that the traffic is sent from the collaborative relay node to the client. The target traffic sequence can originate from pre-collected real website traffic, or from typical traffic templates generated or selected based on the target category.

[0029] Step 2, Obtain Communication Data: The traffic simulation execution module obtains communication data, which includes: raw communication data generated by the client's local application and data returned to the client by the real target server; During actual user communication, the client side acquires the raw communication data generated by the local application and hands it over to the traffic simulation execution module for processing. The raw communication data is not sent out directly according to its natural packet length and direction of transmission. Instead, it enters an encrypted transmission channel between the client and the cooperative relay node, where it is re-encapsulated into data packets conforming to the target traffic sequence. The remote target server requires no modification and continues to receive requests and return responses using normal communication methods.

[0030] What is actually visible on the external network are the tunnel data packets between the client and the cooperative relay node. After receiving the tunnel data, the cooperative relay node is responsible for decapsulating, decrypting, reassembling, and forwarding it to the next hop or the actual target server. For data returned by the server, the relay node also sends it through a traffic simulation process before returning it to the client.

[0031] Step 3, construct a custom data packet format: To support online packet-level traffic simulation, the system uses a custom data packet format, which includes at least a header field, a security metadata field, a padding field, and a data body field.

[0032] The header fields store control information required for packet parsing and flow management, including packet type, protocol type, packet number, number of fragments, fragment offset, and synchronization step number. Specifically, the packet type distinguishes between real and pseudo-packets; the protocol type indicates the type of the upper-layer protocol being encapsulated; the packet number identifies the packet order; the number of fragments and fragment offset support fragmentation and reassembly during cross-packet transmission; and the synchronization step number supports directional synchronization between the client and relay nodes. The security metadata fields store encryption-related information, such as session identifiers, random numbers, or parameters required for key derivation. The padding fields are used to pad the target length when the actual payload is insufficient. The data body field carries the encrypted raw application data.

[0033] Step 4, perform packet size simulation: like Figure 2 For the i-th simulation step in the target sequence, the system reads the target length of the i-th data packet in the target traffic sequence. And according to the fixed head length Calculate the payload length that this data packet can carry: ,in, This represents the available length of the data volume for the i-th simulation step. Indicates the length of the custom header and necessary control fields; the system follows... The original application byte stream is segmented, and the segmented data fragments are written into the data body field and then encrypted. To ensure that encryption does not change the data length, the system can use a length-preserving encryption method, such as counter mode encryption or other streaming encryption methods.

[0034] When the currently available application data is not empty but its length is less than the target length, the system appends random padding bytes after the encrypted data to make the final generated data packet length reach the target length. When a simulation step requires sending a data packet but the application layer has not yet generated valid data, the system generates a pseudo-data packet. The pseudo-data packet uses the same or compatible data packet format as the real data packet and is identified by a data packet type field. After identifying the pseudo-data packet, the receiving end does not treat it as real application data for reassembly, but instead discards it or performs a protocol response. In this way, the system can ensure that the data packet length seen by an external observer is consistent with the target packet size sequence, while not disrupting the transmission semantics of the real application data.

[0035] Step 5, perform data packet direction synchronization: like Figure 3 Data packet direction synchronization is used to ensure that the bidirectional data packet transmission order between the client and the cooperative relay node conforms to the target packet direction sequence. Both the client and the cooperative relay node deploy direction synchronization modules and maintain the same target direction sequence and local step number counter. In each simulation step, the direction synchronization module reads the current target direction. Based on this direction, the local end determines whether it should send a data packet or wait to receive a data packet; When the current direction requests the local end to send a data packet, the direction synchronization module checks the local end's send queue; if there is a data packet in the send queue that has already completed size simulation, the data packet at the head of the queue is retrieved, and the next synchronization number is written into its header field. It is then sent via an encrypted overlay tunnel. If the queue to be sent is empty, a pseudo-data packet conforming to the current target length requirement is generated, and the next synchronization number is written into its header before being sent. After sending is complete, the local step number advances to the next step.

[0036] When the receiving end requests to receive a data packet in the current direction, the direction synchronization module waits for the data packet sent by the peer. The receiving end parses the synchronization number in the data packet header. If the synchronization number is greater than the local current step number, the local step number is updated to the synchronization number. For real data packets, the receiving end puts them into the receive queue and reassembles them based on information such as the number of fragments, fragment offset, and data packet number. For spurious data packets, the receiving end discards them or performs only protocol-level processing based on the data packet type field.

[0037] Step 6: Restore and forward the original communication data: After receiving simulated data packets from the client, the collaborative relay node first determines whether the data packet is real or fake based on the packet header fields. For fake data packets, the collaborative relay node either discards them directly or performs protocol-level processing. For real data packets, the collaborative relay node caches, sorts, and reassembles them based on fragmentation information, and decrypts the data body to recover the original application byte stream. The recovered uplink data is then forwarded by the relay node to the real target server.

[0038] For downlink data returned by the real target server, the collaborative relay node, acting as the peer, performs the same encapsulation, size simulation, and direction synchronization processes. It reshapes the real target server's response data into data packets conforming to the target sequence before sending it to the client. Upon receiving the data, the client decrypts, reassembles, and restores it, then delivers the restored data to its local application. Thus, without altering the application's communication semantics, the system makes externally observable client-to-collaborative relay node traffic exhibit the packet-level behavioral characteristics of the target website.

[0039] Through the above steps, this invention provides an online, bidirectional, message-level target traffic simulation method. Unlike traditional methods that only change statistical distributions or burst characteristics, this invention directly controls the size, direction, and transmission order of data packets during real communication, making the protected traffic approximate the specified target website in terms of packet-level characteristics observable by attackers, thereby reducing the effectiveness of identifying website fingerprint attacks.

[0040] The present invention also discloses an online message-level traffic simulation system for website fingerprinting defense, comprising: a memory, a processor, and a computer program stored in the memory, wherein the computer program is configured to implement the steps of the method described in the present invention when invoked by the processor.

[0041] The present invention also discloses a computer-readable storage medium storing a computer program configured to implement the steps of the method described in the present invention when invoked by a processor.

[0042] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the concept of the present invention, and all such modifications and substitutions should be considered within the scope of protection of the present invention.

Claims

1. An online packet-level traffic simulation method for website fingerprinting defense, characterized in that, include: Step 1, Construct the simulated target sequence: Specify the simulated target traffic sequence through the traffic simulation execution module. The target traffic sequence is used to describe the packet-level behavioral characteristics of the target website or target category to be simulated. The target traffic sequence includes a target packet size sequence and a target packet direction sequence; Step 2, Obtain Communication Data: The traffic simulation execution module obtains communication data, which includes: raw communication data generated by the client's local application and data returned to the client by the real target server; Step 3, Construct a custom data packet format: The system defines a custom data packet format, which includes at least a header field, a security metadata field, a padding field, and a data body field. The header field stores control information required for data packet parsing and flow management. The security metadata field stores encryption-related information. The padding field is used to pad the target length when the actual payload is insufficient. The data body field carries the encrypted original application data. Step 4, Perform packet size simulation: For the i-th simulation step in the target sequence, the system reads the target length of the i-th packet in the target traffic sequence. And according to the fixed head length Calculate the payload length that this data packet can carry: ,in, This represents the available length of the data volume for the i-th simulation step. Indicates the length of the custom header and necessary control fields; the system follows... The original application byte stream is segmented, the segmented data fragments are written into the data body field, and the data body is encrypted. Step 5, Perform packet direction synchronization: The client and the cooperative relay node each deploy a direction synchronization module and maintain the same target direction sequence and local step number counter. In each simulation step, the direction synchronization module reads the current target direction. The direction synchronization module determines whether it should send a data packet or wait to receive a data packet based on the direction. When the current direction requires the local end to send a data packet, the direction synchronization module checks the local end's pending transmission queue. When the current direction requires the local end to receive a data packet, the direction synchronization module waits for the data packet sent by the peer end. Step 6, Restore and forward the original communication data: The collaborative relay node receives and restores the simulated data packets from the client, and then forwards the restored data to the real target server; the collaborative relay node receives the data returned from the real target server, reshapes the data into data packets that conform to the target sequence, and then forwards them to the client.

2. The online message-level traffic simulation method according to claim 1, characterized in that, In step 1, the target flow sequence is represented as: ,in, Represents the target packet size sequence. Indicates the target length of the i-th data packet in the target traffic sequence; Indicates the target packet direction sequence. Where +1 indicates that the traffic is sent from the client to the collaborative relay node, and -1 indicates that the traffic is sent from the collaborative relay node to the client; the target traffic sequence is derived from real website traffic collected in advance, or from typical traffic templates generated or selected according to the target category.

3. The online message-level traffic simulation method according to claim 1, characterized in that, In step 2, the original communication data enters the encrypted transmission channel between the client and the cooperative relay node, and is re-encapsulated into data packets that conform to the target traffic sequence within the encrypted transmission channel; After receiving tunnel data, the collaborative relay node is responsible for decapsulating, decrypting, reassembling, and forwarding the data to the next hop or the real target server. For the data returned by the real target server, the collaborative relay node sends the returned data to the traffic simulation execution module to perform the traffic simulation process before returning it to the client.

4. The online message-level traffic simulation method according to claim 1, characterized in that, In step 3, the header fields include packet type, protocol type, packet number, number of fragments, fragment offset, and synchronization step number. The packet type is used to distinguish between real packets and pseudo packets. The protocol type is used to indicate the type of the upper-layer protocol being encapsulated. The packet number is used to identify the packet order. The number of fragments and fragment offset are used to support fragmentation and reassembly during cross-packet transmission. The synchronization step number is used to support directional synchronization between the client and the relay node. The security metadata fields include session identifier, random number, or parameters required for key derivation.

5. The online message-level traffic simulation method according to claim 1, characterized in that, In step 4, to ensure that encryption does not change the data length, the system adopts a length-preserving encryption method.

6. The online message-level traffic simulation method according to claim 1, characterized in that, In step 4, when the currently available application data is not empty but its length is less than the target length, the system appends random padding bytes after the encrypted data to make the final generated data packet length reach the target length. When a data packet needs to be sent in the current simulation step but the application layer has not yet generated valid data, the system generates a fake data packet. The fake data packet adopts the same or compatible data packet format as the real data packet and is identified by the data packet type field. After the receiving end identifies the fake data packet, it does not participate in the reassembly as real application data, but instead performs discarding or protocol response processing.

7. The online message-level traffic simulation method according to claim 1, characterized in that, In step 5, if there are data packets in the queue that have already completed size simulation, then the data packet at the head of the queue is retrieved, and the next synchronization number is written into its header field. It is sent through an encrypted overlay tunnel; if the queue to be sent is empty, a pseudo data packet that meets the current target length requirement is generated, and the next synchronization number is written into its header before it is sent. After sending, the local step number advances to the next step; In step 5, the receiving end parses the synchronization number in the header of the data packet. If the synchronization number is greater than the local current step number, the local step number is updated to the synchronization number. For real data packets, the receiving end places them into the receiving queue and reassembles them according to the information, which includes: number of fragments, fragment offset, and data packet number; For fake data packets, the receiving end either discards them or performs only protocol-level processing based on the data packet type field.

8. The online message-level traffic simulation method according to claim 1, characterized in that, Step 6 also includes: After receiving a simulated data packet from the client, the collaborative relay node first determines whether it is a real data packet or a fake data packet based on the header field of the data packet. For fake data packets, the collaborative relay node either discards them directly or performs protocol-level processing. For real data packets, the collaborative relay node caches, sorts, and reassembles them according to the fragmentation information, and decrypts the data body to recover the original application byte stream. The recovered uplink data is then forwarded by the collaborative relay node to the real target server. For the downlink data returned by the real target server, the cooperative relay node, as the peer, performs the same encapsulation, size simulation, and direction synchronization process, reshaping the real target server's response data into a data packet that conforms to the target sequence before sending it to the client; after receiving it, the client decrypts, reassembles, and restores the data, and delivers the restored data to the local application.

9. An online packet-level traffic simulation system for website fingerprinting defense, characterized in that, include: A memory, a processor, and a computer program stored on the memory, the computer program being configured to implement the steps of the method of any one of claims 1-8 when invoked by the processor.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program configured to implement the steps of the method according to any one of claims 1-8 when invoked by a processor.

Images