An educational approach
By Scott Raiford
Writing@Sarten-X.com
This tutorial is designed for the enterprising individual, who wants to not just own, but host their own website. This is not for the faint of heart. If you want "someone else" to handle all the details, purchase a hosting package from a hosting company and follow their instructions. If you want to know all the gory details of how a server works, and have almost-absolute control over how your website operates, then this is the route for you.
The approach taken in this tutorial is one of education over ease. Very few details will be hidden. You have been warned. I take no responsibility for any damage caused to any network, systems, or data as a result of this tutorial. The information and instructions contained herein is accurate to the extent of my knowledge, and further limited only for the sake of the reader's understanding.
Before we begin, we must ensure you have the minimal requirements for hosting:
Hosting your own server will take as much time as you let it. If you want your server to run magical websites with lots of functions, multiple websites from the same server, or other similar feats, it will take a lot of time.
Thanks to the generosity of others, hosting your own website is very affordable. At minimum, you will need to pay for a suitable internet connection (which you probably already have) and electricity to run a computer (which shouldn't be much). Registering your own domain (which is probably recommended) will cost you about $10 per year (as of this writing in 2010).
Of course, we will need a physical link to the Internet, by means of wires, radio, pigeons, station wagons, et cetera.
It does little good to run a server if it will be immediately disabled or get you in legal trouble. Check your Internet service provider's terms of service regarding running servers on your existing connection. You can try calling customer service to ask, but bear in mind that most ISPs will try to sell you extra services (static IP address, higher bandwidth, and the like) if you ask about running a server. While these things make the life of a server administrator a little easier, they are usually not necessary. If the terms of service does not specifically say you cannot run a server, you're probably fine. Note that I am not a lawyer.
Being allowed to run a server and being able to do so effectively are different matters. Bandwidth is the measure of how much data you can send through your connection in a given time frame. Many ISPs now are capping (or considering capping) monthly bandwidth usage. Again, check your contract and any literature that you received. Note that a small server's bandwidth usage is somewhat unpredictable, but it will start small. My server (hosting a half-dozen websites, some videos, and a chat system) uses around two gigabytes per month for upload, and another two gigabytes for download.
Unfortunately, most users don't care about how much data they can get in a month. They want their data now. The single biggest factor in a website's apparent speed will be the per-second bandwidth, which is usually proportional to how much you pay for your Internet connection. You should be concerned with both the upper limit (which is advertised, and is what you pay for) and the actual throughput, which reflects how much actual data you'll be able to send, due to interference, bottlenecks, other users on the same connection, et cetera. You can test your actual throughput through any number of online services. Anything is good, but higher upload speeds are better.
This is just a device that connects to a network and serves resources (web pages) to clients. Any such device will do. Servers can be custom-built thousand-dollar machines, old recycled desktops, pulled from a dumpster, or even powered by potatoes. The actual hardware of your machine doesn't matter much.
Once you have a suitable Internet connection and a server, you need to have some way for other computers on the Internet to send you requests. Every device on the Internet has a numeric address. Other devices send data to that address, just like a mailed letter needs a postal address. However, not all addresses can be contacted by the outside world. Some addresses are reserved for private networks, much like an internal mail system for a large company. We need to ensure that your address is accessible to the outside world. This is probably the toughest requirement to verify.
First, ensure your computer can access the computer as it normally would (turned on, connected, and the like). Next, we'll need to figure out the path your information takes to reach the outside world, and make sure that the rest of the Internet can send information directly to you.
Under Windows:
From the Start menu, select "Run" (or in Vista and Windows 7, select the text box at the bottom of the menu), and enter "command" to run the Command Prompt. Type "ipconfig" and press Enter. It will display your IP address, which can take two forms:
Under Mac OS X:
Look in Network Preferences.
We are only concerned with IPv4 addresses. IPv6 addresses should "just work", but I make no guarantees. See, there's only so many possible addresses. With IPv4, we've just about run out, so we've resorted to sharing addresses between multiple computers, which makes running servers difficult. In contrast, IPv6 offers about 430 quintillion addresses per square foot of Earth's surface. Thus, if you have an IPv6 address listed, and it doesn't look like the "::ffff:" address above, you're probably fine.
With IPv4, what we want is to have a public IP address, which can best be defined as simply being not private. By convention (though not guaranteed), the following IP address blocks are private:
If you have an IP address listed that does not fall within one of those blocks, congratulations! You have a routable IP address. Skip to the next section.
If you have a local IP address inside one of those blocks, don't despair. This simply means you're on a Local Area Network, like most Internet users. Look a little further down after the IP address, for the "Default Gateway" or the "Router" address. That's the address of the next link in the chain.
Note: The following steps may not work. Different routers behave differently, and there are far too many to attempt to describe.
Open a web browser, and try to go to that address. Wander around the settings, without changing anything (yet), and look for a "WAN" or "Broadband" IP address. If that one is still private, try finding a new gateway/router, and keep trying. Eventually, you will find either a public IP address, or you will find a router your ISP controls, not you. If you don't have control of a public IP, you will be unable to run your own server.
Retrieving a webpage is actually a fairly complicated procedure. To understand all the separate systems we'll be configuring later, let's look at the process first.
When you type an address into a browser, you're really giving it a Uniform Resource Identifier. The URI tells either what you're looking for (a Uniform Resource Name, which is like an ISBN: devoid of location data, but very specific), or where to find what you want (a Uniform Resource Locator, which is like a street address: A specific location, but no information on what is there). Websites use URLs almost exclusively.
When the browser gets a URL, it breaks it down into separate parts. First is the protocol, which is usually "http", referring to the HyperText Transfer Protocol. This establishes the rules the browser will use to communicate with the server.
Next comes the server address. The server address is a series of words separated by periods. For example, "www.sarten-x.com" is a server address.
Everything else describes the actual resource to get, much like asking for a person by name when you reach their front door. Resources include web pages (written in HTML), images, movies, or any other kind of file.
Unfortunately, the Internet does not function by names. Like all computer systems, it functions by numbers. Data destined for any system on the Internet must be addressed with that system's IP address, which as you'll recall, is numeric. Humans, of course, do not function well by numbers alone. To remedy this, we use the Domain Name System to associate names with the numbers. Here's an example of how it works:
All of that takes place in about a second, and the only human involvement is entering some data into the name servers (the root and (in this example), ns1.afraid.org). Perhaps now is a good time to explain some of the historical quirks of DNS.
Back in the early days of the Internet, when it was still a prototype network known as ARPANET, the original researchers recognized how names were more useful than numbers. Every computer connected to ARPANET had a single name. The computer would also periodically retrieve a file (HOSTS.TXT) from a single master computer. That file would contain the names and addresses of every other computer on the network. As the network grew, so did this file. Imagine what such a beast would look like today!
Fortunately, the researchers developed a new way to handle all the names. Only a (relatively) few basic names would be stored by the master nameserver. Those records would point to other nameservers, that would be managed by other people. That way, when a small change needed to be made, it wouldn't require any work by the managers of the master nameserver.
This coincided with another development. Where a single organization originally could only support (financially or otherwise) running a single computer, sonn multiple computers were added. This provided a natural place to localize the name space.
Now, for example, the Acme Corporation simply controls the "acme.example" space, and can handle all its own computers. They might run one computer for email, and call it "mail". Its full hostname would be "mail.acme.example". Another computer might be for webpages, and be called "www". Its full hostname would be "www.acme.example". One of these subdomains ("research.acme.example") could itself be delegated to the company's research department, who could have their own mail server, with a full name of "mail.research.acme.example".
Note that a name for a single computer should reflect that computer's purpose. We'll discuss this more later.
With an address to send data to, and a port number to identify what service to connect to (HTTP traffic defaults to port 80), we can start making a connection. The browser sends a connection request to the server's address, and each router along the way will pass the request on to whatever router it's connected to that's closer to the destination. In this way, the request will progress through several hops to the server's location.
At each hop, the request will also be subject to rules based on its port number. In this fashion, websites (port 80) can be handled by one physical device, while email (port 25) can be handled by another physical device, which they both share the same name.
Once a connection request arrives at a server, the server's operating system will deny the request by default, unless program is specifically listening for a connection on that port. These programs that spend most of their time waiting are often called daemons. When a daemon accepts the connection request, it sends a reply back to the client running the browser, and prepares to communicate. At this point, all that the daemon can know about the client is its address.
With an established connection, the browser now has an open channel for communication with the daemon. The browser sends a request, asking for the resource specified in the URL. To continue the earlier metaphor, it asks for a person by name, having arrived at the server's front door.
Next, the browser sends more information that might be necessary to complete the request. According to the rules of HTTP, it includes the browser's name, and the name of the server that was requested. Other information is included as needed.
If we are already connected to the server, why do we need to tell the server what its own name is? Originally, HTTP didn't require it. Then, as the Web and the Internet grew, server administrators realized that it could be beneficial to run multiple websites from one physical server. Since multiple names can resolve to the same numeric address, the server can pretend to use whatever name it wants. This is known as virtual hosting. In order for the server to know what to pretend to be, the browser must include the name it's looking for.
When the browser is done sending the resource request, the server will send back the resource, assuming it exists and everything went as planned. If the resource is a web page, it is usually written in Hypertext Markup Language, which is mostly beyond the scope of this document. HTML is a markup language, which describes the content and context of a page. For example, all the structure of this page (paragraphs, headings, links, et cetera) are all noted with HTML.
Once you have everything you need, and know what needs to work, we can begin making the necessary changes. There are really only a few basic steps you must do to have your server function on a basic level. Further work is required to make it work easily, but those will be covered later. First, we must set up your network, to allow the outside world to be able to reach your server. Then, we will need to install a daemon on your server, to respond to requests. We will give your server a hostname, which will let humans remember how to find your server. We will (optionally) purchase a domain name for your server, to give you a professional appearance, and reduce your (visible) reliance on others' services. Finally, we will add a basic page to your server, to be shared with the world.
Single Internet connections are often shared between several computers, creating a Local Area Network (LAN). In this configuration, the first device inside the local network is known as the gateway, since it acts as a doorway to the outside world. When a device inside the local network tries to connect to the outside world, the gateway will notice the connection request, and maintain a table of active connections. Using this table, the gateway is able to send incoming data to the proper device. As an allegory, consider how the intended recipient of a piece of mail can sometimes be inferred from the sender, rather than reading the listed address.
When a connection from the outside world comes to the gateway unsolicited, the gateway must rely on other means to identify the recipient. By default, the usual procedure is to discard the connection request. To run a web server, we must instruct the gateway to pass along (forward) website connections to our server. The easiest way to do that is with a system known as IGD protocol, which utilizes yet another system called Universal Plug-and-play. In a nutshell, programs are capable of setting up their own forwarding, if the gateway supports UPnP.
Windows:
I recommend using a program called UPnP Port Works. It's not pretty, but it works as advertised. To use this program with a web server, the easiest path is to download version b2.0a, and extract the files to an accessible location. Open the eb4.bat file for editing (by right-clicking the file, and selecting "Edit"). Change both instances of the number 59 to the number 80. Change the description in quotes to "Web server" or some other description of your liking. Save the file, overwriting the old example. Double-click eb4.bat to run it. The program should indicate if it is successful. If the program displays "Unable to locate UPnP Router", see the manual instructions below.
Mac OS X
Manual configuration
As this process depends entirely on the gateway device used, I will not be directly covering it here. Rather, I recommend using the instructions at PortForward.com. Note that I do not recommend purchasing their software utility. Simply follow their manual instructions, and you should be fine. Remember: the application you are configuring is HTTP, which runs on port 80. Your gateway address may also not be the default listed. You can find your gateway IP listed with your local machine IP, as described previously.
Once you've configured your ports, you should test the connection before we go further. To do this, I have written a small testing program that functions as a small server. Download and run it. Simply enter a port number (80 for HTTP) and press enter. It will then wait for a connection from the outside world. Conveniently, I also have a web service to create connections. Once this test succeeds, you can now claim to be running a generic server. Your computer can accept incoming connection requests.
Since requests can now reach your computer, you need to have a daemon running to respond to the request. For this tutorial, we will use the most-popular daemon: Apache HTTP Server. Apache runs on Windows, OS X, and Linux, is very stable, very secure, and free.
Installing under Windows
First, go to the Apache HTTP Server download page. Download the Win32 binary (MSI installer, with or without SSL is up to you). Once it's finished, run the MSI installer by double-clicking it.
While installing, you will be asked for a "Network Domain" and "Server Name". These can, in practice, be anything you want, and can be changed later. The "Administrator's Email Address" will be used in some error messages, and should be a valid email address, where you don't mind seeing some spam. I highly recommend running Apache as a service on port 80.
Once Apache is installed, it may be controlled through the various controllers found in the Start menu.
Installing under OS X
Every installation of OS X has Apache preinstalled. Rather than reinvent the wheel, I will defer to the excellent tutorials by Kevin Hemenway. Only Part 1 is necessary at this point.
Once again, we should test before going further. Open a web browser and go to http://localhost/. Note that "localhost" is a special name that refers to the computer's own self. You should see the Apache test page, which on Windows is just a simple "It works!", and on OS X begins with the message "If you can see this, it means that the installation of the Apache web server software on your system was successful."
Once the test is successful, you can begin building and testing your own website. See the HTML section below. The rest of the world can access your server by directly going directly to your IP address.
Up to this point, your server has been accessible only through an IP address. Since humans don't remember IP addresses very well, you should also get a DNS record. The DNS record is an entry on a DNS server that connects a full host name (such as www.sarten-x.com) to your IP address.
There are two ways to get a DNS record. You can either purchase your own domain and set up your own DNS, or you can use someone else's domain free of charge. If you're certain you want to own your own domain, skip to the next section.
There are several services that will let you have a subdomain in an already-purchased domain for free. Two of the oldest such services are DynDNS and No-IP.com. They have registered several generic domains (such as dyndns.org), and will give you a subdomain (such as sarten-x.dyndns.org) for free, in the hope that you will purchase various services from them. Another similar service is FreeDNS.afraid.org, which handles other people's domains for free, and allows you to add your own subdomain to them (pending approval). Since I use this service for sarten-x.com, this means that anyone can have a subdomain anything.sarten-x.com, as long as I approve it.
Use of any of these services is pretty straightforward. Simply register an account, select the domain and subdomain you would like, and request it. You will be able to configure the DNS record to point to any IP address. Point it at yourself, and your server will then be accessible through that name.
From time to time, your ISP will change your IP address, in the interest of providing better support. Once your IP address changes, your DNS record will continue to point to the old address, which may not be valid, or may even point to someone else's server. To change your DNS record automatically, these DNS providers offer "Dynamic DNS clients", which will monitor for changes to your IP address.
Of course, it looks more "professional" if you have your own domain. You can have full control of it, and it can be anything (available) that you want.
The whole domain system is managed by a group called ICANN. ICANN does not deal with individual registrants, however, preferring to do as little actual work as possible. Instead, you'll need to deal with a registrar. There are many different registrars, and some are better than others. The most popular registrar is GoDaddy, which offers decent service for a decent price. One registrar to stay away from is Network Solutions. Network Solutions used to be the biggest registrar, but poor support and unethical practices have ruined their reputation.
Before you actually purchase your domain, you should put some serious thought into what domain you want to register. It should be something related to you or your business, easy to remember, pronounceable, and unique. For more suggestions, GoDaddy's founder Bob Parsons has a video with some helpful advice. For each idea, use the WHOIS lookup, to check if it's in use.
One of the main considerations when choosing a registrar is price. Registrations are done on a yearly basis. It is common for registrars to offer registrations for longer periods, at a reduced per-year price. In addition, you may be able to find coupon codes to reduce the price even further.
Finally, once you're sure of the domain you want and the registrar you want to buy from, go ahead and purchase it. When you register, you'll likely be offered several additional services. Here's a few of the more common ones:
Hosting
You definitely do not want this. You're hosting your own site now!
Private registration
ICANN requires domain owners to provide accurate contact information, so the responsible parties can be contacted in case of legal or technical problems. Unfortunately, this also opens up another method for unscrupulous marketers and other such less-than-honest folks to find you. You'll have to decide for yourself if it's really worth the extra cost, just to hide your name and address.
If you'll be handling email yourself, you don't need to pay someone else to do it for you. It's pretty easy to set up your own management, but even easier to let Google do it for you. My personal opinion is that paying for email service is not worth the cost.
Business Listings
Many registrars are now offering services to add your new site to several lists for a nominal fee. While this might be useful for a company who wants their name to be "out there" as much as possible, the simple reality is that most of those lists will find your site on their own eventually.
Once your domain is registered, your registrar will add a record to the root DNS server, usually pointing toward their own DNS servers. If you plan on using any advanced features that your registrar doesn't offer (like a dynamic DNS client), you'll need to use a third-party DNS provider. Again, I recommend FreeDNS.afraid.org. With any dynamic DNS service, the process should be pretty much the same.
You will need to register for an account, and add your domain to the system. You should be given a set of nameserver hosts (such as ns1.afraid.org), which are the servers used by that provider for DNS. Remember that the root DNS nameservers need to have a consistent chain of nameservers down to the one that actually knows where to find your website. You need to instruct your registrar to change your domain's entry in the root nameserver to point to the third-party nameserver, which will actually handle your domain. This should be a fairly simple process.
Now you'll need to add DNS records. You'll want at least two records. First, you should add a record that covers generic lookups for your domain, with no subdomain. You'll also want a record for the 'www' subdomain. Recall from earlier that subdomain names usually imply what service is provided by that location. Point the addresses at your server's IP address.
Congratulations. At this point, you're mostly done setting up your server. Again, it's time to test. Open your web browser, and simply go to your domain, just like any other user would. You should see the same Apache test page as you did in the earlier test.
Unless you have a static IP address, your address may change at any time, which will make all of your DNS entries (which point to the old address) invalid. To fix the problem, you'll have to update the DNS records to point to your new address. This can be a tedious task, and often you won't even know about the problem for several hours or even days.
There is an easy solution, however. Many third-party DNS providers offer dynamic DNS update clients. They are small programs that will monitor your IP address for changes, and update the DNS records as needed. Each DNS provider will have their own client offerings, but they all work mostly the same. Simply install the program, make sure it's configured to start automatically with your computer, and forget about it. It will probably require a name and password during installation, to identify itself as being allowed to update your records.
That just about ends the scope of this tutorial. You have a server, you have a few DNS entries, and you are serving pages to anyone who asks. What more do you really need?
Oh, right. You need content, too. Apache's test page gets very boring very quickly. You need to replace that test page with something better. Adding pages to your server is easy. All you need to do is place HTML files in a special location, known as DocumentRoot.
First, you need to make some HTML pages. HTML, the HyperText Markup Language, is a language for marking formatting details within text. For example, consider the following:
<html>
<head>
<title>A sample HTML page</title>
</head>
<body>
<p>This is a paragraph of sample text. Only <em>some<em> of it is
emphasized. The rest of it appears as normal, right up until the end.</p>
</body>
</html>
As you can see, HTML is just normal text, with the addition of tags that describe formatting. In this example, a header is defined, which contains the page's title. There is a single paragraph, which contains text. Some of that text is emphasized. Note that there's no declaration of how the page looks. That emphasized text might be underlined, italic, or emphasized in any other manner. HTML is not for describing how a page looks. It is intended to describe what a page means.
HTML files can be edited with any plain text editor, like Notepad or TextEdit. However, editing in this way requires you to know and use the HTML tags yourself. Alternatively, you can use a WYSIWYG editor like SeaMonkey's Composer, which will handle all the HTML for you. HTML is a topic deserving of its own tutorial, as it is outside the scope of this one.
All that's left is to copy the HTML files into the DocumentRoot folder. The DocumentRoot is, by defaut, in different locations on different computers.
Windows:
C:\Program Files\Apache Software Foundation\Apache2.2\htdocs
Mac OS X:
/Library/Webserver/Documents/
General:
Somewhere on your computer, there is a file named httpd.conf. Somewhere in that file, there is a DocumentRoot directive. That tells the location of DocumentRoot on your computer.
Note that when no specific page is requested, index.html is returned. You can also create subfolders inside the DocumentRoot, and they will behave as expected. For example, a URL of 'http://www.acme.example/images/funnycat.png' will request 'funnycat.png' from the folder 'images' inside the DocumentRoot on the server 'www' belonging to 'acme.exaple'.
That's all there is to it. Your computer is now a server. All you're serving right now, though, are webpages, but more functions can be hosted, as well, by simply installing a suitable daemon and opening the proper port. The DNS and domain information stays the same, since it's just used to find your server.
Similarly, that's all I have for this tutorial. If you have suggestions regarding this tutorial, please email me. I will update this tutorial as I have time and ideas.
Enjoy your new server!
What follows is information that didn't really fit into the tutorial, but is still useful nonetheless.
If you have ports open on all routers, but you still can't establish a connection, your computer may be behind a firewall. Firewalls simply block connections based on a set of criteria. One common criterion is the port the connection is going to. If your ISP runs the firewall, it's unlikely there's anything you can do, but you can try to call and ask. In addition, Windows includes its own internal firewall that may be enabled. To open ports in the Windows firewall, see the appropriate tutorial:
For hardware firewalls that you control, see your user's manual.
Every computer connected to the Internet has an IP address. Since there's only a finite number of IP addresses, most ISPs automatically assign them to users as they connect. If someone only turns on their computer for an hour out of the day, they can use the same IP address that was assigned to another computer for the previous hour. Having a static IP address means that you (and only you) will have that one single IP address. It will not change, and will not be shared.
The downside of this is that many ISPs will charge for this service, and it does not provide much benefit. The benefit is that you will never (or rarely) have invalid DNS records requiring updating. Since a dynamic DNS updater can update DNS records automatically, I do not recommend the purchase of a static IP address.
If your ISP charges based on bandwidth usage, there are a few things you can do to reduce your costs.
Use third-party services
You're probably already familiar with this concept. Rather than host pictures yourself, upload them to a photo-sharing site like Imageshack or Photobucket, and just include links on your page. You can also use CoralCDN, which is a free service that will download content from your site once per day, then redistribute it globally. For some more suggestions, take a look at Jeff Atwood's blog.
Use a hosting service
After all this, I would dare suggest paying for a hosting account? Yes. If your bandwidth costs exceed the cost of having someone else host your site, you should consider just taking the cheap route, and giving up on your server. You could always host most of your content on your paid provider, and add a new subdomain to point to your server for other (smaller) things. Sure, it's nice to claim you handle everything yourself, but it's nice to save money, too.
Throughout this tutorial, I have referred to specific products and companies. While I do not specifically endorse anything, I have no complaints about their service.
GoDaddy is one of the biggest registrars around these days, and is generally the most recommended, too. Their site is horrendously busy, and they never seem to keep things looking the same. However, they do run lots of sales and offer many discount codes, so overall they are a decent company for the final price. Another detractor is that they push lots of extra services with every purchase, which may or may not be a good thing. I chose to mention them specifically simple because it's the company that others usually mention, and confusion is best avoided in a tutorial.
While there are other free DNS services, I chose to mention FreeDNS.Afraid.org for three main reasons:
It is a noncommercial project
Personally, I feel better recommending a personal project (especially one with such a high degree of reliability) than a commercial one. This tutorial is aimed at amateurs, and I feel that we amateurs should support each other.
It is simple
Of all the DNS services I have used, FreeDNS.Afraid.org offers the simplest interface. Everything is nice and easy, and works as expected. There's no complex syntax, and no separate system for additional capabilities (like round-robin records). Everything just works.
It also offers the use of other domains
Rather than having to recommend two different services for the two different sections that use DNS, FreeDNS.Afraid.org offers both services. If someone is following this tutorial through its entirety, I'd rather keep the number of separate accounts at a minimum.
Everybody has a favorite daemon. Apache isn't mine. However, it is the most popular daemon by far, and therefore most packaged systems work easily with it. It's also the easiest to set up under Mac OS X (since it's preinstalled), and works decently in all other platforms I support. Yes, it's a big hairy overgrown beast, but it works, it's mature, and it's functional with only a default configuration.
Everybody has a favorite operating system. It is simply a fact of life that Windows and OS X are the most popular, so I've written most of my instructions regarding them. However, if you're up for a bit more of a challenge, you may want to consider some alternatives.
Linux and BSD are free (as in beer). They are available free of charge. All you need to do is download the installer, burn it to a disk (usually), and install. Yes, it's legal. Linux and BSD are developed and made available out of the goodness of programmers' hearts.
Linux and BSD have a major advantage regarding security. When a vulnerability is discovered in Windows, it must wait to be fixed until Microsoft decides that the issue is important enough. Linux and BSD have thousands of programmers who casually look for vulnerabilities. When an issue is found, a solution usually follows within a matter of hours. For this reason alone, Linux and BSD systems are more secure than Windows.
Furthermore, Linux and BSD were designed from the start for use on networks. Security is built into everything they do. Windows was designed for use without a network, so some of its older systems have gaping security holes.
In an effort to make life easier, Windows also leaves some (possibly unnecessary) systems available by default, which may contain security holes. By default, Linux and BSD close off these extra systems. In fact, one form of BSD (OpenBSD) has had only a small handful of security holes in its default state since its inception in 1997.
Note that the core of OS X is itself BSD, so OS X shares the same level of security.
All major operating systems will operate fairly efficiently, as long as nothing else is running. That said, Linux and BSD (including OS X) were designed from the start to handle multiple things running at the same time, and tend to include more on speed, rather than displaying shiny pictures on the screen. Contrast this to Windows, which was originally based on MS-DOS, which could only run one program at a time. Windows also spends a lot of time by default handling unused services and drawing nice images.
All systems, once properly configured, will run continuously as long as they have power. However, there are two main differences that separate Windows from Linux/BSD in this regard.
First, Linux and BSD are capable of updating running program while they run. Windows generally is not capable of such a feat. This means that when a program is updated on Windows, that program (or the whole computer) must be restarted, resulting in a few minutes without service.
Second, Linux and BSD run very few programs as system services. This means that when they are updated, it's not necessary to restart the whole system. Even when a critical process is updated, it does not force the computer to restart.
Each of these will save only a few minutes each time, but after a while, those minutes start adding up. I've seen many Linux systems that are restarted only once a year, or less. I personally restart my servers every few months, but that's usually because I'm tinkering with their hardware.