Backend Transport
TCP/IP and OSI: The Foundation of Everything
Every time a web page opens, the browser performs a TCP handshake in 20-200 ms, and the data passes through all 7 OSI layers - twice. This happens so fast it goes unnoticed. But when something breaks - a slow site, a dropping WebSocket, unresolved DNS - understanding these layers becomes the only way to find the problem.
- **Cloudflare** handles 55+ million HTTP requests per second - each one starts with a TCP handshake (or QUIC over UDP for HTTP/3)
- **Zoom** uses UDP for video and audio, because TCP retransmission delay (100-300 ms) destroys call quality
- **Google** saved billions of requests by switching to HTTP/3 (QUIC over UDP) - 8% faster under packet loss
Предварительные знания
TCP/IP: born in Cold War conditions
In 1974, Vint Cerf and Bob Kahn published 'A Protocol for Packet Network Intercommunication' under a DARPA contract. The military requirement: the network must continue operating even if some nodes are destroyed. This explains packet-switching over circuit-switching: there is no single line of communication to be cut. TCP/IP became the internet standard in 1983 when ARPANET switched from NCP to the new stack.
The OSI Model: 7 Network Layers
Cloudflare handles 55+ million HTTP requests per second. Each one passes through all 7 OSI layers - twice. In normal operation this is invisible. When something breaks - a slow site, a dropping WebSocket, unresolved DNS - understanding the layers becomes the only way to find the problem.
The **OSI model (Open Systems Interconnection)** breaks network communication into 7 layers. Each layer solves one task and knows nothing about the details of others. Like the postal system: the author writes a letter (layer 7), puts it in an envelope (layer 6), takes it to the post office (layer 5), the post office sorts it (layer 4), loads it into a truck (layer 3), the truck drives on the road (layer 2), the road exists physically (layer 1).
In practice, the **TCP/IP** model with 4 layers is used more often: Link (1-2), Internet (3), Transport (4), Application (5-7). OSI is a theoretical model for understanding, TCP/IP is the actual architecture of the internet.
Backend developers work at layers 4-7. Writing a REST API is layer 7 (Application). Choosing TCP or UDP is layer 4 (Transport). Configuring TLS is layer 6 (Presentation). Layers 1-3 are provided by infrastructure.
Each layer adds its own **header** to the data - this is **encapsulation**. An HTTP request is wrapped in a TCP segment, which is wrapped in an IP packet, which is wrapped in an Ethernet frame. On the receiving side the wrappers are stripped in reverse order.
At which OSI layer does the HTTP protocol operate?
TCP vs UDP: Reliability or Speed
Zoom uses UDP for video and audio. TCP retransmission delay (100-300 ms) destroys call quality. Google saved billions of requests by switching traffic to HTTP/3 (QUIC over UDP) - 8% speed gain under packet loss. The choice of layer-4 protocol is not a technical nuance but an architectural decision with business consequences.
**TCP (Transmission Control Protocol)** - reliable delivery. Like registered mail: delivery guarantee, acknowledgment, retransmission if lost, data arrives in the correct order. The cost - additional delays.
**UDP (User Datagram Protocol)** - fast delivery without guarantees. Like a flyer dropped in a mailbox: sent and forgotten. No acknowledgment, no order guarantee, no retransmission. Minimal latency and overhead.
| Characteristic | TCP | UDP |
|---|---|---|
| Connection | Established (handshake) | Connectionless |
| Delivery guarantee | Yes (ACK + retransmission) | No |
| Data order | Guaranteed (sequence numbers) | Not guaranteed |
| Flow control | Yes (flow control, congestion control) | No |
| Header overhead | 20-60 bytes | 8 bytes |
| Speed | Slower (due to guarantees) | Faster (minimal overhead) |
| Use cases | HTTP, SMTP, FTP, databases | DNS, video calls, games, VoIP |
HTTP/1.1 and HTTP/2 run on top of TCP. HTTP/3 (QUIC) is a revolution: it runs on top of **UDP**, but implements reliability at the application layer. This gives UDP speed with TCP guarantees, without TCP's limitations (head-of-line blocking).
The choice between TCP and UDP depends on what matters more: **data integrity** or **minimal latency**. For an API request, a lost packet means a broken response - TCP. For a video call, a lost frame means a micro-glitch that is better to skip than wait for retransmission.
Why do online games (e.g., CS2) use UDP instead of TCP?
TCP Handshake: The Three-Way Handshake
HTTP/1.1 performed a new TCP handshake for every request. With an RTT of 100 ms (client to server in a different region), connection setup alone consumed 150 ms before the first byte of data. That is what drove keep-alive, HTTP/2 multiplexing, and eventually QUIC. Understanding why means understanding the TCP handshake.
**SYN** (synchronize) - the client sends its initial sequence number. **SYN-ACK** - the server acknowledges receipt and sends its own sequence number. **ACK** (acknowledge) - the client acknowledges the server's sequence number. Now both know each other's numbers and can track packet order.
**Sequence numbers** are generated randomly (not from zero) to protect against TCP sequence prediction attacks. If numbers started from 0, an attacker could forge packets by guessing the number.
The handshake is overhead. With an RTT of 50 ms (e.g. Moscow to London), just establishing the connection takes 75 ms. That is why HTTP/1.1 uses **keep-alive** (connection reuse), and HTTP/2 multiplexes requests over a single connection.
TCP and Military Networks
TCP/IP was developed by Vint Cerf and Bob Kahn in 1974 under a DARPA contract. The main requirement: the network must continue to work even if part of the nodes are destroyed (Cold War context). That is why TCP is designed for unreliable channels - it assumes that packets WILL be lost and has recovery mechanisms built in. TCP/IP became the internet standard in 1983 when ARPANET switched from NCP to the new stack.
The server received a SYN from the client. What does it send in response?
Sockets and Ports
nginx on port 443 handles 10,000 simultaneous connections while occupying exactly one port. An IP address identifies a **machine** on the network. But one machine can run a dozen services: web server, database, SSH, mail. The operating system knows which process to deliver an incoming packet to through **ports**.
A **port** is a 16-bit number (0-65535) that identifies a specific process on a machine. IP + port = a unique address of a process on the network. Like an apartment number in a building: IP is the building address, port is the apartment number.
| Range | Name | Examples |
|---|---|---|
| 0-1023 | Well-known ports (require root) | 80 (HTTP), 443 (HTTPS), 22 (SSH), 5432 (PostgreSQL) |
| 1024-49151 | Registered ports (assigned to applications) | 3000 (Node.js dev), 6379 (Redis), 8080 (HTTP alt) |
| 49152-65535 | Dynamic/Ephemeral ports (assigned by OS to clients) | Automatically assigned for outgoing connections |
A **socket** is a combination of an IP address and a port - an endpoint for network communication. A TCP connection is uniquely identified by a **4-tuple**: (client_IP, client_port, server_IP, server_port). One server port (e.g. 443) can serve **thousands** of simultaneous connections - each client has its own IP and ephemeral port.
Starting NestJS on port 3000 creates a server socket bound to `0.0.0.0:3000`. Every incoming HTTP request is a new client socket with a unique (client_ip, client_port) pair.
Sockets and ports are the foundation for everything that follows. Every HTTP request, gRPC call, WebSocket connection - all of these are sockets at the transport layer. The only difference is what happens **inside** those connections at the Application layer.
UDP is unreliable - meaning it's a bad protocol that's better to avoid
UDP is a protocol with minimal overhead, ideal for scenarios where speed matters more than per-packet delivery guarantees
'Unreliable' in the context of UDP means 'without built-in delivery guarantees' - this is an architectural decision, not a defect. Video calls (Zoom, Discord), online games (Fortnite, CS2), DNS queries, IoT telemetry - all use UDP. HTTP/3 (QUIC) is also built on top of UDP because implementing reliability at the application layer turned out to be more efficient than TCP's constraints.
A web server listens on port 443. Ten thousand users connect simultaneously. How many server ports are occupied?
Key Takeaways
- **The OSI model** divides the network into 7 layers - backend developers primarily work at layers 4-7 (Transport to Application)
- **TCP** guarantees delivery and data order at the cost of additional overhead (handshake, ACK). **UDP** - minimum latency, but no guarantees
- **TCP three-way handshake** (SYN - SYN-ACK - ACK) establishes a connection before data transmission in 1.5 RTT
- **Socket = IP + Port** - a unique endpoint on the network. One server port serves thousands of connections thanks to the 4-tuple
Related Topics
TCP/IP is the foundation on which all application-layer protocols are built:
- Transport Overview — All transports from the previous lesson work on top of TCP or UDP
- Serialization — Data transmitted over TCP/UDP must be serialized into bytes
- DNS and TLS — DNS (UDP) resolves domains to IPs, TLS (over TCP) encrypts the connection
Вопросы для размышления
- When starting a local server on port 3000 and opening localhost:3000 in a browser - what TCP handshake steps happen even though client and server are on the same machine?
- Why did HTTP/3 move from TCP to UDP (QUIC), if TCP is more reliable? What TCP problem does this solve?
- If designing a protocol for smart temperature sensors sending readings every second - TCP or UDP? Why?
Связанные уроки
- bt-01-overview — Transport overview establishes the context for understanding TCP/IP
- bt-03-serialization — Serialization is the next layer: what travels inside TCP
- bt-04-dns-tls — DNS (UDP) and TLS (TCP) build on concepts from this lesson
- sec-01 — TLS and network security start from understanding the TCP handshake
- devops-05 — Network diagnostics in devops: tcpdump, netstat - working at the socket level
- web-01 — HTTP is an application-layer protocol built on top of TCP covered here
- net-15-tcp-basics