Proxy server detection method and device based on TCP timing characteristics, equipment and medium

Abstract

This invention provides a proxy server detection method, apparatus, device, and medium based on TCP timing characteristics. The method includes: capturing and filtering TCP traffic on a specified port at the server end; establishing a state record for each TCP connection stream, with key records including the connection establishment completion time and the arrival time of the first application layer data packet; calculating the time difference between the two as the first packet delay, and calculating the smooth round-trip time (SRTT) and RTTVAR jitter of the connection based on the acknowledgment delay of the data packet, and finally making a comprehensive judgment: only when the SRTT and the ratio of RTTVAR to SRTT do not exceed their respective thresholds are abnormalities in the first packet delay judged; if the first packet delay exceeds the preset normal threshold range at this time, it is determined that the source of the traffic uses a proxy server; this achieves high-precision, low-false-positive, real-time detection of proxy server traffic, effectively making up for the shortcomings of traditional detection methods.

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 detecting proxy servers based on TCP timing characteristics. Background Technology

[0002] In the field of web application services, ensuring a good access experience and service quality for legitimate users is a core requirement. However, various web crawlers, automated bots, and their generated abnormal traffic often consume significant server resources through camouflage, leading to increased latency and decreased service quality for legitimate users. To circumvent traditional protection strategies implemented by service providers based on IP addresses and request frequencies, this abnormal traffic widely employs proxy servers as access intermediaries to hide its true client IP address. This significantly reduces the effectiveness of traditional blocking measures based on source IP blacklists, rendering them ineffective.

[0003] Currently, the detection technologies for proxy servers have the following limitations: 1. Detection method based on IP reputation database or known proxy IP list: This method relies on a continuously maintained and updated proxy IP database, which has obvious lag and cannot effectively identify newly enabled or undisclosed proxy servers, resulting in a high false negative rate.

[0004] 2. Detection methods based on HTTP header fields (such as X-Forwarded-For, Via, etc.): This method is only effective against some HTTP proxies that conform to standards and honestly add the proxy identifier header field. Many proxy services (especially privacy-enhancing or malicious proxies) deliberately remove or forge this header information, making this method easy to bypass and unreliable.

[0005] 3. Detection methods based on behavioral characteristics (such as access frequency and request patterns): These methods detect anomalies by analyzing the timing and path of requests. However, intelligent web crawlers or attackers can easily simulate the behavior patterns of normal human users, making it difficult to distinguish between them, resulting in a high false positive rate and significant resource consumption.

[0006] Therefore, there is an urgent need in this field for a proxy server detection method that does not rely on external lists, is difficult to be actively spoofed, and is based on the inherent characteristics of underlying network communication, so as to accurately and efficiently identify access traffic relayed through proxy servers, thereby achieving effective control over abnormal traffic. Summary of the Invention

[0007] The technical problem to be solved by this invention is to provide a proxy server detection method, apparatus, device, and medium based on TCP timing characteristics. By cleverly mining and utilizing the low-level timing characteristics in TCP communication that are difficult to forge, and combining them with adaptive network quality assessment, this invention achieves high-precision, low-false-positive, and real-time detection of proxy server traffic without increasing additional dependencies or significant performance overhead. This effectively makes up for the shortcomings of traditional detection methods and provides a powerful technical tool for network service providers to maintain fair resource allocation, ensure a genuine user experience, and resist automated abuse.

[0008] In a first aspect, the present invention provides a proxy server detection method based on TCP timing characteristics, comprising the following steps: S1. Capture TCP packets on the server-side network interface and set a filter based on the preset monitoring port to capture network traffic of the target service; S2. Parse the captured TCP packets, extract the source address, source port, destination address, and destination port to form the identifier of the corresponding TCP connection stream, and create and maintain a state record for each connection stream represented by the identifier; the state record records at least the time when the TCP connection of the connection stream is established, and the arrival time of the first application layer data packet after the connection is established. S3. Based on the status record, calculate the time difference between the arrival time of the first application layer data packet and the completion time of the TCP connection establishment, and use it as the first packet delay of the connection stream; S4. Based on the sending time of the data packets sent in the same connection stream and the arrival time of the corresponding acknowledgment packets received, measure multiple round-trip time (RTT) samples, and calculate the smoothed round-trip time (SRTT) and round-trip time jitter (RTTVAR) of the connection stream according to the RTT samples. S5. Compare the first packet delay with a preset normal delay threshold range; simultaneously, determine whether the SRTT exceeds a preset first delay threshold, and determine whether the ratio of RTTVAR to SRTT exceeds a preset jitter ratio threshold; if the SRTT does not exceed the first delay threshold and the ratio does not exceed the jitter ratio threshold, then the network condition is determined to be stable; when the network condition is determined to be stable and the first packet delay exceeds the normal delay threshold range, then the source end of the connection stream is determined to use a proxy server.

[0009] Secondly, the present invention provides a proxy server detection device based on TCP timing characteristics, comprising: The packet capture and filtering module captures TCP packets at the server-side network interface and sets filters based on preset monitoring ports to capture network traffic of the target service. The flow state management module parses the captured TCP packets, extracts the source address, source port, destination address, and destination port to form the identifier of the corresponding TCP connection flow, and creates and maintains a state record for each connection flow represented by the identifier; the state record records at least the time when the TCP connection of the connection flow is established, and the arrival time of the first application layer data packet after the connection is established. The indicator calculation module calculates the time difference between the arrival time of the first application layer data packet and the completion time of the TCP connection establishment based on the status record, and uses it as the first packet delay of the connection stream. The calculation module measures multiple round-trip time (RTT) samples based on the sending time of the data packets sent in the same connection stream and the arrival time of the corresponding acknowledgment packets received, and calculates the smoothed round-trip time (SRTT) and round-trip time jitter (RTTVAR) of the connection stream based on the RTT samples. The proxy determination module compares the first packet delay with a preset normal delay threshold range; simultaneously, it determines whether the SRTT exceeds a preset first delay threshold and whether the ratio of RTTVAR to SRTT exceeds a preset jitter ratio threshold; if the SRTT does not exceed the first delay threshold and the ratio does not exceed the jitter ratio threshold, the network condition is determined to be stable; when the network condition is determined to be stable and the first packet delay exceeds the normal delay threshold range, the source end of the connection stream is determined to use a proxy server.

[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: 1. This invention does not rely on application-layer features (such as HTTP headers) or external intelligence (such as IP blacklists), but is based on the inherent, physically determined timing characteristics of the TCP / IP protocol stack (the time difference between the completion of the TCP handshake and the arrival of the first packet). This characteristic is determined by physical factors such as network path and intermediate node processing delays, and is difficult for the client to tamper with or hide at the application layer through software configuration or protocol spoofing.

[0013] 2. By analyzing the relative relationship between the first packet delay and the normal range, this invention can effectively distinguish between normal direct connections, high-latency ordinary proxies (such as HTTP / SOCKS proxies, where the first packet delay is significantly increased), and low-latency encrypted proxies (such as Shadowsocks / V2Ray, where the first packet delay is extremely low), covering mainstream proxy concealment methods.

[0014] 3. This invention distinguishes between "latency anomalies caused by proxies" and "latency fluctuations caused by poor network quality." By calculating and judging metrics such as Smooth Round-Trip Time (SRTT) and Round-Trip Time Jitter (RTTVAR) in real time, abnormal first-packet latency is only attributed to proxy usage when the network quality itself is stable. This effectively prevents normal users in high-latency, high-jitter network environments (such as cross-border links and mobile networks) from being mistakenly identified as proxy users, significantly reducing the false alarm rate.

[0015] 4. Although this invention uses a threshold for judgment, the core criterion (SRTT, RTTVAR) is a dynamic value calculated in real time for each connection. It can adapt to changes in network conditions for different users and at different times, and is more scientific and robust than a static, globally uniform latency threshold.

[0016] 5. The entire detection process of this invention is completed locally on the server side, without relying on any third-party IP databases, reputation services or cloud intelligence, thus avoiding maintenance costs, subscription fees and detection failures caused by the unavailability or update delays of external services.

[0017] 6. This invention analyzes the header information and basic timing of TCP packets without the need for deep analysis of application layer content (such as decrypting HTTPS traffic), resulting in low processing overhead and high computational efficiency. It can achieve real-time or near real-time detection of massive network connections and is suitable for deployment in high-concurrency service scenarios.

[0018] 7. This invention typically only requires the deployment of detection programs or modules on servers or network boundary devices, without requiring changes to the existing network architecture or client, and is easy to integrate into existing security protection systems.

[0019] 8. Because the detection mechanism of this invention does not rely on known proxy IPs or behavioral pattern libraries, it has the ability to proactively discover unknown proxy services. Any traffic attempting to access the internet through a proxy can be identified as long as its TCP timing characteristics match the proxy model, providing a new technical means to defend against new or customized web crawlers and attack tools.

[0020] 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

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

[0022] 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

[0023] The overall concept of the technical solution in this application is as follows: This application provides a proxy server detection method based on TCP handshake and data transmission delay analysis. By analyzing the arrival delay characteristics of the first application layer data packet after the TCP connection is established, the method identifies access requests using a proxy server.

[0024] The core principle of this method is: (1) Normal direct connection scenario: After the TCP three-way handshake is completed, the client immediately constructs and sends application layer data (such as the ClientHello message of HTTPS). The time interval from the completion of the TCP connection establishment to the arrival of the first data packet at the server is mainly the processing time for the client to construct the data packet, which is usually stable at around 30ms.

[0025] (2) Traditional proxy scenario: When the client uses a traditional proxy such as HTTP / SOCKS, the TCP three-way handshake is initiated by the proxy server. The client's application layer data needs to reach the proxy server first, and then be forwarded to the target server by the proxy server. Therefore, the latency of the first packet will increase significantly, usually several times or even more than the normal value.

[0026] (3) Encrypted proxy scenario: When using encrypted proxies such as Shadowsocks, the first business data packet and the proxy handshake information are transmitted in the same TCP / UDP packet. After receiving it, the server first decrypts and parses the target address, and then forwards the business data. Due to this "invisible handshake" mechanism, the latency of the first packet will be abnormally small, far lower than the normal 30ms.

[0027] The core code is as follows: 1. Parameter Configuration and Analysis Rust struct Args { iface: Option<string>, / / Network card selection port: u16, / / Monitoring port IP: Vec <string> / / List of monitored IPs max_srtt: f64, / / Maximum SRTT threshold (default 300ms) max_rttvar_ratio: f64, / / Maximum jitter ratio (default 0.3) max_rto: f64, / / Maximum RTO threshold (default 800ms) min_fb_ms: u64, / / Minimum delay for the first packet (default 10ms) max_fb_ms: u64, / / Maximum delay for the first packet (default 100ms) report_interval: u64, / / Report interval (default 10 seconds) } ``` 2. Packet capture and filtering Use the pcap library to capture packets from a specified network interface card, and set a filter to capture only TCP packets from the target port and the source IP.

[0028] Rust / / List of IPs to monitor let monitor_ips: Vec <ipaddr>= args .ip .iter() .flat_map(|s| s.trim().parse:: <ipaddr>().ok()) .collect(); / / Find the specified network card / default network card let device = match &args.iface { Some(iface) => Device::list() .expect("list device failed") .into_iter() .find(|v| &v.name == iface), None => Device::lookup().expect("device lookup failed"), } .expect("device not found"); / / Shared maps let flows: Arc <Mutex<HashMap<FlowKey, FlowState> >> = Arc::new(Mutex::new(HashMap::new())); println!("Capture device: `{}`", device.name,); / / Enable the capture device let mut cap = Capture::from_device(device)? .promisc(true) .immediate_mode(true) .open()?; / / Construct filter statements let filter = if monitor_ips.is_empty() { format!("tcp port {}", args.port) } else { let ip_filter = monitor_ips .iter() .map(|ip| format!("host {}", ip)) .collect:: <Vec<_> >() .join(" or "); format!("tcp port {} and ({})", args.port, ip_filter) }; println!("Filter: '{}'", filter); cap.filter(&filter, true)?; ``` 3. Parse and analyze the message. The parser determines whether the current packet is a TCP IPv4 packet, extracts srcIp:srcPort -> dstIp:dstPort as the key, and distinguishes different packet types (such as SYN, SYN-ACK, ACK, and packets carrying data) based on the TCP packet's flags and port number.

[0029] Record the time points when the TCP three-way handshake is completed and the time points when each packet is sent.

[0030] Calculate the delay time from the completion of the TCP handshake to the sending of the first data packet based on the first data packet after the handshake is completed.

[0031] Calculate the RTT sample value of the corresponding sent message based on the received ACK message.

[0032] Rust / / Packet capture processing loop { let packet = match cap.next_packet() { Ok(p) => p, Err(e) => { warn!("pcap next_packet error: {}", e); continue? } }; / / Analyze data packets - message capture time let header = packet.header; let ts = ts_to_systemtime(header.ts.tv_sec, header.ts.tv_usec); / / Parse data packet - IP header if let Ok(parsed) = PacketHeaders::from_ethernet_slice(packet.data) && let Some(transport) = parsed.transport && let Some(etherparse::NetHeaders::Ipv4(v4, _)) = parsed.net { / / Parse TCP IPv4 header packet if let etherparse::TransportHeader::Tcp(tcp) = transport { let src_ip = IpAddr::V4(v4.source.into()); let dst_ip = IpAddr::V4(v4.destination.into()); let src_port = tcp.source_port; let dst_port = tcp.destination_port; let seq = tcp.sequence_number; let ack = tcp.acknowledgment_number; let is_syn = tcp.syn; let is_ack = tcp.ack; let payload_len = v4.payload_len().unwrap() -tcp.header_len_u16(); / / Construct flow keys for both directions let forward = FlowKey { src: src_ip, src_port, dst: dst_ip, dst_port, }; let reverse = FlowKey { src: dst_ip, src_port: dst_port, dst: src_ip, dst_port: src_port, }; / / Second handshake SYN-ACK - Sever -> Client if is_syn && is_ack && src_port == args.port { flows.lock().insert(reverse, FlowState::new(seq,ts)); continue; } / / Server -> Client if src_port == args.port && payload_len > 0 { if let Some(entry) = flows.lock().get_mut(&reverse) { entry .outstanding .push_back(PacketState::new(seq.wrapping_add(payload_len as u32), ts)); entry.last_seen = ts; } continue; } / / Client -> Server if!is_syn && dst_port == args.port && let Some(entry) = flows.lock().get_mut(&forward) { / / First data packet after TCP handshake if payload_len > 0 && entry.post_connect_first_data_latency.is_none() && let Some(established_at) = entry.established { entry.post_connect_first_data_latency = Some(ts.duration_since(established_at).unwrap_or_default()); continue; } / / ack packet if is_ack { entry.last_seen = ts; while let Some(packet) = entry.outstanding.front() { if ack.wrapping_sub(packet.seq_end) as i32 >=0 { let sample = ts.duration_since(packet.ts).unwrap_or_default(); let sample_ms = sample.as_secs_f64() *1000.0; / / The third handshake ACK - Client -> Server if entry.established.is_none() { entry.established = Some(ts); } entry.add_sample(sample_ms); entry.outstanding.pop_front(); } else { break; } } } } } } } #[derive(Debug, Clone, Hash, PartialEq, Eq)] struct FlowKey { src: IpAddr, src_port: u16, dst: IpAddr, dst_port: u16, } / / / Packet status (sequence number and timestamp) #[derive(Debug)] struct PacketState { / / / The sequence number (seq) of the sent packet + the length of the TCP packet; the corresponding ACK will be >= this value. seq_end: u32, / / / Sending time ts: SystemTime, } #[derive(Debug)] struct FlowState { / / / TCP handshake completion time established: Option <systemtime>, / / / Delay in sending the first data packet after a successful TCP handshake post_connect_first_data_latency: Option <duration>, / / / Smooth round-trip time, RFC 6298: srtt_new = (1 - α) × srtt_old + α × measured_rtt / / / Best estimate of RTT for expressing TCP connection / / / Smoothed Round-Trip Time srtt: Option <f64>, / / in ms / / / Minimum round trip delay min_rtt: Option <f64>, / / / Round-trip delay jitter rttvar: Option <f64>, / / / List of messages to send outstanding: VecDeque <packetstate>, / / / Last ack time last_seen: SystemTime, } impl PacketState { fn new(seq_end: u32, ts: SystemTime) -> Self { Self { seq_end, ts} } } impl FlowState { fn new(seq_end: u32, ts: SystemTime) -> Self { let packet = PacketState::new(seq_end, ts); let mut outstanding = VecDeque::new(); outstanding.push_back(packet);<000027�>Self { established: None, post_connect_first_data_latency: None, srtt: None, min_rtt: None, rttvar: None, outstanding, last_seen: ts, } } fn add_sample(&mut self, sample_ms: f64) { const ALPHA: f64 = 0.125; / / 1 / 8 const BETA: f64 = 0.25; / / 1 / 4 match self.srtt { Some(prev) => { let srtt = prev * (1.0 - ALPHA) + sample_ms * ALPHA; self.srtt = Some(srtt); let prev_rttvar = self.rttvar.unwrap(); let deviation = (sample_ms - prev).abs(); let rttvar = prev_rttvar * (1.0 - BETA) + deviation *BETA; self.rttvar = Some(rttvar); self.min_rtt = Some(self.min_rtt.unwrap().min(sample_ms)); } None => { self.srtt = Some(sample_ms); self.rttvar = Some(sample_ms / 2.0); self.min_rtt = Some(sample_ms); } } } } ``` 4. Regularly generate reports It outputs test reports within a specified time period, providing raw data for manual analysis and judgment.

[0033] Furthermore, based on preset thresholds, it determines whether a certain source IP is suspected of using a proxy service and marks it in the report.

[0034] The preset threshold can use default values ​​or custom configuration parameters.

[0035] Furthermore, parameters such as max_srtt, max_rttvar_ratio, and max_rto can be used to filter out connections with inherently high latency and packet loss rates, thus avoiding false alarms.

[0036] Rust std::thread::spawn(move || { loop { std::thread::sleep(Duration::from_secs(report_interval)); let flows = flows_r.lock(); println!("--- Proxy detection report ---"); for (k, v) in flows.iter() { if let (Some(post_establish_latency), Some(srtt), Some(rttvar), Some(min_rtt)) = ( v.post_connect_first_data_latency, v.srtt, v.rttvar, v.min_rtt, ) { let post_establish_latency = post_establish_latency.as_secs_f64() * 1000.0; let rto = srtt + rttvar * 4.0; debug!( "{} post_establish_latency={:.2}ms srtt={:.2}msrttvar={:.2}ms min_rtt={:.2}ms rto={:.2}ms", k, post_establish_latency, srtt, rttvar, min_rtt,rto ); if max_srtt < srtt || max_rttvar_ratio < (rttvar / srtt) || max_rto < rto { continue; } if post_establish_latency < min_fb_ms as f64 || post_establish_latency > max_fb_ms as f64 { println!( "{} suspected of using a proxy - post_establish_latency={:.2}ms srtt={:.2}ms rttvar={:.2}ms min_rtt={:.2}ms rto={:.2}ms", k, post_establish_latency, srtt, rttvar, min_rtt, rto ); } } } println!("--- end report ---"); } }); ``` Example 1

[0037] like Figure 1 As shown, this embodiment provides a proxy server detection method based on TCP timing characteristics, including the following steps: S1. Capture TCP packets on the server-side network interface and set a filter based on the preset monitoring port to capture network traffic of the target service; S2. Parse the captured TCP packets, extract the source address, source port, destination address, and destination port to form the identifier of the corresponding TCP connection stream, and create and maintain a state record for each connection stream represented by the identifier; the state record records at least the time when the TCP connection of the connection stream is established, and the arrival time of the first application layer data packet after the connection is established. S3. Based on the status record, calculate the time difference between the arrival time of the first application layer data packet and the completion time of the TCP connection establishment, and use it as the first packet delay of the connection stream; S4. Based on the sending time of the data packets sent in the same connection stream and the arrival time of the corresponding acknowledgment packets received, measure multiple round-trip time (RTT) samples, and calculate the smoothed round-trip time (SRTT) and round-trip time jitter (RTTVAR) of the connection stream according to the RTT samples. S5. Compare the first packet delay with a preset normal delay threshold range; simultaneously, determine whether the SRTT exceeds a preset first delay threshold, and determine whether the ratio of RTTVAR to SRTT exceeds a preset jitter ratio threshold; if the SRTT does not exceed the first delay threshold and the ratio does not exceed the jitter ratio threshold, then the network condition is determined to be stable; when the network condition is determined to be stable and the first packet delay exceeds the normal delay threshold range, then the source end of the connection stream is determined to use a proxy server.

[0038] In this embodiment, preferably, in step S1, the filter is further configured based on a preset list of source IP addresses to be monitored, and only captures traffic from IP addresses in the list.

[0039] In this embodiment, preferably, in step S4, the calculation of the smooth round-trip time delay (SRTT) and round-trip time delay jitter (RTTVAR) follows the RFC 6298 standard; For the initial calculation, SRTT = measured RTT, RTTVAR = measured RTT / 2; In subsequent updates, SRTT = (1-α) × SRTT_old + α × measured RTT, where α = 0.125; RTTVAR = (1-β) × RTTVAR_old + β × |measured RTT - SRTT_old|, where β = 0.25.

[0040] In this embodiment, preferably, in step S5, the retransmission timeout RTO is calculated according to the formula RTO=SRTT+4×RTTVAR, and it is determined whether the RTO exceeds a preset second delay threshold; the network condition is determined to be stable only when the SRTT does not exceed the first delay threshold, the ratio does not exceed the jitter ratio threshold, and the RTO does not exceed the second delay threshold.

[0041] In this embodiment, preferably, the normal delay threshold range is between the first threshold and the second threshold.

[0042] In this embodiment, preferably, the value range of the first threshold is 5 milliseconds to 20 milliseconds, and the value range of the second threshold is 80 milliseconds to 200 milliseconds.

[0043] In this embodiment, preferably, it also includes step S6: summarizing and outputting the determination results of all S5 within the preset time interval.

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

[0045] like Figure 2 As shown, this embodiment provides a proxy server detection device based on TCP timing characteristics, including: The packet capture and filtering module captures TCP packets at the server-side network interface and sets filters based on preset monitoring ports to capture network traffic of the target service. The flow state management module parses the captured TCP packets, extracts the source address, source port, destination address, and destination port to form the identifier of the corresponding TCP connection flow, and creates and maintains a state record for each connection flow represented by the identifier; the state record records at least the time when the TCP connection of the connection flow is established, and the arrival time of the first application layer data packet after the connection is established. The indicator calculation module calculates the time difference between the arrival time of the first application layer data packet and the completion time of the TCP connection establishment based on the status record, and uses it as the first packet delay of the connection stream. The calculation module measures multiple round-trip time (RTT) samples based on the sending time of the data packets sent in the same connection stream and the arrival time of the corresponding acknowledgment packets received, and calculates the smoothed round-trip time (SRTT) and round-trip time jitter (RTTVAR) of the connection stream based on the RTT samples. The proxy determination module compares the first packet delay with a preset normal delay threshold range; simultaneously, it determines whether the SRTT exceeds a preset first delay threshold and whether the ratio of RTTVAR to SRTT exceeds a preset jitter ratio threshold; if the SRTT does not exceed the first delay threshold and the ratio does not exceed the jitter ratio threshold, the network condition is determined to be stable; when the network condition is determined to be stable and the first packet delay exceeds the normal delay threshold range, the source end of the connection stream is determined to use a proxy server.

[0046] In this embodiment, preferably, the packet capture filtering module further includes a filter set based on a preset list of source IP addresses to be monitored, capturing only traffic from IP addresses in the list.

[0047] In this embodiment, preferably, the calculation module calculates the smooth round-trip time delay (SRTT) and round-trip time delay jitter (RTTVAR) in accordance with the RFC 6298 standard; For the initial calculation, SRTT = measured RTT, RTTVAR = measured RTT / 2; In subsequent updates, SRTT = (1-α) × SRTT_old + α × measured RTT, where α = 0.125; RTTVAR = (1-β) × RTTVAR_old + β × |measured RTT - SRTT_old|, where β = 0.25.

[0048] In this embodiment, preferably, the proxy determination module also calculates the retransmission timeout RTO according to the formula RTO=SRTT+4×RTTVAR, and determines whether the RTO exceeds a preset second delay threshold; the network condition is determined to be stable only when the SRTT does not exceed the first delay threshold, the ratio does not exceed the jitter ratio threshold, and the RTO does not exceed the second delay threshold.

[0049] In this embodiment, preferably, the normal delay threshold range is between the first threshold and the second threshold.

[0050] In this embodiment, preferably, the value range of the first threshold is 5 milliseconds to 20 milliseconds, and the value range of the second threshold is 80 milliseconds to 200 milliseconds.

[0051] In this embodiment, preferably, it also includes a display module, which summarizes and outputs the judgment results of all agent judgment modules within the preset time interval.

[0052] 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.

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

[0054] 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.

[0055] 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.

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

[0057] 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.

[0058] 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.

[0059] 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.

[0060] 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.

[0061] 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.

[0062] 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.< / packetstate> < / duration> < / systemtime> < / ipaddr> < / ipaddr> < / string> < / string>

Claims

1. A proxy server detection method based on TCP timing characteristics, characterized in that, Includes the following steps: S1. Capture TCP packets on the server-side network interface and set a filter based on the preset monitoring port to capture network traffic of the target service; S2. Parse the captured TCP packets, extract the source address, source port, destination address, and destination port to form the identifier of the corresponding TCP connection stream, and create and maintain a state record for each connection stream represented by the identifier; the state record records at least the time when the TCP connection of the connection stream is established, and the arrival time of the first application layer data packet after the connection is established. S3. Based on the status record, calculate the time difference between the arrival time of the first application layer data packet and the completion time of the TCP connection establishment, and use it as the first packet delay of the connection stream; S4. Based on the sending time of the data packets sent in the same connection stream and the arrival time of the corresponding acknowledgment packets received, measure multiple round-trip time (RTT) samples, and calculate the smoothed round-trip time (SRTT) and round-trip time jitter (RTTVAR) of the connection stream according to the RTT samples. S5. Compare the first packet delay with a preset normal delay threshold range; at the same time, determine whether the SRTT exceeds a preset first delay threshold, and determine whether the ratio of RTTVAR to SRTT exceeds a preset jitter ratio threshold; if the SRTT does not exceed the first delay threshold and the ratio does not exceed the jitter ratio threshold, then the network condition is determined to be stable. When the network condition is determined to be stable and the delay of the first packet exceeds the normal delay threshold range, it is determined that the source of the connection stream uses a proxy server.

2. The method according to claim 1, characterized in that, In step S1, the filter is further configured based on a preset list of source IP addresses to be monitored, and only captures traffic from IP addresses in the list.

3. The method according to claim 1, characterized in that, In step S4, the calculation of the smooth round-trip time delay (SRTT) and round-trip time delay jitter (RTTVAR) follows the RFC 6298 standard. For the initial calculation, SRTT = measured RTT, RTTVAR = measured RTT / 2; In subsequent updates, SRTT = (1-α) × SRTT_old + α × measured RTT, where α = 0.125; RTTVAR = (1-β) × RTTVAR_old + β × |measured RTT - SRTT_old|, where β = 0.

25.

4. The method according to claim 1, characterized in that, In step S5, the retransmission timeout RTO is calculated according to the formula RTO=SRTT+4×RTTVAR, and it is determined whether the RTO exceeds the preset second delay threshold. The network condition is determined to be stable only when the SRTT does not exceed the first delay threshold, the ratio does not exceed the jitter ratio threshold, and the RTO does not exceed the second delay threshold.

5. The method according to claim 1, characterized in that, The normal delay threshold range is between the first threshold and the second threshold.

6. The method according to claim 5, characterized in that, The first threshold ranges from 5 milliseconds to 20 milliseconds, and the second threshold ranges from 80 milliseconds to 200 milliseconds.

7. The method according to claim 1, characterized in that, It also includes step S6, which involves summarizing and outputting the judgment results of all S5 within a preset time interval.

8. A proxy server detection device based on TCP timing characteristics, characterized in that: include: The packet capture and filtering module captures TCP packets at the server-side network interface and sets filters based on preset monitoring ports to capture network traffic of the target service. The flow state management module parses the captured TCP packets, extracts the source address, source port, destination address, and destination port to form the identifier of the corresponding TCP connection flow, and creates and maintains a state record for each connection flow represented by the identifier; the state record records at least the time when the TCP connection of the connection flow is established, and the arrival time of the first application layer data packet after the connection is established. The indicator calculation module calculates the time difference between the arrival time of the first application layer data packet and the completion time of the TCP connection establishment based on the status record, and uses it as the first packet delay of the connection stream. The calculation module measures multiple round-trip time (RTT) samples based on the sending time of the data packets sent in the same connection stream and the arrival time of the corresponding acknowledgment packets received, and calculates the smoothed round-trip time (SRTT) and round-trip time jitter (RTTVAR) of the connection stream based on the RTT samples. The proxy determination module compares the first packet delay with a preset normal delay threshold range; at the same time, it determines whether the SRTT exceeds a preset first delay threshold and whether the ratio of RTTVAR to SRTT exceeds a preset jitter ratio threshold; if the SRTT does not exceed the first delay threshold and the ratio does not exceed the jitter ratio threshold, the network condition is determined to be stable. When the network condition is determined to be stable and the delay of the first packet exceeds the normal delay threshold range, it is determined that the source of the connection stream uses a proxy server.

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 7.

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 7.

Images