Demystifying the Web 2: The Language of the Internet

In Episode 1, we walked through the basics of how the web works. From typing a web address into your browser, through DNS lookups and secure connections, to rendering the page on your screen. We touched on things like TCP and HTTP, but that's just the surface. Now, in Episode 2, let's dig deeper into the networking protocols that power all this communication. These are the building blocks that make data move reliably and fast across the internet. We'll start with the low-level ones and move up.

The Low-Level Workhorses (TCP vs. UDP)

Before the web can talk, it needs a transport layer that decides how data packets are sent between two machines. Think of this as choosing between a careful courier and a fast bike messenger.

• TCP (Transmission Control Protocol): TCP is the “reliable guy” of the transport layer. It is connection oriented, which means it first sets up a virtual connection between your browser and the server using a handshake before any real data flows. Once the connection is established, TCP breaks your data into numbered segments so they can be reassembled correctly on the receiving side, waits for acknowledgements (ACKs) from the receiver and retransmits any lost segments to ensure nothing goes missing, guarantees that all data arrives in the correct order even if packets take different paths through the network, and performs flow control and congestion control so a fast sender does not overwhelm a slow receiver or a congested network. All of this reliability comes with extra overhead and slightly more latency, but it is perfect when correctness matters more than speed. Like Web browsing, Emails or File transfers
• UDP (User Datagram Protocol): This one's all about speed it takes the opposite approach. It is connectionless and focuses on minimal delay. There is no handshake to set up a session, no tracking of which packets arrived, and no built-in mechanism to reorder or retransmit lost data. Because UDP does not spend time on acknowledgements, retransmissions, or congestion algorithms, it has much lower overhead and can be significantly faster and more predictable in terms of latency. That makes it ideal for real time scenarios where a small amount of loss is acceptable, but delay is not. Like live streaming and video conferencing, Online gaming or VoIP calls.

The Web Giants (HTTP, HTTPS, HTTP/3)

Once TCP or UDP has done the hard work of moving packets around, the web needs a language for clients and servers to talk in. That language is HTTP and its secure cousins.

• HTTP (Hypertext Transfer Protocol): Defines how a client (like your browser) sends a request and how a server replies with a response. It is a simple text based, request response protocol.The client asks for a resource (HTML, CSS, JSON, etc.), and the server answers with a status line, headers, and an optional body. By default, classic HTTP (HTTP/1.1) runs over TCP, so it inherits TCP’s reliability and ordering guarantees.

• HTTPS (Hypertext Transfer Protocol Secure): Is not a different application protocol. It is simply HTTP running inside a TLS-encrypted tunnel. The “S” in https://prasunchakra.com means that before any HTTP request–response messages are exchanged, the client and server perform a TLS handshake to agree on keys and ciphers, and to authenticate the server’s identity using its certificate. So you can think of HTTPS as “take normal HTTP and wrap every byte of it inside TLS, at the transport layer.” Today, browsers treat plain HTTP as “not secure” and strongly prefer HTTPS everywhere.

• HTTP/3 (QUIC): HTTP/2 improved performance by multiplexing many HTTP streams over a single TCP connection, but it ran into a TCP level problem called head of line (HOL) blocking. If one TCP packet is lost, TCP must hold back all later packets for that connection until the missing one is retransmitted, which delays every active HTTP stream sharing that connection. HTTP/3 takes a different route by running over QUIC, a transport protocol built on top of UDP. QUIC provides its own reliability, encryption (it uses TLS 1.3 integrated into the transport), and congestion control, but crucially it is stream-aware: it can treat each HTTP stream independently. This significantly reduces head of line blocking and improves perceived performance, especially on flaky mobile or Wi‑Fi networks where packet loss and changing network paths are common. Modern browsers are gradually adopting HTTP/3 for many large sites so that page loads, API calls, and asset fetches feel snappier and more resilient in real-world conditions.

The Real Time & Legacy Layer (WebSocket, SMTP, FTP)

Not everything on the internet fits cleanly into “classic web pages.” Some protocols exist for real time interactions, others are older but still important in the background.

• WebSockets: WebSockets were created to solve a limitation of HTTP that the client always has to initiate the conversation. With WebSockets, the browser and server upgrade an existing HTTP connection, then switch to a protocol that keeps a single TCP connection open and full‑duplex.
  Once the WebSocket is established, both the client and the server can send messages at any time without creating new HTTP requests, the connection remains open until it is explicitly closed which reduces overhead and latency, and messages can be sent as either text or binary frames, making WebSocket flexible for a wide range of real-time use cases.Which include chat apps, live dashboards (like stock prices or sports scores), collaborative tools (Figma, Google Docs‑style editors), multiplayer games, and any UI that needs instant updates pushed from the server.

• SMTP (Simple Mail Transfer Protocol): It is the protocol responsible for sending emails between mail servers. When you hit “Send” in Gmail or Outlook, your client talks to an SMTP server over TCP, hands over the message, and then a series of SMTP servers relay that message until it reaches the recipient’s mail server.
  A simplified flow works as follows: your email client submits the message to your provider’s SMTP server, that server looks up the recipient’s domain using DNS and forwards the email to the destination SMTP server, possibly passing through intermediate relay servers, and finally the recipient’s server accepts the message and stores it in a mailbox where it can later be retrieved using protocols such as IMAP or POP3. IMAP (Internet Message Access Protocol) and POP3 (Post Office Protocol version 3) are email retrieval protocols, with IMAP keeping messages stored and synchronized on the mail server across multiple devices, while POP3 downloads messages to the local device and usually removes them from the server.

• FTP (File Transfer Protocol): This is one of the oldest protocols for transferring files between a client and a server. It uses separate control and data channels over TCP, which historically made it flexible but also a bit of a pain for firewalls and NAT devices.
  Classic FTP has a big downside that the credentials and file contents are sent in plain text, so anyone sniffing the network can potentially see usernames, passwords, and data. Because of this, modern setups usually prefer secure alternatives such as SFTP (Secure File Transfer Protocol), which transfers files over SSH using a single encrypted channel for both commands and data, and FTPS (File Transfer Protocol Secure), 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, secure browsing, real-time updates, email, or file transfer. The key idea to carry forward is this: 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, security choices, and why things sometimes break in “mysterious” ways on real networks. In future episodes, we will zoom into specific pieces of this puzzle.