UNIT-III

The Web and HTTP, File Transfer: FTP, Electronic Mail in the Internet, Domain
Name System (DNS), P2P File Sharing, Socket Programming with TCP and
UDP, building a Simple Web Server Crea�ng simulated networks and passing
packets through them using different rou�ng techniques. Installing and using
network monitoring tools.
………………………………………………………………………………………………………………………

 THE WEB AND HTTP

1) Overview of HTTP :

• The HyperText Transfer Protocol (HTTP), the Web’s applica�on-layer

protocol, is at the heart of the Web. It is implemented in two programs:
a client program and a server program. The client program and server
program, execu�ng on different end systems, talk to each other by
exchanging HTTP messages. HTTP defines the structure of these
messages and how the client and server exchange the messages.
• A Web page (also called a document) consists of objects. An object is
simply a file—such as an HTML file, a JPEG image, a Java applet, or a
video clip—that is addressable by a single URL. Most Web pages consist
of a base HTML file and several referenced objects. For example, if a Web
page contains HTMLtext and five JPEG images, then the Web page has six
objects: the base HTML file plus the five images. The base HTML file
references the other objects in the page with the objects’ URLs. Each
URL has two components: the hostname of the server that houses the
object and the object’s path name. For example, the URL
http://www.someSchool.edu/someDepartment/picture.gif
• has www.someSchool.edu for a hostname and /someDepartment/
picture.gif for a path name. Because Web browsers (such as Internet
Explorer and Firefox) implement the client side of HTTP, in the context of
the Web.Popular Web servers include Apache and Microso� Internet
Informa�on Server. HTTP defines how Web clients request Web pages
from Web servers and how servers transfer Web pages to clients.
• The client sends HTTP request messages into its socket interface and
receives HTTPresponse messages from its socket interface. Similarly, the
HTTP server receives request messages from its socket interface and
sends response messages into its socket interface. Once the client sends
a message into its socket interface, the message is out of the client’s
hands and is ―in the hands‖ of TCP. TCPprovides a reliable data transfer
service to HTTP. This implies that each HTTP request message sent by a
client process eventually arrives intact at the server; similarly, each
HTTPresponse message sent by the server process eventually arrives
intact at the client. Here we see one of the great advantages of a layered
architecture—HTTPneed not worry about lost data or the details of how
TCPrecovers from loss or reordering of data within the network. That is
the job of TCPand the protocols in the lower layers of the protocol stack.
2) Non-Persistent and Persistent Connec�ons :

• In many Internet applica�ons, the client and server communicate for an

extended period of �me, with the client making a series of requests and
the server responding to each of the requests. Depending on the
applica�on and on how the applica�on is being used, the series of
requests may be made back-to-back, periodically at regular intervals, or
intermitently. When this client-server interac�on is taking place over
TCP, the applica�on developer needs to make an important decision––
should each request/response pair be sent over a
 separateTCPconnec�on, or should all of the requests and their
corresponding responses be sent over the same TCPconnec�on?
• In the former approach, the applica�on is said to use non-persistent
connec�ons; and in the later approach, persistent connec�ons.

HTTP with Non-Persistent Connec�ons

• Let’s walk through the steps of transferring a Web page from server to
client for the case of non-persistent connec�ons. Let’s suppose the page
consists of a base HTMLfile and 10 JPEG images, and that all 11 of these
objects reside on the same server. Further suppose the URLfor the base
HTMLfile is
http://www.someSchool.edu/someDepartment/home.index
• Here is what happens:
1. The HTTPclient process ini�ates a TCPconnec�on to the server
www.someSchool.edu on port number 80, which is the default port
number for HTTP. Associated with the TCPconnec�on, there will be a
socket at the client and a socket at the server.
2. The HTTPclient sends an HTTPrequest message to the server via its
socket. The request message includes the path name
/someDepartment/home.index.
3. The HTTPserver process receives the request message via its socket,
retrieves the object /someDepartment/home.index from its storage
(RAM or disk), encapsulates the object in an HTTPresponse message, and
sends the response message to the client via its socket.
4. The HTTPserver process tells TCPto close the TCPconnec�on.
5. The HTTPclient receives the response message. The TCPconnec�on
terminates. The message indicates that the encapsulated object is an
HTMLfile. The client extracts the file from the response message,
examines the HTMLfile, and finds references to the 10 JPEG objects. 6.
The first four steps are then repeated for each of the referenced JPEG
objects.

As the browser receives the Web page, it displays the page to the user.
Two different browsers may interpret (that is, display to the user) a Web
page in somewhat different ways. HTTPhas nothing to do with how a
Web page is interpreted by a client.
We need a calcula�on to es�mate the amount of �me that elapses from
when a client requests the base HTML file un�l the en�re file is received
by the client. To this end, we define the round-trip �me (RTT), which is
the �me it takes for a small packet to travel from client to server and
then back to the client. As shown in Figure 2.7, this causes the browser
to ini�ate a TCP connec�on between the browser and the Web server;
this involves a ―three-way handshake‖—the client sends a small TCP
segment to the server, the server acknowledges and responds with a
small TCP segment, and, finally, the client acknowledges back to the
server. The first two parts of the threeway handshake take one RTT.

HTTP with Persistent Connec�ons

With persistent connec�ons, the server leaves the TCP connec�on open
a�er sending a response. Subsequent requests and responses between
the same client and server can be sent over the same connec�on. In
par�cular, an en�re Web page (in the example above, the base HTMLfile
and the 10 images) can be sent over a single persistent TCP connec�on.
Moreover, mul�ple Web pages residing on the same server can be sent
from the server to the same client over a single persistent TCP
connec�on. These requests for objects can be made back-to-back,
without wai�ng for replies to pending requests (pipelining). Typically, the
 HTTPserver closes a connec�on when it isn’t used for a certain �me (a
configurable �meout interval).
When the server receives the back-to-back requests, it sends the objects
back-to-back. The default mode of HTTP uses persistent connec�ons
with pipelining.

3) HTTP Message Format :

The HTTP include the defini�ons of the HTTP message formats. There are
two types of HTTP messages, request messages and response messages,
both of which are discussed below.

HTTP Request Message

Below we provide a typical HTTPrequest message:

GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Connec�on: close
User-agent: Mozilla/5.0
Accept-language: fr
The request line has three fields: the method field, the URL field, and the
HTTP version field. The method field can take on several different values,
including GET, POST, HEAD, PUT, and DELETE. The great majority of HTTP
request messages use the GET method. The GET method is used when
the browser requests an object, with the requested object iden�fied in
the URL field. In this example, the browser is reques�ng the object
/somedir/page.html. The version is self-explanatory; in this example, the
browser implements version HTTP/1.1.

HTTP Response Message

Below we provide a typical HTTP response message. This response

message could be the response to the example request message just
discussed.
HTTP/1.1 200 OK
Connec�on: close
Date: Tue, 09 Aug 2011 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 09 Aug 2011 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html
(data datadatadatadata ...)
• 200 OK: Request succeeded and the informa�on is returned in the
response.
• 301 Moved Permanently:Requested object has been permanently
moved; the new URL is specified in Loca�on: header of the response
message. The client so�ware will automa�cally retrieve the new URL.

• 400 Bad Request: This is a generic error code indica�ng that the
request could not be understood by the server.
 • 404 Not Found: The requested document does not exist on this server.
• 505 HTTP Version Not Supported: The requested HTTP protocol version
is not supported by the server.

4) User-Server Interac�on: Cookies :

It is o�en desirable for a Web site to iden�fy users, either because the
server wishes to restrict user access or because it wants to serve content
as a func�on of the user iden�ty. For these purposes, HTTP uses cookies.
.
As shown in Figure, cookie technology has four components: (1) a cookie
header line in the HTTP response message; (2) a cookie header line in
the HTTP request message; (3) a cookie file kept on the user’s end
system and managed by the user’s browser; and (4) a back-end database
at the Web site.

5) Web Caching :

A Web cache—also called a proxy server—is a network en�ty that

sa�sfies HTTP requests on the behalf of an origin Web server. The Web
cache has its own disk storage and keeps copies of recently requested
objects in this storage
1. The browser establishes a TCP connec�on to the Web cache and sends
an HTTP request for the object to the Web cache.
 2. The Web cache checks to see if it has a copy of the object stored
locally. If it does, the Web cache returns the object within an
HTTPresponse message to the client browser.
3. If the Web cache does not have the object, the Web cache opens a
TCPconnec�on to the origin server, that is, to www.someschool.edu.
The Web cache then sends an HTTPrequest for the object into the cache-
to-server TCPconnec�on. A�er receiving this request, the origin server
sends the object within an HTTPresponse to the Web cache.
4. When the Web cache receives the object, it stores a copy in its local
storage and sends a copy, within an HTTPresponse message, to the client
browser.

6) The Condi�onal GET :

An HTTPrequest message is a so-called condi�onal GET message if (1)

the request message uses the GET method and (2) the request message
includes an If-Modified-Since: header line.

 FILE TRANSFER : FTP

In a typical FTP session, the user is si�ng in front of one host (the local
host) and wants to transfer files to or from a remote host. In order for
the user to access the remote account, the user must provide a user
iden�fica�on and a password. A�er providing this authoriza�on
informa�on, the user can transfer files from the local file system to the
remote file system and vice versa. As shown in Figure , the user interacts
with FTPthrough an FTPuser agent. The user first provides the hostname
of the remote host, causing the FTP client process in the local host to
establish a TCP connec�on with the FTP server process in the remote
host. The user then provides the user iden�fica�on and password, which
are sent over the TCP connec�on as part of FTP commands.
Once the server has authorized the user, the user copies one or more
files stored in the local file system into the remote file system (or vice
versa).
HTTP and FTP are both file transfer protocols and have many common
characteris�cs; for example, they both run on top of TCP. However, the
two applica�on-layer protocols have some important differences. The
most striking difference is that FTP uses two parallel TCPconnec�ons to
transfer a file, a control connec�on and a data connec�on. The control
connec�on is used for sending control informa�on between the two
hosts—informa�on such as user iden�fica�on, password, commands to
change remote directory, and commands to ―put‖ and ―get‖ files.
When a user starts an FTP session with a remote host, the client side of
FTP (user) first ini�ates a control TCP connec�on with the server side
(remote host) on server port number 21. The client side of FTP sends the
user iden�fica�on and password over this control connec�on. The client
side of FTP also sends, over the control connec�on, commands to
change the remote directory. When the server side receives a command
for a file transfer over the control connec�on (either to, or from, the
remote host), the server side ini�ates a TCP data connec�on to the client
side. FTPsends exactly one file over the data connec�on and then closes
the data connec�on. If, during the same session, the user wants to
transfer another file, FTP opens another data connec�on.

FTP COMMANDS AND REPLIES

We end this sec�on with a brief discussion of some of the more common
FTP commands and replies. The commands, from client to server, and
replies, from server to client, are sent across the control connec�on in 7-
bit ASCII format. Thus, like HTTP commands, FTP commands are readable
by people. In order to delineate successive commands, a carriage return
and line feed end each command. Each command consists of four
uppercase ASCII characters, some with op�onal arguments. Some of the
more common commands are given below:
• USER username: Used to send the user iden�fica�on to the server.
• PASS password: Used to send the user password to the server.
 • LIST: Used to ask the server to send back a list of all the files in the
current remote directory. The list of files is sent over a (new and non-
persistent) data connec�on rather than the control TCPconnec�on.
• RETR filename: Used to retrieve (that is, get) a file from the current
directory of the remote host. This command causes the remote host to
ini�ate a data connec�on and to send the requested file over the data
connec�on.
• STOR filename: Used to store (that is, put) a file into the current
directory of the remote host.
Each command is followed by a reply, sent from server to client. The
replies are three-digit numbers, with an op�onal message following the
number. This is similar in structure to the status code and phrase in the
status line of the HTTP response message. Some typical replies, along
with their possible messages, are as follows:
• 331 Username OK, password required
• 125 Data connec�on already open; transfer star�ng
• 425 Can’t open data connec�on
• 452 Error wri�ng file

 ELECTRONIC MAIL IN THE INTERNET

Electronic mail has been around since the beginning of the Internet. It
was the most popular applica�on when the Internet was in its infancy
and hasbecome more and more elaborate and powerful over the years.
It remains one of the Internet’s most important and u�lized applica�ons.
As with ordinary postal mail, e-mail is an asynchronous communica�on
medium—people send and read messages when it is convenient for
them, without having to coordinate with other people’s schedules. In
contrast with postal mail, electronic mail is fast, easy to distribute, and
inexpensive. Modern e-mail has many powerful features, including
messages with atachments, hyperlinks, HTML-formated text, and
embedded photos.
Figure presents a high-level view of the Internet mail system, it has three
major components: user agents, mail servers & Simple Mail Transfer
Protocol (SMTP).
We now describe each of these components in the context of a sender,
Alice, sending an e-mail message to a recipient, Bob. User agents allow
users to read, reply to, forward, save, and compose messages. Microso�
Outlook and Apple Mail are examples of user agents for e-mail. When
Alice is finished composing her message, her user agent sends the
message to her mail server, where the message is placed in the mail
server’s outgoing message queue. When Bob wants to read a message,
his user agent retrieves the message from his mailbox in his mail server.
Mail servers form the core of the e-mail infrastructure. Each recipient,
such as Bob, has a mailbox located in one of the mail servers. Bob’s
mailbox manages and maintains the messages that have been sent to
him. Atypical message starts its journey in the sender’s user agent,
travels to the sender’s mail server, and travels to the recipient’s mail
server, where it is deposited in the recipient’s mailbox.
When Bob wants to access the messages in his mailbox, the mail server
containing his mailbox authen�cates Bob (with usernames and
passwords). Alice’s mail server must also deal with failures in Bob’s mail
server. If Alice’s server cannot deliver mail to Bob’s server, Alice’s server
holds the message in a message queue and atempts to transfer the
message later. Reatempts are o�en done every 30 minutes or so; if
there is no success a�er several days, the server removes the message
and no�fies the sender (Alice) with an e-mail message.
SMTP is the principal applica�on-layer protocol for Internet electronic
mail. It uses the reliable data transfer service of TCPto transfer mail from
the sender’s mail server to the recipient’s mail server. As with most
applica�on-layer protocols, SMTPhas two sides: a client side, which
executes on the sender’s mail server, and a server side, which executes
on the recipient’s mail server. Both the client and server sides of SMTP
run on every mail server. When a mail server sends mail to other mail
servers, it acts as an SMTPclient. When a mail server receives mail from
other mail servers, it acts as an SMTPserver.

SMTP :

SMTP is at the heart of Internet electronic mail. As men�oned above,

SMTP transfers messages from senders’mail servers to the recipients’
mail servers. SMTP is much older than HTTP.
To illustrate the basic opera�on of SMTP, let’s walk through a common
scenario. Suppose Alice wants to send Bob a simple ASCII message.

1. Alice invokes her user agent for e-mail, provides Bob’s e-mail address
(for example, [email protected]), composes a message, and
instructs the user agent to send the message.
2. Alice’s user agent sends the message to her mail server, where it is
placed in a message queue.
3. The client side of SMTP, running on Alice’s mail server, sees the
message in the message queue. It opens a TCPconnec�on to an
SMTPserver, running on Bob’s mail server.
4. A�er some ini�al SMTPhandshaking, the SMTPclient sends Alice’s
message into the TCPconnec�on.
5. At Bob’s mail server, the server side of SMTPreceives the message.
Bob’s mail server then places the message in Bob’s mailbox.
6. Bob invokes his user agent to read the message at his convenience.

Let’s next take a look at an example transcript of messages exchanged

between an SMTP client (C) and an SMTP server (S). The hostname of
the client is crepes.fr and the hostname of the server is hamburger.edu.
The ASCII text lines prefaced with C: are exactly the lines the client sends
into its TCP socket, and the ASCII text lines prefaced with S: are exactly
the lines the server sends into its TCP socket. The following transcript
begins as soon as the TCP connec�on is established.

S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <[email protected]>
S: 250 [email protected] ... Sender ok
C: RCPT TO: <[email protected]>
S: 250 [email protected] ... Recipient ok
C: DATA
S: 354 Enter mail, end with ―.‖ on a line by itself
C: Do you like ketchup?
C: How about pickles?
C: . S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connec�on

In the example above, the client sends a message (―Do you like
ketchup? How about pickles?‖) from mail server crepes.fr to mail server
hamburger.edu. As part of the dialogue, the client issued five commands:
HELO (an abbrevia�on for HELLO), MAIL FROM, RCPT TO, DATA, and
QUIT. These commands are self-explanatory.
Comparison with HTTP :

First, HTTP is mainly a pull protocol—someone loads informa�on on a

Web server and users use HTTPto pull the informa�on from the server at
their convenience. In par�cular, the TCPconnec�on is ini�ated by the
machine that wants to receive the file. On the other hand, SMTP is
primarily a push protocol—the sending mail server pushes the file to the
receiving mail server. In par�cular, the TCP connec�on is ini�ated by the
machine that wants to send the file.
A second difference, which we alluded to earlier, is that SMTP requires
each message, including the body of each message, to be in 7-bit ASCII
format. If the message contains characters that are not 7-bit ASCII (for
example, French characters with accents) or contains binary data (such
as an image file), then the message has to be encoded into 7-bit ASCII.
HTTP data does not impose this restric�on.
Athird important difference concerns how a document consis�ng of text
and images (along with possibly other media types) is handled. As we
learned in Sec�on, HTTP encapsulates each object in its own HTTP
response message. Internet mail places all of the message’s objects into
one message.

MAIL MESSAGE FORMATS :

When Alice writes an ordinary snail-mail leter to Bob, she may include
all kinds of peripheral header informa�on at the top of the leter, such as
Bob’s address, her own return address, and the date. Similarly, when an
e-mail message is sent from one person to another, a header containing
peripheral informa�on precedes the body of the message itself.
As with HTTP, each header line contains readable text, consis�ng of a
keyword followed by a colon followed by a value. Some of the keywords
are required and others are op�onal. Every header must have a From:
header line and a To: header line; a header may include a Subject:
header line as well as other op�onal header lines.
Atypical message header looks like this:
From: [email protected]
To: [email protected]
Subject: Searching for the meaning of life.
A�er the message header, a blank line follows; then the message body
(in ASCII) follows. You should use Telnet to send a message to a mail
server that contains some header lines, including the Subject: header
line. To do this, issue telnet serverName 25

Mail Access Protocols :

Once SMTP delivers the message from Alice’s mail server to Bob’s mail
server, the message is placed in Bob’s mailbox. Throughout this
discussion we have tacitly assumed that Bob reads his mail by logging
onto the server host and then execu�ng a mail reader that runs on that
host. Up un�l the early 1990s this was the standard way of doing things.
But today, mail access uses a client-server architecture—the typical user
reads e-mail with a client that executes on the user’s end system, for
example, on an office PC, a laptop, or a smartphone. By execu�ng a mail
client on a local PC, users enjoy a rich set of features, including the ability
to view mul�media messages and atachments.

Given that Bob (the recipient) executes his user agent on his local PC, it is
natural to consider placing a mail server on his local PC as well. With this
approach,Alice’s mail server would dialogue directly with Bob’s PC. There
is a problem with this approach, however. Recall that a mail server
manages mailboxes and runs the client and server sides of SMTP. If Bob’s
mail server were to reside on his local PC, then Bob’s PC would have to
remain always on, and connected to the Internet, in order to receive new
mail, which can arrive at any �me. This is imprac�cal for many Internet
users. Instead, a typical user runs a user agent on the local PC but
accesses its mailbox stored on an always-on shared mail server. This mail
server is shared with other users and is typically maintained by the user’s
ISP (for example, university or company).

Now let’s consider the path an e-mail message takes when it is sent from
Alice to Bob. We just learned that at some point along the path the e-
mail message needs to be deposited in Bob’s mail server. This could be
done simply by having Alice’s user agent send the message directly to
Bob’s mail server. And this could be done with SMTP—indeed, SMTP has
been designed for pushing e-mail from one host to another. However,
typically the sender’s user agent does not dialogue directly with the
recipient’s mail server. Instead, as shown in Figure 2.18, Alice’s user
agent uses SMTPto push the e-mail message into her mail server, then
Alice’s mail server uses SMTP (as an SMTP client) to relay the e-mail
message to Bob’s mail server.

There are currently a number of popular mail access protocols, including

Post Office Protocol—Version 3 (POP3), Internet Mail Access Protocol
(IMAP), and HTTP.

Figure provides a summary of the protocols that are used for Internet
mail: SMTP is used to transfer mail from the sender’s mail server to the
recipient’s mail server; SMTP is also used to transfer mail from the
sender’s user agent to the sender’s mail server. Amail access protocol,
such as POP3, is used to transfer mail from the recipient’s mail server to
the recipient’s user agent.

POP3 :

POP3 is an extremely simple mail access protocol, which is short and

quite readable. Because the protocol is so simple, its func�onality is
rather limited. POP3 begins when the user agent (the client) opens a TCP
connec�on to the mail server (the server) on port 110. With the TCP
connec�on established, POP3 progresses through three phases:
authoriza�on, transac�on, and update.
During the first phase, authoriza�on, the user agent sends a username
and a password (in the clear) to authen�cate the user.
During the second phase, transac�on, the user agent retrieves messages;
also during this phase, the user agent can mark messages for dele�on,
remove dele�on marks, and obtain mail sta�s�cs.
The third phase, update, occurs a�er the client has issued the quit
command, ending the POP3 session; at this �me, the mail server deletes
the messages that were marked for dele�on.
In a POP3 transac�on, the user agent issues commands, and the server
responds to each command with a reply. There are two possible
responses: +OK (some�mes followed by server-to-client data), used by
the server to indicate that the previous command was fine; and -ERR,
used by the server to indicate that something was wrong with the
previous command.

The authoriza�on phase has two principal commands: user <username>

and pass <password>. To illustrate these two commands, we suggest that
you Telnet directly into a POP3 server, using port 110, and issue these
commands. Suppose that mailServer is the name of your mail server. You
will see something like:

telnet mailServer 110

+OK POP3 server ready
user bob
+OK
pass hungry
+OK user successfully logged on
If you misspell a command, the POP3 server will reply with an -ERR
message.

Now let’s take a look at the transac�on phase. A user agent using POP3
can o�en be configured (by the user) to ―download and delete‖ or to
―download and keep.‖ The sequence of commands issued by a POP3
user agent depends on which of these two modes the user agent is
opera�ng in. In the download-and-delete mode, the user agent will issue
the list, retr, and dele commands. As an example, suppose the user has
two messages in his or her mailbox. In the dialogue below, C: (standing
for client) is the user agent and S: (standing for server) is the mail server.
The transac�on will look something like:
C: list
S: 1 498
S: 2 912
S: .
C: retr 1
S: (blah blah ...
S: .................
S: ..........blah)
S: .
C: dele 1
C: retr 2
S: (blah blah ...
S: .................
S: ..........blah)
S: .
C: dele 2
C: quit
S: +OK POP3 server signing off

The user agent first asks the mail server to list the size of each of the
stored messages. The user agent then retrieves and deletes each
message from the server.

IMAP :

With POP3 access, once Bob has downloaded his messages to the local
machine, he can create mail folders and move the downloaded messages
into the folders. Bob can then delete messages, move messages across
folders, and search for messages (by sender name or subject). But this
paradigm—namely, folders and messages in the local machine—poses a
problem for the nomadic user, who would prefer to maintain a folder
hierarchy on a remote server that can be accessed from any computer.
This is not possible with POP3—the POP3 protocol does not provide any
means for a user to create remote folders and assign messages to
folders.
To solve this and other problems, the IMAP protocol, defined in [RFC
3501], was invented. Like POP3, IMAP is a mail access protocol. It has
many more features than POP3, but it is also significantly more complex.
(And thus the client and server side implementa�ons are significantly
more complex.)

An IMAPserver will associate each message with a folder; when a

message first arrives at the server, it is associated with the recipient’s
INBOX folder. The recipient can then move the message into a new, user-
created folder, read the message, delete the message, and so on. The
IMAP protocol provides commands to allow users to create folders and
move messages from one folder to another. IMAPalso provides
commands that allow users to search remote folders for messages
matching specific criteria. Note that, unlike POP3, an IMAP server
maintains user state informa�on across IMAPsessions—for example, the
names of the folders and which messages are associated with which
folders.

Another important feature of IMAPis that it has commands that permit a

user agent to obtain components of messages. For example, a user agent
can obtain just the message header of a message or just one part of a
mul�part MIME message. This feature is useful when there is a low-
bandwidth connec�on (for example, a slow-speed modem link) between
the user agent and its mail server. With a lowbandwidth connec�on, the
user may not want to download all of the messages in its mailbox,
par�cularly avoiding long messages that might contain, for example, an
audio or video clip.

Web-Based E-Mail More and more users today are sending and accessing
their e-mail through their Web browsers. Hotmail introduced Web-based
access in the mid 1990s. Now Web-basede-mail is also provided by
Google, Yahoo!, as well as just about every major university and
corpora�on.
 DNS—The Internet’s Directory Service :

Just as humans can be iden�fied in many ways, so too can Internet hosts.
One iden�fier for a host is its hostname. Hostnames—such as cnn.com,
www.yahoo. com, gaia.cs.umass.edu, and cis.poly.edu—are mnemonic
and are therefore appreciated by humans. However, hostnames provide
litle, if any, informa�on about the loca�on within the Internet of the
host. (Ahostname such as www.eurecom.fr, which ends with the country
code .fr, tells us that the host is probably in France, but doesn’t say much
more.) Furthermore, because hostnames can consist of variablelength
alphanumeric characters, they would be difficult to process by routers.
For these reasons, hosts are also iden�fied by so-called IP addresses.

An IP address looks like 121.7.106.83, where each period separates one

of the bytes expressed in decimal nota�on from 0 to 255.

1) SERVICES PROVIDED BY DNS :

People prefer the more mnemonic hostname iden�fier, while routers

prefer fixed-length, hierarchically structured IP addresses. In order to
resolve these preferences, we need a directory service that translates
hostnames to IP addresses. This is the main task of the Internet’s
domain name system (DNS).

The DNS is
(1) a distributed database implemented in a hierarchy of DNS servers,
and
(2) an applica�on-layer protocol that allows hosts to query the
distributed database.

DNS is commonly employed by other applica�on-layer protocols—

including HTTP, SMTP, and FTP—to translate user-supplied hostnames
to IP addresses. As an example, consider what happens when a
browser (that is, an HTTP client), running on some user’s host,
requests the URL www.someschool.edu/ index.html. In order for the
 user’s host to be able to send an HTTPrequest message to the Web
server www.someschool.edu, the user’s host must first obtain the
IPaddress of www.someschool.eu. This is done as follows.

1. The same user machine runs the client side of the DNS applica�on.
2. The browser extracts the hostname, www.someschool.edu, from
the URL and passes the hostname to the client side of the DNS
applica�on.
3. The DNS client sends a query containing the hostname to a DNS
server.
4. The DNS client eventually receives a reply, which includes the
IPaddress for the hostname.
5. Once the browser receives the IPaddress from DNS, it can ini�ate a
TCPconnec�on to the HTTPserver process located at port 80 at
that IPaddress.
6. DNS provides a few other important services in addi�on to
transla�ng hostnames to IPaddresses:

• Host aliasing :Ahost with a complicated hostname can have one

or more alias names. For example, a hostname such as
relay1.west-coast.enterprise.com could have, say, two aliases such
as enterprise.com and www.enterprise.com.
• Mail server aliasing. For obvious reasons, it is highly desirable
that e-mail addresses be mnemonic. For example, if Bob has an
account with Hotmail, Bob’s e-mail address might be as simple as
[email protected].
• Load distribu�on. DNS is also used to perform load distribu�on
among replicated servers, such as replicated Web servers. Busy
sites, such as cnn.com, are replicated over mul�ple servers, with
each server running on a different end system and each having a
different IP address.

2) Overview of How DNS Works :

Suppose that some applica�on (such as a Web browser or a mail reader)
running in a user’s host needs to translate a hostname to an IP address.
The applica�on will invoke the client side of DNS, specifying the
hostname that needs to be translated.
(On many UNIX-based machines, gethostbyname() is the func�on call
that an applica�on calls in order to perform the transla�on.) DNS in the
user’s host then takes over, sending a query message into the network.
All DNS query and reply messages are sent within UDP datagrams to port
53. A�er a delay, ranging from milliseconds to seconds, DNS in the user’s
host receives a DNS reply message that provides the desired mapping.
This mapping is then passed to the invoking applica�on. Thus, from the
perspec�ve of the invoking applica�on in the user’s host, DNS is a black
box providing a simple, straigh�orward transla�on service. But in fact,
the black box that implements the service is complex, consis�ng of a
large number of DNS servers distributed around the globe, as well as an
applica�on-layer protocol that specifies how the DNS servers and
querying hosts communicate.
The problems with a centralized design include:
• A single point of failure. If the DNS server crashes, so does the en�re
Internet!
• Traffic volume.Asingle DNS server would have to handle all DNS
queries (for all the HTTP requests and e-mail messages generated from
hundreds of millions of hosts).
• Distant centralized database.Asingle DNS server cannot be ―close to‖
all the querying clients. If we put the single DNS server in New York City,
then all queries from Australia must travel to the other side of the globe,
perhaps over slow and congested links. This can lead to significant
delays.
• Maintenance.The single DNS server would have to keep records for all
Internet hosts. Not only would this centralized database be huge, but it
would have to be updated frequently to account for every new host.

A Distributed, Hierarchical Database :

In order to deal with the issue of scale, the DNS uses a large number of
servers, organized in a hierarchical fashion and distributed around the
world. No single DNS server has all of the mappings for all of the hosts in
the Internet. Instead, the mappings are distributed across the DNS
servers.
To a first approxima�on,
there are three classes of DNS servers—
1.root DNS servers,
2.top-level domain (TLD) DNS servers,
and
3.authorita�ve DNS servers
—organized in a hierarchy as shown in Figure 2.19.
To understand how these three classes of servers interact, suppose a
DNS client wants to determine the IP address for the hostname
www.amazon.com. To a first approxima�on, the following events will
take place. The client first contacts one of the root servers, which returns
IP addresses for TLD servers for the top-level domain com. The client
then contacts one of these TLD servers, which returns the IPaddress of
an authorita�ve server for amazon.com. Finally, the client contacts one
of the authorita�ve servers for amazon.com, which returns the IP
address for the hostname www.amazon.com.

Three classes of DNS servers:

• Root DNS servers. In the Internet there are 13 root DNS servers
(labeled A through M), most of which are located in North America.
• Top-level domain (TLD) servers. These servers are responsible for top-
level domains such as com, org, net, edu, and gov, and all of the country
top-level domains such as uk, fr, ca, and jp.
• Authorita�ve DNS servers. Every organiza�on with publicly accessible
hosts (such as Web servers and mail servers) on the Internet must
provide publicly accessible DNS records that map the names of those
hosts to IPaddresses. An organiza�on’s authorita�ve DNS server houses
these DNS records. An organiza�on canchoose to implement its own
authorita�ve DNS server to hold these records; alterna�vely, the
organiza�on can pay to have these records stored in an authorita�ve
DNS server of some service provider. Most universi�es and large
companies implement and maintain their own primary and secondary
(backup) authorita�ve DNS server.
The root, TLD, and authorita�ve DNS servers all belong to the hierarchy
of DNS servers, as shown in Figure 2.19. There is another important type
of DNS server called the local DNS server. Alocal DNS server does not
strictly belong to the hierarchy of servers but is nevertheless central to
the DNS architecture. Each ISP—such as a university, an academic
department, an employee’s company, or a residen�al ISP—has a local
DNS server (also called a default name server). When a host connects to
an ISP, the ISP provides the host with DNS Caching.
DNS Caching :
DNS caching, a cri�cally important feature of the DNS system. In truth,
DNS extensively exploits DNS caching in order to improve the delay
performance and to reduce the number of DNS messages ricoche�ng
aroundthe Internet. The idea behind DNS caching is very simple. In a
query chain, when a DNS server receives a DNS reply (containing, for
example, a mapping from a hostname to an IPaddress), it can cache the
mapping in its local memory.
DNS Records and Messages :

The DNS servers that together implement the DNS distributed database
store resource records (RRs), including RRs that provide hostname-to-IP
address mappings. Aresource record is a four-tuple that contains the
following fields:
(Name, Value, Type, TTL)
TTL is the �me to live of the resource record; it determines when a
resource should be removed from a cache. In the example records given
below, we ignore the TTL field. The meaning of Name and Value depend
on Type:
• If Type=A, then Name is a hostname and Value is the IP address for the
hostname. Thus, a Type Arecord provides the standard hostname-to-
IPaddress mapping. As an example, (relay1.bar.foo.com, 145.37.93.126,
A) is a Type Arecord.
• If Type=NS, then Name is a domain (such as foo.com) and Value is the
hostname of an authorita�ve DNS server that knows how to obtain the
IP addresses for hosts in the domain. This record is used to route DNS
queries further along inthe query chain. As an example, (foo.com,
dns.foo.com, NS) is a Type NS record
. • If Type=CNAME, then Value is a canonical hostname for the alias
hostname Name. This record can provide querying hosts the canonical
name for a hostname. As an example, (foo.com, relay1.bar.foo.com,
CNAME) is a CNAME record.
• If Type=MX, then Value is the canonical name of a mail server that has
an alias hostname Name. As an example, (foo.com, mail.bar.foo.com,
MX) is an MX record. MX records allow the hostnames of mail servers to
have simple aliases. Note that by using the MX record, a company can
have the same aliased name for its mail server and for one of its other
servers (such as its Web server). To obtain the canonical name for the
mail server, a DNS client would query for an MX record; to obtain the
canonical name for the other server, the DNS client would query for the
CNAME record.
DNS Messages
The seman�cs of the various fields in a DNS message are as follows:

 P2P (Peer To Peer) File Sharing :

In Computer Networking, P2P (Peer-to-Peer) is a file-sharing

technology, that allows users to access mainly the mul�media files
like videos, music, e-books, games, etc. The individual users in this
network are referred to as peers. The peers request files from
other peers by establishing TCP or UDP connec�ons.

How Does P2P (Peer-to-Peer) Work?

A peer-to-peer network allows computer hardware and so�ware

to communicate without the need for a server. Unlike client-server
architecture, there is no central server for processing requests in
a P2P architecture. The peers directly interact with one another
without the requirement of a central server.
 Now, when one peer makes a request, mul�ple peers may have a
copy of that requested object. Now the problem is how to get the
IP addresses of all those peers. This is decided by the underlying
architecture supported by the P2P systems. Using one of these
methods, the client peer can get to know all the peers which have
the requested object/file and the file transfer takes place directly
between these two peers.

P2P Architecture :
1. Centralized Directory
2. Query Flooding
3. Exploi�ng Heterogeneity

1) Centralized Directory

A centralized Directory is somewhat similar to client-server

architecture in the sense that it maintains a huge central server to
provide directory service. All the peers inform this central server
of their IP address and the files they are making available for
sharing. The server queries the peers at regular intervals to make
sure if the peers are s�ll connected or not. So basically this server
maintains a huge database regarding which file is present at which
IP addresses. The first system which made use of this method
was Napster, for Mp3 distribu�on.
Working
• Now whenever a reques�ng peer comes in, it sends its query to the
server.
• Since the server has all the informa�on of its peers, so it returns the IP
addresses of all the peers having the requested file to the peer.
• Now the file transfer takes place between these two peers.

Gnutella: Gnutella represents a new wave of P2P applica�ons providing

distributed discovery and sharing of resources across the Internet.
Gnutella is dis�nguished by its support for anonymity and its
decentralized architecture. A Gnutella network consists of a dynamically
changing set of peers connected using TCP/IP.
The major problem with such an architecture is that there is a single
point of failure. If the server crashes, the whole P2P network crashes.
Also, since all of the processing is to be done by a single server so a huge
amount of the database has to be maintained and regularly updated.

2) Query Flooding

Unlike the centralized approach, this method makes use of distributed

systems. In this, the peers are supposed to be connected to an overlay
network. It means if a connec�on/path exists from one peer to another,
it is a part of this overlay network. In this overlay network, peers are
called nodes, and the connec�on between peers is called an edge
between the nodes, thus resul�ng in a graph-like structure. Gnutella was
the first decentralized peer-to-peer network.

Working

• Now when one peer requests for some file, this request is sent to
all its neighboring nodes i.e. to all nodes connected to this node. If
those nodes don’t have the required file, they pass on the query to
their neighbors and so on. This is called query flooding.
• When the peer with the requested file is found (referred to as
query hit), the query flooding stops and it sends back the file
name and file size to the client, thus following the reverse path.
• If there are mul�ple query hits, the client selects from one of
these peers.

This method also has some disadvantages, the query has to be

sent to all the neighboring peers unless a match is found. This
increases traffic in the network.

3) Exploi�ng Heterogeneity

This P2P architecture makes use of both the above-discussed

systems. It resembles a distributed system like Gnutella
because there is no central server for query processing. But
unlike Gnutella, it does not treat all its peers equally. The peers
with higher bandwidth and network connec�vity are at a
higher priority and are called group leaders/supernodes. The
rest of the peers are assigned to these supernodes. These
supernodes are interconnected and the peers under these
supernodes inform their respec�ve leaders about their
connec�vity, IP address, and the files available for sharing.
KaZaA technology is such an example that makes use of
Napster and Gnutella. Thus, the individual group leaders along
with their child peers form a Napster-like structure. These
 group leaders then interconnect among themselves to
resemble a Gnutella-like structure.

Working

• This structure can process the queries in two ways.

• The first one is that the supernodes could contact other
supernodes and merge their databases with their database. Thus,
this supernode now has informa�on about a large number of
peers.
• Another approach is that when a query comes in, it is forwarded
to the neighboring super nodes un�l a match is found, just like in
Gnutella. Thus query flooding exists but with limited scope as each
supernode has many child peers. Hence, such a system exploits
the heterogeneity of the peers by designa�ng some of them as
group leaders/supernodes and others as their child peers

P2P File Sharing Security Concerns :

Steps that ensure that Sensi�ve Informa�on on the network is secure:
• You must delete your sensi�ve informa�on which you don’t require and
you can apply some restric�ons to important file present within the
network.
• For strong or accessing sensi�ve informa�on, try to reduce or remove
P2P file-sharing programs on computers.
 • Constantly try to monitor the network to find unauthorized file-sharing
programs.
• Try to block the unauthorized Peer-to-Peer file sharing programs within
the perimeter of the network.
• Implement strong access controls and authen�ca�on mechanisms to
prevent unauthorized access to sensi�ve informa�on on the network.
• Use encryp�on techniques such as Secure Socket Layer (SSL) or Transport
Layer Security (TLS) to protect data in transit between peers on the
network.
• Implement firewalls, intrusion detec�on and preven�on systems, and
other security measures to prevent unauthorized access to the network
and to detect and block malicious ac�vity.
• Regularly update so�ware and security patches to address known
vulnerabili�es in P2P file-sharing programs and other so�ware used on
the network.
• Educate users about the risks associated with P2P file-sharing and
provide training on how to use these programs safely and responsibly.
• Use data loss preven�on tools to monitor and prevent the transmission
of sensi�ve data outside of the network.
• Implement network segmenta�on to limit the scope of a security breach
in case of a compromise, and to prevent unauthorized access to sensi�ve
areas of the network.
• Regularly review and audit the network to iden�fy poten�al security
threats and to ensure that security controls are effec�ve and up-to-date.

 Socket Programming with TCP and UDP :

Sockets in computer networks are used for allowing the transmission of
informa�on between two processes of the same machines or different
machines in the network. The socket is the combina�on of IP address and
so�ware port number used for communica�on between mul�ple processes.
Socket helps to recognize the address of the applica�on to which data is to be
sent using the IP address and port number.
What is Socket Programming in Computer Networks?
Sockets allow communica�on of two processes that are running on the same or
different machines. Sockets are the end of two-way communica�on between
two programs that are running on the networks.
• Sockets are mostly used in client-server architecture for communica�on
between mul�ple applica�ons.
• Socket programming tells us how we can use socket API for crea�ng
communica�on between local and remote processes.
• The socket is created by the combina�on of the IP address and port
number of the so�ware. With this combina�on, the process knows the
system address and address of the applica�on where data is to be sent.
• : is used to separate IP address and port number. For
eg: 192.168.1.67:80, 155.2.12.23:77, etc.
Below image to show the socket address example

Which Classes are Used for Connec�on-Less Socket Programming?

Connec�on-oriented service involves connec�on establishment before
transmi�ng the data and connec�on termina�on a�er data transmission.
Connec�on-less service does not require any connec�on establishment and
connec�on termina�on for transmi�ng the data over the network.
 • For connec�on-less socket programming, DatagramSocket and
DatagramPacket classes are used.
• For connec�on-oriented socket programming, Socket and ServerSocket
classes are used.
DatagramSocket class represents a connec�onless socket for transmi�ng
datagram packets.
DatagramPacket is a message transmited between two communica�ng
par�es. DatagramPacket is just like a data container that carries data between
two communica�ng par�es. When mul�ple datagram packets are sent over the
network they may arrive in any order irrespec�ve of their sending order.
1) Socket Programming in TCP :

TCP stands for Transmission Control Protocol. TCP is a reliable

connec�on-oriented protocol of the transport layer. TCP establishes the
connec�on before data transmission. Steps for TCP socket programming
for establishing TCP socket at the client-side:
• The first step is to create a socket and use the socket() func�on to create
a socket.
• Use the connect() func�on for connec�ng the socket to the server
address.
• Transmit data between two communica�ng par�es
using read() and write() func�ons.
• A�er data transmission comple�on close the connec�on
using close() func�on.
Following are steps to be followed for establishing a TCP socket on the
server-side:
• Use socket() for establishing a socket.
• Use the bind() func�on for binding the socket to an address.
• Then for listening client connec�ons use listen() func�on.
• The accept() func�on is used for accep�ng the connec�on of the client.
• Transmit data with the help of the read() and write() func�on.
 Below image to show TCP Socket connec�on

2) Socket Programming in UDP :

UDP stands for User Datagram Protocol. UDP is a connec�on-less and
unreliable protocol of transport layer. UDP does not establish a connec�on
between two communica�ng par�es before transmi�ng the data. Following
are the steps given that are to be followed for establishing UDP socket
connec�on on the client-side
• Use socket() func�on for crea�ng socket;
• recvfrom() and sendto() func�ons are used for transmi�ng data
between two communica�ng par�es.
Steps to be followed for establishing UDP socket connec�on at the server-side.
• Create a socket using the socket() func�on.
• Use the bind() func�on for the binding socket to an address.
• Transmit data with the help of the recvfrom() func�on and sendto().
Below image to show UDP socket connec�on

 Installing and using network monitoring tools

Network monitoring involves using specialized so�ware to analyze data from

computers and other devices in order to iden�fy problems and poten�al
security threats. Network monitoring is a vital part of any business, and it’s
important to know what tools are available. Check out the blog for the tools
used for network monitoring.
What is Network Monitoring?
Network monitoring is the process of collec�ng and analyzing data from a
network to iden�fy poten�al network issues. This can be done by using
so�ware, hardware, or both. It’s important that you have an understanding
of what is network monitoring solu�on does before choosing it.
A network monitoring system should provide visibility into all aspects of your
network infrastructure, including servers, switches, routers, firewalls, wireless
access points, and any devices connected to them. The most common types of
network monitoring solu�ons include packet capture, port mirroring, intrusion
detec�on systems (IDS), and web applica�on firewall (WAF).
How does Network Monitoring Work?
Network monitoring works by analyzing network traffic, including all data sent
from one computer to another. This informa�on is then used to iden�fy
malicious ac�vity such as hacking atempts, spamming, or other illegal
ac�vi�es. The process is similar to how law enforcement agencies use forensic
analysis to inves�gate crimes.
It works by iden�fying suspicious behavior on a network. Passive tools monitor
network traffic passively, while ac�ve tools probe for suspicious ac�vity. Passive
tools include packet sniffers, port scanners, and intrusion detec�on systems.
Ac�ve tools include an�virus so�ware, firewalls, and web proxies.
Why use Network Monitoring Tools?
A network monitoring tool helps you monitor all aspects of your network
infrastructure, such as servers, routers, switches, firewalls, etc. This way, you
can iden�fy any issues that may arise and fix them immediately.
Tools are essen�al to help you manage your network infrastructure. They
provide you with detailed sta�s�cs about your network traffic, including
bandwidth usage, latency, packet loss, etc. These tools also allow you to
analyze and troubleshoot problems quickly.
How do Network Monitoring Tools Work?
Network monitoring tools help you monitor all the ac�vity on your computer
network. They allow you to view who had accessed what files, when they were
accessed, and how long they stayed on the system. This informa�on helps you
iden�fy poten�al security breaches and other issues occurring on your
network.
Network monitoring so�ware allows you to see exactly what happens on your
network, and it also lets you know who is accessing your data and how o�en
they access it. This informa�on can help you determine whether someone is
trying to hack into your network, whether your employees are misusing your
systems, or if someone else is trying to steal your sensi�ve informa�on.
Why do businesses need network monitoring tools?
A large company with thousands of people works with many different
applica�ons. All of these applica�ons need to be monitored, users must know
how to use their applica�ons properly. Network monitoring tools are designed
to be used by network administrators, it will allow them to monitor the status
and health of an en�re network. This is done by bringing together informa�on
about every device connected to the network.
Network monitoring tools are o�en used to troubleshoot problems. They help
network administrators find out what is happening on the network. They also
give users insight into the network’s state, which allows them to make
informed decisions about whether or not to connect to the network.
What kind of Network Monitoring Tools Should I use?
Network monitoring tools are so�ware applica�ons designed to monitor and
analyze network traffic. They provide informa�on such as bandwidth usage,
packet size, protocol type, etc. Network monitoring tools can also be used to
iden�fy poten�al security threats or other problems within a network.
There are several types of network monitoring tools. Some are free, and some
are paid. The best network monitoring tool depends on your requirements. If
you want to monitor many devices, you might consider using a cloud-based
solu�on. If you want to monitor only a single device, you can opt for a local
applica�on.
Best Network Monitoring Tools?
Below are some of the Best Network Monitoring Tools:
Network bandwidth analyzer:
The network bandwidth analyzer tool helps you monitor and analyze your
network traffic. This so�ware allows you to view all the data about your
internet connec�on, such as how much data you use each month, what
websites you visit, and how long it takes for them to load.
Network bandwidth analyzers allow you to see exactly how much data you are
using and where it is going. They also help you iden�fy botlenecks in your
network to make changes to improve performance. Network bandwidth
analyzers can even tell you when something goes wrong with your internet
service provider (ISP).
Auvik:
Auvik is a free so�ware for Windows and Mac OS X which allows you to
monitor your computer remotely. This means that you can check whether your
computer is infected with viruses, spyware, adware, etc. Auvik also lets you see
what applica�ons run on your computer and how much memory they use.
Auvik is a free applica�on designed by the company Avast. It is available as a
download from the official website. Once installed, you can start using it
immediately. Simply click on the “Install” buton on the main screen to install it.
A�er installa�on, you need to restart your computer. Then, go to the program
menu and select “Auvik Remote Control”. From here, you can access all the
features of the applica�on.
Site24x7:
Site24x7 is a web applica�on that monitors websites for up�me, performance,
security, and availability. The so�ware allows users to monitor mul�ple sites
from one dashboard, and this means that you don’t need to log in to each site
separately. Site24x7 also provides alerts when something goes wrong.
Obkio:
The Obkio Network Monitoring Tool is a so�ware for Windows that allows you
to monitor all the devices connected to your home network. This program has
been designed to help you keep track of what is happening on your computer
network.
Paessler PRTG:
Paessler PRTG Network Monitoring for monitoring networks and servers. The
program allows users to monitor up to 100 devices simultaneously and view
graphs, charts, and sta�s�cs about the monitored device. The applica�on also
includes alerts, remote control, and a web interface.
The tool provides real-�me data about network performance and enables
administrators to troubleshoot problems remotely. It can be used by IT staff to
check the status of servers, routers, firewalls, switches, and more. Users can
also set up alerts so that the administrator receives an email no�fica�on when
a problem occurs.
Datadog:
Datadog is a free service for monitoring applica�ons, servers, networks, and
infrastructure. The company offers a free trial plan for up to 10 metrics per
applica�on and a paid plan star�ng at $23/month for unlimited metrics.
Datadog has built its business by offering services to help developers monitor
their so�ware. It provides tools to help them understand what’s going on with
their code, including metrics about performance, errors, and up�me. It also
offers features to help them deploy new versions of their apps more quickly
and track changes made to those apps over �me. The company says it has
more than 1 million customers using its products.

1) Installing Network Monitoring Tools :

Here are some steps you can take to install and use network monitoring tools:
1. Choose a tool: There are many network monitoring tools available,
including open-source tools, tools with graphical interfaces, and tools
that can monitor network traffic:
o Nagios: An open-source tool that helps DevOps teams monitor
networks and infrastructure, and maintain records of events and
failures
o Paessler PRTG Network Monitor: A tool with a simple interface
that provides informa�on about network traffic and is easy for
inexperienced users to use
o SolarWinds: A well-known tool that automa�cally maps networks
and nodes, and has a graphical interface that shows network
topology and status
 o Zabbix: An open-source tool that can be scaled from small
businesses to large enterprises, and is available as a so�ware or
virtual appliance download
o DataDog: A tool that installs an agent to enable network discovery
and monitoring, and supports features like network mapping,
resource u�liza�on monitoring, aler�ng, and log management
o ManageEngine OpManager: A tool that focuses on infrastructure
management, but also offers network monitoring and applica�on
performance management features
o WhatsUp Gold: A user-friendly tool that combines infrastructure
management, applica�on performance management, and network
monitoring, and offers customizable pricing packages
o Auvik: A tool that helps small businesses map and monitor
network health and performance, and uses a centralized
dashboard to provide real-�me visibility
o Icinga: An open-source tool that allows network administrators to
monitor infrastructure of all sizes, and checks hosts and services to
no�fy users of their status
2. Install the tool
3. Discover and add devices
4. Configure the monitoring se�ngs
5. Test and verify the monitoring
6. Maintain and update the tool

2) Using Network Monitoring Tool :

Using the tool:

1. Launch the tool: Start the network monitoring tool and log in to
the dashboard.
2. Discover devices: Allow the tool to automa�cally discover
devices on your network or manually add them.
3. Set up monitoring: Configure the tool to monitor specific
devices, services, or applica�ons.
4. Set thresholds and alerts: Define thresholds for performance
metrics and set up alerts for poten�al issues.
 5. Monitor network performance: View real-�me data on network
performance, including bandwidth usage, latency, and packet loss.
6. Troubleshoot issues: Use the tool to iden�fy and troubleshoot
network problems, such as connec�vity issues or device failures.
7. Generate reports: Create customized reports to analyze network
performance, usage trends, and security threats.
8. Customize the dashboard: Tailor the dashboard to display
relevant data and metrics for your network.
9. Integrate with other tools: Integrate the network monitoring
tool with other tools, such as helpdesk so�ware or security
informa�on and event management (SIEM) systems.
10. Regularly update and maintain: Regularly update the tool and
maintain your network monitoring configura�on to ensure op�mal
performance.

Conclusion:
Network monitoring tools are so�ware programs that let you see exactly what
your network is doing at any given �me. They provide detailed informa�on
about your connec�on speed, packet size, and latency.
Network monitoring tools are essen�al when you want to make sure your
website is working correctly. If something goes wrong with your website, you
need to find out as soon as possible so you can fix it. A good network
monitoring tool lets you monitor mul�ple websites at once and provides real-
�me data about each site, and it also allows you to view all of the sites on your
network from one place.