Network: Part 9. Traffic Analysis

From theory to observable reality

Modern information systems are so dependent on the network that any problem with them sooner or later runs into one and the same question: what is really happening in the wires and the air between the components. An engineer may know in detail how the protocols are built, how congestion control works, and how a handshake differs from a connection termination, but this knowledge remains bookish until he opens a real dump and sees in it the living behavior of the system — with all its delays, losses, anomalies, and attacks. Traffic analysis is the process of studying network packets and flows in order to understand what is happening in the network, where the problem is located, and who or what caused it. It is not a separate tool and not a separate chapter of a textbook, but the practical application of all the levels of the network model — from the data link to the application level — to real data.

The key transition that distinguishes the practitioner from the theorist is formulated simply: from the statement "I know how TCP works" to the skill "I can see in a dump why TCP is slowing down." This transition turns traffic analysis from an auxiliary procedure into an independent engineering discipline, which today is applied by network engineers, performance engineers, site reliability engineers (SRE), and security analysts. The discipline has its own object of study (the packet, the flow, the behavior of the system under load), its own toolkit (analyzers, probes, telemetry), its own methods (correlation of events, localization by symptom, visualization), and its own history, going back to the era of radio communication.

Like any mature field, traffic analysis gives rise to a series of through-cutting questions that define both everyday practice and the development of technologies:

1. The diagnostic question. Where does the boundary run between "the network is to blame" and "the application is to blame"? The overwhelming majority of production disputes about the causes of a failure come down to different teams seeing different parts of one picture. Only end-to-end observation of the traffic — from client to server and back — allows localizing the problem at a specific level and in a specific node.
2. The performance question. Why can a formally "healthy" network, in which there are no packet losses, give a poor user experience? The answers include buffer bloat (bufferbloat), tail latency, head-of-line blocking, and the cost of encryption — phenomena that are not visible in average figures and require the analysis of distributions and time series.
3. The encryption question. What remains analyzable when most of the traffic is closed by cryptography? As it turns out, very much: metadata, timing characteristics, packet sizes, handshake parameters, and client fingerprints. Traffic analysis is not reading data, but analyzing behavior, and the encryption of the content does not cancel it, but changes its subject.
4. The security question. How to recognize an attack in the traffic — from the classic SYN flood and port scanning to slow application attacks, reflected DDoS of record power, and hidden channels of data exfiltration? Most attacks leave protocol traces long before the protection systems notice them, and the ability to read these traces remains a basic skill of the analyst.
5. The methodological question. How to turn reading packets from the art of individual experts into a reproducible engineering process? The answer lies in the domain of correlation: linking packet dumps with flow telemetry, metrics, distributed traces, and application logs into a single observability system.

Next, this article examines traffic analysis sequentially: the historical context and the object of analysis, the analyst's toolkit, the behavior of TCP in real traffic including congestion control and its modern algorithms, the application level — HTTP, DNS, TLS, and the new transports, the classic network problems and their recognizable patterns, quality metrics, the connection of analysis with security, the methodology of diagnostics, and, finally, the peculiarities of analysis in modern architectures — software-defined networks, overlays, and clouds.

From the radio air to packets: a brief history of traffic analysis

Traffic analysis before the appearance of packets

The very term "traffic analysis" came into network engineering from radio intelligence and is significantly older than computer networks. Back in the First World War, the warring sides discovered that even without decrypting the enemy's messages, one could extract the most valuable information from the very fact of their transmission: who transmits to whom, when, and how much. A sharp activation of radio transmissions in a sector of the front foreshadowed an offensive; a change of call signs and communication schedules gave away the movement of units. In the Second World War this practice reached maturity: the analysis of the volumes and routes of radio exchange supplemented the work of the codebreakers, and sometimes replaced it when the ciphers did not yield to breaking. The fundamental principle — "metadata speaks no less than the content" — was formulated long before the appearance of the Internet.

The civilian analog of military traffic analysis became the data about telephone connections (call detail records, CDR). Communication operators from the very beginning recorded who called whom, when, and for how long — for billing. It is precisely these records, not the wiretapping of conversations, that historically formed the basis of the communication intelligence of law enforcement agencies in many countries: judicial requests for connection details outnumber by orders of magnitude the requests to intercept the content of conversations, since they are cheaper, more massive, and legally simpler. The criminal world answered with its own defensive traffic analysis: burner phones, frequent changes of SIM cards, deliberate "jamming" with harmless traffic. This race around metadata continues in the era of packet networks too — only instead of telephone bills, the object of observation has become packet flows, connection logs, and telemetry.

The ARPANET era and the birth of the utilities

With the appearance of packet networks, traffic analysis gradually turned from an intelligence practice into an engineering one. The turning point occurred in the 1980s, when researchers began building utilities that became classics. In December 1983, Mike Muuss, working at the US Army research laboratory (BRL), wrote the ping program — a probe sending ICMP echo messages and measuring the response time. The name referred to the echo of a sonar; the utility itself became the first mass tool for checking the "liveness" of a node and to this day remains the starting point of any diagnostics.

In 1987–1988, Van Jacobson of the Lawrence Berkeley National Laboratory (LBNL) created traceroute — a utility that reconstructs the route of packets by successively increasing the TTL field and analyzing the ICMP "time exceeded" responses. By some accounts, the idea of the method had been discussed earlier by Steve Deering, but the working implementation and its spread are connected precisely with Jacobson. Route tracing with the measurement of delays at every hop allowed, for the first time, "seeing" the internet as a sequence of nodes, not as an abstract cloud.

There too, at LBNL, in the second half of the 1980s, Jacobson together with Craig Leres and Steven McCanne began work on tcpdump — a packet capture and decoding utility. Its key innovation was the filtering mechanism in the kernel: in 1993, McCanne and Jacobson published the work on the BSD Packet Filter (BPF), a virtual machine executing filtering programs directly in the operating system kernel. This solved the main problem of early capture — the necessity of copying every single packet into user space. BPF became the foundation of the libpcap library and, essentially, of the whole modern ecosystem of sniffers: the filter language of tcpdump is to this day the de facto standard for setting capture conditions.

It is telling that traffic analysis and the improvement of protocols developed jointly. In the mid-1980s the internet encountered the phenomenon that received the name "congestion collapse": as the load grew, the throughput of the backbones fell by orders of magnitude because of avalanche-like retransmissions. It was precisely observations of the real traffic that led Jacobson in 1988 to create the TCP congestion control algorithms — slow start and congestion avoidance — which literally saved the internet from paralysis. Since then the cycle "measurement — understanding — change of the protocol" has repeated itself more than once: traffic analysis was not an observer, but the engine of the evolution of networks.

Graphical analyzers and intrusion detection systems

In the 1990s, analysis went beyond the console utilities. In the middle of the decade, Vern Paxson (also from LBNL) developed Bro — an intrusion detection system of a new type, which instead of comparing bytes with signatures built an event model of the network's behavior: a scripting language allowed describing the security policy at the level of "events" (connection establishment, DNS request, HTTP session). In 2018–2019 the project was renamed Zeek and remains one of the two main open platforms for network security monitoring. In 1998, Marty Roesch released Snort — a lightweight signature traffic analyzer, which became the basis of a whole class of open network intrusion detection systems (NIDS); later the project was acquired by Sourcefire, and then by Cisco, but the Snort rules are still used everywhere, including by the multithreaded "heir" Suricata, developed by the OISF community since 2009–2010.

In parallel, graphical analyzers developed. At the end of 1997, Gerald Combs, who needed a tool for finding network problems and at the same time wanted to study networks more deeply, began writing Ethereal; the first public release took place in July 1998. The project grew together with the internet: protocol dissectors were added, a display filter system, statistics, and graphs. In May 2006, because of trademark problems, the project was renamed Wireshark — under this name it became the undisputed standard of interactive packet analysis, supporting hundreds of protocols and working on all the major platforms. The console sibling tshark allowed embedding the same decoding engine into automated processing pipelines.

From dumps to telemetry and programmable analysis

Capturing every packet (full packet capture) gives maximum detail, but scales poorly: the dump of a backbone channel for a day is measured in terabytes. Therefore, since the mid-1990s, a parallel approach developed — aggregated telemetry. In 1996, Cisco introduced NetFlow — the export of information about flows (who exchanged data with whom, in what volume) instead of the packets themselves; version 9 (2003–2004) made the format templatable, and in 2013 the IETF standardized its successor IPFIX (RFC 7011). An alternative became sFlow (RFC 3176, 2001), combining statistical sampling of packets with port counters. Flow telemetry sacrificed detail for the ability to store the picture of the network for months and search for anomalies in it.

The next shift was brought by programmability. In 2014, Alexei Starovoitov radically reworked the BPF mechanism, turning it into eBPF — a full-fledged virtual machine in the Linux kernel, allowing safe execution of user programs at kernel tracepoints. On the basis of eBPF grew tools that extract TCP events (connection establishment and lifetime, retransmissions, window changes) directly from the kernel — without packet capture at all, with minimal overhead. Projects like Cilium and Hubble transferred this approach into container environments. At the same time, for the tasks of high-speed capture, kernel bypass mechanisms appeared: DPDK, PF_RING, later AF_XDP — they allow processing flows of 10–100 Gbit/s, which are beyond the reach of the classic stack.

The result of this evolution is the modern observability pyramid: metrics and flows give a constant picture and serve as a trigger, while full packet capture is applied pointwise, for collecting evidence and detailed examination. Understanding which layer of the pyramid answers which question is part of the methodology of analysis, to which we will return in the corresponding section.

The object of analysis: the packet, the flow, and behavior

Encapsulation: reading from the outside in

Any analysis begins with understanding exactly what lands in the dump. A packet in a network is a construction of nested headers:

Ethernet frame → IP packet → TCP/UDP segment → Application data

Each level of the model adds its header when sending and removes it when receiving; the analyst reads them from the outside in. The data link frame carries the MAC addresses of the neighbors in the segment and, possibly, a VLAN tag; the IP header — the end addresses and the routing parameters; the transport segment — the ports, flags, and numbers; and only inside is the payload of the application protocol — an HTTP request, a DNS message, or an encrypted TLS record. In tunneled environments there are more levels of nesting: a VXLAN or IPsec packet contains inside a full-fledged inner IP packet, and analyzers know how to unpack such "matryoshkas," but the analyst must always understand precisely at which level of nesting he is.

What is visible at each level

Each layer of headers answers its own questions, and an experienced analyst extracts the maximum from them even before looking at the payload:

• Data link level (L2). The MAC addresses of the source and the recipient, VLAN tags (802.1Q), the service protocols of the segment — ARP, NDP. These fields rarely participate in the diagnostics of internet traffic, but are irreplaceable inside a local network: they show who actually exchanges frames with whom, and allow detecting address substitution.
• Network level (L3). The IP addresses of the source and the recipient, the TTL field, the fragmentation flags and offsets, the DSCP field. TTL is decreased by one at the passage of every router, so by its value in the received packet one can roughly estimate the distance to the sender and the operating system of the stack (different implementations choose different initial values — 64, 128, 255). An anomalous TTL in the middle of a connection is a sign of the intervention of an intermediate device: a NAT, a proxy, a balancer, or a filtering system.
• Transport level (L4). The ports, the TCP flags, the sequence numbers and the acknowledgment numbers, the window size, the connection parameters — MSS, SACK, timestamps, window scaling. This is the most informative layer for performance diagnostics: almost all classic network problems — losses, congestion, exhaustion of buffers — manifest themselves precisely here.
• Application level (L7). The methods and response codes of HTTP, the requests and responses of DNS, the handshake messages of TLS, the commands of the mail protocols. The application layer answers the question "what were they doing," but its analysis is possible only where the traffic is not encrypted or where the analyst has legitimate keys.

The anatomy of one packet: reading byte by byte

It is useful once to take apart a packet literally byte by byte — after that the structure is reproduced from memory. An Ethernet II frame: 6 bytes of the destination MAC address, 6 bytes of the source MAC address, 2 bytes of the payload type (0x0800 — IPv4, 0x0806 — ARP, 0x86DD — IPv6); when a VLAN is present, a 4-byte 802.1Q tag is inserted before the type. The IPv4 header begins with the version and length half-bytes (4 and 5), then the DSCP/ECN byte, two bytes of the total length, two bytes of the identifier, the flags and the fragment offset (2 bytes), the TTL byte, the protocol byte (6 — TCP, 17 — UDP, 1 — ICMP), the checksum, and four bytes each of the addresses. The TCP header: the source and destination ports (2 bytes each), the sequence number (4), the acknowledgment number (4), the header offset with the reserved bits and flags (2+2), the window (2), the checksum (2), the urgent pointer (2), and the optional parameters — MSS, SACK, timestamps, window scale. The ability to mentally lay this grid over a hex dump distinguishes the engineer from the user of an analyzer and saves the day in situations when the protocol dissector is absent or mistaken.

Packet versus flow: TCP as a stream of bytes

The fundamental conceptual boundary runs between thinking in "packets" and thinking in "flows." TCP is not a sequence of packets, but a stream of bytes: the application writes bytes into the socket, and the protocol itself decides how to cut them into segments for transmission. The boundaries of the application's writes are not preserved; one segment can contain parts of different HTTP requests, and one request can be smeared over dozens of segments. Analyzers perform the reverse operation — stream reassembly — and commands like "Follow TCP Stream" in Wireshark show precisely the byte stream as the application sees it.

The practical consequence: many anomalies make sense only at the flow level. The reordering of segments, retransmissions, breaks at the boundaries of the receiver's window, pauses caused by packetization algorithms — all this cannot be correctly interpreted by looking at the packets one by one. An engineer who thinks in packets sees "strange packets"; an engineer who thinks in flows sees the behavior of the transport system.

The timeline: the event is more important than the packet

The highest level of abstraction is viewing the traffic as a timeline of events. The analyst looks not at separate packets, but at the sequence "time → event → behavior." The simplest example is the dissection of one web transaction:

0 ms     SYN
50 ms    SYN-ACK
100 ms   ACK
200 ms   HTTP request
500 ms   HTTP response

From these five lines more is extracted than from a hundred packets considered out of context: the round-trip time (RTT) to the server is about 50 ms — this is a characteristic of the network; between receiving the request and the start of the response about 300 ms passed — this is a characteristic of the server and the application. The conclusion "the network is fine, the server is slow" is made in seconds and does not require reading the payload.

That is exactly why traffic analysis is the synthesis of all levels simultaneously. A real transaction looks like an end-to-end chain DNS → TCP → TLS → HTTP → processing on the server, and the analyst's task is to find at which link of the chain the time is lost or the failure occurs. Every level contributes to the total delay and can turn out to be the bottleneck; to mentally "play through" this chain while looking at a dump is precisely what distinguishes a systemic understanding of the network from a simple enumeration of facts about the protocols.

The analyst's toolkit

There are dozens of traffic analysis tools today, but their functions add up into several clear classes: interactive packet analyzers, console capture tools, state and active diagnostics utilities, flow telemetry tools, and programmable analysis platforms. The maturity of a practitioner is determined not by the number of programs mastered, but by the understanding of which class of tool answers which question.

Wireshark and tshark: the interactive standard

Wireshark remains the main tool of interactive analysis. It can capture traffic from interfaces in real time, open saved dumps (pcap, pcapng), decode hundreds of protocols with a full dissection of the fields, apply display filters, perform stream reassembly, and build visualizations. For everyday diagnostics several capabilities are especially useful:

• Expert Info — the built-in system of expert hints, which ranks the noticed anomalies by levels (Note, Warning, Error) and immediately points to retransmissions, zero windows, checksum errors, and other signs of problems. The dissection of an unfamiliar dump often begins with it.
• Display filters — a query language over the unpacked content of the packets. Combinations like tcp.analysis.retransmission, tcp.analysis.zero_window, tcp.analysis.duplicate_ack, dns.time > 1, http.time > 0.5, tls.handshake.type == 1 allow selecting in seconds the events of interest out of hundreds of thousands of packets.
• Follow Stream — viewing the reassembled TCP/UDP/HTTP stream as the application sees it; a fast way to understand the semantics of the exchange without scrolling through segments.
• Statistics and graphs — the protocol hierarchy (Protocol Hierarchy), the lists of connections and nodes (Conversations, Endpoints), the input/output intensity graphs (IO Graph), and the specialized TCP stream graphs: throughput, round-trip time, window size over time. The visual pattern of a problem is often recognized faster than it is found by going through the packets.
• Decrypting TLS with a key file. If the browser, curl, or a Go application is configured to write the session secrets to a file (the environment variable SSLKEYLOGFILE), Wireshark uses it for the full decryption of the TLS traffic. This is the standard legitimate debugging technique for one's own systems, turning "invisible" HTTPS into readable HTTP over an encrypted channel.

The console tshark provides the same decoding engine in a scriptable form: extraction of fields (-T fields -e ip.src -e tcp.len), batch filtering, export to CSV/JSON. Together with the utilities mergecap (merging dumps), editcap (slicing and editing), capinfos (the passport of a dump), and tcpreplay (re-injection of traffic), it forms a full-fledged automated processing pipeline, capable of taking apart a multi-gigabyte dump where the graphical interface would hopelessly hang.

tcpdump and the BPF filter language

Where there is no graphical environment — on servers, routers, in containers, on embedded devices — tcpdump works: console capture with filtering in the kernel through libpcap. Its filter language (the BPF syntax) is more compact and operates at the capture stage, not the display stage, so it is exactly what cuts off the excess before writing to disk:

tcpdump -i eth0 port 80 -w capture.pcap          # all HTTP traffic to a file
tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0'    # all SYN packets (scans, handshakes)
tcpdump -i eth0 host 10.0.0.5 and port 443 -C 100 -W 10   # ring buffer: 10 files of 100 MB

The ring buffer (-C/-W) is standard production practice: the capture runs continuously, the old data is overwritten, and in case of an incident the engineer has at his disposal "the last minutes before the catastrophe." Useful techniques: limiting the length of the captured packet (-s) when only the headers matter, capturing on several interfaces simultaneously, the mandatory writing to a file with subsequent dissection in Wireshark instead of reading the output in the console. Good form is to document the capture conditions: the time, the interface, the filters applied — otherwise the dump loses its evidentiary value.

State and active diagnostics utilities

Packet capture is passive observation; it is accompanied by active and status tools:

• ss (the modern replacement of netstat from the iproute2 package) — an instant snapshot of the state of the sockets: established connections, TCP states, the sizes of the send and receive queues (Send-Q/Recv-Q), the active timers (retransmission, keep-alive, zero-window probe). A non-empty Send-Q on a live connection is a quick sign that the data is "stuck": either the network is not accepting it, or the partner is not acknowledging it. A non-empty Recv-Q — the application is not reading from the socket.
• ping / traceroute / mtr — active probes of delay and route. mtr (1997) combines tracing with multiple polls of each hop, showing the distribution of delays and the percentage of losses along the whole path — often this is enough to localize the problem section at the provider.
• iperf3 — measuring the achievable throughput between two points: TCP and UDP modes, parallel streams, bidirectional tests, a report on jitter and losses for UDP. It allows separating "the network gives no more" from "the application can do no more."
• dig / nslookup — manual DNS requests to specific servers with a full dissection of the response: return codes, flags, TTL, response time. Indispensable when it is necessary to separate a resolving problem from a connection problem.
• curl with the timing output format (-w) — effectively a micro-analyzer of a single HTTP transaction: it breaks down the total time into the phases of DNS, the TCP handshake, the TLS handshake, the time to the first byte (TTFB), and the transfer of the body. One run of curl often replaces a minute of scrolling through a dump.

Where to capture: the observation points

The analyst's conclusions depend on the observation point, and the choice of this point is the first methodological decision. A capture at the client shows the traffic as the user sees it (including all the intermediate delays); a capture at the server — as the application sees it (without the client network); a capture at an intermediate point (a port mirror, a TAP) — the picture of the section between them. In the ideal case, for a complex problem, dumps are taken simultaneously at both ends: the discrepancy between them is precisely the problem.

The ways of organizing an observation point differ in reliability and price:

• Port mirroring (SPAN) on switches — the most accessible way, but with reservations: under load the switch may lose the mirrored packets, the direction is sometimes mirrored asymmetrically, and the very fact of the losses is not always noticeable in the dump.
• Hardware taps (TAP) — passive devices giving a full copy of the traffic in both directions without influencing the channel; the standard for responsible measurements.
• Network packet brokers — aggregate the traffic from several TAP/SPAN, filter, deduplicate, and distribute the copies among the tools (IDS, analyzers); used in large data centers.
• Cloud mirrors — the large providers have their own mechanisms: VPC Traffic Mirroring (AWS), Packet Mirroring (GCP), vTAP (Azure). In container environments the capture is done on the host: the interfaces of veth pairs, connecting to the network namespace of the container through nsenter.
• High-speed capture on channels of 10–100 Gbit/s requires kernel bypass (DPDK, PF_RING, AF_XDP) and specialized storage systems; ordinary tcpdump at such speeds loses packets, and the analyst is obliged to check the loss statistics of the capture itself, so as not to take an artifact of the tool for a property of the network.

Flow telemetry: NetFlow, IPFIX, sFlow

Full capture answers the question "what exactly happened," but does not answer the question "what has been happening in the network for the last three months" — the volume does not allow storing dumps that long. This niche is closed by flow telemetry: routers and hosts export aggregated records about flows — the five-tuple set (the IP addresses and ports of the source and the recipient, the protocol) plus the volumes of bytes and packets, timestamps, routing fields.

NetFlow (Cisco, since 1996; the templatable version 9 — since 2003–2004) and its open successor IPFIX (RFC 7011, 2013) became the standard of de facto collection; sFlow (RFC 3176) complements the picture with statistical sampling of packets and interface counters. On flow data, tasks are solved that are beyond the reach of pcap at network scale: finding anomalies of bandwidth consumption, revealing scans and the lateral movement of an attacker, accounting of traffic by departments, the retrospective answer "who talked to this node before the incident." The practical hierarchy is this: flow telemetry works constantly and serves as a trigger, while full capture is switched on pointwise — for collecting evidence.

Programmable analysis: from Scapy to eBPF

When the ready-made tools are not enough, programmable analysis comes into play. Scapy (Philippe Biondi, since 2003) allows constructing and sending arbitrary packets, assembling one's own probes, and testing the behavior of systems on "wrong" input data — effectively this is a protocol laboratory in Python. Zeek turns traffic into structured event logs (connection.log, dns.log, http.log, ssl.log), on top of which detection scripts are written in its own language — the approach that formed the basis of the modern NDR platforms (Network Detection and Response).

A separate revolution is eBPF. Programs executed in the Linux kernel allow registering the events of the transport stack (creation and closing of connections, retransmissions, window changes, delays in queues) and aggregating them without packet capture, with negligibly small overhead. The tools of the bcc/bpftrace family (tcplife, tcpretrans, tcptop) give instant statistics of the TCP behavior of running processes; Cilium Hubble builds flow maps in Kubernetes clusters. For production, where continuous pcap capture is impossible, eBPF has become the main way to "always see the transport layer."

TCP — the heart of the analysis

TCP accounts for the lion's share of the diagnostic tasks: it is both the main transport of the web and the protocol with the most complex dynamics of behavior. The key to understanding is a change of optics: TCP should be viewed not as an exchange of packets, but as a closed-loop automatic control system, which continuously measures the network (through acknowledgments and losses) and adjusts the transmission rate to it. All the "strange behavior" of TCP — pauses, bursts, collapses of speed — is essentially the work of this control system, and an analyst who knows its logic reads the dump as the protocol of its decisions.

The lifecycle of a connection

Establishing a connection is the three-way handshake:

SYN → SYN-ACK → ACK

Already at this stage the dump gives unambiguous diagnoses. A SYN without any response — the packets are being discarded along the way (a firewall with a drop policy, a routing "black hole," an unreachable host); silence differs from a refusal precisely by the absence of packets. An immediate RST in response to a SYN — the port is closed, or an intermediate device is actively rejecting the connection (a reject policy). A SYN-ACK that reached the server but was not acknowledged — a problem on the return path or at the client. The delay between SYN and SYN-ACK is the "pure" round-trip time to the server, the first measurement of the RTT in every connection.

The TCP flags are the alphabet of analysis:

• SYN — the request to establish a connection, the start of the counting of sequence numbers.
• ACK — the acknowledgment of the received bytes, present in almost every packet of an established connection.
• FIN — the regular closing of a transmission direction; a full teardown of the connection is an exchange of two FIN/ACK pairs.
• RST — an emergency reset: the immediate destruction of the connection without the regular procedures. Who sent the RST (the server on a closed socket, a firewall, a balancer on a timeout, a filtering system) is the key question; the hints are the TTL and the IP identifier, differing from the rest of the connection's traffic.
• PSH — the request for immediate transfer of the data to the application; URG — urgent data. They are encountered less often, but anomalous combinations of flags (FIN only, SYN+FIN, FIN+PSH+URG, the so-called "Xmas" packet, a packet with no flags at all — NULL) practically do not occur in legitimate traffic and are a sign of scanning.

A regular close generates the TIME_WAIT state on the side that sent the FIN first: the socket is held for double the segment lifetime (2×MSL, typically 60–120 seconds), so that late duplicates of old packets do not fall into a new connection with the same port numbers. A multitude of TIME_WAIT states on a balancer or proxy is not a pathology, but a consequence of its work; the pathology is the exhaustion of the local port range in such a scenario, which is treated by configuring socket reuse and keep-alive.

SYN cookies deserve a separate mention — the technique of protection against SYN flood proposed by Dan Bernstein in 1996: the server does not allocate resources for the half-open connection, but encodes all the necessary information in the sequence number of the SYN-ACK, restoring it from the client's ACK. If a SYN flood has nevertheless exhausted the queue of half-open connections, the dump shows retransmissions of SYN-ACK and new SYNs without a response, and on the server — the overflow of the SYN queue in the kernel statistics.

Numbers, acknowledgments, and windows

The sequence number in TCP is not the number of the packet, but the number of the first byte of the segment's payload in the common stream; the acknowledgment number is the number of the byte that the receiver expects next. The cumulative nature of the acknowledgments means: an ACK with the number N acknowledges all bytes up to N−1 inclusive. The ability to read these two fields automatically is a basic skill, without which it is impossible to understand either retransmissions, or ordering, or pauses.

The receive window reports how many bytes the sender has the right to transmit before receiving an acknowledgment — this is flow control, the protection of the receiver from overflow. Since the basic 16-bit window field limited the volume to 64 KB, window scaling was introduced back in 1992 for fast channels with a large delay (RFC 1323, now RFC 7323): the multiplier is negotiated at the handshake, and the window reaches gigabytes. The volume of data "in flight" is limited by the minimum of the receive window and the congestion window (cwnd) — and the diagnostics always begins with the question of which of the two limits is holding back the transmission at the given moment: if the sender has hit the receive window, the problem is at the receiver; if the congestion window — in the network or in its estimation algorithm.

RTT: the measure of the network and its traps

The round-trip time is the central metric of the transport level. In a dump it is measured in several ways: the SYN → SYN-ACK interval (the pure network RTT without the participation of the application), the "data → acknowledgment" intervals by the TCP timestamps (the timestamps option), the built-in estimates of Wireshark. TCP uses the RTT to compute the retransmission timer (RTO) — and here lies a trap: the RTO never drops below hundreds of milliseconds, so the loss of one packet discovered only by the timer costs the connection 200+ ms of downtime even in a network with an RTT of 5 ms.

The fundamental distinction that the analyst must keep in mind: a stable RTT characterizes the network, while the pause between the request and the response characterizes the server. If in a transaction the acknowledgment of the request came after 50 ms, and the response began to be transmitted 300 ms after the request, then the network provided 50 ms, and the application "thought" for 250 ms — and no network optimizations will eliminate this delay.

Losses and retransmissions

Retransmissions are the main signal of a channel's ill health. Wireshark marks them with explicit flags, and there exist different mechanisms that are worth distinguishing:

• Retransmission by timer (RTO) — the acknowledgment did not arrive at all; the most expensive scenario: the connection freezes for hundreds of milliseconds, the congestion window is reset to the minimum.
• Fast retransmit — the receiver sends duplicate acknowledgments (duplicate ACK): every next segment after the lost one provokes a repeated ACK with the same expected number. By the rule of three duplicates (RFC 5681), the sender repeats the segment without waiting for the timer and reduces the speed more gently. A sequence of identical ACKs in the dump is a direct signal "a segment was lost here."
• SACK — selective acknowledgments (RFC 2018, 1996): the receiver reports which blocks of bytes have already been received, allowing only the genuinely lost segments to be repeated. The SACK blocks in the headers are an exact map of the losses.

It is critically important to distinguish true losses from spurious ones (spurious retransmission): with strong reordering or a sharp growth of delay, the sender may repeat a segment that was not actually lost. The analysis of the TTL, IP ID, and timestamps helps: for a segment retransmitted by timer and for its "original," the delayed copy arrives later than the retransmission, and the acknowledgment covers both. An error in either direction costs dearly: having taken reordering for losses, the engineer will look for a nonexistent channel problem; having taken losses for reordering — he will miss real congestion.

The price of losses for performance is nonlinear. In a connection with window scaling enabled, a single loss in the slow start phase throws the transmission rate back to the beginning; regular losses of even fractions of a percent on high-speed channels are capable of cutting the effective throughput several times over. Hence the practical rule: losses and retransmissions are the first thing checked when there are complaints that "the network is slow," and only after ruling them out does it make sense to look for the cause deeper.

Zero Window: when the application is to blame

A zero window (window size = 0) is the receiver's message "my buffer is full, do not send anything more." This is the point where transport analysis passes into application analysis: the network delivered the data, but the receiving application does not manage to read it from the socket. After a zero window come the probes (zero window probe) — the sender periodically sends one-byte segments, checking whether the window has opened; a dump filled with "probe — zero ACK" pairs unambiguously indicates the degradation of the receiving side: an overloaded database server, a hung handler, a shortage of reading threads.

The adjacent case is Window Full: the sender has exhausted the allowed volume of data in flight and is waiting for acknowledgments. If the receive window is large at that, it means the limit was created by the congestion window — a bottleneck in the network; if the receive window is small or zero — the receiver is to blame. This pair of diagnoses (Zero Window vs Window Full) localizes the problem between the application and the network faster than any other technique.

Historically the silly window syndrome also belongs here: a receiver that reads the data in small portions advertises tiny windows, provoking the transmission of inefficient small segments. The standard solutions — Dave Clark's algorithm on the receiver side and Nagle's algorithm on the sender side — are familiar to everyone who has encountered "small-packet" traffic; their interaction gave birth to a separate class of hard-to-catch delays, about which we will speak below.

Congestion control in live traffic

The algorithms created by Jacobson at the end of the 1980s (Tahoe, then Reno) laid down the scheme that lives to this day:

• Slow start — the congestion window doubles every RTT, starting from several segments; in the dump this looks like ever denser bunches of packets and a sharply growing throughput, until the connection hits a limit or a loss occurs.
• Congestion avoidance — after reaching the threshold (ssthresh) the window grows linearly; the traffic becomes even.
• Reaction to a loss — fast retransmit halves the window (multiplicative decrease); a loss by timer resets it almost to zero; then the growth cycle repeats. The graph of the speed of a single connection is the characteristic "sawtooth": growth, collapse, growth.

Modern implementations have developed this base. CUBIC (2008; the default algorithm in Linux since kernel 2.6.19) describes the growth of the window by a cubic function of time: after a loss, the window quickly returns to the previous level, then grows slowly in its neighborhood and aggressively beyond it. This makes CUBIC effective on long channels with a large delay, where the linear growth of Reno would take minutes to reach full speed. BBR (Google, 2016; the publication by Cardwell, Cheng, Gunn, Yeganeh, and Jacobson in ACM Queue) fundamentally changes the philosophy: instead of reacting to losses, the algorithm builds an explicit model of the channel — it continuously measures the bottleneck bandwidth and the minimum RTT (round-trip propagation time) and keeps the volume of data in flight equal to their product. Losses cease to be considered a congestion signal: on channels with background losses (satellite, mobile networks, transcontinental backbones) BBR shows a substantial gain — according to Google's data, its deployment gave on the order of a 4% average increase of throughput for the company's services, and on certain long routes the increase reached, according to published data, two to twenty-five times. The price was the disputes about fairness: BBR flows can occupy more bandwidth in competition with loss-oriented algorithms, and the second version (BBRv2, since 2019) added the accounting of congestion signals — ECN and losses — in order to reduce the aggressiveness.

A separate mechanism is explicit congestion notification (ECN, RFC 3168, 2001): the router, instead of discarding the packet, sets a bit in the IP header, and the receiver returns the mark to the sender in an acknowledgment. In the dump, the ECN marks (CE) are visible in the DSCP field and in the TCP flags — this is direct evidence that the queue along the path has begun to fill, obtained without losses. ECN remained niche for decades, but today the large cloud providers enable it inside their data centers, and in their traffic the analysis of the marks becomes part of the routine.

The practical conclusion for the analyst: before declaring "the network is to blame," one should understand which congestion control algorithm is running (on Linux — the sysctl parameter tcp_congestion_control; in the dump — the characteristic patterns of window growth) and whether the observed behavior corresponds to its logic. What looks like chaotic collapses of speed often turns out to be the regular work of Reno in a network with single losses; what looks like "the network will not let it accelerate" is a peculiarity of slow start on short transactions, which simply do not have enough RTTs to accelerate.

Subtle interactions: Nagle and delayed ACK

Two independent optimizing mechanisms, created five years apart, when working together give one of the most frequent hard-to-catch performance defects. Nagle's algorithm (RFC 896, 1984) prescribes that the sender accumulate small segments: while the previous data has not been acknowledged, new small portions are buffered and leave in one packet — a measure against the clogging of networks with "teletype" traffic of one-byte packets. Delayed acknowledgments (delayed ACK, RFC 1122, 1989) prescribe that the receiver not hurry with the ACK, in the hope of sending it together with the response data or of merging two acknowledgments into one — the typical delay is 40 ms in Linux and up to 200–500 ms in other stacks.

The pathology arises in a "request — response" dialogue on small packets: the client, obeying Nagle, has sent a small request and is waiting for the acknowledgment before sending the rest; the server, obeying delayed ACK, is waiting for the application data before acknowledging. Both parties wait for each other until a timer fires — and every transaction receives a regular pause of tens to hundreds of milliseconds. The symptom in the dump is recognizable: small requests, then strange even pauses (~40 or ~200 ms), then continuation. It is treated by disabling Nagle at the sender (TCP_NODELAY — the standard for interactive protocols like SSH and for most RPC) or by fast acknowledgments at the receiver. The class of delay "exactly 40 ms on every operation" is almost always this mechanism, and recognizing it saves days of searching for "problems in the network."

Reordering and asymmetric routes

The packets of one flow may arrive out of order (1 → 3 → 2 → 4): multipath routing, link aggregation (LAG), ECMP balancing on different hops — all these are legal reasons for reordering. TCP reacts to it the same way as to a loss — with duplicate acknowledgments and a possible false retransmission. In Wireshark the events are marked as Out-of-Order; the TTL and IP ID help distinguish them from real retransmissions: for a reordered packet the IP ID continues the monotonic series, for a retransmission — it repeats the original one. Moderate reordering is a reason not for panic, but for checking: are the thresholds (reordering) configured too aggressively, and is the congestion algorithm "punishing" the network for harmless multipath.

More insidious is asymmetric routing, in which the forward and the reverse traffic of a connection go by different paths. For the capture this means that the observation point on one router sees only half of the dialogue: the acknowledgments "disappear," the RTT looks anomalous, the retransmissions seem massive. The sign of asymmetry is a one-sided dump on a connection that is definitely alive. The conclusion is methodological: before interpreting the statistics of losses and delays, one must make sure that the observation covers both directions.

The "bandwidth × delay" product

The maximum volume of data that a connection can hold "in flight" is limited by the product of the throughput and the RTT (bandwidth-delay product, BDP). For a channel of 1 Gbit/s with a delay of 100 ms (a typical transcontinental route) the BDP is 12.5 MB — that many bytes must continuously be on the way for the channel to be loaded. A single TCP connection reaches this volume only with corresponding windows and a healthy slow start; applications that open a connection for every operation physically cannot quickly transfer a large file across the ocean — and this is not a "network problem," but a consequence of the laws of signal propagation.

Hence three practical consequences. First: slow transfer on long routes is often treated not by "adding bandwidth," but by tuning the protocol — window scaling, resumable sessions, parallel streams, algorithms like BBR. Second: measuring the speed with one short test is pointless — the connection does not have time to get out of slow start; one must measure on volumes many times exceeding the BDP. Third: estimating "how many RTTs a transaction needs" is the primary design tool: reducing the number of round trips (TLS 1.3 instead of 1.2, QUIC with 0-RTT, connection reuse) on long channels gives a bigger gain than speeding up the server by tens of milliseconds.

The application level: HTTP, DNS, TLS

The transport level explains how the data arrives; the application level explains why it was being sent at all. Web traffic gives the analyst the richest set of observable events: here every user operation breaks down into a chain of protocol phases, each of which can be measured separately.

HTTP: the anatomy of a transaction

The basic unit of analysis is the "request — response" transaction: the method and URL in the request, the status code and the body in the response. The response codes are the first landmark: 4xx indicate a problem on the side of the client or the application logic (a wrong path, a missing authorization); 5xx — a failure on the server side (an exception in the code, the unavailability of the database, a balancer timeout). The time to the first byte of the response (TTFB, time to first byte) is the key metric: it includes the processing of the request by the application and the waiting for the dependencies (the database, the cache, external APIs). A large TTFB with a fast TCP handshake is an almost unambiguous verdict of "the backend is slow."

It is useful to break down the full delay of loading a resource into phases: DNS resolution, the TCP handshake, the TLS handshake, the TTFB, the transfer of the body. This is exactly how the waterfall diagram in the browser developer tools and the HAR format show the transaction; the same breakdown is extracted from a pcap and from the curl timings. Comparing the phases instantly localizes the problem: a long DNS phase — to the resolver; a long TLS — to the cryptography and the RTT; a long transfer of the body — to the bandwidth or the serving server. Chains of redirections deserve separate attention: every 301/302 adds a full "request — response" cycle (and sometimes a new connection), and a cascade of three or four redirects unnoticed eats up seconds — in the dump it is visible as a series of short transactions before the real work begins.

Connection reuse (keep-alive) fundamentally changes the picture: in HTTP/1.1 the browser maintains up to six parallel TCP connections to one host and reuses them for dozens of requests. If the dump shows a new handshake for every request — the configuration or an intermediate device is breaking keep-alive, and every operation pays the full price of establishing a connection. Pipelined transmission of requests (pipelining) in HTTP/1.1, on the contrary, was almost never applied in practice — because of head-of-line blocking: the response to the first request delayed all the subsequent ones in the same connection.

HTTP/2: multiplexing and its price

HTTP/2 grew out of the experimental SPDY protocol (Google, 2009–2012), was standardized as RFC 7540 in 2015, and refined in RFC 9113 (2022). Its central idea is multiplexing: a multitude of independent streams within one TCP connection, with prioritization and its own flow control at the frame level (WINDOW_UPDATE), with HPACK header compression. One connection instead of six eliminates the competition of handshakes and allows the server to see the whole picture of the page load.

But multiplexing has a price, and it manifests itself precisely in traffic analysis. All HTTP/2 streams share one TCP channel, and TCP provides strict order of byte delivery: the loss of one segment stops the delivery of data to the application on all streams, even those whose data has already arrived — this is transport head-of-line blocking. In the dump the picture is characteristic: a single connection, dozens of interleaved HTTP requests, and a sudden general freezing, coinciding with a retransmission. One lost packet at the price of an RTO freezes the whole page. The paradox of HTTP/2: the protocol was created to reduce the influence of delays, but in channels with losses it sometimes works worse than HTTP/1.1 with its independent connections — those at least degrade partially.

HTTP/3 and QUIC: a transport over UDP

The answer to transport blocking became QUIC — the protocol started by Google in 2012 and standardized by the IETF in May 2021 (RFC 9000 — the transport, RFC 9001 — the TLS integration, RFC 9002 — loss detection and congestion control; version 2 — RFC 9369, 2023). The application profile on top of it is HTTP/3 (RFC 9114, 2022). QUIC implements reliable stream delivery directly over UDP:

• Independent streams without head-of-line blocking — a loss in one stream does not delay the others: the ordering is performed at the stream level, not the connection level.
• Built-in encryption — TLS 1.3 is part of the protocol, not a layer over it: the QUIC handshake is merged with the transport one, hence the start in one round trip, and on session resumption — in zero (0-RTT).
• Connection migration — the connection is identified not by the quadruple "addresses-ports," but by an identifier (Connection ID), so a change of network (Wi-Fi → cellular) does not tear the session.
• Improved estimation of the RTT and of the packet numbers — a forgery-protected monotonic numbering eliminates the ambiguity of retransmissions that tormented TCP.

By the mid-2020s, HTTP/3 is supported by all the main browsers and the largest CDNs; by Cloudflare's measurements, it already accounts for on the order of a quarter to a third of the HTTP requests in their network, and the share keeps growing.

For traffic analysis QUIC is simultaneously a gift and a challenge. The gift: the artifacts of the TCP level are gone, and the RTT and loss metrics are available more precisely. The challenge: practically everything is encrypted — not only the payload, but also most of the headers (header protection) — and nobody gives away the keys by default. Wireshark decodes QUIC and HTTP/3 only with a key file (the same SSLKEYLOGFILE) or debug builds; in production traffic the analyst works with what has remained visible: UDP packets on port 443, the sizes and timings of the packets, the connection identifiers, the initial unencrypted version header, the acknowledgment patterns. Effectively, the analysis of QUIC is the analysis of behavior by the shape of the traffic, and this tendency will strengthen. There is also an infrastructural problem: intermediate devices optimized for TCP not rarely cut or deprioritize UDP, because of which the clients fall back to TCP — in the dump such a fallback is visible as a QUIC attempt, then a new TCP handshake to the same host, and this is a signal to check the UDP policies along the path.

DNS: the invisible culprit of delays

A huge share of the complaints "the server is slow" turn out, on dissection, to be a DNS problem: name resolution precedes every new connection, and its cost is added in full to the delay of the first transaction. What to look for in the dump:

• The response time (dns.time in Wireshark): a healthy resolver answers in single-digit milliseconds; tens and hundreds are a sign of degradation.
• Repeats of one and the same request: the client asks again because the response was lost or the resolver is silent; a cascade of repeats with growing intervals is the classic picture of DNS unavailability.
• The return codes: NXDOMAIN (the name does not exist) where it should exist is a sign of a stale cache, of DNS interception by the provider, or of a configuration error; SERVFAIL is a failure of resolving higher up the chain.
• The truncation flag (TC): the response did not fit into the UDP datagram; the client repeats the request already over TCP — an additional delay, often connected with large DNSSEC signatures.
• CNAME chains: every canonical name may require a new request; a domain hung with five CNAMEs to a CDN and analytics services resolves into five successive queries.
• TTLs that are too small: settings that force the client to resolve the name for every connection; too large — a problem when the addresses change.

DNS is also a zone where a traffic "storm" serves as a symptom of someone else's problem: the mass retries of thousands of clients when a resolver fails look like a DDoS on the DNS server. And, as everywhere, the trend toward encryption has reached DNS: DNS-over-TLS (RFC 7858, port 853) and DNS-over-HTTPS (RFC 8484, over the standard 443) close the requests from observation in the network — with all the consequences for the privacy of the users, for the visibility of the traffic by the operators, and for the filtering systems.

TLS: the cost of the handshake and the remnants of visibility

TLS defines the "price of entry" of every protected connection. In TLS 1.2 (and earlier) the handshake required two round trips on top of the TCP handshake; TLS 1.3 (RFC 8446, 2018) reduced it to one round trip (1-RTT), and on session resumption — to zero (0-RTT, at the price of the risk of reusing intercepted early data). The total arithmetic of the first request to a new HTTPS site on a long route: DNS (1+ request) + TCP (1 RTT) + TLS (1 RTT) + request-response (1 RTT) — and with an RTT of 150 ms, only the protocol part eats half a second before the first byte. The conclusion "HTTPS is always more expensive than HTTP" is true precisely for the first connection; the reuse of sessions and tickets (session resumption) reduces the difference almost to zero, and TLS 1.3 with 0-RTT can make a protected connection faster than the unprotected analog of previous versions.

What does the analyst see in the TLS traffic without keys? Significantly more than it seems:

• Client Hello: the supported versions, the cipher suites, the extensions, the elliptic curves — and, most importantly, the SNI (Server Name Indication), that is, the domain name of the requested site in the clear. SNI is the main source of awareness about the visited resources for everyone who observes the channel; it is precisely around closing it that the modern privacy battles are fought (see below).
• The certificate chain (in TLS 1.2 — in the clear; in 1.3 the Certificate message is already encrypted, but the server's certificate is nevertheless transmitted during the handshake and can be obtained by an observer with a separate request): who issued the certificate, for which domains, the validity period.
• ALPN: the negotiated application protocol (h2, http/1.1) — it is visible which protocol the exchange will go by.
• Chronometry and volumes: the duration of the handshake, the sizes of the records, the rhythm of the exchange — material for behavioral analysis.

Client fingerprints: JA3 and JA4

Observation of the Client Hello parameters gave birth to a whole direction — TLS fingerprinting. The JA3 method, proposed by the engineers of Salesforce (John Althouse and colleagues) in 2017, computes a hash of the ordered set of the Client Hello fields — the version, the list of ciphers, the extensions, the elliptic curves, and the point formats. Different TLS stacks form different sets, so the hash stably distinguishes Chrome from Firefox, curl from the Python requests library, and a mass botnet — from both. The server variant JA3S fingerprints the server's response. In 2023 the JA4+ family appeared (FoxIO): modular fingerprints for TLS (JA4), HTTP headers (JA4H), certificates (JA4X), TCP parameters (JA4T), and other protocols — with a human-readable structure instead of a "blind" hash.

The applications are twofold. Defenders block unwanted clients (scrapers, bots) by fingerprint, even if they disguise the User-Agent, and reveal malicious software: many C2 frameworks and script clients have characteristic, known fingerprints. Observers (including censorship systems) use fingerprints to identify the tools of block circumvention. The attacking side answers with the randomization of the handshake parameters. Thus the encryption of the content gave birth to a new layer of analysis — by shape, not by content — and this layer will only grow.

Classic network problems and their patterns

The value of experience in traffic analysis consists in recognizing patterns: most problems manifest themselves with standard signatures, which an experienced engineer identifies in the first seconds of viewing. Below is the canonical set of such signatures with the mechanisms of their arising.

Packet losses

Signs: retransmissions, duplicate ACKs, gaps in the SACK blocks, exponential RTO pauses. The causes divide into two large classes, and it is important to distinguish them. Congestive losses (tail drop in an overflowing queue) correlate with the peaks of load: they come in bursts at the moments when the traffic intensity is maximal, and are accompanied by the reaction of the congestion algorithms. Random losses (errors on the physical medium — a degraded optical link, a noisy Wi-Fi radio channel, a defective cable) are distributed evenly in time and are not connected with the volume of traffic; they are given away by the growing counters of CRC errors on the interfaces. The distinction is important because the treatment is opposite: congestion is treated with queue and bandwidth management, physics — with the repair of the link; the congestion algorithms, however, treat any loss as congestion and on a noisy radio line pointlessly strangle the speed — a case where the model-oriented algorithms like BBR win.

Delay and jitter

A high base RTT is explained by geometry (long routes, satellite channels, detour routes through exchange points) and by queues. Jitter — the variation of the delay between the packets of one flow — is no less important: interactive applications (voice, video, remote access, games) suffer from the unevenness more than from the absolute magnitude. In the dump, jitter is visible as "floating" intervals between acknowledgments with a stable average; it is also measured actively — by the UDP mode of iperf3, by mtr with long observation. The causes are most often shared queues with heterogeneous traffic (see bufferbloat), balancing over non-equivalent paths, and a wireless medium with retransmissions at the L2 level, invisible to the IP observer.

Bufferbloat: the "healthy" network that slows down

One of the most underestimated problems of the last decade and a half. The term bufferbloat was introduced by Jim Gettys in 2009–2011, describing a systemic defect: the manufacturers of network equipment laid down excessively large queues, guided by the naive logic "a bigger buffer — fewer losses." The consequence turned out to be devastating: when the channel saturates, the packets are not lost, but accumulate in the queue for hundreds of milliseconds and even seconds; the RTT grows proportionally to the load; TCP sees no losses and keeps pumping the queue, while the interactive traffic suffocates. The symptomatology is recognizable: the base ping at rest is single-digit milliseconds, under load (a file download, a video stream) — hundreds; video calls fall apart precisely when someone in the network has started a download; retransmissions are practically absent.

The problem is treated with active queue management (AQM) — disciplines that deliberately create an early congestion signal instead of accumulating: RED (Random Early Detection; Sally Floyd and Van Jacobson, 1993) discards packets with a growing probability before the queue fills; CoDel (Nichols and Jacobson, 2012) tracks not the length of the queue, but the time a packet spends in it, and presses it down when the delay exceeds the target (~5 ms); fq_codel combines CoDel with a fair per-flow queue and since 2012 is part of the Linux kernel, having become the standard for home routers (OpenWrt/SQM); a more "polite" alternative to TCP, PIE, and the comprehensive discipline CAKE have also been developed. For the analyst, the main lesson of bufferbloat is methodological: "there are no losses" does not mean "the network is fine" — the absence of losses with a growing delay is by itself a diagnosis.

Fragmentation and Path MTU

The channels along the path between the hosts have different maximum frame sizes (MTU): classic Ethernet — 1500 bytes, PPPoE — 1492; IPsec/GRE/VXLAN tunnels eat another 20–50+ bytes. The path MTU discovery mechanism (RFC 1191) relies on the fact that a router unable to transmit the packet whole will return the ICMP message "Fragmentation Needed." If the firewalls along the path block ICMP entirely (a frequent "just in case" practice), the discovery breaks, and the "PMTU black hole" arises: the TCP connection is established (the handshake is small packets), but the data transfer hangs on the very first large segment — it is silently discarded, no ICMP notification returns, and the sender endlessly repeats one and the same large segment. The signature in the dump is unmistakable: the connection is alive, the ACK for the handshake is there, and one full-size segment is retransmitted time after time without a single acknowledgment.

The workarounds: MSS clamping (RFC 2923) — an intermediate device reduces the MSS in the SYN packets so that the parties immediately choose a safe segment size; fragmentation at the IP level (in IPv4) with its own woes — the loss of one fragment kills the whole datagram, and fragmented traffic is loved by attackers for bypassing filters; in IPv6 transit fragmentation is forbidden altogether, and only Packetization Layer PMTUD (RFC 4821) works, performing discovery by probes — which makes the blocking of ICMPv6 even more fatal. For the analyst the rule is simple: "the small works, the large does not, and the connection is established" — check the MTU.

Blocking, resets, and injections

The two ways in which a connection is killed deliberately look different in the dump and mean different things. Dropping: the SYN leaves and nothing returns — silence; this is how firewalls behave by default, and routing "black holes" look the same. Rejecting: an RST or the ICMP message "port unreachable" arrives instantly in response to the SYN — this is how host firewalls with a reject policy and closed services behave. Silence is diagnostically harder: from it one cannot distinguish filtering from unavailability without tracing.

A special class is the injection of packets by intermediate systems. An intermediate device (a content filtering system, a DPI gateway) can itself generate a TCP RST on behalf of the server in order to tear an unwanted connection. The first documented mass example of this kind was described in 2006 by the researchers Clayton, Murdoch, and Watson in their study of the "Great Chinese Firewall": the filtering system sent fake RSTs to both parties of the connection upon detecting forbidden keywords. In 2007–2008, the American provider Comcast applied a similar technique — fake RSTs to tear BitTorrent sessions — which led to proceedings in the US Federal Communications Commission and became one of the cornerstones of the net neutrality debates. The signature of an injection in the dump: two RSTs for one event — with different TTLs, different IP IDs, sometimes with different sequence numbers; or an RST that arrived faster than the response of the real server is physically possible. The ability to see this difference turns the analyst from an observer of "strange breaks" into a witness of deliberate interference.

CDNs, balancers, and NAT: the illusion of a direct connection

The modern client almost never talks to the "real" server. Behind the domain name stands an anycast address of a content delivery network (CDN), behind which is the edge node nearest to the client, behind which is a chain of balancers, and only then the origin server. For analysis this means several obligatory questions. With whom is the connection actually established — the IP in the dump belongs to the CDN, and its RTT characterizes the path to the cache, not to the source. Why does one and the same domain resolve into different addresses, and why do the responses come with an anomalously small TTL (the edge node is near) or, on the contrary, a suspiciously large one. Does the certificate in the TLS handshake match the expected domain, and is a corporate proxy substituting the chain with its own certificate authority. Where is the observation point relative to the balancer — one and the same "slow transaction" can be fast at the origin and slow at the edge, or vice versa.

NAT adds its own layer of illusions: a multitude of clients behind one address, translation tables with timeouts (typically minutes for idle TCP connections and tens of seconds for UDP), ALG "helpers" that rewrite the content of protocols. A long-idle connection (an SSH session, a database pool keep-alive) can be silently thrown out of the NAT table, and the next packet will spawn an RST "from nowhere" — in the dump this looks like a sudden reset of a live connection without any preceding errors. The signs of NAT in the traffic: a discrepancy between the addresses in the headers and in the application data (for example, in SIP or FTP), "jumping" TTLs from one source, the coincidence of the lifetime of many connections with the typical timeouts of the translators.

Broadcast and multicast traffic: the invisible load

Not all network traffic is unicast, and its service part regularly confuses the analysis. Broadcast transmissions are addressed to all the nodes of the segment: ARP requests "who owns this IP," service discovery (mDNS, SSDP, NetBIOS), the DHCP search for a server. In a normal segment this is background noise of single-digit percent of the bandwidth, which the analyst filters out with the very first display filter; but with a loop in the switching topology or an infection of the network, a broadcast storm turns the segment into an inoperable one — in the dump it looks like an avalanche of identical frames clogging the channel, and it is treated with the spanning tree protocol (STP) and segmentation. Multicast transmissions — video streams, stock exchange feeds, the multicast groups of routing protocols — are managed by IGMP and require group delivery from the infrastructure; in an unprepared network multicast degenerates into a flood to all the ports of the VLAN. The practical consequences for analysis: one must be able to quickly separate the service traffic from the useful one (otherwise the Conversations statistics is misleading), and the complaints "the network is down" with live servers sometimes turn out to be a broadcast storm, which is visible only at the data link level.

Summary of patterns

A compact cheat sheet linking the observable with the cause:

• SYN → silence. Dropping by a firewall, unavailability of the host, a route "black hole."
• SYN → RST. The port is closed, the service is not listening, active rejection by policy.
• Long DNS, repeats of requests. Degradation of the resolver; the "server" may have nothing to do with it.
• TCP is fast, HTTP is slow (a large TTFB). A backend problem: the application, the database, locks.
• The RTT grows under load, there are no losses. Bufferbloat: the queue, not the channel.
• The connection is there, large segments are retransmitted without ACK. A Path MTU black hole.
• Regular pauses of 40–200 ms on small exchanges. The interaction of Nagle and delayed ACK.
• One HTTP/2 connection, everything freezes simultaneously. The loss of a segment, transport head-of-line blocking.
• Two RSTs with different TTL/IP ID. Injection by an intermediate system.
• Zero window, probes. The receiving application is not reading the socket.
• A sawtooth of speed with collapses. The regular reaction of the congestion algorithm to losses; look for the source of the losses.
• Many small connections with almost zero return. A "slow" attack (Slowloris) is possible, or a broken client.

Quality metrics: from QoS to QoE

Traffic analysis is meaningless without measurable criteria: "fast" and "slow" are not engineering categories. The basic set of metrics is small, but each of them has subtleties that determine whether the diagnosis will be correct.

The basic metrics and the culture of measurement

• RTT / latency. The round-trip time of a packet to the target point. It is measured passively (by the handshakes and acknowledgments in the dump) and actively (ping, mtr, probes of TCP connections). It requires indicating the distribution, not only the average.
• Throughput. The volume of data delivered per unit of time. It differs from goodput — the payload minus the headers, the retransmissions, and the service traffic: on a noisy channel the difference reaches tens of percent.
• Losses (packet loss). The share of packets that did not reach the receiver. In passive analysis it is derived from the gaps in the numbers and the retransmissions; actively it is measured with UDP probes (iperf3) and long mtr.
• Jitter. The variation of the delay; critical for real time. Formally — the average deviation of the delivery intervals; in practice the tails of the distribution matter more.

The culture of measurement is no less important than the metrics themselves. A single measurement is not data; data is a distribution over time and over flows. A measurement in a quiet period does not characterize the peak. And every active measurement (ping, iperf) interprets the network in its own way: the probes pass through the same queues and policies as the ordinary traffic — or do not pass, when the ICMP is filtered, which systematically distorts the picture in favor of an "ideal" delay.

Tail latency: why the average lies

The classic work of Jeff Dean and Luiz André Barroso "The Tail at Scale" (Communications of the ACM, 2013) formulated the problem long familiar to network people: in a distributed system a request touches dozens of components, and its final delay is determined by the maximum of their delays. If each component has 1% of requests with an anomalous delay, then a request touching a hundred components will almost certainly land in the tail of at least one of them. The average response time looks wonderful at that.

Applied to traffic this means: one must analyze the percentiles — p50, p95, p99, p99.9. "An average RTT of 20 ms" is compatible with "p99 = 1.5 s," and it is precisely the tails that create the user experience of "heavy" pages. The modern performance practice (the SRE approach, SLI/SLO monitoring) is built on percentiles, and the packet analysis follows the same discipline: graphs of the distribution of the RTT over the connections, the share of transactions with a TTFB above the threshold, the tails of the DNS time. The tail latencies are where bufferbloat, timer retransmissions, the competition of flows, and the degradation of individual servers of the pool live: single causes, invisible in the average, but determining the worst user experience.

QoS: how the network manages the traffic

Quality of Service is the mechanism by which the network guarantees (or tries to guarantee) the delivery parameters for different classes of traffic. Historically two approaches took shape. IntServ (RFC 1633, 1994) with the RSVP protocol assumed the reservation of resources for every flow — elegant, but not scalable to the internet: the core routers cannot store the state of millions of flows. DiffServ (RFC 2474, 1998) won: the packet is marked with the DSCP code in the IP header at the boundary of the network, and inside, the routers serve the queues in accordance with the class — without the state of the individual flows. Voice receives priority; background downloads — the residual bandwidth.

Inside a node, QoS is implemented with queue disciplines and schedulers: priority queues (PQ), weighted fair queueing (WFQ and its descendants SFQ/FQ), shaping (smoothing bursts to a given profile, as a rule through buffering), and policing (hard discarding beyond the profile). For the analyst, QoS is an explanatory frame: "the voice is clean, but the download is slow" is the regular behavior of prioritization; "all the traffic is slow, the DSCP is zeroed in the middle of the path" is the typical disease of the junctions between management domains, where the provider does not trust the client's marking and grinds it off. Understanding which shaping/policing policies are applied along the path is often more important than measuring the channel itself.

QoE: the user's truth

Quality of Experience is a metric of another kind: not what the network provides, but what the user feels. The key paradox that every analyst must know: the network can be "ideal" by all the QoS indicators, while the user is dissatisfied. The classic example: the RTT is normal, there are no losses, the bandwidth is sufficient — but the video lags, because the problem lies in the logic of the adaptive streaming, the buffering of the player, the choice of the CDN node, or the degradation of a concrete origin server, invisible from the access network.

The QoE toolkit includes: for video — the startup time, the share of rebuffering time (rebuffering ratio), the quality of the chosen profile in adaptive systems (Apple's HLS, 2009; MPEG-DASH, an ISO standard since 2012), where the player constantly switches the bitrate according to the actual throughput; for voice — the MOS score (ITU-T P.800), the requirements for the one-way delay (the G.114 recommendation: up to 150 ms is acceptable, over 400 ms the conversation falls apart), and the size of the jitter buffer; for the web — user experience metrics like Core Web Vitals (the rendering time of the largest element, the responsiveness, the stability of the layout), which the search engines have turned into the de facto standard of site quality.

The methodological conclusion: traffic analysis should begin with reproducing the user scenario and fixing the QoE symptom ("the video starts for 8 seconds"), and only then descend to the packets for the cause. The reverse order — looking at the dump in search of "strangeness" without tying it to the complaint — gives birth to endless lists of found anomalies that have nothing to do with the matter.

Traffic analysis and security

The same skill of reading protocol behavior that cures slow sites forms the basis of network detection of attacks. Most intrusions leave traces at the transport and application levels long before the endpoints record them, and for a whole class of threats the traffic is the only source of signals.

Attacks visible in the dump

• SYN flood. An avalanche of SYN packets, often with forged addresses, without the closing ACKs: the queue of half-open connections overflows, and the legitimate clients do not live to see a response. The signature: a dense stream of SYNs to one port, retransmissions of SYN-ACK from the server, the absence of completed handshakes; on the server — the overflow of the SYN queue in the kernel counters. The standard protection is SYN cookies (see above), switching on when the queue overflows; its traces are "strange" initial numbers of the SYN-ACK.
• Port scanning. A series of SYNs to the sequential or characteristic ports of one host, or to one port of many hosts; the responses are RST (the port is closed) or SYN-ACK (open). Advanced variants use anomalous combinations of flags: the FIN scan, the NULL scan (no flags), the Xmas scan (FIN+PSH+URG) — they exploit the RFC requirements for the reaction to incorrect segments and are detected worse by simple rules. Slow scanning (a packet per minute, distributed over subnets) bypasses the threshold signatures and is revealed only by aggregation in flow telemetry.
• Slowloris and "slow" attacks. The attack published by Robert Hansen in 2009: a multitude of connections in which the header of an HTTP request is sent byte by byte with pauses, not letting the connection either complete or close by timeout. The connection pool of the web server is exhausted without a single "bad" packet. The signature in the traffic: dozens of long connections with a near-zero speed and regular small add-ons. The related class is RUDY (the slow sending of the body of a POST request) and slow-read attacks (the slow reading of the response, holding the server stream open).
• Application DDoS. An avalanche of correct HTTP requests — to the search, to the login, to an expensive API. Every packet is legitimate; the attack can be distinguished from a flash mob of users only by behavioral aggregation: the distribution of the User-Agents and the TLS fingerprints, the concentration by sources and geography, the uniformity of the request parameters, the unnatural evenness of the rhythm. This is the zone of joint work of traffic analysis and web analytics.

Reflection and amplification: record DDoS

A separate family of attacks uses servers with a forged source address (UDP allows this without a handshake) and protocols in which the response is many times larger than the request. The amplifiers: DNS (a factor of ~28–54 on recursive ANY requests), NTP with the monlist command (~556x), Memcached (~51,000x — a text protocol without authentication, answering with megabytes to bytes of request). The victim receives an avalanche from the addresses of unsuspecting open servers.

Two milestones that showed the scale of the problem. In October 2016, the attack on the DNS provider Dyn, carried out by the Mirai botnet of infected IoT devices (cameras, video recorders with factory passwords), reached by various estimates 1.2 Tbit/s and for hours took down a significant part of the popular sites of the East Coast of the USA. In February–March 2018, a series of amplification attacks through Memcached poured 1.35 Tbit/s onto GitHub — at that time the largest publicly recorded DDoS attack; the attack was repelled in minutes, but demonstrated how cheaply it had become to buy "record" power: a few thousand unprotected memcached servers exposed to the internet are enough. In the dump on the victim's side, these attacks look like a flood of UDP (port 53, 123, or 11211 — the source) from heterogeneous sources with fragments of huge responses; the protection is filtering by traffic type and limiting at the owners of the amplifiers, not at the victim.

Data exfiltration and command channels

Stolen data and the control of botnets must also travel over the network — and traffic analysis looks not for the content (it is encrypted), but for the rhythm and the shape. Beaconing: a malicious agent periodically "checks in" at the command center — connections at fixed intervals, sometimes with a small random jitter. An even periodicity is the strongest signal: live users and legitimate applications do not do this; the search for regular intervals in the time series of connections has become a standard technique of the NDR platforms.

Tunneling: DNS tunnels (the data is encoded in the long labels of domain names — tools of the iodine class), ICMP tunnels (the payload inside the echo requests), HTTPS tunnels (the C2 is indistinguishable from a browser by the mere fact of encryption — that is why the reputation of the destination, the SNI, and the TLS fingerprint of the client matter: the JA3 of script libraries and C2 frameworks is characteristic and well catalogued). The volumetric signs: an anomalous outgoing upload (in user networks the outgoing traffic is historically small), the night activity of workstations, requests to rarely used external addresses, "fat" DNS requests.

Sniffing, substitution, and the "man in the middle"

Inside local networks the classic of the genre is ARP spoofing: the attacker broadcasts fake ARP responses, tying the gateway's IP to his own MAC, and intercepts the traffic of the segment. In the victim's dump this is visible as two different MAC addresses for one IP, bursts of gratuitous ARP; in the statics — a divergence of the ARP tables of the neighbors. The related techniques: a rogue DHCP server (in the offers — "its own" gateway and DNS), the substitution of DNS responses (the response arrives faster than from the legitimate server, with a different TTL).

MITM against TLS is possible only when the attacker controls a trusted certificate authority of the client. The legal case of such control is corporate proxies with TLS inspection: a root certificate of the company is installed in the trusted stores of the employees; the proxy unpacks the HTTPS, inspects it, and packs it anew. In the traffic this manifests itself as different certificate chains and different JA3S for one and the same service depending on the observation point. The practice is ubiquitous and at the same time risky: the inspection point becomes a concentrator of sensitive data and a target of attacks, and the errors of its implementation (for example, indiscriminate forwarding) break the encryption in practice. For the analyst it is important to be able to distinguish such an inspection from a real attack — by the issuer of the certificate and by the behavior of the infrastructure.

What remains of privacy in encrypted traffic

Encryption closed the content, but did not close the behavior. The set of observable metadata — who, with whom, when, for how long, in what volume, in what rhythm — is still extensive: the SNI gives away the visited domain (in unencrypted form until the deployment of ECH), the DNS requests — the full list of the queries, the volumes and timings — the character of the activity. The scientific results show how serious this is: the task of website fingerprinting — determining the visited site by the sequence of the sizes and intervals of the packets of an encrypted connection — is solved by machine learning methods with an accuracy of up to 99% in closed experiments (Deep Fingerprinting; Sirinam and co-authors, 2018); in open conditions the accuracy is lower, but still sufficient for targeted surveillance. Application classifiers (AppScanner and subsequent works) determine the type of software by the shape of the traffic without decryption. This is not a theoretical threat: it is precisely on the metadata — the connection records, the flow telemetry — that the main mass of the communication intelligence of law enforcement agencies is built, since such data are cheaper and legally simpler to obtain than the interception of the content.

The countermeasures develop on all fronts: Encrypted Client Hello (ECH) — the successor of ESNI, hiding the SNI inside the encrypted handshake — is being standardized (support is already being rolled out by the large CDNs and browsers; the specification is at the stage of finalization in the IETF); DoH/DoT close the DNS; protective schemes (padding, traffic shaping, mixing networks like Tor) complicate fingerprinting — although both the studies show and the race continues. The engineering conclusion for the analyst is twofold: on the one hand, the analysis of encrypted traffic shifts toward metadata and machine learning, and one must be able to do this; on the other hand, the collection of traffic data has itself become an object of legal regulation. The EU directive on the mandatory retention of traffic data (2006/24/EC) was declared invalid by the EU Court in 2014 (the Digital Rights Ireland decision) as a disproportionate interference in private life; the disputes about the admissible terms and volumes of metadata retention continue in the national courts to this day. Telemetry is not only diagnostics, but also privacy, and the minimization of the collected data must be part of the architecture of observation.

Methodology: analysis as a detective investigation

The skill of reading packets by itself does not make an engineer an analyst: what makes him an analyst is the method. A traffic investigation is built around three questions that every dissection is obliged to answer.

The three questions of the investigation

1. Where is the problem? — localization: the level of the model (L2/L3/L4/L7), the node of the path (the client, the access network, the backbone, the data center, the server), the phase of the transaction (DNS, handshake, transfer).
2. Why? — the mechanism: losses, a queue, exhaustion of the window, a blocking of the application, a configuration error, the intervention of an intermediate device, an attack.
3. Who is responsible? — the zone of responsibility: the network, the server, the client, an external party (the provider, the CDN, the regulator), or security. Without the third answer the dissection has no practical completion — it does not turn into action.

Localization by symptom

The primary sorting is performed even before the dump — by the character of the complaint:

Symptom	Probable level	First checks
No response at all	Network / IP / firewall	ping, traceroute, SYN in the dump
The connection is not established	TCP / L4	RST or silence, the state of the port
It establishes, but slowly	TCP / application	RTT, window, TTFB
4xx/5xx errors	Application	response codes, server logs
Works with interruptions	Junctions and states	NAT timeouts, reordering, bufferbloat
Slow "for everyone, always"	Architecture / capacity	base metrics at scale
Slow "sometimes for some"	Tails and node degradation	percentiles, per-server statistics

This table is not a dogma, but the order of going through the hypotheses: it saves hours by preventing the classic mistake — starting with scrolling through the packets when the problem is localized with one command of mtr or ss.

Correlation of events: the end-to-end chain

The highest mastery is linking the levels into a single causal chain: network → TCP → TLS → HTTP → application logic. Each link receives its own assessment from the dump, and the verdict is passed on the divergence of the assessments. The canonical example: the RTT is normal, the TCP handshake is fast, the TLS handshake is fast, but the first byte of the HTTP response arrives after half a second — the network is acquitted, the processing of the request is to blame; the next step is the logs of the application and the database, where a slow query, a lock, or a garbage collector is usually discovered. The thinking shifts from "the packets go strangely" to "the server answers slowly because of a database lock" — and this is already a diagnosis, not an observation.

Modern practice strengthens the correlation with end-to-end identifiers. Distributed tracing systems (OpenTelemetry and compatible ones) propagate the context of the request through HTTP headers (traceparent), and these headers are visible in the pcap: the packet dump and the trace of the application are linked literally by one field. The timestamp of the incident from the monitoring narrows gigabytes of capture down to minutes; the connection identifier from the proxy logs — down to a single stream. Correlated analysis — packet, flow, metric, trace, log — is precisely that observability system toward which the industry is moving.

Practical cases

Case 1: the site does not open. The order of actions becomes second nature: ping — is there IP connectivity at all; traceroute — where does the route break; dig — does the name resolve and to the right address; a dump — what is happening at the TCP level. Three outcomes: SYN without a response (a drop along the way — a firewall, a "black hole," unavailability), SYN → RST (the port is closed or an active rejection), the handshake is there but there is no exchange (the problem is higher — a TLS failure, the application). In every case the answer to the question "who is to blame" is given in minutes.

Case 2: the site is slow. The decomposition by phases: dns.time is long — a resolving problem, the server may have nothing to do with it; the TCP handshake is long — geography or the queues of the channel; the TLS is long — the version of the protocol (1.2 instead of 1.3), the absence of session reuse; the TTFB is large — the backend; the body is transmitted slowly with a normal TTFB — the bandwidth, the window, the losses. Five different diagnoses behind one complaint of "it is slow" — and the dump distinguishes them unambiguously.

Case 3: the connection breaks. An RST is always somebody's: the server closed the socket (a crash, a restart, the exhaustion of resources), the firewall rejected by policy or by the state timeout, the NAT threw out the entry, the balancer exceeded the idle limit, or the RST was injected by a filtering system. The distinction is by the TTL and IP ID relative to the rest of the connection's traffic, by the time of appearance relative to the physical RTT (an injection "outruns" the server), by the sequence numbers (an injected RST often has an incorrect seq and is ignored by the stack, which is also visible — by the retransmission after a "reset" connection).

Case 4: the video is slow, "the network is fine." There are no losses, the RTT at rest is excellent — but under load the RTT grows several times (bufferbloat of the home queue), or the player switches the adaptive profile down because of competing traffic, or a concrete CDN edge node has degraded, invisible from the general statistics. The diagnosis requires looking not at the averages over the channel, but at the concrete stream at the concrete time — and at the QoE metrics, not the QoS.

Visualization: the eye is faster than the search

Experienced analysts look at the graphs before the packets. Wireshark builds the IO Graph (the traffic intensity over time with filtering by any expression), the TCP Stream Graphs (throughput, RTT, window size over time — the legacy of the tcptrace utility), and the Flow Graph (the sequence diagram of the messages between the parties). The patterns are recognized instantly: the "sawtooth" is the work of the congestion algorithm; the steps with a plateau at zero are the zero window; the sharp vertical bursts of identical packets are scanning or flooding; the gradual upward slope of the RTT line under load is the growth of the queues. What in the list of packets would require thousands of lines of scrolling is on the graph a single characteristic shape. Visualization is not a decoration of the analysis, but its primary tool.

The mental model of the expert

The difference of the levels of qualification is easiest to show with pairs of formulations. The novice: "the packets go strangely." The expert: "TCP is reducing the congestion window because of losses at the third hop — here are the duplicate ACKs and the SACK gaps, here are the error counters on the provider's interface." The novice: "the site is slow." The expert: "after a TLS handshake of 40 ms, the backend gives the first byte after 500 ms — the network is fine, look at the database." The novice: "some extra packets." The expert: "an RST with a TTL different from the rest of the flow arrived before the physical response of the server — this is an injection by an intermediate system."

The final shift of thinking that this stage of the engineer's training gives: traffic analysis is not about packets. It is about the behavior of the system under load, reconstructed from its external manifestations. The dump is the log of the system, which it writes itself without knowing it; the analyst's task is to read it more competently than the system has managed to confuse it. The indicator of maturity: the ability to open an unfamiliar pcap without a graphical shell (tshark or even a hex view), to see the problem in the first thirty seconds, and to clearly separate the zones of responsibility — the network, the server, the client, security.

Modern architectures: SDN, overlays, clouds

The tools and patterns described above assume a classic network with relatively static routes and explicit capture points. Modern infrastructures blur these assumptions, and traffic analysis must take this into account.

SDN: when the behavior of the network is software-defined

Software-defined networks (SDN) separate the control plane from the forwarding plane: the decisions about forwarding are made by a centralized controller (or a set of controllers), and the switches execute the rules it installs; the OpenFlow interface was proposed by the group of Nick McKeown with co-authors in the 2008 article that became the manifesto of the direction. For the analyst this means: the path of a packet can change dynamically, bypassing the classic routing protocols; traceroute may not reflect the real forwarding; "strange" behavior (loops, asymmetry, sudden changes of path) is sometimes a consequence of the controller's logic, not of a hardware failure. The controller itself is added as an observation point: its flow installation logs and rule statistics are a source of data that did not exist in the classic network.

Overlays and tunnels: the "matryoshkas" of packets

Virtualization moved the networks inside the hosts: VXLAN (RFC 7348, 2014) and Geneve encapsulate the frames of the virtual machines in UDP for transfer through the physical network (fabric); GRE and IPsec connect the data centers; WireGuard and the like solve the tasks of remote access; in mobile networks the traffic of a smartphone travels inside GTP-U tunnels from the base station to the core. The consequences for analysis: the internal traffic is invisible on the physical interfaces without accounting for the encapsulation; the capture must be chosen consciously — before the encapsulation (the internal packet is visible, the path is not) or after; the host's offload mechanisms (TSO/GSO segment the packets on sending, GRO/LRO glue them on reception) distort the picture — in the dump on the hypervisor, "superpackets" of tens of kilobytes are visible, which physically did not exist in the network, and their sizes and MSS dynamics must be interpreted with caution.

Clouds and containers: the vanished capture points

In the cloud there is neither a TAP nor physical access to the switch; observation is organized by the means of the provider (VPC Traffic Mirroring in AWS, Packet Mirroring in GCP, vTAP in Azure) or by agents on the hosts. In Kubernetes the path of a request passes through network namespaces, veth pairs, the CNI plugin, the iptables chains or eBPF programs, and often through the sidecar proxy of the service mesh (Envoy in Istio and the like). A capture "simply on the interface of the Pod" may not show the whole picture — the balancing and NAT rules are applied between the capture points. At the same time, the role of eBPF observability is growing: Cilium Hubble and similar tools build maps of flows and L7 events (HTTP codes, gRPC methods, DNS) right from the kernel, without packet capture, covering the cluster constantly — where continuous pcap is physically impossible by volume.

Observability as a system: the place of the pcap in the whole picture

The final element of the methodology is the place of traffic analysis in the general observability system. The pillars of the classic triad (metrics, logs, traces) are supplemented by the network layer: flow telemetry (NetFlow/IPFIX/sFlow), the counters of the equipment, and pointwise full capture. The working cycle looks like a cascade: the metrics give the signal ("the p99 has tripled"), the flows localize it ("the degradation is on the connections with a concrete ASN segment"), the packet capture explains the mechanism ("retransmissions after a route change, the RTT grew by 80 ms"), the traces of the application link it with the business logic ("the slow responses of a concrete service behind this connection"). Every layer is cheaper than the previous one in storage and more expensive in detail; the art is to ask of each layer exactly what it is capable of answering.

Conclusions

Traffic analysis is the assembly point of all the knowledge about networks. In it converge the structure of the protocols from the data link level to the application level, the theory of congestion control, the architecture of the internet with its CDNs, NATs, and overlays, the performance metrics, and the practice of security. It has no "chapter" of its own in the classic courses — because it is precisely the practical application of all the other chapters to real data.

The main transition that the specialist makes is from reading packets to reconstructing the behavior of the system under load. The packet ceases to be the object of analysis and becomes a testimony: what matters is not the bytes themselves, but the timeline, the causal connections, and the zones of responsibility that are reconstructed from them. The three questions of the investigation — where, why, who is responsible — turn the dump from a "set of strangeness" into an engineering document.

Encryption changed the subject, but did not cancel the discipline. When the content is closed, the analysis shifts toward the metadata and the shape of the traffic: timings, volumes, rhythms, handshake parameters, TLS fingerprints. This is simultaneously an expansion of the possibilities (behavioral analysis, detection of hidden channels, fingerprinting) and a new challenge to privacy — the metadata, as both the history of the telephone networks and the modern science of website fingerprinting show, is capable of telling about a person no less than the content of his messages. The engineer must keep both sides in mind: his observation tools work both for diagnostics and for surveillance, and the architecture of the collected telemetry is also an architectural decision about privacy.

The practical checklist of what a modern traffic analysis specialist must master:

• extracting the base metrics from a dump — RTT, throughput, losses, jitter — and working with distributions and percentiles, not averages,
• distinguishing the contribution of the network, the server, and the client to the delay of a transaction and confidently localizing the bottleneck,
• understanding the dynamics of TCP — slow start, the reaction to losses, the work of the window, the differences of CUBIC and BBR — and recognizing their signatures in the traffic,
• analyzing the application level — the phases of an HTTP transaction, DNS, the cost of the TLS handshake, the peculiarities of HTTP/2 and QUIC,
• knowing the classic patterns of problems: losses, bufferbloat, PMTU black holes, Nagle with delayed ACK, reordering, NAT timeouts, RST injections,
• recognizing attacks in the traffic — floods, scanning, slow attacks, reflected DDoS, beaconing and exfiltration tunnels,
• mastering the observability hierarchy: metrics, flows (NetFlow/IPFIX/sFlow), pointwise full capture, eBPF events,
• taking into account the peculiarities of modern architectures: overlays and tunnels, cloud mirrors, container networks, service meshes, SDN.

The toolkit will keep changing: eBPF is displacing the classic capture in everyday monitoring, machine learning — the signature methods in the detection of attacks, ECH and QUIC — are reducing the observation surface, and the new transports add layers of encapsulation. But the foundation will remain the same: the understanding of how the protocols behave under load, and the methodical discipline of measurements. Complexity is the main enemy of the reliability of systems, and as the systems grow more complex, the price of the ability to answer quickly and with proof the question "what is really happening in the network" only grows. The engineer capable of reading a dump as the log of a system — of seeing in it the sawtooth of the congestion algorithm, a database lock, the bloated buffer of a home router, or the beginning of a targeted attack — will remain in demand for as long as the networks themselves exist. And they, by all appearances, will not stop existing.