Identifying Services and Devices Efficiently with a TCP Stateless Scanning Model ^†

Abstract

Fast large-scale network scanning is an important way to understand internet service configurations and security in real time, among which stateless scan technology is representative. Existing stateless scanners can perform single-packet scans for internet-wide network measurements but are limited to host discovery or port scanning. To obtain further information over TCP, slower stateful scanners must be used in conjunction, which spend more time and memory because of connection state maintenance. Through the simplification of the TCP finite state machine (FSM), this paper proposes a novel stateless scanning model, which can establish TCP connections and obtain further responses in a completely stateless manner. Based on this model, we implement ZBanner, an improved modular stateless scanner that utilizes user-defined probes for identifying services and versions, fingerprinting TLS servers, etc. We present the unique design of ZBanner and experimentally characterize its feasibility and performance. Experiments show that ZBanner performs better than current state-of-the-art solutions in terms of scan rate and memory usage. ZBanner achieves a scan rate that is at least three times faster than current tools for generic ports and over 90 times faster for open ports while keeping a minimum and stable memory usage.

1. Introduction

Fast, large-scale network scanning serves as an important way to understand service configurations and security within the internet in real time. Among methods, stateless scanning is often used to quickly collect information of internet-scale ports, which is the basis of subsequent network measurements [1,2,3,4,5,6]. Recent research indicates that focusing solely on TCP liveness during large-scale network surveys, as stateless scanners do, can result in misjudgments regarding actual services [7] and can overlook that some ports cannot complete the expected application-layer handshakes. To address these limitations, many studies incorporate stateful scanners which are capable of establishing complete TCP connections to obtain more accurate and comprehensive information about target ports [8,9,10,11,12,13,14,15].

Existing stateless scanners are limited to single-packet scans such as host discovery or port scanning without local state maintaining. They cannot obtain further information over TCP. Stateful scanners, which can establish TCP connections with target ports to obtain further responses, have to maintain states for every connection through protocol stacks. However, when conducting large-scale scans, maintaining a significant number of connection states becomes resource intensive and also slows down the scan rate, especially with regard to ordinary hardware configuration. Consequently, two-phase scanning that combines stateless and stateful scanners is typically used, which spends more time and resources overall.

In this paper, we first analyze popular stateless scanning techniques from the perspective of the TCP finite state machine (FSM). Then, we simplify the FSM for TCP communication and construct a stateless scanning model, which can establish a TCP connection and receive further responses in a completely stateless manner. Based on this model, we implement ZBanner—a modular stateless scanner designed for fast large-scale network measurement. ZBanner establishes connections with target ports and achieves high-speed responses obtaining TCP with low memory usage. Specifically, ZBanner remains robust from a number of network anomalies during the scanning process. In addition, ZBanner includes extensible probe modules which enable various scanning tasks.

Through a series of experiments and comparisons with state-of-the-art solutions, we characterized ZBanner’s feasibility and validated its performance on scan rate and memory usage for obtaining responses over TCP in a generalized scenario. The experimental results demonstrate that ZBanner achieves 98% coverage, which is independent of the scan rate and sufficiently comprehensive for typical research applications. Furthermore, ZBanner’s scan rate and memory usage advantages increase as the proportion of known open ports rises. On ordinary hardware configuration, ZBanner performs at least three times faster than current state-of-the-art solutions. When scanning specific target ports already determined to be open, ZBanner reduces scan time by over 90 times compared to existing approaches, all while maintaining minimal and stable memory usage.

This paper makes the following key contributions:

• We construct a stateless scanning model by simplifying the TCP finite-state machine, which, to the best of our knowledge, is the first to enable fully stateless asynchronous scanning over TCP connections—completing the three-way handshake and obtaining subsequent application-layer responses without maintaining per-connection state.
• Based on the stateless scanning model, we implement a modular stateless scanner called ZBanner for fast large-scale network measurement. Depending on user-defined probes, ZBanner is capable of banner grabbing, service identification or version detection efficiently, etc.
• Through a series of experiments and comparisons, we validate the feasibility of the stateless scanning model and demonstrate that ZBanner outperforms current state-of-the-art solutions.

2. Related Works

Our work improves on existing stateless scanning technique to produce a stateless scanner for establishing TCP connections and obtaining further responses. This stateless scanner operates just like a two-phase scan but with a faster scan rate and lower memory usage. In this section, we introduce existing well-known stateless scanning technique and commonly used two-phase scan solutions. The latter will be the subject of comparison in the experimental section of this paper.

2.1. Stateless Scanning Technique

Stateless scanning bypasses the TCP protocol stack of the operating system and does not maintain connection states. This avoids memory limitations and the complex state transform process in order to accelerate the scanning speeds across the internet. The stateless scanning technique serves as the foundation for large-scale network measurements and is the initial step in identifying vulnerable nodes or weakness on the internet [16]. ZMap [17], the most popular stateless port scanner, efficiently utilizes network interfaces and bandwidth resources to scan specified ports across the entire IPv4 address space within 45 min. Similar to ZMap, XMap [18], improved by Li et al. and open-source tools like Masscan [19], also employs a similar stateless scanning technique with additional support for IPv6. Building upon these tools, Yarrp [20,21], Flashroute [22], and D-Miner [23] apply the stateless scanning technique to network topology discovery, achieving the rapid tracking of /24 prefix routes at the internet scale.

However, existing stateless scanners are designed for single-packet scans and are suitable only for limited scenarios such as host discovery and port scanning that work without complete TCP connections.

2.2. Two-Phase Scan

In real-world scenarios, stateless port scanners are often combined with slower stateful scanners which are capable of establishing complete TCP connections [16] to obtain further information. These two-phase approaches decompose the scanning process into port scanning and obtaining further information over TCP.

Some studies optimize scanning mechanisms to achieve a rapid scan rate for stateful scanners as much as possible. Nmap [24], for instance, employs its custom asynchronous communication library Nsock to obtain information over TCP from target ports, forming the basis of features like service identification and version detection. ZGrab [25] utilizes Go language’s standard library Net and goroutines to produce a high-speed scan. Actually, ZGrab relies on OS-provided asynchronous communication API. LZR [7] and Masscan, aiming for service identification, maintain TCP connection states in user space memory to complete scanning after confirming port availability without a new connection.

Depending on whether the stateless and stateful scanners share a single TCP connection for one target port, the two-phase scanning approach can be further categorized into the continuous two-phase scan and separate two-phase scan. ZMap/LZR and ZMap/ZGrab are representative solutions for these two scanning types and widely used in various large-scale network measurements.

However, the introduction of stateful scanners in two-phase scans leads to a dependence of the TCP connections’ establishment through the operating system or user-space (maybe incomplete) TCP protocol stack. Although many studies leverage asynchronous mechanisms to enhance its efficiency, maintaining a large number of TCP connection states during large-scale scanning limits the overall scan rate and spends more memory.

3. Stateless Scanning Model

Existing stateless scanning techniques only support single-packet scans and collect limited information. Our target is to construct a new stateless scanning model which can establish complete TCP connections obtaining further information by improving existing stateless scanners.

Take the previous popular port scanner ZMap, for example; it efficiently utilizes network interfaces and bandwidth as it encodes state information into SYN packets to achieve statelessness during scanning, as is illustrated in Figure 1a. ZMap operates with only two states during scanning: CLOSED and SYN_SENT, as shown in Figure 1b. With just two states, ZMap identifies the SYN_SENT state by encoding information into the sequence number field of SYN packets and achieves statelessness. This approach leverages the deterministic relationship between the acknowledgment numbers in received SYN-ACK or RST packets and the SYN_SENT state.

Figure 1. Analysis of the stateless mechanism in ZMap. (a) Communication process of ZMap. (b) FSM of ZMap.

To obtain further information over TCP, the scanning process must involve the establishment of complete TCP connection, sending specified probes, receiving responses, and closing connection with target ports. Inspired by the analysis to ZMap, we attempt to simplify the TCP FSM based on scanning scenarios that obtain information over TCP. Our simplification process adheres to the following principles, shown in Figure 2:

Figure 2. Simplification of FSM in specific scanning scenarios.

• Since scanning is a client-side behavior, we remove typical server-side state transitions, such as from LISTEN to SYN_RCVD.
• Stateless conditions prevent us from maintaining timers for connections. Consequently, we eliminate state transitions caused by timeouts, such as from TIME_WAIT to CLOSED.
• In the absence of maintaining half-closed connections, we always choose to terminate communication by having the client send an RST packet. This simplifies the process such as from ESTABLISHED to FIN_WAIT_1.

Following the outlined approach, we arrive at a preliminarily simplified FSM as depicted in the Figure 3. Unlike existing stateless scanning techniques, ours involve establishing complete TCP connection states and subsequent interactions. Consequently, we introduce the ESTABLISHED state [26] into the FSM.

Figure 3. Preliminarily simplified FSM.

Although the internal transitions within ESTABLISHED are complex, we do not require long-term stable TCP data communication while scanning. Thus, we avoid maintaining congestion control and retransmission mechanisms to simplify the general communication pattern of scanning (as shown in the Figure 4a). By attaching probe payloads to ACK packets during the three-way handshake, we further streamline the communication process (as illustrated in Figure 4b). At this point, the handshake and ESTABLISHED stages are no longer explicitly differentiated, resulting in the final FSM, shown in the Figure 5.

Figure 4. Simplification of communication process in scanning. (a) Typical pattern of communication process. (b) Merging the handshake and ESTABLISHED phases.

Figure 5. Simplified FSM.

The simplified FSM for scanning comprises three states: CLOSED, SYN_SENT, and TRANSMIT. While SYN_SENT is identified using the relationship between the SYN packet’s sequence number and the received SYN-ACK packet’s acknowledgment number, TRANSMIT is identified based on the difference between their acknowledgment numbers (which corresponds to the length of probe content). To support multiple probe types, we encode the probe type, content length, and TCP connection quadruple hash into the initial sequence number of the SYN packet, as is depicted in Figure 6.

Figure 6. Encoding of 32-bit sequence number.

After identifying all states, we construct the final stateless scanning model. The core algorithm (logic for the receiver thread) is illustrated in Algorithm 1. When we receive a TCP packet with ACK flag, we identify and handle its state as follows:

Algorithm 1: Stateless Scanning Model

• If the acknowledgment number’s hash part (last 16 bits) equals the hash value of the TCP connection quadruple plus one, we identify the packet as originating from a SYN_SENT connection. We promptly send an ACK packet with the probe payload attached.
• When the acknowledgment number’s hash part equals the hash value of the TCP connection quadruple plus one and the acknowledgment number’s probe content length (bits 4 to 11), we identify the packet as coming from an ESTABLISHED connection. We then determine the probe type based on the first four bits of the acknowledgment number. The accompanying data is processed by the corresponding probe module, and we actively send an RST packet to terminate the connection.
• For other acknowledgment numbers, the packet is either not a response from our initiated connection or indicates an error.

To assess the risk of hash collisions, we model a typical probing scenario based on the birthday paradox. In a single experiment, the number of concurrent probing connections is typically no more than 500 for experimental setup). Under this condition, the collision probability for a 16-bit hash (with a space size of 65,536) is approximately 1.9%. More importantly, after an initial hash match, the system further verifies the consistency of the source/destination IP addresses and port numbers (i.e., the four-tuple). A response is deemed valid only when both the hash and the four-tuple match, thereby reducing false positives to a negligible level.

4. Design of ZBanner

Based on the stateless scanning model proposed in previous section, we designed and implemented a modular stateless scanner called ZBanner for large-scale network measurement. In this section, we describe the main unique designs of ZBanner for implementing the stateless scanning model. ZBanner is capable of performing port scanning and obtaining further information over TCP efficiently in a completely stateless manner with the architecture shown in Figure 7. Its differences from existing stateless scanners are noted in distinctive colors.

Figure 7. Architecture of ZBanner.

4.1. Asynchronous Mode with Callback Queue

Current asynchronous stateless scanners decouple the packets sending and receiving into separate threads. However, our stateless scanning model needs to be sent/reply to the target host after identified different states. To adapt ZBanner to our stateless scanning model, we introduce a callback queue between the sender and receiver threads based on the existing asynchronous mode. After the receiver thread receives a packet and identifies the state, it generates new packets that need to be sent into the callback queue. The sender thread periodically takes the packets from the callback queue and sends them.

To prevent connection anomalies due to timeouts, the sender thread prioritizes transmitting packets from the callback queue in each batch. When the callback queue becomes empty, the sender thread continues transmitting TCP SYN packets to new target ports. By utilizing an asynchronous mode with a callback queue, ZBanner is capable of replying appropriately for different states, thus achieving the stateless operation.

4.2. Handling Various Connection Anomalies

While our stateless scanning model is an idealized creation based on normal communication, ZBanner must handle various connection anomalies efficiently and robustly in the real world. Combining several anomalies described by Izhikevich et al. [7] and our findings in actual scans, we identified that scanners may encounter the following connection anomalies that result in slowing down the scan rate or missing some targets.

• Connection Shunning: During the execution of a separate two-phase scan (e.g., ZMap followed by LZR or ZGrab), the initial stateless scanner may leave a semi-connected state on the target host, resulting in the failure of the subsequent stateful scan and causing some target ports to be missed—an issue that ZBanner avoids by reusing the same connection for both scanning and follow-up interaction.
• Zero Window DDoS Protections: Target hosts may specify a zero window size in the TCP SYN-ACK packet to prevent us from sending further probes. This makes existing stateless scanners believe the port is open and stateful scanners keep waiting senselessly for the target to open its TCP window.
• Dropping Connections Mid-Handshake: The selective discarding of packets by middleboxes can lead to the target hosts not receiving the final ACK packets during the TCP handshake process and can prevent us from establishing connections. This causes stateful scanners to receive several TCP SYN-ACK packets because of the retransmiting of the target, and to keep trying to reply to TCP ACK packets.
• Dynamic Blocking after Handshake: Due to the blocking of the ACK packets from the target port by middleboxes, target hosts cannot acknowledge the probe data we sent. This makes stateful scanners keep retransmitting the probe senselessly.
• Waiting Complete Probe: When our probe contains data that does not match the service of target port yet, the target host confirms our probe and expects further data instead of responding to hint at an error. This makes stateful scanners maintain the connection for a long time until target host closes it.

Since ZBanner implements our stateless scanning model, it is inherently capable of handling some connection anomalies. For the “connection shunning”, ZBanner reuses the same connection to port scanning and follow-up interaction to avoid the anomaly. For the “dynamic blocking after handshake”, the stateless scanning model ensures that just the valid connection state is maintained.

Zero Window Exclusion. Regarding “zero window DDOS protection”, if ZBanner receives a TCP SYN-ACK packet with a window size of zero during port scanning, it identifies this and actively closes the invalid connection.

Sliding Window Deduplication. For the “dropping connections mid-handshake”, ZBanner employs a sliding window mechanism to filter out duplicate packets within a short time frame during both port scanning and response obtaining over TCP. This prevents sending useless duplicate probes and conserves bandwidth.

Allowlist Filtering. For the “waiting complete probe”, ZBanner does not process acknowledgement without response data from target ports and maintains no state at all. ZBanner employs an allowlist to filter out packets we do not care for. The following TCP flag combinations can carry response data:

• ACK: This indicates a large-sized response and is the first packet with data that contains a banner.
• PSH-ACK: This contains the whole response data to our probe.
• FIN-PSH-ACK: This includes the whole response data and actively closes the connection.

4.3. Handling TCP Sliding Window Protocol

The sliding window protocol controls and optimizes packet flow between senders and receivers in TCP connection, while ensuring a balanced approach to packet delivery. The protocol requires the receiver to acknowledge receipt of each data packet, and it enables the receiver to use a single or multiple acknowledgments to confirm the delivery of multiple packets.

However, the sliding window protocol facilitates sending a batch of packets that makes trouble for ZBanner. ZBanner potentially assumes the first received packet with the response data is the actual first packet in the order. This is because our stateless scanning model cannot identify the order of packets without maintaining states for each connection.

To handle the TCP sliding window protocol, ZBanner sets a proper TCP window size for the ACK packet to mention the limited capability of handling data. This means the target host sends no more than one packet before our acknowledgement in most cases.

We discuss the robustness of ZBanner in the Appendix A, and detailed experimental results are presented in Table A1.

4.4. Extensible Probe Module

Compared to single-packet scan, ZBanner encounters a diverse range of services over TCP from which richer information can be extracted. ZBanner offers an extensible probe module that supports the custom generation of probe content and the handling of response results through a unified interface. Once ZBanner establishes a connection with the target port after confirming its TCP aliveness with a non-zero window size, the specified probe module will generate proper probe data based on the type of target. Then generated content is sent by ZBanner, and the response banners are processed and reported by the specified probe module.

This approach significantly simplifies the process of extending ZBanner’s capabilities. By creating custom probe modules, various types of information detection over TCP can be achieved. We have implemented some typical probes to achieve practical functions including service identification, service version, detection, etc.

5. Evaluation

In this section, we conducted a series of experiments to characterize its differences from existing stateless scanners, its feasibility in fast, large-scale network scanning, and its performance in terms of scan rate and memory usage.

5.1. Experimental Setup

All experiments were conducted on a virtual cloud host equipped with a four-core CPU and 8 GB of memory—a configuration commonly used in personal cloud hosting. The host was allocated symmetric 1 GbE of bandwidth for both upstream and downstream communication. The operating system running on the host was Ubuntu 22.04 LTS, with the 6.5.0-14 generic version of the Linux kernel. The server’s geographical location is within the Chinese mainland, and no other special network configurations were applied.

In fact, ZBanner is able to increase the send rate by up to 10 GbE by parallelization and the zero-copy technique, but such a large amount of traffic will lead to a sharp increase in the packet loss rate [27]. We believe that it is important to have a relatively complete picture of the internet state when applying ZBanner to real-world network measurements. Since the 10 GbE bandwidth condition is not applicable to most network measurement research, a more reasonable network condition was used.

Since information obtaining over TCP could be of various types in different scenarios and since it is impossible to evaluate them for all ports, we take the banner grabbing from the 80 port as the most basic and representative example of information obtaining over TCP. We would like to characterize the efficiency of the various solutions in terms of time by the average scan rate. However, the average scan rate is very difficult to compute accurately, so we use the scan duration to most directly characterize the efficiency.

We consider the following state-of-the-art solutions and their respective settings for comparison:

• ZMap/LZR: Conducts a continuous two-phase scan. The first phase employs an asynchronous, stateless TCP SYN scan using the system calls of raw socket to identify open ports. The second phase performs asynchronous, stateful banner grabbing using the libpcap library. In our experiments, we selectively enabled only one handshake module as the probe, given that LZR is primarily used for service recognition. We utilized the latest release versions of ZMap 3.0 and LZR.
• ZMap/ZGrab: Executes a seperate two-phase scan. Similarly to ZMap/LZR, the first phase involves an asynchronous, stateless TCP SYN scan to identify open ports. The second phase leverages Go language’s goroutines and the Net library for asynchronous, stateful banner grabbing. In our experiments, we avoided ZGrab performing TLS handshakes, for fairness. We used the most recent release versions of ZMap 3.0 and ZGrab 2.

To minimize interference from geographical location and provider restrictions on the detection results, all scanning in our experiments focused on a collection of publicly accessible IP addresses managed by Chinese mainland operators, referred to as the “address set”. This address set encompasses 6691 autonomous systems and approximately 343 million unique public IPs.

5.2. Scan Rate: Is It Too Fast over TCP?

In previous studies [17], it has been demonstrated that when performing stateless port scanning, the scan rate (i.e., the rate of packets sent per second) does not significantly affect the number of port hits (i.e., the count of received SYN-ACK responses) at lower than 1 gbE network speeds. However, when ZBanner establishes TCP connections using a stateless approach and sends probes to target ports, more round-trip exchanges of TCP packets are involved. Consequently, it becomes crucial to determine whether the number of response banners over TCP is influenced by variations in the scan rate.

To address this, we conducted a series of tests using ZBanner. By limiting the packets sent per second, we attempted to grab banners from port 80 across the address set. We performed ten trials, varying the scan rate from 1000 packets per second (pps) to 1.25 million pps. For each scan rate, we calculated the mean port hit count and response banner count. We take the results obtained at the slowest scan rate (1000 pps) as baseline and plot the relationship between the port hit rate and banner respond rate, as shown in Figure 8.

Figure 8. Relationship between port hit rate, banner respond rate, and scan rate.

Our result reveals a clear positive correlation between the port hit rate and banner response rate. This relationship arises because whether a port is hit successfully directly determines whether the establishment of a follow-up TCP connection is attempted. Surprisingly, our preliminary experiments reveal no noticeable correlation between scan rate and either port hit rate or banner response rate. This suggests that ZBanner remains unaffected by changes to the scan rate, even when working in a completely stateless manner. Consequently, running ZBanner at high-speed scan rates within the bandwidth limit of 1 gbE does not compromise the port hit rate or banner response rate. Furthermore, our results validate that ZBanner, based on our stateless scanning model, is fully capable of handling responses triggered by gigabit–speed packet transmission.

5.3. Coverage: How Many Banners We Have Lost?

While a high scan rate does not lead to a decrease in the port hit rate and banner response rate, it fails to fully describe the coverage of information obtaining over TCP during stateless banner grabbing. Specifically, we need to understand what proportion of banners ZBanner can effectively grab.

Given the vast number of internet ports and their dynamic states, determining the exact count of internet ports that respond to a specific probe during a given time frame (i.e., the number of ports running a particular service) is challenging at best, or almost impossible. To address this, we employed ZBanner to try to establish multiple connections in sequence for each target port within a single turn of scanning. Every time the connection was established, we sent the same type of probe to attempt to grab banners. To avoid interference, we ensured a minimum 1 s interval between the connection attempts for each target port. By analyzing the distribution of unique response banners relative to the number of connection attempts, we estimated the actual count of ports running the specified service during that time frame.

As the number of connection attempts increases, the port hit count eventually converges [17]. We expect a similar convergence in the response banner count. If convergence occurs, we can treat the converged value as an estimate of the actual number of service-running ports during that period. This estimate serves as a baseline for assessing the banner grabbing coverage at lower connection attempt rates.

We randomly sampled 30% of the addresses from the address set and conducted 15 rounds of ZBanner scans on port 80 for each sampled address. The connection attempts for each target port ranged from 1 to 15 incrementally. After each connection, we recorded the unique port hit count and response banner count. Since the final convergence value is unknown, we used the results from the first scan (one attempt per port) as the baseline. We calculated port hit rates and banner response rates for subsequent rounds to analyze their trends as shown in Figure 9.

Figure 9. Relationship between port hit rate, banner response rate, and connection times.

Based on the observed trend in banner response rate, we notice that the results stabilize from the tenth round onward. Consequently, we consider the average count of response banners from rounds 10 to 15 as the convergence value. Using this value, we estimate the coverage for the initial three rounds, as shown in the Table 1. While the results may exhibit slight deviations due to factors such as sample selection, scan start time, port services, and probe types, empirical evidence from multiple experiments suggests that as long as upstream network bottlenecks are not a concern, the banner grabbing coverage achieved by attempting only one connection remains consistently around 98%.

Table 1. Coverage Achieved in the Initial three scanning rounds.

Round	Coverage
	Port Hit	Banner Grabbing
1	97.84%	98.15%
2	98.18%	98.79%
3	98.89%	99.40%

This result underscores that ZBanner’s default mode (attempting only one connection) yields sufficiently comprehensive outcomes for common use cases. While it is possible to enhance coverage by configuring ZBanner to increase the number of connection attempts, this approach inevitably extends scan duration.

Unlike port scanning, obtaining information over TCP entails multiple round-trip exchanges of packets within the network. ZBanner deliberately forgoes any guarantees of reliable packet transmission while operating under stateless scanning conditions. However, experimental results, as shown in Figure 9, and Table 1 reveal an intriguing relationship: while banner respond rate and port hit rate converge due to their interdependence, and the former’s convergence value remains lower than the latter’s. This discrepancy challenges our intuitive understanding. After this analysis we think there are two key factors contributing to this phenomenon:

State Maintenance from one Endpoint: Although ZBanner does not maintain the state to ensure reliable packet transmission, the target hosts actively maintain the TCP connection state once they have received the TCP SYN packet. From ZBanner’s perspective, this one-sided effort to maintain network transmission reliability effectively mitigates most packet loss scenarios (as indicated in the Table 2). Consequently, banner grabbing coverage does not significantly lag behind port hit coverage.

Table 2. Mitigation of Packet Loss.

Type	Direction	If Mitigated	Reason
SYN	ZBanner → Target	✖	No maintenance of state.
SYN-ACK	ZBanner ← Target	✔	Target didn’t receive ACK for this packet and retransmit.
ACK with data	ZBanner → Target	✔	Target didn’t receive this packet and retransmit the previous packet.
Banner	ZBanner ← Target	✔	Target didn’t receive ACK for this packet and retransmit.
RST	ZBanner → Target	✔	Target didn’t receive this packet and retransmit the previous packet.

Open Ports Unresponsive to Expected Services: Izhikevich et al. [7] measured that a considerable portion of TCP ports failed to complete the expected application-layer handshake even after responding SYN-ACK packets. For instance, approximately 14% of port 80 responses do not conform to HTTP probes. These deviations may arise from non-HTTP protocols running on the port or other anomalies (as listed in Section 4.2). While these ports do not impact ZBanner’s scan rate, they do contribute to a lower convergence value in the banner response rates. Consequently, the estimated banner grabbing coverage slightly exceeds the port hit coverage.

5.4. Comparison: What Does Statelessness Bring to Us?

When evaluating the performance of large-scale information obtaining over TCP, several factors need to be considered. Notably, the proportion of open ports in the scanned samples significantly impacts the performance of stateful scanners such as LZR and ZGrab.

To comprehensively assess ZBanner’s performance compared to other state-of-the-art solutions across different scenarios, we followed the following steps:

• We randomly selected 500,000 independent addresses from the address set, forming subset A. The remaining addresses constituted the pool for port scanning, from which we identified targets with port 80 open as subset B.
• By combining addresses from subsets A and B, we created 11 sample sets. Each set represented a different proportion (ranging from 0% to 100%) of the known open ports. The total number of unique addresses in each sample set remained constant at 500,000.
• These sample sets corresponded to three scenarios:
  • Generic Target Set with Unknown Information: Addresses with no prior information about open ports.
  • Specific Target Set with Known Open Ports: Addresses with confirmed open ports.
  • Intermediate Target Set with Varying Port Knowledge: Addresses changes after confirmed open ports and is in an intermediate state.

To ensure a fair comparison, we controlled for other factors as follows:

• Both ZBanner and ZMap were configured with a single packet-sending thread.
• We limited the available CPU cores to one using Linux GRUB boot parameters.

It has been verified that under these conditions, ZBanner and ZMap achieve comparable maximum packet scan rates for TCP SYN packets sending.

Under these experimental conditions, we scanned and grabbed banners using ZBanner and other tools. All scans operated at their maximum scan rate (ensuring no packet loss on local machines and completing the scan tasks). The scan durations for each solution are depicted in Figure 10. Additionally, we recorded the user-space virtual memory size occupied by each solution (Figure 11) virtual memory differs from resident memory in that the former can be larger than the physical memory size through memory swapping).

Figure 10. Relationship between scan duration and known open port proportion.

Figure 11. Relationship between virtual memory usage and known open port proportion.

Scan Duration: When the known open port proportion was 0%, the performance of all three solutions was comparable. As the known open port proportion increased, the performance of ZMap/LZR and ZMap/ZGrab declined. ZMap/ZGrab exhibited the most significant degradation. ZMap/LZR’s scan duration was up to 5.2 times longer than ZBanner, while ZMap/ZGrab’s was 28.3 times longer. ZBanner consistently maintained high performance even when the known open port proportion reached 100%. Its stateless packet exchange approach avoided the connection state overhead faced by ZMap/LZR and ZMap/ZGrab.

Memory Usage: ZBanner’s low memory usage aligned with expectations due to our stateless scanning model. ZMap/LZR’s memory usage increased significantly (up to 18.9 GB) as it maintained connection states in user space. ZMap/ZGrab’s memory usage remained stable because ZGrab leveraged Go language’s Net standard library, allowing the operating system protocol stack to manage connection states and preventing memory growth from impacting user memory space. However, this stability comes at the cost of scan rate limitations imposed by the operating system protocol stack, resulting in a significantly increased scan duration.

5.5. Practice: Real Performance in Large-Scale Scanning Scenarios

Building upon the work of Izhikevich et al. [7], it has been observed that when ZMap/LZR operates in an environment with 1 GbE bandwidth and optimal hardware conditions, its scan rate surpasses that of ZMap in identifying live hosts on generic ports across the internet. The difference is particularly pronounced for low-hit-rate ports. This observation aligns with the experimental findings in Section 5.4, where ZBanner’s advantage from the stateless scanning model is not fully evident when the proportion of known open ports is zero.

However, it is essential to recognize that ideal hardware conditions are not always achievable in large-scale network measurements. To demonstrate ZBanner’s practical performance under commonly used hardware conditions, we conducted scans using ZBanner and the current state-of-the-art solutions on the whole address set, targeting port 80. We then curated a subset C comprising approximately 3.61 million unique addresses with known open ports. Both solutions were configured to operate at their maximum scan rates, ensuring complete execution without packet loss on the operation system. The scan duration and virtual memory usage for both solutions during these two rounds of scanning are summarized in Table 3.

Table 3. Comparison of performance in large-scale scanning scenarios.

Type of Targets	Solution	Scan Duration	Virtual Memory Usage
Unknown Open Ports	ZBanner	5 m 32 s	447 MB
	ZMap/LZR	29 m 11 s	223 MB + 23.2 GB
	ZMap/ZGrab	21 m 3 s	223 MB + 2209 MB
Confirmed Open Ports	ZBanner	19 s	428 MB
	ZMap/LZR	31 m	996 MB + 22.7 GB
	ZMap/ZGrab	29 m 50 s	996 MB + 2215 MB

When scanning a generic port set of internet targets, ZBanner’s scan rate is approximately 5.2 times faster than ZMap/LZR and 3.8 times faster than ZMap/ZGrab, according to their scan duration. For specific targets with confirmed open ports, ZBanner’s scan rate is more than 90 times faster than both ZMap/LZR and ZMap/ZGrab.

ZBanner maintains a consistently low memory usage. In contrast, ZMap/LZR’s memory consumption exceeds 20 GB when scanning a diverse set of internet targets. However, this memory usage does not increase proportionally with the known open port ratio. This limitation arises from the hardware configuration used in our experiments, where the memory usage is already at the system’s limit. Attempting to increase scan rates further would result in excessive resource utilization by the process, leading to termination by the operating system.

In summary, when conducting large-scale information obtaining over TCP under commonly used hardware conditions, ZBanner exhibits significant advantages over the current state-of-the-art solutions in terms of both scan rate and memory usage.

6. Discussion

In this section, we discuss the advantages and limitations of, and the reasons for, the stateless scanning model and ZBanner.

6.1. Advantages in Practice

Although the efficiency gains of ZBanner may seem modest in absolute terms based on our experiments, the significance of ZBanner’s efficiency advantage is magnified in practical measurements. Taking the active TLS server fingerprinting as an example, we implemented the corresponding probe to extract the most classical JARM fingerprint [28]. To extract a JARM fingerprint, ten specific probes are sent to the target port and obtain corresponding responses. We believe that the following steps are actually included in the process of fingerprint extraction:

• Confirm whether the target port is open or not.
• If the target port is open, send a probe to confirm that it is running TLS services.
• If the target port is running a TLS service, connect to it multiple times to send probes and obtain responses.

ZBanner is able to combine all the steps in one round of scanning unlike all existing tools of its kind. Since the execution of any step depends on the result of the previous step, bandwidth and other resources are not wasted. Existing stateful scanners and two-phase scan solutions are not well suited to accomplish this task for large-scale targets. For ZBanner, all we need is to write a probe.

6.2. Inherent Limitations

ZBanner is intended to enhance the capabilities of existing stateless scanners, rather than completely replace some stateful scanners. This is because of the inherent limitations of the stateless scanning model.

First, since the stateless scanning model can only recognize the first packet with payload returned by the target host, the banner that we obtain in any given case is maybe incomplete. A typical example is that sometimes it fails to obtain the HTML contents or complete the HTTP header. Although our model is sufficient for identifying most protocols and various scanning tasks, scanning and detection at the content level is beyond the capabilities of ZBanner, and we believe this is better accomplished with existing stateful scanners.

Second, since the stateless scanning model can only complete one-time data interaction after completing the TCP handshake, for the TLS protocol, ZBanner can only identify and obtain some information about the TLS itself, but cannot touch the upper-layer services. While at some point it is possible to identify upper-layer services by the ALPN [29] field of the TLS, we recommend the use of specialized tools for further detection.

6.3. Applicability and Limitations

The stateless scanning model presented in this paper is fundamentally protocol agnostic: as long as a service responds to a well-crafted probe within a single reply packet (or a predictable short sequence), ZBanner can be extended to support it by implementing an appropriate probe generator and response parser. This makes the approach readily applicable to common cleartext protocols such as HTTP (port 80), FTP (21), SMTP (25), and SSH (22), where banner or error messages are typically returned immediately after the TCP handshake.

However, protocols requiring multi-round application-layer negotiation—such as TLS/SSL (e.g., HTTPS on port 443), MySQL 8.0, PostgreSQL 16, or RDP 10.0—pose inherent challenges. In these cases, the server often expects a client-initiated handshake message after the TCP connection is established, and may not send any data until it receives a valid protocol-specific request. Moreover, responses may span multiple packets or depend on session state, which cannot be handled under our strictly stateless model without storing per-connection context. While one could theoretically predefine full handshake sequences, doing so would compromise the memory efficiency that defines our approach. Thus, ZBanner is best suited for services that emit immediate, self-contained responses upon connection establishment—a limitation rooted in protocol semantics rather than the scanning mechanism itself.

7. Conclusions

This paper presents a novel analysis of existing stateless scanning techniques from the perspective of TCP finite-state machines (FSM). Leveraging a simplified TCP FSM, we construct a stateless scanning model that is capable of establishing complete TCP connections and obtaining further information over TCP. Building upon this model, we design and implement ZBanner, a modular stateless scanner specifically tailored for large-scale network measurements. ZBanner operates entirely in a stateless manner, significantly enhancing the efficiency of information obtaining over TCP in large-scale networks. However, due to the limited interaction over TCP, it remains challenging to detect services running on the TLS-encrypted protocol. Future work will focus on efficiently scanning services over the TLS-encrypted protocol with the stateless scanning model.