FlowCLIP: Contrastive Pretraining Using Domain Names for Encrypted Traffic Classification
arXiv:2606.17746v1 [cs.NI] 16 Jun 2026
Eun Hun Choi Department of Computer Science University of North Carolina at Chapel Hill Chapel Hill, NC, USA [email protected]
Abstract—Network traffic classification enables website fingerprinting, intrusion detection, and Quality of Service management. However, developing methods that capture stable and generalizable traffic patterns under realistic deployment conditions remains challenging. We introduce FlowCLIP, a contrastive pretraining framework for domain name prediction from encrypted traffic using only side-channel features: packet inter-arrival times, packet sizes, and packet directions. FlowCLIP uses raw domain names as textual supervision by aligning traffic flow representations with domain name representations through a CLIPstyle contrastive objective. The pretrained traffic encoder is then frozen and evaluated through linear probing on canonicalized domain name labels. We evaluate FlowCLIP on a large-scale QUIC traffic dataset using a time-based protocol, where models are trained on Week 1 traffic and evaluated on traffic from Weeks 2–4. FlowCLIP outperforms competitive machine learning baselines across later evaluation weeks, suggesting that raw domain names provide a textual supervision signal for learning transferable encrypted traffic representations.
I. I NTRODUCTION Network traffic classification supports a variety of tasks, including website fingerprinting, intrusion detection, and Quality of Service management [1]–[3]. These tasks involve identifying websites visited by users, characterizing traffic associated with malicious activity, and allocating network resources efficiently across applications. Two traditional network traffic classification methods are port-based identification, which is based on transport layer port numbers, and deep packet inspection, which reads packet content. In modern network environments, both methods have become unreliable: dynamic port negotiation limits identification by port numbers, while end-to-end encryption limits visible packet content [3]. Recent advances in network infrastructure, transport security, and transport-layer protocols further limit the identifiers available to traffic classifiers, including server IP addresses, domain names, and transport-layer header information. Content delivery networks may host multiple services behind a single address, reducing the reliability of server IP addresses for application identification [4]. Domain names remain reliable identifiers; however, DNS over HTTPS and TLS Encrypted Client Hello can hide these identifiers [4], [5]. In addition, major content providers have widely adopted QUIC, a UDPbased secure transport protocol that reveals less transportlayer header information to passive observers than TLS over
TCP [6]–[8]. Given these limitations, recent encrypted traffic classification studies increasingly train machine learning, deep learning, and self-supervised representation learning models using visible packet metadata and encrypted packet byte representations [3], [9]–[12]. However, reported performance can be difficult to interpret for several reasons. First, evaluation methodology and input representation can strongly influence the results. Packet-level splits may introduce leakage by allowing packets from the same flow to appear in both training and test sets, enabling models to rely on flowspecific artifacts rather than generalizable behavior [13], [14]. Input representation poses a related challenge: when models are trained on packet payload bytes from datasets containing unencrypted traffic, they may learn payload-dependent signals that would not be available in encrypted traffic [14], [15]. These issues motivate evaluations that split data at the flowlevel and restrict inputs to features available under encryption. Second, SNI domain names are commonly used to support labeling in traffic classification datasets [11], [12], [14], [16]. However, there is no standard procedure for mapping domain names to application categories, so application labels may vary across datasets and reflect different labeling choices [17]. Third, recent studies show that lightweight machine learning models using flow-level features may perform competitively with more complex deep learning models on widely used traffic classification datasets [9], [18], [19]. For example, XGBoost [20] and 1-nearest neighbor classifiers (1-NN) [21] have been reported to match or exceed recent deep learning models on widely used datasets [9], [18]. These findings suggest that new classification methods should be evaluated against strong baselines. Motivated by these challenges, we present FlowCLIP, a contrastive pretraining framework for predicting domain names from encrypted traffic under a realistic evaluation setting. FlowCLIP consists of a traffic encoder and a domain name text encoder that map side-channel traffic features and raw domain names into a shared representation space. During pretraining, the two encoders are optimized with a CLIP-style contrastive objective to align matched traffic and domain name representations [22]. After pretraining, the traffic encoder is frozen and paired with a linear classification head for downstream prediction over canonicalized domain name labels. We evaluate FlowCLIP on a large-scale QUIC traffic
dataset, motivated by QUIC’s wide deployment by major content providers and reduced visibility of transport-layer information compared with TCP [6], [8], [23]. We use a timebased evaluation protocol in which training data comes from earlier traffic and test data comes from later traffic [19]. This paper therefore focuses on whether contrastive pretraining can improve flow-level representations for domain name prediction under temporal distribution shift. The main contributions of this paper are as follows: We present FlowCLIP, a contrastive pretraining framework for learning transferable traffic flow representations. FlowCLIP represents raw domain names as ordered sequences of domain components to reflect their hierarchical structure and aligns side-channel traffic flow representations with domain name representations using a CLIP-style objective. • We define an automated canonicalization procedure for constructing a domain name label space from training data, reducing dependence on manually defined application categories. • We evaluate FlowCLIP under a time-based evaluation protocol and compare it against competitive machine learning baselines, including XGBoost and 1-NN. We analyze accuracy, macro F1, weighted F1, and runtime cost.
•
II. BACKGROUND In this section, we provide background on the Domain Name System and the QUIC protocol. A. Domain Name System Domain Name System provides a standard naming system for identifying hosts and other network resources using domain names [24]. Domain names are written from left to right as dot-separated labels, beginning with the most specific label and ending with the least specific label [24]. B. QUIC QUIC is a transport protocol that provides secure communication over UDP and has been widely adopted since 2021 by major service providers, including Akamai, Amazon, Apple, Cloudflare, Fastly, Google, Meta, and Microsoft [7]. QUIC reduces transmission latency by optimizing connection establishment and loss recovery [6]. Unlike TCP, which requires separate round trips for TCP and TLS handshakes, QUIC combines these procedures into a single round trip [6]. QUIC also mitigates the head-of-line blocking problem inherent in TCP, where packet loss delays the delivery of subsequent data until the missing packet is retransmitted. To address this limitation, QUIC enables multiple independent streams within a single connection, isolating the effects of packet loss to the affected stream while allowing other streams to continue transmitting [6].
III. C HALLENGES IN E NCRYPTED N ETWORK T RAFFIC C LASSIFICATION In this section, we discuss three challenges that affect the development and evaluation of encrypted traffic classification methods: feature representation, evaluation setup, and application labeling. Feature Representation: Features used for traffic classification should reflect generalizable traffic patterns rather than dataset-specific artifacts [14], [25], [26]. For example, models may rely on IP addresses, but these addresses can be tied to specific hosts, services, or content delivery networks at a particular time [14], [25], [27]. Models that depend on dataset artifacts may perform well in controlled settings but degrade in real-world deployments [26]. A similar concern arises for raw packet byte representations. Although raw byte representations may reduce the need for manual feature engineering, they may also encode signals that do not generalize across encrypted sessions or deployment settings. Many packet header fields may contain sessionspecific information, and encrypted payload bytes vary across TLS sessions [9], [14]. In addition, datasets with unencrypted payloads may encourage models to rely on features unavailable in encrypted traffic, while datasets with TLS metadata such as SNI may induce reliance on identifiers that may be unavailable when Encrypted Client Hello (ECH) is enabled [14], [15]. These findings motivate the use of compact side-channel features that are observable under encryption and less tied to dataset-specific identifiers. Evaluation Setup: Some representation learning methods split traffic at the packet level, allowing packets from the same flow to appear in both the training and test sets [13]. Since these methods typically use raw packet bytes as features, the models trained using these methods may rely on flow-specific artifacts that are similar among packets from the same flow but differ across flows [13], [14]. When evaluated with a flow-level split, where all packets from a given flow are assigned either to training or testing, the performance of the models drops substantially [13]. These findings highlight the importance of aligning the evaluation setup with the intended deployment setting, where models must generalize to entirely unseen traffic flows. Furthermore, many widely used datasets are collected in controlled laboratory settings [18]. As a result, even a random flow-level split may place nearly identical samples in both the training and test sets, making the classification task easier than it would be in deployment [18]. This highlights the need to evaluate classification models on heterogeneous traffic that reflects realistic deployment conditions. Application Labels: Network traffic datasets require accurate ground truth labels because incorrect or inconsistent labels may introduce bias during training [25]. Many encrypted traffic datasets use SNI domain names as a basis for assigning traffic labels [11], [12], [14], [16]. However, defining application categories is challenging because there is no standard procedure for mapping domain names to applications. As a
result, annotators may rely on different heuristics or levels of granularity. For example, YouTube traffic may involve several related domains and subdomains, including music.youtube.com, img.youtube.com, and googlevideo.com. Although these domains are related to the YouTube platform, they do not necessarily correspond to the same service function. One annotator may group them under a broad label such as “YouTube” or “Video Streaming,” while another may assign finer-grained labels that distinguish music delivery, image hosting, and video content distribution. Since both approaches may be reasonable in the absence of a standard labeling procedure, application categories may differ across datasets. These challenges motivate labeling procedures that reduce dependence on manually defined application categories. IV. M ETHOD In this section, we define the problem, describe the dataset and data preparation procedure, and present the FlowCLIP architecture and training objective. A. Problem Definition We analyze network traffic at the bidirectional flow level. A bidirectional flow consists of packets exchanged between two endpoints and is grouped using the forward and reverse 5-tuples (source IP address, destination IP address, source port, destination port, and transport protocol). Let X = {x1 , x2 , . . . , xN } denote a dataset of N flows, where each flow xi is associated with a raw domain name si . The objective of FlowCLIP is to learn a flow-level traffic encoder that produces transferable representations for downstream traffic classification tasks. During contrastive pretraining, FlowCLIP uses raw domain names as textual supervision by aligning each traffic flow xi with its corresponding domain name si . We evaluate the learned traffic representations through domain name prediction using canonicalized domain name labels. B. Dataset We first discuss limitations of commonly used application classification datasets, then describe the dataset used in this study. Two popular datasets are ISCXVPN2016 and CSTNETTLS1.3 [10], [28]. ISCXVPN2016 contains traffic from six application types over regular and VPN connections, but it may not reflect modern encrypted traffic because it was released in 2016 and 98.9% of its traffic is unencrypted [14]. CSTNETTLS1.3 categorizes traffic into 120 website classes using SNIbased labels [10]. However, the dataset includes only TCP flows, and the SNI domains associated with individual flows are not available in the public dataset [13]. To evaluate FlowCLIP on heterogeneous network traffic, we use CESNET-QUIC22 dataset [16]. The dataset contains approximately 153 million QUIC flows collected over one month, with traffic from each day provided as a separate CSV file. We group the dataset into four weekly periods corresponding to collection Weeks 44–47; for clarity, we refer to these periods as Weeks 1–4 throughout the paper. For
each flow, the dataset records sequential traffic features for up to 30 packets, including packet sizes, inter-arrival times, and directions. Packet sizes are reported in bytes, inter-arrival times are recorded in milliseconds, and directions are encoded as +1 for client-to-server traffic and −1 for server-to-client traffic. Each row also includes SNI domains, human-annotated application labels, and supplementary metadata. C. Data Preparation Feature Representation: We use side-channel features: packet inter-arrival times, packet sizes, and packet directions [12]. Packet direction is encoded using signed packet size, where positive values denote client-to-server packets and negative values denote server-to-client packets. Each flow is represented using up to the first 30 packets, with shorter flows zero-padded. To capture endpoint-specific behavior, we compute direction-aware inter-arrival time, defined as the elapsed time since the previous packet sent in the same direction. For the first packet in a flow, this value is set to 0. Since the dataset reports inter-arrival time relative to the immediately preceding packet, we compute direction-aware inter-arrival time by accumulating the inter-arrival times of intervening packets traveling in the opposite direction. This avoids measuring timing gaps between packets sent in opposite directions, which may belong to different QUIC streams.1 Domain Name Labels: We use domain names as labels to reduce dependence on manually mapping traffic into application categories. However, domain name labels are long-tailed and may contain instance-specific identifiers that inflate the number of distinct labels [4], [29]. To address these challenges, we construct a label space using an automated procedure based on Week 1 data. Each domain name is decomposed into dot-separated components. For example, mail.google.com is decomposed into mail, google, and com. Components that appear at least twice in Week 1 are retained, while components that appear only once are treated as out-of-vocabulary.2 Each domain name is then canonicalized by replacing out-of-vocabulary components with <unk>. We retain the most frequent canonicalized domain names accounting for 99% of Week 1 traffic and map the remaining tail labels to an “other” class. This yields 1,914 retained canonicalized domain name classes plus the “other” class, resulting in 1,915 classes. The Week 1 train-validation split is performed after canonicalization and tail-label mapping using a stratified 90%/10% split. The same split is used for contrastive pretraining and linear probing: pretraining uses the raw domain names associated with the selected flows, while linear probing uses the corresponding canonicalized labels. For Weeks 2–4, domain names are canonicalized using the Week 1 component vocabulary, 1 A single QUIC connection may carry multiple concurrent streams. 2 The procedure uses frequency-based component filtering rather than semantic canonicalization rules; repeated instance-specific components may therefore remain if they occur more than once in Week 1.
and labels outside the retained Week 1 label set are mapped to “other”. D. FlowCLIP Architecture FlowCLIP consists of a traffic encoder and a domain name text encoder for contrastive pretraining. The traffic encoder is a Transformer encoder with self-attention and padding masks to ignore zero-padded positions [30]. It takes side-channel features as input and mean-pools encoder outputs over nonpadded positions to produce a flow-level representation. The domain name text encoder represents each raw domain name as an ordered sequence of domain components. Components are ordered from top-level domain to subdomain; for example, mail.google.com is represented as [com, google, mail]. Each component is mapped to a learnable component embedding shared across all occurrences of that component, and a learnable positional embedding indicates its location in the domain hierarchy. The resulting component representations are mean-pooled over non-padded positions to produce a domain name representation with the same dimensionality as the traffic flow representation. E. Training FlowCLIP is trained in two stages: contrastive pretraining and linear probing. Contrastive Pretraining: During pretraining, FlowCLIP aligns traffic flow embeddings with raw domain name embeddings. Let zix denote the normalized traffic embedding for flow xi , and let zis denote the normalized text embedding for its raw domain name si . Given a minibatch of matched traffic flows and domain names, pairwise similarities are computed using a temperature-scaled dot product: (zix )⊤ zjs , τ where τ is the temperature parameter. Following CLIP [22], the model is optimized using a symmetric cross-entropy loss over the similarity scores in both directions: from traffic flows to domain names and from domain names to traffic flows. Linear Probing: After contrastive pretraining, the traffic encoder is frozen and can be paired with a linear classification head for a chosen downstream label space. In this work, we train the linear head for domain name prediction using crossentropy loss over canonicalized domain name labels. ℓij =
V. E XPERIMENT This section evaluates FlowCLIP under a time-based protocol and compares it with machine learning baselines and ablated model variants. A. Experimental Setup We use a time-based evaluation protocol inspired by [19]. Week 1 is used for training and validation, and final evaluation is performed on Weeks 2–4. The train-validation split uses a fixed split seed of 42, and all models are trained using seed 0. We compare FlowCLIP against 1-NN and XGBoost. Table I summarizes the FlowCLIP hyperparameters.
TABLE I T HE TRAFFIC ENCODER CONFIGURATION . Category
Hyperparameter
Value
Architecture
dmodel / heads / layers FFN dimension / dropout
256 / 4 / 4 1024 / 0.1
Optimization
Batch size / learning rate Weight decay Contrastive temperature
1024 / 3 × 10−4 0.01 0.07
Training
Pretraining: epochs Linear probing: epochs
50 50
For FlowCLIP, both contrastive pretraining and linear probing use early stopping with patience 10, and the checkpoint with the best validation loss is restored for evaluation. For both baselines, each fixed-length input sequence is flattened into a vector before training. For 1-NN, we z-score normalize the flattened vectors using statistics computed from the Week 1 training data and perform one-nearest-neighbor search with Manhattan distance following [18]. For XGBoost, we use a multiclass softmax objective with histogram-based tree construction, following prior encrypted traffic classification work [9]. We apply early stopping with a patience of 10 validation rounds and select the best boosting iteration based on validation performance. We used PyTorch for Transformer-based models, FAISS for 1-NN, and the XGBoost library for XGBoost. Transformerbased and 1-NN experiments used one NVIDIA A6000 GPU and 8 CPU cores. XGBoost was run on 8 CPU cores.3 Evaluation Metrics: We report accuracy, weighted F1, and macro F1. Accuracy measures the overall fraction of correct predictions. Weighted F1 averages per-class F1 scores according to class frequency, while macro F1 averages per-class F1 scores uniformly across classes. B. Results Table II reports performance on Weeks 2–4, corresponding to 42.6M, 33.8M, and 44.2M evaluation samples, respectively. FlowCLIP consistently outperforms 1-NN and XGBoost across all three weeks on accuracy, weighted F1, and macro F1. Table III reports training time and inference latency. For 1-NN, training time corresponds to FAISS index construction, while FlowCLIP training time includes both contrastive pretraining and linear probing. Under our experimental setup, FlowCLIP requires the highest training time. XGBoost has the lowest inference latency even when run on CPU, while 1-NN has the highest inference latency. C. Ablation Study We conduct two ablation studies to examine the contribution of contrastive pretraining and the effect of the classification head. First, we compare FlowCLIP with a supervised Transformer classifier that uses the same traffic encoder architecture, mean-pooled flow representation, and linear classification 3 XGBoost was run on CPU because GPU execution exceeded the available GPU memory in our experimental environment.
TABLE II P ERFORMANCE COMPARISON ACROSS W EEKS 2–4. A LL METRICS ARE REPORTED AS PERCENTAGES .
Week
Model
Acc.
W-F1
M-F1
Week 2
1-NN XGBoost FlowCLIP
71.17 50.17 81.38
71.42 48.59 82.98
27.56 7.19 44.91
Week 3
1-NN XGBoost FlowCLIP
69.11 42.81 70.30
69.73 41.78 73.28
26.27 6.59 40.35
Week 4
1-NN XGBoost FlowCLIP
68.19 42.30 69.55
68.81 41.26 72.54
25.14 6.31 39.15
Table IV shows that the supervised Transformer achieves the highest macro F1 across all three weeks, indicating better performance on less frequent classes. FlowCLIP with a linear head improves accuracy and weighted F1 over the supervised Transformer. FlowCLIP with MLP head yields the best accuracy and weighted F1 across all weeks and achieves comparable macro F1 to the supervised Transformer. These results suggest that contrastive pretraining improves representations for common domain name classes, while a nonlinear head more effectively maps the pretrained FlowCLIP representations to downstream labels than linear head. VI. D ISCUSSION
TABLE III RUNTIME COMPARISON . T RAINING TIME IS REPORTED IN SECONDS , AND INFERENCE LATENCY IS REPORTED IN MILLISECONDS PER SAMPLE .
Model
Week
Training Time
Inference Latency
1-NN
Week 2 Week 3 Week 4
0.30
1.002 1.000 1.000
XGBoost
Week 2 Week 3 Week 4
9501.75
0.007 0.006 0.008
FlowCLIP
Week 2 Week 3 Week 4
121127.13
0.030 0.030 0.030
head, but is trained directly with cross-entropy loss on canonicalized domain name labels. This architecture-controlled comparison isolates the effect of the training objective, allowing us to evaluate whether contrastive pretraining improves the learned traffic representations beyond direct supervised training. Second, we evaluate a FlowCLIP variant with a two-layer multilayer perceptron (MLP) classification head instead of a linear head. The MLP head has a hidden dimension of 256 and uses GELU activation with dropout 0.1 between the two linear layers. This comparison evaluates whether the pretrained representations benefit from a nonlinear head. TABLE IV A BLATION STUDY ON W EEKS 2–4. A LL METRICS ARE REPORTED AS PERCENTAGES .
Week
Model
Acc.
W-F1
M-F1
Week 2
Transformer FlowCLIP + Linear Head FlowCLIP + MLP Head
80.84 81.38 82.87
82.50 82.98 84.09
50.93 44.91 49.80
Week 3
Transformer FlowCLIP + Linear Head FlowCLIP + MLP Head
69.30 70.30 73.16
72.68 73.28 75.46
45.84 40.35 44.53
Week 4
Transformer FlowCLIP + Linear Head FlowCLIP + MLP Head
68.10 69.55 72.30
71.65 72.54 74.68
44.30 39.15 43.20
The experimental results provide several insights into encrypted traffic classification under realistic deployment conditions. Across all three models, performance decreases from Week 2 to later weeks, highlighting the impact of temporal distribution shift. Moreover, macro F1 remains substantially lower than accuracy and weighted F1, suggesting that rare classes remain challenging to classify. The baseline results provide additional insight. XGBoost underperforms in our evaluation. Notably, the first boosting round was selected as the best iteration during training despite an early stopping patience of 10 rounds, suggesting that additional boosting stages did not improve validation performance. One possible explanation is that the large and sparse label space considered in this study limits the effectiveness of standard multiclass XGBoost in this setting. Therefore, the observed performance may be specific to the characteristics of this classification task. XGBoost may still be effective for encrypted traffic classification problems involving coarser application labels. The 1-NN baseline also provides an informative comparison. Despite its simplicity, 1-NN remains competitive during the later evaluation periods, with Week 3 and Week 4 accuracy and weighted F1 scores comparable to FlowCLIP. However, this competitive performance comes at the cost of notably higher inference latency, since each prediction requires a nearest-neighbor search over the training set. Therefore, reducing the search space effectively may be a useful direction for future work. Beyond these performance results, FlowCLIP offers an additional advantage: the learned traffic encoder is not inherently tied to the canonicalized domain name label space used in our evaluation. Since contrastive pretraining uses raw domain names as textual supervision instead of predefined classes, the same encoder can be paired with a new linear head for different label spaces. This is advantageous when different deployments require varying levels of label granularity. A. Limitations This study has several limitations. First, the automated canonicalization procedure reduces dependence on manually defined application categories, but it does not semantically merge all instance-specific domain components. A stricter canonicalization procedure could incorporate human-defined
rules to further merge instance-specific identifiers such as shard labels. However, such extensions would introduce a tradeoff between reducing label sparsity and increasing dependence on manual design choices. Second, FlowCLIP improves performance over the evaluated baselines, but performance still decreases on later weeks, indicating that static contrastive pretraining does not fully address changes in traffic patterns over time. Future work could incorporate FlowCLIP into continual learning frameworks to effectively handle temporal drift. VII. C ONCLUSION We introduced FlowCLIP, a contrastive pretraining framework that uses raw domain names as textual supervision for encrypted traffic representation learning. FlowCLIP aligns side-channel traffic flow representations with raw domain name representations and then evaluates the frozen traffic encoder through linear probing on canonicalized domain name labels. FlowCLIP consistently outperforms XGBoost and 1NN across Weeks 2–4, demonstrating that textual supervision from raw domain names improves flow-level representations under temporal distribution shift. R EFERENCES [1] T. Wang, X. Cai, R. Nithyanand, R. Johnson, and I. Goldberg, “Effective attacks and provable defenses for website fingerprinting,” in 23rd USENIX Security Symposium (USENIX Security 14). San Diego, CA: USENIX Association, Aug. 2014, pp. 143–157. [Online]. Available: https://www.usenix.org/conference/ usenixsecurity14/technical-sessions/presentation/wang tao [2] S. Kumar, S. Gupta, and S. Arora, “Research trends in networkbased intrusion detection systems: A review,” IEEE Access, vol. 9, pp. 157 761–157 779, 2021. [3] E. Papadogiannaki and S. Ioannidis, “A Survey on Encrypted Network Traffic Analysis Applications, Techniques, and Countermeasures,” ACM Comput. Surv., vol. 54, no. 6, pp. 123:1–123:35, Jul. 2021. [Online]. Available: https://dl.acm.org/doi/10.1145/3457904 [4] M. Trevisan, F. Soro, M. Mellia, I. Drago, and R. Morla, “Does domain name encryption increase users’ privacy?” ACM SIGCOMM Computer Communication Review, vol. 50, no. 3, pp. 16–22, Jul. 2020. [Online]. Available: https://dl.acm.org/doi/10.1145/3411740.3411743 [5] E. Rescorla, K. Oku, N. Sullivan, and C. A. Wood, “TLS Encrypted Client Hello,” RFC 9849, Mar. 2026. [Online]. Available: https://www.rfc-editor.org/info/rfc9849 [6] A. Langley, A. Riddoch, A. Wilk, A. Vicente, C. Krasic, D. Zhang, F. Yang, F. Kouranov, I. Swett, J. Iyengar, J. Bailey, J. Dorfman, J. Roskind, J. Kulik, P. Westin, R. Tenneti, R. Shade, R. Hamilton, V. Vasiliev, W.-T. Chang, and Z. Shi, “The QUIC Transport Protocol: Design and Internet-Scale Deployment,” in Proceedings of the Conference of the ACM Special Interest Group on Data Communication. Los Angeles CA USA: ACM, Aug. 2017, pp. 183–196. [Online]. Available: https://dl.acm.org/doi/10.1145/3098822.3098842 [7] J. Mücke, M. Nawrocki, R. Hiesgen, P. Sattler, J. Zirngibl, G. Carle, J. Luxemburk, T. C. Schmidt, and M. Wählisch, “Waiting for QUIC: Passive Measurements to Understand QUIC Deployments,” Proc. ACM Netw., vol. 3, no. CoNEXT4, pp. 41:1–41:26, Nov. 2025. [Online]. Available: https://dl.acm.org/doi/10.1145/3768988 [8] M. Kühlewind and B. Trammell, “Manageability of the QUIC Transport Protocol,” RFC 9312, Sep. 2022. [Online]. Available: https://www.rfc-editor.org/info/rfc9312 [9] N. Wickramasinghe, A. Shaghaghi, E. Ferrari, and S. Jha, “Less is More: Simplifying Network Traffic Classification Leveraging RFCs,” in Companion Proceedings of the ACM on Web Conference 2025, ser. WWW ’25. New York, NY, USA: Association for Computing Machinery, May 2025, pp. 1398–1401. [Online]. Available: https://dl.acm.org/doi/10.1145/3701716.3715492
[10] X. Lin, G. Xiong, G. Gou, Z. Li, J. Shi, and J. Yu, “Et-bert: A contextualized datagram representation with pre-training transformers for encrypted traffic classification,” in Proceedings of the ACM Web Conference 2022, ser. WWW ’22. ACM, Apr. 2022, p. 633–642. [Online]. Available: http://dx.doi.org/10.1145/3485447.3512217 [11] J. Luxemburk and T. Čejka, “Fine-grained tls services classification with reject option,” Computer Networks, vol. 220, p. 109467, Jan. 2023. [Online]. Available: http://dx.doi.org/10.1016/j.comnet.2022.109467 [12] I. Akbari, M. A. Salahuddin, L. Aniva, N. Limam, R. Boutaba, B. Mathieu, S. Moteau, and S. Tuffin, “Traffic classification in an increasingly encrypted web,” Commun. ACM, vol. 65, no. 10, p. 75–83, Sep. 2022. [Online]. Available: https://doi.org/10.1145/3559439 [13] Y. Zhao, G. Dettori, M. Boffa, L. Vassio, and M. Mellia, “The Sweet Danger of Sugar: Debunking Representation Learning for Encrypted Traffic Classification,” in Proceedings of the ACM SIGCOMM 2025 Conference, ser. SIGCOMM ’25. New York, NY, USA: Association for Computing Machinery, Aug. 2025, pp. 296–310. [Online]. Available: https://dl.acm.org/doi/10.1145/3718958.3750498 [14] N. Wickramasinghe, A. Shaghaghi, G. Tsudik, and S. Jha, “SoK: Decoding the Enigma of Encrypted Network Traffic Classifiers,” in 2025 IEEE Symposium on Security and Privacy (SP), May 2025, pp. 1825–1843. [Online]. Available: https://ieeexplore.ieee.org/abstract/ document/11023502 [15] R. Beltiukov, S. Guthula, W. Guo, W. Willinger, and A. Gupta, “Demystifying network foundation models,” Advances in neural information processing systems (NeurIPS), 2025. [16] J. Luxemburk, K. Hynek, T. Čejka, A. Lukačovič, and P. Šiška, “CESNET-QUIC22: A large one-month QUIC network traffic dataset from backbone lines,” Data in Brief, vol. 46, p. 108888, Feb. 2023. [Online]. Available: https://linkinghub.elsevier.com/retrieve/pii/ S2352340923000069 [17] M. Geva, Y. Goldberg, and J. Berant, “Are We Modeling the Task or the Annotator? An Investigation of Annotator Bias in Natural Language Understanding Datasets,” in Proceedings of the 2019 Conference on Empirical Methods in Natural Language Processing and the 9th International Joint Conference on Natural Language Processing (EMNLP-IJCNLP), K. Inui, J. Jiang, V. Ng, and X. Wan, Eds. Hong Kong, China: Association for Computational Linguistics, Nov. 2019, pp. 1161–1166. [Online]. Available: https://aclanthology.org/D19-1107/ [18] J. Pesek, J. Luxemburk, and K. Hynek, “Lightweight Traffic Classification: A Simple Baseline Matching Deep Learning Performance,” in 2025 9th Network Traffic Measurement and Analysis Conference (TMA), Jun. 2025, pp. 1–4. [Online]. Available: https://ieeexplore.ieee.org/document/11096965 [19] K. Jerabek, J. Luxemburk, R. Plny, J. Koumar, J. Pesek, and K. Hynek, “When simple model just works: Is network traffic classification in crisis?” 2025. [Online]. Available: https://arxiv.org/abs/2506.08655 [20] T. Chen and C. Guestrin, “Xgboost: A scalable tree boosting system,” in Proceedings of the 22nd ACM SIGKDD International Conference on Knowledge Discovery and Data Mining, ser. KDD ’16. ACM, Aug. 2016, p. 785–794. [Online]. Available: http: //dx.doi.org/10.1145/2939672.2939785 [21] T. Cover and P. Hart, “Nearest neighbor pattern classification,” IEEE Trans. Inf. Theor., vol. 13, no. 1, p. 21–27, Sep. 2006. [Online]. Available: https://doi.org/10.1109/TIT.1967.1053964 [22] A. Radford, J. W. Kim, C. Hallacy, A. Ramesh, G. Goh, S. Agarwal, G. Sastry, A. Askell, P. Mishkin, J. Clark, G. Krueger, and I. Sutskever, “Learning transferable visual models from natural language supervision,” in Proceedings of the 38th International Conference on Machine Learning, ser. Proceedings of Machine Learning Research, M. Meila and T. Zhang, Eds., vol. 139. PMLR, 18–24 Jul 2021, pp. 8748–8763. [Online]. Available: https://proceedings.mlr.press/v139/radford21a.html [23] J. Mücke, M. Nawrocki, R. Hiesgen, P. Sattler, J. Zirngibl, G. Carle, J. Luxemburk, T. C. Schmidt, and M. Wählisch, “Waiting for quic: Passive measurements to understand quic deployments,” Proceedings of the ACM on Networking, vol. 3, no. CoNEXT4, p. 1–26, Nov. 2025. [Online]. Available: http://dx.doi.org/10.1145/3768988 [24] P. Mockapetris, “Domain Names - Concepts and Facilities,” RFC 1034, Nov. 1987. [Online]. Available: https://www.rfc-editor.org/info/rfc1034 [25] D. Arp, E. Quiring, F. Pendlebury, A. Warnecke, F. Pierazzi, C. Wressnegger, L. Cavallaro, and K. Rieck, “Dos and don’ts of machine learning in computer security,” in 31st USENIX Security Symposium (USENIX Security 22). Boston, MA: USENIX
Association, Aug. 2022, pp. 3971–3988. [Online]. Available: https: //www.usenix.org/conference/usenixsecurity22/presentation/arp [26] A. S. Jacobs, R. Beltiukov, W. Willinger, R. A. Ferreira, A. Gupta, and L. Z. Granville, “Ai/ml for network security: The emperor has no clothes,” in Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’22. New York, NY, USA: Association for Computing Machinery, 2022, p. 1537–1551. [Online]. Available: https://doi.org/10.1145/3548606.3560609 [27] V. F. Taylor, R. Spolaor, M. Conti, and I. Martinovic, “AppScanner: Automatic Fingerprinting of Smartphone Apps from Encrypted Network Traffic,” in 2016 IEEE European Symposium on Security and Privacy (EuroS&P). Saarbrucken: IEEE, Mar. 2016, pp. 439–454. [Online]. Available: http://ieeexplore.ieee.org/document/7467370/ [28] A. Habibi Lashkari, G. Draper Gil, M. Mamun, and A. Ghorbani, “Characterization of encrypted and vpn traffic using time-related features,” 02 2016. [29] J. Luxemburk, K. Hynek, R. Plný, and T. Čejka, “Universal embedding function for traffic classification via quic domain recognition pretraining: A transfer learning success,” IEEE Transactions on Network and Service Management, vol. 23, p. 1647–1663, 2026. [Online]. Available: http://dx.doi.org/10.1109/TNSM.2025.3642984 [30] A. Vaswani, N. Shazeer, N. Parmar, J. Uszkoreit, L. Jones, A. N. Gomez, L. Kaiser, and I. Polosukhin, “Attention is All you Need,” in Advances in Neural Information Processing Systems, I. Guyon, U. V. Luxburg, S. Bengio, H. Wallach, R. Fergus, S. Vishwanathan, and R. Garnett, Eds., vol. 30. Curran Associates, Inc., 2017. [Online]. Available: https://proceedings.neurips.cc/paper files/paper/2017/file/3f5ee243547dee91fbd053c1c4a845aa-Paper.pdf