What Are Servers and Clients?
When you view a website, your PC or smartphone is not simply displaying a screen.
In reality, a browser or app sends a request to a server on the internet, and the server returns the necessary data.
In this situation, the side that sends the request is called the client, and the side that receives the request and returns a response is called the server.
Much of web communication is built on this client-server relationship.
Put simply, the basic shape of web communication is this:
The client requests. The server responds.
This article organizes the relationship between the "requesting side" and the "responding side," which is the foundation of web communication.
What Does It Mean to View a Website?
When you open a website in a browser, a page appears on the screen.
However, that page was not inside your device from the beginning.
The browser communicates with the website's server and obtains the data needed to display the page.
For example, suppose you open an article page.
At that time, the browser sends the server a request:
"Please give me the data for this page."
The server receives that request and returns the data needed to display the page.
The browser reads the returned data and displays text, images, buttons, layouts, and similar elements on the screen.
In other words, viewing a website is made up of the following flow.
- The browser sends a request to the server
- The server receives the request
- The server returns the necessary data
- The browser displays the received data on the screen
From your point of view, it may look as if you simply opened a page.
Behind the scenes, however, "request" and "response" are taking place between the client and the server.
What Is a Client?
A client is the side that sends requests in communication.
When viewing a website, your browser is the client.
For example, browsers such as Chrome, Safari, Firefox, and Edge send requests to servers in order to view websites.
The browser asks the server:
"Please give me the data needed to display this page."
Then it uses the data returned from the server to display the web page on the screen.
In other words, a browser is not merely a display app.
It is a client that sends requests to a website's server and displays the returned data.
Apps Can Also Be Clients
Browsers are not the only things that become clients.
Smartphone apps and PC apps also become clients when they send requests to servers.
For example, when you open a social media app, it displays a timeline, notifications, profiles, images, videos, and similar information.
This information was not all inside the smartphone from the beginning.
The app sends requests to a server and receives the latest data from the server.
For example, a social media app may send requests like these to a server.
- Please give me timeline data
- Please check for new notifications
- Please give me this user's profile
- Please give me the data for this image or video
The server returns the necessary data in response.
Then the app displays the received data on the screen.
Cloud note apps, chat apps, online games, file-sharing apps, and similar apps work the same way.
They request the necessary data from servers and operate using the data that comes back.
In other words, "client" does not mean only "browser."
The side that sends requests in communication is the client.
What Is a Server?
A server is the side that receives requests and returns the necessary data in communication.
For a website, the server has the data needed to display the website.
For example, news sites, search engines, social media, online stores, and similar services receive requests from users' browsers and apps, then return data in response.
The data returned by a server includes, for example, the following.
- HTML
- CSS
- JavaScript
- Images
- Videos
- Article body text
- Product information
- User information
HTML is data that represents the text and structure of a page.
CSS is data used to determine appearance, such as text size, color, and placement.
JavaScript is data used to create behavior when buttons are pressed and processing that happens on the page.
Images and videos are media data displayed within the page.
The browser reads these pieces of data returned from the server and displays them on the screen as a web page.
One Page Can Involve Multiple Requests
When opening one web page, the browser does not always communicate only once and then finish.
Multiple pieces of data may be needed to display the page.
For example, when opening an article page, the browser first obtains the main page data.
After that, it may additionally obtain CSS that shapes the page's appearance, JavaScript that creates behavior on the page, images inside the article, and similar data.
In other words, even if it looks to you as if you opened one page, multiple requests may be happening behind the scenes.
For example, requests like these may occur.
- Please give me the main page data
- Please give me the design data
- Please give me the image file
- Please give me the data for page behavior
- Please give me the latest comments or notifications
The server returns the necessary data for each request.
The browser combines the returned data and displays it on the screen as one web page.
It becomes easier to understand web pages if you think of them as "data returned from the server that the browser assembles and displays."
Where Is Website Data Located?
Website data is basically on the server side.
When you open a website, the browser connects to the server and obtains the necessary data.
Then the browser displays the obtained data on the screen.
In other words, viewing a website means that the client goes to retrieve data on the server and displays it on your own device.
However, once-loaded images and some files may be temporarily saved on your device.
This is used, for example, to make display faster when opening the same page again.
Even so, the basic structure does not change.
Website data is on the server side, and the client obtains it as needed.
A Server Is Not Always One Machine
On this page, for convenience, "server" has been explained as if it were one entity.
However, in real web services, a server is not necessarily one physical machine.
A small website may run on one server.
Large web services, however, have many users accessing them at the same time.
For that reason, processing may be shared across multiple servers.
For example, roles may be divided in the following ways.
- A server that returns web pages
- A server that delivers images and videos
- A server that manages user information
- A server that handles databases
- A mechanism that distributes access across multiple servers
Today, it is also common to operate web services using the cloud.
In the cloud, the operator of a web service does not prepare physical machines directly, but uses a server environment provided by a cloud provider.
In addition, CDNs are sometimes used to deliver images, videos, CSS, JavaScript, and similar data.
A CDN is a mechanism that places data in multiple locations and delivers it from a location near the user.
This can make pages display faster and reduce load on the original server.
However, you do not need to memorize the detailed structure from the beginning.
The first important point is that a server has the role of receiving requests from clients and returning the necessary data.
And in real web services, that role may be supported not only by one machine, but also by multiple servers, the cloud, CDNs, and similar systems.
Client and Server Are Determined by Role
Clients and servers are not determined only by the kind of machine.
What matters is the role being played in communication.
The side that sends the request is the client.
The side that receives the request and returns the response is the server.
For example, your PC usually acts as a client when you view websites.
However, if you publish a web service on that PC and make it accept connections from other devices, that PC can also act as a server.
In other words, clients and servers are easier to understand as "roles in communication," not as "names of devices."
An Important Perspective for Thinking About Anonymity
The relationship between client and server is important when thinking about anonymity.
This is because, in web communication, your browser or app basically sends requests to the destination server.
The server receives requests from the client.
For that reason, some information may be visible to the website side.
For example, the website side may be able to see information such as the following.
- The IP address visible as the connection source
- Access time
- The requested page
- Information about the browser or device
- Information related to cookies
The important point here is that the information visible to the other side changes depending on whether "your device connects directly to that website," whether "you use a , , proxy, or similar tool," and whether "the destination site uses a CDN."
For example, when connecting directly to a website, the destination server may be able to see the IP address assigned to your internet connection.
On the other hand, when going through a VPN, Tor, or similar route, the website side may see a VPN, Tor exit, or proxy IP address rather than your original IP address.
Also, when cookies are used, a website may be able to identify access from the same browser.
However, what is visible and to what extent changes depending on the communication route, browser settings, website-side mechanisms, whether HTTPS is used, how cookies are used, and similar factors.
What you should understand at this point is not the details of tracking technologies.
The first important point is the structure in which the client sends a request to the server, and the server receives that request.
Because this structure exists, the question of "what is visible to the destination server" arises.
To understand anonymity, you first need to grasp this client-server relationship.
Summary
A client is the side that sends requests in communication.
Web browsers, smartphone apps, PC apps, and similar software become clients when they send requests to servers.
A server is the side that receives requests and returns the necessary data.
Website data is generally stored on the server side, and browsers and apps obtain the necessary data from the server.
When viewing a web page, the browser asks the server, "Please give me the data for this page."
The server returns HTML, CSS, JavaScript, images, and similar data.
The browser reads the received data and displays it on the screen.
Also, in real web services, a server is not necessarily one physical machine.
Multiple servers, the cloud, CDNs, and similar systems may be used.
Even so, the basics do not change.
The client requests, and the server responds.
This is the basic structure of web communication.
When thinking about anonymity, you need to take this structure as the premise and think about what is visible to the destination server.
Related tools
WhatIsMyIP
An external resource related to this article. Open it only when it fits your situation and threat model.
Why it is listed: It can help with the article topic, but it is outside Anonymity Sense and should be checked before use.
BrowserLeaks WebRTC
An external resource related to this article. Open it only when it fits your situation and threat model.
Why it is listed: It can help with the article topic, but it is outside Anonymity Sense and should be checked before use.
Tor Project
An external resource related to this article. Open it only when it fits your situation and threat model.
Why it is listed: It can help with the article topic, but it is outside Anonymity Sense and should be checked before use.
Proton VPN
An external resource related to this article. Open it only when it fits your situation and threat model.
Why it is listed: It can help with the article topic, but it is outside Anonymity Sense and should be checked before use.
URL : https://protonvpn.com/
Mullvad VPN
An external resource related to this article. Open it only when it fits your situation and threat model.
Why it is listed: It can help with the article topic, but it is outside Anonymity Sense and should be checked before use.
URL : https://mullvad.net/