Understanding Common Internet Terms and Jargon
Simple definitions for internet jargons
In computer science fields there are a lot of technical terms, that look heavy and complicated to people who come from some other domain, and sometimes it is true even for computer science people.
I am just trying to solve this issue by simplifying the terms and understanding it with real-life case scenarios.
Internet Jargons :
PROTOCOLS
HTTP
HTTPS
TLS, SSL CERTIFICATES
SERVER
CLIENT
DNS
COOKIES
SESSION etc.
PROTOCOLS :
Think protocols are just like guidelines, Now you may be confused about what is meant by guidelines So I think you all are familiar with covid days. During COVID, our government declares some rules and guidelines for common people like "maintaining social distancing", wearing masks on the face, etc. Just like this In Computer fields, there are several protocols for different purposes ( just like COVID guidelines were for maintaining safety ), like some for communication, some for sending files, etc.
HTTP for accessing websites.
FTP for file transfer.
TCP/IP for network communication.
Or, you can say that protocols are predefined rules that devices and systems must follow to communicate, transfer data, or perform specific tasks effectively.
Now you might be wondering about the terms HTTP, FTP, and TCP/IP which I used in the protocol section. Don’t worry I will explain everything.
HTTP :
HTTP means HyperText Transfer Protocol. I am pretty sure by reading the full form of HTTP you might not understand it properly. Let’s dive into one by one :
HyperText → The term HyperText means it is simply a text which contains links to other texts. Now you might not heard about links. https://www.youtube.com/ → This is the link you used to access YouTube.
Transfer → The term transfer is quite straightforward, It means just transferring things from one location to another location.
Protocol → The term 'Protocol' refers to a set of rules that allow communication between different systems. We already discussed this in the Protocol section. Now, let's talk about HTTP. HTTP is also a protocol, and its role is nothing more than acting as a 'middleman' between a client (like your browser) and a server (where the website's data is stored).
→ What does 'middleman' mean? Let’s use an analogy to make it clear:
"Imagine you walk into a restaurant and want to order food. You (the client) tell the waiter (the protocol) what you want from the menu. The waiter then communicates your request to the kitchen (the server). The kitchen prepares the food and gives it back to the waiter, who delivers it to you.
In this scenario:
You are like a web browser (the client).
The waiter is like HTTP, which acts as the communication protocol.
The kitchen is the web server that processes your request and provides the data (like a webpage or resource).
The food is the information (e.g., the webpage or content) that is sent back to you."
In this article, we do not specifically study HTTP. Therefore, the types of HTTP and its internal workings are not covered.
HTTPS :
"Both HTTP and HTTPS are protocols used for communication, but HTTPS includes an extra layer of security. Think of it like this:
HTTPS = HTTP + Security (via SSL/TLS).
Now, you might wonder: 'If HTTPS is more secure, does that mean HTTP isn’t secure at all?' The answer is that HTTP works fine for general communication, but it does not encrypt the data being transmitted. This means when you use HTTP, the information you send—like login details or personal data—travels in plain text. Anyone intercepting the communication can easily read or modify the data.
In contrast, HTTPS encrypts the data, making it unreadable to anyone except the intended recipient. This added security makes HTTPS a better choice for sensitive communication, like online banking, shopping, or any exchange of private information.
While both HTTP and HTTPS are good, their use depends on the situation. For example:
HTTP is fine for public websites like blogs or informational pages.
HTTPS is essential for websites where users share personal or sensitive data."
Let's understand it with good real-life scenarios.
Think of it like carrying valuables in a bag. Using HTTP is like carrying them in a transparent bag—everyone along the way can see what’s inside. Using HTTPS is like carrying them in an opaque, sealed bag—no one can see or access what’s inside except the intended recipient.
While HTTP is fine for public, non-sensitive information, HTTPS is crucial for websites handling private or sensitive data, such as online banking or shopping."
TLS :
TLS is what makes HTTPS secure. It adds encryption, authentication, and checks to protect the data sent between your browser and the website. In simple terms, TLS turns HTTP into HTTPS by making sure the communication is private and safe.
Analogy for TLS:
Sealed Envelope with a Wax Seal:
Imagine you’re sending a letter to someone:
Without TLS, you just write your letter and send it in a regular envelope. Anyone can open it, read it, and reseal it without your knowledge.
With TLS, you put your letter in an envelope, encrypt the contents so no one can read it, and seal the envelope with a wax stamp that has your unique signature.
Encryption: Makes the letter unreadable to anyone who doesn’t have the key.
Authentication: The wax seal confirms the sender’s identity, ensuring the letter is from you and not someone pretending to be you.
Data Integrity: If the seal is broken, you know someone tampered with the letter.
Here Wax Seal is working just like SSL Certificates, you may wonder how.
Without an SSL/TLS certificate, your letter is like being sent without any proof of authenticity. Anyone can read or tamper with it, and you have no way of knowing if the person who receives it is trustworthy.
With an SSL/TLS certificate, the letter is sealed with a wax seal that carries a unique signature. This seal confirms the authenticity of the sender (server), ensuring the recipient (the browser) knows that the letter hasn’t been tampered with and that it comes from a legitimate source.
So, in this analogy:
The envelope represents the communication channel.
The letter represents the data being transmitted.
The wax seal represents the SSL/TLS certificate, which proves the server’s identity and ensures data integrity and security.
SERVER :
A server is like a powerful computer that stores, manages, and provides data or services to other computers (called clients) over the internet or a network.
Now, this definition might sound a bit technical with terms like "data," "clients," and "network." Let's make it simpler with an analogy.
Imagine a restaurant:
The server is like the waiter at the restaurant.
When you order food (send a request), the waiter (server) takes your order to the kitchen (where the data is stored) and brings the prepared food (the data) back to you.
In this case, the food is like the data or webpage, and the waiter (server) ensures that your request is fulfilled.
So, in simple terms, the server is just like the waiter who makes sure you get what you asked for from the kitchen. That’s it—nothing more to it!
CLIENT :
A client is a device or software (like a web browser or app) that sends requests to a server to access data, services, or resources over the internet or a network. In simple terms, a client is the "requester."
Imagine a library:
The client is like you, going to the library to borrow books or ask for information.
You (the client) walk up to the librarian (server) and request a book or information.
The librarian then retrieves the book (data) from the shelves (storage system) and gives it to you.
In this analogy:
You are the client making the request.
The librarian is the server fulfilling that request by providing the information or resources.
A client is just a device or application that sends requests to a server to get what it needs—just like asking a librarian for a book at a library.
DNS :
The term DNS stands for Domain Name System. I know it is hard for some of you to understand it just by this simple full form of DNS, Don’t worry I will take the best example to explain it.
DNS is like the phonebook of the internet. It translates human-friendly website names (like google.com) into IP addresses that computers can understand (like 172.217.5.68). This allows you to visit websites by typing in easy-to-remember names instead of complex numbers.
When you type google.com into your browser, it needs to connect to a server that hosts the Google website. But the internet doesn’t use names like google.com to locate servers; it uses IP addresses (like 172.217.5.68). These IP addresses act like the address of the server that hosts the website, similar to how your home has an address for others to find it.
Now, it’s not practical for people to remember long numbers like IP addresses for every website they want to visit. This is where DNS (Domain Name System) comes in.
Analogy:
Imagine a phonebook:
When you want to call someone, you don’t dial their full phone number by memory. Instead, you look up their name in the phonebook to find their phone number.
The DNS is like that phonebook. When you type a website name into your browser (like example.com), DNS looks up the corresponding IP address (the "phone number" of the website) so your browser can connect to it.
In this analogy:
You are the browser (client).
The phonebook is DNS, translating the easy-to-remember website name into the necessary IP address.
The phone number is the IP address of the website.
COOKIES :
Cookies are small pieces of data that websites store on your computer or device. These cookies help websites remember things about you, like your login information, preferences, and activity, to improve your browsing experience.
Cookies Analogy:
Imagine you’re going to a coffee shop:
When you order your first cup of coffee, the waiter asks for your name and how you like your coffee (e.g., size, type of milk, sweetness).
The waiter writes this information down on a card and keeps it in a drawer so they can prepare your coffee exactly the way you like it next time.
When you visit the shop again, you don’t need to tell them your preferences—they already have them stored on the card, so they can serve you faster and more efficiently.
In this analogy:
The card is like the cookie.
The waiter and coffee shop are like the website, which stores your preferences.
The stored preferences are like the information cookies store on your device (such as login info or preferences).
Cookies are like a preference card at a coffee shop. They store your choices so that the next time you visit, the website (or coffee shop) can give you exactly what you like without needing to ask again.
You can check your cookies in your browser by right-clicking, selecting 'Inspect', and then going to the 'Application' tab.
SESSIONS :
Imagine you're at a theme park:
When you enter, you buy a ticket, and the park staff gives you a wristband. The wristband helps the staff remember things like your ride preferences, whether you've paid for special privileges, or if you’ve already entered certain attractions.
As you move around the park, the staff can check your wristband to remember you and provide the service you're entitled to (like access to specific rides).
But when you leave the park and the wristband is taken off, your connection to that experience is ended. If you come back the next day, you'd need a new wristband (session) because it’s no longer valid after you leave.
In this analogy:
The wristband is like a session. It stores temporary information about you and your activity while you’re using the service.
The theme park staff is like the website or server, which uses the session to track what you're doing during your visit.
The end of the day or leaving the park is like the session expiring after you stop using the service or close the website.
But with this analogy, it is hard to distinguish between cookies and sessions. Let’s take a closer look at how sessions and cookies differ from each other.
Difference Between Cookies and Sessions :
Storage Location :
→ Stored on the client side (the user's device, such as the browser).
→ Stored on the server side (on the web server).
Lifetime :
→ cookies stay on the user's device for a set period (e.g., days, months) unless deleted manually or by the server.
→ Sessions last until the user logs out, the session expires, or the browser is closed (depending on the implementation).
If you have any doubts related to these topics, feel free to search on Google for more information.
Thanks
— AMIT