Method, device and medium for multi-agent parallel race-based tls handshake optimization

Abstract

This invention provides a method, apparatus, device, and medium for TLS handshake optimization in a multi-proxy parallel racing scenario. The method includes: intercepting a proxy request initiated by a browser and reading the header traffic of the request; parsing the header traffic to determine whether it is a TLS handshake request; if it is a TLS handshake request, writing the read traffic to a first proxy server and reading the return packet traffic within a preset first timeout window; if the return packet is successfully read within the first timeout window, locking the first proxy as the service proxy for this request; if reading fails or times out within the first timeout window, concurrently starting at least one second proxy; reading traffic from the party that returns the return packet first and determining the first returning proxy as the service proxy for this request, thereby achieving secondary optimization in the critical business stage after the proxy handshake is successful, significantly improving the success rate and response speed of proxy requests.

Description

Technical Field

[0001] This invention relates to the field of network communication technology, and in particular to a method, apparatus, device, and medium for selecting the best TLS handshake in a multi-agent parallel racing manner. Background Technology

[0002] Currently, with the widespread encryption of internet traffic, TLS (Transport Layer Security) has become the de facto standard for web communication. Statistics show that over 98% of web page requests are currently encrypted using TLS. When users access internet resources through a proxy client, the quality of the proxy line directly determines the smoothness and stability of the browsing experience.

[0003] However, due to the complexity and uncertainty of the global network environment, the lines provided by different proxy service providers vary significantly in terms of latency, packet loss rate, and bandwidth stability. Even under network conditions of the same operator and region, the access speed and success rate of different proxy lines can differ by several times or even tens of times. For ordinary users, manually selecting the fastest and highest quality line from a massive number of proxy lines in the current network environment is almost impractical.

[0004] To address the aforementioned issues, several proxy line optimization schemes have emerged in the existing technology. These schemes typically employ the following technical approach: the proxy client simultaneously initiates TCP connections to multiple proxy servers, using the TCP handshake completion time as the selection criterion; or they extend this further to the proxy protocol handshake layer, using the SOCKS / HTTP proxy protocol handshake response time as the selection standard. Once a proxy completes its TCP handshake or proxy protocol handshake, it is locked as the service proxy for this request, and the remaining proxy connections are immediately released.

[0005] However, existing solutions have significant technical flaws: a successful TCP handshake or proxy protocol handshake only signifies the establishment of a transport layer or proxy protocol layer connection between the proxy client and the proxy server; it does not guarantee the success of subsequent actual business requests initiated through the proxy. In practice, many proxy request failures occur precisely during the business data transmission phase after a successful proxy handshake, such as TLS handshake timeouts between the proxy server and the target server, certificate verification failures, remote connection resets, or internal errors within the proxy server. Because existing optimization schemes stop the optimization process after a successful proxy handshake, users must endure negative experiences such as connection failures, interrupted page loading, and retry delays when these business layer failures occur, and the optimization mechanism itself fails to respond effectively to such situations.

[0006] Therefore, existing proxy line optimization technologies are essentially still at the transport layer or proxy protocol layer, failing to penetrate to the core of business requests—the TLS handshake layer. This limits their success rate improvement in practical application scenarios and makes it impossible to meet the requirements for highly reliable and low-latency proxy access. Summary of the Invention

[0007] The technical problem to be solved by this invention is to provide a method, apparatus, device and medium for TLS handshake optimization in multi-proxy parallel racing. By parsing the TLS Client Hello message in real business traffic, and taking the response speed of the proxy server returning Server Hello as the core optimization index, a secondary optimization is achieved in the key business stage after the proxy handshake is successful, which significantly improves the success rate and response speed of proxy requests.

[0008] In a first aspect, the present invention provides a TLS handshake selection method for multi-agent parallel racing, comprising the following steps: Intercept proxy requests initiated by the browser and read the request header traffic; The header traffic is parsed using TLS Client Hello packets to determine whether it is a TLS handshake request; If it is a TLS handshake request, the first proxy performs the following operations in parallel: Write the read Client Hello traffic to the first proxy server, and read the Server Hello response traffic within the preset first timeout window; If the Server Hello response packet is successfully read within the first timeout window, then the first proxy is locked as the service proxy for this request. If a read fails or times out within the first timeout window, at least one second agent is started concurrently. Write the Client Hello traffic to the second proxy server and start parallel race reading; Read the traffic from the party that first returns a Server Hello response packet, and determine that the first proxy to return a response as the service proxy for this request.

[0009] Secondly, the present invention provides a TLS handshake optimization device for multi-agent parallel racing, comprising: The traffic sniffing module intercepts proxy requests initiated by the browser and reads the request header traffic; The proxy scheduling module parses the header traffic using TLS Client Hello packets to determine if it is a TLS handshake request. If it is a TLS handshake request, the first proxy performs the following operations in parallel: Write the read Client Hello traffic to the first proxy server, and read the Server Hello response traffic within the preset first timeout window; If the Server Hello response packet is successfully read within the first timeout window, then the first proxy is locked as the service proxy for this request. If a read fails or times out within the first timeout window, at least one second agent is started concurrently. Write the Client Hello traffic to the second proxy server and start parallel race reading; Read the traffic from the party that first returns a Server Hello response packet, and determine that the first proxy to return a response as the service proxy for this request.

[0010] Thirdly, the present invention provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in the first aspect.

[0011] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in the first aspect.

[0012] One or more technical solutions provided by this invention have at least the following technical effects or advantages: The beneficial effects of the above technical solution are as follows: 1. This invention uses a parallel racing mechanism to immediately start the second and third proxies to attempt a TLS handshake in parallel when the first proxy cannot complete the TLS handshake within 2 seconds due to network congestion, slow server response, or connection failure. This significantly reduces the probability of connection failure caused by a single point of failure and improves the overall availability of the proxy service.

[0013] 2. This invention uses the proxy that returns Server Hello first as the service proxy, ensuring that each TLS handshake uses the fastest proxy link in the current network environment, avoiding long handshake waiting times due to poor quality of a single proxy path, thereby reducing the browser's first byte time and improving the user's internet experience.

[0014] 3. The present invention enables the concurrent startup of alternative proxies after the first proxy times out. This process is performed without interrupting the connection attempts that the first proxy is still making. The selection result is transparent to the browser, and the browser does not need to be aware of the underlying proxy switching or resend requests, thus ensuring session continuity.

[0015] 4. This invention performs three-level successive verification of record type, protocol version, and message length, fully covering the core characteristic fields of TLSClient Hello messages. It can accurately distinguish between TLS handshake requests and non-TLS requests, non-standard TLS requests, and malformed messages, avoiding unnecessary proxy speed-up processing of non-TLS traffic and saving system resources.

[0016] 5. For non-TLS requests, non-standard TLS requests, or malformed TLS messages, this invention directly uses the first proxy for forwarding without initiating parallel speed-up, thus ensuring compatibility and avoiding the waste of bandwidth and connection resources caused by multiple proxy concurrency, thereby achieving a refined traffic scheduling strategy.

[0017] 6. This invention does not require manual configuration of the preferred proxy, nor does it rely on external speed testing services. It dynamically selects the best proxy based entirely on the TLS handshake response speed of real business traffic, and can adapt to changes in the network environment and select the fastest available proxy path in real time.

[0018] 7. This invention divides the functions of request interception, traffic sniffing, proxy scheduling, race control, and connection reuse into independent modules. Each module has clear responsibilities and well-defined interfaces, supports adding more proxy instances to participate in the race, and has good scalability and maintainability.

[0019] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0020] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0021] Figure 1 This is a flowchart of the method in Embodiment 1 of the present invention; Figure 2 This is a schematic diagram of the device in Embodiment 2 of the present invention. Detailed Implementation

[0022] The overall concept of the technical solution in this application is as follows: Step 1: Prepare 3 proxies, configure and start our proxy client. Step 2: Configure the proxy client to listen for the browser. Step 3: The browser initiates a network request. Step 4: The proxy client receives the proxy request. Step 5: The proxy client reads the request header traffic. Step 6: Parse the TLS client hello packet. Step 7: If the parsing is successful, use proxy 1 to connect to the proxy server. Step 8: Write the read traffic to the server first. Step 9: Read the TLS server hello response packet traffic from the proxy 1 server. If successful within 2 seconds, the process ends. Step 10: If the read fails or is not read within 2 seconds (default), then use both Proxy 2 and Proxy 3 to connect to the server simultaneously, write the read traffic to the servers of Proxy 2 and Proxy 3, and read the TLS Server Hello response traffic from Proxy 2 and Proxy 3. Step 11: The proxy that receives the traffic first will be used for this proxy request (meaning it is the fastest proxy at the moment).

[0023] The core code is as follows: package proxy const ( recordHeaderLen = 5 recordTypeHandshake = 22 versionTLS10 = 0x0301 versionTLS11 = 0x0302 versionTLS12 = 0x0303 versionTLS13 = 0x0304 ) type TLSRetrySelector struct { myOutboundAdapter ctx context.Context tags []string outbounds []adapter.Outbound retryInterval time.Duration requestCount uint64 retrySuccessCount uint64 retryFailCount uint64 } type connInfo struct { conn net.Conn data []byte tag string } func (s *TLSRetrySelector) dialContext(ctx context.Context, srcConnnet.Conn, network string, destination M.Socksaddr) (net.Conn, error) { s.logger.InfoContext(ctx, "dialing ", network, " ", destination) clientData, isTls, err := s.tlsSniff(srcConn) if err != nil { s.logger.ErrorContext(ctx, "tls sniff error: ", err) } doneCh := make(chan struct{}) outFailCh := make(chan struct{}) connCh := make(chan connInfo, len(s.outbounds)) go func() { for i, outbound := range s.outbounds { go func(outbound adapter.Outbound, i int) { conn, err := outbound.DialContext(ctx, network, destination) if err != nil { s.logger.ErrorContext(ctx, "dial error: ", err) if i == 0 { close(outFailCh) } return } var serverData []byte if isTls { if len(clientData) > 0 { if _, err = conn.Write(copyData(clientData)); err != nil { s.logger.ErrorContext(ctx, "write error: ", err) if i == 0 { close(outFailCh) } return } } var err error s.logger.InfoContext(ctx, "outbound ", outbound.Tag(), " is tlsrequest") serverData, err = s.readServerHello(conn) if err != nil { s.logger.ErrorContext(ctx, "read server hello error: ", err) if i == 0 { close(outFailCh) } return } } else { s.logger.InfoContext(ctx, "outbound ", outbound.Tag(), " is nottls request") } s.logger.InfoContext(ctx, "outbound ", outbound.Tag(), " dialsuccess") select { case <-doneCh: s.logger.InfoContext(ctx, "outbound ", outbound.Tag(), " isclosed") conn.Close() default: connCh <- connInfo{conn: conn, data: serverData, tag:outbound.Tag()} } }(outbound, i) if i == 0 { timer := time.NewTimer(s.retryInterval) defer timer.Stop() select { case <-outFailCh: s.logger.InfoContext(ctx, "outbound ", outbound.Tag(), " is dialfailed") case <-timer.C: s.logger.InfoContext(ctx, "outbound ", outbound.Tag(), " is dialtimeout") case <-doneCh: s.logger.InfoContext(ctx, "tls retry selector is done") return } } select { case <-doneCh: s.logger.InfoContext(ctx, "dial already success: ", outbound.Tag()) return default: } } }() select { case connInfo := <-connCh: close(doneCh) s.logger.InfoContext(ctx, "using outbound: ", connInfo.tag) if !isTls && len(clientData) > 0 { if _, err = connInfo.conn.Write(clientData); err != nil { s.logger.ErrorContext(ctx, "write error: ", err) return nil, err } } if len(connInfo.data) > 0 { _, err = srcConn.Write(connInfo.data) if err != nil { s.logger.ErrorContext(ctx, "write error: ", err) return nil, err } } return connInfo.conn, nil case <-ctx.Done(): close(doneCh) return nil, ctx.Err() case <-time.After(30 * time.Second): close(doneCh) return nil, errors.New("tls retry selector: timeout") } } func (s *TLSRetrySelector) readServerHello(conn net.Conn) ([]byte,error) { buffer := buf.New() defer func() { buffer.DecRef() buffer.Release() }() err := conn.SetReadDeadline(time.Now().Add(constant.TcpReadDeadline)) if err != nil { return nil, err } defer func() { _ = conn.SetReadDeadline(time.Time{}) }() if _, err = buffer.ReadOnceFrom(conn); err != nil { return nil, err } return copyDataFromBuffer(buffer), nil } func (s *TLSRetrySelector) tlsSniff(conn net.Conn) ([]byte, bool,error) { buffer := buf.New() defer func() { buffer.DecRef() buffer.Release() }() err := conn.SetReadDeadline(time.Now().Add(constant.TcpReadDeadline)) if err != nil { return nil, false, err } defer func() { _ = conn.SetReadDeadline(time.Time{}) }() _, err = buffer.ReadOnceFrom(conn) if err != nil { return nil, false, err } err = s.parserTLSHandshakeRecordHeader(buffer.Bytes()) if err != nil { return copyDataFromBuffer(buffer), false, err } return copyDataFromBuffer(buffer), true, nil } func (s *TLSRetrySelector) parserTLSHandshakeRecordHeader(data []byte) (err error) { start := 0 dataLen := len(data) if dataLen < recordHeaderLen { return errors.New("tls: internal error: empty ClientHello") } if data[start] != recordTypeHandshake { return errors.New("tls: internal error: not a ClientHello") } if !verifyTlsVerFormat(data[1:3]) { return errors.New("tls: internal error: ClientHello version error") } handshakeMessageLen := int(data[start+3])<<8 | int(data[start+4]) if dataLen < start+recordHeaderLen+handshakeMessageLen { return errors.New("tls: internal error: ClientHello length error") } return nil }

[0024] Example 1 like Figure 1 As shown, this embodiment provides 1. a TLS handshake optimization method for multi-agent parallel racing, characterized by the following steps: Intercept proxy requests initiated by the browser and read the request header traffic; The header traffic is parsed using TLS Client Hello packets to determine whether it is a TLS handshake request; If it is a TLS handshake request, the first proxy performs the following operations in parallel: Write the read Client Hello traffic to the first proxy server, and read the Server Hello response traffic within the preset first timeout window; If the Server Hello response packet is successfully read within the first timeout window, then the first proxy is locked as the service proxy for this request. If a read fails or times out within the first timeout window, at least one second agent is started concurrently. Write the Client Hello traffic to the second proxy server and start parallel race reading; Read the traffic from the party that first returns a Server Hello response packet, and determine that the first proxy to return a response as the service proxy for this request.

[0025] In this embodiment, preferably, the preset first timeout window is 2 seconds.

[0026] In this embodiment, preferably, it also includes: If the header traffic is not a TLS handshake request after parsing, the header traffic is directly written to the first proxy, and the first proxy is used as the service proxy.

[0027] In this embodiment, preferably, the TLS Client Hello packet parsing of the header traffic includes: Read the message header and determine if the record type field is 0x16, i.e., Handshake type; If the record type is not Handshake, it is determined to be a non-TLS handshake request, and the TLS-specific processing flow is terminated. If the record type is Handshake, continue parsing the protocol version field; Determine if the protocol version field is 0x0301, 0x0302, 0x0303, or 0x0304, which correspond to TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3, respectively. If the protocol version does not meet any of the above values, it is determined to be a non-standard TLS handshake request, and the TLS-specific processing flow is terminated. If the protocol version conforms to the standard, continue parsing the message length field; Verify the integrity of the Client Hello message based on the message length field, and determine whether the length of the read data is not less than the sum of the header length and the message length; If the integrity verification fails, the Client Hello is determined to be incomplete or malformed, and the TLS-specific processing flow is terminated. If the integrity verification passes, it is considered a valid TLS handshake request.

[0028] In this embodiment, preferably, the concurrent startup of the second agent means establishing a connection to the second agent simultaneously without interrupting the connection attempts that the first agent is still making.

[0029] In this embodiment, preferably, it also includes: After determining the service proxy, write the ServerHello return packet traffic read from the service proxy to the browser-side connection; The browser-side connection and the service proxy connection are connected to forward data to complete subsequent proxy communication.

[0030] Based on the same inventive concept, this application also provides an apparatus corresponding to the method in Embodiment 1, as detailed in Embodiment 2.

[0031] Example 2 like Figure 2 As shown, this embodiment provides a TLS handshake optimization device for multi-agent parallel racing, including: The traffic sniffing module intercepts proxy requests initiated by the browser and reads the request header traffic; The proxy scheduling module parses the header traffic using TLS Client Hello packets to determine if it is a TLS handshake request. If it is a TLS handshake request, the first proxy performs the following operations in parallel: Write the read Client Hello traffic to the first proxy server, and read the Server Hello response traffic within the preset first timeout window; If the Server Hello response packet is successfully read within the first timeout window, then the first proxy is locked as the service proxy for this request. If a read fails or times out within the first timeout window, at least one second agent is started concurrently. Write the Client Hello traffic to the second proxy server and start parallel race reading; Read the traffic from the party that first returns a Server Hello response packet, and determine that the first proxy to return a response as the service proxy for this request.

[0032] In this embodiment, preferably, the preset first timeout window is 2 seconds.

[0033] In this embodiment, preferably, it also includes: If the header traffic is not a TLS handshake request after parsing, the header traffic is directly written to the first proxy, and the first proxy is used as the service proxy.

[0034] In this embodiment, preferably, the TLS Client Hello packet parsing of the header traffic includes: Read the message header and determine if the record type field is 0x16, i.e., Handshake type; If the record type is not Handshake, it is determined to be a non-TLS handshake request, and the TLS-specific processing flow is terminated. If the record type is Handshake, continue parsing the protocol version field; Determine if the protocol version field is 0x0301, 0x0302, 0x0303, or 0x0304, which correspond to TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3, respectively. If the protocol version does not meet any of the above values, it is determined to be a non-standard TLS handshake request, and the TLS-specific processing flow is terminated. If the protocol version conforms to the standard, continue parsing the message length field; Verify the integrity of the Client Hello message based on the message length field, and determine whether the length of the read data is not less than the sum of the header length and the message length; If the integrity verification fails, the Client Hello is determined to be incomplete or malformed, and the TLS-specific processing flow is terminated. If the integrity verification passes, it is considered a valid TLS handshake request.

[0035] In this embodiment, preferably, the concurrent startup of the second agent means establishing a connection to the second agent simultaneously without interrupting the connection attempts that the first agent is still making.

[0036] In this embodiment, preferably, it also includes: After determining the service proxy, write the ServerHello return packet traffic read from the service proxy to the browser-side connection; The browser-side connection and the service proxy connection are connected to forward data to complete subsequent proxy communication.

[0037] Since the apparatus described in Embodiment 2 of the present invention is an apparatus used to implement the method of Embodiment 1 of the present invention, those skilled in the art can understand the specific structure and variations of the apparatus based on the method described in Embodiment 1 of the present invention, and therefore will not be described again here. All apparatuses used in the method of Embodiment 1 of the present invention fall within the scope of protection of the present invention.

[0038] Based on the same inventive concept, this application provides an electronic device embodiment corresponding to Embodiment 1, as detailed in Embodiment 3.

[0039] Example 3 This embodiment provides an electronic device, including 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 any of the implementation methods in Embodiment 1.

[0040] Since the electronic device described in this embodiment is the device used to implement the method in Embodiment 1 of this application, those skilled in the art can understand the specific implementation method and various variations of the electronic device in this embodiment based on the method described in Embodiment 1 of this application. Therefore, how the electronic device implements the method in the embodiment of this application will not be described in detail here. Any device used by those skilled in the art to implement the method in the embodiment of this application falls within the scope of protection of this application.

[0041] Based on the same inventive concept, this application provides a storage medium corresponding to Embodiment 1, as detailed in Embodiment 4.

[0042] Example 4 This embodiment provides a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it can implement any of the implementation methods in Embodiment 1.

[0043] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0044] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0045] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0046] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0047] While specific embodiments of the present invention have been described above, those skilled in the art should understand that the specific embodiments described are merely illustrative and not intended to limit the scope of the present invention. Equivalent modifications and variations made by those skilled in the art in accordance with the spirit of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A TLS handshake selection method with multiple agents competing for speed, characterized in that, Includes the following steps: Intercept proxy requests initiated by the browser and read the request header traffic; The header traffic is parsed using TLS Client Hello packets to determine whether it is a TLS handshake request; If it is a TLS handshake request, the following operations are performed in parallel using the first proxy: Write the read Client Hello traffic to the first proxy server, and read the Server Hello response traffic within the preset first timeout window; If the Server Hello response packet is successfully read within the first timeout window, then the first proxy is locked as the service proxy for this request. If a read fails or times out within the first timeout window, at least one second agent is started concurrently. Write the Client Hello traffic to the second proxy server and start parallel race reading; Read the traffic from the party that first returns a Server Hello response packet, and determine that the first proxy to return a response as the service proxy for this request.

2. The method according to claim 1, characterized in that, The preset first timeout window is 2 seconds.

3. The method according to claim 1 or 2, characterized in that, Also includes: If the header traffic is not a TLS handshake request after parsing, the header traffic is directly written to the first proxy, and the first proxy is used as the service proxy.

4. The method according to claim 1, characterized in that, The TLS Client Hello packet parsing of the header traffic includes: Read the message header and determine if the record type field is 0x16, i.e., Handshake type; If the record type is not Handshake, it is determined to be a non-TLS handshake request, and the TLS-specific processing flow is terminated. If the record type is Handshake, continue parsing the protocol version field; Determine if the protocol version field is 0x0301, 0x0302, 0x0303, or 0x0304, which correspond to TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3, respectively. If the protocol version does not meet any of the above values, it is determined to be a non-standard TLS handshake request, and the TLS-specific processing flow is terminated. If the protocol version conforms to the standard, continue parsing the message length field; Verify the integrity of the Client Hello message based on the message length field, and determine whether the length of the read data is not less than the sum of the header length and the message length; If the integrity verification fails, the Client Hello is determined to be incomplete or malformed, and the TLS-specific processing flow is terminated. If the integrity verification passes, it is considered a valid TLS handshake request.

5. The method according to claim 1, characterized in that, The concurrent startup of the second agent means establishing a connection to the second agent simultaneously without interrupting the connection attempts that the first agent is still making.

6. The method according to claim 1, characterized in that, Also includes: After determining the service proxy, write the Server Hello response traffic read from the service proxy to the browser-side connection; The browser-side connection and the service proxy connection are used to forward data to complete subsequent proxy communication.

7. A TLS handshake selection device for multi-agent parallel racing, characterized in that, include: The traffic sniffing module intercepts proxy requests initiated by the browser and reads the request header traffic; The proxy scheduling module parses the header traffic using TLS Client Hello packets to determine if it is a TLS handshake request. If it is a TLS handshake request, the first proxy performs the following operations in parallel: Write the read Client Hello traffic to the first proxy server, and read the Server Hello response traffic within the preset first timeout window; If the Server Hello response packet is successfully read within the first timeout window, then the first proxy is locked as the service proxy for this request. If a read fails or times out within the first timeout window, at least one second agent is started concurrently. Write the Client Hello traffic to the second proxy server and start parallel race reading; Read the traffic from the party that first returns a Server Hello response packet, and determine that the first proxy to return a response as the service proxy for this request.

8. The TLS handshake optimization device for multi-agent parallel racing according to claim 7, characterized in that, The preset first timeout window is 2 seconds.

9. An electronic 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 program, it implements the method as described in any one of claims 1 to 6.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 6.

Images