ICE – 2401

Computer Systems &

Network
Lecture 4

-1
Application layer: overview

 Principles of network
applications
 Web and HTTP
 E-mail, SMTP, IMAP
 The Domain Name System
DNS

-2
Some network apps
 social networking  voice over IP (e.g., Skype)
 Web  real-time video conferencing
 text messaging (e.g., Zoom)
 e-mail  Internet search
 multi-user network games  remote login
 streaming stored video …
(YouTube, Hulu, Netflix)
 P2P file sharing Q: your favorites?

3
Creating a network app
application

write programs that:

transport
network
mobile network
data link

 run on (different) end systems

physical
national or global ISP

 communicate over network

 e.g., web server software
communicates with browser software
local or
no need to write software for regional ISP

network-core devices home network content

 network-core devices do not run user application
transport
provider
network datacenter
network
applications
application
data link network
transport
physical network

 applications on end systems allows data link

physical

for rapid app development, enterprise

propagation network

4
Client-server paradigm
server: mobile network
 always-on host national or global ISP

 permanent IP address
 often in data centers, for scaling
clients: local or
 contact, communicate with server regional ISP

 may be intermittently connected home network content

provider
 may have dynamic IP addresses network datacenter
network

 do not communicate directly with

each other
enterprise
 examples: HTTP, IMAP, FTP network

5
Peer-peer architecture
 no always-on server mobile network
 arbitrary end systems directly national or global ISP

communicate
 peers request service from other
peers, provide service in return to
other peers local or
regional ISP
• self scalability – new peers bring new
service capacity, as well as new service home network content
demands provider
network datacenter
 peers are intermittently connected network

and change IP addresses

• complex management enterprise
 example: P2P file sharing network

6
Processes communicating
process: program running clients, servers
within a host client process: process that
initiates communication
 within same host, two
server process: process
processes communicate that waits to be contacted
using inter-process
communication (defined by
OS)  note: applications with
P2P architectures have
 processes in different hosts client processes &
communicate by exchanging server processes
messages
7
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

application application
socket controlled by
process process app developer

transport transport
network network controlled
link
by OS
link Internet
physical physical

8
Addressing processes
 to receive messages, process  identifier includes both IP address
must have identifier and port numbers associated with
 host device has unique 32-bit process on host.
IP address  example port numbers:
 Q: does IP address of host on • HTTP server: 80
which process runs suffice for • mail server: 25
identifying the process?  to send HTTP message to
 A: no, many processes bangor.ac.uk web server:
can be running on • IP address: 52.17.79.56
same host • port number: 80

9
Type of Sockets
 Different types of sockets implement different service models:

• Stream socket (Transmission Control Protocol “TCP”)

• Datagram socket (User Datagram Protocol “UDP”)

10
Internet transport protocols services
TCP service: UDP service:
• Connection oriented; requires three packets  Connectionless; there is no ordering
of messages, no tracking
to set up a socket connection, before any
connections, etc.
user data can be sent.
 Packets are sent individually and are
• Data is read as a byte stream; no checked for integrity only if they
arrive. Packets have definite
distinguishing indications are transmitted to
boundaries which are honoured
signal message (segment) boundaries. upon receipt.

11
Internet transport protocols services
TCP service: UDP service:
• Reliable; many attempts to reliably deliver the  Unreliable; when a message is sent, it
cannot be known if it will reach its
message are made. If it gets lost along the way,
destination; it could get lost along the
the server will re-request the lost part way. There is no concept of
acknowledgment and retransmission

• Ordered; If two messages are sent over a

 Not ordered; if two messages are sent to
connection in sequence, the first message will
the same recipient, the order in which
reach the receiving application first. When data they arrive cannot be predicted.
segments arrive in the wrong order, TCP buffers
the out-of-order data until all data can be
properly re-ordered and delivered to the
application
12
 Internet applications, and transport protocols
application
application layer protocol transport protocol

file transfer/download FTP [RFC 959] TCP

e-mail SMTP [RFC 5321] TCP
Web documents HTTP 1.1 [RFC 7320] TCP
Internet telephony SIP [RFC 3261], RTP [RFC TCP or UDP
3550], or proprietary
streaming audio/video HTTP [RFC 7320], DASH TCP
interactive games WOW, FPS (proprietary) UDP or TCP

13
Web and HTTP
First, a quick review…
 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.,
www.someschool.edu/someDept/pic.gif

host name path name

14
HTTP overview
HTTP: hypertext transfer protocol
 Web’s application-layer protocol
HT
 client/server model: PC running
TP
req
ues
HT t
• client: browser that requests, Firefox browser TP
res
pon
receives, (using HTTP protocol) and se

“displays” Web objects ues

t
req
• server: Web server sends (using HTTP
p o ns
e server running
es Apache Web
HTTP protocol) objects in response HTTP
r
server
to requests
iPhone running
Safari browser

15
HTTP overview (continued)
HTTP uses TCP: HTTP is “stateless”
 client initiates TCP connection  server maintains no
(creates socket) to server, port 80 information about past client
 server accepts TCP connection requests
from client aside
 HTTP messages (application-layer protocols that maintain “state”
protocol messages) exchanged are complex!
 past history (state) must be
between browser (HTTP client) and maintained
Web server (HTTP server)  if server/client crashes, their views
 TCP connection closed of “state” may be inconsistent, must
be reconciled

16
HTTP connections: two types
Non-persistent HTTP Persistent HTTP
1. TCP connection opened  TCP connection opened to
2. at most one object sent a server
over TCP connection  multiple objects can be
3. TCP connection closed sent over single TCP
connection between client,
downloading multiple and that server
objects required multiple  TCP connection closed
connections

17
 Non-persistent HTTP: example
User enters URL: www.someSchool.edu/someDepartment/home.index
(containing text, references to 10 jpeg images)

1a. HTTP client initiates TCP

connection to HTTP server 1b. HTTP server at host
(process) at www.someSchool.edu on www.someSchool.edu waiting for TCP
port 80 connection at port 80 “accepts”
connection, notifying client
2. HTTP client sends HTTP
request message (containing
URL) into TCP connection 3. HTTP server receives request message,
socket. Message indicates forms response message containing
time that client wants object requested object, and sends message
someDepartment/home.index into its socket
18
 Non-persistent HTTP: example (cont.)
User enters URL: www.someSchool.edu/someDepartment/home.index
(containing text, references to 10 jpeg images)

4. HTTP server closes TCP

5. HTTP client receives response connection.
message containing html file,
displays html. Parsing html file,
finds 10 referenced jpeg objects

6. Steps 1-5 repeated for

each of 10 jpeg objects
time

19
Non-persistent HTTP: response time

RTT (definition): time for a small

packet to travel from client to initiate TCP
server and back connection
RTT
HTTP response time (per object):
 one RTT to initiate TCP connection request file
 one RTT for HTTP request and first few RTT time to
transmit
bytes of HTTP response to return file
 obect/file transmission time file received

time time
Non-persistent HTTP response time = 2RTT+ file transmission time
20
Persistent HTTP (HTTP 1.1)
Non-persistent HTTP issues: Persistent HTTP (HTTP1.1):
 requires 2 RTTs per object  server leaves connection open after
 OS overhead for each TCP sending response
connection  subsequent HTTP messages
 browsers often open multiple between same client/server sent
parallel TCP connections to over open connection
fetch referenced objects in  client sends requests as soon as it
parallel encounters a referenced object
 as little as one RTT for all the
referenced objects (cutting
response time in half)
21