In the previous chapter, we looked at Network Devices — the physical hardware, such as switches, routers, and modems, that actually forms a network. But hardware alone isn't enough for two devices to communicate meaningfully. Every device on a network still needs to agree on a common set of rules describing exactly how data should be formatted, sent, received, and interpreted, and that's exactly what a network protocol provides.
A network protocol is a defined set of rules that governs how communication takes place between devices on a network. Without a shared protocol, one device might send data in a format the other device has no way of understanding, in the same way that two people speaking entirely different languages would struggle to hold a meaningful conversation, even while standing right next to each other. This chapter looks at five of the most important and widely used protocols on the internet today: HTTP, HTTPS, FTP, SMTP, and DNS.
A network protocol precisely defines things like the format a message must follow, the order in which information should be exchanged, how a device should respond to a particular kind of request, and how errors or unexpected situations should be handled. Different protocols are designed for very different purposes — some are built for browsing websites, others for transferring files, sending emails, or translating human-friendly names into the numerical addresses computers actually use. Each protocol covered in this chapter solves one particular kind of communication problem, and together they form much of the foundation the modern internet is built on.
HTTP, short for HyperText Transfer Protocol, is the protocol responsible for transferring web pages and other resources between a web browser and a web server. Whenever a person types a website address into their browser or clicks a link, the browser uses HTTP to send a request to the server hosting that website, asking for the specific page, image, or other resource the person wants to view. The server then responds using the same protocol, sending back the requested content along with some additional information describing that response.
HTTP follows a request-response model, meaning every exchange begins with a client, usually a web browser, sending a request, and ends with the server sending back a corresponding response. Each request includes a method describing the action being requested, such as retrieving a page or submitting a form, and each response includes a status code indicating whether the request succeeded, failed, or needs further action. HTTP is what's known as a stateless protocol, meaning each individual request is treated independently by the server, without automatically remembering anything about earlier requests from the same client, unless additional mechanisms are used to maintain that continuity.
HTTPS, or HTTP Secure, is essentially the same protocol as HTTP, extended with an additional layer of encryption to protect the data being exchanged between the browser and the server. While standard HTTP transmits data as plain, readable text, meaning anyone intercepting that traffic could potentially read it, HTTPS wraps that same HTTP communication inside an encrypted connection, scrambling the data so that only the intended sender and receiver can actually make sense of it.
This encryption is typically established using a security protocol that performs a process often referred to as a handshake, during which the browser and server agree on encryption methods and exchange the necessary security credentials before any actual data is transmitted. Once this secure connection is established, all subsequent HTTP requests and responses travel through it protected from eavesdropping and tampering. Because of the added protection it offers, particularly for sensitive activities like logging into an account or entering payment details, HTTPS has become the standard, expected protocol for nearly all modern websites, and browsers now commonly flag websites still using plain HTTP as insecure.
FTP, short for File Transfer Protocol, is a protocol specifically designed for transferring files between two devices over a network. Unlike HTTP, which is generally used for browsing and displaying content directly within a web page, FTP is built specifically around efficiently uploading and downloading files between a client device and an FTP server, and is commonly used by website administrators to upload website files, and by organisations to share large files internally or with external partners.
A notable feature of FTP is that it typically uses two separate connections between the client and the server: one dedicated to sending commands, such as requesting a file listing or initiating a file transfer, and a second, separate connection dedicated purely to the actual transfer of file data itself. This separation allows commands to be exchanged even while a large file transfer is still in progress. FTP also supports user authentication, allowing a server to restrict file access to only those users who provide valid login credentials, although some FTP servers also allow limited public access without requiring a personal account.
SMTP, or Simple Mail Transfer Protocol, is the protocol responsible for sending email messages from a sender's mail client or mail server onward to the recipient's mail server. Whenever someone sends an email, their email application typically hands that message over to a mail server using SMTP, and that server then uses SMTP again to relay the message onward, potentially through one or more additional servers, until it finally reaches the mail server responsible for the recipient's mailbox.
It's worth noting that SMTP is specifically used for sending and relaying outgoing mail, not for retrieving messages that have already arrived in a mailbox. Reading and downloading received emails is instead typically handled by separate protocols designed for that purpose. SMTP essentially acts as the postal delivery system of the email world, focused entirely on reliably getting a message from its point of origin to the correct destination mail server, leaving the job of presenting that message to the end user to other parts of the overall email system.
DNS, or Domain Name System, solves a very different problem from the other protocols covered so far. Computers on a network identify each other using numerical IP addresses, but remembering a long string of numbers for every website a person wants to visit would be impractical. DNS acts as a translation system, converting human-friendly domain names, such as a website's familiar name, into the numerical IP address that a browser actually needs in order to connect to the correct server.
When a browser needs to visit a particular website, it sends a DNS query asking for the IP address associated with that website's domain name. This query is typically handled by a DNS server, which either already has that information stored from a previous lookup, or forwards the query onward to other DNS servers until the correct IP address is eventually found and returned. Once the browser receives this IP address, it can then use it to establish an actual connection to the correct server, often using HTTP or HTTPS to request the desired page. Because so many other protocols rely on first knowing the correct IP address to connect to, DNS is often described as functioning much like a phonebook for the internet, quietly working behind the scenes before almost every other kind of network communication can even begin.
Although each of these five protocols solves a distinct problem, they very often work together in a single, ordinary user action. For example, simply visiting a secure website typically begins with a DNS lookup to find the server's IP address, followed by an HTTPS connection being established to that server, during which encrypted HTTP requests and responses are exchanged to actually load the page. Sending an email might involve a mail client using SMTP to hand off the message to a mail server, which itself may rely on DNS to determine which server is responsible for the recipient's domain before relaying the message onward. Understanding each protocol individually makes it much easier to see how these pieces fit together to support the everyday internet activities most people take for granted.
| Protocol | Full Form | Primary Purpose |
|---|---|---|
| HTTP | HyperText Transfer Protocol | Transferring web pages and resources between browser and server |
| HTTPS | HTTP Secure | Same as HTTP, with encryption added for secure communication |
| FTP | File Transfer Protocol | Uploading and downloading files between client and server |
| SMTP | Simple Mail Transfer Protocol | Sending and relaying outgoing email messages |
| DNS | Domain Name System | Translating domain names into IP addresses |
| Mistake | Correct Practice |
|---|---|
| Thinking HTTPS is a completely different protocol from HTTP. | HTTPS is HTTP combined with an added layer of encryption, not an unrelated protocol. |
| Assuming FTP is used for browsing websites like HTTP. | FTP is specifically designed for transferring files, not for displaying web pages. |
| Believing SMTP is also used to read incoming email. | SMTP only handles sending and relaying outgoing mail; retrieving messages is handled separately. |
| Forgetting that DNS runs before other protocols can connect to a server. | Remember that a domain name usually must be resolved into an IP address through DNS before communication can begin. |
Network Protocols provide the shared rules that allow devices across a network to actually understand and communicate with each other. We looked at HTTP and HTTPS, which govern how web content is requested and delivered, with HTTPS adding encryption for security; FTP, which handles transferring files between a client and a server; SMTP, which sends and relays outgoing email; and DNS, which translates domain names into the IP addresses needed to actually connect to a server.
With a solid understanding of how these protocols enable communication over a network, you are now ready to move on to IP addressing, which explains how the IP addresses referenced throughout this chapter are actually structured and assigned to devices.