Network Traffic on Web (PDF)

Some network apps  social networking  voice over IP (e.g.,  Web Skype)  text messaging  real-time video  conferencing e-mail  Internet search  multi-user network games...

Some network apps  social networking  voice over IP (e.g.,  Web Skype)  text messaging  real-time video  conferencing e-mail  Internet search  multi-user network games  remote login  streaming stored video … (YouTube, Hulu, Netflix) Q: your favorites?  P2P file sharing Application Layer: 2-1 Material is taken from Computer networking: A top down approach 8th edition Application Layer: 2-2 What transport service does an app need? data integrity throughput  some apps (e.g., file  some apps (e.g., transfer, web multimedia) require transactions) require minimum amount of 100% reliable data throughput to be transfer “effective”  other apps (e.g., audio)  other apps (“elastic can tolerate some loss timing apps”) make use of whatever throughput  some apps (e.g., Internet security they get telephony, interactive  encryption, data games) require low delay to integrity, … be “effective” Application Layer: 2-3  Transport service requirements: common apps applicationdata loss throughput time sensitive? file transfer/downloadno loss elastic e-mailno loss elastic no Web documentsno loss elastic no real-time audio/videoloss-tolerant audio: 5Kbps- no 1Mbps yes, 10’s msec streaming audio/videoloss-tolerant video:10Kbps- interactive gamesloss-tolerant 5Mbps yes, few secs text messagingno loss same as above yes, 10’s msec Kbps+ yes and no Application Layer: 2-4 Internet transport protocols services TCP service: UDP service:  reliable transport between  unreliable data transfer sending and receiving process between sending and  flow control: sender won’t receiving process overwhelm receiver  does not provide:  congestion control: throttle reliability, flow control, sender when network congestion control, overloaded timing, throughput guarantee, security, or  does not provide: timing, connection setup. minimum throughput Q: why bother? guarantee, security Why is there a  connection-oriented: setup UDP? Application Layer: 2-5  Internet transport protocols services 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 TCP or UDP [RFC 3550], or streaming audio/video proprietary HTTP TCP interactive games [RFC 7320], DASH UDP or TCP WOW, FPS (proprietary) Application Layer: 2-6 Application layer: overview  P2P applications  Principles of network  video streaming and applications content distribution  Web and HTTP networks  E-mail, SMTP, IMAP  socket programming  The Domain Name with UDP and TCP System DNS Application Layer: 2-7 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 www.someschool.edu/someDept/pic.gif addressable by a URL, e.g., host name path name Application Layer: 2-8 HTTP overview HTTP: hypertext transfer protocol  Web’s application layer HT TP req ues PC running H protocol Firefox browser TTP res t  client/server model: pon se client: browser that es t u requests, receives, (using req e T TP o ns server running H p HTTP protocol) and TP res Apache Web T server “displays” Web objects H server: Web server sends iPhone running (using HTTP protocol) Safari browser objects in response to requests Application Layer: 2-9 HTTP overview (continued) HTTP uses TCP: HTTP is “stateless”  client initiates TCP  server maintains no connection (creates socket) information about past to server, port 80 client requests  server accepts TCP aside connection from client protocols that maintain  HTTP messages “state” are complex!  past history (state) must be (application-layer protocol maintained messages) exchanged  if server/client crashes, their between browser (HTTP views of “state” may be client) and Web server inconsistent, must be (HTTP server) reconciled  TCP connection closed Application Layer: 2-10 HTTP connections: two types Non-persistent HTTP Persistent HTTP 1. TCP connection  TCP connection opened opened to a server 2. at most one object  multiple objects can sent over TCP be sent over single connection TCP connection 3. TCP connection between client, and closed that server  TCP connection downloading multiple closed objects required Application Layer: 2-11  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 waiting for www.someSchool.edu on port TCP connection at port 80 80 “accepts” connection, notifying 2. HTTP client sends HTTP client request message (containing URL) into 3. HTTP server receives request TCP connection socket. message, forms response time Message indicates that message containing requested client wants object object, and sends message into someDepartment/home.inde its socket Application Layer: 2-12  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 5. HTTP client receives TCP connection. response message containing html file, displays html. Parsing html file, finds 10 referenced jpeg objects 6. Steps 1-5 repeated for each of 10 jpeg time objects Application Layer: 2-13 Non-persistent HTTP: response time RTT (definition): time for a small packet to travel from client to server and back initiate TCP connection HTTP response time (per RTT object): request file  one RTT to initiate TCP RTT time to connection transmit  one RTT for HTTP request and file file first few bytes of HTTP response received to return  obect/file transmission time time time Non-persistent HTTP response time = 2RTT+ file transmission time Application Layer: 2-14 Persistent HTTP (HTTP 1.1) Non-persistent HTTP Persistent HTTP (HTTP1.1): issues:  server leaves connection  requires 2 RTTs per object open after sending response  OS overhead for each TCP  subsequent HTTP messages connection between same client/server  browsers often open sent over open connection multiple parallel TCP  client sends requests as connections to fetch soon as it encounters a referenced objects in referenced object parallel  as little as one RTT for all the referenced objects (cutting response time in half) Application Layer: 2-15  HTTP request message  two types of HTTP messages: request, response  HTTP request message: ASCII (human-readable format) carriage return character line-feed character request line (GET, GET /index.html HTTP/1.1\r\n POST, Host: www-net.cs.umass.edu\r\n HEAD commands) User-Agent: Firefox/3.6.10\r\n Accept: text/html,application/xhtml+xml\r\n headerAccept-Language: en-us,en;q=0.5\r\n linesAccept-Encoding: gzip,deflate\r\n Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n Keep-Alive: 115\r\n Connection: keep-alive\r\n carriage return, line \r\n feed at start of line indicates end of * Check out the online interactive exercises for more header lines examples: http://gaia.cs.umass.edu/kurose_ross/interactive/ Application Layer: 2-16 HTTP request message: general format method sp URL sp version cr lf request line header field name value cr lf header ~ ~ ~ ~ lines header field name value cr lf cr lf ~ ~ entity body ~ ~ body Application Layer: 2-17 Other HTTP request messages POST method: HEAD method:  web page often includes  requests headers (only) form input that would be returned if  user input sent from client specified URL were to server in entity body of requested with an HTTP HTTP POST request GET method. message PUT method:  uploads new file (object) to GET method (for sending data to server server):  completely replaces file  include user data in URL field of that exists at specified URL HTTP GET request message www.somesite.com/animalsearch?monkeys&banana with content in entity body (following a ‘?’): of POST HTTP request message Application Layer: 2-18 HTTP response message status line (protocol HTTP/1.1 200 OK\r\n status code status Date: Sun, 26 Sep 2010 20:09:20 GMT\r\n Server: Apache/2.0.52 (CentOS)\r\n phrase) Last-Modified: Tue, 30 Oct 2007 17:00:02 GMT\r\n header ETag: "17dc6-a5c-bf716880"\r\n Accept-Ranges: bytes\r\n lines Content-Length: 2652\r\n Keep-Alive: timeout=10, max=100\r\n Connection: Keep-Alive\r\n Content-Type: text/html; charset=ISO-8859-1\ r\n \r\n data, e.g., requested data data data data data... HTML file * Check out the online interactive exercises for more examples: h ttp://gaia.cs.umass.edu/kurose_ross/interactive/ Application Layer: 2-19 HTTP response status codes  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 Application Layer: 2-20 Maintaining user/server state: cookies a stateful protocol: client Recall: HTTP makes two changes to X, GET/response interaction or none at all is stateless X  no notion of multi-step lock dat record X a X exchanges of HTTP messages up d a t e OK to complete a Web X’ X X’ “transaction” t’ up d a t e OK X no need for client/server to X’’ X’ OK track “state” of multi-step unlock X ’ exchange OK X’’ all HTTP requests are time time independent of each other Q: what happens if network no need for client/server to connection or client crashes at t’ ? “recover” from a partially- Application Layer: 2-21 Maintaining user/server state: cookies Web sites and client browser Example: use cookies to maintain  Susan uses browser on laptop, visits specific e- some state between commerce site for first transactions time  when initial HTTP four components: requests arrives at site, 1) cookie header line of HTTP site creates: response message unique ID (aka 2) cookie header line in next “cookie”) HTTP request message entry in backend 3) cookie file kept on user’s database for ID host, managed by user’s subsequent HTTP browser requests from Susan to this site will contain Application Layer: 2-22 Maintaining user/server state: cookies client server ebay 8734 usual HTTP request Amazon server cookie file msg creates ID usual HTTP 1678 for user create backend ebay 8734 response entry database amazon set-cookie: 1678 1678 usual HTTP request msg cookie- access cookie: 1678 specific usual HTTP response action msg one week later: access ebay 8734 usual HTTP request amazon msg cookie- 1678 cookie: 1678 specific usual HTTP response action time msg time Application Layer: 2-23 HTTP cookies: comments aside What cookies can be used for: cookies and privacy:  authorization  cookies permit sites  shopping carts to learn a lot about  recommendations you on their site.  third party persistent  user session state (Web e-mail) cookies (tracking cookies) allow common identity Challenge: How to keep state: (cookie value) to be  protocol endpoints: maintain state at tracked across sender/receiver over multiple multiple web sites transactions  cookies: HTTP messages carry state Application Layer: 2-24 Web caches (proxy servers) Goal: satisfy client request without involving origin  user server configures browser to point to a Web cache proxy HT st  browser sends all HTTP TP req server req u e HT ues T P se requests to cache client TP res t H T res p o n origin pon if object in cache: se t HT TP server u es cache returns object P req nse to client HT T s po e Pr else cache requests HT T object from origin client server, caches origin server received object, then returns object to client Application Layer: 2-25 Conditional GET client server Goal: don’t send object if HTTP request msg cache has up-to-date cached If-modified-since: object version not modified no object transmission delay HTTP response before HTTP/1.0 lower link utilization 304 Not Modified  cache: specify date of cached copy in HTTP request HTTP request msg If-modified-since: object If-modified-since: modified  server: response contains HTTP response after HTTP/1.0 200 OK no object if cached copy is up-to-date: Application Layer: 2-26 DNS: Domain Name System people: many identifiers: Domain Name System: SSN, name, passport  distributed database # implemented in hierarchy of Internet hosts, routers: many name servers IP address (32 bit) - used  application-layer protocol: for addressing datagrams hosts, name servers “name”, e.g., communicate to resolve cs.umass.edu - used by names (address/name humans translation) Q: how to map between note: core Internet function, IP address and name, and vice versa ? implemented as application- layer protocol complexity at network’s Application Layer: 2-27 DNS: services, structure DNS services Q: Why not centralize  hostname to IP address DNS? translation  single point of failure  host aliasing  traffic volume canonical, alias names  distant centralized database  mail server aliasing A: doesn‘t scale!  maintenance  load distribution  Comcast DNS replicated Web servers: servers alone: 600B many IP addresses DNS queries per day correspond to one name Application Layer: 2-28  DNS: a distributed, hierarchical database 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 Client wants IP address for www.amazon.com; 1st approximation:  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-29 DNS: root name servers  official, contact-of-last- resort by name servers 13 logical root name “servers” worldwide each “server” that can not resolve name replicated many times (~200  incredibly important servers in US) Internet function Internet couldn’t function without it! DNSSEC – provides security (authentication and message integrity)  ICANN (Internet Corporation for Assigned Names and Numbers) manages root DNS domain Application Layer: 2-30 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.:.cn,.uk,.fr,.ca,.jp  Network Solutions: authoritative registry for.com,.net TLD  Educause:.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-31 Local DNS name servers  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-32 DNS name resolution: iterated query root DNS server Example: host at engineering.nyu.edu wants IP 2 address for gaia.cs.umass.edu 3 TLD DNS server Iterated query: 1 4  contacted server 8 5 replies with name requesting host at local DNS server of server to contact engineering.nyu.edu dns.nyu.edu gaia.cs.umass.edu  “I don’t know this 7 6 name, but ask this server” authoritative DNS server dns.cs.umass.edu Application Layer: 2-33 DNS name resolution: recursive query root DNS server Example: host at engineering.nyu.edu wants IP 2 3 address for gaia.cs.umass.edu 7 6 Recursive query: 1 TLD DNS server  puts burden of 8 name resolution requesting host at local DNS server 5 4 engineering.nyu.edu dns.nyu.edu on contacted gaia.cs.umass.edu name server  heavy load at authoritative DNS server upper levels of dns.cs.umass.edu hierarchy? Application Layer: 2-34 Caching, Updating DNS 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 Application Layer: 2-35 DNS records DNS: distributed database storing resource records (RR)RR format: (name, value, type, ttl) type=A type=CNAME  name is hostname  name is alias name for some  value is IP address “canonical” (the real) name  www.ibm.com is really type=NS servereast.backup2.ibm.com  value is canonical name  name is domain (e.g., foo.com) type=MX  value is hostname of  value is name of mailserver authoritative name server associated with name for this domain Application Layer: 2-36 DNS protocol messages DNS query and reply messages, both have same format: 2 bytes 2 bytes identification flags message header:  identification: 16 bit # for # questions # answer RRs query, reply to query uses # authority RRs # additional RRs same #  flags: questions (variable # of questions) query or reply answers (variable # of RRs) recursion desired recursion available authority (variable # of RRs) reply is authoritative additional info (variable # of RRs) Application Layer: 2-37 DNS protocol messages DNS query and reply messages, both have same format: 2 bytes 2 bytes identification flags # questions # answer RRs # authority RRs # additional RRs name, type fields for a questions (variable # of questions) query RRs in response to query answers (variable # of RRs) records for authoritative authority (variable # of RRs) servers additional “ helpful” info additional info (variable # of RRs) that may be used Application Layer: 2-38 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 NS, A RRs into.com TLD server: (networkutopia.com, dns1.networkutopia.com, NS) (dns1.networkutopia.com, 212.212.212.1, A)  create authoritative server locally with IP address 212.212.212.1 type A record for www.networkuptopia.com type MX record for networkutopia.com Application Layer: 2-39 DNS security DDoS attacks Redirect attacks  bombard root servers  man-in-middle with traffic intercept DNS queries not successful to date  DNS poisoning traffic filtering send bogus relies to DNS DNSSE local DNS servers cache IPs server, which caches C of TLD servers, allowing Exploit DNS for DDoS [RFC root server bypass  send queries with 4033]  bombard TLD servers spoofed source potentially more dangerous address: target IP  requires amplification Application Layer: 2-40