lecture 3: web continued application layer 2-1. outline network basics: http protocols studies on...
TRANSCRIPT
Lecture 3: Web Continued
Application Layer 2-1
Outline
Network basics: HTTP protocols
Studies on HTTP performance from different views: Browser types [NSDI 2014] Cellular Networks [IMC 2012] ,[MOBICOM 2014] Home [IMC 2013] Search Provider [SIGCOMM 2013]
Network Measurement fundamentals: Decision Tree (one popular machine learning
tool)
Application Layer 2-2
Suggested project ideas (1) How quick is QUIC? Your task is to use NSDI2014-SPDY
paper’s testbed experiment methodology, evaluate how QUIC helps SPDY in various scenarios. http://en.wikipedia.org/wiki/QUIC
Mentor: Ruming Tang [email protected]
Application Layer 2-3
Suggested project ideas (II) We already have an OpenWrt-based tool which
measures the wireless interference between neighboring APs. This project is similar to
http://pages.cs.wisc.edu/~suman/pubs/coap-infocom15.pdf
(To be covered in week 5) Your task is to build an Android/IOS/HTML5 App
which can a. visualize and analyze the results from the above
tool. b. add basic admin functions to the App for the
OpenWRT based router. Some sample code:https://forum.openwrt.org/viewtopic.php?id=35574Mentor: Changhua Pei [email protected]
2-4
Suggested Project Ideas (III)• Build a real-time heat map for the
Campus WiFi. • Mentor: Kaixin [email protected]
5
Suggested Project Ideas (IV)• We have the rough location
information for each device every 3 minutes.
• Build a mobility model based on Campus WiFi data– Movement frequency distribution– Inter-movement time distribution– Migration Pattern
– Mentor: Kaixin Sui [email protected]
Suggested Project Ideas (V)• Anomaly Detection Based on
WiFi Usage data
• Detecting abnormal behavior by applying some existing anomaly detection algorithms (with existing implementation code)
• Mentor: Dapeng Liu• [email protected]
.cn
7
Application Layer 2-8
DNS: domain name system
people: many identifiers: SSN, name,
passport #Internet hosts, routers:
IP address (32 bit) - used for addressing datagrams
“name”, e.g., www.yahoo.com - used by humans
Q: how to map between IP address and name, and vice versa ?
Domain Name System: distributed database
implemented in hierarchy of many name servers
application-layer protocol: hosts, name servers communicate to resolve names (address/name translation) note: core Internet
function, implemented as application-layer protocol
complexity at network’s “edge”
Application Layer 2-9
DNS: services, structure why not centralize DNS? single point of failure traffic volume distant centralized
database maintenance
DNS services hostname to IP
address translation host aliasing
canonical, alias names
mail server aliasing load distribution
replicated Web servers: many IP addresses correspond to one name
A: doesn’t scale!
Application Layer 2-10
Root DNS Servers
com DNS servers org DNS servers edu DNS servers
poly.eduDNS servers
umass.eduDNS servers
yahoo.comDNS servers
amazon.comDNS servers
pbs.orgDNS servers
DNS: a distributed, hierarchical database
client wants IP for www.amazon.com; 1st approx: 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
… …
Application Layer 2-11
DNS: root name servers contacted by local name server that can not
resolve name root name server:
contacts authoritative name server if name mapping not known
gets mapping returns mapping to local name server
13 root name “servers” worldwide
a. Verisign, Los Angeles CA (5 other sites)b. USC-ISI Marina del Rey, CAl. ICANN Los Angeles, CA (41 other sites)
e. NASA Mt View, CAf. Internet Software C.Palo Alto, CA (and 48 other sites)
i. Netnod, Stockholm (37 other sites)
k. RIPE London (17 other sites)
m. WIDE Tokyo(5 other sites)
c. Cogent, Herndon, VA (5 other sites)d. U Maryland College Park, MDh. ARL Aberdeen, MDj. Verisign, Dulles VA (69 other sites )
g. US DoD Columbus, OH (5 other sites)
Application Layer 2-12
TLD, authoritative servers
top-level domain (TLD) servers: responsible for com, org, net, edu, aero, jobs,
museums, and all top-level country domains, e.g.: uk, fr, ca, jp
Network Solutions maintains servers for .com TLD
Educause for .edu TLD
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
Application Layer 2-13
Local DNS name server
does not strictly belong to hierarchy each ISP (residential ISP, company,
university) has one also called “default name server”
when host makes DNS query, query is sent to its local DNS server has local cache of recent name-to-address
translation pairs (but may be out of date!) acts as proxy, forwards query into hierarchy
Application Layer 2-14
requesting hostcis.poly.edu
gaia.cs.umass.edu
root DNS server
local DNS serverdns.poly.edu
1
23
4
5
6
authoritative DNS serverdns.cs.umass.edu
78
TLD DNS server
DNS name resolution example
host at cis.poly.edu wants IP address for gaia.cs.umass.edu
iterated query: contacted server
replies with name of server to contact
“I don’t know this name, but ask this server”
Application Layer 2-15
45
6
3
recursive query: puts burden of
name resolution on contacted name server
heavy load at upper levels of hierarchy?
requesting hostcis.poly.edu
gaia.cs.umass.edu
root DNS server
local DNS serverdns.poly.edu
1
27
authoritative DNS serverdns.cs.umass.edu
8
DNS name resolution example
TLD DNS server
Application Layer 2-16
DNS: caching, updating records once (any) name server learns mapping, it
caches mapping cache entries timeout (disappear) after some
time (TTL) TLD servers typically cached in local name
servers• thus root name servers not often visited
cached entries may be out-of-date (best effort name-to-address translation!) if name host changes IP address, may not be
known Internet-wide until all TTLs expire update/notify mechanisms proposed IETF
standard RFC 2136
Application Layer 2-17
DNS records
DNS: distributed db storing resource records (RR)
type=NS name is domain (e.g.,
foo.com) value is hostname of
authoritative name server for this domain
RR format: (name, value, type, ttl)
type=A name is hostname value is IP address
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
type=MX value is name of
mailserver associated with name
Application Layer 2-18
DNS protocol, messages query and reply messages, both with same message format
msg header identification: 16 bit #
for query, reply to query uses same #
flags: query or reply recursion desired recursion available reply is authoritative
identification flags
# questions
questions (variable # of questions)
# additional RRs# authority RRs
# answer RRs
answers (variable # of RRs)
authority (variable # of RRs)
additional info (variable # of RRs)
2 bytes 2 bytes
Application Layer 2-19
name, type fields for a query
RRs in responseto queryrecords for
authoritative servers
additional “helpful”info that may be used
identification flags
# questions
questions (variable # of questions)
# additional RRs# authority RRs
# answer RRs
answers (variable # of RRs)
authority (variable # of RRs)
additional info (variable # of RRs)
DNS protocol, messages
2 bytes 2 bytes
Application Layer 2-20
Inserting records into DNS
example: new startup “Network Utopia” register name networkuptopia.com at DNS
registrar (e.g., Network Solutions) provide names, IP addresses of authoritative
name server (primary and secondary) registrar inserts two RRs into .com TLD server:(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A) create authoritative server type A record for
www.networkuptopia.com; type MX record for networkutopia.com
Transport Layer 3-21
Connection Managementbefore exchanging data, sender/receiver
“handshake”: agree to establish connection (each knowing the
other willing to establish connection) agree on connection parameters
connection state: ESTABconnection variables:
seq # client-to-server server-to-clientrcvBuffer size at server,client
application
network
connection state: ESTABconnection Variables:
seq # client-to-server server-to-clientrcvBuffer size at server,client
application
network
Socket clientSocket =
newSocket("hostname","port number");
Socket connectionSocket = welcomeSocket.accept();
Transport Layer 3-22
Q: will 2-way handshake always work in network?
variable delays retransmitted messages
(e.g. req_conn(x)) due to message loss
message reordering can’t “see” other side
2-way handshake:
Let’s talk
OKESTAB
ESTAB
choose xreq_conn(x)
ESTAB
ESTABacc_conn(x)
Agreeing to establish a connection
Transport Layer 3-23
Agreeing to establish a connection
2-way handshake failure scenarios:
retransmitreq_conn(
x)
ESTAB
req_conn(x)
half open connection!(no client!)
client terminat
es
serverforgets x
connection x completes
retransmitreq_conn(
x)
ESTAB
req_conn(x)
data(x+1)
retransmitdata(x+1)
acceptdata(x+1)
choose xreq_conn(x)
ESTAB
ESTAB
acc_conn(x)
client terminat
es
ESTAB
choose xreq_conn(x)
ESTAB
acc_conn(x)
data(x+1) acceptdata(x+1)
connection x completes server
forgets x
Transport Layer 3-24
TCP 3-way handshake
SYNbit=1, Seq=x
choose init seq num, xsend TCP SYN msg
ESTAB
SYNbit=1, Seq=yACKbit=1; ACKnum=x+1
choose init seq num, ysend TCP SYNACKmsg, acking SYN
ACKbit=1, ACKnum=y+1
received SYNACK(x) indicates server is live;send ACK for SYNACK;
this segment may contain client-to-server data received ACK(y)
indicates client is live
SYNSENT
ESTAB
SYN RCVD
client state
LISTEN
server state
LISTEN
Transport Layer 3-25
TCP segment structure
source port # dest port #
32 bits
application
data
(variable length)
sequence number
acknowledgement number
receive window
Urg data pointerchecksum
FSRPAUhead
len
not
used
options (variable length)
URG: urgent data
(generally not used)
ACK: ACK #
valid
PSH: push data now
(generally not used)
RST, SYN, FIN:
connection estab
(setup, teardown
commands)
# bytes
rcvr willing
to accept
counting
by bytes
of data
(not segments!)
Internet
checksum
(as in UDP)
Transport Layer 3-26
TCP congestion control: additive increase multiplicative decrease
approach: sender increases transmission rate (window size), probing for usable bandwidth, until loss occurs additive increase: increase cwnd by 1
MSS every RTT until loss detected multiplicative decrease: cut cwnd in half
after loss
cwnd:
TC
P s
ende
r
cong
estio
n w
indo
w s
ize
AIMD saw tooth
behavior: probing
for bandwidth
additively increase window size ……. until loss occurs (then cut window in half)
time
The RRC State Machine for UMTS Network State promotions have promotion delay State demotions incur tail times
Tail Time
Tail Time
Delay: 1.5sDelay: 2s
Channel Radio Power
IDLE Not allocated
Almost zero
CELL_FACH Shared, Low Speed
Low
CELL_DCH Dedicated, High
Speed
High
Page 27
A Network can be really complex: e.g. Cellular E2E Cross-layer Topology