Module 1

Vidya Vardhaka College of Engineering, Mysuru
Department of Computer Science & Engineering
Computer Networks (15CS52)
Module-1:Application Layer
Gururaj H L
Assistant Professor,
Dept. of CSE, VVCE, Mysuru
gururaj1711@vvce.ac.in
gururajhl.blogspot.com

Contents
1. Principles of network applications
2. Web and HTTP
3. FTP
4. Electronic mail
• SMTP, POP3, IMAP
5. DNS
6. P2P applications
7. Socket programming with UDP and TCP
30-07-2018 Dept. of CSE, VVCE, Mysuru 2

1. Principles of Network Applications
In web application, there are two distinct programs that communicate
with one another.
• Browser program running in the user’s host (desktop, laptop,
tablet, smartphone, and so on).
• Web server program running in the Web server host.

Figure 1: Communication for a network application takes place between end system of an application layer

1.1Network Application Architectures
An application developer should likely to know two basic architectures before developing
the software for network application.
• Client Server Architecture
• Peer to Peer architecture
An interaction between client and service machine takes place, where client always sends
the request to the server using the server IP address. The server may get request all the
time henceforth, the server machine should always kept open (Web, FTP, Telnet, and e-
mail).
It is a centralised system, therefore providing security is easy
Due to flood of requests many a times server cant able to reply all the clients so data
center plays a virtual role of a server.
• search engines (e.g., Google and Bing),
• Internet commerce (e.g., Amazon and e-Bay),
• Web-based email (e.g., Gmail and Yahoo Mail),
• social networking (e.g., Facebook and Twitter)

In P2P architecture has self-scalability.
P2P is a decentralised system. Secure concern is a pitfall.
Three major challenges: ISP Friendly, Security, Incentives
• File sharing (e.g., Bit Torrent)
• Internet Telephony (e.g., Skype)
Figure 2: Amazon Data center Figure 3: Google Data center30-07-2018 Dept. of CSE, VVCE, Mysuru 6

Figure 4: Client Server Architecture Figure 5: Peer to Peer Architecture

1.2 Processes Communicating
SEND and RECEIVE Messages.
• In the context of a communication session between a pair of processes,
the process that initiates the communication (that is, initially contacts
the other process at the beginning of the session) is labeled as the
client.
• The process that waits to be contacted to begin the session is the
server.
Client and Server Processes

The Interface Between the Process and the Computer
Network
• A process sends messages into, and receives messages from, the
network through a software interface called a socket.
• Provides an interface between the application layer and transport layer
called Application Programming Interface (API).
Figure 6: Application processes, sockets, and underlying transport protocol

Addressing Processes
To identify the receiving process, two pieces of information need to be
specified:
• The address of the host –IPAddress (IPv4, IPv6)
• An identifier that specifies the receiving process in the destination
host. –Port Number of destination. (Port number of web server is 80
and Mail server is 25)

1.3 Transport Services Available to Applications
Services provided by transport layer in four dimensions:
• Reliable data transfer
• Throughput
Bandwidth-sensitive Applications
Elastic Applications
• Timing
Lower delays
End to End delays
• Security.
Confidentiality
Data integrity
End-point authentication,

Transport Services Provided by the Internet
Table 1. Requirements of selected network applications

TCP Services
• Connection-oriented service
Handshake protocol
• Reliable data transfer service (Guarantee of Service (GoS))
UDP Services
• Connection- less service
No Handshake protocol
• No GoS
The detailed functionalities of TCP and UDP will be portrayed in Module-2

Services Not Provided by Internet Transport Protocols
Table 2. Popular Internet applications, their application-layer and their underlying transport protocols

Application-Layer Protocols
Basically application layer protocol defines
• The types of messages exchanged between the end users request
messages and response messages
• The syntax of the various message types and indication of each fields.
• The semantics and information of the fields
• Rules for determining the messages

RFC (Request for Comment)
A Request for Comments (RFC) is a type of publication from
the Internet Engineering Task Force (IETF) and the Internet
Society (ISOC), the principal technical development and standards-
setting bodies for the Internet.
A Request for Comments (RFC) is a formal document from the Internet
Engineering Task Force (IETF) that is the result of committee drafting
and subsequent review by interested parties.
RFC 791 - Internet Protocol
RFC 2616 - Hypertext Transfer Protocol
RFC 793-TCP

2 The Web and HTTP
• In early 1990 the internet has been evolved.
2.1 Overview of HTTP
• A web page also called document is a collection of objects.
• HTTP is implemented in two programs: a client program and a server
program.
• URL
• Web Browser
• Web Server

URL
The hostname of the server that houses the object and the object’s path name:
• A scheme
HTTP (without SSL) or HTTPS (with SSL).
• A host
www.example.com
• A path
/software/cics/index.html
• A query string
If a query string is specified, it is preceded by a question mark
Path?query
Example:
http://www.example.com/software/index.html
http://www.example.com:1013/software/index.html

HTTP
HTTP is called sometimes as stateless protocol
Figure 7. HTTP Request Response Behavior

Non-Persistent and Persistent Connections
Non-persistent Persistent
Default for HTTP/1.0 Default for HTTP/1.1
Server parses requests, responds, and
closes TCP connection
On same TCP connection: server,
parses request, responds, and also
parses new requests.
2 RTTs to fetch each object Client sends requests for all referenced
objects as soon as it receives base
HTML.
Each object transfer suffers from slow
start.
Fewer RTTs and less slow start.
Table 3. Persistent and Non Persistent HTTP

Figure 8. RTT in HTTP Request Response Behavior

HTTP Message Format
There are two types of HTTP messages
• Request message
• Response message
Request message
GET /somedir/page.html HTTP/1.1 Request Line
Host: www.someschool.ed
Connection: close Header Lines
User-agent: Mozilla/5.0
Accept-language: fr

The request line consists of three fields
• method field
• URL field
• HTTP version field.
The method field can take
• GET
• POST
• HEAD
• PUT and DELETE values
GET /index.html HTTP/1.1rn

HTTP Request Message
Figure 9. General format of an HTTP request message

HTTP Response Message
HTTP/1.1 200 OK status line
Connection: close
Date: Thur, 10 Aug 2017 15:44:04 GMT header lines
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 09 Aug 2011 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html
(data data data data data ...) entity body

HTTP Response Message
Figure 10. General format of an HTTP response message

Status Code
Status code Meaning
200 OK Request succeeded, requested object later in this
message
301 Moved Permanently Requested object moved, new location specified later
in this message (Location:)
400 Bad Request Request message not understood by server
404 Not Found Requested document not found on this server
505 HTTP Version Not Supported Version Not Supported
Table 4. Status codes of HTTP

User-Server Interaction: Cookies
• As HTTP server is stateless to increase the performance of a server
cookies were introduced
• Cookies - RFC 6265
• 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
(4) a back-end database at the Web site
Example: Set-cookie: 1678

Figure 11. Keeping user state with cookies

Uses of Cookies
•authorization
•shopping carts
•recommendations
•user session state (Web e-mail)

Web Caching
• The main goal is to satisfy client request without involving origin
server
• The Web cache has its own disk storage and keeps copies of recently
requested objects in this storage
Figure 12. Web cache

• Cache acts as both client and server
• Typically cache is installed by ISP (university, company etc ..)
Uses of Web caching
• Reduce response time for client request
• Reduce traffic on an institution’s access link
• Internet dense with caches: enables “poor” content providers to
effectively deliver content.

The Conditional GET
• HTTP has a mechanism that allows a cache to verify that its objects
are up to date. This mechanism is called the conditional GET
• Note that the value of the If-modified-since: header line is exactly
equal to the value of the Last-Modified: header line that was sent by
the server one week ago.
• The conditional GET is telling the server to send the object only if the
object has been modified since the specified date.

3. File Transfer: FTP
FTP transfers file to/from remote host. It follows the basic principles of
client/server model
• FTP: RFC 959 and server port: 21
• HTTP and FTP are both file transfer protocols and have many
common characteristics.
• They both run on top of TCP.

Figure 13. FTP local and remote files Figure 14. FTP connections

• FTP client contacts FTP server at port 21, using TCP
• Client authorized over control connection
• Client browses remote directory, sends commands over control
connection.
• When server receives file transfer command, server opens 2nd TCP
data connection (for file) to client.
• After transferring one file, server closes data connection.
• Server opens another TCP data connection to transfer another file
• Control connection: “out of band”
• FTP server maintains “state”: current directory, earlier authentication.

FTP Commands
Commands Meaning
USER username
PASS password
LIST return list of file in current directory
RETR filename retrieves (gets) file
STOR filename stores (puts) file onto remote host
Table 5. Commands of FTP

Return codes
Status
code
Meaning
331 Username OK, password required
125 data connection already open; transfer starting
425 Can’t open data connection
452 Error writing file
Table 6. Status codes of FTP

4. Electronic Mail
Three major components
• User agents
• Mail servers
• Simple Mail Transfer Protocol: SMTP

Figure 15. Email System

SMTP [RFC 2821]
• Uses TCP to reliably transfer email message from client to server, port 25
• Direct transfer: sending server to receiving server
• Three phases of transfer
• Handshaking (greeting)
• Transfer of messages
• Closure
• Command/response interaction (like HTTP, FTP)
• commands: ASCII text
• response: status code and phrase
• Messages must be in 7-bit ASCII (simple messages )

Scenario: Alice sends message to Bob
Figure 16. Scenario

Scenario: Alice sends message to Bob
• Alice uses UA to compose message “to” bob@someschool.edu
• Alice’s UA sends message to her mail server; message placed in
message queue
• Client side of SMTP opens TCP connection with Bob’s mail server
• SMTP client sends Alice’s message over the TCP connection
• Bob’s mail server places the message in Bob’s mailbox
• Bob invokes his user agent to read message

Alice sends message to Bob
Figure 17. Scenario

SMTP Interaction
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <alice@crepes.fr>
S: 250 alice@crepes.fr... Sender ok
C: RCPT TO: <bob@hamburger.edu>
S: 250 bob@hamburger.edu ... 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 connection

SMTP Interaction Illustration
• Telnet server name 25
• See 220 reply from server
• Enter HELO, MAIL FROM, RCPT TO, DATA, QUIT commands

Comparison with HTTP
SMTP HTTP
SMTP uses persistent connections
SMTP: push
HTTP: pull
SMTP requires message (header & body) to be
in 7-bit ASCII. Hence it is Simple protocol.
Both have ASCII command/response interaction,
status codes
SMTP server uses CRLF.CRLF to determine end
of message
Various status code
HTTP: each object encapsulated in its own
response msg
SMTP: multiple objects sent in multipart msg

SMTP Message format
header lines, e.g.,
To:
From:
Subject:
Body: the “message”
ASCII characters only

Mail Access Protocols
Widely supported Mail Access protocols are:
• Post Office Protocol (POP3)
• Internet Mail Access Protocol (IMAP4)
Post Office Protocol (POP3)
• The client POP3 is installed on the recipient machine and the server
POP3 software installed on mail server.
• The client opens a connection with the server on TCP port number
110.
• Sends username and password.
• Can access the mails, one by one.

Two modes
• Delete mode- mails deleted as they are read
• Keep mode- mails remain in the mailbox
POP3 has commands for
• Log in
• Log out
• Fetch messages
• Delete messages

IMAP4 Features
• A user can check the email header before downloading
• A user can search the contents of the email for a specific string prior to
downloading
• A user can create, delete or rename mailboxes on the mail server
• A user can create a hierarchy of mailboxes in a folder for email
storage.

Purpose of MIME
SMTP can’t transmit non text messages. SO MIME protocol came
into existence.
MIME is not a program that runs on the server, rather than it’s acts as a
translator which sits on the top of SMTP and converts non text mail to
equivalent text mail along with relevant information.

Domain Name Server
• The global database system for internet addressing, mail and other
information
• Much easier to use and memorize
Concepts of Domains and sub domains
• Domain management is distributed
• DNS Servers translate domain names to IP addresses.

Top Level Domains

Domain Name structure
• Domain names are arranged in a hierarchical tree like structure

Statistical Information

Name Resolution Process
• The commonly used server is BIND (Berkley internal domain name)
Runs under UNIX as a process called named.
• When an application needs some information from the server, it invokes the
DNS name resolver.
• DNS translates fully qualified domain name into corresponding IP address
Using the command nslookup table.

• If the name server does not have the information locally, it asks its
primary server and so on.
• For redundancy, each host may also have one or more secondary name
servers which may be queried when the primary fails.
Figure . Hierarchy of Name Servers

Recursive Name Resolution

DNS Caching
• Once name server learns mapping, it caches mapping
Cache entries timeout (disappear) after some time (TTL)
DNS Records
• DNS: distributed db storing resource records (RR)
DNS Record
RR format: (name, value, type, ttl)
type=A
 name is hostname
 value is IP address
type=A
 name is hostname
 value is IP address

DNS Protocol Message Format
DNS protocol has query and reply messages, both with same message
format

Attacking DNS
DDoS attacks
• Bombard root servers with traffic
• Not successful to date
• Traffic Filtering
• Local DNS servers cache IPs of TLD servers, allowing root server bypass
• Bombard TLD servers
• Potentially more dangerous
Redirect attacks
• Man-in-middle
• Intercept queries
• DNS poisoning
• Send bogus relies to DNS server, which caches
Exploit DNS for DDoS
• Send queries with spoofed source address: target IP
• Requires amplification

Peer-to-Peer Applications
• P2P File Distribution
Scalability of P2P Architecture
Server:
Time to send one copy: F/us
Time to send N copies: NF/usdmin = min
Client:
Client download rate
Min client download time: F/dmin

Peer to Peer file Distribution
server transmission: must upload at least one
copy
time to send one copy: F/us
client: each client must download file copy
min client download time: F/dmin
clients: as aggregate must download NF bits
max upload rate (limiting max download rate) is us + Sui

Bit Torrent
• File divided into 256Kb chunks
• Peers in torrent send/receive file chunks

• peer joining torrent:
• Has no chunks, but will accumulate them over time from other
peers
• Registers with tracker to get list of peers, connects to subset of
peers (“neighbors”)
• While downloading, peer uploads chunks to other peers
• Peer may change peers with whom it exchanges chunks
• Churn: peers may come and go
• Once peer has entire file, it may (selfishly) leave or (altruistically)
remain in torrent
• Bit Torrent: tit-for-tat

Distributed Hash Tables(DHTs)
• Centralized version of simple database, will simply contain (key,
value) pairs.
• For example, the keys could be social security numbers and the values
could be the corresponding human names; (156-45-7081, Johnny Wu)
Or the keys could be content names (e.g., names of movies, albums,
software), and the value could be the IP address at which the content
is stored; (Zeppelin IV, 128.17.123.38).
• If the database stores content names and their corresponding IP
addresses, we can query with a specific content name, and the
database returns the IP addresses that store the specific content.
• Building such a database is straightforward with a client-server
architecture that stores all the (key, value) pairs in one central server.

• P2P version of this database that will store the (key, value) pairs over
millions of peers.
• In the P2P system, each peer will only hold a small subset of the
totality of the (key, value) pairs. We’ll allow any peer to query the
distributed database with a particular key.
• The distributed database will then locate the peers that have the
corresponding (key, value) pairs and return the key-value pairs to the
querying peer.
• Any peer will also be allowed to insert new key-value pairs into the
database. Such a distributed database is referred to as a distributed
hash table (DHT).

• In this design, the querying peer sends its query to all other peers, and
the peers containing the (key, value) pairs that match the key can
respond with their matching pairs.
• Such an approach is completely unscalable, of course, as it would
require each peer to not only know about all other peers (possibly
millions of such peers!) but even worse, have each query sent to all
peers.
• To address this problem of scale, let’s now consider organizing the
peers into a circle. In this circular arrangement, each peer only keeps
track of its immediate successor and immediate predecessor (modulo
2^n)

Figure.a Circular DHT Figure.b Circular DHT with shortcuts

• Each peer is only aware of its immediate successor and predecessor; for example,
peer 5 knows the IP address and identifier for peers 8 and 4 but does not
necessarily know anything about any other peers that may be in the DHT.
• This circular arrangement of the peers is a special case of an overlay network.
• From Figure.a now suppose that peer 3 wants to determine which peer in the DHT
is responsible for key 11. Using the circular overlay, the origin peer (peer 3)
creates a message saying “Who is responsible for key 11?” and sends this message
clockwise around the circle.
• So, for example, when peer 4 receives the message asking about key 11, it
determines that it is not responsible for the key (because its successor is closer to
the key), so it just passes the message along to peer 5. This process continues until
the message arrives at peer 12, who determines that it is the closest peer to key 11.
• At this point, peer 12 can send a message back to the querying peer, peer 3,
indicating that it is responsible for key 11.

• But this solution introduces yet a new problem. Although each peer is only
aware of two neighboring peers, to find the node responsible for a key (in
the worst case), all N nodes in the DHT will have to forward a message
around the circle; N/2 messages are sent on average.
• This is overcome by adding “shortcuts” so that each peer not only keeps
track of its immediate successor and predecessor, but also of a relatively
small number of shortcut peers scattered about the circle. An example of
such a circular DHT with some shortcuts is shown in Figure .b.
• when a peer receives a message that is querying for a key, it forwards
the message to the neighbor (successor neighbor or one of the shortcut
neighbors) which is the closest to the key.
• Example: When peer 4 receives the message asking about key 11, it
determines that the closest peer to the key (among its neighbors) is its
shortcut neighbor 10 and then forwards the message directly to peer 10.
Clearly, shortcuts can significantly reduce the number of messages used to
process a query.

Peer Churn
• In P2P systems, the peers are not owned by any service providers but the users will be the
actual masters.
• Here, a peer can arrive or vanish from the system without any warning /prior notice.
• Thus while designing a Distributed Hash Table, one must also be concerned about the
maintenance of the DHT overlay in the presence of such peer churns.
• To explain this better, consider a circular DHT(Figure .a):
• Now, to handle the peer churn, we will require each peer to track (i. e, to know the IP
add.)its first and second successors.
• Also each peer must periodically verify that both of its successors are alive.(i. e, by sending
ping messages to them and asking for the response).

• Lets consider a situation where in a peer(say 5) leaves abruptly. Now the two peers preceding
the departed peer(4 and 3) will update their successor state info in this way:
• Peer 4 replaces its first successor with its second one(peer 8). Then peer 4 asks the peer 8 to
return the identifier and IP address. of its immediate successor(peer 10) and considers peer 10
as its second successor. Now consider a situation where in a peer wants to join a DHT(say 13)
and during the time of joining it only knows about the existence of peer1.
• Peer 13 sends a message to peer1 saying “what will be the predecessor and successor of
peer13?” and this will be forwarded throughout the DHT until it reaches the peer12 and it
responds back to the peer13 saying peer 12 will be its predecessor and peer15 will be its
successor.
• Now peer13 joins the DHT by making peer15 as its successor and notifying peer12 to change
its immediate successor as peer13.
• For example: By querying the DHT with a torrent identifier, a newly arriving Bit torrent peer
can determine the peer responsible for the identifier.
• Here the key will be the Torrent identifier and value will be the IP address. So, after finding
that peer, the arriving peer can query it for the list of other peer in the torrent.

REFERENCES
Text Book:
[1]James F kurose, Keith W Ross “Computer Networking -A
top down approach” Sixth Edition, Pearson publication, 2017
[2] NPTEL videos on Computer Networks.

THANK YOU

Module 1

More Related Content

What's hot (20)

Similar to Module 1 (20)

Recently uploaded (20)

Module 1