0% found this document useful (0 votes)
9 views

Lecture 3 Application Layerss

The document discusses HTTP connections, HTTP methods, URIs, XML, and DNS. It covers how HTTP connections work, defines common HTTP methods like GET and POST, explains the components of a URI, provides examples of using XML and JSON to represent data, and describes how DNS maps between domain names and IP addresses in a decentralized manner.

Uploaded by

hicam12309
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
9 views

Lecture 3 Application Layerss

The document discusses HTTP connections, HTTP methods, URIs, XML, and DNS. It covers how HTTP connections work, defines common HTTP methods like GET and POST, explains the components of a URI, provides examples of using XML and JSON to represent data, and describes how DNS maps between domain names and IP addresses in a decentralized manner.

Uploaded by

hicam12309
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 41

Agenda

1. HTTP conections
2.HTTP methods
3. URI
4. XML
5. DNS

2.2
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

 Have dynamic IP addresses home network content


provider
 examples: HTTP, SMTP, FTP network datacenter
network

enterprise
network

Application Layer: 2-3


 Types of messages exchanged, open protocols:
• e.g., request, response  Allows for interoperability
 Message syntax: between heterogeneous
• what fields in messages & machines
how fields are delineated  e.g., HTTP, SMTP, FTP,DNS
 Message semantics
• meaning of information in
fields
 Rules for when and how
processes send & respond to
messages
Non-persistent HTTP Persistent HTTP
1. TCP connection opened 1.TCP connection opened to a
server
2. Only one object sent over 2.Multiple objects can be sent
TCP connection over single TCP connection
between client, and that server
3. TCP connection closed
3. TCP connection closed
downloading multiple objects Can download multiple objects
required multiple in one connection
connections
User enters URL: www.AIU.edu/someDepartment/home.index

(containing text, references to 10 jpeg images)


1a. HTTP client initiates TCP connection 1b. HTTP server at host www.AIU.edu waiting
to HTTP server (process) at for TCP connection at port 80 “accepts”
www.AIU.edu on port 80 connection, notifying client
2. HTTP client sends HTTP request 3. HTTP server receives request
message (containing URL) into TCP message, forms response message
connection socket. Message indicates containing requested object, and
that client wants sends message into its socket
objectsomeDepartment/home.index
4. HTTP server closes TCP
5. HTTP client receives response message connection.
containing html file, displays html.
Parsing html file, finds 10 referenced
time jpeg objects

6. Steps 1-5 repeated for


each of 10 jpeg objects
RTT Round-Trip time(definition):
time sending a client request and initiate TCP
receive respond from server connection
RTT
request file
HTTP response time (per object):
RTT time to
 one RTT to initiate TCP connection transmit
 one RTT for HTTP request and first few file received
file
bytes of HTTP response to return
 object/file transmission time
time time
initiate TCP
connection
RTT
request file
RTT time to
transmit
file received file
initiate TCP
connection RTT

request file
RTT time to
transmit
file
time time 2.8
Time needed to transfer data including text file and ten figures from
HTML at the server to a client

Non-persistent
2 RTT (Connection time) + 2 * 10 RTT+ files transfer time= 22RTT+ files transfer time

Persistent
2 RTT (Connection time) + 10 RTT+ files transfer time = 12RTT+ files transfer time

2.9
• GET − Provides a read only access to a resource.

• POST − Used to create a new resource.

• DELETE − Used to remove a resource.

• PUT − Used to update a existing resource


• HTTP methods deals with stored data as resources.

• Resources can be Text Files, Html Pages, Images, Videos or Dynamic


Business Data.

• Each resource is identified by URIs/ Global IDs.

• URI: Uniform Resource Identifiers are simply formatted string containing


name and location to identify a resource.

2.13
• scheme://authority/path1/path2?query#fragment-id

• schema: used application layer protocol


followed by a colon: ":“ followed by double slash: "//"
• authority component: Domain terminated by "/",
• path components separated by "/".
• A question mark: "?“ for query
• A pound sign: "#“ fragment id (next) is present.

2.14
https://AIU.edu/tests/test1/?tag=computernetwork#part2

Protocol: Domain: path path Key value Secondary


https AIU.edu 1 2 computernetworks part

Query FragmentID
1 GET
Retrieve information from the given server using a given URI. Requests using GET should only retrieve
data and should have no other effect on the data.

2 POST
Send data to the server, for example, customer information, file upload.

3 PUT
Change (update) the current representations of the target resource with the uploaded content.

4 DELETE
Removes all current representations of the target resource given by a URI.
.

2.18
Request to get hello.html file

HTTP/1.1 200 OK
<html>
<body>
<h1>Hello, World!
</h1>
</body>
</html>
• GET /hello.htm HTTP/1.1

Hello.html file
<html>
<body>
<h1>Hello, World!
</h1>
</body>
</html>
2.19
• HTML can represent data to be displayed without formatting or
data types.

• HTML doesn’t enable new tags names(only reserved tags)

• To deal with data and functionality we need another global


common language.

• XML eXtensible Markup Language.


2.20
• XML eXtensible Markup Language
• a student is a resource which is represented using the following XML format −
• <student>
• <id>16214</id>
• <name>Ahmed</name>
• <level>4</level>
• </student>

• The same resource can be represented in JSON format as follows −

• {
• "id":16214,
• "name":“Ahmed",
• “level":4
• }
HTTP Method GET

URI http://AIU.edu/FCSE/students

Operation Get list of students

HTTP Method GET

URI http://AIU.edu/FCSE/students/16442

Operation Get student with id=16442


HTTP Method POST

URI http://http://AIU.edu/FCSE/students164522

Operation Insert user with Id 16452


HTTP Method PUT

URI http://http://AIU.edu/FCSE/students16232

Operation Update Student with Id 16232


HTTP Method DELETE

URI http://http://AIU.edu/FCSE/students16224

Operation Delete User with Id 16224


 status code appears in 1st line in server-to-client response message.
 some sample codes:
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)
400 Bad Request
• request msg not understood by server
404 Not Found
• requested document not found on this server
505 HTTP Version Not Supported
Human understand names
Computers understand numbers
(IP address)

How to bridge this gap


https://www.AIU.edu/index.php/en/

Blink chrome
https://www.AIU.edu/index.php/en/

Ip=
DNS 002.012.002…

Blink chrome
Q: How to map between IP address and name, and vice versa ?

A: We need a database including names and IP addresses to perform


matching.
It is considered the phonebook of the Internet.

Q: Can we use centralize DNS?


NO (Billion records, many Trillions of request)
Single point of failure
Traffic volume
Distant from centralized database
• Main service (hostname-to-IP-address translation)

 distributed database implemented in hierarchy of many name servers

 hosts, DNS servers communicate to resolve names (address/name translation)


• Core Internet function, implemented as application-layer protocol
Root DNS Servers Root
… …
.com DNS servers .org DNS servers .edu DNS servers Top Level Domain
… … … …
yahoo.com amazon.com pbs.org nyu.edu umass.edu
DNS servers DNS servers DNS servers DNS servers DNS servers Authoritative

st
Client wants IP address for www.amazon.com; approximation:
1
 client queries root server to find .com DNS server
 client queries .com DNS server to get amazon.com DNS server
 client queries amazon.com DNS server to get IP address for www.amazon.com
 Root servers, or DNS root servers, are 13 logical root name “servers”
name servers that are responsible for the worldwide each “server” replicated
functionality of the DNS as well as the many times (~200 servers in US)
entire Internet.

Who operates DNS root servers?


The Internet Corporation for Assigned
Names and Numbers (ICANN) operates
servers for one of the 13 IP addresses in
the root zone and delegated operation of
the other 12 IP addresses to various
organizations including NASA, the
University of Maryland, American
departement of defence.
NS-Root-Servers Letters IPv4 address operator
A 198.41.0.4 VeriSign
B 192.228.79.201 USC-ISI
C 192.33.4.12 Cogent Communications
D 199.7.91.13 University of Maryland
E 192.203.230.10 NASA
F 192.5.5.241 ISC
G 192.112.36.4 U.S. DoD NIC
H 128.63.2.53 US Army Research Lab
I 192.36.148.17 Autonomica
J 192.58.128.30 VeriSign
K 193.0.14.129 RIPE NCC
L 199.7.83.42 ICANN
M 202.12.27.33 WIDE Project
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, .eg
 Network Solutions: authoritative registry for .com, .net, .edu

Authoritative DNS servers:


 organization’s own DNS server(s), providing authoritative hostname to IP
mappings for organization’s named hosts
 can be maintained by organization or service provider
1. Cached by operating system or the browser.

When writing the name of web site a query is sent to resolve the IP address of the
specific name.

First, your computer will see if the website is cached in your system by your OS or
browser.

If it’s not, the query will head to a local DNS recursive server.
2. 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!)
• forwarding request into DNS hierarchy for resolution
• each ISP has local DNS name server; to find yours:
• Windows: >ipconfig /all.
A recursive server is usually operated by your internet service provider (ISP) or wireless
carrier.

If the website isn’t cached in this server (usually by another user who has visited the
website), then the query heads to a root server.
root DNS server
Example: host at engineering.nyu.edu
wants IP address for gaia.cs.umass.edu 2
3
TLD DNS server
Iterated query: 1 4

 contacted server replies 8


5
with name of server to requesting host at local DNS server
contact engineering.nyu.edu dns.nyu.edu
gaia.cs.umass.edu
 “I don’t know this name, 7 6
but ask this server”
authoritative DNS server
dns.cs.umass.edu
DNS name resolution: recursive query
root DNS server
Example: host at engineering.nyu.edu
wants IP address for gaia.cs.umass.edu 2 3

7 6
Recursive query: 1 TLD DNS server
 puts burden of name 8
resolution on requesting host at local DNS server
4
engineering.nyu.edu dns.nyu.edu 5
contacted name gaia.cs.umass.edu

server
 heavy load at upper authoritative DNS server
levels of hierarchy? dns.cs.umass.edu
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!

You might also like