Optimization method and system for request header compression

Abstract

This application provides an optimized method and system for request header compression. The method includes: obtaining multiple historical network requests for a target interface; comparing the request header data in the multiple historical network requests; extracting request header data whose content has not changed as static request header data; sending the static request header data and the interface identifier of the target interface to the server, and receiving the cache identifier of the corresponding static request header data returned by the server; when intercepting a network request to be sent for the target interface, removing the static request header data from the request header data of the network request to be sent, and obtaining the remaining dynamic request header data; adding the cache identifier to the dynamic request header data to generate an optimized network request, and sending the optimized network request to the server. This reduces the transmission of redundant request header bytes in the request message from the source of network packet transmission, reduces network bandwidth overhead, and improves interface communication efficiency.

Description

Technical Field

[0001] This invention relates to the field of network communication technology, and in particular to an optimized method and system for request header compression. Background Technology

[0002] Currently, various internet systems typically engage in high-frequency data exchange via protocols such as HTTP or RPC. Taking the most common HTTP protocol as an example, according to the engineering specifications of communication protocols, each network interaction must carry complete request header data. In actual system operation, a large number of requests initiated by the same client device to the same target interface often contain highly repetitive fixed fields (such as device-specific parameters, unchanging authorization tickets, etc.). As application access volume increases, this mechanism of assembling and transmitting unchanging request header fields in full for each request leads to invalid data packets containing the same byte sequence being repeatedly transmitted in the network link. A large number of redundant byte strings not only waste the system's network bandwidth resources but also directly increase the physical packet size of a single network request, lengthening data transmission latency, and consequently restricting the overall system's network concurrency processing capabilities and access efficiency. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide an optimized method and system for request header compression, which can reduce the transmission of redundant request header bytes in request messages from the source of network packet sending, reduce network bandwidth overhead and improve interface communication efficiency.

[0004] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: An optimization method for request header compression, applied to the client side, includes: Obtain multiple historical network requests to the target interface, compare the request header data in the multiple historical network requests, and extract the request header data whose content has not changed as static request header data; Send the static request header data and the interface identifier of the target interface to the server, and receive the cache identifier corresponding to the static request header data returned by the server; When a network request to be sent for the target interface is intercepted, the static request header data is removed from the request header data of the network request to be sent, and the remaining dynamic request header data is obtained. The cache identifier is added to the dynamic request header data to generate an optimized network request, and the optimized network request is sent to the server.

[0005] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: An optimization method for request header compression, applied to the server side, includes: Receive static request header data and interface identifier of the target interface sent by the client; the static request header data is the request header data whose content remains unchanged after the client compares multiple historical network requests of the target interface; Generate a cache identifier corresponding to the static request header data based on the interface identifier, establish an association between the static request header data and the cache identifier, and store them in the local database; Return the cache identifier to the client; The system receives an optimized network request for the target interface sent by the client; the optimized network request header contains dynamic request header data and the cache identifier, and the optimized network request is generated by the client after intercepting the network request to be sent and removing the static request header data; Based on the cache identifier, the corresponding static request header data is read from the local database, and the static request header data is concatenated with the dynamic request header data to generate a complete network request.

[0006] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: An optimized system for request header compression includes a client and a server. The client includes a first processor and a first memory, the memory storing a computer program. The server includes a second processor and a second memory. When the first processor executes the computer program, it implements the steps executed by the client in the optimized program packaging method described above. When the second processor executes the computer program, it implements the steps executed by the client in the optimized program packaging method described above. The beneficial effects of this invention are as follows: By acquiring multiple historical network requests from the target interface on the client side, comparing and extracting static request header data with unchanged content, and pre-sending it to the server to obtain the corresponding short-byte cache identifier, the original static request header data is physically removed when a network request to be sent is subsequently intercepted. Only the remaining dynamic request header data is combined with the cache identifier and sent to the server for reassembly. This technical solution is based on the engineering logic of data state decoupling, splitting the request header payload in the network communication message into dynamic and static parts, replacing the large static request header data with a very small number of bytes of cache identifier. The overhead of repeatedly sending redundant byte sequences at high frequency in the network physical link is transformed into low-frequency single state synchronization and high-speed splicing and reading from the local memory of the receiving end. The physical volume of the network request is compressed from the source of message assembly, directly reducing the data transmission latency and network bandwidth consumption of a single interface interaction. Attached Figure Description

[0007] Figure 1This is a client flowchart of an optimization method for request header compression according to an embodiment of the present invention; Figure 2 This is a server-side flowchart of an optimized request header compression method according to an embodiment of the present invention; Figure 3 This is a schematic diagram of an optimized request header compression system according to an embodiment of the present invention. Detailed Implementation

[0008] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0009] In existing technologies, modern internet applications and related systems typically require high-frequency data interaction with servers via communication protocols such as Hypertext Transfer Protocol (HTTP) and Remote Procedure Call (RPC). Taking the most mainstream HTTP protocol as an example, to comply with communication engineering protocol specifications and complete identity verification or status transmission, each network packet must carry complete request header data (HTTP Headers), such as device basic attributes, authorization tokens, and User-Agent information. However, in actual business operation environments, for the same type of interface continuously called by the same client device, a large portion of the request header data is fixed and highly repetitive. This forces each request message to carry a large number of redundant and invalid byte sequences on the physical network link. As the scale of application users expands and the frequency of interface requests surges, this mechanism of forcibly transmitting all duplicate request headers not only wastes valuable network bandwidth but also significantly increases the packet size of a single network request, thereby lengthening the physical latency of network transmission and severely restricting the response efficiency of interfaces and the network throughput of the system in high-concurrency scenarios.

[0010] To at least address the aforementioned issues, this invention provides an optimized method for request header compression. The method first involves the client automatically collecting and comparing multiple historical requests to the target interface, extracting unchanged data as static request headers, and pre-synchronizing this data with the server in exchange for a very short cache identifier. Subsequently, when the client system intercepts a packet request for that interface again, it physically removes the original static request header data, sending only the changed dynamic data and the very short cache identifier. Upon receiving this simplified request, the server gateway quickly reads the corresponding complete static data from its local cache using the cache identifier, reassembles it with the dynamic data to reconstruct a standard message, and then hands it over to the backend service for processing.

[0011] This approach, based on the engineering logic of data state decoupling, cleverly splits network packet request headers into dynamic variables and static constants, replacing large volumes of fixed, unchanging data with extremely short-byte cache identifiers. This significantly reduces the size of packets that need to be transmitted through the physical network interface card (NIC) at the source, eliminating the overhead of repeated transmission of invalid, redundant bytes in the network. This effectively reduces network bandwidth consumption, decreases data transmission latency, and greatly improves overall access efficiency during high-frequency network interactions.

[0012] The following describes in detail an optimization method for request header compression according to the present invention. Please refer to [link / reference]. Figure 1 The method 100 includes steps 110 to 140: Step 110: Obtain multiple historical network requests for the target interface, compare the request header data in the multiple historical network requests, and extract the data parts in the request header data that have not changed as static request header data.

[0013] In one alternative implementation, when an internet application conducts network communication, the client initiates a request to a specified URL (i.e., the target interface) via protocols such as HTTP. Due to the communication protocol specifications, each request carries complete request header data. After sampling multiple historical communication messages, by parsing the message request headers, it is possible to physically separate the parts that dynamically change with each individual request from the parts that remain fixed over a long period.

[0014] Step 120: Send the static request header data and the interface identifier of the target interface to the server, and receive the cache identifier of the corresponding static request header data returned by the server.

[0015] In one optional implementation, after extracting the fixed request header data, the client proactively initiates a state synchronization action with the server, uploading the extracted data entities and their respective interface identifiers. Upon receiving and saving this data, the server allocates a cache identifier consisting of a very short byte sequence and sends it to the client to establish consensus on the data state between the two ends.

[0016] Step 130: When a network request to be sent to the target interface is intercepted, remove the static request header data from the request header data of the network request to be sent and obtain the remaining dynamic request header data.

[0017] In one alternative implementation, when the client's business logic sends a packet to the target interface again, the underlying network component intercepts the packet sending action. The packet stream is manipulated at the memory level, erasing previously identified immutable data from physical memory and retaining only the dynamic business attributes that indicate the specific operation being performed.

[0018] Step 140: Add the cache identifier to the dynamic request header data to generate an optimized network request, and send the optimized network request to the server.

[0019] In one alternative implementation, a very short cache identifier is injected into the network request header after redundant data has been removed. Since the short cache identifier consumes far less network bandwidth than a complete static request header, the size of the packet ultimately pushed to the physical network card and sent to the server is significantly reduced.

[0020] As described above, this invention obtains multiple historical network requests from the target interface on the client side, compares and extracts static request header data with unchanged content, and pre-sends it to the server to obtain the corresponding short-byte cache identifier. Then, when a subsequent network request is intercepted, the original static request header data is physically removed, and only the remaining dynamic request header data is combined with the cache identifier and sent to the server for reassembly. This technical solution is based on the engineering logic of data state decoupling, splitting the request header payload in the network communication message into dynamic and static parts. It replaces the large static request header data with a very small cache identifier, transforming the overhead of frequently sending redundant byte sequences in the network physical link into low-frequency single-time state synchronization and high-speed concatenation and reading from the receiver's local memory. This compresses the physical volume of the network request from the source of message assembly, directly reducing the data transmission latency and network bandwidth consumption of a single interface interaction.

[0021] In one embodiment of the present invention, steps 101 to 102 are included before obtaining multiple historical network requests of the target interface in step 110: Step 101: Record the number of network requests corresponding to each type of interface initiated by the client.

[0022] In one alternative implementation, the client layer is responsible for listening to all network packet sending actions and accumulating the frequency of their calls according to different interface path dimensions to quantify the network communication activity of each interface.

[0023] Step 102: Sort the network requests in descending order of quantity, and select the interfaces that are in the first preset position as the target interfaces.

[0024] In one alternative implementation, the requests are sorted in descending order based on their quantified frequency, and the interfaces with the highest request frequency (e.g., top 3 or top 5) are selected. Resources are then allocated to these most frequently called network requests for subsequent compression operations.

[0025] As described above, this application achieves quantitative analysis and priority allocation of network request scale by fully recording the frequency of interface calls and extracting them in descending order. In scenarios where client computing resources and memory space are limited, the core business interfaces with the highest request volume are precisely identified as the targets for request header compression, avoiding ineffective caching of low-frequency interfaces and maximizing the marginal benefits of performance optimization.

[0026] In one embodiment of the present invention, step 110 compares the request header data in multiple historical network requests and extracts the data portion of the request header data whose content has not changed as static request header data, including steps 111 to 113: Step 111: Parse the request header data of multiple historical network requests, and extract the multiple request header fields contained in the request header data and the field values ​​corresponding to each request header field.

[0027] In one alternative implementation, the collected messages are split into strings according to protocol standards such as HTTP / HTTPS, and the request header data is structured into multiple key-value pairs.

[0028] Step 112: For request header fields with the same name in multiple historical network requests, compare the field values ​​corresponding to each request.

[0029] In one alternative implementation, the key name is used as the comparison reference anchor point, and binary or character-level equality comparisons are performed on multiple values ​​captured at different times under the same anchor point.

[0030] Step 113: Combine the request header fields whose field values ​​remain consistent in each request with their corresponding field values ​​to construct static request header data.

[0031] In one alternative implementation, key-value pairs that differ from each other are removed, and key-value pairs that are completely equal in multiple samples are concatenated and recombined to form a data block consisting of constants.

[0032] As described above, by using structured message parsing, key anchoring, and value equivalence comparison, accurate extraction of steady-state features from the request header data is achieved. In engineering implementation, this logic based on multi-sample difference comparison eliminates the need for manual hard-coding of which fields to retain. Instead, the program adaptively converges to the steady-state set based on actual data flow characteristics, ensuring the objectivity of the extraction results and the reliability of data compression.

[0033] In one embodiment of the present invention, receiving the cache identifier of the corresponding static request header data returned by the server in step 120 includes steps 121 to 122: Step 121: Receive the cache identifier and the cache expiration time associated with the cache identifier returned by the server.

[0034] In one alternative implementation, while receiving the compression code, the server obtains the TTL (TimeToLive) parameter, which defines the effective boundary of the lifecycle of the cached data.

[0035] Step 122: Establish a mapping relationship between the target interface's interface identifier, cache identifier, and cache expiration time, and write it into the local cache.

[0036] In one alternative implementation, an index table is created in the client's memory or a lightweight local database to bind and store these three pieces of data for quick indexing when a subsequent request is triggered.

[0037] As described above, by introducing a cache expiration time and establishing a local memory mapping structure with the interface and identifier, lifecycle management of the compressed state is achieved. In practical applications, this allows clients to maintain data timeliness and avoid business anomalies caused by clients using expired request header data for extended periods due to remote server logic changes or login status failures.

[0038] In one embodiment of the present invention, before removing static request header data from the request header data of the network request to be sent in step 130, steps 125 to 128 are further included: Step 125: Locate the local cache based on the interface identifier of the network request to be sent, and obtain the corresponding cache identifier and cache expiration time.

[0039] In one alternative implementation, when a packet to be sent is intercepted at the network layer, its URL or path is extracted, and a locally established mapping table is retrieved.

[0040] Step 126: Determine if the current system time exceeds the cache expiration time.

[0041] In one alternative implementation, the underlying clock interface of the client operating system is invoked to compare the obtained current timestamp with the expiration timestamps recorded in the table.

[0042] Step 127: If the cache expiration time has not expired, then remove the static request header data from the request header data of the network request to be sent.

[0043] Step 128: If the cache expiration time has expired, stop the eviction operation and send the network request to be sent to the server with complete request header data.

[0044] As described above, by adding a comparison and verification step between the local index and the system clock during packet interception, dynamic degradation and fault tolerance of the request header compression strategy are achieved. Static request header data is strictly removed during the cache expiration period to ensure high network efficiency; once the cache expiration time is exceeded, it falls back to the standard full message sending mode, ensuring the continuity and robustness of the business request flow in extreme or cache-invalidation scenarios.

[0045] In one embodiment of the present invention, step 120, which involves sending the static request header data and the interface identifier of the target interface to the server, includes steps 118 to 119: Step 118: Obtain the client's unique device identifier.

[0046] In one alternative implementation, the physical or logical device entity that initiated the current request is identified by reading underlying hardware information such as a MAC address, IMEI, or application-generated UUID.

[0047] Step 119: Encapsulate the device unique identifier, interface identifier, and static request header data into a synchronization request, and send the synchronization request to the server.

[0048] In one alternative implementation, attributes representing the device are combined with business interface attributes to form a load subject, which then requests cache registration from the server.

[0049] As described above, by introducing a unique device identifier and encapsulating it with static request header data, strict spatial isolation of communication objects is achieved. In application scenarios where multiple terminals access the server, although different devices request the same interface, their Tokens or User-Agents are often different. Adding a device identifier as an isolation dimension fundamentally prevents the risk of state data corruption and unauthorized access between devices in a concurrent environment.

[0050] The following describes another optimization method for request header compression in this invention. Please refer to [link / reference]. Figure 2 The method 200 includes steps 210 to 250: Step 210: Receive the static request header data and interface identifier of the target interface sent by the client; the static request header data is the request header data that has not changed when the client compares the content of multiple historical network requests of the target interface.

[0051] Step 220: Generate a cache identifier for the corresponding static request header data based on the interface identifier, establish an association between the static request header data and the cache identifier, and store it in the local database.

[0052] In one alternative implementation, after receiving a synchronization message, the server generates a unique and short identifier string using a hash algorithm or an auto-incrementing sequence, and persists the mapping pair in the server's memory or a cache database (such as Redis).

[0053] Step 230: Return the cache identifier to the client.

[0054] Step 240: Receive the optimized network request for the target interface sent by the client; the optimized network request header contains dynamic request header data and cache identifier, and the optimized network request is generated by the client after intercepting the network request to be sent and removing the static request header data.

[0055] In one alternative implementation, the server gateway or load balancer intercepts a packet containing only a very small number of bytes and a cache identifier.

[0056] Step 250: Read the corresponding static request header data from the local database according to the cache identifier, and concatenate the static request header data with the dynamic request header data to generate a complete network request.

[0057] In one alternative implementation, the server uses the carried identifier string to retrieve the original large block of data from the cache database, reconstructs it in memory with the dynamic data block sent in this request, and then hands it over to the backend business logic for processing.

[0058] As described above, this application constructs a closed-loop mechanism on the server side for receiving, associating, storing, parsing, mapping, and reassembling messages. By pre-implanting the data unloaded by the client into the server's memory architecture, and utilizing the server's extremely high-speed memory read / write operations to replace the extremely slow external network transmission, the server can reconstruct complete messages to meet the protocol requirements of the backend system, while simultaneously achieving business architecture decoupling and improving link efficiency.

[0059] In one embodiment of the present invention, after generating the cache identifier corresponding to the static request header data based on the interface identifier in step 220, the method further includes step 221, and the return of the cache identifier to the client in step 230 includes step 231: Step 221: Configure the corresponding cache expiration time for the cache identifier.

[0060] Step 231: Send the cache identifier and cache expiration time to the client to instruct the client to replace the static request header data with the cache identifier before the cache expiration time has expired.

[0061] In one alternative implementation, the server assigns a lifetime constraint mechanism to each cache group and synchronizes the constraint rules to the client in the response message to ensure that both ends run under the same lifecycle contract.

[0062] As described above, by actively configuring and issuing lifecycle parameters on the server side, centralized control over the freshness of cached data is achieved between both ends. In actual engineering, this allows the server to adjust the expiration policy at any time according to its own resource capacity and business security requirements, preventing dirty data from residing for a long time and ensuring the security of the overall system architecture and the reasonable reclamation of storage resources.

[0063] In one embodiment of the present invention, receiving the static request header data and interface identifier of the target interface sent by the client in step 210 includes step 211, and establishing an association between the static request header data and the cache identifier and storing it in the local database in step 220 includes step 225. Step 211: Receive the static request header data of the target interface, the interface identifier, and the client's unique device identifier sent by the client.

[0064] Step 225: Establish the association between static request header data, cache identifier, and device unique identifier, and store them in isolation in the local database.

[0065] In one alternative implementation, during persistent storage operations on the server side, the device unique identifier is set as part of the primary key or composite primary key to form a two-dimensional positioning matrix of device ID and interface ID, thereby dividing the data area into independent regions.

[0066] As described above, by constructing an isolated storage structure based on unique device identifiers on the server side, sandboxed management of data in multi-path concurrent network request environments is achieved. In internet applications with millions or even tens of millions of concurrent requests, the cache privilege escalation problem caused by different physical terminals calling interfaces with the same name is completely eliminated, ensuring the absolute security of network optimization.

[0067] Please refer to Figure 3 The present invention also provides an optimization system 300 for request header compression, including a client and a server. The client includes a first processor 301 and a first memory 302, the memory storing a computer program. The server includes a second processor 303 and a second memory 304. When the first processor executes the computer program, it implements the steps executed by the client in any of the program packaging optimization methods. When the second processor executes the computer program, it implements the steps executed by the client in any of the program packaging optimization methods. In one alternative implementation, the system can be a smartphone terminal with specific components deployed, or a server cluster node in the cloud. The coordinated operation of the aforementioned hardware structure supports the physical implementation of the overall message compression architecture.

[0068] The following provides supplementary explanations of the application scenarios of the above-mentioned embodiments in conjunction with specific business systems: In one embodiment of the present invention, a unified forwarding SDK package is embedded in the client. All external business interface calls no longer directly call the system's native network library, but are instead diverted to this SDK package. The SDK package internally builds an observer model, silently collecting multiple message data of the same type of interface (the interface's unique identifier can be an HTTP URL path) throughout the program's lifecycle, performing memory interception and comparison, and automatically identifying and accumulating an unchanging header data pool. When initiating synchronization with the server, the server caches it and establishes a contract through the returned cache ID (i.e., cache identifier). When the business layer issues the same interface call again, the SDK package automatically intercepts and removes the unchanging parts of the original HTTP headers, directly writes the cache ID into the request header as a custom minimal field, and pushes it into the sending queue. When the request reaches the gateway system corresponding to the server, the gateway extracts the cache ID, directly loads the complete field data from the server's local memory buffer area, overwrites the request message, restores it to the standard HTTP format, and then sends it to the specific microservice business system.

[0069] As described above, by deploying the SDK package that takes over the global network channel and the corresponding gateway service, a "zero-intrusion" optimization of the existing business code is achieved. Business developers do not need to modify the existing request assembly logic. The underlying components will automatically isolate solid data through multiple sniffing and use mapping codes to replace long byte transmission, achieving the technical effect of greatly reducing physical network consumption and reducing request latency without changing the upper-layer protocol standard.

[0070] In summary, this application achieves physical compression of the packet payload volume by logically separating dynamic and static data in the network request header. By comparing multiple historical packets, steady-state redundant data in the request header is identified, and this data is replaced using a short identifier pre-stored on the server. The high-frequency transmission of a large number of repetitive byte sequences in the physical network link is transformed into local memory mapping and retrieval operations based on consensus identifiers at both ends. Since memory read speed far exceeds external network transmission speed, this solution directly reduces packet transmission latency by reducing the total number of data packets pushed into the physical network card.

[0071] Furthermore, by quantifying and sorting interface request frequencies, this ensures that computing resources are prioritized for core business interfaces. By introducing unique device identifiers and cache expiration time verification, the accuracy of cache status is guaranteed from both physical space isolation and temporal validity perspectives. Ultimately, this solution reduces message request header size while maintaining business protocol compatibility, effectively solving the problems of bandwidth resource waste and response latency caused by request header redundancy in high-frequency interaction scenarios, and improving the overall communication efficiency of the application system.

[0072] The above are merely embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention's specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. An optimized method for request header compression, characterized in that, Applied to a client, the method includes: Obtain multiple historical network requests to the target interface, compare the request header data in the multiple historical network requests, and extract the request header data whose content has not changed as static request header data; Send the static request header data and the interface identifier of the target interface to the server, and receive the cache identifier corresponding to the static request header data returned by the server; When a network request to be sent for the target interface is intercepted, the static request header data is removed from the request header data of the network request to be sent, and the remaining dynamic request header data is obtained. The cache identifier is added to the dynamic request header data to generate an optimized network request, and the optimized network request is sent to the server.

2. The optimization method for request header compression according to claim 1, characterized in that, Before obtaining the multiple historical network requests for the target interface, the following is also included: Record the number of network requests for each type of interface initiated by the client; The network requests are sorted in descending order of quantity, and the interfaces in the top preset positions are selected as the target interfaces.

3. The optimization method for request header compression according to claim 1, characterized in that, The step of comparing the request header data from the multiple historical network requests and extracting the request header data with unchanged content as static request header data includes: Parse the request header data of the multiple historical network requests, and extract the multiple request header fields contained in the request header data and the field values ​​corresponding to each of the request header fields; For request header fields with the same name in the multiple historical network requests, compare the field values ​​corresponding to each request; The request header fields whose field values ​​remain consistent across all requests, along with their corresponding field values, are combined to construct the static request header data.

4. The optimization method for request header compression according to claim 1, characterized in that, The cache identifier for receiving the static request header data returned by the server includes: Receive the cache identifier and the cache expiration time associated with the cache identifier returned by the server; Establish a mapping relationship between the interface identifier of the target interface, the cache identifier, and the cache expiration time, and write it into the local cache.

5. The optimization method for request header compression according to claim 4, characterized in that, Before removing the static request header data from the request header data of the network request to be sent, the method further includes: The local cache is located based on the interface identifier of the network request to be sent, and the corresponding cache identifier and cache expiration time are obtained. Determine whether the current system time exceeds the cache expiration time; If the cache expiration time has not been exceeded, then the step of removing the static request header data from the request header data of the network request to be sent is performed; If the cache expiration time is exceeded, the eviction operation is stopped, and the network request to be sent is sent to the server with complete request header data.

6. The optimization method for request header compression according to claim 1, characterized in that, Sending the static request header data and the interface identifier of the target interface to the server includes: Obtain the unique device identifier of the client; The device unique identifier, the interface identifier, and the static request header data are encapsulated into a synchronization request, and the synchronization request is sent to the server.

7. An optimized method for request header compression, characterized in that, Applied to the server side, the method includes: Receive static request header data and interface identifier of the target interface sent by the client; the static request header data is the request header data whose content remains unchanged after the client compares multiple historical network requests of the target interface; A cache identifier corresponding to the static request header data is generated based on the interface identifier, and the static request header data is associated with the cache identifier and stored in the local database; Return the cache identifier to the client; The system receives an optimized network request for the target interface sent by the client; the optimized network request header contains dynamic request header data and the cache identifier, and the optimized network request is generated by the client after intercepting the network request to be sent and removing the static request header data; Based on the cache identifier, the corresponding static request header data is read from the local database, and the static request header data is concatenated with the dynamic request header data to generate a complete network request.

8. The optimization method for request header compression according to claim 7, characterized in that, After generating the cache identifier corresponding to the static request header data based on the interface identifier, the method further includes: Configure a corresponding cache expiration time for the cache identifier; Returning the cache identifier to the client includes: sending the cache identifier and the cache expiration time to the client together, so as to instruct the client to replace the static request header data with the cache identifier if the cache expiration time has not expired.

9. The optimization method for request header compression according to claim 7, characterized in that, The static request header data and interface identifier of the target interface sent by the receiving client include: Receive the static request header data, interface identifier, and unique device identifier of the client sent by the client for the target interface; The step of establishing a relationship between the static request header data and the cache identifier and storing it in the local database includes: The static request header data, the cache identifier, and the device unique identifier are associated and stored in the local database in an isolated manner.

10. An optimized system for request header compression, characterized in that, The device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor, when executing the computer program, implements the steps of the optimization method for request header compression as described in any one of claims 1 to 6.

Images