Web Servers

Overview and Goals of This Chapter

In this chapter you will learn the core concepts and practical skills needed to deploy and manage web servers on Linux. The following sections go into detail in later chapters:

• Apache basics
• Nginx basics
• Virtual hosts
• SSL/HTTPS
• Reverse proxy concepts

This chapter ties those pieces together, focusing on:

• How web servers fit into a Linux server stack.
• Common architectures and deployment patterns.
• How to choose between Apache and Nginx and combine them.
• Performance, security, logging, and troubleshooting concerns specific to web servers.
• Operational best practices for running web workloads in production.

You are expected to already be comfortable with basic Linux administration, networking fundamentals, and systemd-based service management from earlier parts of the course.

What a Web Server Does (in Practice)

A web server’s primary role is to accept HTTP/HTTPS requests and return responses, usually:

• Static assets: HTML, CSS, JS, images, downloads.
• Dynamic content: generated by an application (PHP, Python, Ruby, Go, Node.js, etc.).
• API responses: JSON or other serialized data.
• Redirects and error pages.

Key responsibilities of a production web server:

• Terminate TCP connections (and often TLS).
• Parse and route HTTP requests.
• Enforce access control and basic security rules.
• Offload / cache frequent responses to reduce backend load.
• Log activity for monitoring, debugging, and compliance.
• Integrate with upstream application servers and databases.

Typical Web Server Architectures

Single-Server Architecture

All roles on one machine:

• Web server (Apache/Nginx).
• Application runtime (PHP-FPM, Python app, etc.).
• Database.

Pros:

• Simple to set up.
• Good for small sites, prototypes, or intranet tools.

Cons:

• Limited scalability.
• Failure of one system affects everything.
• Harder to tune components independently.

Use case: internal apps, low-traffic sites, early development.

Two-Tier: Web + Database

Split web/application from database:

• Frontend server: web server + application runtime.
• Backend server: database (e.g., PostgreSQL, MySQL/MariaDB).

Benefits:

• Independent scaling: e.g., multiple web servers, one or more DB servers.
• Clear separation for security (DB in a protected network).

Use case: most small to medium production deployments.

Three-Tier / Multi-Tier

A common arrangement:

• Load balancer (or reverse proxy) at the edge.
• Multiple web/application servers behind it.
• One or more DB servers or clusters.

Web servers often act as:

• The main gateway (if facing the internet directly).
• A reverse proxy/load balancer (fronting more application servers).

Used for:

• High-availability and scaling.
• Microservices or multi-application environments.

Static Content vs Dynamic Applications

Many deployments separate:

• Static content: served directly by Nginx/Apache, often from disk or object storage (e.g., S3 plus a CDN).
• Dynamic content: handled by an application server (e.g., Gunicorn for Python, PHP-FPM, uWSGI, Node.js, etc.).

The web server typically:

• Serves static assets from a local directory or cache.
• Proxies requests needing computation to an upstream app server.

Choosing a Web Server: Apache vs Nginx (and Others)

Details of Apache and Nginx configuration are covered in their own chapters. Here we focus on when and why to use them.

Apache HTTP Server

Characteristics:

• Mature, widely deployed, enormous module ecosystem.
• Flexible per-directory configuration via .htaccess (though not ideal for performance).
• Excellent for legacy applications and shared hosting environments.

Strengths:

• Rich auth/authz features (LDAP, Kerberos, etc.).
• Mature mod_php / PHP-FPM integration for classic LAMP stacks.
• Variety of MPM (Multi-Processing Modules) for different workloads.

Consider Apache when:

• You host many small, independent sites for different customers.
• Applications rely heavily on .htaccess rules.
• You need diverse authentication modules out of the box.

Nginx

Characteristics:

• Event-driven, asynchronous architecture; very efficient with many concurrent connections.
• Strong focus on reverse proxying, load balancing, and static file serving.
• Configuration is centralized in the main config and included files (no .htaccess).

Strengths:

• Excellent performance for static content and as a TLS terminator.
• Built-in reverse proxy and load-balancing features.
• Smaller memory footprint and simpler config for common cases.

Consider Nginx when:

• You need high concurrency and efficient resource usage.
• You want a dedicated reverse proxy / load balancer.
• You have modern app stacks (e.g., Node.js, Python, Go) behind it.

Using Apache and Nginx Together

A common pattern:

• Nginx on port 80/443 as a reverse proxy and static file server.
• Apache behind it on a different port (e.g., 8080) to handle legacy applications.

Nginx can:

• Handle TLS termination.
• Perform HTTP/2, compression, caching.
• Distribute requests among multiple Apache backends.

Apache continues to provide:

• Compatibility for old .htaccess-based apps.
• Advanced auth modules.

Core Concepts for All Web Servers

HTTP and HTTPS Basics

Web servers implement HTTP/1.1, and often HTTP/2 and/or HTTP/3.

At a high level:

• Client opens a TCP connection to the server’s IP:port (default HTTP: 80, HTTPS: 443).
• Sends an HTTP request (e.g., GET /index.html HTTP/1.1).
• Server returns a status code (e.g., 200, 301, 404, 500) and headers, then optional body.

As an admin you will often:

• Inspect request/response structure when debugging.
• Configure redirects (3xx responses), caching hints, and security headers.

HTTPS adds TLS:

• Encrypts traffic.
• Requires certificates and keys.
• Adds CPU and configuration complexity but is now considered mandatory for public sites.

Ports and Binding

A web server typically:

• Listens on 0.0.0.0:80 and 0.0.0.0:443 for all interfaces, or
• A specific IP address and port for isolated services.

Common tasks:

• Configure listeners (e.g., by Listen/server directives).
• Ensure firewall rules allow access.
• Bind to internal-only interfaces when the service should not be internet-facing.

Static vs Dynamic Content Handling

For static content:

• Web server directly maps URLs to files on disk.
• Security requires careful path control: prevent directory traversal and access to sensitive files.

For dynamic content:

• Web server delegates processing via:
• FastCGI (e.g., PHP-FPM).
• HTTP proxy to an app server (e.g., Gunicorn, Node.js).
• Other protocols depending on your stack.

You decide, per URL path or virtual host, whether a request:

• Is served from disk,
• Is forwarded to an upstream service, or
• Is rejected or redirected.

Virtual Hosting and Multi-Site Architectures

The Virtual hosts chapter will cover concrete configuration. Here we focus on concepts and scenarios.

Name-Based Virtual Hosting

Most common method:

• Multiple domains share a single IP.
• Differentiated by the Host header in the HTTP request.

Use cases:

• Hosting many domains on a small number of servers.
• SaaS platforms with customer-specific domains.

Requirements:

• DNS for each hostname points to the same IP.
• Web server config matches Host to a virtual host/server block.

IP-Based and Port-Based Virtual Hosts

IP-based:

• Each site has a different IP.
• Used less often now; sometimes used with strict legacy requirements or certain certificates.

Port-based:

• Different sites on different ports (e.g., http://example.com:8080).
• Mainly used internally (admin consoles, backends) rather than for public websites.

Multi-Tenant Considerations

When hosting many customers / sites on the same server:

• Resource isolation becomes critical (CPU, memory, filesystem).
• Security boundaries must be defined (avoid one tenant accessing another’s data).
• File permissions, chroot/containers, and separate Unix users are common tools.

Reverse Proxies and Load Balancing

There is a separate Reverse proxy concepts chapter, but you should understand why web servers commonly act as reverse proxies.

Reverse Proxy Role

A web server acting as a reverse proxy:

• Accepts client connections.
• Forwards some or all requests to upstream servers.
• Returns the upstream response to the client.

Common functions:

• Hide internal architecture (clients see only the proxy).
• Terminate TLS (offloading crypto from backends).
• Apply uniform security and logging policies.
• Centralize routing (e.g., URL-based dispatch to different microservices).

Basic Load Balancing Patterns

With multiple upstreams, the web server can:

• Round-robin: distribute requests equally among servers.
• Least connections: send new requests to the least loaded server.
• Weighted: favor more powerful servers with higher weights.

You will typically:

• Define pools of upstreams.
• Configure health checks (if supported).
• Decide how to handle failed or slow upstreams (timeouts, retries, circuit breakers).

Path and Host-Based Routing

Reverse proxies often route based on:

• Hostname: api.example.com vs www.example.com.
• Path prefix: /api/ vs /static/.

This allows:

• Multiple applications behind one IP and one reverse proxy.
• Gradual migration and blue/green deployments (route a fraction of traffic to a new backend).

TLS/SSL and Certificates in Web Server Context

The SSL/HTTPS chapter covers in-depth configuration. Here we focus on what matters operationally.

Certificate Types

Common certificate forms:

• Single-domain: www.example.com.
• Wildcard: *.example.com.
• Multi-domain (SAN): multiple hostnames in one certificate.

As an admin, you need to:

• Understand which type matches your deployment (e.g., many subdomains vs many unrelated domains).
• Track expiration and renewal processes.
• Store private keys securely (permissions, encryption at rest where possible).

Let’s Encrypt and Automation

In modern deployments, you will often:

• Use ACME clients (e.g., certbot, acme.sh) to obtain and renew certificates.
• Integrate with your specific web server to reload configuration after renewal.
• Ensure open ports and DNS records allow the ACME challenge validation.

Key operational point:

• Automate certificate renewal and have monitoring for failures before expiration.

TLS Termination Strategies

You can:

• Terminate TLS directly on the web server handling requests.
• Terminate TLS at a front proxy / load balancer and speak plain HTTP to backends.
• Use mutual TLS in internal networks for additional security.

Trade-offs:

• Central termination simplifies certificate management.
• End-to-end TLS may be required for compliance or zero-trust environments.

Performance and Scalability Considerations

Apache/Nginx tuning specifics live in their respective chapters; this section covers general strategies.

Concurrency and Worker Models

Web servers handle many simultaneous clients. You will decide:

• Max number of concurrent connections/requests.
• Worker processes and threads per worker, depending on the server.

Tools to evaluate:

• How many open connections your hardware and kernel limits allow.
• Whether applications or DB become the bottleneck first.

Static Asset Optimization

Web servers can:

• Enable compression (e.g., gzip, brotli) for text-based assets.
• Set cache headers (Cache-Control, ETag, Last-Modified) to reduce repeated downloads.
• Support HTTP/2 or HTTP/3 to improve load times on high-latency links.

Operational practice:

• Offload huge static assets to a CDN where possible.
• Serve small static assets locally with aggressive caching and compression.

Caching Layers

You can use:

• Web server built-in cache (e.g., proxy cache) for responses from upstreams.
• Dedicated caching systems (e.g., Varnish) in front of web servers.
• Application-level caches (Redis, in-process caches).

As an admin you must:

• Decide where caching belongs in the stack.
• Configure cache keys, TTLs, and invalidation mechanisms.
• Ensure cache does not leak private data between users/tenants.

Horizontal Scaling

Scaling web servers typically means:

• Add more instances behind a load balancer.
• Ensure all instances share required data or use stateless design.

Key considerations:

• Session handling (stickiness vs external session stores).
• Shared file storage for uploads if needed (NFS, object storage, etc.).
• Config management and deployment automation so all nodes stay consistent.

Security Considerations for Web Servers

General system security is covered elsewhere; here is what’s specific to web services.

Attack Surface of Web Servers

Typical threats:

• HTTP-specific attacks (XSS, CSRF, SQL injection) mainly handled at application level.
• Resource exhaustion (DoS/DDoS) via many connections or heavy requests.
• Protocol misuse (malformed requests, header abuse).
• Information leakage (detailed error pages, directory listings).

Your job at the web server layer:

• Reduce the blast radius and reject obviously bad traffic.
• Limit resource consumption per client as much as reasonably possible.
• Avoid giving attackers detailed information about your stack.

Hardening Web Server Configuration

Common practices:

• Disable unnecessary modules/features.
• Restrict HTTP methods to those required (e.g., often just GET, HEAD, POST).
• Hide version banners where possible.
• Turn off directory listings unless explicitly needed.
• Serve sensitive paths only over HTTPS with proper access control.

Integration with system security:

• Use firewall rules (UFW, firewalld, iptables/nftables).
• Run web server as an unprivileged user, with minimal filesystem access.
• Use SELinux/AppArmor profiles tuned for your web stack where applicable.

Request and Connection Limits

To mitigate abuse:

• Limit maximum request size (to prevent giant uploads).
• Cap maximum header size and number of headers.
• Set connection timeouts and keep-alive parameters carefully.
• Optionally rate-limit certain paths or IP ranges.

Web Application Firewalls (WAF)

Often deployed:

• As a module in Apache/Nginx (e.g., ModSecurity).
• As a separate gateway.

They provide:

• Rule-based detection of common patterns (SQL injection, RCE attempts).
• Extra logging for suspicious and blocked traffic.

You must:

• Tune WAF rules to reduce false positives.
• Keep WAF signatures updated.
• Integrate WAF logs with your monitoring/alerting stack.

Logging, Monitoring, and Troubleshooting

Access and Error Logs

Every serious deployment must:

• Enable structured access/logging (status code, path, bytes, user agent, upstream info).
• Write error logs with sufficient detail for debugging.

You will typically:

• Rotate logs (logrotate) to prevent disk from filling up.
• Ship logs to a central system (e.g., via systemd-journald, syslog, or log forwarders).
• Use filters (e.g., grep, journalctl) to quickly find relevant entries.

Typical troubleshooting steps:

• Check error logs when a site is down or misbehaving.
• Correlate specific HTTP status codes (e.g., 500, 502, 503, 504) with upstream failures.
• Look for spikes in 4xx/5xx responses as early indicators of issues.

Key Metrics to Monitor

For web servers and their environment:

• Request rate (RPS/QPS).
• Latency percentiles (p50, p95, p99).
• Error rate (4xx/5xx by type).
• Connection counts and open file descriptors.
• CPU, memory, and disk I/O usage.
• TLS handshake times and certificate expiration dates.

Use:

• System-level tools (top, htop, iostat, ss) for immediate checks.
• Dedicated monitoring/metrics stack (Prometheus/Grafana, etc.) in real deployments.

Common Problems and Their Symptoms

• Misconfigured virtual host:
• Wrong site shows up for a given domain.
• TLS certificate mismatch warnings.
• App server down:
• 502/503/504 responses from the web server.
• Error log entries about upstream connection failures.
• Permissions issues:
• 403 responses for resources that should be public.
• Error log shows file permission errors or denied access.
• Exhausted resources:
• 500 errors under load.
• High CPU, memory, or open file descriptor usage.

Your workflow:

1. Observe symptoms from the client side.
2. Check web server logs and metrics.
3. Check upstream/application and database status.
4. Adjust configuration or roll back recent changes.

Operational Best Practices

Configuration Management

For reliability and reproducibility:

• Store web server configuration in version control (Git).
• Use templates where you have many similar virtual hosts.
• Apply changes using automation tools (Ansible, etc.) rather than manual edits.

Always:

• Test config syntax with built-in tools before reloading (-t options, etc.).
• Use staged rollouts in larger environments.

Deployment Strategies

You’ll often coordinate:

• Application deployment (code, assets, DB migrations).
• Web server configuration changes (new routes, headers).

Strategies:

• Blue/green: two environments, switch traffic between them.
• Canary: send a small percentage of traffic to a new version first.
• Rolling: update nodes one at a time behind a load balancer.

Web server responsibilities in deployment:

• Routing to correct application version.
• Serving maintenance pages when needed.
• Rolling reloads without dropping connections (graceful restarts).

Documentation and Runbooks

For production readiness:

• Document each site’s domains, virtual hosts, backends, and ports.
• Keep a runbook for common incidents (site down, certificate expired, high error rates).
• Define clear ownership for each service and escalation paths.

Summary

By the end of this chapter you should:

• Understand where web servers sit in typical Linux server architectures.
• Know when to choose Apache, Nginx, or both together.
• Be familiar with how web servers handle static vs dynamic content.
• Recognize the key concerns for performance, security, and scaling.
• Know what to log and monitor to keep web services reliable.

The following chapters (Apache basics, Nginx basics, Virtual hosts, SSL/HTTPS, and Reverse proxy concepts) will build on these ideas with concrete, hands-on configuration examples and deeper dives into each topic.