This section familiarize you with networking concepts and terms.
A NIC presents a single hardware interface to a network. A NIC can be wired or wireless. A typical wired NIC interfaces to a Ethernet network (the most common type of wired network). A typical wireless NIC interfaces to a IEEE 802.11b or 802.11g network.
A NIC transduces the electrical (wired), radio frequency (RF) or optical (fiber optics) signal into data in terms of a stream of 0s and 1s. Note that a NIC does very little to interpret the 0s and 1s.
A computer (server or workstation) may have any number of NICs. Most modern computers have two Ethernet NICs. Most notebook computers have one Ethernet NIC and one IEEE 802.11b/g NIC.
You can discover the active network interface using the following command
A result like the following means that eth1 is a network interface. As well as lo.
Note that lo is the loop back interface, which does not actually connect to a physical network interface card.
The Transmission Control Protocol (TCP) and Internet Protocol (IP) are the most commonly used “language” used by networked computers to talk to each other.
There are quite a few layers between a NIC and TCP/IP. This means that in terms of networking software of an operating system, there are a few levels of software libraries between the hardware driver of a NIC and the presentation of TCP/IP.
For the purpose of this module, however, it is not important to understand the layers of software in between.
Each NIC that communicates in TCP/IP (remember, TCP/IP is like a language) needs an identifier. This is similar to each active phone line needs a phone number so that other people can dial to it. The identifier of a NIC that communicates in TCP/IP is called an “IP address”.
Because an IP address is associated with a NIC, and a computer may have any number of NICs, that means a computer may have multiple IP addresses.
There are two versions of IP. IPv4 (version 4) is somewhat dated, but it remains to be the most widely used version. IPv6 is meant to replace IPv4, and it is slowly gaining momentum. For the purpose of this article, we will use IPv4.
In IPv4, an IP address has four “octets”. An octet is an eight-bit (hence the “oct”) number. An octet is a value that can range from 0 to 255 in decimal. As a result, an IPv4 address is a sequence of four numbers, each ranging from 0 to 255.
For example, 127.0.0.1 and 192.168.0.1 are IPv4 addresses.
You can check the IP address of an interface using the following command:
You should get a result similar to the following:
This means that the interface named eth1 has an IP address of 192.168.7.32. The loopback interface lo has an IP address of 127.0.0.1.
Here is where things get interesting. A single IP address may have up to 65536 ports associated with it. Each port is numbered by a value ranging from 0 to 65535. Furthermore, there is a convention relating certain port numbers to certain services.
A (network) service is a resource that is available to other computers via networking. A computer that offers a service is a server, and a computer that uses the service of another computer is a “client” with respect to that service. Note that a computer can be both a server and a client, even with respect to the same service.
The following is a list of port numbers and their associated services. Each service has an application layer protocol associated with it. Don’t worry about the purposes of services for the time being.
A full list of ports and services can be accessed at http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers.
At this point, let us assume a computer with a single NIC offers FTP so that other computers may download files from it. Furthermore, let us assume the IP address is 192.168.0.30. From the previous topic, we know that the FTP service is offered via ports 20 (data) and 21 (command).
Now, think about the following scenario. This FTP has a large file that is 500MB. Now, two client computers, 192.168.0.50 and 192.168.0.55, want to download the same file from 192.168.0.30. How is this going to happen? In other words, does one client has to wait for the other client to finish first?
If connections to a single port must be sequential, then the associated service won’t be very helpful. This is especially the case when a connection uses very little network resources but lasts a long time. Such services include SQL and telnet, where long sessions of user interaction can be expected.
As a result, most implementations of TCP/IP permits simultaneous connections to the same port. In our example, it means that 192.168.0.50 and 192.168.0.55 can both connect to port 20 and port 21 of 192.168.0.30 at the same time.
Now, how does that happen?
Let us assume 192.168.0.50 made the first request to connect to port 21 of 192.168.0.30, and 192.168.0.55 made the second request. The following is what happens:
In fact, a client may open a number of simultaneous connections to the same port of the same server at the same time. This is because a pair of sockets (one on the client, one on the server) is specific to a connection. This means that 192.168.0.50 may open a number of simultaneous connections to port 21 of 192.168.0.30. Each connection is distinct from the others.
From the file system perspective, a socket is like a special file. Ordinarily, when a program writes to a file, the data is stored somewhere. With a socket, however, when a program writes to it, the data is transmitted to another socket from which another program can read the content. The two programs may run on the same machine. Or, the two programs may run on different machines that are networked. A TCP/IP connection is one way to make one socket on one machine link to a socket on another machine.
What has to happen on the server side to offer a service, and respond to requests from clients? The operating system needs to offer a TCP/IP protocol stack. This means that the operating system needs to be able to translate the 0s and 1s from a NIC into the language known as TCP/IP.
Then, individual programs (called daemons) serve various ports. From the programming perspective, each connection requires the following steps:
In the simplest case, a server program can only handle one connection (socket) at a time because only one socket is created. Such a daemon is a non-forking daemon.
However, many daemons fork a new process whenever a connection is created, and the socket corresponding to the connection is passed along to the new process. Then another socket is created in the old process to wait for another connection.
Forking a new processing is like a program creating a clone. This means that when a cloning daemon accepts a TCP/IP connection, it creates a new clone to handle that particular connection by passing the associated socket along to the clone, while the original creates another socket and wait for another connection. This is why simultaneous connection can be made to the same port of the same IP address.
When a connection is concluded, the associated daemon clone exits and returns all the associated resources to the operating system.
It is both cumbersome and prone to error when each and every service needs a cloning daemon that replicates the logic of “new-socket, accept connection, clone”. As a result, many servers use a super-server daemon that listens to many ports at the same time.
A super-server daemon does not know how to handle services. In other words, it does not know FTP, HTTP and the other application protocols. It differs from a forking daemon in that when it accepts a connection, it creates a process that invokes a server program to handle that specific connection. This server program exits as soon as the connection terminates.
Because of the availability of the super-server daemon, a service can be implemented by a relatively simple “server program” that does not need to create sockets, bind a socket to the port of an interface, or to fork a new process. In fact, from a programming perspective, a “server program” is extremely easy to write, and it does not require any privileged operating system services.
For those who are interested in programming and details, refer to http://en.wikipedia.org/wiki/Inetd.
A daemon is essentially a program that does not have any means to interact with a user via the keyboard or screen (technically called the console). However, a daemon is useful because it interacts with other programs and the operating system. There are many ways for a daemon to communicate with another program (locally or on a remote machine) or the operating system.
One can say that a daemon executes “in the background” because such a program does not run in the foreground to interact with a user.
When network ports were explained, “daemon” was mentioned. However, it should be noted that not all daemons answer network ports. This is because there are other ways to for a program to interact with a daemon, such as named pipes and file-based sockets. From the security perspective, however, named pipes and file-based sockets are not as dangerous as network ports because named pipes and file-based sockets are accessible only on the local machine.
In Linux, most daemons are started automatically according to the “init” level. Use the command man init to read the manual page of “init” and the concept of “runlevel”. Each run level specifies a collection of daemons. As a result, Linux uses this mechanism to control the “mode” of an operating system, such as single user versus multi-user, with or without a GUI environment, with or without database or web serving and etc.
Though not required, almost all Linux daemons have their control scripts located in /etc/init.d. Some of those scripts do not control a single daemon, but rather a “service” that may involve multiple daemons working together, or none at all. For example, networking is a service that may not start a daemon. On the other hand, samba has two related daemons that collectively provide a single service.
All control scripts in /etc/init.d accept a common set of options to control a service. For example, in order to turn off all networking of a computer, a super user can use /etc/init.d/networking stop. Likewise, on a server that has mysql installed, the database service can be started using /etc/init.d/mysql start.
The “run-level” of init is closely related to the scripts in /etc/init.d. A collection of folders, /etc/rc0.d to /etc/rc6.d and /etc/rcS.d contain symbolic links to the files in /etc/init.d. These folders define the services of specific run levels. For example, /etc/rc2.d contains symbolic links to services for run level 2.
Each symbolic link has a name that starts with S or K, then a two digit number. This prefix determines the sequence of the service for a run level. For example, in run-level 2, S21sysklogd (for the system kernel logger daemon) starts up before S25samba (for Windows share SMB services).
As a run level is specified by the init command, the scripts in the corresponding /etc/rcX.d folder are invoked. To switch out of a run level, the scripts are invoked with the stop parameter. To switch into a run level, the scripts are invoked with the start parameter.
To further customize run level behavior, one can edit /etc/inittab (init table). However, editing the init table can be risky, as it can cause start up problems.
To make it easier to update services to start up for each run level, Linux has a command called update-rc.d. You can look up the manual page of this command for examples of how to use the command.