CSEN 404

Introduction to Networks

Hisham Othman
Basma Mohamed Afifi
Nadeen Hamza

** Slides are attributed to J. F. Kurose

Roadmap: Application layer

 Principles of network applications

 Web and HTTP

2
 Internet protocol stack
1-3

 application: supporting network

applications application
 FTP, SMTP, HTTP
 transport: process-process data transfer transport
 TCP, UDP
 network: routing of datagrams from source network
to destination
 IP, routing protocols link
 link: data transfer between neighboring
network elements physical
 PPP, Ethernet
 physical: bits “on the wire”
Creating a network app application
transport
network
data link
physical

write programs that

 run on (different) end systems
 communicate over network
 e.g., web server software
communicates with browser
software
application
No need to write software for transport
network

network-core devices data link

physical
application
transport

Network-core devices do not run

network
 data link

user applications
physical

 applications on end systems

allows for rapid app
development, propagation

4
 Application architectures
5

 Client-Server
 Peer-to-Peer (P2P)
 Hybrid of Client-Server and P2P
 Client-Server Architecture
6

Server attributes:
 always-on host
 permanent IP address

 server farms for scaling

Clients attributes:
 communicate with server
client/server  may be intermittently connected
 may have dynamic IP addresses
 do not communicate directly with
each other
 Server Farms
7
 Server Farms
8
 Pure P2P architecture
9

 no always-on server
 arbitrary end systems
directly communicate peer-peer
 peers are intermittently
connected and change IP
addresses

 Pros and cons:

Highly scalable
Difficult to manage
 Hybrid of client-server and P2P
10

Skype
 voice-over-IP P2P application
 centralized server: finding address of remote party:
 client-client connection: direct (not through server)
Instant messaging
 chatting between two users is P2P
 centralized service: client presence detection/location
 user registers its IP address with central server when it
comes online
 user contacts central server to find IP addresses of buddies
Processes communicating
Process: program running Client process: process that
within a host initiates communication
 within same host, two
Server process: process that
processes communicate using waits to be contacted
inter-process communication
(defined by OS)
 processes in different hosts
communicate by exchanging  Note: applications with P2P
messages architectures have client
processes & server
processes

11
 Addressing processes

 host device has unique 32-bit  Q: does IP address of host on

IP address which process runs suffice for
 Exercise: use ipconfig from identifying the process?
command prompt to get your  A: No, because many
IP address (Windows) processes can be running
 to receive messages, process on same host
must have identifier  Identifier includes both IP
address and port numbers
Device ID Device ID associated with process on host
 Example port numbers:
 HTTP server: 80
Process ID
Process ID
Process ID
Process ID  Mail server: 25
Process ID Process ID

12
 Sockets
13
host or host or
 process sends/receives server server
messages to/from its socket
controlled by
 socket is analogous to door app developer
process process
 sending process pushes message
through the door socket socket

 sending process relies on TCP with

Internet
TCP with
buffers, buffers,
transport infrastructure on other variables
variables
side of door which brings
message to socket at receiving
controlled
process
by OS

 The socket is the combination of an IP address and a port.

 The type of the socket is the type of its transport protocol, e.g. TCP socket,
UDP socket, etc.
1-14 Transport Service Requirments
Delay/Timing
Data Loss
Throughput
Security
 What transport service does an app need?

Data loss Throughput

 some apps (e.g., audio/video  some apps (e.g., multimedia)
streaming) can tolerate some require minimum amount of
loss throughput to be “effective”
 other apps (e.g., file transfer,  other apps (“elastic apps”)
telnet) require 100% reliable make use of whatever
data transfer throughput they get

Delay Security
 some apps (e.g., Internet  Encryption,
telephony, interactive  Data integrity, …
games) require low delay
to be “effective”
15
 Transport service requirements of common apps
16

Application Data loss Throughput Delay Sensitive

file transfer no loss elastic no

e-mail no loss elastic no
Web documents no loss elastic no
real-time audio/video loss-tolerant audio: 5kbps-1Mbps yes, 100’s msec
video:10kbps-5Mbps
stored audio/video loss-tolerant same as above yes, few secs
interactive games loss-tolerant few kbps yes, 100’s msec
instant messaging no loss elastic yes
Internet transport protocols services

TCP service: UDP service:

 connection-oriented: setup required  unreliable data transfer
between client and server between sending and receiving
processes process
 reliable transport between sending  does not provide: connection
and receiving process. Detects Loss setup, reliability, flow control,
and supports retransmission. congestion control, timing,
 flow control: sender won’t throughput guarantee, or
overwhelm receiver security

 congestion control: throttle sender

when network overloaded Q: why bother? Why is there a
 does not provide: timing, minimum UDP?
throughput guarantees, security

18
 Internet apps: application, transport protocols
19

Application Underlying
Application layer protocol transport protocol

e-mail SMTP [RFC 2821] TCP

remote terminal access Telnet [RFC 854] TCP
Web HTTP [RFC 2616] TCP
file transfer FTP [RFC 959] TCP
streaming multimedia HTTP (eg Youtube), TCP or UDP
RTP [RFC 3550]
Internet telephony SIP, RTP, proprietary
(e.g., Skype) typically UDP
Application Layer Protocol Defines
 Types of messages Ownership:
exchanged, Public-domain protocols:
 e.g., request, response
 defined in RFCs
 Message syntax  allows for interoperability
 what fields in messages & how  e.g., HTTP, SMTP, BitTorrent
fields are delineated
 Message semantics
 meaning of information in Proprietary protocols:
fields  Made and maintained by a
companey
 Rules for when and how
 e.g., Skype, ppstream
processes send & respond to
messages

20
1-21 HTTP
HyperText Transfer Protocol
Uniform Resource Locator (URL)
 Web and HTTP
22

 Web page consists of objects

 Object can be HTML file, JPEG image, audio file, video clip,…
 Web page consists of base HTML-file which includes several
referenced objects
 Each object is addressable by a URL
 Example URL:
www.someschool.edu/someDept/pic.gif

host name path name

1-23
 First Web Browser and The Browser Wars
1-24

Early days of Mosaic & Netscape Browsers Marc Andreessen

Jim Clark John Doerr
https://www.youtube.com/watch?v=_L3Y2_YiT-A

BROWSER WARS: The True Story of the Internet -

Documentary - Netscape vs. Microsoft
https://www.youtube.com/watch?v=NbAnM3GuZQg
HTTP overview

HTTP: hypertext transfer

protocol
 Web’s application layer protocol PC running
Explorer
 client/server model
 client: browser that requests,
receives, “displays” Web
objects Server
running
 server: Web server sends
Apache Web
objects in response to requests server

Mac running
Navigator

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

26
 Stateless vs. Stateful Protocols
1-27

Stateless Protocol Stateful Protocol

Server does not retain client Server retains client information or
information or session details. session details.
Simple to design Complex to design
Difficult to recover from crash
Easy to recover from crash because
because server must retrieve saved
there is no state that must be restored
state and session details
Servers handle transactions faster. Servers handle transactions slower.
More scalable Less scalable
Example of Stateless Example of Stateful are FTP , Telnet ,
are UDP , DNS , HTTP , etc. etc.

https://www.geeksforgeeks.org/difference-between-stateless-and-stateful-protocol/
 HTTP request message
28

 two types of HTTP messages: request, response

 HTTP request message:
 ASCII (human-readable format)

request line
(GET, POST, GET /somedir/page.html HTTP/1.1
HEAD commands) Host: www.someschool.edu
User-agent: Mozilla/4.0
header Connection: close
lines Accept-language:fr
(extra carriage return, line feed)
Carriage return,
line feed
indicates end
of message
 HTTP request message: general format
29
Uploading form input

Post method: GET (URL) method:

 Web page often includes  Uses GET method

form input  Input is uploaded in URL

 Input is uploaded to server field of request line:

in entity body
www.somesite.com/animalsearch?monkeys&banana

30
HTTP Methods
HTTP/1.0 HTTP/1.1
 GET  GET, POST, HEAD

 POST  PUT

 HEAD  uploads file in entity body to

path specified in URL field
 Similar to GET request, but
without the response body.  DELETE
 useful for retrieving meta-  deletes file specified in the
information in response URL field
headers, without having to
transport the entire content.

32
 HTTP response message
33

status line
(protocol, status code, status phrase)
HTTP/1.1 200 OK
Connection: close
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
header
Last-Modified: Mon, 22 Jun 1998 …...
lines
Content-Length: 6821
Content-Type: text/html

data, e.g., data data data data data ...

requested
HTML file
 HTTP response status codes
1-34

 In first line in server-to-

client response message.

 Families of codes:
 2xx Success
 3xx Redirections: moved,
new location specified
later in this message
(Location:)
 4xx Client Errors
 5xx HTTP Server Errors
 Summary
1-35

 Principles of network applications

 Socket
 Application Requirements
 Data Loss
 Throughput
 Timing

 Overview on HTTP
 Message types
 Methods:
 GET, POST, HEAD, ..
 Message structure
 Any Question?
1-36