Setting Up a Local Web Server

In client-server architecture, responsibilities are sharply divided. Clients (desktops, laptops, mobile phones) initiate requests whenever a user wants to view a document, load a webpage, or fetch database records. The server silently processes incoming requests, enforces authentication, and delivers the requested payloads.

Because servers provide mission-critical resources to the entire organization, they require dedicated hardware with redundant power supplies, enterprise-grade storage, and high-bandwidth network adapters. Placing servers on a centralized network segment ensures that all departmental workstations can access company files concurrently without bottlenecks.

On your canvas, place a rackmount Enterprise Server and an Access Switch, along with two client workstations: Workstation Alpha and an Engineer Laptop.

Connect the Enterprise Server to switch port 1, Workstation Alpha to switch port 2, and the Engineer Laptop to switch port 3 using standard Cat6 Straight-Through cables.

Production servers must always have predictable static IP addresses. If a server IP changed dynamically via DHCP every morning, bookmarks, scripts, and internal DNS entries across the company would immediately break.

Open the Server inspector and configure its static IPv4 parameters: assign IP address 192.168.1.100 with subnet mask 255.255.255.0. Inside the server operating system, an embedded HTTP daemon is bound to the wildcard socket 0.0.0.0:80.

A network socket binds an IP address to a Layer 4 port number (such as `192.168.1.100:80`). Binding to the wildcard address 0.0.0.0 rather than loopback (127.0.0.1) is mandatory—it instructs the operating system kernel to accept incoming HTTP requests across every physical network interface on the machine.

Next, configure Workstation Alpha with static IP 192.168.1.10/24 and the Engineer Laptop with 192.168.1.20/24 within the same broadcast domain. Confirm that all physical link lights turn solid green.

Analyzing server network and socket configuration fields:

Before a client can send an HTTP request, the two machines must establish a reliable transport layer session. HTTP relies on the Transmission Control Protocol (TCP) at Layer 4, which uses a synchronized three-way handshake.

The TCP handshake synchronizes connection parameters in three discrete steps:

Because TCP handles sequencing, retransmission of lost packets, and flow control, application developers never have to worry about missing bytes.

Analyzing the TCP connection setup steps:

With the reliable TCP tunnel established, Workstation Alpha transmits its application layer payload: an HTTP GET request.

Open the web browser on Workstation Alpha, enter http://192.168.1.100, and press Enter. The browser generates plaintext ASCII headers:

GET / HTTP/1.1 Host: 192.168.1.100 User-Agent: SimnetaBrowser/2.0 Accept: text/html

When the web server daemon receives these headers, it validates the request, fetches the target index.html file from local disk, and generates an HTTP 200 OK response.

The server headers contain metadata including Content-Type, Content-Length, and Server version, followed by the HTML markup that renders the corporate portal on the user monitor.

Examining the HTTP transaction structure:

In enterprise troubleshooting, network engineers rarely rely on graphical browsers alone. Instead, they use command-line utilities like curl to inspect raw HTTP status codes and headers.

Open the CLI terminal on Workstation Alpha and execute curl -i http://192.168.1.100 to request both protocol headers and HTML body content across the local switch.

Observe the server reply displaying headers, status code, and HTML body.

Analyzing the terminal verification output: