|
Chapter 9: Web Site and Server Maintenance
|
| bet | 5/28 | | Sana | 21.03.2017 | | Hajmi | 430 Kb. | | #805 |
|
No matter where your server resides, you will need some basic components in your Web publishing infrastructure. This diagram depicts some of the core elements:
Your server is named www.ci.smallville.mi.us. (We’ll discuss server names and Internet domain names in more detail later in this chapter.) Your server has a direct, permanent connection to an Internet Service Provider or ISP. Your users connect to any service provider of their own choice (such as America Online in this example) and across the global Internet to your server.
In essence, your server waits until it “hears” a request for a Web page, then delivers it on demand. That request comes across a TCP session established by your user’s Web browser to your Web server:
Thus, your server needs to know how to “speak” the Hypertext Transfer Protocol (HTTP) in order to understand and process requests to transfer Web documents to the user. Generally speaking, your server does not need to understand anything about HTML in order to deliver content to your users. Your content providers and your authoring tools take care of producing good HTML documents; the server just sees them as files to be sent on demand. (In the case of dynamic documents and live database content, the scenario is somewhat more complicated; the server and associated software will produce HTML content “on the fly.” The HTTP server itself still doesn’t concern itself with that content, but associated tools need to generate correct HTML.)
In order to achieve the publishing mission, you will typically need more components than a simple HTTP server. This diagram depicts some of the pieces you may need:
Here we assume that the Web server is a standalone box dedicated to the function of serving Web pages. It will thus run a “process” or “service” that is capable of listening for HTTP requests and replying to them.
Note that this diagram depicts a box called a “router.” A router is a device that’s capable of deciding which traffic needs to leave the local network, and be “routed” to other networks on the Internet. The router is connected to some sort of Wide Area Network (WAN) adapter, which could vary from a simple ISDN modem to a digital interface for a modern high-speed link.
If you have an existing Internet infrastructure, you already have a router on your premises. Some “server appliances” (discussed later in this chapter) come with their own router functionality built-in; the more typical case is to have a router running in its own box. The leading vendors of routers are Cisco Systems, 3Com, and Bay Networks.
One optional device is not shown in this diagram, and that is the “firewall.” A firewall is a device that filters network activity and rejects traffic that isn’t appropriate for your local network. Firewalls also help monitor traffic and detect attacks on your various servers. Firewall functionality can be built into a router, or you might choose a separate router. While many commercial enterprises run firewalls as a matter of course, many institutions such as libraries and universities historically have chosen not to. Over time as security needs increase, firewalls may become popular in virtually all sites. Today, whether your site incorporates a firewall depends on how you balance concerns about safeguarding information, maintaining open access, and budgetary constraints.
You have a choice of whether to dedicate your Web server to the sole task of serving Web content, as opposed to running multiple ancillary services on the same box. These ancillary services may reside on other servers on your premises, or even on servers hosted off-premise by someone else. If your site is small you may opt to run a variety of ancillary services on a single physical server box. For instance:
Many people find it helpful to spread services out among multiple boxes in order to isolate functions; they argue this improves performance of each function, and minimizes disruptions when servers fail. For instance, in this example, if your external database server goes down, your static HTML content (such as the main home page for your site) could still be available to users.
The choice of how many server computers to install depends on many factors: performance, budget, and the philosophy of the server administrator. In one extreme case, you would run a single Web service and a mechanism for transferring content to the server – and nothing else – on your Web server. In the other extreme case, you might run all of the services shown here on a single piece of server hardware. Most sites will choose between these extremes.
Whether you use a single server or many, note that some of these related services are essential to every Web publishing project. Others may not be necessary for your publishing project. Let’s consider each of these services:
|
| |
