Introduction to the Web

What this chapter is really for

The PDF is two decks stapled together. Slide 1–21 is Chapter 1-a: Introduction to Web Development and slide 22–58 is Chapter 1-b: How the Web Works. They are graded very differently, so study them differently.

The single most useful thing you can take out of this chapter is a mental picture of what happens between typing a URL and seeing a page. Everything else in the chapter hangs off that one story.

All 59 slides, weighted

Context: how the web got here, and why it matters to you

Internet ≠ WWW

The Internet is the global network of connected machines and the protocols that run on it. The World Wide Web is one service delivered over that network, the one that speaks HTTP and exchanges HTML. Email, SSH and file transfer are also on the Internet and are not the Web. The slides open with this distinction because the rest of Part B is about the Internet, not the Web.

Circuit switching vs packet switching

The five things Berners-Lee defined (1992)

Slide 8 is a list that maps almost perfectly onto the rest of this course, which makes it easy to remember and easy to examine:

1. URL — uniquely identifies a resource (chapter 1)
2. HTTP — describes how requests and responses operate (chapter 1)
3. Web server software — responds to HTTP requests (chapter 6)
4. HTML — publishes documents (chapter 2)
5. A browser — makes requests and displays what it receives (chapters 3–5)

Web apps vs desktop apps

Static → dynamic → Web 2.0

The machinery: layers, addresses, and name resolution

The four-layer model

TCP/IP was originally abstracted as four layers. Later models subdivide it into five or seven, but this course uses the four-layer version, and questions are phrased in its terms.

IP addresses

PAT (Port Address Translation) lets multiple unrelated networks share one public IP address, which is how the coffee shop, your home and the university all keep working despite IPv4 exhaustion. It is a stopgap; IPv6 is the long-term answer.

TCP vs UDP — the trade-off

The slide’s example is worth keeping: a broadcaster streaming a match to millions cannot afford to track and retransmit every lost packet, and a small amount of loss is acceptable because viewers still see the game.

DNS: why it exists

Humans do not remember numeric addresses. In the ARPANET era a single downloadable hosts file mapped names to IPs; that stopped scaling, so it was replaced by the distributed Domain Name System. A second, less obvious benefit: because the name is separate from the address, a site can move to a different host without changing its name.

Name levels and TLD categories

IDN (Internationalized Domain Names) allow non-ASCII characters and have been deployed since 2009 — over 9 million exist. Registration in KSA: .sa from 1995, the Arabic-script TLD from 2010; since February 2021 accredited registrars serve individuals and non-government entities, while government entities register through the Digital Government Authority. ICANN oversees top-level domains, accredits registrars and coordinates DNS.

Address resolution — the ten steps

Draw this from memory. It is the most likely long-answer question in the chapter.

1. Client requests a domain.
2. The client computer checks its local DNS cache.
3. If it is not cached, the computer asks its primary DNS server.
4. If that server has no cached record, it asks a root name server.
5. The root server returns the address of the relevant TLD server.
6. The DNS server requests the record from that TLD server.
7. The TLD server returns the addresses of the domain’s authoritative DNS servers.
8. The DNS server asks one of those authoritative servers for the IP.
9. The authoritative server returns the IP address.
10. The client finally makes its actual request to that IP.

Domain registration, in order

1. Registrant searches for a domain via a registrar or reseller portal.
2. The registrar queries the TLD registry operator for availability.
3. If available, the registrant pays and supplies WHOIS information.
4. The registrar pushes the WHOIS data to the TLD registry operator.
5. The registry operator adds it to its authoritative list.
6. The registry operator pushes DNS information out to the TLD name servers.

URL anatomy and HTTP — the part you keep using all semester

Label every part of a URL

https://www.funwebdev.com:8080/pages/search?term=css&page=2#results
└─┬─┘   └────────┬───────┘ └─┬─┘ └─────┬────┘ └───────┬───────┘ └───┬──┘
  │              │            │        │             │             │
  │              │            │        │             │             └─ fragment (browser only, never sent to the server)
  │              │            │        │             └─ query string: key=value pairs, ? starts it, & joins them
  │              │            │        └─ path: maps to a location under the server root
  │              │            └─ port: OPTIONAL. Defaults to 80 for http, 443 for https
  │              └─ domain (or IP address) to connect to        ← REQUIRED
  └─ protocol used to connect                                   ← REQUIRED

Two details the slides call out explicitly. Port: not commonly used on production sites, but useful to route requests to a test server, to stress test, or to get around filters; http://funwebdev.com:8080/ connects on port 8080. Path: the server root corresponds to a real folder on the server — often /var/www/html/ on Linux or /inetpub/wwwroot/ on Windows — and when you request a folder rather than a file, the server decides which file to send you.

The request/response cycle

── REQUEST ─────────────────────────────────────────────
GET /pages/search?term=css HTTP/1.1
Host: www.funwebdev.com          ← which site, on a shared IP
User-Agent: Mozilla/5.0 ...       ← data about the client machine
Cache-Control: max-age=0

── RESPONSE ────────────────────────────────────────────
HTTP/1.1 200 OK                    ← status code
Server: nginx/1.24.0             ← data about the server
Content-Type: text/html; charset=utf-8
Last-Modified: Tue, 18 Feb 2026 09:14:02 GMT
Content-Encoding: gzip

<!DOCTYPE html>                    ← optional message body
<html> ... </html>

HTTP establishes a TCP connection on port 80 by default, the server waits for the request, then responds with headers, a response code, and an optional message which may include files. Headers are described by the slides as one of the most powerful aspects of HTTP: request headers carry data about the client machine, response headers carry data about the server and the data being sent.

GET vs POST

The other methods the slides name but do not cover are HEAD, CONNECT, TRACE and OPTIONS. You meet PUT and DELETE properly in chapter 7.

Status codes

The first digit gives the family: 2xx success, 3xx redirection, 4xx client error, 5xx server error.

How a page actually loads

The browser requests the initial HTML page, parses it to find every referenced resource — images, style sheets, scripts — and requests those too. The page is only fully loaded once all the files have been retrieved. The whole set of algorithms to download, parse, lay out, fetch assets and produce the final interactive page is collectively called rendering. Remember this: it is the reason chapter 4 tells you where to put your <script> tag, and the reason chapter 5 uses DOMContentLoaded.

The application stack

Slide 57 defines a web server as "nothing more than a process that responds to HTTP requests", and lists the five parts of an application stack. This is a preview of your whole semester:

How to make an all-theory chapter stick

You cannot code your way through chapter 1, but you can observe everything in it in about fifteen minutes. Reading the slides again is the worst use of your time; doing this instead is the best.

curl -I https://example.com                 # 200 OK, plus every response header
curl -I https://example.com/no-such-page    # 404 Not Found
curl -I http://github.com                   # 301 Moved Permanently → https
curl -I https://httpbin.org/status/500      # 500 Internal Server Error
curl -I https://httpbin.org/status/401      # 401 Unauthorized

nslookup psu.edu.sa          # name → IP, exactly what step 9 returns
dig +trace psu.edu.sa        # the whole chain: root → TLD → authoritative
ping psu.edu.sa              # shows the resolved IP before the first reply

The five things people get wrong

Chapter 1 on a single screen

Close the slides and answer these out loud

1. Name the four layers bottom to top, and give one job for each.
2. A packet arrives out of order. Which layer fixes it, and by what mechanism?
3. Give three services that use UDP and say why guaranteed delivery is not worth its cost for them.
4. Write out a URL that uses all six parts, then label each one and say which two are required.
5. List the ten steps of address resolution without looking. Check yourself with dig +trace.
6. Name the three subtypes of gTLD and give two examples of each.
7. Give four HTTP status codes from four different families and say what each one tells the client.
8. Explain why submitting a long form with GET can produce a 414, and what to do instead.
9. List four request headers and four response headers, and say which side sends each.
10. Describe what the browser does between receiving the HTML and finishing the page load.
11. Name the five layers of an application stack and say which SE371 chapter covers each.
12. State the difference between the Internet and the WWW in one sentence.

Can you answer these without scrolling up?