Skip to main content
Advertisement

What Are Web Servers and WAS?

When operating web services, you will inevitably encounter two concepts: "Web Server" and "WAS (Web Application Server)." At first, both have "server" in their names, which can be confusing, but their roles and origins are completely different. Understanding the distinction between the two and why they are used together is the first step in learning server integration.

What Is a Web Server?​

A web server is software that receives HTTP requests from clients (browsers) and returns static content.

Static content refers to pre-stored files that are delivered as-is from the server.

  • HTML files (index.html)
  • CSS files (style.css)
  • JavaScript files (app.js)
  • Images (logo.png, photo.jpg)
  • Fonts, PDFs, videos, and other binary files

Web servers simply read these files from disk and send them to the client. They can handle this quickly and efficiently without executing any programs or querying databases.

Major Web Servers​

NameDeveloperCharacteristics
NginxIgor SysoevAsync event-driven, high performance, doubles as reverse proxy and load balancer
Apache HTTPDApache FoundationModule-based extensibility, long history, flexible configuration with .htaccess
CaddyCaddyserverAutomatic HTTPS, concise configuration syntax
IISMicrosoftOptimized for Windows environments

What Is a WAS (Web Application Server)?​

A WAS extends web server functionality by providing an application execution environment capable of generating dynamic content.

Dynamic content is a response generated at the moment of the request by running a program.

  • HTML containing the user's name after login
  • Product list queried from a database
  • Order number generated after payment processing
  • Real-time search results

To handle this processing, WAS embeds runtimes such as a Java EE container (Servlet/JSP), ** Python WSGI**, or ** Node.js**.

Major WAS Products​

NameDeveloperCharacteristics
Apache TomcatApache FoundationServlet/JSP container, lightweight, open source
JBoss / WildFlyRed HatFull Java EE spec support, enterprise-grade
WebLogicOracleEnterprise commercial, high availability
WebSphereIBMLarge financial/public enterprise environments
JettyEclipse FoundationLightweight embedded WAS

Why Separate Web Servers and WAS?​

Those new to web development often ask: "Tomcat alone can handle HTTP requests and responses, so why do we need Nginx?" In fact, Tomcat alone can receive HTTP requests and send responses. However, in production environments, they are always separated for the following reasons.

1. Performance Improvement Through Role Specialization​

Web servers (Nginx) are optimized for serving static files. Nginx's asynchronous event-driven architecture can handle tens of thousands of simultaneous static file requests. In contrast, when Tomcat directly serves static files, it runs on the JVM, creating unnecessary overhead.

[Browser]
  │
  ├─ GET /logo.png   →  [Nginx]   → Returns file immediately (no WAS needed)
  └─ GET /api/users  →  [Nginx]   → [Tomcat] → DB query → Response

2. WAS Protection (Security)​

Directly exposing WAS to the internet creates several security risks. Placing a web server in front enables:

  • Blocking external access to WAS ports (8080, 8009) via firewall
  • First-line filtering of malicious requests and DDoS by the web server
  • SSL/TLS termination at the web server layer, so WAS only needs to handle plain HTTP

3. Zero-Downtime Deployment and Operational Convenience​

With a web server in front, when replacing or restarting a WAS instance, traffic can be rerouted to another WAS instance so users don't see error pages.

4. Load Balancing (Horizontal Scaling)​

When traffic increases, you can run multiple WAS instances and have the web server distribute requests across them for load balancing.

[Browser]
     │
  [Nginx] ─ Round Robin ─┬─ [Tomcat 1]
                         ├─ [Tomcat 2]
                         └─ [Tomcat 3]

HTTP Request Flow​

Let's look at the complete request flow when a web server and WAS work together.

1. Browser sends request: https://example.com/api/products
         │
2. DNS lookup → Resolves server IP (e.g., 203.0.113.10)
         │
3. TCP connection (3-way handshake)
         │
4. TLS handshake (for HTTPS)
         │
5. [Nginx] receives HTTP request
         │
    ┌────┴──────┐
    │  Static?  │
    ├─ Yes ─────→ Read file from disk and return immediately (Tomcat not needed)
    └─ No ──────→
         │
6. [Nginx → Tomcat] Forward via proxy (HTTP or AJP protocol)
         │
7. [Tomcat] Servlet container processes request
         │
8. Business logic execution (Java code)
         │
9. Database query (JDBC)
         │
10. HTTP response generation (JSON, HTML, etc.)
         │
11. [Tomcat → Nginx → Browser] Return response

Standalone Web Server vs Standalone WAS vs Combined​

ConfigurationAdvantagesDisadvantagesBest For
Web Server OnlyFast, simpleCannot handle dynamic requestsStatic sites, CDN
WAS OnlySimple setupSecurity vulnerable, inefficient for static filesDevelopment/test environments
Web Server + WASExcellent performance, security, scalabilityIncreased configuration complexity** Production standard**

In production environments, the combination of a web server (Nginx or Apache) and WAS (Tomcat) is the de facto standard.

Summary​

  • Web Servers (Nginx·Apache): Static file serving, reverse proxying, SSL handling, load balancing
  • WAS (Tomcat): Dynamic content generation, business logic execution, database integration
  • Reasons for separation: Performance optimization, security hardening, zero-downtime deployment, horizontal scaling
  • Request flow: Browser → Web Server (static handling or proxy) → WAS (dynamic processing) → Response

The next chapter dives deeper into the differences between static and dynamic content, and explores the evolution from CGI to Servlets and WAS.

Advertisement
Advertisement