Chapter2: Application layer Web and HTTP

ˆ Principles of network applications First some jargon

™ Architecture: client-server or P2P ˆ Web page consists of objects
™ Services that an application needs ˆ Object can be HTML file, JPEG image, Java
applet, audio file,…
ˆ important application-level protocols
ˆ Web page consists of base HTML-file which
™ FTP, SMTP, P2P, ……
includes several referenced objects
ˆ programming network applications ˆ Each object is addressable by a URL
™ socket API ˆ Example URL:
ˆ Web stuff www.someschool.edu/someDept/pic.gif
™ HTTP, DNS, Web searching
host name path name

2: Application Layer 1 2: Application Layer 2

HTTP overview HTTP overview (continued)

HTTP: hypertext Uses TCP: HTTP is “stateless”
transfer protocol HT
T Pr
ˆ client initiates TCP ˆ server maintains no
ˆ Web’s application layer PC running HT
equ
est connection (creates socket) information about
TP past client requests
protocol Explorer res to server, port 80
pon
se
ˆ client/server model ˆ server accepts TCP
connection from client aside
™ client: browser that st Protocols that maintain
ue ˆ HTTP messages (application-
requests, receives, eq “state” are complex!
T Pr nse Server
“displays” Web objects HT spo running layer protocol messages) ˆ past history (state) must
P re
™ server: Web server
T Apache Web exchanged between browser
HT be maintained
server (HTTP client) and Web
sends objects in ˆ if server/client crashes,
response to requests server (HTTP server)
Mac running
their views of “state” may
ˆ TCP connection closed
ˆ HTTP 1.0: RFC 1945 Navigator be inconsistent, must be
ˆ HTTP 1.1: RFC 2068 reconciled

2: Application Layer 3 2: Application Layer 4

1
 HTTP connections Nonpersistent HTTP
(contains text,
Suppose user enters URL references to 10
Nonpersistent HTTP Persistent HTTP
www.someSchool.edu/someDepartment/home.index jpeg images)

ˆ At most one object is ˆ Multiple objects can 1a. HTTP client initiates TCP
sent over a TCP be sent over single connection to HTTP server
1b. HTTP server at host
(process) at
connection. TCP connection www.someSchool.edu on port 80
www.someSchool.edu waiting
between client and for TCP connection at port 80.
ˆ HTTP/1.0 uses “accepts” connection, notifying
nonpersistent HTTP server. client
2. HTTP client sends HTTP
ˆ HTTP/1.1 uses request message (containing
persistent connections URL) into TCP connection 3. HTTP server receives request
in default mode socket. Message indicates message, forms response
that client wants object message containing requested
someDepartment/home.index object, and sends message
into its socket

time
2: Application Layer 5 2: Application Layer 6

Nonpersistent HTTP (cont.) Non-Persistent HTTP: Response time

Definition of RTT: time to
4. HTTP server closes TCP
connection. send a small packet to
5. HTTP client receives response travel from client to
message containing html file, server and back. initiate TCP
displays html. Parsing html connection
file, finds 10 referenced jpeg Response time: RTT
objects
ˆ one RTT to initiate TCP
time 6. Steps 1-5 repeated for each
request
connection file
time to
of 10 jpeg objects RTT
ˆ one RTT for HTTP transmit
file
request and first few file

bytes of HTTP response

received

to return time time

ˆ file transmission time
total = 2RTT+transmit time
2: Application Layer 7 2: Application Layer 8

2
Persistent HTTP
Nonpersistent HTTP issues:
ˆ requires 2 RTTs per object
ˆ OS overhead for each TCP
connection
ˆ browsers often open parallel
TCP connections to fetch
referenced objects
HTTP request message: general format
Persistent HTTP
ˆ server leaves connection
open after sending
response
ˆ 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
2: Application Layer
2: Application Layer
HTTP request message
ˆ 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
Carriage return,
(extra carriage return, line feed)
line feed
indicates end
of message
9 2: Application Layer 10
Uploading form input
Post method:
ˆ Web page often
includes form input URL method:
ˆ Input is uploaded to ˆ Uses GET method
server in entity body ˆ Input is uploaded in
URL field of request
line:
www.somesite.com/animalsearch?monkeys&banana
11 2: Application Layer 12
3
Method types HTTP response message
status line
HTTP/1.0 HTTP/1.1 (protocol
ˆ GET ˆ GET, POST, HEAD status code HTTP/1.1 200 OK
status phrase) Connection close
ˆ POST ˆ PUT Date: Thu, 06 Aug 1998 12:00:15 GMT
ˆ HEAD ™ uploads file in entity header
Server: Apache/1.3.0 (Unix)
body to path specified lines
Last-Modified: Mon, 22 Jun 1998 …...
™ asks server to leave
in URL field Content-Length: 6821
requested object out of
response ˆ DELETE Content-Type: text/html

™ deletes file specified in data, e.g., data data data data data ...
the URL field requested
HTML file

2: Application Layer 13 2: Application Layer 14

HTTP response message HTTP response status codes

In first line in server->client response message.
A few 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 (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
2: Application Layer 15 2: Application Layer 16

4
 Trying out HTTP (client side) for yourself User-server state: cookies
Example:
1. Telnet to your favorite Web server: Many major Web sites
use cookies ˆ Susan always access
telnet cis.poly.edu 80 Opens TCP connection to port 80 Internet always from PC
(default HTTP server port) at cis.poly.edu. Four components:
Anything typed in sent 1) cookie header line of ˆ visits specific e-
to port 80 at cis.poly.edu HTTP response message commerce site for first
2) cookie header line in time
2. Type in a GET HTTP request: HTTP request message
3) cookie file kept on ˆ when initial HTTP
By typing this in (hit carriage
GET /~ross/ HTTP/1.1
return twice), you send
user’s host, managed by requests arrives at site,
Host: cis.poly.edu user’s browser site creates:
this minimal (but complete)
GET request to HTTP server 4) back-end database at
Web site ™ unique ID

3. Look at response message sent by HTTP server! ™ entry in backend

database for ID
2: Application Layer 17 2: Application Layer 18

Cookies: keeping “state” (cont.) Cookies (continued)

client server aside
What cookies can bring: Cookies and privacy:
ebay 8734 ˆ authorization ˆ cookies permit sites to
usual http request msg
Amazon server learn a lot about you
creates ID ˆ shopping carts
cookie file usual http response
ˆ you may supply name
Set-cookie: 1678 1678 for user create ˆ recommendations
ebay 8734 entry and e-mail to sites
amazon 1678 ˆ user session state
usual http request msg
cookie: 1678 cookie- access (Web e-mail)
specific
one week later: usual http response msg backend How to keep “state”:
action
access
database ˆ protocol endpoints: maintain state
ebay 8734 usual http request msg at sender/receiver over multiple
amazon 1678 cookie: 1678 cookie- transactions
spectific
usual http response msg action ˆ cookies: http messages carry state

2: Application Layer 19 2: Application Layer 20

5
 Web caches (proxy server) More about Web caching
Goal: satisfy client request without involving origin server
ˆ cache acts as both Why Web caching?
ˆ user sets browser: origin client and server ˆ reduce response time
server
Web accesses via ˆ typically cache is for client request
cache Proxy installed by ISP
HT t ˆ reduce traffic on an
T ues
equ server P req
Pr
ˆ browser sends all (university, company, institution’s access
clientHTT Pr
est
HT T
p on se
HTTP requests to esp
ons T P res residential ISP) link.
e HT
cache st
eque ˆ Internet dense with
object in cache: cache r se
TP on
™
HT esp caches: enables “poor”
returns object T Pr
HT content providers to
™ else cache requests
object from origin client effectively deliver
server, then returns
origin
server
content (but so does
object to client P2P file sharing)
2: Application Layer 21 2: Application Layer 22

Caching example Caching example (cont)

origin origin
Assumptions Possible solution
servers servers
ˆ average object size = 100,000 ˆ increase bandwidth of access
bits public link to, say, 10 Mbps public
Internet Internet
ˆ avg. request rate from Consequences
institution’s browsers to origin ˆ utilization on LAN = 15%
servers = 15/sec ˆ utilization on access link = 15%
1.5 Mbps 10 Mbps
ˆ delay from institutional router ˆ Total delay = Internet delay +
access link access link
to any origin server and back access delay + LAN delay
institutional institutional
to router = 2 sec = 2 sec + msecs + msecs
network network
10 Mbps LAN 10 Mbps LAN
Consequences ˆ often a costly upgrade
ˆ utilization on LAN = 15%
ˆ utilization on access link = 100%
ˆ total delay = Internet delay + institutional institutional
access delay + LAN delay cache cache
= 2 sec + minutes + milliseconds
2: Application Layer 23 2: Application Layer 24

6
Caching example (cont) Conditional GET
origin
possible solution: install servers ˆ Goal: don’t send object if cache server
cache public cache has up-to-date cached HTTP request msg
ˆ suppose hit rate is 0.4 Internet version
object
If-modified-since:
consequence ˆ cache: specify date of <date>
not
ˆ 40% requests will be cached copy in HTTP request modified
satisfied almost immediately If-modified-since: HTTP response
1.5 Mbps
ˆ 60% requests satisfied by access link <date>
HTTP/1.0
origin server 304 Not Modified
institutional ˆ server: response contains no
ˆ utilization of access link
reduced to 60%, resulting in network
10 Mbps LAN object if cached copy is up-
HTTP request msg
negligible delays (say 10 to-date:
msec) HTTP/1.0 304 Not
If-modified-since:
<date> object
ˆ total avg delay = Internet Modified modified
delay + access delay + LAN institutional
delay = .6*(2.01) secs + HTTP response
cache
.4*milliseconds < 1.4 secs HTTP/1.0 200 OK
<data>
2: Application Layer 25 2: Application Layer 26

Chapter2: Application layer DNS: Domain Name System

ˆ Principles of network applications People: many identifiers: Domain Name System:

™ Architecture: client-server or P2P
™ SSN, name, passport #
Internet hosts, routers:
™ Services that an application needs
™ IP address (32 bit) -
ˆ important application-level protocols used for addressing
™ FTP, SMTP, P2P, …… datagrams
™ “name”, e.g.,
ˆ programming network applications ww.yahoo.com - used by
™ socket API humans
ˆ Web stuff Q: map between IP
addresses and name ?
™ DNS
ˆ distributed database
implemented in hierarchy of
many name servers
ˆ application-layer protocol
host, routers, name servers to
communicate to resolve names
(address/name translation)
™ note: core Internet
function, implemented as
application-layer protocol
™ complexity at network’s
“edge”

2: Application Layer 27 2: Application Layer 28

7
 DNS Distributed, Hierarchical Database
Root DNS Servers

DNS services Why not centralize DNS?

ˆ Hostname to IP ˆ single point of failure
com DNS servers org DNS servers edu DNS servers
address translation ˆ traffic volume
ˆ Host aliasing ˆ distant centralized yahoo.com amazon.com pbs.org poly.edu umass.edu
database DNS servers DNS serversDNS servers
™ Canonical and alias DNS servers DNS servers
names ˆ maintenance Client wants IP for www.amazon.com; 1st approx:
ˆ Mail server aliasing
ˆ Client queries a root server to find com DNS
ˆ Load distribution server
doesn’t scale!
™ Replicated Web ˆ Client queries com DNS server to get amazon.com
servers: set of IP DNS server
addresses for one
canonical name ˆ Client queries amazon.com DNS server to get IP
address for www.amazon.com
2: Application Layer 29 2: Application Layer 30

DNS: Root name servers TLD and Authoritative Servers

ˆ contacted by local name server that can not resolve name
ˆ root name server: ˆ Top-level domain (TLD) servers:
™ contacts authoritative name server if name mapping not known ™ responsible for com, org, net, edu, etc, and all
™ gets mapping top-level country domains uk, fr, ca, jp.
™ returns mapping to local name server ™ Network Solutions maintains servers for com TLD
a Verisign, Dulles, VA ™ Educause for edu TLD

ˆ Authoritative DNS servers:

c Cogent, Herndon, VA (also Los Angeles)
d U Maryland College Park, MD k RIPE London (also Amsterdam,
g US DoD Vienna, VA Frankfurt)

™ organization’s DNS servers, providing

h ARL Aberdeen, MD i Autonomica, Stockholm (plus 3
j Verisign, ( 11 locations) other locations)

authoritative hostname to IP mappings for

m WIDE Tokyo
e NASA Mt View, CA

organization’s servers (e.g., Web, mail).

f Internet Software C. Palo Alto,
CA (and 17 other locations)

13 root name ™ can be maintained by organization or service

servers worldwide
b USC-ISI Marina del Rey, CA
provider
l ICANN Los Angeles, CA

2: Application Layer 31 2: Application Layer 32

8
 DNS name
Local Name Server root DNS server

resolution example
2
ˆ Does not strictly belong to hierarchy ˆ Host at cis.poly.edu 3
TLD DNS server
ˆ Each ISP (residential ISP, company, wants IP address for 4

university) has one. gaia.cs.umass.edu 5

™ Also called “default name server” iterated query: local DNS server
dns.poly.edu
ˆ When a host makes a DNS query, query is ˆ contacted server 7 6
replies with name of 1 8
sent to its local DNS server server to contact
™ Acts as a proxy, forwards query into hierarchy. ˆ “I don’t know this
authoritative DNS server
dns.cs.umass.edu
name, but ask this requesting host
server” cis.poly.edu

gaia.cs.umass.edu

2: Application Layer 33 2: Application Layer 34

DNS name
DNS: caching and updating records
resolution example root DNS server

ˆ once (any) name server learns mapping, it caches

recursive query: 2 3 mapping
ˆ puts burden of name
7 6 ™ cache entries timeout (disappear) after some
resolution on
contacted name TLD DNS server time
server ™ TLD servers typically cached in local name
ˆ heavy load? local DNS server servers
dns.poly.edu 5 4
• Thus root name servers not often visited
1 8
ˆ update/notify mechanisms under design by IETF
authoritative DNS server ™ RFC 2136
dns.cs.umass.edu ™ http://www.ietf.org/html.charters/dnsind-charter.html
requesting host
cis.poly.edu

gaia.cs.umass.edu
2: Application Layer 35 2: Application Layer 36

9
 DNS records
DNS: distributed db storing resource records (RR)
ˆ Type=A RR format: (name, value, type, ttl)
™ name is hostname
™ value is IP address
™ E.g.: (dns.umass.edu, 128.119.40.111, A)

ˆ Type=NS
™ name is domain (e.g. foo.com)
™ value is hostname of authoritative name server for this domain
™ E.g.: (umass.edu, dns.umass.edu, NS)

ˆ Type=CNAME
™ name is alias name for some “canonical” (the real) name
www.ibm.com is really servereast.backup2.ibm.com
™ value is canonical name
™ E.g. : (www.ibm.com, servereast.backup2.ibm.com, CNAME)

ˆ Type=MX
™ value is name of mailserver associated with name
2: Application Layer 37 ™ E.g. (foo.com, mail.bar.foo.com, MX) 2: Application Layer 38

Domain Type TTL Answer

Example hotmail.com. MX 3600 mx2.hotmail.com.
hotmail.com.
hotmail.com.
MX
MX
3600
3600
mx3.hotmail.com.
mx4.hotmail.com.
DNS protocol, messages
hotmail.com. MX 3600 mx1.hotmail.com.
DNS protocol : query and reply messages, both with
mx2.hotmail.com. A 3600 65.54.244.168
mx2.hotmail.com. A 3600 65.54.244.40
same message format
mx2.hotmail.com. A 3600 65.54.190.50
msg header
mx2.hotmail.com. A 3600 65.54.245.40
ˆ identification: 16 bit #
mx3.hotmail.com. A 3600 65.54.244.200
for query, reply to query
mx3.hotmail.com. A 3600 64.4.50.179
uses same #
mx3.hotmail.com. A 3600 65.54.244.72
ˆ flags:
mx3.hotmail.com. A 3600 65.54.245.72
™ query or reply
mx4.hotmail.com. A 3600 65.54.244.104
mx4.hotmail.com. A 3600 65.54.244.232 ™ recursion desired

mx4.hotmail.com. A 3600 65.54.245.104 ™ recursion available

mx4.hotmail.com. A 3600 65.54.190.179 ™ reply is authoritative

mx1.hotmail.com. A 3600 65.54.244.8
mx1.hotmail.com. A 3600 64.4.50.50
mx1.hotmail.com. A 3600 65.54.245.8
2: Application Layer 39 2: Application Layer 40
mx1.hotmail.com. A 3600 65.54.244.136

10
 DNS protocol, messages Inserting records into DNS
ˆ Example: just created startup “Network Utopia”
Name, type fields ˆ Register name networkuptopia.com at a registrar
for a query (e.g., Network Solutions)
™ Need to provide registrar with names and IP addresses of
RRs in response your authoritative name server (primary and secondary)
to query ™ Registrar inserts two RRs into the com TLD server:

records for (networkutopia.com, dns1.networkutopia.com, NS)

authoritative servers (dns1.networkutopia.com, 212.212.212.1, A)

additional “helpful” ˆ Put in authoritative server Type A record for

info that may be used www.networkuptopia.com and Type MX record for
mail.networkutopia.com
ˆ How do people get the IP address of your Web site?

2: Application Layer 41 2: Application Layer 42

Exercise
Chapter2: Application layer
ˆ Suppose within your Web browser, you click on a link
to obtain a Webpage. The IP address for the
associated URL is not cached in your local host. ˆ Principles of network applications
Suppose that n DNS servers should be visited before ™ Architecture: client-server or P2P
your host receives the IP address. The successive ™ Services that an application needs
visits incur an RTT of RTT1, RTT2, …, RTTn. Suppose
ˆ important application-level protocols
that the base HTML file associated with the link
references three very small objects (small pictures) ™ FTP, SMTP, P2P, ……

on the same server. Let RTT0 denote the RTT ˆ programming network applications
between the local host and the server containing the ™ socket API
objects. Neglecting transmission times, how much time
elapses with ˆ Web stuff
™ a) Non-persistent HTTP with no parallel TCP connections? ™ Web searching
™ b) Non-persistent HTTP with parallel connections?
™ c) Persistent HTTP with pipelining?
2: Application Layer 43 2: Application Layer 44

11
How Search Engines Work Standard Web Search Engine Architecture
Check for duplicates,
crawl the store the
ˆ Gather the contents of all web pages (using web documents
Crawler
a program called a crawler or spider) machines
docIDs

ˆ Organize the contents of the pages in a

way that allows efficient retrieval Create an
(indexing) inverted
index
ˆ Take in a query, determine which pages
match, and show the results (ranking and
display of results) Search
Inverted
engine
index
servers

2: Application Layer 45 2: Application Layer 46

Standard Web Search Engine Architecture

Check for duplicates,
crawl the store the
web documents
Crawler More detailed
DocIds architecture,
machines
from “Anatomy of a Large-
Scale Hypertext Web
Search Engine”, Brin &
Create an Page, 1998.
user inverted http://dbpubs.stanford.edu:8090/pub/1998-8

query index

Search
Inverted
Show results engine
index
To user servers

2: Application Layer 47 2: Application Layer 48

12
Spiders or crawlers Spider behaviour varies

ˆ How to find web pages to visit and copy? ˆ Parts of a web page that are indexed
™ Can start with a list of domain names, visit ˆ How deeply a site is indexed
the home pages there.
ˆ Types of files indexed
™ Look at the hyperlink on the home page, and
follow those links to more pages. ˆ How frequently the site is spidered
• Use HTTP commands to GET the pages
™ Keep a list of URLs visited, and those still to
be visited.
™ Each time the program loads in a new HTML
page, add the links in that page to the list to
be crawled.

Slide adapted from Lew & Davis2: Slide adapted from Lew & Davis2:
Application Layer Application Layer

Four Laws of Crawling Lots of tricky aspects

ˆ A Crawler must show identification ˆ Servers are often down or slow

ˆ Hyperlinks can get the crawler into cycles
ˆ A Crawler must obey the robots ˆ Some websites have junk in the web pages
exclusion standard ˆ Now many pages have dynamic content
http://www.robotstxt.org/wc/norobots.html ™ The “hidden” web
E.g., schedule.berkeley.edu
ˆ A Crawler must not hog resources
™
• You don’t see the course schedules until you run a
query.
ˆ A Crawler must report errors
ˆ The web is HUG

2: Application Layer 51 2: Application Layer 52

13
The Internet Is Enormous “Freshness”
ˆ Need to keep checking pages
™ Pages change (25%,7% large changes)
• At different frequencies
• Who is the fastest changing?
• Pages are removed
™ Many search engines cache the pages (store a
copy on their own servers)

Image from http://www.nature.com/nature/webmatters/tomog/tomfigs/fig1.html

2: Application Layer 53 2: Application Layer 54

What really gets crawled? ii. Index (the database)

ˆ A small fraction of the Web that search Record information about each page
engines know about; no search engine is ˆ List of words
exhaustive
™ In the title?
ˆ Not the “live” Web, but the search engine’s
™ How far down in the page?
index
™ Was the word in boldface?
ˆ Not the “Deep Web”
ˆ URLs of pages pointing to this one
ˆ Anchor text on pages pointing to this one
™ The anchor text summarizes what the
website is about.
™ <a href=http://web.njit… > CS 656 </a>

Slide adapted from Lew & Davis2: Slide adapted from Lew & Davis2:
Application Layer Application Layer

14
 Inverted Index Example
Inverted Index

ˆ How to store the words for fast lookup

ˆ Basic steps:
™ Make a “dictionary” of all the words in all of the web
pages
™ For each word, list all the documents it occurs in.
™ Often omit very common words
• “stop words”
™ Sometimes stem the words
• (also called morphological analysis)
• cats -> cat
• running -> run

2: Application Layer 57 Image from http://developer.apple.com 2: Application Layer 58

/documentation/UserExperience/Conceptual/SearchKitConcepts/searchKit_basics/chapter_2_section_2.html

Inverted Index Query Serving Architecture

“travel”

ˆ In reality, this index is HUGE

Index divided into segments
ˆ Need to store the contents across many
Load Balancer ˆ
“travel”
each served by a node
machines FE1 FE2 … FE8 … ˆ Each row of nodes replicated
for query load
ˆ Need to do optimization tricks to make “travel” ˆ Query integrator distributes
lookup fast. QI1 QI2 … QI8 … query and merges results
ˆ Front end creates a HTML
“travel” “travel” page with the query results

Node1,1 Node1,2 Node1,3 … Node1,N

Node2,1 Node2,2 Node2,3 … Node2,N

Node3,1 Node3,2 Node3,3 … Node3,N

2: Application Layer 59
Node4,1 Node4,2 Node4,3 … Node4,N
2: Application Layer 60

15
iii. Results ranking Some ranking criteria

ˆ Search engine receives a query, then

ˆ For a given candidate result page, use:
ˆ Looks up the words in the index, retrieves many ™ Number of matching query words in the page
documents, then ™ Proximity of matching words to one another
Location of terms within the page
ˆ Rank orders the pages and extracts “snippets” or ™
™ Location of terms within tags e.g. <title>, <h1>, link text, body
summaries containing query words. text
™ Most web search engines assume the user wants all of ™ Anchor text on pages pointing to this one
the words (Boolean AND, not OR). ™ Frequency of terms on the page and in general
Link analysis of which pages point to this one
ˆ These are complex and highly guarded algorithms ™
™ (Sometimes) Click-through analysis: how often the page is
unique to each search engine. clicked on
™ How “fresh” is the page
ˆ Complex formulae combine these together.

Slide adapted from Lew & Davis2: Slide adapted from Lew & Davis2:
Application Layer Application Layer

Measuring Importance of Measuring Importance of

Linking Linking
ˆ PageRank Algorithm ˆ Example: each page starts with 100
points.
™ Idea: important pages are pointed
ˆ Each page’s score is recalculated by
to by other important pages
adding up the score from each incoming
™ Method: link.
• Each link from one page to another is counted as a ™ This is the score of the linking page
“vote” for the destination page divided by the number of outgoing links it
• But the importance of the starting page also has.
influences the importance of the destination page. ™ E.g, the page in green has 2 outgoing links
and so its “points” are shared evenly by
• And those pages scores, in turn, depend on those
the 2 pages it links to.
linking to them.
ˆ Keep repeating the score updates until
no more changes.

2: Application Layer
Image and explanation from http://www.economist.com/science/tq/displayStory.cfm?story_id=3172188
63 2: Application Layer 64
Image and explanation from http://www.economist.com/science/tq/displayStory.cfm?story_id=3172188

16
Search Engine Information Acknowledgement
ˆ www.searchenginewatch.com ˆ Slides about web searching are adapted
ˆ www.searchenginejournal.com from the slides authored by Dr. Marti
ˆ www.searchengineshowdown.com Hearst.
ˆ http://battellemedia.com
ˆ http://jeremy.zawodny.com/blog/

2: Application Layer 65 2: Application Layer 66

17