---
{
  "title": "Transmission Control Protocol",
  "summary": "Understand TCP connections, ordered streams, retransmissions, and why a successful handshake cannot prove an application action succeeded.",
  "topic": "networking",
  "level": "Beginner",
  "updated": "2026-10-12",
  "units": [
    1
  ],
  "aliases": [],
  "sources": [
    {
      "title": "IETF: TCP specification",
      "url": "https://www.rfc-editor.org/rfc/rfc9293.html"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## A reliable stream between endpoints

Transmission Control Protocol, or TCP, gives applications an ordered stream of bytes between communication endpoints. Sequence information, acknowledgments, and retransmission help the receiver reconstruct data despite loss or reordering on the network. Reliability here concerns transport behavior. It does not promise that a remote application will accept an order, save a file, or keep running indefinitely.

The endpoint context includes addresses and [[ports-and-services]]. A server can handle many connections, so “the server uses TCP” is only the beginning of describing a particular exchange.

## Separate connection setup from useful work

A typical connection starts with a three-way handshake. The peers establish transport state before exchanging application data. Establishing that state differs from authenticating a user or authorizing a request. Those decisions belong to other mechanisms, often above TCP.

Consider a fictional learner downloading a course handout. The laptop reaches the server and establishes a connection, but the learner's session has expired. The server can return an application response asking them to sign in. The transport worked while the requested download did not happen.

This distinction changes troubleshooting. If the application returns a clear error, repeatedly changing network settings may distract from the actual account or application problem.

## Bytes do not carry application boundaries

An application must define how its messages are represented within the stream. One application write does not necessarily correspond to one network packet or one receiver read. Protocol designers therefore use mechanisms such as lengths, delimiters, or structured framing to distinguish messages.

For the handout example, a packet capture is not automatically a list of complete documents. An analyst must understand the application protocol, the capture's completeness, and whether encryption prevents content inspection. [[packet-analysis]] develops that evidence question.

## Delay has more than one cause

Retransmissions can indicate that data was not acknowledged as expected, but they do not identify the cause by themselves. Congestion, loss, capture limitations, endpoint behavior, and path changes can complicate an observation. Record where the capture was collected and what it actually contains.

A TCP acknowledgment concerns transport receipt; it should not be reported as proof that the application completed a database transaction. For the fictional learner, the useful evidence might combine transport observations with the HTTP response and server records.

## Add the security properties separately

TCP does not itself encrypt the application stream. [[tls]] can protect a suitable connection, while application identity and permission checks determine access. [[tcp-and-udp]] compares transport responsibilities without reducing them to “safe” and “unsafe.”

In a lab you own, draw the sequence from connection setup to a rejected download. Mark which observation supports reachability, which supports an encrypted exchange, and which explains the application outcome. The exercise is successful when you can state what each layer proves and what remains unknown.