Internet and Web Foundations

Introduction and Context

The Internet and the World Wide Web are related but distinct systems. The Internet is a global network infrastructure that connects computers, mobile devices, servers, and embedded systems. The Web is an application service that uses the Internet to deliver interlinked resources through browsers and web servers. Email, online gaming, file transfer, and voice communication can use the Internet without being part of the Web.

For students of Artificial Intelligence and Machine Learning, web foundations are essential. AI systems increasingly consume web-based data, expose prediction services through application programming interfaces (APIs), operate in cloud environments, and interact with users through browser-based applications. Understanding how a request travels from a browser to a server helps developers design reliable, secure, efficient, and accessible systems.

This chapter develops a conceptual and practical model of Internet architecture, the Web’s evolution, client–server computing, URLs, DNS, TCP/IP, HTTP and HTTPS, browsers, web servers, standards, and the request–response lifecycle.

Learning Objectives

By the end of this chapter, students should be able to:

1. Distinguish the Internet from the World Wide Web.

2. Explain layered Internet architecture and the role of TCP/IP.

3. Describe client–server and related distributed-computing models.

4. Interpret URLs and explain how DNS resolves domain names.

5. Explain the principal functions of HTTP and HTTPS.

6. Describe how browsers and web servers cooperate.

7. Trace a web request from user action to returned content.

8. Explain the importance of standards, interoperability, security, and accessibility.

9. Analyze common performance, reliability, privacy, and governance issues in web systems.

From Networks to the World Wide Web

The Internet

A computer network is a collection of connected devices that exchange data. The Internet is a network of networks. It does not consist of one centrally controlled machine or one physical medium. It combines home networks, enterprise networks, cellular networks, data centers, undersea cables, satellites, and Internet Service Provider (ISP) infrastructure.

Routers forward packets between networks. A packet is a unit of data containing payload information and control information such as source and destination addresses. Packet switching allows many users to share communication links efficiently. Unlike a dedicated circuit, a packet-switched network does not reserve one complete physical path for the entire communication session.

The Internet’s design emphasizes interoperability and resilience. Devices made by different manufacturers can communicate because they implement shared protocols. Traffic can often be rerouted when a link or router fails, although this does not guarantee uninterrupted service.

The World Wide Web

The Web was developed at CERN by Tim Berners-Lee and introduced publicly in the early 1990s. Its central ideas were:

• resources identified by uniform addresses;
• documents linked through hypertext;
• a protocol for transferring resources; and
• software that could request and display those resources.

The original Web was largely document-oriented. Web 2.0 later emphasized user-generated content, social interaction, dynamic interfaces, and platform services. Modern Web applications support real-time collaboration, video, online commerce, cloud software, machine-learning interfaces, and decentralized or distributed services. The distinction between “website” and “web application” is now less rigid: a site may provide both documents and interactive computation.

The Web is therefore an application layer built above Internet communication services. A browser may use HTTP or HTTPS over an IP network, but HTTP is not itself the Internet.

Internet Architecture and Layering

Layering divides a complex communication task into cooperating responsibilities. A layer provides services to the layer above and uses services of the layer below. This separation allows one component to change without redesigning every other component.

The TCP/IP Model

The practical Internet architecture is commonly explained using four layers:

1. Application layer: protocols used by applications, including HTTP, DNS, SMTP, and SSH.

2. Transport layer: end-to-end communication between processes, principally TCP and UDP.

3. Internet layer: logical addressing and routing, principally IP.

4. Link or network-access layer: communication across a local physical or wireless network, such as Ethernet or Wi-Fi.

Some textbooks use a five-layer model by separating the physical layer from the data-link layer. The OSI reference model uses seven layers and is valuable for teaching, but real Internet implementations do not always map perfectly to it.

When an application sends data, each layer typically adds control information. This process is called encapsulation. At the destination, corresponding layers remove and interpret these headers; this is decapsulation. For example, an HTTP message may be carried in a TCP segment, which is placed in an IP packet, which is transmitted in a Wi-Fi or Ethernet frame.

IP Addressing and Routing

Internet Protocol provides addressing and routing. IPv4 addresses contain 32 bits and are commonly written in dotted-decimal notation, such as `192.0.2.10`. IPv6 addresses contain 128 bits and are written in hexadecimal groups, such as `2001:db8::10`. The ranges `192.0.2.0/24` and `2001:db8::/32` are reserved for documentation and examples.

An IP address identifies a network interface or logical endpoint, not necessarily a person or permanent physical machine. Addresses may be dynamically assigned, shared through Network Address Translation (NAT), or associated with multiple services. Routing protocols help networks exchange reachability information and select paths.

TCP and UDP

TCP provides a reliable, ordered byte stream between endpoints. It uses connection establishment, acknowledgements, sequence numbers, retransmission, and flow and congestion control. TCP does not preserve application message boundaries; an application must define how a stream is divided into messages.

UDP is a connectionless datagram protocol with lower protocol overhead. It does not itself guarantee delivery, ordering, or duplicate suppression. Applications such as real-time media, DNS, and newer protocols may use UDP when they require low latency or implement reliability themselves.

Modern HTTP/3 uses QUIC, a transport protocol implemented over UDP. QUIC provides features including encrypted transport, multiplexed streams, and connection migration. The use of UDP by QUIC does not mean that HTTP/3 abandons reliability; reliability is supplied by QUIC rather than by TCP.

Client–Server and Distributed Computing

In the client–server model, a client requests a service and a server provides it. A browser is commonly a client, while a web server is a program that receives requests and returns responses. The terms describe roles, not necessarily different kinds of hardware. One physical machine can act as both client and server, and a server can itself be a client of another service.

A web system often uses multiple tiers:

• Presentation tier: browser interface and user interaction.
• Application tier: business rules, authentication, and API logic.
• Data tier: databases, object stores, search engines, or machine-learning models.

In a request to an online prediction service, a browser may send input to an application server. The application server may validate the input, call a model-serving service, retrieve feature data, and return a prediction. This is a distributed computation even if the user sees one web page.

Client–server systems provide centralized management and shared services, but they introduce dependence on network connectivity, server availability, and service capacity. Alternatives include peer-to-peer systems, edge computing, serverless platforms, and hybrid architectures. These approaches do not eliminate client–server interactions; they distribute or abstract them.

URLs, URIs, and Resource Identification

A Uniform Resource Identifier (URI) identifies a resource. A Uniform Resource Locator (URL) is a URI that also indicates how and where the resource can be accessed. In everyday web development, the terms are often used interchangeably, although URI is the broader term.

Consider:

`https://www.example.org:443/courses/web/index.html?unit=1#tcp`

Its components are:

• `https`: scheme identifying the access protocol;
• `www.example.org`: host name;
• `443`: optional port, here the conventional HTTPS port;
• `/courses/web/index.html`: path identifying a resource or processing route;
• `unit=1`: query string containing a parameter;
• `tcp`: fragment identifier.

The fragment is normally processed by the client and is not sent to the server in the HTTP request. The query string, by contrast, is sent as part of the request target.

URLs are case-sensitive in some components, especially paths, depending on server and file-system behavior. Spaces and certain characters must be percent-encoded. Poorly designed URLs can expose sensitive information through browser history, logs, referrer information, or analytics systems. Passwords, access tokens, and confidential data should not be placed in URLs.

DNS: Translating Names into Addresses

Humans prefer names such as `www.example.org`, while network communication requires addresses. The Domain Name System (DNS) is a distributed, hierarchical naming system that maps domain names to resource records.

The hierarchy includes a root, top-level domains such as `.org` and `.com`, and authoritative name servers for particular domains. A resolver, often operated by an ISP, organization, or public DNS provider, obtains answers for clients. DNS can return several record types, including:

• A: an IPv4 address;
• AAAA: an IPv6 address;
• CNAME: an alias for another name;
• MX: mail-server information;
• TXT: text used for verification and policy information;
• NS: authoritative name-server information.

A typical lookup may proceed from a browser cache to an operating-system cache, then to a local recursive resolver. If the resolver lacks an answer, it may query root, top-level-domain, and authoritative servers. Results are cached for a period specified by the record’s time to live (TTL). Caching reduces delay and traffic but means that changes are not always visible immediately.

DNS is not intrinsically a security or identity system. DNS Security Extensions (DNSSEC) can provide authenticity for DNS data through digital signatures, but DNSSEC does not encrypt ordinary DNS queries. DNS over HTTPS (DoH) and DNS over TLS (DoT) protect the communication between a client and resolver, addressing confidentiality in that part of the process. They do not automatically make the destination website trustworthy.

HTTP and HTTPS

HTTP Semantics

Hypertext Transfer Protocol is an application-layer protocol for exchanging representations of resources. HTTP follows a request–response model. A request generally contains a method, target, protocol version, headers, and possibly a body. A response contains a status code, headers, and possibly a body.

Common methods include:

• GET: retrieve a representation; it should be safe and is normally cacheable.
• POST: submit data for processing or create an operation; it is not generally idempotent.
• PUT: create or replace a representation at a specified target; it is intended to be idempotent.
• PATCH: partially modify a resource.
• DELETE: request removal of a resource.
• HEAD: request headers corresponding to a GET response without the response body.

“Safe” means that the method is intended not to request a state-changing action. “Idempotent” means that repeating the same request has the same intended effect as making it once; it does not mean that every response will be identical.

HTTP status codes are grouped as follows:

• 1xx: informational;
• 2xx: successful, such as `200 OK` and `201 Created`;
• 3xx: redirection, such as `301 Moved Permanently` and `304 Not Modified`;
• 4xx: client-side or request-related error, such as `400 Bad Request`, `401 Unauthorized`, `403 Forbidden`, and `404 Not Found`;
• 5xx: server-side failure, such as `500 Internal Server Error` and `503 Service Unavailable`.

A status code describes the result of a particular HTTP exchange. A `200` response does not prove that the application’s business operation produced the result the user expected; application-level validation remains necessary.

HTTP Headers, State, and Caching

Headers carry metadata. Examples include `Content-Type`, `Content-Length`, `Accept`, `Authorization`, `Cache-Control`, `Cookie`, and `Set-Cookie`. HTTP itself is stateless: each request can be interpreted independently. Applications create sessions using cookies, tokens, server-side session stores, or other mechanisms.

Caching improves performance by avoiding repeated transfers. A browser, proxy, content delivery network (CDN), or server may cache a response. Cache-control directives specify conditions such as freshness, revalidation, or non-storage. Developers must prevent private or personalized data from being cached publicly.

HTTPS and TLS

HTTPS is HTTP carried through Transport Layer Security (TLS). TLS provides encryption against eavesdropping, integrity protection against undetected modification, and server authentication through certificates. A certificate binds a domain name to a public key and is issued within a trust system involving certificate authorities.

HTTPS does not guarantee that a site is honest, free of vulnerabilities, or appropriate for a user. It protects the connection to the authenticated domain, not the correctness of content or the safety of every download. Secure deployment also requires sound authentication, authorization, input validation, software updates, logging, and protection of secrets.

Browsers and Web Servers

A browser performs several major tasks:

1. parses a URL and determines how to access it;

2. resolves the host name through DNS;

3. establishes transport and, for HTTPS, TLS communication;

4. sends HTTP requests;

5. parses HTML and builds a Document Object Model (DOM);

6. parses CSS and computes styles;

7. executes permitted JavaScript;

8. constructs a layout and paints pixels;

9. manages storage, cookies, permissions, and security policies.

The browser’s same-origin policy restricts scripts from freely reading data from different origins. An origin is commonly defined by scheme, host, and port. Cross-Origin Resource Sharing (CORS) provides a controlled mechanism for servers to permit selected cross-origin requests.

A web server is software that listens for requests and returns resources or forwards requests to application logic. Examples of server software include Apache HTTP Server, Nginx, and Microsoft IIS. Application frameworks often run behind a reverse proxy or gateway. Large systems use load balancers, CDNs, caches, databases, queues, and observability tools.

Static content, such as images and style sheets, can often be served directly. Dynamic requests may invoke application code that authenticates users, accesses databases, calls external APIs, or executes an AI model. Separating these functions improves scalability and security, but also increases architectural complexity.

The Request–Response Lifecycle

Consider a user entering `https://shop.example/products/7`.

1. Input and URL interpretation: The browser identifies HTTPS, the host, and the path.

2. Cache and service-worker checks: The browser may satisfy the request locally if a valid cached representation exists.

3. DNS resolution: The host name is mapped to one or more IP addresses.

4. Connection establishment: The browser establishes a TCP connection for HTTP/1.1 or HTTP/2, or a QUIC connection for HTTP/3. HTTPS includes a TLS handshake that negotiates cryptographic parameters and authenticates the server certificate.

5. HTTP request: The browser sends a method such as GET, request headers, cookies where applicable, and the target path.

6. Network delivery: Routers forward packets across multiple networks to the server or CDN.

7. Edge processing: A CDN, firewall, load balancer, or reverse proxy may inspect, cache, filter, or route the request.

8. Application processing: The server validates input, checks authorization, queries data stores, and constructs a response.

9. HTTP response: The server returns a status code, headers, and content such as HTML or JSON.

10. Rendering: The browser parses the response, discovers additional resources, requests them, and renders the interface.

11. Interaction: JavaScript may issue further asynchronous requests using mechanisms such as `fetch`.

The lifecycle is not always linear. A cache hit can bypass an origin server; a redirect can produce another request; a failed connection can trigger retries; and a page can progressively render while resources arrive.

A Basic Performance Model

A simplified estimate of user-perceived response time can be expressed as:

`T_total ≈ T_lookup + T_connection + T_TLS + T_request/response + T_processing + T_rendering`

The terms represent DNS lookup, connection establishment, TLS negotiation, network transfer, server processing, and browser rendering. This is an explanatory model, not an exact protocol equation. Some terms overlap, are reused, or are avoided through caching and connection reuse. Performance engineering therefore requires measurement using tools such as browser developer tools, server logs, tracing, and real-user monitoring.

Web Standards and Interoperability

Web standards allow independently developed browsers, servers, libraries, and assistive technologies to work together. The World Wide Web Consortium (W3C) develops many Web standards and guidelines; the Internet Engineering Task Force (IETF) publishes Internet standards and specifications, including important HTTP and TLS documents. The WHATWG maintains living standards for technologies such as HTML and the DOM.

Standards are not merely bureaucratic rules. They support portability, reduce vendor lock-in, improve accessibility, and provide shared security and semantic expectations. Examples include semantic HTML, CSS specifications, HTTP specifications, URL standards, Web APIs, and Web Content Accessibility Guidelines (WCAG).

Conformance does not mean that every implementation behaves identically in every situation. Developers should test across browsers, operating systems, screen sizes, network conditions, and assistive technologies. Progressive enhancement—providing a usable basic experience and adding advanced capabilities when supported—improves resilience.

Security, Privacy, and Governance

Web systems face threats including phishing, cross-site scripting (XSS), SQL injection, cross-site request forgery (CSRF), credential theft, insecure direct object references, denial-of-service attacks, and supply-chain compromise. Defensive practices include:

• validate input on the server;
• encode output according to its context;
• use parameterized database queries;
• apply least privilege;
• protect credentials with strong hashing and secure storage;
• use secure cookies and appropriate security headers;
• enforce authorization for every protected operation;
• maintain software dependencies and monitor vulnerabilities;
• collect only necessary personal data;
• log security-relevant events without exposing secrets.

Privacy involves more than encryption. Organizations should explain data collection, establish retention limits, obtain appropriate consent where required, and provide meaningful controls. Laws and regulations vary by jurisdiction and may govern personal data, children’s information, accessibility, electronic communications, and breach notification. Developers must involve legal, security, accessibility, and governance specialists when systems affect sensitive populations or high-impact decisions.

AI-enabled web applications create additional responsibilities. Inputs may contain personal or maliciously crafted content; model outputs may be inaccurate or discriminatory; and prompts or uploaded documents may expose confidential information. A web security boundary does not automatically protect a model, and model safeguards do not replace ordinary web security.

Illustrative Case: An Online University Prediction Service

Background

An illustrative university deploys a browser-based system that predicts whether a student may need academic support. The system presents a dashboard to authorized advisers and uses a machine-learning model hosted on an application service.

Problem

The initial prototype sends data directly from the browser to a model endpoint. It uses an unencrypted connection, exposes a database identifier in the URL, and assumes that hiding the dashboard link is sufficient authorization. Response times are unpredictable because every page request recomputes features.

Analysis

The design has several weaknesses. Unencrypted traffic can reveal sensitive data. A URL containing identifiers may be recorded in logs and browser history. The absence of server-side authorization allows a user to alter an identifier and request another student’s result. Recomputing features creates unnecessary latency and load. The system also risks treating a prediction as a definitive academic judgment.

Approach and Solution

The university redesigns the system as a layered application. The browser communicates with an HTTPS API. An identity provider authenticates advisers, while the application server checks role and student-specific authorization on every request. Sensitive identifiers are transported in controlled request bodies or protected paths rather than exposed unnecessarily in query strings. Parameterized database access prevents injection.

Frequently used, non-sensitive features are cached with carefully defined lifetimes. The model service is isolated behind the application tier, and audit logs record access without storing raw sensitive values. The interface labels predictions as uncertain decision support, displays relevant explanations, and requires human review. Accessibility testing covers keyboard use, screen readers, contrast, and clear error messages.

Outcome

The revised design reduces unauthorized access risk, improves response consistency, and makes accountability possible. It does not eliminate model bias or prediction error; those require separate evaluation, monitoring, and institutional policy.

Learning Points

A successful web system requires more than a functioning page. Architecture, protocol security, authorization, performance, privacy, accessibility, and responsible use must be designed together. In AI systems especially, technical reliability and ethical governance are inseparable.

Contemporary Developments and Best Practices

Modern web engineering increasingly uses HTTP/2 and HTTP/3, content delivery networks, edge computing, progressive web applications, WebAssembly, real-time protocols, and serverless deployment. These technologies can improve responsiveness or operational flexibility, but each introduces trade-offs in debugging, portability, cost, and security.

Recommended practices include:

1. Use semantic HTML and accessible design from the beginning.

2. Prefer HTTPS and keep certificates and dependencies managed.

3. Design clear resource URLs and appropriate HTTP methods and status codes.

4. Validate and authorize on the server; never trust browser controls alone.

5. Measure performance instead of assuming where delay occurs.

6. Use caching deliberately, especially for personalized data.

7. Apply standards and test across browsers and assistive technologies.

8. Minimize personal data and protect secrets from URLs, logs, and client code.

9. Treat third-party scripts, APIs, and AI services as supply-chain dependencies.

10. Document architecture, failure behavior, monitoring, and recovery procedures.

Chapter Summary

The Internet is a global network of interconnected networks, whereas the Web is an application system operating over it. Internet communication is organized through layers: applications use transport protocols, transport uses IP, and IP operates across local network technologies. TCP provides reliable ordered streams, UDP provides lightweight datagrams, and QUIC supports modern HTTP/3 services over UDP.

Web applications commonly follow a client–server model and may contain presentation, application, and data tiers. URLs identify resources through schemes, hosts, ports, paths, queries, and fragments. DNS translates human-readable names into network addresses through a distributed hierarchy and caching. HTTP defines request–response communication, methods, headers, status codes, caching, and resource representations. HTTPS adds TLS-based confidentiality, integrity, and server authentication.

Browsers resolve names, establish connections, send requests, parse responses, execute scripts, and render pages. Servers and supporting infrastructure route, process, cache, and secure requests. Standards from organizations such as the W3C, IETF, and WHATWG support interoperability, accessibility, and consistent behavior. Secure and responsible web engineering also requires authorization, privacy protection, input validation, monitoring, and awareness of legal and ethical obligations. These foundations are directly relevant to AI and ML systems that consume web data or deliver model-based services.

Key Terms

Internet: Global network of interconnected networks.

World Wide Web: Interlinked resources and applications accessed through Internet protocols.

Packet: Formatted unit of data transmitted across a network.

Protocol: Agreed rules for communication between systems.

TCP/IP: The principal family of protocols used for Internet communication.

IP address: Logical address used to identify a network interface or endpoint.

TCP: Reliable, ordered transport-layer byte-stream protocol.

UDP: Connectionless datagram transport protocol without built-in delivery guarantees.

Client: System or program that requests a service.

Server: System or program that provides a service.

URL: Resource identifier that specifies access information and location.

DNS: Hierarchical system that maps domain names to resource records.

HTTP: Application protocol based on requests and responses.

HTTPS: HTTP protected by Transport Layer Security.

TLS: Protocol providing encrypted and authenticated communication.

Browser: Client application that retrieves, interprets, and renders web resources.

Web server: Software that receives HTTP requests and returns resources or delegates processing.

Cache: Stored representation used to avoid repeated computation or transfer.

API: Defined interface through which software systems communicate.

CORS: Mechanism controlling permitted cross-origin browser requests.

Review Questions

Short Answer Questions

1. How does the Internet differ from the World Wide Web?

2. What is the purpose of DNS?

3. Name and explain three common HTTP methods.

4. What security properties does HTTPS provide?

5. Why is layering useful in Internet architecture?

Long Answer Questions

1. Explain the TCP/IP model and describe how data is encapsulated as it travels across a network.

2. Describe the complete lifecycle of a browser request to an HTTPS web application.

3. Compare client–server, peer-to-peer, and multi-tier application models.

4. Explain how browsers, web servers, reverse proxies, CDNs, and databases may cooperate in a modern web system.

5. Discuss the role of standards, accessibility, privacy, and security in professional web development.

Analytical / Application Questions

1. A university dashboard exposes student identifiers in query strings and permits access based only on a hidden link. Analyze the risks and propose a safer architecture.

2. A page loads quickly for some users but slowly for others. Use the request–response lifecycle to identify possible causes and recommend measurements.

3. Design a high-level web architecture for an AI prediction API. Explain how you would address authentication, authorization, privacy, model reliability, caching, and failure handling.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes the Internet from the World Wide Web?

A. The Internet is a global network infrastructure, while the Web is an application service using it.

B. The Web is the physical infrastructure, while the Internet is a collection of HTML pages.

C. The Internet only supports email, while the Web only supports file transfer.

D. They are identical terms for exactly the same system.

Correct Answer: A. The Internet is a global network infrastructure, while the Web is an application service using it.

Question 2

Which TCP/IP layer is primarily responsible for logical addressing and routing?

A. Application layer

B. Transport layer

C. Internet layer

D. Link layer

Correct Answer: C. Internet layer

Question 3

What is the primary function of DNS?

A. Encrypting HTTP responses

B. Mapping domain names to resource records such as IP addresses

C. Rendering HTML documents

D. Guaranteeing that a website is trustworthy

Correct Answer: B. Mapping domain names to resource records such as IP addresses

Question 4

Which URL component is normally processed by the browser and not sent to the server in an HTTP request?

A. Host

B. Path

C. Query string

D. Fragment identifier

Correct Answer: D. Fragment identifier

Question 5

Which HTTP method is generally intended to retrieve a representation without requesting a state-changing action?

A. GET

B. POST

C. PATCH

D. DELETE

Correct Answer: A. GET

Question 6

What does a successful HTTP status code in the 2xx range indicate?

A. A redirection is required

B. The request was successfully processed at the HTTP level

C. The client is forbidden from accessing the resource

D. The server encountered an internal failure

Correct Answer: B. The request was successfully processed at the HTTP level

Question 7

What additional protection does HTTPS provide over ordinary HTTP?

A. Guaranteed accurate application content

B. Automatic authorization for every user

C. TLS-based confidentiality, integrity, and server authentication

D. Permanent prevention of denial-of-service attacks

Correct Answer: C. TLS-based confidentiality, integrity, and server authentication

Question 8

Which statement about TCP is correct?

A. It provides an unreliable unordered datagram service.

B. It provides a reliable ordered byte stream between endpoints.

C. It is used only for DNS queries.

D. It automatically encrypts all application data.

Correct Answer: B. It provides a reliable ordered byte stream between endpoints.

Question 9

What is the principal purpose of CORS in browser-based applications?

A. To control which cross-origin requests a server permits

B. To replace DNS with IP addresses

C. To compress images before rendering

D. To establish a TLS certificate authority

Correct Answer: A. To control which cross-origin requests a server permits

Question 10

Why should authorization be checked on the server rather than relying only on hidden browser links or interface controls?

A. Browsers cannot display hidden links

B. Users can modify client-side requests and bypass interface restrictions

C. Server-side checks prevent all model errors

D. Authorization is unrelated to web requests

Correct Answer: B. Users can modify client-side requests and bypass interface restrictions