In this article we go over what web servers are, how they work, and why they're important.
|Prerequisites:||You should already know how the Internet works, and understand the difference between a web page, a web site, a web server and a search engine.|
|Objective:||You will learn what a web server is and gain a general understanding of how it works.|
"Web server" can refer to hardware or software, or both of them working together.
- On the software side, a web server includes several parts that control how web users access hosted files, at minimum an HTTP server. An HTTP server is a piece of software that understands URLs (web addresses) and HTTP (the protocol your browser uses to view webpages). It can be accessed through the domain names (like
mozilla.org) of websites it stores, and delivers their content to the end-user's device.
At the most basic level, whenever a browser needs a file which is hosted on a web server, the browser requests the file via HTTP. When the request reaches the correct web server (hardware), the HTTP server (software) accepts request, finds the requested document (if it doesn't then a 404 response is returned), and sends it back to the browser, also through HTTP.
To publish a website, you need either a static or a dynamic web server.
A static web server, or stack, consists of a computer (hardware) with an HTTP server (software). We call it "static" because the server sends its hosted files "as-is" to your browser.
A dynamic web server consists of a static web server plus extra software, most commonly an application server and a database. We call it "dynamic" because the application server updates the hosted files before sending them to your browser via the HTTP server.
For example, to produce the final webpages you see in the browser, the application server might fill an HTML template with contents from a database. Sites like MDN or Wikipedia have many thousands of webpages, but they aren't real HTML documents, only a few HTML templates and a giant database. This setup makes it easier and quicker to maintain and deliver the content.
There is no active learning available yet. Please, consider contributing.
To fetch a webpage, as we already said, your browser sends a request to the web server, which proceeds to search for the requested file in its own storage space. On finding the file, the server reads it, processes it as needed, and sends it to the browser. Let's look at those steps in more detail.
Technically, you could host all those files on your own computer, but it's far more convenient to store them all on a dedicated web server that
- is always up and running
- is always connected to the Internet
- has the same IP address all the time (not all ISPs provide a fixed IP address for home lines)
- is maintained by a third-party provider
For all these reasons, finding a good hosting provider is a key part of building your website. Dig through the various services companies offer and choose one that fits your needs and your budget (services range from free to thousands of dollars per month). You can find more details in this article.
Once you set up a web hosting solution, you just have to upload your files to your web server.
Communicating through HTTP
Second, a web server provides support for HTTP (Hypertext Transfer Protocol). As its name implies, HTTP specifies how to transfer hypertext (i.e., linked web documents) between two computers.
A Protocol is a set of rules for communication between two computers. HTTP is a textual, stateless protocol.
- All commands are plain-text and human-readable.
- Neither the server nor the client remember previous communications. For example, relying on HTTP alone, a server cannot remember a password you typed or what step you're on in a transaction. You need an application server for tasks like that. (We'll cover that sort of technology in further articles.)
HTTP provides clear rules for how a client and server communicate. We'll cover HTTP itself in a technical article later on. For now, just be aware of these things:
- Only clients can make HTTP requests, and then only to servers. Servers can only respond to a client's HTTP request.
- When requesting a file via HTTP, clients must provide the file's URL.
- The web server must answer every HTTP request, at least with an error message.
- On receiving a request, an HTTP server first checks whether the requested URL matches an existing file.
- If so, the web server sends the file content back to the browser. If not, an application server builds the necessary file.
- If neither process is possible, the web server returns an error message to the browser, most commonly
404 Not Found. (That error is so common that many web designers spend quite some time designing 404 error pages.)
Static vs. dynamic content
Roughly speaking, a server can serve either static or dynamic content. "Static" means "served as-is". Static websites are the easiest to set up, so we suggest you make your first site a static site.
"Dynamic" means that the server processes the content or even generates it on the fly from a database. This solution provides more flexibility, but the technical stack becomes more difficult to handle, making it dramatically more complex to build the website.
Take for example the page you're reading right now. On the web server hosting it, there is an application server that takes article content from a database, formats it, puts it inside some HTML templates, and sends you the results. In this case, the application server is called Kuma and is built with Python (using the Django framework). The Mozilla team built Kuma for the specific needs of MDN, but there are many similar applications built on many other technologies.
There are so many application servers that it's pretty hard to suggest a particular one. Some application servers cater to specific website categories like blogs, wikis or e-shops; others, called CMSs (content management systems), are more generic. If you're building a dynamic website, take the time to choose a tool that fits your needs. Unless you want to learn some web server programming (which is an exciting area in itself!), you don't need to create your own application server. That's just reinventing the wheel.
Now that you are familiar with web servers, you could: