Topic Two: Application Layer

Overview
 Principles of network applications
 Web and HTTP
 E-mail, SMTP, IMAP
 The Domain Name System DNS
 P2P applications
 video streaming and content distribution networks
 socket programming with UDP and TCP

Our goals and objectives

 Conceptual and implementation aspects of application-layer protocols
• transport-layer service models
• client-server paradigm
• peer-to-peer paradigm
 Learn about protocols by examining popular application-layer protocols and
infrastructure
• HTTP
• SMTP, IMAP
• DNS
• video streaming systems, CDNs
 programming network applications
• socket API

Course Contents

Application Layer:
The application layer enables the user, whether human or software, to access the network. It
provides user interfaces and support for services such as electronic mail, remote file access and
transfer, shared database management, and other types of distributed information services.
Specific services provided by the application layer include the following:
i) Network virtual terminal: A network virtual terminal is a software version of a physical
terminal, and it allows a user to log on to a remote host. To do so, the application creates
a software emulation of a terminal at the remote host. The user's computer talks to the
software terminal which, in turn, talks to the host, and vice versa. The remote host
believes it is communicating with one of its own terminals and allows the user to log on.
ii) File transfer, access and management: This application allows a user to access files in
a remote host (to make changes or read data), to retrieve files from a remote computer for
use in the local computer, and to manage or control files in a remote computer locally.
iii) Mail services: This application provides the basis for e-mail forwarding and storage.
Directory services. This application provides distributed database sources and access for
global information about various objects and services.

1
Some network application that utilizes application Layer
 Social Networking
 Web
 Text Messaging
 E-Mail
 Multi-User Network Games
 Streaming Stored Video (Youtube, Hulu, Netflix)
 P2p File Sharing
 Voice Over Ip (E.G., Skype)
 Real-Time Video Conferencing (E.G., Zoom)
 Internet Search
 Remote Login

Creating a Network Application

Write programs that:
 run on (different) end systems
 communicate over network
 e.g., web server software communicates with browser software
No need to write software for network-core devices
 network-core devices do not run user applications
 applications on end systems allows for rapid app development, propagation

Figure: Network application

2
Client-server paradigm
Server:
 Always-on host
 Permanent IP address
 Often in data centers, for scaling
Clients:
 Contact, communicate with server
 May be intermittently connected
 May have dynamic IP addresses
 Do not communicate directly with each other
 Examples: HTTP, IMAP, FTP

Figure: Network application

Peer-peer architecture
 no always-on server
 arbitrary end systems directly communicate
 peers request service from other peers, provide service in return to other peers
• self-scalability – new peers bring new service capacity, as well as new service
demands
 peers are intermittently connected and change IP addresses
• complex management
Example: P2P file sharing

3
Figure: Peer-peer architecture

Processes communicating
Process: program running within a host
 within same host, two processes communicate using inter-process communication
(defined by OS)
 processes in different hosts communicate by exchanging messages
Main functions of end systems
 client process: process that initiates communication
 server process: process that waits to be contacted
Note: applications with P2P architectures have client processes & server processes

Sockets
 process sends/receives messages to/from its socket
 socket analogous to door
• sending process shoves message out door
• sending process relies on transport infrastructure on other side of door to deliver
message to socket at receiving process
• two sockets involved: one on each side

Figure: socket abstraction between client transport layers

Addressing processes
To receive messages, process must have identifier. Host device has unique 32-bit IP address.
Identifier includes both IP address and port numbers associated with process on host. example
port numbers:
 HTTP server: 80
 mail server: 25
To send HTTP message to [Link] web server we require
 IP address: [Link]
 port number: 80

4
 Question: Does IP address of host on which process runs suffice for identifying the process?
Answer: no, many processes can be running on same host

An application-layer protocol defines:

i) types of messages exchanged,
• e.g., request, response
ii) message syntax:
• what fields in messages & how fields are delineated
iii) message semantics
• meaning of information in fields
iv) Rules for when and how processes send & respond to messages

Categories of application layer protocols

1. Open protocols:
 Defined in RFCs, everyone has access to protocol definition
 allows for interoperability
 e.g., HTTP, SMTP
2. Proprietary protocols: e.g., Skype, Zoom

What transport service does an application need?

1. Data integrity: some apps (e.g., file transfer, web transactions) require 100% reliable
data transfer and other apps (e.g., audio) can tolerate some loss
2. Throughput: some apps (e.g., multimedia) require minimum amount of throughput to be
“effective” and other apps (“elastic apps”) make use of whatever throughput they get
3. Timing: some apps (e.g., Internet telephony, interactive games) require low delay to be
“effective”
4. Security: To provide and implement encryption data integrity, confidentiality and
privacy
Transport service requirements: common application for application layer

5
Internet transport protocols services on application layer
TCP service:
 Reliable Transport between sending and receiving process
 Flow Control: sender won‟t overwhelm receiver
 Congestion Control: throttle sender when network overloaded
 Connection-Oriented: setup required between client and server processes
 Does not provide: timing, minimum throughput guarantee, security
UDP service:
 Unreliable Data Transfer between sending and receiving process
 Does not provide: reliability, flow control, congestion control, timing, throughput
guarantee, security, or connection setup.

Internet applications and transport protocols

Securing TCP
TCP & UDP sockets: are not encrypted and clear text passwords sent into socket traverse
Internet in clear text.
Transport Layer Security (TLS) protocol provides encrypted TCP connections, data integrity
and end-point authentication. TLS implemented in application layer applications use TLS
libraries, that use TCP in turn and clear text sent into “socket” traverse Internet encrypted.

Web and HTTP

Web page consists of objects, each of which can be stored on different Web servers. Object can
be HTML file, JPEG image, Java applet, audio file. Web page consists of base HTML-file which
includes several referenced objects, each addressable by a URL, e.g.,

HTTP overview
HTTP: hypertext transfer protocol. Web‟s application-layer protocol for client/server model:
Client browser requests, receives, (using HTTP protocol) and “displays” Web objects and Web
server sends (using HTTP protocol) objects in response to requests from clients

6
HTTP uses TCP where
Client initiates TCP connection (creates socket) to server, port 80 and server accepts TCP
connection from client. HTTP messages (application-layer protocol messages) exchanged
between browser (HTTP client) and Web server (HTTP server) and TCP connection closed.
HTTP is “stateless” where server maintains no information about past client requests

HTTP connections: two types

a.) Non-persistent HTTP implements
i) TCP connection opened
ii) at most one object sent over TCP connection
iii) TCP connection closed
For example to download multiple objects required multiple connections

b.) Persistent HTTP implements

i) TCP connection opened to a server
ii) multiple objects can be sent over single TCP connection between client, and that
server
iii) TCP connection closed

7
Non-persistent HTTP: response time
Round Trip Time (RTT) (definition): time for a small packet to travel from client to server and
back
HTTP response time (per object):
a.) one RTT to initiate TCP connection
b.) one RTT for HTTP request and first few bytes of HTTP response to return
c.) object/file transmission time
Example

Non-persistent HTTP response time = 2RTT+ file transmission time

Non-persistent HTTP disadvantages

a.) Requires 2 RTTs per object
b.) OS overhead for each TCP connection
c.) Browsers often open multiple parallel TCP connections to fetch referenced objects in
parallel

Persistent HTTP (HTTP 1.1)

Server leaves connection open after sending response and subsequent HTTP messages between
same client/server sent over open connection. Client sends requests as soon as it encounters a
referenced object as little as one RTT for all the referenced objects (cutting response time in half)

HTTP request message

There are two types of HTTP messages that includes request and response messages.
 HTTP request message:

8
 • ASCII (human-readable format)
Sample request head Carriage return
Request line (GET, POST, character
Line-feed character
HEAD commands)

Carriage return, line feed at start of line

indicates end of header lines

HTTP format structure

Other HTTP request messages

POST method:
 Web page often includes form input
 User input sent from client to server in entity body of HTTP POST request message
HEAD method:
 Requests headers (only) that would be returned if specified URL were requested with an
HTTP GET method.
GET method (for sending data to server):
 Include user data in URL field of HTTP GET request message (following a „?‟):
PUT method:
 Uploads new file (object) to server
 Completely replaces file that exists at specified URL with content in entity body of POST
HTTP request message
HTTP response status codes
Status code appears in 1st line in server-to-client response message. Some sample codes
displayed
 200 OK: request succeeded, requested object later in this message
 301 Moved Permanently: requested object moved, new location specified later in this
message (in Location: field)

9
  400 Bad Request: Request msg not understood by server
 404 Not Found: Requested document not found on this server
 505 HTTP Version Not Supported

Maintaining user/server state: cookies

Web sites and client browser use cookies to maintain some state between transactions
four components:
1. Cookie header line of HTTP response message
2. Cookie header line in next HTTP request message
3. Cookie file kept on user‟s host, managed by user‟s browser
4. Back-end database at Web site

Example:
Susan uses browser on laptop, visits specific e-commerce site for first time. When initial HTTP
requests arrives at site, site creates: unique ID (aka “cookie”) and entry in backend database for
ID. Subsequent HTTP requests from Susan to this site will contain cookie ID value, allowing site
to “identify” Susan.
Cookies can be used to track user behavior on a given website (first party cookies) and track user
behavior across multiple websites (third party cookies) without user ever choosing to visit
tracker site (!)

Web caches
Goal: satisfy client requests without involving origin server
User configures browser to point to a (local) Web cache browser sends all HTTP requests to
cache. If object in cache returns object to client and cache requests object from origin server,
caches received object, then returns object to client.

Web caches as proxy servers

Web cache acts as both client and server where the server for original requesting client
and client to origin server. The server tells cache about object‟s allowable caching in response
header:
Why Web caching
1. Reduce response time for client request since cache is closer to client

10
 2. Reduce traffic on an institution‟s access link
3. Internet is dense with caches enables “poor” content providers to more effectively
deliver content

HTTP/2
Key goal: decreased delay in multi-object HTTP requests
HTTP1.1: Introduced multiple, pipelined GETs over single TCP connection
 Server responds in-order (FCFS: first-come-first-served scheduling) to GET requests
 With FCFS, small object may have to wait for transmission (head-of-line (HOL)
blocking) behind large object(s)
 loss recovery (retransmitting lost TCP segments) stalls object transmission
HTTTP 1.2 or HTTP/2: Increased flexibility at server in sending objects to client:
 Methods, status codes, most header fields unchanged from HTTP 1.1
 Transmission order of requested objects based on client-specified object priority (not
necessarily FCFS)
 push unrequested objects to client
 Divide objects into frames, schedule frames to mitigate HOL blocking

HTTP/2: mitigating HOL blocking

HTTP 1.1: client requests 1 large object (e.g., video file) and 3 smaller objects

HTTP/2: objects divided into frames, frame transmission interleaved

11
HTTP/3
HTTP/2 over single TCP connection means:
1. Recovery from packet loss still stalls all object transmissions
• as in HTTP 1.1, browsers have incentive to open multiple parallel TCP
connections to reduce stalling, increase overall throughput
2. no security over TCP connection
HTTP/3: adds security, per object error- and congestion-control (more pipelining) over
UDP and more on HTTP/3 in transport layer

E-mail
Three major components:
1. user agents
2. mail servers
3. simple mail transfer protocol: SMTP

12
User Agent usage
 Authentication and Key Agreement, (aka)“mail reader”
 composing, editing, reading mail messages
 e.g., Outlook, iPhone mail client
 outgoing, incoming messages stored on server
E-mail: mail servers
 mailbox contains incoming messages for user
 message queue of outgoing (to be sent) mail messages
SMTP protocol between mail servers to send email messages
 client: sending mail server
 “server”: receiving mail server
Simple Mail Transfer Protocol (SMTP)
SMTP protocol for exchanging e-mail messages. Uses TCP to reliably transfer email message
from client (mail server initiating connection) to server, port 25. Direct transfer: sending server
(acting like client) to receiving server
Three phases of transfer
• SMTP handshaking (greeting)
• SMTP transfer of messages
• SMTP closure
Command/response interaction (like HTTP) using
• Commands: ASCII text (Human interaction)
• Response: status code and phrase
Example of STMP between client and server interaction

Comparison between SMTP with HTTP

1. HTTP: client pull
2. SMTP: client push
3. both have ASCII command/response interaction, status codes
4. HTTP: each object encapsulated in its own response message

13
 5. SMTP: multiple objects sent in multipart message
6. SMTP uses persistent connections
7. SMTP requires message (header & body) to be in 7-bit ASCII
8. SMTP server uses [Link] to determine end of message

Retrieving email: mail access protocols

1. SMTP: delivery/storage of e-mail messages to receiver‟s server
2. mail access protocol: retrieval from server
a. IMAP: Internet Mail Access Protocol [RFC 3501]: messages stored on server,
IMAP provides retrieval, deletion, folders of stored messages on server
3. HTTP: gmail, Hotmail, Yahoo!Mail, etc. provides web-based interface on top of STMP
(to send), IMAP (or POP) to retrieve e-mail messages
DNS: Domain Name System

Domain Name System (DNS)

DNS communicate to resolve names address and name translation. Distributed database
implemented in hierarchy of many name servers. Core Internet function, implemented as
application-layer protocol.
Question- How to map between IP address and name, and vice versa?
DNS: services and structure
DNS services:
1. Hostname-to-IP-address translation
2. Host aliasing

14
 a. canonical, alias names
3. mail server aliasing
4. load distribution
a. replicated Web servers: many IP addresses correspond to one name
Q: Why not centralize DNS?
1. Single point of failure
2. Traffic volume
3. Distant centralized database
4. Maintenance
DNS: a distributed, hierarchical database

DNS: root name servers

Official, contact-of-last-resort by name servers that cannot resolve name. Incredibly important
Internet function where Internet couldn‟t function without it. DNSSEC provides security
(authentication, message integrity). ICANN (Internet Corporation for Assigned Names and
Numbers) manages root DNS domain.
Example

Top-Level Domain, and authoritative servers

Top-Level Domain (TLD) servers:
Responsible for .com, .org, .net, .edu, .aero, .jobs, .museums, and all top-level country domains,
e.g.: .cn, .uk, .fr, .ca, .jp. Network Solutions: authoritative registry for .com, .net TLD, Educause:
.edu TLD.

15
Authoritative DNS servers:
Organization‟s own DNS server(s), providing authoritative hostname to IP mappings for
organization‟s named hosts and can be maintained by organization or service provider
Example

Local DNS name servers

When host makes DNS query, it is sent to its local DNS server. Local DNS server returns reply,
answering:
 from its local cache of recent name-to-address translation pairs (possibly out of date!)
o forwarding request into DNS hierarchy for resolution
 each ISP has local DNS name server; to find yours:
o MacOS: % scutil –dns
o Windows: >ipconfig /all
 local DNS server doesn‟t strictly belong to hierarchy
Types of DNS name resolution servers
1. Iterative Query DNS
2. Recursive query DNS

Iterative Query DNS

 Puts burden of name resolution on contacted name server
 Heavy load at upper levels of hierarchy?
Example: host at [Link] wants IP address for [Link]

16
 Recursive Query DNS
 Puts burden of name resolution on contacted name server
 Heavy load at upper levels of hierarchy?
Example: host at [Link] wants IP address for [Link]

Caching DNS Information

 Once (any) name server learns mapping, it caches mapping, and immediately returns a
cached mapping in response to a query
• caching improves response time
• cache entries timeout (disappear) after some time (TTL)
• TLD servers typically cached in local name servers
 Cached entries may be out-of-date
• if named host changes IP address, may not be known Internet-wide until all TTLs
expire!
• best-effort name-to-address translation!
DNS records
DNS: distributed database storing resource records (RR)

17
RR format: (name, value, type, ttl)
Type=A
 name is hostname
 value is IP address
Type=NS
 name is domain (e.g., [Link])
 value is hostname of authoritative name server for this domain
Type=CNAME
 name is alias name for some “canonical” (the real) name
 [Link] is really [Link]
 value is canonical name
Type=MX
 value is name of SMTP mail server associated with name
DNS protocol messages
DNS query and reply messages, both have same format:
Message header:
 Identification: 16 bit # for query, reply to query uses same #
 flags:
• query or reply
• recursion desired
• recursion available
• reply is authoritative
 Name, type fields for a query
 RRs in response to query
 Records for authoritative servers
 Additional “ helpful” info that may be used
DNS security
1. 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
2. Spoofing attacks
 Intercept DNS queries, returning bogus replies
 DNS cache poisoning
 DNSSEC authentication services

Peer-to-peer (P2P) architecture

No always-on server arbitrary end systems directly communicate peers request service from
other peers, provide service in return to other peers
 self-scalability – new peers bring new
 service capacity, and new service demands
Peers are intermittently connected and change IP addresses and complex management
Examples: P2P file sharing, streaming and VoIP

18
Video Streaming and Content distribution networks (CDNs):
Stream video traffic: major consumer of Internet bandwidth
• Netflix, YouTube, Amazon Prime: 80% of residential ISP traffic (2020)
1. Challenge: scale - how to reach ~1B users?
2. Challenge: heterogeneity
 different users have different capabilities (e.g., wired versus mobile; bandwidth
rich versus bandwidth poor)
Solution: distributed, application-level infrastructure
Multimedia: video
 Video: sequence of images displayed at constant rate
• e.g., 24 images/sec
 Digital image: array of pixels
• each pixel represented by bits
 Coding: use redundancy within and between images to decrease # bits used to encode
image
• spatial (within image)
• temporal (from one image to next)
 CBR: (constant bit rate): video encoding rate fixed
 VBR: (variable bit rate): video encoding rate changes as amount of spatial, temporal
coding changes
 Examples:
• MPEG 1 (CD-ROM) 1.5 Mbps
• MPEG2 (DVD) 3-6 Mbps
• MPEG4 (often used in Internet, 64Kbps – 12 Mbps)

Streaming stored video

Main challenges:
 Server-to-client bandwidth will vary over time, with changing network congestion levels
(in house, access network, network core, video server)

19
  Packet loss, delay due to congestion will delay playout, or result in poor video quality

 Continuous playout constraint: during client video playout, playout timing must match
original timing
• … but network delays are variable (jitter), so will need client-side buffer to match
continuous playout constraint
• Client interactivity: pause, fast-forward, rewind, jump through video
• Video packets may be lost, retransmitted
Solutions
[Link]-side buffering and playout delay: compensate for network-added delay, delay jitter
[Link], Adaptive Streaming over HTTP( DASH) on the
1. server:
 divides video file into multiple chunks
 each chunk encoded at multiple different rates
 different rate encodings stored in different files
 files replicated in various CDN nodes
 manifest file: provides URLs for different chunks
2. client:
 periodically estimates server-to-client bandwidth
 consulting manifest, requests one chunk at a time
 chooses maximum coding rate sustainable given current bandwidth
 can choose different coding rates at different points in time (depending on
available bandwidth at time), and from different servers
3. “intelligence” at client: client determines
 when to request chunk (so that buffer starvation, or overflow does not
occur)
 what encoding rate to request (higher quality when more bandwidth
available)
 where to request chunk (can request from URL server that is “close” to
client or has high available bandwidth)
Streaming video = encoding + DASH + playout buffering

Content distribution networks (CDNs)

Challenge: how to stream content (selected from millions of videos) to hundreds of thousands of
simultaneous users?
 option 1: single, large “mega-server”
• single point of failure
• point of network congestion
• long (and possibly congested) path to distant clients
 option 2: store/serve multiple copies of videos at multiple geographically distributed sites
(CDN)
• enter deep: push CDN servers deep into many access networks
• close to users
• 240,000 servers deployed in > 120 countries (2015)
 bring home: smaller number (10‟s) of larger clusters in POPs near access nets
• used by Limelight

20
Socket programming
Goal: learn how to build client/server applications that communicate using sockets
Socket: door between application process and end-end-transport protocol

Two socket types for two transport services:

 UDP: unreliable datagram
 TCP: reliable, byte stream-oriented
Application Example:
1. client reads a line of characters (data) from its keyboard and sends data to server
2. server receives the data and converts characters to uppercase
3. server sends modified data to client
4. client receives modified data and displays line on its screen

Socket programming with UDP

UDP: no “connection” between client and server:
 no handshaking before sending data
 sender explicitly attaches IP destination address and port # to each packet
 receiver extracts sender IP address and port# from received packet
UDP: transmitted data may be lost or received out-of-order
Application viewpoint:
 UDP provides unreliable transfer of groups of bytes (“datagrams”) between client and
server processes
Example
Client/server socket interaction: UDP

21
Socket programming with TCP
Client must contact server
 server process must first be running
 server must have created socket (door) that welcomes client‟s contact
Client contacts server by:
 Creating TCP socket, specifying IP address, port number of server process
 when client creates socket: client TCP establishes connection to server TCP
 when contacted by client, server TCP creates new socket for server process to
communicate with that particular client
 allows server to talk with multiple clients
 client source port # and IP address used to distinguish clients
Application viewpoint
 TCP provides reliable, in-order byte-stream transfer (“pipe”) between client and server
processes
Example
Client/server socket interaction: TCP

22
TCP Sockets (Reliable)
 Workflow:
 socket() → Create socket
 bind() → Bind IP and port
 listen() → Wait for connections
 accept() → Accept connection from client
 connect() → Client connects to server
 send() / recv() → Data transfer
 Example: Chat application over TCP ensures all messages arrive in order.

. UDP Sockets (Unreliable)

 Workflow:
 socket() → Create socket
 bind() → Bind IP and port
 sendto() / recvfrom() → Send/receive messages
Example: Online gaming where speed is critical; dropped packets are tolerable

Topic Review questions

1. A company wants to provide a secure online transaction system for e-commerce.
Recommend and discuss application layer protocols and security measures that would be
necessary to ensure secure transactions
2. Employees are facing issues accessing web-based services such as email (via webmail),
file sharing via FTP, and remote desktop applications. While the network seems up and
running, users complain that these applications are slow, unresponsive, or sometimes fail
to connect at all. The network administrator confirms there‟s no physical or routing issue
and suspects the problem lies in how the application layer is functioning.
a. Explain the three roles and responsibilities of the application layer based on
context given
b. Identify and describe at least two protocols that operate at this layer and how they
may be impacted.
c. Suggest and discuss possible causes of issues at the application layer based on the
context given.
d. Explain tools or methods to troubleshoot and resolve the problem on same
context.

23