Layers and How a Connection Opens

1OSI and TCP/IP layering

Meera taps https://shop.rao.example/tea on her phone. That tap is not one blob on the wire. The phone builds a stack of wrappers: the HTTP request (what page she wants), a TCP segment (how those bytes will be delivered in order), an IP packet (which machine should receive them), and a Wi-Fi frame (this hop to the home router). Each wrapper is a layer — a job with its own header, the extra bytes in front that the next machine will read.

Two naming systems describe the same stack. OSI names seven jobs top-down: Application, Presentation, Session, Transport, Network, Data Link, Physical. The Internet's TCP/IP model folds those jobs into four: Application, Transport, Internet, and Link. HTTP sits at Application; TCP at Transport; IP at Internet; Wi-Fi at Link. When someone asks which layer TCP belongs to, they mean that Transport job — OSI number 4, or the TCP/IP name Transport. Same job, two labels.

Figure. OSI's seven names collapse into TCP/IP's four jobs — exam 'which layer?' usually means OSI numbering.

2TCP versus UDP

The tea page must arrive complete and in order. A missing byte would break the HTML. That is why the phone uses TCP: a connection-oriented transport. Connection-oriented means the two ends agree they are talking before data moves. TCP then numbers bytes, waits for acknowledgements (short 'I got that' messages), and resends what was lost.

UDP is the other transport: connectionless. Each UDP datagram — one self-contained message — stands alone. Nothing resends it. Nothing puts late pieces back in order. Use TCP when every byte matters (the web page, mail, a file). Use UDP when a late packet is worthless (a live voice sample, a game tick) or when the app will retry itself (a DNS name lookup). UDP's header is 8 bytes; TCP's is at least 20. That size gap is the concrete cost of reliability.

Figure. TCP buys reliability and ordering with a connection; UDP ships datagrams with minimal overhead.

How to pick the transport

1. Must every byte arrive in order?If yes, TCP's reliability and sequencing are the default.
2. Is a late packet useless?If yes — live media, games — UDP avoids retransmission delay.
3. Header costUDP's 8-byte header is the low-overhead cue when the payload is already tiny.

3Three-way handshake

Before any tea-page byte moves, TCP opens a connection with three segments. A segment is one TCP message. SYN means 'I want to start, and here is my starting byte number' — that number is the initial sequence number, ISN. The shop replies SYN-ACK: 'I also want to start, here is my ISN, and I heard yours.' The phone sends ACK: 'I heard yours.' After those three, both sides have agreed on sequence numbers. Data can flow.

The count is three segments to establish, not two and not four. Four is how a graceful close works, later. UDP has no handshake to count — that is what connectionless means.

Figure. Three-way handshake: client SYN, server SYN-ACK, client ACK — three segments to establish.

How the handshake runs

1. SYNClient → server: propose connection and client ISN.
2. SYN-ACKServer → client: accept, send server ISN, acknowledge client ISN.
3. ACKClient → server: acknowledge server ISN; connection is established.

4Four-way teardown

When Meera leaves the page, each direction of the byte stream shuts on its own. TCP is full-duplex: phone-to-shop and shop-to-phone are two one-way pipes sharing one connection. One side sends FIN ('I am done sending'); the other ACKs that direction. Later the other side sends its own FIN; the first ACKs. Two FIN/ACK pairs — four segments.

A single FIN does not close both pipes. That is why graceful teardown is four segments while the open was three. An RST is a different, abrupt reset, not this graceful close.

Figure. Each side closes its direction with FIN; each FIN is ACKed — four segments when close is independent each way.

How a graceful close runs

1. FIN + ACKActive closer sends FIN; peer ACKs that direction.
2. Other FIN + ACKPeer later sends its FIN; active closer ACKs.
3. CountFour segments total for graceful close; remember setup was three.

5TCP and UDP header sizes

A header is the extra bytes in front of the payload. The tea HTML is the payload; the header names the ports and options. A port is a number on one machine that says which program should receive the bytes: 443 for this HTTPS page, 53 for a DNS lookup. UDP's header is a fixed 8 bytes: source port, destination port, length, checksum. TCP's header is at least 20 bytes and grows when options (timestamps, window scale) are present.

That is why people say UDP is low-overhead: every datagram pays 8 bytes of tax; every TCP segment pays at least 20 before the first payload byte.

Figure. UDP's 8-byte header is the overhead story; TCP and IPv4 start at 20 bytes each before options.

6When the phone picks TCP or UDP

Meera's phone already made two transport choices for one tap. The name lookup for shop.rao.example is a tiny question that can be asked again if it fails — UDP. The tea page itself must be complete — TCP. The words that decide are about the job: if loss is unacceptable, pick TCP; if a late packet is useless, pick UDP.

Do not mix this choice with the three-way open or four-way close counts. Those counts describe TCP's life cycle. UDP has no handshake to count.

Read the stem for reliability, ordering, and connection setup. Words like reliable byte stream or handshake point to TCP; fire-and-forget datagram or streaming media without setup point to UDP. The cue table is the artefact — no diagram adds a third protocol.

How to read the stem

1. Reliability wordsIf loss is unacceptable, pick TCP.
2. Latency wordsIf late data is useless, pick UDP.
3. Don't mix counts3-way open / 4-way close answer lifecycle questions, not "which protocol".