TCP

TCP sits between your application and the IP layer. IP alone just throws packets at an address and hopes they arrive. Packets can be dropped, duplicated, delayed, or show up in the wrong order. TCP wraps IP and turns that mess into something an application can trust: a connection where the bytes you send come out the other end in the same order, exactly once, with nothing missing.

It is a byte-stream protocol, not a message protocol. When you write 1000 bytes then 500 bytes, the receiver might read it back as one chunk of 1500, or as 200 then 1300. TCP does not preserve your message boundaries; that is your job, which is why protocols built on top of it (HTTP, for example) add their own framing like Content-Length headers.

TCP is also connection-oriented. Before any data flows, both sides agree to talk and set up shared state: starting sequence numbers, window sizes, and options. That setup is the famous three-way handshake.

The handshake is three packets. The client sends a SYN with a random initial sequence number. The server replies SYN-ACK, acknowledging the client and sending its own sequence number. The client sends a final ACK. Now both sides know the other is reachable and agree on where the byte counting starts. This costs one full round trip before any real data moves, which is why latency matters: a client 200ms away pays 200ms just to open the connection.

Reliability comes from sequence numbers and acknowledgements. Every byte has a number. The receiver acknowledges the highest contiguous byte it has received. If the sender does not get an ACK before a timer expires, or it sees three duplicate ACKs, it retransmits. Out-of-order packets are buffered and reordered before being handed to the application.

Flow control stops a fast sender from drowning a slow receiver. The receiver advertises a window: how many more bytes it can accept right now. The sender never sends more than that window allows. Congestion control is separate and protects the network itself. Algorithms like CUBIC (Linux default) and BBR (built by Google) start slow, ramp up, and back off when they detect loss or rising delay, so thousands of connections can share a link without collapsing it.

Closing is a four-way exchange of FIN and ACK packets, and the side that closes first sits in a TIME_WAIT state for a couple of minutes to make sure stray packets are gone before the port is reused.

Use TCP when correctness matters more than the last few milliseconds: web pages, APIs, file transfers, database connections, email. If a missing byte would corrupt the result, TCP is the default and correct choice.

The cost is latency and head-of-line blocking. The handshake adds a round trip, and because TCP delivers bytes strictly in order, one lost packet stalls everything behind it even if those later packets already arrived. On a lossy mobile link this hurts. It is also heavier than the alternative: per-connection state, buffers, and timers on both ends.

UDP is the alternative when you would rather drop data than wait for it: live video, voice calls, gaming, and DNS lookups. QUIC, which now carries HTTP/3, was built specifically to fix TCP's weaknesses. It runs reliability and ordering over UDP, folds the TLS handshake into the connection setup so a new connection costs zero or one round trip, and avoids head-of-line blocking across independent streams.

A practical gotcha: opening a fresh TCP connection per request is expensive. That is why HTTP keep-alive, connection pooling in database drivers, and reverse proxies all reuse connections instead of paying the handshake cost repeatedly.

Load a page on amazon.com and TCP is doing the heavy lifting underneath. Your browser resolves the IP, opens a TCP connection to port 443, and the three-way handshake completes in one round trip. The TLS handshake then runs on top of that reliable channel, and finally the HTTP request goes out.

Amazon, like most large sites, keeps these connections alive and reuses them for many requests so it does not pay the handshake tax on every image and script. Their load balancers terminate millions of concurrent TCP connections, and the TIME_WAIT state at that scale is a real tuning concern, which is why operators adjust kernel parameters like net.ipv4.tcp_tw_reuse and ephemeral port ranges.

On the data side, congestion control decides how fast bytes flow. Netflix serves video over TCP from its Open Connect appliances and tunes the congestion algorithm so a single stream can fill a fat pipe quickly without starving other users sharing the same link.