1st Principles
Menu

Networking · 36 min read

TCP/IP

The internet's core contracts: IP for addressing and forwarding, TCP for reliable byte streams on top of an unreliable network, including handshake, ACK, and windowing mechanics.

Why this exists

Applications often want something like a dependable pipe: bytes in order, without silent gaps. The physical world offers noisy, shared, multi-hop paths.

TCP/IP splits the problem. IP moves packets between hosts. TCP reconstructs order, reliability, and flow control when apps need a stream. Together they are the workhorse contract of the classical internet.

Even when newer transports appear, they are judged against the TCP/IP baseline: what guarantees do you keep, what latency do you buy, and how do you share the path?

Axioms & primitives

  1. 01IP delivers packets best-effort between hosts identified by addresses.
  2. 02TCP provides a connection-oriented, reliable, ordered byte stream atop IP.
  3. 03Ports multiplex many conversations on one host.
  4. 04TCP uses acknowledgments, retransmission, and windowing to cope with loss and limited buffers.
  5. 05Flow control protects the receiver; congestion control protects the network.
  6. 06Byte-stream semantics do not preserve application message boundaries.

Learning objectives

After this lesson you should be able to:

  • Trace a TCP three-way handshake and say what state each side learns.
  • Explain how sequence numbers and ACKs repair loss and reorder.
  • Distinguish flow control (receiver capacity) from congestion control (network capacity).
  • Describe what a port number contributes that an IP address does not.
  • Predict a user-visible symptom of head-of-line blocking on a single TCP connection.

Progressive depth

Read the layers in order for a full explanation. Or open the layer you need.

01

Intuition

IP is how the internet finds a path for labeled chunks. TCP is a careful conversation on top: did you get chunk 7? If not, resend. Together they let a browser download a file without you stitching packets by hand.

Ports are apartment numbers on a building (the host): 443 is not a different machine; it is a different listening application.

The handshake exists so both sides agree that a conversation has started and synchronize their sequence number spaces before data is trusted.

02

Formal shape

IPv4/IPv6 headers carry source/destination and other forwarding fields. TCP adds ports, sequence numbers, acknowledgments, windowing, flags, and a handshake (SYN, SYN-ACK, ACK).

Byte-stream semantics mean message boundaries are not preserved unless the app encodes them. Flow control uses the receiver advertised window. Retransmission timers and fast retransmit on duplicate ACKs repair loss.

Connection termination uses FIN/ACK (and RST for abort). Middleboxes track this state and can cause pain when they get it wrong or time out aggressively.

Congestion control (deepened separately) modulates how large the congestion window can grow. Confusing it with flow control is a classic exam and debugging mistake.

TCP handshake

Click a stage to see how both sides start a conversation before data is trusted. Matches the SYN, SYN-ACK, ACK framing on this page.

Loading diagram...

Select a stage to read the boundary detail.

03

Worked examples

Opening https://example.com: DNS yields an IP; TCP connects to port 443; TLS secures the stream; HTTP rides inside. If Wi-Fi drops packets, TCP retransmits, and your page load stalls rather than silently corrupting HTML mid-tag.

Lost SYN-ACK: client retransmits SYN (or server retransmits SYN-ACK depending on what was lost). User sees a slow connect, not a half-built stream of data.

A stuck ESTABLISHED connection with no progress may be a blackhole path, a firewall, or a peer that vanished without RST/FIN. TCP keepalives and application heartbeats are different layers of liveness.

Socket APIs (listen/accept/connect/send/recv) are the programmer's view of this contract. A partial read is normal; loop until you have a full application frame.

04

Edge cases

NAT and firewalls complicate the pure end-to-end story. Head-of-line blocking in TCP motivated HTTP/2 multiplexing workarounds and HTTP/3's move to QUIC over UDP.

Mobile networks renumber; sessions die; apps retry. TCP's assumptions about loss meaning congestion are imperfect on wireless, which drove decades of research and newer transports.

Asymmetric routing and middleboxes that only see one direction can break state. MTU issues stall large segments while small control packets still flow.

RST injection and sequence guessing are security topics: TCP was not designed as an authentication protocol.

Mental models

  • Postal system plus phone call

    IP is the postal network (addressed letters). TCP is a phone call discipline: dial (handshake), speak in order, ask for repeats, hang up.

  • Sliding window

    TCP keeps multiple packets in flight, advancing only as acknowledgments arrive: efficiency under uncertainty.

  • Two conversations

    IP talks to routers about where. TCP talks to the peer about what arrived and what may be sent next.

  • Numbered conveyor belt

    Bytes get sequence numbers. The receiver loads them onto a belt in order; gaps pause delivery to the app until filled (or the connection fails).

Common misconceptions

  • Myth

    TCP is inherently faster or slower than UDP.

    Reality

    TCP adds reliability and congestion control. That can feel slower for some workloads and essential for others. UDP is not magic speed; it leaves more to the app.

  • Myth

    An IP address permanently names a person or machine.

    Reality

    Addresses are routing locators that can change with network attachment, NAT, and renumbering.

  • Myth

    A TCP connection is a reserved physical circuit.

    Reality

    It is shared-state agreement between endpoints. The path in the middle remains packet-switched and may change.

  • Myth

    TCP delivers messages the way you write() them.

    Reality

    TCP delivers a byte stream. Writes may coalesce or split; apps must frame messages themselves.

Exercises

Work these without looking up answers first. Check yourself against the intent notes.

  1. Exercise 01

    Walk through what fails if the SYN-ACK is lost, and how the client typically recovers.

    What good looks like

    Client retransmits SYN; server may retransmit SYN-ACK; connection establishes once handshake completes. No application data delivered before that.

  2. Exercise 02

    Why can two browsers on one laptop download from the same server at once without mixing bytes?

    What good looks like

    Different source ports (and thus 5-tuples) demultiplex separate TCP connections.

  3. Exercise 03

    An app writes() three JSON messages back-to-back on one TCP socket. The peer reads() once and gets all three stuck together. Who is wrong, and how do you fix it?

    What good looks like

    Nobody violated TCP; byte stream coalesced. Add length prefixes or delimiters; parse accordingly.

Sources & further reading

External references. Prefer primary documents and clear explainers.

Go deeper on your own

These picks go past the foundation in this lesson. Use them when you want a primary spec, official docs, or a longer walkthrough.