Networking Fundamentals and Protocols Questions

Direct answer
The TCP three-way handshake establishes a reliable connection before any data flows: the client sends a SYN, the server replies with a combined SYN-ACK, and the client finishes with an ACK. Its job is to let both sides agree on starting sequence numbers and confirm that both directions of the path actually work before committing application data to the wire.

Structured elaboration

1. SYN: the client picks an initial sequence number (ISN, essentially a large pseudo-random 32-bit number) and sends a segment with the SYN flag set and that sequence number. The client moves to the SYN-SENT state.
2. SYN-ACK: the server, if it's listening on that port, picks its OWN initial sequence number, and replies with a segment that has both the SYN flag set (announcing the server's own sequence number) AND the ACK flag set (acknowledging the client's sequence number + 1). The server moves to the SYN-RECEIVED state.
3. ACK: the client acknowledges the server's sequence number + 1 with a plain ACK segment. Both sides now move to ESTABLISHED, and either side may now send data.

Why three steps rather than two: TCP needs BOTH sides' sequence numbers acknowledged, since TCP is full-duplex (both directions need independent sequence tracking). A two-way handshake could confirm only one direction; the third message is what confirms the client's original SYN actually arrived, closing the loop for the client's own sequence space.

Worked example
Suppose a client opens a TCP connection to a web server on port 443. The client sends SYN, seq=1000. The server responds SYN, ACK, seq=5000, ack=1001 (acknowledging the client's SYN by number+1). The client responds ACK, seq=1001, ack=5001. From this point, the client's next data byte will carry sequence number 1001, and the server's next data byte will carry sequence number 5001; each side tracks the OTHER side's sequence space independently via the ACK field of every following segment.

Trade-offs & pitfalls
A frequent mistake is describing the handshake as three round trips; it's actually one and a half round trips of latency, because the SYN-ACK piggybacks the server's SYN onto its ACK of the client's SYN. This is also exactly why TCP always incurs at least one round trip of setup latency before any data can flow, which is the whole motivation behind newer mechanisms like TCP Fast Open that try to send data alongside the very first SYN.

Direct answer
Bandwidth is the link's raw theoretical capacity; throughput is what's actually achieved end-to-end, which is always less than or equal to bandwidth; and goodput is throughput minus any overhead that isn't USEFUL application data (protocol headers, retransmissions of data that eventually succeeds anyway). An application commonly sees less than the rated bandwidth for several genuinely distinct reasons, and telling them apart is the fast path to the right fix.

Structured elaboration
Four common, distinct reasons throughput or goodput falls short of bandwidth:

1. Retransmissions: any lost segment that has to be resent consumes bandwidth without contributing new useful data, so a lossy path shows lower goodput even at unchanged raw throughput.
2. Protocol overhead: every layer's headers (Ethernet, IP, TCP) consume bytes that count toward raw throughput but never toward the application's actual USEFUL payload, goodput specifically excludes them.
3. Congestion-window or flow-control limits: if the connection's congestion window or receive window is smaller than the path's bandwidth-delay product, the sender is idle waiting for ACKs rather than continuously filling the pipe, capping achieved throughput well below the link's rated bandwidth regardless of loss.
4. Application-level inefficiency: an application that reads/writes in small chunks, adds its own serialization overhead, or simply isn't pipelining requests efficiently can bottleneck well below what the transport layer itself is capable of moving.

Worked example
The fastest way to localize which of these applies to a specific slow transfer: check retransmission counters first (ss -i's retrans field), if they're elevated, loss/retransmission is a real contributor. If retransmissions are low but the window (cwnd/rwnd from the same tool) is small relative to the path's bandwidth-delay product, the connection is window-limited rather than loss-limited, and no amount of "fixing loss" will help. If BOTH retransmissions are low and the window is comfortably larger than the bandwidth-delay product, yet throughput is still poor, suspect application-level inefficiency (measure CPU usage and how the application is actually issuing reads/writes) rather than anything at the transport layer at all.

Trade-offs & pitfalls
The most common diagnostic mistake is assuming a throughput shortfall is automatically a "network problem" and reaching straight for network-level tuning; a genuinely application-bound bottleneck (small, unbuffered writes; serialized rather than pipelined requests) is common and invisible to any amount of TCP-level tuning, wasting real effort until the actual bottleneck is correctly localized first.

Direct answer
The TCP header carries, at minimum, a sequence number and acknowledgment number (for tracking and confirming data), the SYN/ACK/FIN/RST control flags (for connection setup and teardown), a window size (for flow control), and a set of options including MSS (Maximum Segment Size), window scale, SACK-permitted (Selective Acknowledgment), and timestamps (all negotiated at the handshake). If you could only check a few during a performance incident, window size and the options negotiated at the handshake (MSS, window scale, SACK) are the highest-value first checks, since they directly bound how efficiently the connection CAN perform, before even looking at anything dynamic.

Structured elaboration

• Sequence number: identifies the position, in bytes, of this segment's data within the overall byte stream; every byte sent gets a sequence number.
• Acknowledgment number: when the ACK flag is set, indicates the NEXT byte the receiver expects, effectively confirming everything before that point has arrived.
• Flags (SYN/ACK/FIN/RST): SYN initiates a connection, ACK confirms received data (present on nearly every segment after the handshake), FIN requests a graceful close, RST aborts the connection immediately.
• Window size: the receiver's advertised available buffer space (subject to the negotiated window SCALE factor from the handshake), the mechanism behind flow control.
• Options (MSS, window scale, SACK-permitted, timestamps): negotiated ONLY in the SYN/SYN-ACK exchange and fixed for the connection's lifetime; MSS caps the largest single segment, window scale extends the effective window size beyond the raw 16-bit field, SACK-permitted enables selective (rather than only cumulative) acknowledgment, and timestamps support accurate RTT measurement and protect against stale, wrapped sequence numbers.

Worked example
Triaging a performance incident with limited time, check the negotiated OPTIONS first: if window scale never negotiated successfully (visible by comparing the SYN and SYN-ACK), the connection is capped at a 64KB window for its ENTIRE lifetime regardless of anything else, a hard, structural ceiling worth ruling out before looking at anything dynamic. Then check the CURRENT window size value on live segments (has it collapsed to something small, suggesting a flow-control-limited receiver) alongside the flags (any unexpected RSTs indicating the connection is being torn down and re-established repeatedly, itself a red flag). Sequence and acknowledgment numbers matter most for confirming specific loss/retransmission behavior (comparing them across segments), a more detailed, second-pass check once the higher-level structural questions (options, window, flags) have been ruled out.

Trade-offs & pitfalls
It's easy to over-focus on sequence and acknowledgment numbers first because they feel like "the real data" of TCP's bookkeeping, but for a FIRST-PASS performance triage, the options negotiated once at the handshake (which structurally CAP what the connection can ever achieve) and the live window size (which shows whether that cap is even being approached) are higher-leverage checks, they answer "is there a hard ceiling here" before you spend time analyzing moment-to-moment sequence-level behavior.

Direct answer
The UDP header is deliberately minimal, just four fields: source port, destination port, length, and checksum, and it provides no reliability, no ordering, and no flow or congestion control at all. The checksum is optional over IPv4 (it can be all-zeros to mean "not computed") but MANDATORY over IPv6, since IPv6 dropped the network-layer checksum that IPv4 had, leaving UDP's checksum as the only integrity check left covering the payload for that traffic.

Structured elaboration

• Source port (16 bits): the sending application's port, allowing a reply to be addressed back to the right process; can legitimately be zero if no reply is expected.
• Destination port (16 bits): identifies which application on the receiving host should get the datagram.
• Length (16 bits): the total length of the UDP header plus payload, in bytes, this is how a receiver knows where the datagram actually ends (UDP has no separate "end of message" marker otherwise).
• Checksum (16 bits): a checksum computed over a pseudo-header (which includes the source/destination IP addresses, borrowed conceptually from the IP layer to catch certain misdelivery errors) plus the UDP header and payload.

Over IPv4, the sender is technically permitted to skip computing the checksum entirely, since IPv4 packets already carry a header checksum which catches SOME corruption, though notably NOT payload corruption. Over IPv6, sending a UDP checksum is mandatory, precisely because IPv6 has no header checksum of its own at all, so UDP's checksum became the last line of defense for detecting corruption anywhere in the packet.

Worked example
If corrupted UDP payloads are reaching an application in production despite the checksum being enabled, that's actually a meaningful signal about WHERE the corruption is happening: a valid checksum plus corrupted payload data can only mean the corruption happened AFTER the checksum was computed and BEFORE the packet was actually transmitted onto the wire (for instance, in host memory, in a buggy driver, or in hardware), or that checksum offloading to the NIC is misconfigured or buggy (many NICs compute the checksum in hardware rather than the OS, and a broken offload implementation can silently produce or accept bad checksums). It would NOT typically indicate ordinary in-transit bit-flip corruption, since that's exactly the class of error the checksum exists to catch and reject.

Trade-offs & pitfalls
The 16-bit checksum, while better than nothing, is not cryptographically strong and won't catch every possible corruption pattern, especially certain kinds of systematic bit errors; applications with strict data-integrity requirements over UDP (like some real-time media or gaming protocols) often layer their own additional integrity or authentication checks on top rather than relying on the UDP checksum alone.

Direct answer
TIME_WAIT is the state the side that sent the FINAL ACK of a connection close sits in for a fixed period (commonly twice the maximum expected segment lifetime, often around 60 seconds on Linux) before the connection's resources are fully released. It exists so a delayed, duplicate packet from an old connection can't be mistaken for part of a brand-new connection reusing the same address/port pair. A half-open connection is one where only one side still believes the connection is alive; the other side has already reset, crashed, or otherwise abandoned it without a clean FIN exchange.

Structured elaboration
TIME_WAIT exists to protect two things: (1) it guarantees the final ACK the closing side sent actually gets through, by giving time to retransmit it if the peer's FIN gets retransmitted (meaning the ACK was lost); (2) it prevents a stray, delayed packet from a previous incarnation of a connection (same 4-tuple: source IP, source port, destination IP, destination port) from being delivered into a brand new connection that happens to reuse the same 4-tuple before the old segments have had time to disappear from the network.

To detect a large number of sockets stuck in TIME_WAIT on Linux, ss -tan state time-wait | wc -l (or the older netstat -ant | grep TIME_WAIT | wc -l) gives a live count; watching this metric over time distinguishes a normal, self-draining backlog from a genuine problem.

Worked example
A server that closes millions of short-lived outbound connections per hour (for instance, a service making one HTTP call per request to an upstream) can exhaust its available ephemeral source ports if TIME_WAIT sockets accumulate faster than they expire, because each TIME_WAIT socket still holds its port reserved. The two standard mitigations are: raise the number of available client-side (ephemeral) ports and/or reuse connections via keepalive/connection pooling so fewer connections churn through TIME_WAIT in the first place; and, on the SERVER side specifically, enabling SO_REUSEADDR and, where safe, tcp_tw_reuse lets a new outgoing connection reuse a TIME_WAIT 4-tuple once TCP timestamps confirm it's safe to do so, rather than waiting out the full timer.

Trade-offs & pitfalls
Disabling or drastically shortening TIME_WAIT globally (rather than tuning port ranges or reuse settings) is the wrong fix: it reintroduces the exact correctness problem TIME_WAIT was designed to prevent, stray old packets landing in a new connection and corrupting it. The safe levers are reducing HOW MANY connections churn through the state (pooling, keepalive) and widening the ephemeral port range, not shrinking the safety window itself.