1. Lecture 3: Application Layer1 מבוא לרשתות תקשורת : The Web and HTTP (chapter 2 – application) פרופ ' אמיר הרצברג Computer Networking: A Top Down Approach Featuring the Internet, 3 rd edition. Jim Kurose, Keith Ross Addison-Wesley, July 2005. Based on foils by Kurose & Ross ©, see: http://www.aw.com/kurose-ross/ http://www.aw.com/kurose-ross/ Site: http://AmirHerzberg.com

2. Lecture 3: Application Layer2 Web and HTTP : outline r HTTP Overview r HTTP Requests/responses r Connections: Persistent, pipeline r Authorization & cookies r Caching and proxies

3. Lecture 3: Application Layer3 Web and HTTP First some jargon r Web page consists of objects r Object can be HTML file, JPEG image, Java applet, audio file,… r Web page consists of base HTML-file which usually includes several referenced objects r Each object is addressable by a URL/URI m Universal Resource Locator / Identifier r Example URL: http://www.cs.biu.ac.il/~herzbea/index.html host name path name

4. Lecture 3: Application Layer4 HTTP overview HTTP: hypertext transfer protocol r Web’s application layer protocol r client/server model m client: browser that requests, receives, “displays” Web objects m server: Web server sends objects in response to requests r HTTP 1.0: RFC 1945 r HTTP 1.1: RFC 2068 Browser (e.g. IE) Web Server Browser (e.g. Mozilla) HTTP request HTTP response

5. Lecture 3: Application Layer5 HTTP overview (continued) Uses TCP: r client initiates TCP connection (creates socket) to server, port 80 r server accepts TCP connection from client r HTTP messages (application- layer protocol messages) exchanged between browser (HTTP client) and Web server (HTTP server) r TCP connection closed HTTP is “stateless” r server maintains no information about past client requests r TCP has state, but only within connection Protocols that maintain “state” are complex! r past history (state) must be maintained r if server/client crashes, their views of “state” may be inconsistent, must be reconciled aside

6. Lecture 3: Application Layer6 HTTP requests r two types of HTTP messages: request, response r HTTP request message: m ASCII (human-readable format): easier to debug E.g. experiment using telnet to web server GET /somedir/page.html HTTP/1.1 Host: www.someschool.edu User-agent: Mozilla/4.0 Connection: close Accept-language: fr (extra carriage return, line feed) Optional body (e.g. uploaded file) request line (GET, POST, HEAD commands) header lines Carriage return, line feed indicates end of message / header

7. Lecture 3: Application Layer7 HTTP request message: general format

8. Lecture 3: Application Layer8 Uploading web form input Using Post method: r Input is uploaded to server in request body Using Get method: r Input is uploaded in URL field of request line: www.site.com/search?monkeys&banana

9. Lecture 3: Application Layer9 HTTP response message HTTP/1.1 200 OK Connection: close Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 …... Content-Length: 6821 Content-Type: text/html data data data data data... status line (protocol status code status phrase) header lines data, e.g., requested HTML file

10. Lecture 3: Application Layer10 HTTP response status codes 200 OK m request succeeded, requested object later in this message 301 Moved Permanently m requested object moved, new location specified later in this message (Location:) 400 Bad Request m request message not understood by server 404 Not Found m requested document not found on this server 505 HTTP Version Not Supported In first line in server->client response message. A few sample codes:

11. Lecture 3: Application Layer11 Web and HTTP : outline r HTTP Overview r HTTP Requests/responses r Connections: Persistent, pipeline r Authorization & cookies r Caching and proxies

12. Lecture 3: Application Layer12 HTTP connections Non-persistent connections r At most one object is sent over a TCP connection. Persistent Connections r Multiple objects can be sent over single TCP connection.

13. Lecture 3: Application Layer13 Non-persistent Connections URL: www.someSchool.edu/someDepartment/home.index 1a. HTTP client initiates TCP connection to Web server at www.someSchool.edu on port 80 2. HTTP client sends HTTP request message (containing URL) via socket, for object someDepartment/home.index 1b. HTTP server “accepts” connection, notifies client 2b. HTTP server receives request, sends response message containing HTML object time 3. Client receives, displays object 4. Parsing html file, client finds referenced objects (e.g..gif); repeat steps 1-3 for each

14. Lecture 3: Application Layer14 Non-Persistent Connection: Response time modeling RTT (Round Trip Time): time to send packet from client to server and back. Response time: r one RTT to initiate TCP connection r one RTT for request and (MSS-|HTTPheader|) bytes of response r file transmission time total = 2RTT+transmit time time to transmit file initiate TCP connection RTT request file RTT file received time

15. Lecture 3: Application Layer15 Non-Persistent Connection: Modeling Slow Start Total time: r 2RTTs for first segment r RTT for next two… m Assume fixed RTT r After i*RTT, i>0: m Send 2 i-1 sgments m Assuming below threshold m Sent: 1+…+ 2 i-1 =2 i -1 sgments r File size: F bytes  Done: F ≤ ( 2 i -1)*MSS m Ignoring HTTP headers m i=log 2 (F/MSS)+1 total time = RTT*(log 2 (F/MSS)+1) time to transmit file initiate TCP connection RTT request file RTT file received time

16. Lecture 3: Application Layer16 Nonpersistent HTTP issues r Requires 2 RTTs per tiny object r Or: RTT*(log 2 (F/MSS)+1) (for F bytes) r And: sequential… r Browsers often open parallel TCP connections to fetch referenced objects m But not too many  (why?), e.g. IE: (only) 2 per server r And… OS overhead for each TCP connection r But… Simple; only option in HTTP 1.0 Alternative: Persistent HTTP Connections r Same connection for multiple requests r Default in HTTP 1.1

17. Lecture 3: Application Layer17 HTTP 1.1: Persistent Connections r Client sends multiple requests on same connection r Server sends responses in FIFO (on connection) r Default in HTTP 1.1  Use Content-Length: header to identify end of req.  Use Connection: close for last request / response Persistent without pipelining: r Issue new request when previous response received Persistent with pipelining (default) r Send requests concurrently (don’t wait for response)

18. Lecture 3: Application Layer18 Persistent Connections: Pipelining Persistent without pipelining: r Issue new request when previous response received r (at least) one RTT for each referenced object r Saves: setup/teardown, slow-start Persistent with pipelining: r Client sends requests as soon as it encounters a referenced object r Server sends responses in FIFO (on connection) m May send `connection: close’ at any time r Default in HTTP/1.1 r Only 2*RTT for many (tiny) objects

19. Lecture 3: Application Layer19 Persistent Connections: Performance m n   objects, each F>>MSS bytes m Fixed RTT; Max (flow control) window of w bytes, w>>F Non-Persistent: n*RTT*(log 2 (F/MSS)+1) >> n*RTT Persistent without pipelining: r Slow start, Rapid Accelerate (RA) till |window|=min{F,w}=F m RA*RTT time, where F<=MSS*2 RA-1 m RA=log 2 (F/MSS)+1; total sent at RA=MSS*(2 RA -1)=2F-1 r Rest (n-2)*F+1 at rate F/RTT r Total Time=RA*RTT+[(n-2)*F+1]/(F/RTT)= =(n-2)*RTT+RTT*[log 2 (F/MSS)+1+(1/F)]  n*RTT Persistent with pipelining: r Slow start, Rapid Accelerate (RA): till window fixed at w m RA*RTT time, where w<=MSS*2 RA-1 m RA=log 2 (w/MSS)+1; total sent at RA=MSS*(2 RA -1)=2w-1 r Rest (n*F-(2w-1)) at rate w/RTT r Total Time=RA*RTT+(n*F-2w+1)/(w/RTT)= =RTT*(RA-2+(n*F+1)/w)  RTT*[(n*F/w-1)+log 2 (w/MSS)]  RTT*n*F/w << n*RTT

20. Lecture 3: Application Layer20 Web and HTTP : outline r HTTP Overview r Connections: Persistent, pipeline r Requests/responses r Authorization & cookies r Caching and proxies

21. Lecture 3: Application Layer21 User-server interaction: authorization Authorization : control access to server content r Authorization methods: basic (password), digest, other r stateless: client presents authorization in each request  authorization: header line in each request  if no authorization : header, server refuses access, sends WWW authenticate: header line in response r Similar to cookies… (next) client server usual http request msg 401: authorization req. WWW authenticate: usual http request msg + Authorization: usual http response msgusual http request msg + Authorization: usual http response msg time

22. Lecture 3: Application Layer22 Cookies: client-side state Four components: 1) cookie header in HTTP response 2) cookie header in HTTP request 3) cookie file kept by browser 4) back-end database at Web site Example: m Susan access Internet always from same PC m She visits a specific e- commerce site for first time m When initial HTTP request arrives at site, site response contains cookie with unique ID m Cookie attached by browser to future requests from site – identifying Suzan

23. Lecture 3: Application Layer23 Cookies: keeping “state” (cont.) client Server (Amazon) usual http request msg usual http response + Set-cookie: 1678 usual http request msg cookie: 1678 usual http response msg usual http request msg cookie: 1678 usual http response msg cookie- specific action cookie- specific action server creates ID 1678 for user entry in backend database access Cookie file amazon: 1678 ebay: 8734 Cookie file ebay: 8734 Cookie file amazon: 1678 ebay: 8734 one week later:

24. Lecture 3: Application Layer24 Cookies (continued) What cookies can bring: r authorization r shopping carts r recommendations r customization r user session state (Web e-mail) Cookies, privacy & security: r cookies permit sites to learn a lot about you r And possibly to share info across sites r Also: cookies-based authorization is tricky r Cookies security: m Same domain only m SSL only, HTTP only,… r More: security courses aside

25. Lecture 3: Application Layer25 Web and HTTP : outline r HTTP Overview r HTTP Requests/responses r Connections: Persistent, pipeline r Authorization & cookies r Caching and proxies

26. Lecture 3: Application Layer26 Conditional GET: client-side caching r Goal: don’t send object if client has up-to-date cached version r client: specify date of cached copy in HTTP request If-modified-since: (copied from Last-Modified) r server: response contains no object if cached copy is up- to-date: HTTP/1.0 304 Not Modified client server HTTP request msg If-modified-since: HTTP response HTTP/1.0 304 Not Modified object not modified HTTP request msg If-modified-since: HTTP response HTTP/1.1 200 OK Date: Fri, 31 Dec 2006 23:59:59 GMT object modified

27. Lecture 3: Application Layer27 Web caches: at Proxy server r Proxy defined to browser, e.g. by user r browser sends HTTP requests to proxy m Object in cache: proxy returns object m Else: proxy requests object from origin server, then returns object to client m Persistent connections Goal: satisfy client request without involving origin server client Proxy server client HTTP request HTTP response HTTP request HTTP response origin server origin server

28. Lecture 3: Application Layer28 More about Web caching r Proxy acts as both client and server  Cache can do up-to-date check using If-modified-since HTTP header r Typically cache is installed by ISP (university, company, residential ISP) r  fails for `dynamic pages` r  requires query per object r improvements via script in browser and/or proxy… m E.g. load only `Delta updates` to cached version r Requires configuring browser m Auto-configuration protocols m Avoid with `Reverse proxy` Why Web caching? r Reduce response time for client request. r Reduce traffic on an institution’s access link. r Reduce load on content provider, backbone r Same persistent connection (to proxy) for many clients! Example…

29. Lecture 3: Application Layer29 Caching example (1) Assumptions r average object size = 100,000 bits r avg. request rate from institution’s browser to origin serves = 15/sec r delay from institutional router to any origin server and back to router = 2 sec Consequences r utilization on LAN = 15% r utilization on access link = 100% r total delay = Internet delay + access delay + LAN delay = 2 sec + minutes + milliseconds origin servers public Internet institutional network 10 Mbps LAN 1.5 Mbps access link institutional cache

30. Lecture 3: Application Layer30 Caching example (2) Possible solution r increase bandwidth of access link to, say, 10 Mbps Consequences r utilization on LAN = 15% r utilization on access link = 15% r Total delay = Internet delay + access delay + LAN delay = 2 sec + msecs + msecs r often a costly upgrade origin servers public Internet institutional network 10 Mbps LAN 10 Mbps access link institutional cache

31. Lecture 3: Application Layer31 Caching example (3) Install cache r suppose hit rate is.4 Consequence r 40% requests will be satisfied almost immediately r 60% requests satisfied by origin server r utilization of access link reduced to 60%, resulting in negligible delays (say 10 msec) r total delay = Internet delay + access delay + LAN delay =.6*2 sec +.6*.01 secs + milliseconds < 1.3 secs origin servers public Internet institutional network 10 Mbps LAN 1.5 Mbps access link institutional cache

32. Lecture 3: Application Layer32 Chapter 2: Summary r application service requirements: m reliability, bandwidth, delay r client-server paradigm m Request/response m Stateless server (why, how) r Transport services m connection-oriented, reliable: TCP m unreliable, datagrams: UDP Our study of network apps now complete! r specific protocols: m HTTP m SMTP, POP, IMAP m DNS r socket programming r content distribution m Proxy/caches, CDNs m Peer to peer file sharing