What the internet actually is
The internet is a huge number of computers connected by cables, fiber, and radio, all agreeing to pass messages to each other. That is it. Everything else in this course is detail about how those messages are addressed, delivered, and understood.
Why learn this? Because every program you will ever ship talks over a network, and every outage ticket you will ever get, whether "the site is down", "the app cannot reach the server", or "login broke", is really the question of which link in the chain failed. This course teaches the chain link by link, so those tickets become checklists instead of mysteries.
Two roles matter from day one:
- A client is the computer that asks for something. Your laptop running a browser is a client, and your phone running an app is a client.
- A server is a computer that waits for requests and answers them. It is usually an ordinary computer in a data center, running a program that listens for incoming messages.
The conversation always has the same shape: the client sends a request, meaning something like "give me the homepage", and the server sends back a response, meaning "here it is" plus the page itself. One request, one response. Web pages, videos, and app data all arrive this way, request by request.
Identifying the client in an exchange
When a weather app on your phone shows today's forecast, the client is your phone.
The client is whoever asks. Your phone sent the request for today's forecast, which makes it the client, and the weather company's computer waited for that request and answered it, which makes it the server.
Apps and browsers both work this same request-and-response way, and neither role is about how powerful the machine is. A phone asking a small server is still the client.
The roles are also per-conversation rather than permanent. That weather server is a client itself when it goes off to fetch data from a forecasting service, which is worth knowing before you meet backend services that spend their day calling each other.
Protocols: the agreed rules
For a request to make sense, both sides must agree on the exact format of the messages. That agreement is called a protocol. A protocol is just a written set of rules: what a message looks like, byte by byte, and what each part means.
You will meet a small family of protocols in this course, and each has one job:
| Protocol | Job |
|---|---|
| IP | Gets a chunk of data to the right computer |
| TCP | Makes delivery reliable (nothing lost, nothing out of order) |
| DNS | Turns names like example.com into addresses |
| HTTP | The language of web requests and responses |
| TLS | Encrypts the conversation (the S in HTTPS) |
Do not memorize this table. You will build each one up slowly, and by the end of the course this table will feel obvious.
What a protocol is
A protocol is an agreed set of rules for the format and meaning of messages.
It is an agreement, not a thing. Nothing is installed and nothing is shipped. If both computers format their messages by the same rules, they can talk, even when they were built by different companies and run entirely different software.
HTTP, TCP, IP, DNS, and TLS are all such rulebooks, and that interoperability is the whole reason the internet works. A browser written by one company reaches a server written by another because both read the same specification.
It also explains why protocols change so slowly. Anything that breaks the agreement breaks every existing participant, so new versions are designed to be ignorable by software that has not been updated.