 |
 Click here to learn more about Hill Associates, Inc. |
|
TCP/IP and the Internet |
|
|
PROTOCOL |
URL FORMAT/EXAMPLE |
|---|---|
|
File reference |
file://hostname/path/filename |
|
FTP |
ftp://username:password@hostname:port/path/filename |
|
Gopher |
gopher://host:port/gopher-path |
|
HTTP |
http://host:port/directory/filename?searchpart |
|
Telnet |
telnet://username:password@host:port/ |
|
|
mailto:e-mail_address |
Finally, with the
use of the File Transfer Protocol (FTP), Telnet, Gopher, HTTP, and
other protocols over the Web, it became increasingly cumbersome to
write down a host address, user name, password, protocol port
number, directory path, file name, search string, and other
relevant information in a clear fashion. Uniform Resource
Locators, or URLs, were designed to provide such a shorthand, as
shown in Table 1.
Selecting The Web Server And Communications Facility
There are Web server products on the market for nearly every type of hardware and every operating system, providing users with significant choice in the selection of hardware and software. All of the products have slightly different capabilities, of course, and the main criteria are cost, adherence to Web standards, processing power, security, and additional features, such as the capability of the server to communicate with local databases. The largest body of server software is available for the various dialects of UNIX, with Windows NT not far behind; but WWW server software is also available for Windows 95, Windows 3.1, NetWare, OS/2 Warp, and MacOS.
Before selecting the server, there are a number of issues that the user must address. The most important one is to match the capabilities of the server hardware, server software, and communications facility to the expected use of the site. This means backing up even one more step and determining why you are building a server, and who the target audience is, what kinds of applications you will be running.
In general, you want the Web server to be a pretty powerful system to avoid common bottlenecks. First, you want the fastest processor that is reasonable; a small Web site may be able to get by with a 486 machine while a large Web site may need multiple Alpha workstations. Second, use software that matches the sophistication of your site. Shareware Web server software may suffice for your intended application but a commercial package may employ a better TCP/IP and HTTP implementation, not to mention better security. Third, load up on memory and disk space. This is particularly important because more memory will allow more simultaneous TCP connections which, in turn, will support more simultaneous users and/or faster downloads. Be sure that you use fast memory and disk controllers. Consider also the Web-based applications that you intend to provide; if your site has only text and simple graphics, you may not need as powerful a processor as if you are providing real-time audio and video.
The communications facility will, of course, play a big role as well. For general Internet users, there are three primary ways to gain access to the Internet; via a dial-up host account with an online provider such as AOL, CompuServe, or Netcom; a dial-up IP connection using SLIP or PPP; or a dedicated connection of some sort. If you want to host a Web server, the only effective option is for the server to be directly connected to the Internet 24 hours a day, 7 days a week. That means that either the Web server is physically a part of your own local network or the server is part of your provider's network; in either case, it is connected to the Internet on a full-time basis and is always accessible.
One technical aspect of this connection is the speed and responsiveness of the communications facility. In the late-1980s, the Internet backbone was comprised of what was then considered to be high-speed links -- 56 kbps! The backbone has since been upgraded to T1 (1.5 Mbps), T3 (45 Mbps), and OC-3 (155.52 Mbps); and OC-12 (622 Mbps) is expected in early 1997 [Author's Note: MCI's upgrade was completed in November 1996]. So, what's the right access speed to your premises?
The answer lies in several factors: what is available, what you can afford, and what your application requires. Just a few years ago, a "dedicated Internet connection" meant a leased line; since leased lines are billed on a mileage basis, this effectively limited users to a very local ISP. Today, frame relay, Switched Multimegabit Data Service (SMDS), and Asynchronous Transfer Mode (ATM) access allows users to be literally hundreds or thousands of miles from their ISP and still have "dedicated" access. Dedicated access at 56 kbps is about the lowest commonly used speed and can support Internet access by multiple users on a LAN. Faster speeds, of course, are what everyone wants; users today justify high-speed Internet access because it lessens response time rather than the traditional justification of high volume. A T1 local loop, however, may cost up to ten times that of a 56 kbps local loop.
But the application will also drive the solution. If you are running a site that contains simple text and some basic company information, 56 kbps may be quite adequate. If you are selling an online product, however, faster speeds will almost undoubtedly be warranted, especially if customers will be downloading large files or engaging in some real-time application with your server. In some instances, the communications facility operates at an adequate speed but having a single Web server is insufficient!
Another related, but not-so-technical issue, is that of the server's domain name. Every host on the Internet has a numeric IP address; almost all also have a name. The domain portion of the name identifies the owner (or apparent owner) of the subnet where the Web server resides. End user organizations access the Internet through an ISP. For routing and addressing efficiencies, most ISPs are assigned a block of addresses. If a user has a dedicated connection to the Internet through their ISP, they will usually have the option of obtaining a domain name and will be assigned an address within their ISP's address block.
If your company operates a Web server, you probably want the server to have your domain name. In some industries, this is not just a matter of snob appeal anymore, but a very real one of credibility. My family's Internet access, for example, is through a local ISP called Together Networks, and my personal home page can be found at http://www.together.net/~kessler/gck.html. This is fine for me as a person since most people don't expect individuals to necessarily have their own domain name (yet!).
But how much credibility would a network provider, equipment manufacturer, or service organization have without their own domain? BBN's home page, for example, is at http://www.bbn.com, much more "professional" than if it were at an address such as http://www.websrus.vt.us/~bbn/home.html.
Your ISP should be able to help you register a domain name; if they are unable to help you, think twice before doing business with them. If they won't allow you to register a domain name because they won't do the routing or manage the domain name system (DNS) database, then you should probably find another ISP. As an aside, domain name registration in the com, edu, gov, net, and org domains costs $50 per year.
It is well beyond the scope of this article to discuss all of the issues related to finding an ISP. There are, however, between 1500 and 2000 ISPs in the U.S. The so-called "second tier" ISPs -- those directly connected to the Internet backbone network or the Network Access Points (NAPs) -- are national providers such as AT&T, BBN Planet, CompuServe, MCI, Netcom, and Sprint. The "third tier" ISPs connect to the backbone via a second tier provider.
This distinction is important. A second tier network has more control over its network than one of its customers (e.g., the third tier provider), but that may or may not translate into better service for you. One might expect a higher level of technical expertise at a large ISP than at a small one, but that assumption may not be valid; a local ISP may be more responsive to your needs and provide you with a higher level of service than a bigger provider, particularly if you are a small company.
Remember that if you have dedicated access to the Internet, your ISP provides a line to your router. Most of the technical work is on your network; your ISP is primarily a conduit. But do be sure that they will provide DNS support and/or a backup DNS to your local system, and a backup mail relay system. Access to NETNEWS may or not may not also be an important criteria.
There are many
places on the Internet to get lists of ISPs. Two places to start
are the Internet Society (http://www.isoc.org/~bgreene/nsp-index.html)
and Yahoo! (http://www.yahoo.com/Business_and_Economy/Companies/Internet_Services/).
Configuring The Server Software
Most Web server software installs easily, but some rudimentary configuration is necessary before operation is possible. After acquiring the software, configuration files must be created (or edited); some server software gives you just a few options while some other software has many configuration files. Usually, default entries can be used for most of the parameters. Parameters that almost always need to be configured include:
-
Port number: The TCP port number on which the Web server "listens." The default port is 80, although any other unused port number may be used instead (and often is for experimental servers).
-
Root directory: Specifies the root directory for HTTP applications to provide protection against outside users perusing your server's disk. All HTML file requests are automatically relative to this directory. For example, suppose the root directory (on a UNIX system) is configured to be /usr/local/webroot. Individual users or projects, then, will be given directories under this path, but only the subdirectory name must be provided in the URL. Thus, the file /usr/local/webroot/gck/home.html could be accessed with the URL http://www.websrus.vt.us/gck/home.html.
-
Default HTML filename: Specifies the name of the HTML file to be returned to the client when no file name is specified; the filename index.htm or index.html is often used. With some servers, this filename is automatically searched for whenever a user specifies any directory without a file name; if the file is missing, many servers will return a list of all files in that directory.
-
Number of TCP connections: Controls the number of TCP connections that can be open simultaneously. This value affects the performance of the server and the number of simultaneous users, and should be as high as can reasonably be supported by your hardware and TCP/IP software. Each TCP connection requires that a block of memory be set aside, which is why the amount of available RAM is so important.
-
Location of special files: Indicates where the server should place various administrative, log, statistics, and security files.
-
Name of server: The hostname of this machine.
-
Name of the administrator: Specifies the e-mail address of the Web site administrator; the name webmaster is most frequently used. Note that the e-mail address of the webmaster does not have to be in the same domain as the server; thus, the server name might be www.websrus.vt.us and the webmaster's address might be webmaster@gary.org.
As stated above, the
number of configurable parameters varies widely. The NCSA HTTPd
server, for example, has many configuration files with many
configurable parameters (a portion of one such file is shown in
Table 2), while NetManage's Personal Web Server for Windows 95 has
only four configurable parameters.
# This is the main server configuration file. It is best to # leave the directives in this file in the order they are in, or # things may not go the way you'd like. See URL http://hoohoo.ncsa.uiuc.edu/ # for instructions. # ServerType is either inetd, or standalone. ServerType standalone Port 80 # User/Group: The name (or #number) of the user/group to run httpd as. User nobody Group #-1 ServerAdmin webmaster@websrus.vt.us ServerRoot /usr/local/httpd ErrorLog logs/error_log RefererLog logs/referer_log ServerName www.websrus.vt.us |
============== ------------ --------------- ------------- ------------
| Why build | | Assemble | | Create | | Implement | | Maintain |
| a site? |-->| design |-->| (& revisit) |-+->| ideas! |-->| Update |
| | | team | | content | | ------------- | Respond |
| What | ------------ --------------- ^ ------------
|capabilities| |
| do you | ------------- --------- ---+------
| want? | | Select | | Get | | Get |
| |-->| server |-->| ISP |-->| domain |
============== | h/w & s/w | | conn. | | name |
------------- --------- ----------
FIGURE 1. Steps in building a Web site.
Goals Of Your Web Site
The first step in designing a web site is to identify one or more goals of the site. If a site is being used for marketing purposes (which will be true for any commercial organization), it is imperative that you articulate why you are building a site.
This is actually harder than it may appear. Every page at the site should have a purpose. Are you trying to sell a product, promote your organization or company, provide a public service, sway public opinion, or what? Answers to these questions will start to dictate the layout and framework of your site, as well as the content, which may range from the serious to the frivolous. Answers to these questions may change over time.
Who is the target audience? Answering this question will help you understand the likely sophistication and Internet access method of the expected user population. As much as possible, orient your site to the capabilities of the audience.
Determine the organizational resources that will be made available. This includes personnel (e.g., the Webmaster), communications facilities and network resources, and computers systems (e.g., the Web server).
Finally, providing services or accepting money over the network requires special attention. If you are using your site to sell products, then care must be taken to ensure that the server and the network can keep up with demand. Web-based commerce is particularly intriguing; just about anything that can be purchased can be purchased over the Web, ranging from clothes and books to vacations and tickets to sporting events. Web-based commerce may be very lucrative; revenues from Web-based transactions reached nearly $500 million in 1995 and other studies suggest that these revenues will reach $6.6 billion by 2000, $46 billion by 1998, and $1 trillion by 2001, indicating that no one really knows what the future holds!
It is important,
however, that the value of your site not be judged solely
on the direct revenue that it brings in. In many industries today,
a Web site is as much a part of basic business communication as a
telephone and fax machine. If you must cost-justify your presence
on the Web, try to estimate the amount of revenue not
realized due to your absence. Look at your competition. If they're
on the Web, you'd better be there, too; if they're not, you have a
tremendous opportunity.
Site Design Plan
The second step in designing the site is to create a site design plan. In some cases, you may want to go to a third-party that specializes in the creation and storage of Web pages. But if you do it within your own organization, create a project team that comprises someone from every corporate entity that has an interest in the server, including network operations, marketing, art designers, etc.
Identify who (or what group) will design the overall layout, as well who will actually design the individual pages and supply content. Identify who has the technical skills to write HTML, Java scripts, PERL code, CGI forms, surveys, etc. Determine where the site will be physically hosted. Go to other Web sites on the Internet and learn from what you like and don't like. Determine how your site can extend -- or define -- your company's "marketing" image.
As you design the page, focus on content, organization, and usefulness. Don't overdo the graphics, audio, video, frames, CGI, Java, animation, and other high-tech jazz; while they may be cute the first one or two times someone visits the site, after that they're potentially annoying and slow down access. In some cases, some of these features are actually security risks. If these features are important to your site's content, then by all means use them; but if they're just their for flash, then consider carefully their necessity. Along these lines, consider carefully before using browser-specific capabilities; always ask "is this feature really necessary?"
Finally, be sure to
identify how corporate policies relate to your site. Some policies
may affect content; e.g., a "privacy policy" may
prohibit use of Web pages containing any personal employee
information. Other policies or procedures may affect external
access, such as use of a corporate firewall.
Building Your Site
The third step is building your site is to ensure that your site is usable and worth returning to. Provide sufficient information at the very top page so that users know who you are and what you do, and what they can find at the site. Make navigation as easy as possible; provide a site map and local search engine, if applicable.
You also should provide users with a reason to want to return to your site. You might want to sponsor a contest and give away something periodically. You may want to include a periodic newsletter, column, humor, advice, industry insights, etc. You might want to host a discussion list, BBS, or information archive on some topic to demonstrate your commitment to that issue.
It is important that you keep the site dynamic. Realize, however, that you may not be able to stop once you start; if you post a monthly newsletter and let it languish, it may raise questions as to what's up with your organization.
Finally, be mindful
of security and build in the appropriate precautions. Not only is
it safer for you, but customers appreciate it as well.
Test And Maintain The Site
The fourth step in running a site to continually test and maintain the server. Before information goes online, examine the content. Is it readable? Is it grammatically right? Are there spelling errors? Does it look ok? Is it logical?
Also, be sure to test all links to ensure accuracy, and keep the links up-to-date; it is surprising how many sites have invalid links and pointers to their own server.
In addition, keep the content current and accurate. Although it is chic to include a date on your Web pages, only do so if you change your pages often and/or the date is relevant.
Provide an e-mail link to the webmaster at your site and solicit input from your viewers. And listen carefully to the suggestions.
Finally, continually
monitor your hardware, software, and communications facilities to
ensure that they are meeting your needs. Responsive, fast,
available servers are a must to successfully provide a Web-based
product or service.
Advertise Yourself
The fifth step is to get advertised. Publicize your site by registering with the popular search tools, such as Yahoo! (http://www.yahoo.com), Lycos (http://www.lycos.com), and WebCrawler (http://www.webcrawler.com). Note also that while most such registration databases limit you to two or three categories, you can register every page if need be since each page is a different URL!
Intelligent agents such as AltaVista (http://altavista.digital.com) search all "visible" Web pages and do a text search. To ensure that these search engines find your pages under the categories that you choose, include keywords in your HTML files (using the META keyword= label).
There are other ways to advertise your site. If individuals are members of Internet discussion lists and/or USENET newsgroups, have them add your site's URL to their signature line. Put the Web site address on all business cards, literature, and other materials.
Finally, consider
carefully before advertising on the Web. Some organizations report
tremendous success with paid advertising while others have found
it to be a waste of money, making this no different from print
ads.
Conclusion
This article has discussed both the technical and non-technical aspects of putting a Web server together. Both aspects are important and must go hand-in-hand.
Installing, designing, and running a Web site is actually a fun process. What makes it hard is not the technology but the nature of bringing together many parts of an organization in the design and implementation; but that also adds to the fun. Set reasonable expectations and goals for the site and be familiar with the technology so that you know what the Web site can and cannot do.
And finally, plan
for success; almost everyone underestimates the capabilities
and potential of the Web.
About The Author: Gary Kessler is a Senior Engineer at BBN Systems and Technologies (Cambridge, MA), and works out of his home in Colchester, VT. He is the co-author of ISDN, 3rd ed., published by McGraw-Hill last August. His e-mail address is gkessler@bbn.com.
