Week 1.pdf

Internet Architecture TCP/IP Protocol Suite IPC - Concept of Socket HTTP 1.1, 2 and 3 Cookies Web Caching Computer Networking: A Top-Down Approach 8th edition Jim Kurose, Keith Ross...

Internet Architecture TCP/IP Protocol Suite IPC - Concept of Socket HTTP 1.1, 2 and 3 Cookies Web Caching Computer Networking: A Top-Down Approach 8th edition Jim Kurose, Keith Ross Pearson, 2020 Introduction: 1-1 A closer look at Internet structure mobile network Network edge: national or global ISP ▪ hosts: clients and servers ▪ servers often in data centers local or regional ISP home network content provider network datacenter network enterprise network Introduction: 1-2 A closer look at Internet structure mobile network Network edge: national or global ISP ▪ hosts: clients and servers ▪ servers often in data centers local or Access networks, physical media: regional ISP ▪ wired, wireless communication home network content provider links network datacenter network enterprise network Introduction: 1-3 A closer look at Internet structure mobile network Network edge: national or global ISP ▪ hosts: clients and servers ▪ servers often in data centers local or Access networks, physical media: regional ISP ▪ wired, wireless communication home network content provider links network datacenter network Network core: ▪ interconnected routers enterprise network ▪ network of networks Introduction: 1-4 Protocol “layers” and reference models Networks are complex, with many “pieces”: ▪ hosts ▪ routers ▪ links of various media ▪ applications ▪ protocols ▪ hardware, software Introduction: 1-5  ISO/OSI reference model Two layers not found in Internet application protocol stack! presentation ▪ presentation: allow applications to interpret meaning of data, e.g., encryption, session compression, machine-specific conventions transport ▪ session: synchronization, checkpointing, network recovery of data exchange link ▪ Internet stack “missing” these layers! physical these services, if needed, must be implemented in application The seven layer OSI/ISO reference model needed? Introduction: 1-6 Layered TCP/IP stack ▪ application: supporting network applications HTTP, IMAP, SMTP, DNS application application ▪ transport: process-process data transfer TCP, UDP transport transport ▪ network: routing of datagrams from source to destination network IP, routing protocols ▪ link: data transfer between neighboring network link elements physical Ethernet, 802.11 (WiFi), PPP ▪ physical: bits “on the wire” Introduction: 1-7 Why layering? Approach to designing/discussing complex systems: ▪ explicit structure allows identification, relationship of system’s pieces layered reference model for discussion ▪ modularization eases maintenance, updating of system change in layer's service implementation: transparent to rest of system e.g., change in gate procedure doesn’t affect rest of system Introduction: 1-8  Services, Layering and Encapsulation M application Application exchanges messages to implement some application application service using services of transport layer H M transport t Transport-layer protocol transfers M (e.g., reliably) from transport one process to another, using services of network layer network ▪ transport-layer protocol encapsulates network application-layer message, M, with link transport layer-layer header Ht to create a link transport-layer segment Ht used by transport layer protocol to physical implement its service physical source destination Introduction: 1-9  Services, Layering and Encapsulation M application application H M transport t Transport-layer protocol transfers M (e.g., reliably) from transport one process to another, using services of network layer H H network n t M network Network-layer protocol transfers transport-layer segment [Ht | M] from one host to another, using link layer services link link ▪ network-layer protocol encapsulates transport-layer segment [Ht | M] with physical network layer-layer header Hn to create a physical network-layer datagram source Hn used by network layer protocol to destination implement its service Introduction: 1-10  Services, Layering and Encapsulation M application application H M transport t transport H H network n t M network Network-layer protocol transfers transport-layer segment [Ht | M] from one host to another, using link layer services H H H link M link n t Link-layer protocoll transfers datagram [Hn| [Ht |M] from host to neighboring host, using network-layer services physical physical ▪ link-layer protocol encapsulates network datagram [Hn| [Ht |M], with link-layer source header Hl to create a link-layer frame destination Introduction: 1-11  Services, Layering and Encapsulation M application M application message H M transport t H M transport t segment H H H H network n t M n t M network datagram H H H H H H link M l n t M link l n t frame physical physical source destination Introduction: 1-12  message M source application Encapsulation: an segment datagram H H H t M transport network end-end view M H H n H t frame M link l n t physical link physical switch H H destination M network H nH H t H H M application M link M H l n t n t M transport physical H H t M network H H n H t M link router l n t physical Introduction: 1-13 “Real” Internet delays and routes ▪ what do “real” Internet delay & loss look like? ▪ traceroute program: provides delay measurement from source to router along end-end Internet path towards destination. For all i: sends three packets that will reach router i on path towards destination (with time-to-live field value of i) router i will return packets to sender sender measures time interval between transmission and reply 3 probes 3 probes 3 probes Introduction: 1-14 Real Internet delays and routes traceroute: gaia.cs.umass.edu to www.eurecom.fr 3 delay measurements from gaia.cs.umass.edu to cs-gw.cs.umass.edu 1 cs-gw (128.119.240.254) 1 ms 1 ms 2 ms 3 delay measurements 2 border1-rt-fa5-1-0.gw.umass.edu (128.119.3.145) 1 ms 1 ms 2 ms 3 cht-vbns.gw.umass.edu (128.119.3.130) 6 ms 5 ms 5 ms to border1-rt-fa5-1-0.gw.umass.edu 4 jn1-at1-0-0-19.wor.vbns.net (204.147.132.129) 16 ms 11 ms 13 ms 5 jn1-so7-0-0-0.wae.vbns.net (204.147.136.136) 21 ms 18 ms 18 ms 6 abilene-vbns.abilene.ucaid.edu (198.32.11.9) 22 ms 18 ms 22 ms 7 nycm-wash.abilene.ucaid.edu (198.32.8.46) 22 ms 22 ms 22 ms trans-oceanic link 8 62.40.103.253 (62.40.103.253) 104 ms 109 ms 106 ms 9 de2-1.de1.de.geant.net (62.40.96.129) 109 ms 102 ms 104 ms 10 de.fr1.fr.geant.net (62.40.96.50) 113 ms 121 ms 114 ms looks like delays 11 renater-gw.fr1.fr.geant.net (62.40.103.54) 112 ms 114 ms 112 ms 12 nio-n2.cssi.renater.fr (193.51.206.13) 111 ms 114 ms 116 ms decrease! Why? 13 nice.cssi.renater.fr (195.220.98.102) 123 ms 125 ms 124 ms 14 r3t2-nice.cssi.renater.fr (195.220.98.110) 126 ms 126 ms 124 ms 15 eurecom-valbonne.r3t2.ft.net (193.48.50.54) 135 ms 128 ms 133 ms 16 194.214.211.25 (194.214.211.25) 126 ms 128 ms 126 ms 17 * * * 18 * * * * means no response (probe lost, router not replying) 19 fantasia.eurecom.fr (193.55.113.142) 132 ms 128 ms 136 ms * Do some traceroutes from exotic countries at www.traceroute.org Introduction: 1-15 Application Layer Protocol - HTTP Application Layer: 2-16 Processes communicating process: program running clients, within a host servers client process: process that initiates communication ▪ within same host, two server process: process processes communicate that waits to be contacted using inter-process communication (defined by OS) ▪ note: applications with P2P architectures have ▪ processes in different hosts client processes & communicate by exchanging server processes messages Application Layer: 2-17 Sockets ▪ process sends/receives messages to/from its socket ▪ socket analogous to door sending process shoves message out door sending process relies on transport infrastructure on other side of door to deliver message to socket at receiving process two sockets involved: one on each side application application proce socket proce controlled by ss ss app developer transport transport network network controlled link by OS link Internet physical physical Application Layer: 2-18 Addressing processes ▪ to receive messages, process ▪ identifier includes both IP address must have identifier and port numbers associated with ▪ host device has unique 32-bit process on host. IP address ▪ example port numbers: ▪ Q: does IP address of host on HTTP server: 80 which process runs suffice for mail server: 25 identifying the process? ▪ to send HTTP message to ▪ A: no, many processes gaia.cs.umass.edu web server: can be running on IP address: 128.119.245.12 same host port number: 80 ▪ more shortly… Application Layer: 2-19 An application-layer protocol defines: ▪ types of messages exchanged, open protocols: e.g., request, response ▪ defined in RFCs, everyone ▪ message syntax: has access to protocol what fields in messages & definition how fields are delineated ▪ allows for interoperability ▪ message semantics ▪ e.g., HTTP, SMTP meaning of information in proprietary protocols: fields ▪ e.g., Skype, Zoom ▪ rules for when and how processes send & respond to messages Application Layer: 2-20 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 addressable by a URL, e.g., www.someschool.edu/someDept/pic.gif host name path name Application Layer: 2-21 HTTP overview HTTP: hypertext transfer protocol ▪ Web’s application-layer protocol ▪ client/server model: PC running client: browser that requests, Firefox browser receives, (using HTTP protocol) and “displays” Web objects server: Web server sends (using server running Apache Web HTTP protocol) objects in response server to requests iPhone running Safari browser Application Layer: 2-22 HTTP overview (continued) HTTP uses TCP: HTTP is “stateless” ▪ client initiates TCP connection ▪ server maintains no (creates socket) to server, port 80 information about past client ▪ server accepts TCP connection requests from client aside ▪ HTTP messages (application-layer protocols that maintain “state” are complex! protocol messages) exchanged ▪ past history (state) must be between browser (HTTP client) and maintained Web server (HTTP server) ▪ if server/client crashes, their views ▪ TCP connection closed of “state” may be inconsistent, must be reconciled Application Layer: 2-23 HTTP connections: two types Non-persistent HTTP Persistent HTTP 1. TCP connection opened ▪ TCP connection opened to 2. at most one object sent a server over TCP connection ▪ multiple objects can be 3. TCP connection closed sent over single TCP connection between client, downloading multiple and that server objects required multiple ▪ TCP connection closed connections Application Layer: 2-24  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 on www.someSchool.edu waiting for TCP port 80 connection at port 80 “accepts” connection, notifying client 2. HTTP client sends HTTP request message (containing URL) into TCP connection 3. HTTP server receives request message, socket. Message indicates forms response message containing time that client wants object requested object, and sends message someDepartment/home.index into its socket Application Layer: 2-25  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 TCP 5. HTTP client receives response connection. message containing html file, displays html. Parsing html file, finds 10 referenced jpeg objects 6. Steps 1-5 repeated for each of 10 jpeg objects time Application Layer: 2-26 Non-persistent HTTP: response time RTT (definition): time for a small packet to travel from client to initiate TCP server and back connection RTT HTTP response time (per object): ▪ one RTT to initiate TCP connection request file ▪ one RTT for HTTP request and first few RTT time to transmit bytes of HTTP response to return file file received ▪ object/file transmission time time time Non-persistent HTTP response time = 2RTT+ file transmission time Application Layer: 2-27 Persistent HTTP (HTTP 1.1) Non-persistent HTTP issues: Persistent HTTP (HTTP1.1): ▪ requires 2 RTTs per object ▪ server leaves connection open after ▪ OS overhead for each TCP sending response connection ▪ subsequent HTTP messages ▪ browsers often open multiple between same client/server sent parallel TCP connections to over open connection fetch referenced objects in ▪ client sends requests as soon as it parallel encounters a referenced object ▪ as little as one RTT for all the referenced objects (cutting response time in half) Application Layer: 2-28  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: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:80.0) Gecko/20100101 Firefox/80.0 \r\n header Accept: text/html,application/xhtml+xml\r\n lines Accept-Language: en-us,en;q=0.5\r\n Accept-Encoding: gzip,deflate\r\n Connection: keep-alive\r\n \r\n carriage return, line feed at start of line indicates end of header lines * Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/ Application Layer: 2-29 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-30 Other HTTP request messages POST method: HEAD method: ▪ web page often includes form ▪ requests headers (only) that input would be returned if specified ▪ user input sent from client to URL were requested with an server in entity body of HTTP HTTP GET method. POST request message PUT method: ▪ uploads new file (object) to server GET method (for sending data to server): ▪ completely replaces file that ▪ include user data in URL field of HTTP exists at specified URL with GET request message (following a ‘?’): content in entity body of POST www.somesite.com/animalsearch?monkeys&banana HTTP request message Application Layer: 2-31 HTTP response message status line (protocol HTTP/1.1 200 OK status code status phrase) Date: Tue, 08 Sep 2020 00:53:20 GMT Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/7.4.9 mod_perl/2.0.11 Perl/v5.16.3 header Last-Modified: Tue, 01 Mar 2016 18:57:50 GMT lines ETag: "a5b-52d015789ee9e" Accept-Ranges: bytes Content-Length: 2651 Content-Type: text/html; charset=UTF-8 \r\n data, e.g., requested data data data data data... HTML file * Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/ Application Layer: 2-32 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-33 Maintaining user/server state: cookies a stateful protocol: client makes Recall: HTTP GET/response two changes to X, or none at all interaction is stateless X ▪ no notion of multi-step exchanges of HTTP messages to complete a Web X “transaction” no need for client/server to track X’ “state” of multi-step exchange t’ all HTTP requests are independent of X’’ each other no need for client/server to “recover” X’’ from a partially-completed-but-never- time time completely-completed transaction Q: what happens if network connection or client crashes at t’ ? Application Layer: 2-34 Maintaining user/server state: cookies Web sites and client browser use Example: cookies to maintain some state ▪ Susan uses browser on laptop, visits specific e-commerce site between transactions for first time four components: ▪ when initial HTTP requests 1) cookie header line of HTTP response arrives at site, site creates: message unique ID (aka “cookie”) entry in backend database 2) cookie header line in next HTTP for ID request message subsequent HTTP requests 3) cookie file kept on user’s host, from Susan to this site will managed by user’s browser contain cookie ID value, 4) back-end database at Web site allowing site to “identify” Susan Application Layer: 2-35 Maintaining user/server state: cookies client server ebay 8734 usual HTTP request msg Amazon server cookie file creates ID usual HTTP response 1678 for user backend create ebay 8734 set-cookie: 1678 entry database amazon 1678 usual HTTP request msg cookie: 1678 cookie- access specific usual HTTP response msg action one week later: access ebay 8734 usual HTTP request msg amazon 1678 cookie: 1678 cookie- specific usual HTTP response msg action time time Application Layer: 2-36 HTTP cookies: comments aside What cookies can be used for: cookies and privacy: ▪ authorization ▪ cookies permit sites to ▪ shopping carts learn a lot about you on their site. ▪ recommendations ▪ third party persistent ▪ user session state (Web e-mail) cookies (tracking cookies) allow common identity (cookie value) to be Challenge: How to keep state? tracked across multiple ▪ at protocol endpoints: maintain state at web sites sender/receiver over multiple transactions ▪ in messages: cookies in HTTP messages carry state Application Layer: 2-37 Cookies: tracking a user’s browsing behavior Cookies can be used to: ▪ track user behavior on a given website (first party cookies) ▪ track user behavior across multiple websites (third party cookies) without user ever choosing to visit tracker site (!) ▪ tracking may be invisible to user: rather than displayed ad triggering HTTP GET to tracker, could be an invisible link third party tracking via cookies: ▪ disabled by default in Firefox, Safari browsers ▪ disabled in Chrome browser in 2023  GDPR (EU General Data Protection Regulation) and cookies “Natural persons may be associated with online identifiers […] such as internet protocol addresses, cookie identifiers or other identifiers […]. This may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them.” GDPR, recital 30 (May 2018) User has explicit control over when cookies can identify an individual, cookies whether or not cookies are are considered personal data, subject to GDPR allowed personal data regulations Web caches Goal: satisfy client requests without involving origin server ▪ user configures browser to point to a (local) Web cache Web cache ▪ browser sends all HTTP client origin server requests to cache if object in cache: cache returns object to client else cache requests object client from origin server, caches received object, then returns object to client Application Layer: 2-40 Web caches (aka proxy servers) ▪ Web cache acts as both Why Web caching? client and server ▪ reduce response time for client server for original requesting client request client to origin server cache is closer to client ▪ reduce traffic on an institution’s ▪ server tells cache about object’s allowable caching in access link response header: ▪ Internet is dense with caches enables “poor” content providers to more effectively deliver content Application Layer: 2-41 Caching example Scenario: ▪ access link rate: 1.54 Mbps origin ▪ RTT from institutional router to server: 2 sec servers ▪ web object size: 100K bits public Internet ▪ average request rate from browsers to origin servers: 15/sec ▪ avg data rate to browsers: 1.50 Mbps 1.54 Mbps access link Performance: ▪ access link utilization =.97 problem: large queueing delays institutional network ▪ LAN utilization:.0015 at high utilization! 1 Gbps LAN ▪ end-end delay = Internet delay + access link delay + LAN delay = 2 sec + minutes + usecs Application Layer: 2-42 Option 1: buy a faster access link Scenario: 154 Mbps ▪ access link rate: 1.54 Mbps origin ▪ RTT from institutional router to server: 2 sec servers ▪ web object size: 100K bits public Internet ▪ average request rate from browsers to origin servers: 15/sec ▪ avg data rate to browsers: 1.50 Mbps 154 Mbps 1.54 Mbps access link Performance: ▪ access link utilization =.97.0097 institutional network ▪ LAN utilization:.0015 1 Gbps LAN ▪ end-end delay = Internet delay + access link delay + LAN delay = 2 sec + minutes + usecs Cost: faster access link (expensive!) msecs Application Layer: 2-43 Option 2: install a web cache Scenario: ▪ access link rate: 1.54 Mbps origin ▪ RTT from institutional router to server: 2 sec servers ▪ web object size: 100K bits public Internet ▪ average request rate from browsers to origin servers: 15/sec ▪ avg data rate to browsers: 1.50 Mbps 1.54 Mbps access link Cost: web cache (cheap!) institutional network Performance: 1 Gbps LAN ▪ LAN utilization:.? How to compute link ▪ access link utilization = ? utilization, delay? ▪ average end-end delay = ? local web cache Application Layer: 2-44 Browser caching: Conditional GET client server Goal: don’t send object if browser HTTP request msg has up-to-date cached version If-modified-since: object no object transmission delay (or use not modified of network resources) HTTP response before HTTP/1.0 ▪ client: specify date of browser- 304 Not Modified cached copy in HTTP request If-modified-since: ▪ server: response contains no HTTP request msg If-modified-since: object object if browser-cached copy is modified up-to-date: HTTP response after HTTP/1.0 200 OK HTTP/1.0 304 Not Modified Application Layer: 2-45 HTTP/2 Key goal: decreased delay in multi-object HTTP requests HTTP1.1: introduced multiple, pipelined GETs over single TCP connection ▪ server responds in-order (FCFS: first-come-first-served scheduling) to GET requests ▪ with FCFS, small object may have to wait for transmission (head-of- line (HOL) blocking) behind large object(s) ▪ loss recovery (retransmitting lost TCP segments) stalls object transmission Application Layer: 2-46 HTTP/2 Key goal: decreased delay in multi-object HTTP requests HTTP/2: [RFC 7540, 2015] increased flexibility at server in sending objects to client: ▪ methods, status codes, most header fields unchanged from HTTP 1.1 ▪ transmission order of requested objects based on client-specified object priority (not necessarily FCFS) ▪ push unrequested objects to client ▪ divide objects into frames, schedule frames to mitigate HOL blocking Application Layer: 2-47 HTTP/2: mitigating HOL blocking HTTP 1.1: client requests 1 large object (e.g., video file) and 3 smaller objects server GET O4 GET O3 GET O 2 GET O1 object data requested client O1 O2 O1 O3 O2 O3 O4 O4 objects delivered in order requested: O2, O3, O4 wait behind O1 Application Layer: 2-48 HTTP/2: mitigating HOL blocking HTTP/2: objects divided into frames, frame transmission interleaved server GET O4 GET O3 GET O 2 GET O1 object data requested client O2 O4 O3 O1 O2 O3 O1 O4 O2, O3, O4 delivered quickly, O1 slightly delayed Application Layer: 2-49 HTTP/2 to HTTP/3 HTTP/2 over single TCP connection means: ▪ recovery from packet loss still stalls all object transmissions as in HTTP 1.1, browsers have incentive to open multiple parallel TCP connections to reduce stalling, increase overall throughput ▪ no security over vanilla TCP connection ▪ HTTP/3: adds security, per object error- and congestion- control (more pipelining) over UDP more on HTTP/3 in transport layer Application Layer: 2-50