Learn IT Fundamentals with Teacher PochiKey points
- The Web is something everyone uses as a natural part of daily life β for shopping, social media, search, and more.
- Behind that everyday experience are building blocks like "Request/Response," "Protocol," "Domain," "Cookie," "Session," and "Cache."
- Let's understand what these elements are made of, and what technology makes them work.
Teacher Pochi uses the Web like this every day, too
What is the "Web," anyway?
The Web is a mechanism that lets you view and interact with information stored on servers around the world, through a browser.
It's built on two roles: the "client" (the device or browser the user operates) and the "server" that provides information. The client asks the server, "please give me this information," and the server responds β this exchange repeats over and over.
(PC, phone, tablet, etc.)
β "Sure, here you go"
Teacher Pochi's hintThis is like walking into a shop, where the staff shows you to a seat and hands you a menu. When your browser visits a server, the server gets the information ready and shows it to you in just the same way.
Requests and responses
The ask a browser sends to a server is called a "request," and the server's reply is called a "response."
Requests come in different "types," called "methods." The two you'll see most are "GET," used to fetch a page's information, and "POST," used to submit form input. Opening this page used GET, for example, while submitting the contact form uses POST.
For example, when you open https://hassan-learning-portal.com/ in a browser, the following four steps happen.
(no data)
the same HTML
response
on screen
(data attached)
your data
with the result
on screen
Teacher Pochi's hintWhen you sit down at a restaurant, water and a wet towel show up without you ordering anything β that's GET. But your meal only arrives once you actually order it β that's POST.
What is HTTP?
HTTP (HyperText Transfer Protocol) is the common rule set (protocol) that browsers and servers use to exchange information. The "request"/"response" exchange from the previous slide, and methods like GET and POST, are all defined within this same set of HTTP rules.
The "http" at the start of a URL means "talk to this URL using the HTTP protocol." "https" means the same thing, but over an encrypted, secure connection (more on that in a later slide).
The server's response comes with a "status code" like the ones below.
Teacher Pochi's hintThink of a status code as a one-line reply from a shop clerk: "It's ready for you (200)," "There seems to be an issue with your order (400s)," "We can't help with that right now (500s)" β each sums up the outcome in a word.
How URLs and domains work
You use URLs every day without a second thought β but break one down, and it's actually made up of the following parts.
A URL is like an address that specifies "which server, and which piece of information on it, to access."
https://Protocolhassan-learning-portal.comDomain/en/topics/web-fundamentals/overview.htmlPathThe domain is "the server's address," and the path is "where the content lives on that server." Even on the same server (domain), a different path shows a different page. We cover this in more detail in the dedicated domain topic.
Teacher Pochi's hintHere's how I like to picture it: the domain is a "building's address" and the path is "the room number inside the building." Even with the same address (domain), a different room number (path) leads you somewhere different (a different page is shown).
HTTP "doesn't remember state"
HTTP has a property called "stateless," meaning the relationship resets after every single exchange. In other words, a server generally doesn't remember "who sent what a moment ago."
makes a request
"nice to meet you"
requests again
"nice to meet you" again
Even when the request comes from the same client, the server has no way of telling that. But on the Web sites you use every day, that's not actually what happens. Once you log in, you stay logged in, and anything you add to your cart stays right where you left it. A mechanism called a "session" is what makes that possible.
Teacher Pochi's hintPicture a forgetful shop clerk who greets you with "nice to meet you" every single time β that's HTTP for you! Since they don't remember what you ordered last time, they can't treat you like a regular customer as things stand.
How session management works
A mechanism called a "session" is what keeps recognizing the same user over time. First, the server issues each user an identifying number called a "session ID" and hands it to the client. The client then includes that session ID in every request from then on, so the server can recognize "oh, it's this same person" each time.
a session ID
the session ID
the session ID
recognizes them
But you probably don't remember ever being told a session ID, or typing one in yourself. And if you were paying close attention to the GET explanation earlier, you might be wondering β GET doesn't send any data, so how does the session ID even reach the server? The next slide's "cookie" mechanism answers exactly that.
Teacher Pochi's hintIt's a lot like the number you get at a hospital reception desk. Show that same number at the cashier or the pharmacy window later, and they instantly recognize you as "the same person as before."
The roles of cookies and sessions
A cookie is a mechanism for storing a small piece of data on the browser side. From then on, requests to the matching domain generally have the cookie enclosed alongside them (though an expired cookie, or certain security settings, can stop it from being sent).
Cookies are created per domain, and can be rewritten not just by the server, but from the client side too (e.g. by JavaScript).
The "session ID" from the previous slide is actually stored in this cookie. By keeping the server-issued session ID as a cookie, the client can attach that same session ID to every request from then on.
visit
a session ID
with the session ID
with the session ID
the cookie's contents
the user
Together, these two mechanisms make it possible to "move between pages while staying logged in." We cover this in more detail in the dedicated cookie and session topics.
Teacher Pochi's hintIt's a lot like a wristband at an amusement park. At the entrance, they write a number on the wristband and put it on you β after that, you don't need to show it deliberately each time; staff just glance at it as you pass through the gate.
The role of caching
A cache is a mechanism that temporarily stores data you've already fetched once, so it can be reused the next time it's needed.
fetch from the server
data locally
reuse the stored copy
generate the data
the server
reuse the kept copy
There are two kinds of caching: "client-side caching," which keeps data close at hand on your own device, and "server-side caching," which keeps data the server already generated once. Each speeds things up in a different way.
Client-side caching skips the request to the server entirely, since it just redisplays the copy you already have. Server-side caching, on the other hand, shortens the processing time by returning a saved copy instead of regenerating it from scratch every time. We cover this in more detail in the dedicated cache topic.
Teacher Pochi's hintI like to think of it as keeping a stock of seasonings you use often in the kitchen cupboard, instead of going out to buy them every time. What's already on hand can be used right away, saving you the trip (the request to the server).