Networks and the Internet: Client-Server, Addresses, Protocols and the Journey of a Request

In this lesson#

This lesson is built from a few short chapters, in the same order as the slides:

1. Chapter 1 — computer networks, LAN, the internet, client and server
2. Chapter 2 — IP address, port, domain and DNS
3. Chapter 3 — request, response and protocols: HTTP, HTTPS, TCP and UDP
4. Chapter 4 — what happens from the moment you type an address until the site is shown

Chapter 1: Computer Networks, LAN, the Internet, Client and Server#

What will we learn?#

• What a computer network is.
• LAN (local network) versus the internet.
• The router, the device that connects networks.
• The client-server model, the basis of every website, app and server we will build in the backend and databases topics.

Why do we need this?#

Every modern app talks to the network: WhatsApp, websites, games, and in the backend and databases topics also the server you will write. Backend developers write exactly the server side. Frontend developers write the client side. Without understanding this model, you cannot understand what your code does.

Explanation from the basics#

What is a network?#

A computer network is two or more devices connected so that they can pass information between them. The connection can be by cable (Ethernet), through the air (Wi-Fi), or by optical fiber.

Why do we connect computers?

• Sharing information — messages, files, websites.
• Sharing resources — one printer for the whole office, one internet connection for the whole home.
• Dividing the work — the information is kept in one place (a server), and everyone accesses it.

LAN — Local Area Network#

A LAN is a local network: the devices at home, in the office or in the classroom. In your home, the LAN includes the computer, the phone, the smart TV and the printer, all connected to the same router.

• All the devices on the LAN can talk to each other directly, without going out to the internet.
• Very fast, and under your control.

The internet — a network of networks#

The internet is a network of networks: millions of local networks all over the world, connected to each other through internet providers (ISPs) and undersea cables between continents.

Router — the gateway between networks#

The router is the device that connects your LAN to the internet. It knows whether a packet of information should stay at home (for example from the computer to the printer) or go out (for example to a website).

          Your home (LAN)
   ┌──────────────────────────┐
   │ Laptop   Phone   Printer │
   │    \       |       /     │
   │         Router ──────────┼───► ISP ───► Internet ───► Google's network
   └──────────────────────────┘                           (another LAN)

The client-server model#

Almost all communication on a network follows one model:

• Client — the program that initiates and sends a request. “Give me the home page”, “save this message”.
• Server — the program that waits for requests, handles them and returns a response.

Very important: client and server are roles of programs, not kinds of computers. The same laptop can run a browser (client) and a FastAPI server (server) at the same time. In the backend and databases topics that is exactly what you will do: the server and the client will run on the same computer.

Request and response — an example#

When you browse to a website, the browser is the client and the website is the server:

Browser (Client)                  Server (example.com)
   │                                   │
   │ ──── Request: GET /  ──────────►  │
   │                                   │  finds the page
   │ ◄──── Response: 200 + HTML  ────  │
   ▼                                   │
shows the page

1. The browser initiates — sends a request: “give me the main page”.
2. The server, which is always waiting for requests, finds the page.
3. The server returns a response: a success code (200) and the page content.
4. The browser shows what it received.

The very same pattern repeats in every app: WhatsApp sends a message to the server, a weather app asks for a forecast, and later in the course — a server you write will receive requests and return responses.

Common mistake#

The mistake: “a server is a huge computer in an air-conditioned room”, so “you can’t run a server on a laptop”.

• A server is a program that waits for requests — not a special kind of computer.
• Any laptop can run server software. Later in the course you will run a server on your own computer.
• The same computer can be a client and a server at the same time: your browser (client) can contact a server running on the same laptop.
• Server rooms simply run many such server programs, on powerful computers that are always on.

Second mistake: thinking that a website “sits in the browser”. The browser only requests and shows. The website, meaning the files and the logic, sits on the server.

Summary#

• Network = connected devices that pass information. LAN = a local network. The internet = a network of networks.
• The router connects the LAN to the internet and decides what stays inside and what goes out.
• The client initiates a request. The server waits, handles it and returns a response.
• Client and server are roles of programs. The same computer, and even the same program, can fill both.
• Every page you browse is a request from the client and a response from the server.

Official documentation#

• MDN — How does the Internet work?
• MDN Glossary — Server

Chapter 2: IP Address, Port, Domain and DNS#

What will we learn?#

Three questions every message on a network has to answer:

1. To which computer? — the IP address.
2. To which program on that computer? — the port.
3. How do I know the address if I only remember a name? — the domain and DNS.

Why do we need this?#

• In the backend and databases topics you will run a server on http://127.0.0.1:8000. Today you will understand every part of that address.
• An error like Address already in use (the port is taken) or Name or service not known (DNS failed) is routine in backend work.
• When you connect an app to a database, you need to give it a host and a port.

Explanation from the basics#

IP address — the computer’s address#

An IP address (Internet Protocol address) is a numeric address that identifies a device on the network. Without an address you cannot send it information, exactly like a letter without an address.

The common format, IPv4, is four numbers between 0 and 255, separated by dots:

192.168.1.23
 │   │  │  │
 └───┴──┴──┴── four numbers, each 0–255

There is also IPv6, a newer and longer format (2001:db8::1), created because there were not enough IPv4 addresses for all the devices in the world. The principle is the same.

Three kinds of addresses worth knowing#

Port — the door to the right program#

An IP address brings the information to the computer. But many programs on the computer use the network: a browser, Spotify, Zoom, a server you wrote. How does the information reach the right program?

A port is a number between 0 and 65535 that identifies a particular program on the computer. A server “listens” on a particular port, and every request that arrives at that port is passed to it.

IP   = which building    →  192.168.1.23
Port = which apartment   →  8000
Full address             →  192.168.1.23:8000

Well-known ports:

An important rule: on each port (on each address) only one program can listen at any moment.

Domain and DNS — names instead of numbers#

People don’t remember 142.250.75.14. We remember google.com.

• A domain is a readable name that stands for an address: google.com, ynet.co.il.
• DNS (Domain Name System) is “the internet’s phone book”: a worldwide system of servers that translates a domain into an IP address.

The structure of a domain (read from right to left, from the general to the specific):

   www   .   ynet   .   co   .   il
    │         │          │        │
subdomain   name      second    TLD (top-level domain: country/type)

What happens in a DNS translation (in short):

1. The computer checks whether it already knows the answer (the cache, a memory of previous answers).
2. If not, it asks the DNS server it was configured with (usually the internet provider’s, or Google’s 8.8.8.8).
3. The DNS server finds the answer (asking other servers in the hierarchy if needed) and returns an IP address.
4. Only after that does the computer send the request itself to the address it received.

DNS lookup — step by step#

You type:     example.com
     │  "What is the IP of example.com?"
     ▼
DNS server:   93.184.215.14
     │
     ▼
Browser connects to 93.184.215.14:443

1. You type a name — example.com.
2. The computer asks a DNS server: “what is the IP of this name?” (first it checks whether the answer is already saved from last time — the cache).
3. An IP address comes back.
4. Only now does the browser connect — to the IP and the port (443 for HTTPS).

A few example answers:

google.com              ->  142.250.75.14
localhost               ->  127.0.0.1
no-such-domain-123.com  ->  lookup failed

• localhost is always translated to 127.0.0.1 — the computer itself.
• A name that does not exist — DNS finds no address for it, and the browser shows an error even before it tried to connect.

Common mistake#

The mistake: running a second server on a port that is already taken.

Program A listens on port 8000   -> OK
Program B tries port 8000        -> ERROR

Address already in use

Why? Only one program can listen on a port at any moment. The first program “took” 8000.

The fix: stop the first program, or start the second one on another port, for example 8001.

Second mistake: confusing localhost with the IP on the LAN. 127.0.0.1 is reachable only from the same computer. If a friend tries to browse from their phone to 127.0.0.1:8000, they will reach their own phone.

Summary#

• An IP identifies a computer on the network. Private (192.168.x.x) inside the LAN, public on the internet.
• 127.0.0.1 / localhost = this computer itself. Not reachable from other computers.
• A port identifies a program inside the computer. Only one program listens on each port. 80 = HTTP, 443 = HTTPS.
• A domain is a readable name. DNS translates it to an IP before the request is sent.
• A full address: protocol://host:port/path, for example http://127.0.0.1:8000/students.

Official documentation#

• MDN Glossary — IP Address
• MDN Glossary — Port
• MDN Glossary — DNS

Chapter 3: Request, Response and Protocols: HTTP, HTTPS, TCP and UDP#

What will we learn?#

• What a protocol is.
• Request and response: what is sent and what comes back.
• HTTP and HTTPS: the language of the web.
• TCP and UDP: how the information itself is carried.

Why do we need this?#

The whole backend topic is built on HTTP: you will write a server that receives requests and returns responses, and you will choose a method (GET/POST/PUT/DELETE) and a status code (200, 404…). Today we see what it looks like “from the inside”. Once you understand it, FastAPI will look like a shortcut, not like magic.

Explanation from the basics#

What is a protocol?#

A protocol is an agreed set of rules for communication: what to send, in which order, in which format, and what to answer. If two sides do not speak the same protocol, they do not understand each other, even if the connection itself works.

On a network there are layers of protocols, and each layer handles a different problem:

HTTP / HTTPS   ← WHAT we say      (application: "give me /index.html")
TCP  / UDP     ← HOW it travels   (transport: reliable or fast)
IP             ← WHERE it goes    (addressing: 93.184.215.14)
Wi-Fi/Ethernet ← the physical link

Request and response#

All HTTP communication is a pair:

• Request — the client sends: what it wants and where.
• Response — the server returns: whether it succeeded, and the content.

It is always the client that starts. An HTTP server sends nothing on its own initiative.

HTTP — HyperText Transfer Protocol#

HTTP is a text-based protocol: the request and the response really are text you can read.

The structure of a request:

GET /index.html HTTP/1.1          ← request line: METHOD  PATH  VERSION
Host: example.com                 ← headers: extra info, "Name: value"
User-Agent: Mozilla/5.0
Accept: text/html
                                  ← empty line = end of headers
(body — empty for GET)            ← body: data we send (used in POST/PUT)

The structure of a response:

HTTP/1.1 200 OK                   ← status line: VERSION  STATUS CODE  REASON
Content-Type: text/html           ← headers
Content-Length: 1256
                                  ← empty line
<!doctype html><html>...          ← body: the content itself

Status codes, by their first digit:

HTTPS — secure HTTP#

In plain HTTP, the text travels the network in the open. Anyone sitting along the way (for example on public Wi-Fi) can read passwords and credit-card numbers.

HTTPS = HTTP + encryption (using a protocol called TLS). It adds two things:

1. Encryption — only the server and the client can read the content.
2. Identity verification — a digital certificate proves that you really are talking to bank.co.il and not to an impostor.

The HTTP inside the encryption is exactly the same. Port: HTTP = 80, HTTPS = 443. The lock icon 🔒 in the browser says the connection is HTTPS.

TCP and UDP — how the information travels#

Information on a network is split into small packets. IP brings each packet to the right address, but packets can get lost or arrive in the wrong order. This is where TCP and UDP come in:

HTTP runs on top of TCP. When the browser asks for a page, a TCP connection to the server is opened first (on port 80 or 443), and only then is the request text sent inside it.

Common response codes#

Every HTTP response starts with a status code — a three-digit number that says what happened. The first digit tells the “family”:

• 2xx — success. 3xx — redirect. 4xx — the client’s mistake. 5xx — the server’s mistake.

Common mistake#

The mistake: thinking that 404 means “the internet isn’t working” or “the server is down”.

• 404 is a valid response from the server: “I got the request, but I have no resource at this path”. The server works perfectly. The problem is in the request, that is, the path.
• If the server is not available at all, you get no status code. You get a connection error, such as Connection refused or timed out.
• 500 = the server got the request and crashed while handling it. In the backend topic, when you see 500, the bug is in your server code.

Second mistake: thinking HTTPS “hides” which site you are browsing. The encryption protects the content — passwords, forms, the page itself — but the domain you connect to is still visible on the network.

Summary#

• Protocol = agreed rules for communication. There are layers: HTTP (what we say), TCP/UDP (how it travels), IP (where to).
• HTTP request = method + path + headers + body. HTTP response = status code + headers + body.
• Status codes: 2xx success, 4xx the client’s mistake, 5xx the server’s mistake.
• HTTPS = HTTP + encryption and identity verification (TLS). Port 443.
• TCP is reliable and ordered (websites, files). UDP is fast and not guaranteed (video, games, DNS).

Official documentation#

• MDN — Overview of HTTP
• MDN Glossary — HTTPS
• MDN Glossary — TCP
• MDN Glossary — UDP

Chapter 4: What Happens from the Moment You Type an Address Until the Site Is Shown#

What will we learn?#

This is a classic interview question: “What happens when you type https://www.example.com/about in the browser and press Enter?” In this chapter we will build a full answer, step by step, and connect all the terms from today: URL, DNS, IP, port, TCP, HTTPS, request, response.

Why do we need this?#

• It is the most common question in junior interviews. It checks whether you see the “big picture”.
• When a site “doesn’t work”, someone who knows the steps knows where to look: DNS? the connection? the server? the content?
• In the backend and databases topics you will write step 6, the processing on the server. It is good to understand what happens before and after it.

Explanation from the basics#

Step 0 — breaking down the URL#

A URL (Uniform Resource Locator) is the “full address” of a resource on the internet:

https://www.example.com:443/about?lang=he
└─┬─┘   └──────┬──────┘ └┬┘ └─┬─┘ └──┬──┘
protocol     domain     port  path   query

The eight steps#

1. The browser breaks down the URL — it understands that the protocol is HTTPS (so port 443), that the domain is www.example.com and that the path is /about.

2. DNS lookup — name → IP address. The browser needs an IP, not a name. It checks in order: the browser’s cache, the operating system’s cache, and if there is no answer — it asks the DNS server. It gets, for example, 93.184.215.14.

3. TCP connection — the three-way handshake. The browser opens a TCP connection to the address 93.184.215.14:443. The connection opens with a “handshake” of three messages:

Client ──── SYN ────────►  Server     "Can we talk?"
Client ◄─── SYN-ACK ─────  Server     "Yes, can you hear me?"
Client ──── ACK ────────►  Server     "Yes. Let's start."

4. TLS handshake — encryption. Because it is HTTPS: the server sends a certificate, the browser checks that it is genuine and belongs to www.example.com, and both sides agree on an encryption key. From here on everything is encrypted. (With http:// there is no such step.)

5. Sending the HTTP request:

GET /about?lang=he HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 ...
Accept: text/html

6. The server processes the request. The server software receives the request, understands what was asked (GET /about), and prepares a response. Sometimes it is just a fixed file, and sometimes a lot of work: running code, a query to a database, building HTML. This is the part you will write in the backend and databases topics.

7. The server sends the HTTP response:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8

<!doctype html><html> ... <link href="/style.css"> <img src="/logo.png"> ...

8. The browser displays it (rendering). The browser reads the HTML and builds the page from it. When it comes across more files (CSS, images, JavaScript), it sends more requests, one per file, repeating steps 5–7. An average page makes dozens of requests! (The TCP connection and the encryption already exist, so steps 2–4 are usually not repeated.)

How long each step takes#

This whole journey usually takes less than a second. An example measurement of one request:

Step 2 - DNS: example.com -> 93.184.215.14 | ms: 21
Step 3 - TCP connected to 93.184.215.14 443 | ms: 64
Step 4 - TLS version: TLSv1.3 | ms: 71
Steps 5-7 - first line: HTTP/1.1 200 OK | ms: 66

You can see the same timings in any browser: F12 → the Network tab → click a request → Timing. The instructor will show it on the screen. There you can also see how many requests one page sends — sometimes dozens.

Common mistake#

The mistake: skipping DNS or putting it after the connection (“the browser connects to google.com”). You cannot connect to a name. A TCP connection needs an IP, so DNS always comes first.

Second mistake: thinking the whole page arrives in one request. The HTML arrives first, and from it the browser discovers dozens more files and requests each one separately. In the Network tab of DevTools you see this right away.

Third mistake — diagnosing a failure wrongly:

Summary#

• URL = protocol + domain + port + path + query.
• The order: break down the URL → DNS → TCP handshake → TLS → HTTP request → processing on the server → HTTP response → rendering.
• DNS always comes before the connection, because you connect to an IP and not to a name.
• One page = dozens of requests: HTML first, then CSS, images and JS.
• Every kind of failure belongs to a particular step, and that is how you diagnose it.

Official documentation#

• MDN — How the web works

Practice#

Comprehension questions on the lesson material — no code.

Exercise 1: Client or Server?#

In each scenario — who is the Client and who is the Server?

1. Browsing from your phone to a bank’s website.
2. A weather app asks for a forecast.
3. Dana runs a program on her laptop that waits for requests, and opens it in the browser on the same laptop.

Exercise 2: IP, Port and DNS#

1. What does an IP address identify, and what does a Port identify?
2. What does the address 127.0.0.1:8000 mean?
3. A friend tries to open 127.0.0.1:8000 on their phone to see a server running on your computer. Why won’t it work?

Exercise 3: Breaking down a URL#

Break the address into its parts — Protocol, Domain, Port, Path and Query:

https://shop.example.com:443/cart?coupon=SALE10

And what would the port be if :443 were not written in the address?

Exercise 4: Response codes#

What does each code mean, and where is the problem — the Client or the Server?

200   301   404   500

And what will the browser get if the server is not running at all?

Exercise 5: The journey of a request#

Put the steps in order — from typing an address until the site is shown:

• (a) TCP connection — the three-way handshake
• (b) DNS — translating the name into an IP address
• (c) The browser displays the page (Rendering)
• (d) Sending the HTTP Request
• (e) Setting up encryption (TLS)
• (f) Breaking down the URL
• (g) The server returns the HTTP Response

And why must DNS come before the TCP connection?