TCP (Transmission Control Protocol)

What it is (Definition)

TCP (Transmission Control Protocol) is a connection-oriented transport protocol that provides reliable, ordered delivery of a byte stream between applications. It sits above IP and turns best-effort packet delivery into something applications can treat as a continuous stream. TCP handles retransmissions, sequencing, congestion control, and flow control so the receiving application gets bytes in the correct order (or receives a clear failure if the connection cannot be maintained).

In most networks, TCP is the “default choice” when correctness matters more than minimal latency. Web browsing (HTTP/1.1 and many HTTP/2 deployments), email, SSH, file transfer protocols, and many enterprise client-server systems commonly rely on TCP because it can recover from loss and reordering in the middle of the network.

A useful mental model: IP moves packets from A to B, but it does not guarantee they arrive, arrive once, or arrive in order. TCP adds the missing pieces by maintaining per-connection state, tracking what has been sent, what has been acknowledged, and what needs retransmission. That extra state is also why TCP behaves differently from stateless protocols during failures, NAT changes, or middlebox timeouts.

Where it sits in the stack (Layer & usage)

TCP is a transport-layer protocol (L4) that runs end-to-end between hosts. Applications typically create a socket and let the operating system’s TCP stack manage the connection. From the application perspective, TCP provides a stream; from a packet perspective, TCP carries segments identified by IP addresses and ports.

Below: IPv4/IPv6 provides addressing and routing; TCP uses IP to deliver segments end-to-end.
Above: Applications and application frameworks (HTTP, TLS, SMTP, SSH); they open a TCP socket (IP + port).
Where used: Most stateful client-server applications where reliability and ordering matter.

A TCP connection is commonly identified by a 4-tuple: source IP, source port, destination IP, destination port. In practice, sequence/acknowledgment state and negotiated options (like MSS or Window Scale) also define how a connection behaves. On real networks, middleboxes like NAT and firewalls often track TCP state too, which is why idle connections can drop when a device’s timeout is shorter than the application expects.

Another practical point: TCP is sensitive to round-trip time (RTT) and loss. Even if bandwidth is high, long RTT or frequent loss can reduce throughput, especially during slow start or recovery. That is why troubleshooting TCP often focuses on patterns like retransmissions, duplicate ACKs, window behavior, and handshake success rates.

Header overview (Fields at a glance)

TCP’s header provides addressing via ports, state via sequence/acknowledgment numbers, and behavior via flags and options. You do not need bit-level knowledge to understand most captures. In practice, focusing on flags, Seq/Ack progression, window behavior, and retransmission patterns is enough for effective diagnosis.

Field	Size	Purpose	Common values / notes
Source / Destination port	2 bytes / 2 bytes	Identifies application endpoints	Common: 80/443 for web, 22 for SSH, ephemeral client ports
Sequence / Acknowledgment	4 bytes / 4 bytes	Ordering and reliability	Seq advances with bytes sent; Ack confirms bytes received
Flags	variable	Connection state and signaling	SYN, ACK, FIN, RST, PSH; combos define handshake/teardown
Window size	2 bytes	Flow control (receiver capacity)	Often scaled when Window Scale option is negotiated
Checksum	2 bytes	Integrity of TCP segment	Computed with pseudo-header including IP addressing info
Options	variable	Negotiated features	MSS, SACK, Window Scale, Timestamps are common

How it works (Typical flow)

A typical TCP session has a predictable structure: a handshake to establish state, a data phase with acknowledgments, and a shutdown sequence. The steps below are the “shape” you should expect to see in most normal captures.

Handshake: Client sends SYN; server replies SYN-ACK; client sends ACK (3-way handshake).
Option negotiation: MSS, Window Scale, SACK and timestamps may be proposed/accepted during handshake.
Data transfer: Application sends bytes; TCP segments them and tracks Seq/Ack for reliability.
Flow control: Receiver advertises a window so sender doesn’t overwhelm buffers.
Congestion control: Sender adapts rate based on loss/RTT signals to avoid congestion collapse.
Retransmission and recovery: Lost segments are retransmitted; out-of-order delivery is handled.
Teardown: FIN/ACK closes cleanly; RST indicates abrupt termination or rejected state.

Reliability cost: TCP adds overhead and latency during handshake and recovery, but improves correctness.
Stateful: Endpoints and middleboxes track state; timeouts and resets can break idle sessions.
Performance depends on path: RTT, loss, and MTU issues can dominate perceived speed.

In modern web traffic, TCP is often paired with TLS. When debugging “slow web,” it helps to separate TCP-level symptoms (handshake delays, loss, window stalls) from TLS/application-level symptoms (certificate errors, server response delays). TCP captures give you the transport truth: what was sent, what was acknowledged, and what was retransmitted.

How it looks in Wireshark

Display filter example:

tcp.port == 443

What you typically see:

Flags (SYN/SYN-ACK/ACK) at the start, FIN or RST at the end
Seq/Ack progression; TCP “Len=” indicates payload size at TCP level
Window and options (MSS, SACK Permitted, Timestamps, Window Scale)
Expert info such as Retransmission, Out-Of-Order, Dup ACK

Quick read tip: To isolate initial connection attempts, focus on SYN packets and check whether a matching SYN-ACK returns. Many SYNs with no SYN-ACK is a strong sign of filtering, routing problems, or a service not listening.

Common issues & troubleshooting hints

Connection timeout during handshake

Symptom: The client repeatedly sends SYN packets, but the connection never establishes. Applications report timeouts, “cannot connect,” or “connection timed out,” especially during the initial open.
Likely cause: Firewall drops, server down, routing issues, asymmetric return path, or a port that is not reachable. In some cases, a middlebox may silently drop unsolicited inbound traffic, making failures look like “nothing happens.”
How to confirm: Capture near the client and filter for SYN/SYN-ACK. If SYN leaves but no SYN-ACK returns, suspect path or policy issues. If SYN-ACK returns but the final ACK is missing, investigate client-side filtering or packet loss on the client path.

Frequent retransmissions and poor throughput

Symptom: Transfers are slow or unstable. Wireshark flags Retransmission and Duplicate ACK, and throughput appears much lower than the link speed would suggest.
Likely cause: Packet loss, congestion, Wi-Fi interference, overloaded links, or buffer problems. MTU/fragmentation problems can also cause consistent loss patterns, especially when large segments are used.
How to confirm: Look for bursts of Dup ACK, rising RTT, and retransmissions clustered around specific sequence ranges. Compare captures from both ends when possible to distinguish true loss from capture loss or offload artifacts.

RST storms and abrupt disconnects

Symptom: Connections drop suddenly with RST. Applications see “connection reset” or unexpected disconnects, sometimes after a period of idle time.
Likely cause: Middlebox timeout, policy-based reset, application crashes, or mismatched state after NAT rebinding or failover. Some security devices actively reset connections they classify as forbidden or anomalous.
How to confirm: Identify who sends the RST (client, server, or an intermediate device). Correlate resets with idle durations and verify NAT/firewall timers. If the RST does not match either endpoint’s MAC/IP path, suspect injection by a middlebox.

Zero Window and stalled sender

Symptom: The sender stops transmitting because the receiver advertises a zero window. Applications appear “hung” or “stalled,” even though the connection remains open.
Likely cause: The receiver application is not reading data fast enough, buffers are exhausted, or the system is under memory/CPU pressure. In some environments, upstream backpressure can cascade into prolonged window closure.
How to confirm: Filter for zero window indications and check whether Window Update appears later. Compare the timing to application behavior (e.g., a slow consumer or a blocked thread) rather than assuming the network is the only cause.

Security notes (if relevant)

TCP does not encrypt payloads, so confidentiality is normally provided by TLS on top. However, TCP state can be targeted: SYN floods exploit handshake state, and resets or state exhaustion can disrupt long-lived connections. Many defenses are deployed at network edges, such as SYN cookies, rate limits, and careful tuning of stateful firewall timeouts.

When security is a concern, it is also useful to separate transport issues from authentication and encryption issues: TCP tells you whether a path is stable; TLS and application logs tell you whether a peer is trusted and the session is valid.

Related pages (internal links)

Back to Dictionary Index
Key fields (TCP flags, Window, Options — Soon)
Related topics (3-way handshake walkthrough, Retransmission patterns, Zero Window troubleshooting — Soon)