A / b test based network connection protocol optimization method, system, computer device and medium

Abstract

The application relates to an A / B test-based network connection protocol optimization method, system, computer device and medium, the method comprising the following steps: a client obtains a configuration containing a candidate protocol list from a configuration center; a sampling probability is used for group determination, and after group determination, a test protocol is randomly selected; a probe carrying complete protocol characteristics is executed, a private format is used for analysis and address echo verification is used for determining the probe result; if the probe is successful, the protocol is used for proxying traffic, a protocol identifier is written into a connection request, and the probe result is reported; a server attributes test traffic through double verification of the identifier and the bearing protocol, and the success rate of the probe and traffic indexes are counted; when a sample meets effectiveness conditions, protocol priority order is generated through sorting and is released to the configuration center for application by the client in subsequent connection. The application can continuously and accurately evaluate candidate connection protocols without affecting the networking experience of most users, and can dynamically release optimal protocol order.

Description

Technical Field

[0001] This application relates to the field of network communication technology, and in particular to a method, system, computer equipment, and medium for optimizing network connection protocols based on A / B testing. Background Technology

[0002] VPN (Virtual Private Network) / proxy products offering global services typically incorporate multiple switchable connection protocols. These include basic protocols and their enhanced variants based on UDP (User Datagram Protocol), TCP (Transmission Control Protocol), TLS (Transport Layer Security), and HTTP (Hypertext Transfer Protocol), as well as HTTP CONNECT proxy protocols, QUIC (Quick UDP Internet Connections), and Wireguard (an open-source VPN protocol). These protocols are not general network probing protocols like ICMP (Internet Control Message Protocol), but rather multiple interchangeable connection bearers used within the VPN / proxy product to establish data tunnels. The same tunnel service can be carried by any of these protocols. However, these protocols differ in transport layer type, handshake method, encryption, and traffic characteristics, resulting in varying availability and transmission quality under different network censorship and interference environments. Determining the optimal connection protocol and its fallback order for the user is a core challenge for these products.

[0003] In related technologies, a common practice is to rely on manual experience to fix the protocol configuration order. However, network environments are constantly changing; for example, operators may upgrade their blocking policies, or the traffic characteristics of a certain protocol may be identified by DPI (Deep Packet Inspection). Manual configuration is difficult to adjust automatically and in a timely manner according to changes in the network environment, resulting in high operating costs and slow response times. Another common practice is to rely on general connectivity probes such as ICMP to determine protocol availability. However, these probes do not carry the protocol's own handshake and traffic characteristics, and cannot reflect whether the protocol can completely establish a tunnel under real inspection conditions. Furthermore, probe responses may come from reflections from intermediate network devices, easily leading to false judgments that the connection appears to be available but is actually unusable. In addition, related technologies generally lack metrics for transmission quality after a successful connection. For example, some protocols can establish a connection but are subsequently rate-limited or intermittently interrupted. Simple connectivity success rates cannot reflect the actual transmission quality available to users, while simple traffic statistics cannot reflect the initial success probability of the connection. Furthermore, if a candidate protocol is directly switched and tested on all users, it will cause widespread connection failures if the protocol performs poorly in a specific network environment, resulting in a high risk of trial and error. Even if a better protocol order is obtained through testing, how to enable all users to apply the result in a timely manner at low cost is a problem that related technologies have not been able to solve properly. Summary of the Invention

[0004] To address the aforementioned shortcomings or drawbacks, this application provides a method, system, computer equipment, and medium for optimizing network connection protocols based on A / B testing.

[0005] This application provides a method for optimizing a network connection protocol based on A / B testing, according to a first aspect. This method is applied to a system including a client and a server, and includes: The client performs the following operations: When initiating a connection, protocol configuration data is obtained from the configuration center. The protocol configuration data includes a list of candidate protocols and a protocol priority fallback chain. The inclusion determination is performed on this connection according to the preset sampling probability, and the inclusion determination result is obtained; If the grouping result indicates that the connection is included in the group, a candidate protocol is randomly selected from the candidate protocol list as the test protocol. Establish a connection with the server corresponding to the test protocol according to the protocol establishment process, send an application layer probe frame to the server, receive the response frame returned by the server, and determine the probe result of the test protocol based on the response frame; wherein, if the response frame is successfully parsed according to the preset protocol format and the parsed fields include the network address of the client echoed by the server, the probe result is determined to be successful. If the detection result is successful, the business traffic of this connection will be forwarded to the server through the test protocol, the protocol identifier of the test protocol will be written into the connection request, and the connection request carrying the protocol identifier and the detection result will be sent to the server. The server performs the following operations: If it is determined that the connection request carries a protocol identifier and the protocol carrying the service traffic is consistent with the protocol identifier, the service traffic is counted as the test traffic of the test protocol. Based on the probe results reported by multiple connections and the test traffic of each candidate protocol obtained by statistics, the probe success rate and traffic indicators of each candidate protocol are calculated. If the sample data meets the preset validity conditions, the candidate protocols are sorted according to at least one of the detection success rate and traffic indicators to obtain the protocol priority order. The protocol priority order is published to the configuration center to update the protocol configuration data, so that when the client initiates a connection in a subsequent connection, it can determine the connection protocol to use based on the updated protocol configuration data.

[0006] This application provides a method for optimizing network connection protocols based on A / B testing, applied to a client, according to a second aspect. The method includes: When initiating a connection, protocol configuration data is obtained from the configuration center. The protocol configuration data includes a list of candidate protocols and a protocol priority fallback chain. The inclusion determination is performed on this connection according to the preset sampling probability, and the inclusion determination result is obtained; If the grouping result indicates that the connection is included in the group, a candidate protocol is randomly selected from the candidate protocol list as the test protocol. Establish a connection with the server corresponding to the test protocol according to the protocol establishment process, send an application layer probe frame to the server, receive the response frame returned by the server, and determine the probe result of the test protocol based on the response frame; wherein, if the response frame is successfully parsed according to the preset protocol format and the parsed fields include the network address of the client echoed by the server, the probe result is determined to be successful. If the detection result is successful, the business traffic of this connection will be forwarded to the server through the test protocol, the protocol identifier of the test protocol will be written into the connection request, and the connection request carrying the protocol identifier and the detection result will be sent to the server.

[0007] This application provides a method for optimizing network connection protocols based on A / B testing, applied to a server, according to a third aspect. The method includes: It receives probe results reported by the client and connection requests sent by the client. The probe result refers to the probe result of the test protocol determined by the client after randomly selecting a candidate protocol from the candidate protocol list as the test protocol when the client joins the connection group, establishing a connection according to the protocol establishment process of the test protocol, and sending an application layer probe frame. The connection request carries the protocol identifier of the test protocol. If it is determined that the connection request carries a protocol identifier and the protocol carrying the service traffic is consistent with the protocol identifier, the service traffic is counted as the test traffic of the test protocol, and the detection success rate and traffic indicators of each candidate protocol are calculated based on the detection results reported by multiple connections and the test traffic of each candidate protocol. If the sample data meets the preset validity conditions, the candidate protocols are sorted according to at least one of the detection success rate and traffic indicators to obtain the protocol priority order. The protocol priority order is published to the configuration center to update the protocol configuration data stored in the configuration center, so that when the client initiates a connection in a subsequent connection, it can determine the connection protocol to use based on the updated protocol configuration data.

[0008] This application provides a system according to a fourth aspect, the system including a client and a server; the system is used to perform the preferred method for network connection protocol based on A / B testing provided in any embodiment of the first aspect.

[0009] According to a fifth aspect, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the preferred method for a network connection protocol based on A / B testing as described in the third or fourth aspect.

[0010] According to a sixth aspect, this application provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the preferred method of a network connection protocol based on A / B testing in the third or fourth aspect.

[0011] This application can continuously evaluate the performance of multiple candidate connection protocols in a real network environment without affecting the normal network experience of the vast majority of users, and dynamically publish the optimal protocol priority order obtained from the evaluation to all user applications.

[0012] This application firstly determines the inclusion of connections according to a preset sampling probability, allowing only a small number of included connections to participate in the test. This avoids widespread connection failures caused by full-scale trial and error, minimizing the impact of the test on all users. Secondly, by establishing connections according to the test protocol's establishment process and sending application-layer probe frames, and requiring response frames to be successfully parsed according to a preset protocol format with the parsed fields including the client's network address echoed by the server, the probes accurately reflect the protocol's availability in the current network environment and eliminate misjudgments caused by reflections from intermediate network devices. Thirdly, by only including service traffic as test traffic for the test protocol when the connection request carries a protocol identifier and the protocol carrying the service traffic matches the protocol identifier, the evaluation traffic and normal traffic are strictly distinguished and attributed, ensuring the accuracy and reliability of the probe success rate and traffic indicators of each candidate protocol. Furthermore, by only performing sorting when the sample data meets preset validity conditions, misjudgments due to insufficient samples are avoided. Finally, by publishing the protocol priority order to the configuration center to update the protocol configuration data, all clients can automatically apply the latest protocol priority order when initiating connections, achieving low-cost diffusion of test benefits to all users. Attached Figure Description

[0013] Figure 1 A flowchart illustrating a method for optimizing a network connection protocol based on A / B testing in one or more embodiments of this application; Figure 2 This is a schematic diagram of the system architecture in one or more embodiments of this application; Figure 3 This is a schematic diagram of the internal structure of a computer device according to one or more embodiments of this application. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings. It should be understood that the described embodiments are merely some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0015] In the following description, when referring to the accompanying drawings, the same numbers in different drawings denote the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0016] In the description of this application, it should be understood that the terms "first," "second," "third," etc., are used only to distinguish similar objects and are not necessarily used to describe a specific order or sequence, nor should they be construed as indicating or implying relative importance. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances. Furthermore, in the description of this application, unless otherwise stated, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0017] To address the shortcomings or defects of related technologies, this application provides a network connection protocol optimization method based on A / B testing, according to the first aspect. This method can continuously and accurately evaluate candidate connection protocols and dynamically publish the optimal protocol order without affecting the network experience of the vast majority of users. In some exemplary embodiments of this application, such as Figure 1 As shown, the method includes steps S110-S180. The following detailed explanation of each step is based on an example of the method being applied to a system. This system includes a client 10 (which may include computer devices such as a laptop 11, desktop computer 12, or smartphone 13) and a server 20 (which may be an independent server, a server cluster, etc.). Its architecture can be found in [reference needed]. Figure 2 As shown.

[0018] Step S110: When the client initiates a connection, it obtains protocol configuration data from the configuration center. The protocol configuration data includes a list of candidate protocols and a protocol priority fallback chain.

[0019] The configuration center refers to a distributed configuration storage accessible to both the client and server. For example, the configuration center can organize key-value pairs by cluster name, user type (free / paid), and country code, storing recommended default protocols, version numbers of the recommended default protocols, protocol priority fallback chains, and a list of domain names for each protocol. This information is written by the server's computational tasks and read by the client during connection. The candidate protocol list refers to a collection of multiple interchangeable connection protocols currently available for establishing data tunnels. These network connection protocols are not general network probing protocols like ICMP, but rather connection bearer methods used internally by VPN / proxy products to establish data tunnels. The same tunnel service can be carried by any of these protocols, such as basic connection protocols like UDP, TCP, TLS, HTTP, HTTP CONNECT, QUIC, and Wireguard, as well as various enhanced variants derived from these basic protocols by changing the handshake method, bearer format, and traffic characteristics. The protocol priority fallback chain is a data structure used to indicate the order in which connection protocols are attempted. For example, the protocol priority fallback chain can be a two-dimensional list, with the outer layer arranged by priority and the inner layer grouping protocols of the same priority. The client attempts each group sequentially according to the order of the outer layer.

[0020] In this step, the client can read the currently effective protocol configuration data from the configuration center by cluster name, user type, and country code each time a connection is initiated, such as automatic connection after application startup, manual connection by the user, disconnection reconnection, configuration refresh reconnection, etc. For example, if there is no independent configuration for the country, the client can fall back to read the baseline country or global configuration. In addition to the candidate protocol list and protocol priority fallback chain, the content read may also include the recommended default protocol and its version number, the list of domain names required for each protocol handshake and the candidate set of TLS client handshake fingerprints, the list of outgoing server IPs, ports, line group identifiers, regional priority speed test groups, and probe parameters, such as the number of packets sent in a single probe and the minimum number of responses required for a successful determination.

[0021] This step retrieves the currently effective protocol configuration data from the configuration center each time a connection is initiated, ensuring that the client's connection decisions are always based on the latest configuration. This allows the client to obtain an updated list of candidate protocols and protocol priority fallback chains without needing to upgrade the client.

[0022] Step S120: The client performs an inclusion determination on this connection according to the preset sampling probability and obtains the inclusion determination result.

[0023] Sampling probability is a parameter used to control the proportion of a single connection entering the test group, and it can be pre-configured and issued by the server. Group inclusion determination refers to the process of determining whether this connection should participate in the A / B test; the result of the group inclusion determination includes either inclusion or exclusion.

[0024] In this step, the client can perform a random decision on the current connection according to a preset sampling probability, such as a Bernoulli decision. If the random result matches the sampling probability, the connection is accepted; otherwise, it is rejected. For example, the sampling probability can default to 5 / 100, and the system design constrains the upper limit of the sampling probability to no more than 5 / 100. For example, the acceptance decision can be bound to each connection attempt rather than permanently bound to the device; the same client can make independent decisions in different connection cycles.

[0025] This step involves enrolling a small number of connections with a low probability, thus avoiding widespread connection failures caused by full trial and error, and allowing the sample to spread naturally across both time and device dimensions.

[0026] Step S130: If the group entry determination result is that the connection is entered into the group, the client randomly selects a candidate protocol from the candidate protocol list as the test protocol.

[0027] The test protocol refers to the candidate protocol selected for detection and evaluation in this connection.

[0028] In this step, when the group inclusion result is "inclusion", the client can randomly select one candidate protocol from the candidate protocol list with equal probability as the test protocol. For example, special protocols configured not to participate in random testing can be pre-removed from the candidate protocol list; the test protocol tested in a single group inclusion event is unique and unchanged, and the client will not iterate through multiple candidate protocols in the same group inclusion event.

[0029] This step uses a single protocol for random sampling, which ensures that each test sample has a unique statistical classification, avoiding statistical inconsistencies caused by traversing multiple protocols during a single group entry, and guaranteeing the accuracy of subsequent statistical data.

[0030] Step S140: The client establishes a connection with the server corresponding to the test protocol according to the protocol establishment process, sends an application layer probe frame to the server, receives a response frame returned by the server, and determines the probe result of the test protocol based on the response frame; wherein, if the response frame is successfully parsed according to the preset protocol format and the parsed fields include the network address of the client echoed by the server, the probe result is determined to be successful.

[0031] The protocol establishment process refers to the complete establishment process executed during actual use, including selecting the transport layer type according to protocol requirements for dial-up connection and performing the protocol's own handshake process. An application layer probe frame is a probe data frame sent at the application layer after the protocol handshake is completed. For example, an application layer probe frame can be a heartbeat probe frame in a private VPN packet format, carrying a client identifier and KeepAlive / IsPing command flags. A response frame is a response data frame returned by the server in response to the application layer probe frame. The preset protocol format refers to the private packet format agreed upon with the server. The client's network address can be the client's public IPv4 address, which can be identified by the server when processing the application layer probe frame and echoed in the response frame. The probe result refers to the conclusion of this probe of the test protocol, including at least probe success and probe failure.

[0032] In this step, the client can perform a probe before establishing a connection: first, select the transport layer type (e.g., TCP or UDP) according to the test protocol requirements and dial to the server port corresponding to the test protocol; then, perform the protocol's own handshake process according to the configured domain name and TLS client handshake fingerprint; after the handshake is completed, the client sends an application layer probe frame to the server and waits for the server to return a response frame; for example, the client can perform multiple send and receive operations according to the configuration and count the round-trip latency and packet loss rate of each send and receive operation.

[0033] After receiving the response frame, the client can parse it according to a preset protocol format. Only if the parsing is successful and the parsed fields include the client's network address echoed by the server, is the response confirmed to have originated from the server actually running the test protocol and a protocol-level round trip completed, thus determining the probe result as successful. If the response frame cannot be parsed or the echoed network address is missing, the response is determined to be a reflection packet from a network intermediate device, and the probe is treated as a failure. For example, after the probe is completed, the client can also calculate a probe quality score based on round-trip time and packet loss rate, for example, using the formula Score = -2 × RTT - 8 × Lost, where RTT is the round-trip time and Lost is the packet loss rate; the weighting coefficients can be adjusted.

[0034] This step, by fully executing the protocol's own establishment process and sending application-layer probe frames, as well as performing private format parsing and echo address verification on the server's response, ensures that the probe accurately reflects the protocol's availability in the current censorship environment and eliminates false successes caused by reflected traffic from intermediate devices such as firewalls and transparent proxies.

[0035] Step S150: If the detection result is successful, the client forwards the service traffic of this connection to the server through the test protocol, writes the protocol identifier of the test protocol into the connection request, and sends the connection request carrying the protocol identifier and the detection result to the server.

[0036] Service traffic refers to the data traffic actually generated by the user using the network after the connection is established. Protocol identifier refers to unique identification information used to identify the test protocol, such as the name of the test protocol. Connection request refers to a request initiated by the client to the server to establish a service connection.

[0037] In this step, if the probe is successful, the client can forward all business traffic to the server through the test protocol proxy for the entire lifecycle of this connection (e.g., until the next disconnection and reconnection), allowing the test protocol to carry real user traffic. The client can also write the protocol identifier of the test protocol into a dedicated field in the connection request (a pre-defined field in the connection request structure used to carry the protocol identifier) ​​and send the connection request carrying the dedicated field to the server. For example, the dedicated field is only assigned a value when the connection is successfully joined; it is always empty in a normal connection, and the value of the dedicated field remains unchanged during the reconnection process. After the probe is completed, regardless of whether it is successful or not, the client can immediately report a probe result to the server. For example, the server can supplement the received date and device identifier to form a six-tuple record including the date, test protocol, status, duration in milliseconds, final connection status, and device identifier.

[0038] This step involves enabling the test protocol to carry real business traffic after a successful probe, and using a dedicated field to carry the protocol identifier with the connection request. This allows the server to simultaneously know the test traffic attributes and their corresponding test protocol based solely on the connection request, without the need to allocate additional test batch identifiers.

[0039] Step S160: When the server determines that the connection request carries a protocol identifier and the protocol carrying the business traffic is consistent with the protocol identifier, it counts the business traffic as the test traffic of the test protocol. Based on the probe results reported by multiple connections and the test traffic of each candidate protocol obtained by statistics, the server calculates the probe success rate and traffic indicators of each candidate protocol.

[0040] Test traffic refers to service traffic identified as generated during A / B testing. Probe success rate is a metric reflecting the probability of a test protocol's connectivity. Traffic metrics reflect the actual transmission quality after a successful connection; for example, traffic metrics may include average traffic per connection.

[0041] In this step, the server can attribute business traffic during the billing / traffic statistics phase: when the connection request carries a protocol identifier and the actual protocol carrying the business traffic matches the protocol identifier, the server writes the business traffic into the A / B test-specific traffic table according to dimensions such as date, platform, country, and protocol, strictly isolating it from the normal traffic table; if the protocol carrying the business traffic does not match the protocol identifier, for example, in a scenario where the client randomly selects a test protocol but the test protocol probe fails and the fallback protocol successfully carries the traffic, the server can exclude this business traffic from the test protocol's test traffic. The server can also calculate the probe success rate and traffic metrics for each candidate protocol based on the probe results reported from multiple connections and the test traffic in the A / B test-specific traffic table.

[0042] This step uses a dual verification process, carrying both the protocol identifier and the carrier protocol, to attribute traffic. This ensures that the evaluation traffic is strictly distinguished from normal traffic, and that traffic carried by the fallback protocol is not incorrectly attributed to the test protocol, thus guaranteeing accurate and reliable detection success rate and traffic metrics.

[0043] Step S170: If the sample data meets the preset validity conditions, the server sorts the candidate protocols according to at least one of the detection success rate and traffic indicators of each candidate protocol to obtain the protocol priority order.

[0044] Sample data refers to the accumulated probe results and test traffic within the statistical window. Validity conditions refer to the criteria used to determine whether the sample data meets statistical reliability standards. For example, validity conditions may include statistical window conditions, probe sample size conditions, and traffic sample size conditions. Corresponding parameters include a 14-day statistical window, a probe sample size of at least 100 times within the window, and a total test traffic volume of at least 1TB. Protocol priority order refers to the order in which candidate protocols are ranked according to their merits.

[0045] In this step, the server can determine whether the sample data meets the preset validity conditions. If so, the server can sort the candidate protocols based on at least one of the following: detection success rate and traffic metrics, to obtain the protocol priority order. For example, the server can determine the comprehensive score by summing the product of the traffic metrics and the traffic weight coefficient, and the product of the detection success rate and the success rate weight coefficient, and sort them in descending order of comprehensive score. For example, the traffic weight coefficient is 0.6 and the success rate weight coefficient is 0.4. Alternatively, the server can use the total window traffic adjusted by a conversion factor as the sorting basis. If the sample data does not meet the validity conditions, the server can choose not to update the sorting results and continue using the previously published protocol priority order.

[0046] This step, by triggering the sort update only after the sample data has reached statistical validity, avoids publishing unreliable sorting results when the sample is insufficient, thus ensuring the statistical credibility of the published protocol priority order.

[0047] Step S180: The server publishes the protocol priority order to the configuration center to update the protocol configuration data, so that when the client initiates a connection in the future, it can determine the connection protocol to be used for the connection based on the updated protocol configuration data.

[0048] In this step, the server can write the protocol priority order into the configuration center to update the protocol configuration data stored in the configuration center. For example, before writing, the server can calculate the content digest of the protocol priority order to be written and compare it with the content digest currently stored in the configuration center. If the content has not changed, the writing is skipped.

[0049] Each time the client initiates a connection, it can read the updated protocol configuration data and determine the connection protocol to be used for that connection based on the protocol priority fallback chain or recommended default protocol in the updated protocol configuration data. For example, the server can generate a new version number and release it with the configuration when the recommended default protocol changes. The client records whether the version number has been applied, and when it reads a new version number that has not been applied, it switches the default protocol to the recommended default protocol all at once.

[0050] This step, through the mechanism of "server-side computation and publishing + client-side connection retrieval," enables all clients to apply the latest protocol priority order without upgrading, pushing, or interrupting established sessions, allowing the test benefits to spread to all users at almost zero cost.

[0051] In the above embodiments of this application, firstly, the client performs grouping determination on the connection according to a preset sampling probability, allowing only a small number of grouped connections to participate in the test, thus avoiding large-scale connection failures caused by full trial and error; secondly, by establishing a connection and sending application layer probe frames according to the protocol establishment process of the test protocol, and performing private format parsing and echo address verification on the response frames, the probe can truly reflect the protocol availability and eliminate misjudgments caused by reflections from intermediate devices; thirdly, the server performs traffic attribution by carrying a protocol identifier with dual verification of consistency with the carrying protocol, which can ensure the accuracy and reliability of the probe success rate and traffic indicators; furthermore, by performing sorting only after the sample data meets the validity conditions, misjudgments caused by insufficient samples can be avoided; finally, by publishing the protocol priority order to the configuration center to update the protocol configuration data, all clients can automatically apply the latest results, achieving low-cost diffusion of test benefits.

[0052] In some embodiments, the client performs an inclusion determination on the current connection according to a preset sampling probability, and obtains the inclusion determination result, including: If the client determines that the connection meets the preconditions for inclusion, it performs a Bernoulli decision on the connection according to the sampling probability corresponding to the target region to which the client belongs, and obtains the inclusion decision result. The preconditions for inclusion include at least one of the following: the user who initiated the connection is an unsubscribed user, the client is running on the specified operating system platform, and the line group identifier of the connection is empty. Among them, the sampling probability corresponding to different regions is configured independently and does not exceed the preset probability upper limit. The sampling probability corresponding to regions whose historical sample data volume reaches the preset data volume threshold is less than the sampling probability corresponding to regions whose historical sample data volume does not reach the preset data volume threshold. The group entry determination is bound to each connection, and the same client performs the group entry determination independently in different connection cycles.

[0053] Preconditions for inclusion refer to the conditions that a connection request must meet to be eligible for inclusion. A Bernoulli decision is a single random decision that outputs one of two mutually exclusive results with a specified probability. The preset probability upper limit refers to the highest constraint value set by the system for the sampling probability. The preset data volume threshold is a threshold used to determine whether historical sample data for a region is sufficient.

[0054] In this embodiment, the client can first determine whether the current connection meets the preconditions for grouping. Exemplary preconditions include: the user initiating the connection is a free user who has not subscribed; the client is running on a specified operating system platform such as iOS or Android; the line group identifier for this connection is empty (i.e., the user selects the fastest automatic line); and the current connection belongs to a specified product project. After meeting the preconditions, the client performs a Bernoulli determination according to the sampling probability corresponding to the target region to which the client belongs. Exemplarily, the sampling probability can be configured independently by country / region: the default is 5 / 100, and for regions with historical sample data reaching a preset data threshold and with independent protocol sorting (e.g., the United States, Canada, the United Kingdom, Iran, Russia, and the United Arab Emirates), it can be reduced to 2 / 100, and the sampling probability of any region does not exceed the preset probability upper limit of 5 / 100. The grouping determination is bound to each connection attempt rather than permanently bound to the device. The same client makes independent determinations at different connection periods; for example, this connection is grouped to test protocol A, the next connection is not grouped, and the next connection is grouped to test protocol B.

[0055] This embodiment protects the experience of paid users and fixed-line users from being affected by filtering pre-enrollment conditions and configuring sampling probabilities according to regional differences. It allows regions with sufficient data to maintain continuous observation with less disturbance, while regions with insufficient data can accelerate sample accumulation with a default upper limit.

[0056] In some embodiments, the method further includes: when the test protocol is different from the original user protocol used by the client before this connection, the client constructs a temporary fallback chain based on the test protocol, the original user protocol, and the protocol priority fallback chain, wherein the first priority protocol of the temporary fallback chain is the test protocol, the second priority protocol is the original user protocol, and the subsequent priority groups are the remaining protocol groups after deleting the test protocol and the original user protocol from the protocol priority fallback chain; when the test protocol is the same as the original user protocol, the client determines the protocol priority fallback chain as the temporary fallback chain.

[0057] The original user protocol refers to the connection protocol used by the client prior to this connection. The temporary fallback chain refers to the sequence of protocol attempts temporarily constructed by the client for this test.

[0058] This embodiment constructs a temporary fallback chain with the test protocol as the first step and the user's original protocol as the next step. This ensures that the test protocol gets a testing opportunity while retaining the user's original available protocol as the most recent fallback, and avoids repeated invalid attempts on the same protocol.

[0059] In some embodiments, the method further includes: if the probe result is a probe failure, the client performs connection establishment using the original user protocol according to the priority order of the temporary fallback chain; if the connection fails using the original user protocol, the client performs connection establishment group by group according to the order of the remaining protocol groups in the temporary fallback chain until the connection is successful, and sends the service traffic of this connection to the server through the protocol that the connection is successful; if all protocols in the temporary fallback chain fail to connect, the client determines that the connection has failed, and reports the connection failure result of this connection as a negative sample of the test protocol to the server.

[0060] Negative samples refer to failure-class sample data used to characterize protocol unavailability.

[0061] This embodiment, through a layered fallback sequence, can ensure the availability of user connections when the test protocol is unavailable. At the same time, the reporting of failed samples can enable the server to perceive the unavailability of the test protocol in the current network environment, providing data basis for prioritizing it.

[0062] In some embodiments, the client establishes a connection with the server corresponding to the test protocol according to the protocol establishment process of the test protocol, sends application layer probe frames to the server, receives response frames returned by the server, and determines the probe result of the test protocol based on the response frames. This includes: the client dials up to the server port corresponding to the test protocol according to the transport layer type corresponding to the test protocol, and performs a protocol handshake with the server according to the configured domain name and TLS client handshake fingerprint; after the protocol handshake is completed, the client sends multiple application layer probe frames to the server according to the configured number of probe packets, and receives response frames returned by the server; the round-trip delay and packet loss rate of each transmission are calculated, and the probe result is determined based on the response frames received within their respective timeout limits for each transmission.

[0063] Transport layer type refers to the type of transport layer protocol used, such as TCP or UDP. TLS client handshake fingerprint refers to the set of characteristics of the client's Hello message during the TLS handshake phase. For example, the configuration center can issue a candidate set of TLS client handshake fingerprints for the client to choose from. Probe packet count refers to the number of application layer probe frames actually sent in a single probe. Round-trip time (RTT) is the time interval between sending an application layer probe frame and receiving a response frame. Packet loss rate refers to the proportion of application layer probe frames that do not receive a response frame within the timeout period. Application layer probe frames can be application layer heartbeat probe frames, which are a type of application layer probe frame. For example, a heartbeat frame in a private VPN packet format, carrying a client identifier and KeepAlive / IsPing command flags, can be used.

[0064] In this embodiment, the client can dial to the server port corresponding to the test protocol according to the transport layer type of the test protocol, and perform a protocol handshake with the server according to the configured domain name and TLS client handshake fingerprint. After the handshake is completed, the client sends multiple application layer heartbeat probe frames to the server according to the configured number of probe packets, receives the response frames returned by the server, calculates the round-trip latency and packet loss rate of each transmission, and determines the probe result based on the response frames received within their respective timeout limits for each transmission. For example, since the handshake overhead of different protocols is different, the client can determine the number of probe packets by deducting the probe packet budget according to the known round-trip number of handshakes of the test protocol, so as to ensure the probe caliber is fair among protocols with different handshake overheads. The probe packet budget refers to the total number of transmissions allowed in a single probe.

[0065] This embodiment enables the probe to verify whether the protocol has been identified, intercepted, or hijacked by fully executing the protocol's own handshake process and performing real round trips with application layer heartbeat probe frames, and by calculating the packet budget based on the number of handshake round trips, thus avoiding the systematic underestimation of protocols with high handshake overhead.

[0066] In some embodiments, the method further includes: the client calculating the probe quality score of the test protocol based on the round-trip time, packet loss rate, a first weighting coefficient corresponding to the round-trip time, and a second weighting coefficient corresponding to the packet loss rate, wherein both the first weighting coefficient and the second weighting coefficient are negative values; the probe quality score is used by the client to select a target egress address among multiple egress addresses corresponding to the test protocol.

[0067] The detection quality score is a score that quantifies and distinguishes the quality of a single detection. The first weighting coefficient is the weighting coefficient corresponding to the round-trip delay, and the second weighting coefficient is the weighting coefficient corresponding to the packet loss rate.

[0068] In this embodiment, the client can calculate the probe quality score of the test protocol based on round-trip time (RTT), packet loss rate, a first weighting coefficient, and a second weighting coefficient, both of which are negative. For example, the probe quality score can be calculated using the formula Score = -2 × RTT - 8 × Lost, where RTT is the round-trip time in seconds and Lost is the packet loss rate. The specific values ​​of the two weighting coefficients can be configured and adjusted, and are not limited to the values ​​described above. The probe quality score can be used by the client to select a target egress address among multiple egress addresses corresponding to the test protocol, for example, by combining area-priority rate testing groups to select the best egress address for different egress addresses of the same protocol.

[0069] This embodiment introduces a quantitative score in addition to the binary determination of success and failure, which can distinguish the detection quality in a more granular way and provide a basis for selecting the best among different exit addresses of the same protocol.

[0070] In some embodiments, if the response frame is successfully parsed according to a preset protocol format and the parsed fields include the client's network address echoed by the server, the following conditions are checked, and if all conditions are met, the probe result is determined to be successful: ① The transport layer connection and protocol handshake between the client and the server are successfully established; ② The number of response frames received within their respective timeout limits in each transmission and reception reaches the configured minimum response threshold. Wherein, if the remaining transmission and reception attempts are insufficient to reach the minimum response threshold, the client determines the probe result to be a probe failure. The minimum response threshold refers to the minimum number of response frames required to determine a successful probe, and can be configured by the server.

[0071] For example, the client can execute a fast failure logic: when the remaining number of send and receive attempts is insufficient to reach the minimum number of response frames received, the client can preemptively determine that the probe has failed and return without waiting for all send and receive attempts to complete.

[0072] This embodiment improves the accuracy of successful detection by jointly determining the connection establishment, the number of responses, and the source of the responses. The fast failure logic can also reduce invalid waiting and lower the connection establishment latency.

[0073] In some embodiments, the detection result includes the following four mutually exclusive states: detection success state, rollback success state, detection failure state, and cancellation state.

[0074] A successful probe status indicates that the probe was successful and the protocol carrying the business traffic for this connection is the test protocol. A successful fallback status indicates that the connection was ultimately successful and the protocol carrying the business traffic for this connection is a protocol other than the test protocol in the protocol priority fallback chain. A failed probe status indicates that all candidate protocols in the candidate protocol list failed to connect. A canceled status indicates that the connection process was canceled midway, such as by the user or upper-layer logic.

[0075] When the server calculates the detection success rate of each candidate protocol, it counts both the detection results in the rollback success state and the detection failure state as failure samples of the corresponding test protocol. That is, the rollback success state is not included in the numerator of the detection success rate, and the detection results in the cancellation state are counted separately, that is, neither the success sample nor the failure sample is included.

[0076] This embodiment prevents the success of the rollback protocol from polluting the statistical data of the test protocol by listing the successful rollback as an independent state and removing the successful samples. At the same time, it can avoid user-initiated cancellation behavior from interfering with the evaluation conclusion of the protocol's availability by separately counting the user's actions.

[0077] In some embodiments, the client reports the probe results to the server, including: reporting a probe event to the server after the probe is completed; the server generating a probe record based on the probe event; the probe record includes the receipt date, the protocol identifier of the test protocol, the status of the probe result, the probe duration, the final connection status, and the device identifier. The device identifier is used to parse the client's platform type and country code, which serve as statistical filtering dimensions. The dedicated field is assigned a value only when the connection is included in the group; in connection requests for connections not included in the group, the dedicated field is empty, and the value of the dedicated field remains unchanged during the reconnection process.

[0078] A probe event refers to a single probe message reported by the client after the probe is completed. A probe record refers to a structured record generated by the server based on probe events. A device identifier refers to the identification information used to identify the device where the client is located.

[0079] In this embodiment, the client can report a probe event to the server immediately after the probe ends (regardless of whether the probe is successful or not). Upon receiving the probe event, the server can supplement the reception date and device identifier to generate a six-tuple probe record including the reception date, the protocol identifier of the test protocol, the status of the probe result, the probe duration, the final connection status, and the device identifier. For example, the server can parse the device identifier to obtain the client's platform type (iOS / Android) and country code, using the platform type and country code as statistical filtering dimensions. The dedicated field can only be assigned a value if the connection is included in the group; in connection requests for connections not included in the group, the dedicated field is empty, and the value of the dedicated field remains unchanged during the reconnection process of this connection.

[0080] This embodiment enables the server to identify test traffic and its corresponding protocols without additional test batch identifiers by using dedicated field assignment rules and six-tuple probe records. It also supports filtering and analysis of statistical data by platform and country.

[0081] In some embodiments, the operation of the server to count the detection success rate and traffic metrics of each candidate protocol includes: grouping and summarizing the detection results in the statistical window according to two dimensions, region and protocol, to obtain the total number of detections and the number of successful detections for each candidate protocol in the statistical window, and determining the ratio of the number of successful detections for each candidate protocol to the total number of detections as the detection success rate of each candidate protocol; summarizing the test traffic in the statistical window according to two dimensions, region and protocol, to obtain the total traffic of each candidate protocol, and determining the ratio of the total traffic of each candidate protocol to the number of successful detections as the average traffic per connection for each candidate protocol, and the traffic metrics include the average traffic per connection.

[0082] The statistics window refers to the time range used to summarize sample data. Total probe count refers to all probes for a specific protocol within the statistics window. Successful probe count refers to the number of probes that were successful within the statistics window. Total traffic refers to the total number of bytes of test traffic for a specific protocol within the statistics window. Average traffic per connection is the ratio of total traffic to the number of successful probes.

[0083] For example, the server can count the number of successful connections, and determine the final success rate as the ratio of the number of successful connections to the total number of probes. It can also bin the probe time at both the second and millisecond levels, outputting latency distribution and a list of failed devices (e.g., up to 100 devices per platform) for manual troubleshooting. The server can also aggregate the test traffic within the statistical window according to region and protocol, obtaining the total traffic for each candidate protocol. The ratio of the total traffic to the number of successful probes is then determined as the average traffic per connection.

[0084] This embodiment, by simultaneously calculating the detection success rate and the average traffic per connection, can take into account both the initial connection success probability of the protocol and the actual usable transmission quality after the connection is successful, thus avoiding the one-sided evaluation caused by a single indicator.

[0085] In some embodiments, validity conditions include statistical window conditions, probe sample size conditions, and flow sample size conditions. The statistical window conditions, probe sample size conditions, and flow sample size conditions refer to the threshold requirements for the statistical window duration, the probe sample size within the window, and the total test flow within the window, respectively.

[0086] Different regions independently configure their own validity criteria parameters, including statistical window duration, minimum probe sample size, minimum traffic sample size, and platform type participating in the statistics. Regions that do not independently configure parameters inherit global default parameters, while the baseline region is exempt from validity criterion determination. Global default parameters refer to the parameter values ​​automatically inherited by regions that do not independently configure parameters. The baseline region refers to the region that serves as the global fallback data source, such as the United States.

[0087] If the sample data in any region does not meet the corresponding validity conditions for that region, the protocol priority order for that region will not be updated in this update cycle, and the protocol priority order of the previous release will be used.

[0088] For example, the global default parameters can be a 14-day statistical window, a minimum of 100 probe samples, a minimum of 1TB of test traffic, and statistics only for iOS and Android platforms. Regions with a large user base can configure a shorter statistical window, such as 7 days, to quickly respond to changes in blocking strategies. Regions with a small user base can configure a longer statistical window, such as 15 to 30 days, and can lower the traffic threshold to fully accumulate samples. Regions without independently configured parameters automatically inherit the global default parameters. Baseline regions are exempt from validity condition determination, and their data also serve as the global fallback ranking basis. If the sample data of any region does not meet the corresponding validity conditions for that region, the protocol priority order for that region will not be updated in this update cycle, but will use the protocol priority order from the previous release, and the reason for not meeting the conditions can be recorded for viewing on the management page.

[0089] This embodiment enables large-scale regions to respond quickly with short windows and small-scale regions to accumulate data fully with long windows by configuring validity parameters independently at the regional level, thus avoiding the problems of slow response and misjudgment due to insufficient samples caused by uniform thresholds.

[0090] In some embodiments, the server may also periodically perform update checks independently for each region. The update check includes: for each region, determining whether the region has reached the update cycle based on the statistical window duration configured for that region and the update time of the last protocol priority order of that region; the update checks and sorting updates for different regions are performed independently of each other; wherein, if any region fails to sort the update, the reason for the update failure is recorded, and the sorting update is re-executed for that region in the update check of the subsequent cycle.

[0091] The update cycle refers to the time interval between two consecutive sorting updates.

[0092] In this embodiment, the server can periodically and independently perform update checks on each region through background tasks, for example, looping approximately every 5 minutes. For each region, the server determines whether the region has reached its update cycle based on the configured statistical window duration and the update time of the last protocol priority order for that region. Update checks and sorting updates for different regions are executed independently and do not block each other. If a sorting update fails in any region, the server can record the reason for the failure and automatically re-execute the sorting update for that region in subsequent update checks. For example, the management page can also support manually triggering updates for individual regions.

[0093] This embodiment, through regional independent scheduling and automatic retry for failures, can match the update pace of each region with its own data accumulation speed, so that the update failure of one region will not affect the normal update of other regions.

[0094] In some embodiments, the candidate protocols are ranked according to at least one of the detection success rate and traffic metrics to obtain a protocol priority order, including: The server calculates the overall score for each candidate protocol by summing the product of its traffic metrics and traffic weight coefficient, and the product of its detection success rate and success rate weight coefficient. The candidate protocols are then ranked in descending order based on their overall scores to determine their priority. Alternatively, For candidate protocols configured with a conversion factor, the server determines the corrected traffic factor of the candidate protocol by multiplying the traffic factor of the candidate protocol by the conversion factor. For candidate protocols without a conversion factor, the server determines the corrected traffic factor of the candidate protocol by multiplying the traffic factor of the candidate protocol. The server then sorts the candidate protocols in descending order according to their corrected traffic factors to obtain the protocol priority order.

[0095] The overall score refers to the score obtained by comprehensively evaluating candidate protocols. The flow weight coefficient refers to the weight of flow metrics in the overall score, and the success rate weight coefficient refers to the weight of detection success rate in the overall score. The conversion factor is a coefficient less than 1 used to adjust flow metrics for protocols with specific statistical definitions. The corrected flow metric refers to the flow metric after adjustment using the conversion factor.

[0096] In this embodiment, the traffic weight coefficient and success rate weight coefficient can be configured. For example, the traffic weight coefficient is 0.6 and the success rate weight coefficient is 0.4, that is, traffic accounts for 6 points and success rate accounts for 4 points.

[0097] In another exemplary implementation, for variant protocols (such as TCP-2, TCP-3, HTTP-2, etc.) that cause inflated statistical traffic due to the bearer method, an 80% conversion factor can be configured. The statistical traffic is first multiplied by the conversion factor before being included in the sorting. The conversion factor can be configured by protocol or by region.

[0098] This embodiment uses a weighted scoring model to balance the actual user experience of the protocol with the probability of connectivity; by correcting the conversion factor, it can prevent protocols with special statistical caliber from obtaining unfair rankings due to inflated traffic.

[0099] In some embodiments, the protocol priority order adopts a two-dimensional backchain structure. The outer layer of the two-dimensional backchain structure is arranged according to priority, and the inner layer consists of protocol groups of the same priority. After sorting, the first preset number of candidate protocols each occupy a priority level, and the remaining candidate protocols are aggregated into subsequent priority groups.

[0100] Candidate protocols with fixed positions are not sorted but directly set in the priority group corresponding to their fixed positions in the two-dimensional fallback chain structure. For regions with manually specified protocol lists, the protocol priority order is directly generated using these lists. The protocol priority order for free users is generated by removing candidate protocols unsuitable for free users from the protocol priority order for paid users. After the protocol priority order is published to the configuration center, it serves as the protocol priority fallback chain in the protocol configuration data.

[0101] A two-dimensional backlink structure refers to a protocol ordering structure where the outer layer is arranged by priority and the inner layer consists of groups of protocols with the same priority. Fixed position refers to a fixed ranking position configured for a specific protocol. A manually specified protocol list refers to a fixed list of recommended protocols directly configured by a human.

[0102] In this embodiment, the protocol priority order output by the server can adopt a two-dimensional backlink structure: after sorting, the first preset number (e.g., the first two) of candidate protocols each occupy the two highest priorities, and the remaining candidate protocols are aggregated into subsequent priority groups. Candidate protocols configured with fixed positions do not participate in automatic sorting competition and are directly set in the priority group corresponding to their fixed positions. For example, a certain variant protocol is fixed as the second to last, and Wireguard is fixed as the last. For special regions with manually specified protocol lists, the server can directly use the manually specified protocol list to generate the protocol priority order, skipping automatic sorting. For example, the protocol priority order corresponding to the free user type can be generated separately after deleting candidate protocols that are not applicable to the free user type based on the protocol priority order corresponding to the paid user type. After the protocol priority order is published to the configuration center, it serves as the protocol priority backlink in the protocol configuration data.

[0103] This embodiment, through the coexistence of a two-dimensional backchain structure, fixed positions, and manually specified lists, allows automated data-driven processes and human experience intervention to complement each other, balancing the objectivity of sorting with the flexibility of operational strategies.

[0104] In some embodiments, the protocol configuration data further includes a recommended default protocol and its corresponding change version number; the server publishes the protocol priority order to the configuration center, including: the server determines the candidate protocol ranked first in the protocol priority order as the new recommended default protocol; if the new recommended default protocol is different from the recommended default protocol currently stored in the configuration center, a new change version number (e.g., a random version number) is generated, and the new recommended default protocol and the new change version number are written to the configuration center; if the new recommended default protocol is the same as the recommended default protocol currently stored in the configuration center, the change version number currently stored in the configuration center is retained.

[0105] Based on this, the method also includes: when the client initiates a connection later, it reads the change version number stored in the configuration center. If the read change version number has not been applied by the client, it switches the local default protocol to the recommended default protocol and records the change version number as applied, so that the same change version number will not trigger the switch again.

[0106] The recommended default protocol refers to the connection protocol recommended to users as the default. The version number is a version identifier used to identify changes to the recommended default protocol.

[0107] This embodiment uses a one-time switching mechanism controlled by version number keys, which allows the client to automatically apply the latest recommendation when the recommended default protocol changes, without repeatedly overwriting the protocol manually selected by the user.

[0108] In some embodiments, the method further includes: Before writing the protocol priority order into the configuration center, the server calculates the content digest of the protocol priority order to be written and compares the content digest with the content digest of the protocol priority order currently stored in the configuration center. If the two are the same, the writing is skipped. When a client that has not joined the group initiates a connection again after the server publishes the configuration, it reads the updated protocol configuration data from the configuration center and applies it without interrupting the established connection session.

[0109] A content digest is a digest value calculated from the content according to the protocol priority order, such as a hash digest.

[0110] In this embodiment, before writing the protocol priority order into the configuration center, the server can calculate the content digest of the protocol priority order to be written and compare the content digest with the content digest of the protocol priority order currently stored in the configuration center; if the two are the same, it indicates that the content has not changed, and the server skips this writing.

[0111] When a client not yet in the group initiates a connection again after the server publishes the configuration, such as during application startup, manual user connection, disconnection and reconnection, or configuration refresh, the updated protocol configuration data is read from the configuration center and applied without interrupting the established connection session. For example, considering the server's periodic update check rhythm, the actual application delay can typically range from minutes to hours.

[0112] This embodiment avoids invalid writes when the content remains unchanged by comparing the digest before writing, thus reducing the load on the configuration center; by pulling the settings during connection, users can apply the latest configuration without being aware of it and without interrupting existing sessions.

[0113] In some embodiments, the method further includes: if the test protocol is different from the user's original protocol and the detection result is successful, the client records the user's original protocol to local storage and restores the connection protocol to the user's original protocol stored locally when initiating a connection again.

[0114] Local storage refers to key-value storage on the client's local machine. Pre-connection callback refers to a callback mechanism triggered before each connection is initiated.

[0115] This embodiment records and automatically restores the user's original protocol after a successful test, ensuring that the temporary protocol switching during A / B testing does not pollute the user's long-term protocol selection and guaranteeing the consistency of the user-side configuration.

[0116] In some embodiments, target protocols that do not participate in random testing have been removed from the candidate protocol list. The target protocols only exist in the protocol priority fallback chain, meaning they can still be tried during normal fallback, but they are not included in the A / B random candidate pool. For example, for protocols with special connection structures that require multiple hops through third-party networks, the client and server can configure them as target protocols.

[0117] The target protocol refers to the protocol configured not to participate in random testing. In some examples, the target protocol can be a protocol that is relayed through a third-party network node during connection.

[0118] This embodiment avoids ranking distortion caused by the incomparability of statistical standards between target protocols with special statistical calibers and direct connection protocols by excluding them from the random candidate pool, thus ensuring the fairness of the ranking results.

[0119] It should be noted that, regarding the various steps included in the A / B testing-based network connection protocol optimization method provided in any of the above embodiments, unless explicitly stated herein, there is no strict order restriction on the execution of these steps; they can be executed in other orders. Furthermore, at least some of these steps may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is also not necessarily sequential, but can be performed alternately or in turn with other steps or at least a portion of the sub-steps or stages of other steps.

[0120] This application provides a method for optimizing network connection protocols based on A / B testing, applied to a client, according to a second aspect. The method includes: When initiating a connection, protocol configuration data is obtained from the configuration center. The protocol configuration data includes a list of candidate protocols and a protocol priority fallback chain. The inclusion determination is performed on this connection according to the preset sampling probability, and the inclusion determination result is obtained; If the grouping result indicates that the connection is included in the group, a candidate protocol is randomly selected from the candidate protocol list as the test protocol. Establish a connection with the server corresponding to the test protocol according to the protocol establishment process, send an application layer probe frame to the server, receive the response frame returned by the server, and determine the probe result of the test protocol based on the response frame; wherein, if the response frame is successfully parsed according to the preset protocol format and the parsed fields include the network address of the client echoed by the server, the probe result is determined to be successful. If the detection result is successful, the business traffic of this connection will be forwarded to the server through the test protocol, the protocol identifier of the test protocol will be written into the connection request, and the connection request carrying the protocol identifier and the detection result will be sent to the server.

[0121] For specific limitations on the network connection protocol selection method based on A / B testing in the second aspect, please refer to the limitations on the network connection protocol selection method based on A / B testing in the first aspect, which will not be repeated here.

[0122] This application provides a method for optimizing network connection protocols based on A / B testing, applied to a server, according to a third aspect. The method includes: It receives probe results reported by the client and connection requests sent by the client. The probe result refers to the probe result of the test protocol determined by the client after randomly selecting a candidate protocol from the candidate protocol list as the test protocol when the client joins the connection group, establishing a connection according to the protocol establishment process of the test protocol, and sending an application layer probe frame. The connection request carries the protocol identifier of the test protocol. If it is determined that the connection request carries a protocol identifier and the protocol carrying the service traffic is consistent with the protocol identifier, the service traffic is counted as the test traffic of the test protocol, and the detection success rate and traffic indicators of each candidate protocol are calculated based on the detection results reported by multiple connections and the test traffic of each candidate protocol. If the sample data meets the preset validity conditions, the candidate protocols are sorted according to at least one of the detection success rate and traffic indicators to obtain the protocol priority order. The protocol priority order is published to the configuration center to update the protocol configuration data stored in the configuration center, so that when the client initiates a connection in a subsequent connection, it can determine the connection protocol to use based on the updated protocol configuration data.

[0123] For specific limitations on the network connection protocol selection method based on A / B testing in the third aspect, please refer to the limitations on the network connection protocol selection method based on A / B testing in the first aspect, which will not be repeated here.

[0124] This application provides a system according to a fourth aspect, the system including a client and a server; the system is used to perform the preferred method for network connection protocol based on A / B testing provided in any embodiment of the first aspect.

[0125] This application also provides a computer device, in some embodiments of which the computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it can implement the preferred network connection protocol method based on A / B testing in the third or fourth aspect.

[0126] In some embodiments, the internal structure diagram of a computer device may be as follows: Figure 3 As shown. The computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores data, and the specific data stored can be further defined in the above method embodiments. The network interface communicates with external terminals via a network connection. When the computer program is executed by the processor, it implements the preferred method for network connection protocols based on A / B testing in the third or fourth aspect.

[0127] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0128] This application also provides a computer-readable storage medium, in some embodiments of which a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, it implements the preferred method for network connection protocol based on A / B testing in the third or fourth aspect.

[0129] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0130] Those skilled in the art will understand that implementing all or part of the processes in the above method embodiments can be accomplished by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), Synchlink, DRAM (SLDRAM), memory bus, direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0131] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0132] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A method for optimizing network connection protocols based on A / B testing, characterized in that, Applied to a system including a client and a server, the method includes: The client performs the following operations: When initiating a connection, protocol configuration data is obtained from the configuration center, which includes a list of candidate protocols and a protocol priority fallback chain; The inclusion determination is performed on this connection according to the preset sampling probability, and the inclusion determination result is obtained; If the grouping determination result is that the connection is accepted into the group, a candidate protocol is randomly selected from the candidate protocol list as the test protocol. A connection is established with the server corresponding to the test protocol according to the protocol establishment process of the test protocol, an application layer probe frame is sent to the server, and a response frame returned by the server is received. The probe result of the test protocol is determined according to the response frame. If the response frame is successfully parsed according to the preset protocol format and the parsed fields include the network address of the client echoed by the server, the probe result is determined to be successful. If the detection result is successful, the service traffic of this connection is forwarded to the server through the test protocol, the protocol identifier of the test protocol is written into the connection request, and the connection request carrying the protocol identifier and the detection result are sent to the server. The server performs the following operations: If it is determined that the connection request carries the protocol identifier and the protocol carrying the service traffic is consistent with the protocol identifier, the service traffic is counted as the test traffic of the test protocol. Based on the detection results reported by multiple connections and the test traffic of each candidate protocol obtained by statistics, the detection success rate and traffic indicators of each candidate protocol are calculated. If the sample data meets the preset validity conditions, the candidate protocols are sorted according to at least one of the detection success rate and traffic indicators of each candidate protocol to obtain the protocol priority order. The protocol priority order is published to the configuration center to update the protocol configuration data, so that when the client initiates a connection in a subsequent connection, it can determine the connection protocol to be used for the connection based on the updated protocol configuration data.

2. The method according to claim 1, characterized in that, The client performs an inclusion determination on this connection according to a preset sampling probability, and obtains the inclusion determination result, including: If the client determines that the current connection meets the preconditions for inclusion, it performs a Bernoulli judgment on the current connection according to the sampling probability corresponding to the target region to which the client belongs, and obtains the inclusion judgment result; the preconditions for inclusion include at least one of the following: the user who initiated the current connection is an unsubscribed user, the client is running on a specified operating system platform, and the line group identifier of the current connection is empty; Among them, the sampling probability corresponding to different regions is independently configured and does not exceed the preset probability upper limit. The sampling probability corresponding to regions whose historical sample data volume reaches the preset data volume threshold is less than the sampling probability corresponding to regions whose historical sample data volume does not reach the preset data volume threshold. The group entry determination is bound to each connection, and the same client executes the group entry determination independently in different connection cycles.

3. The method according to claim 1 or 2, characterized in that, The method further includes: If the test protocol is different from the original user protocol used by the client before this connection, the client constructs a temporary fallback chain based on the test protocol, the original user protocol, and the protocol priority fallback chain. The first priority protocol of the temporary fallback chain is the test protocol, the second priority protocol is the original user protocol, and the subsequent priority groups are the remaining protocol groups after deleting the test protocol and the original user protocol from the protocol priority fallback chain. If the test protocol is the same as the user's original protocol, the client will determine the protocol priority fallback chain as the temporary fallback chain.

4. The method according to claim 3, characterized in that, The method further includes: If the detection result is a failure, the client shall establish a connection using the original user protocol according to the priority order of the temporary fallback chain. If the connection fails using the original user protocol, the connection is established one group at a time according to the order of the remaining protocol groups in the temporary fallback chain until the connection is successful, and the service traffic of this connection is sent to the server through the protocol of the successful connection. If all protocols in the temporary fallback chain fail to connect, the connection failure is determined, and the connection failure result of this connection is reported to the server as a negative sample of the test protocol.

5. The method according to claim 1, characterized in that, The client establishes a connection with the server corresponding to the test protocol according to the protocol establishment process, sends an application layer probe frame to the server, receives a response frame returned by the server, and determines the probe result of the test protocol based on the response frame, including: The client dials up to the server port corresponding to the test protocol according to the transport layer type corresponding to the test protocol, and performs the protocol handshake of the test protocol with the server according to the configured domain name and TLS client handshake fingerprint; After the protocol handshake is completed, multiple application layer probe frames are sent to the server according to the configured number of probe packets, and the response frames returned by the server are received. The round-trip delay and packet loss rate of each transmission and reception are calculated, and the detection results are determined based on the response frames received within their respective timeout limits for each transmission and reception.

6. The method according to claim 1, characterized in that, If the response frame is successfully parsed according to the preset protocol format and the parsed fields include the network address of the client echoed by the server, check whether each of the following conditions is met, and if each condition is met, determine that the probe result is a successful probe: The transport layer connection and protocol handshake between the client and the server were successfully established. The number of response frames received within their respective timeout limits in each transmission and reception reaches the configured minimum response threshold; If the remaining number of send and receive attempts is insufficient to reach the minimum number of response frames received, the client determines that the probe result is a probe failure.

7. The method according to claim 1, characterized in that, The detection results include the following four mutually exclusive states: successful detection, successful rollback, failed detection, and cancelled detection. The successful detection status indicates that the test protocol was successfully detected and the protocol carrying the service traffic of this connection is the test protocol; The successful rollback status indicates that the connection was finally established and that the protocol carrying the service traffic of this connection is a protocol other than the test protocol in the protocol priority rollback chain. The detection failure status indicates that all candidate protocols in the candidate protocol list have failed to connect; The cancellation status indicates that the connection process for this connection was cancelled midway. When the server calculates the success rate of each candidate protocol's detection, it counts both the detection results in the successful rollback state and the failed detection state as failure samples of the corresponding test protocol, and counts the detection results in the canceled state separately.

8. The method according to claim 1, characterized in that, The server-side operation of calculating the detection success rate and traffic metrics for each candidate protocol includes: The server grouped and summarized the detection results within the statistical window according to two dimensions: region and protocol, to obtain the total number of detections and the number of successful detections for each candidate protocol within the statistical window. The ratio of the number of successful detections for each candidate protocol to the total number of detections was determined as the detection success rate of each candidate protocol. The test traffic within the statistical window is summarized according to two dimensions: region and protocol, to obtain the total traffic of each candidate protocol. The ratio of the total traffic of each candidate protocol to the number of successful probes is determined as the average traffic per connection of each candidate protocol. The traffic metric includes the average traffic per connection.

9. The method according to claim 1, characterized in that, The validity conditions include statistical window conditions, probe sample size conditions, and flow sample size conditions; Different regions can independently configure their own validity conditions corresponding parameters, including statistical window duration, minimum detection sample size, minimum traffic sample size, and platform type participating in the statistics; Regions that have not independently configured the above parameters inherit the global default parameters, and the base region is exempt from the determination of the validity conditions; If the sample data in any region does not meet the corresponding validity conditions for that region, the protocol priority order for that region will not be updated in this update cycle, and the protocol priority order of the previous release will be used.

10. The method according to claim 8, characterized in that, The step of sorting the candidate protocols according to at least one of the detection success rate and traffic metrics to obtain the protocol priority order includes: The server determines the comprehensive score of each candidate protocol by summing the product of its traffic metrics and traffic weight coefficient, and the product of its detection success rate and success rate weight coefficient. The server then sorts the candidate protocols in descending order according to their comprehensive scores to obtain the protocol priority order; or... For candidate protocols configured with a conversion factor, the server determines the corrected traffic factor of the candidate protocol by multiplying the traffic factor of the candidate protocol by the conversion factor. For candidate protocols without a conversion factor, the server determines the corrected traffic factor of the candidate protocol by the traffic factor. The server then sorts the candidate protocols in descending order according to their corrected traffic factors to obtain the protocol priority order.

11. The method according to claim 1, characterized in that, The protocol configuration data also includes recommended default protocols and their corresponding version numbers; the server publishes the protocol priority order to the configuration center, including: The server determines the candidate protocol ranked first in the protocol priority order as the new recommended default protocol; if the new recommended default protocol is different from the recommended default protocol currently stored in the configuration center, a new change version number is generated, and the new recommended default protocol and the new change version number are written to the configuration center; if the new recommended default protocol is the same as the recommended default protocol currently stored in the configuration center, the change version number currently stored in the configuration center is retained. The method further includes: When the client initiates a connection later, it reads the change version number stored in the configuration center. If the changed version number read has not been applied by the client, it switches the local default protocol to the recommended default protocol and records the changed version number as applied.

12. A method for optimizing network connection protocols based on A / B testing, characterized in that, Applied to a client, the method includes: When initiating a connection, protocol configuration data is obtained from the configuration center, which includes a list of candidate protocols and a protocol priority fallback chain; The inclusion determination is performed on this connection according to the preset sampling probability, and the inclusion determination result is obtained; If the grouping determination result is that the connection is accepted into the group, a candidate protocol is randomly selected from the candidate protocol list as the test protocol. A connection is established with the server corresponding to the test protocol according to the protocol establishment process of the test protocol, an application layer probe frame is sent to the server, and a response frame returned by the server is received. The probe result of the test protocol is determined according to the response frame. If the response frame is successfully parsed according to the preset protocol format and the parsed fields include the network address of the client echoed by the server, the probe result is determined to be successful. If the detection result is successful, the service traffic of this connection is forwarded to the server through the test protocol, the protocol identifier of the test protocol is written into the connection request, and the connection request carrying the protocol identifier and the detection result are sent to the server.

13. A method for optimizing network connection protocols based on A / B testing, characterized in that, Applied to the server side, the method includes: The system receives probe results reported by the client and connection requests sent by the client. The probe results refer to the probe results of the test protocol determined by the client after randomly selecting a candidate protocol from the candidate protocol list as the test protocol, establishing a connection according to the protocol establishment process of the test protocol, and sending an application layer probe frame. The connection request carries the protocol identifier of the test protocol. If it is determined that the connection request carries the protocol identifier and the protocol carrying the service traffic is consistent with the protocol identifier, the service traffic is counted as the test traffic of the test protocol, and the detection success rate and traffic index of each candidate protocol are calculated based on the detection results reported by multiple connections and the test traffic of each candidate protocol. If the sample data meets the preset validity conditions, the candidate protocols are sorted according to at least one of the detection success rate and traffic indicators of each candidate protocol to obtain the protocol priority order. The protocol priority order is published to the configuration center to update the protocol configuration data stored in the configuration center, so that when the client initiates a connection in a subsequent connection, it can determine the connection protocol to be used for the connection based on the updated protocol configuration data.

14. A system, characterized in that, The system includes a client and a server; the system is used to perform the method according to any one of claims 1 to 11.

15. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 12 to 13.

16. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 12 to 13.

Images