Demystifying the Web 2: The Language of the Internet
Source: Dev.to
Episode 2 – Networking Protocols that Power the Web
In Episode 1 we walked through the basics of how the web works: typing a URL, DNS look‑ups, secure connections, and rendering the page. We only skimmed the surface of TCP and HTTP.
Now we’ll dig deeper into the networking protocols that make data move reliably and fast across the Internet. We’ll start with the low‑level transport protocols and work our way up to the application‑layer languages that browsers and servers use.
1. Transport Layer – How data packets travel between two machines
Think of the transport layer as choosing between a careful courier (reliable but slower) and a fast bike messenger (quick but less reliable).
| Protocol | Key Characteristics | Typical Use‑Cases |
|---|---|---|
| TCP (Transmission Control Protocol) | • Connection‑oriented – establishes a virtual connection with a three‑way handshake before data flows. • Breaks data into numbered segments; reassembles them in order on the receiver side. • Waits for ACKs, retransmits lost segments, guarantees in‑order delivery. • Performs flow‑control and congestion‑control to avoid overwhelming the network. • Extra overhead → slightly higher latency. | Web browsing, email, file transfers, any situation where correctness matters more than speed. |
| UDP (User Datagram Protocol) | • Connectionless – no handshake, no tracking of individual packets. • No built‑in retransmission, ordering, or congestion control. • Minimal overhead → lower latency and more predictable timing. • Small amount of loss is acceptable. | Live streaming, video conferencing, online gaming, VoIP calls – real‑time scenarios where speed trumps reliability. |
2. Application Layer – The language browsers and servers use to talk
Once TCP or UDP has moved the packets, the web needs a protocol for request/response communication.
2.1 HTTP (Hypertext Transfer Protocol)
Defines how a client (e.g., a browser) sends a request and how a server replies.
- Text‑based, request‑response protocol.
- A client asks for a resource (HTML, CSS, JSON, …).
- The server responds with a status line, headers, and an optional body.
- Classic HTTP/1.1 runs over TCP, inheriting TCP’s reliability and ordering guarantees.
2.2 HTTPS (HTTP Secure)
Not a different application protocol – it is simply HTTP inside a TLS‑encrypted tunnel.
- Before any HTTP messages are exchanged, the client and server perform a TLS handshake to agree on keys, ciphers, and to authenticate the server’s certificate.
- Think of it as “wrap every byte of HTTP inside TLS at the transport layer.”
- Modern browsers treat plain HTTP as “not secure” and strongly prefer HTTPS everywhere.
2.3 HTTP/3 (QUIC)
- HTTP/2 improved performance by multiplexing many HTTP streams over a single TCP connection, but it still suffered from head‑of‑line (HOL) blocking: if one TCP packet is lost, all later packets for that connection are held back.
- HTTP/3 runs over QUIC, a transport protocol built on top of UDP.
- QUIC provides its own reliability, encryption (TLS 1.3 integrated), and congestion control.
- It is stream‑aware: each HTTP stream is independent, so loss on one stream does not block the others.
- Result: reduced HOL blocking, faster page loads, and more resilience on flaky mobile or Wi‑Fi networks.
- Major browsers are gradually adopting HTTP/3 for many large sites.
3. Real‑Time & Legacy Protocols – Beyond classic web pages
Not everything on the Internet fits neatly into “HTML + CSS.” Below are some additional protocols you’ll encounter.
3.1 WebSockets
- Solves the limitation of HTTP where the client must always initiate the conversation.
- The browser upgrades an existing HTTP connection to a full‑duplex protocol that keeps a single TCP connection open for bi‑directional communication.
3.2 Email Protocols
| Protocol | Purpose | Transport |
|---|---|---|
| SMTP (Simple Mail Transfer Protocol) | Sends email between mail servers. | TCP (usually port 25) |
| IMAP (Internet Message Access Protocol) | Retrieves messages while keeping them on the server; synchronizes across devices. | TCP (port 143/993 for TLS) |
| POP3 (Post Office Protocol v3) | Downloads messages to a local device and typically removes them from the server. | TCP (port 110/995 for TLS) |
3.3 File‑Transfer Protocols
| Protocol | Description | Security |
|---|---|---|
| FTP (File Transfer Protocol) | One of the oldest file‑transfer methods; uses separate control and data channels over TCP. | Plain‑text (no encryption) |
| SFTP (SSH File Transfer Protocol) | Transfers files over SSH using a single encrypted channel for both commands and data. | Strong encryption (SSH) |
| FTPS (FTP Secure) | FTP with TLS/SSL encryption (either explicit or implicit mode). | TLS/SSL encryption |
4. Recap
- Transport layer: TCP (reliable) vs. UDP (fast).
- Application layer: HTTP → HTTPS → HTTP/3 (QUIC).
- Specialized protocols: WebSockets, SMTP/IMAP/POP3, FTP/SFTP/FTPS.
Understanding these building blocks helps you see why the web feels fast, reliable, and secure—and where the trade‑offs lie when you need real‑time interaction or legacy support.
Next episode we’ll explore how browsers render those resources into the pages you see on screen.
FTPS – File Transfer Protocol Secure (often written as FTPS), which runs FTP over SSL/TLS to add encryption on top of the traditional FTP model.
From TCP and UDP at the transport layer to HTTP, HTTPS, WebSockets, SMTP, and FTP at the application layer, these protocols are the invisible glue that holds the internet together. Each one solves a slightly different problem:
- Reliable delivery – TCP
- Low‑latency, connectionless communication – UDP
- Web page retrieval – HTTP
- Secure web browsing – HTTPS (HTTP + TLS)
- Real‑time, bidirectional updates – WebSockets
- Email transmission – SMTP
- File transfer – FTP (or FTPS for encrypted transfers)
When you type prasunchakra.com or open your favorite app, you are really triggering a carefully layered conversation between machines, with each protocol playing its part in the stack.
As you build web apps, APIs, or backend systems, understanding these layers helps you:
- Reason about performance issues
- Make informed security choices
- Diagnose why things sometimes break in “mysterious” ways on real networks
In future episodes, we will zoom into specific pieces of this puzzle.