## 4 Automated Online Traffic Collection, Sample Construction, and Correlation
### Cross-Platform Traffic Collection and Sample Construction
#### 4.2.1 Windows  
The Windows platform has the most significant number of application types. However, its user affinity leads to a large number of resource-intensive applications. We first use the netstat command and network adapter packet capture to realize sample capture in a Windows environment and confirm the current packet's process by querying the \"PID-port\" pair returned by netstat. However, severe packet loss occurs because netstat polling consumes many system resources. In Windows, interactions are event-based.  
The event will be recorded in the system, including the process of access to the network. These can be obtained through WinAPI system functions. Hence, we propose an A3C optimization method for the Windows platform using WinAPI. In WinAPI system functions, two functions can obtain the network access relationship of the process, respectively, namely _GetExtendedTopTable_ and _GetExtendedUdpTable_. These two functions can obtain the current TCP and UDP network connection status, including the port to PID mapping relationship, and do not need to read the disk. These two functions retrieve tables we call Extended TCP Table (ETT) and Extended UDP Table (EUT), respectively.  
In addition, to obtain the relationship between the process name and PID, we need to obtain the running status of the current process in the system when the traffic is generated. This information can also be obtained through the WinAPI function _CreateToolhelp32 Snapshot_, known as the snapshot of processes (SoP). A3C-Windows sample collection and construction procedure is demonstrated in Figure 4. It can be divided into three phases: traffic collection, packet parsing, and process mapping.  
In order to realize automation and improve efficiency to prevent packet loss, we first automatically identify network adapters through the gateway and pre-initialize port-PID mapping (PP mapping), PID-process name mapping (PN mapping), and process name-application tree (NA tree) relationships. We first retrieve all the network adapters because, in a Windows environment, there are often multiple network adapters, and the name of the network adapter is inconsistent with the name of the network access. The phenomenon can confuse the choice of adapters that need to listen to. Therefore, we first query the adapter configured with a gateway because only the adapter which accesses the network will be assigned a gateway on the same network segment as the IP address. Then we obtain the PP mapping from the current ETT and EUT, the PN mapping from the process table, and the NA tree from the prior knowledge base.  
Then, in packet parsing and process mapping, the three mapping relationships are updated in real-time, and the continuous association of \"port-PID-process name-application\" is realized to form labeled samples automatically.  
It is important to note that the traffic could be encrypted on the network or the data link layer. The label is acquired before the data encryption in sample construction, but the sample is acquired after. If the transport layer is encrypted, it is necessary to advance the collection point before the encryption.  
Under Windows, a semi-automated sample collection is built to correspond to the regular operation of the user, which is user transparent. Moreover, fully-automated sample collection and construction can be achieved through scripts. Since the user is only responsible for using the application, no manual error is introduced into the collection and labeling process.