1. 1 WWW Protocols Dr. Rocky K. C. Chang 6 November 2006

2. 2 WWW components  Three key components: Universal Resource Locators (URLs) Hypertext Markup Language (HTML) HyperText Transfer Protocol (HTTP)  Web clients, servers, proxies, and caches... ClientForward proxy Reverse proxy Origin server

3. 3 Hypertext transfer protocol (HTTP)  Global URL Rely on URLs to identify resources on the Web.  Request-response exchange There are two HTTP/1.0 message types: requests (from clients) and responses (from servers).  Statelessness No state is maintained by clients and servers across requests and responses.  Resource metadata Information related to a resource but is not part of the resource itself, e.g., length, content types.

4. 4 Stateless HTTP  HTTP is a stateless protocol. No state is maintained by clients and servers across requests ad responses. Each pair of request and response is treated as an independent message exchange.  Adding state to HTTP was perceived to hamper the scalability of the Web. Require a significant amount of information to be stored on the part of a server.

5. 5 Stateless HTTP  A Web server Do not know about the hypertext links between documents.  Followed by a browser Do not know about inline images.  They are links in the document that are delivered to the browser. Do not know what links may point to a document it serves.

6. 6 Stateless HTTP and cookies  A server may send a “cookie” to a client with its response, requesting that the client includes the cookie in subsequent requests. A cookie is a small amount of state, which is sent by a server and stored in a client’s machine. For server to keep track of the user within a session and across sessions, e.g., shopping cart.

7. 7 HTTP/1.0 requests  An HTTP/1.0 request: request-line (method request-URI HTTP- version) headers (0 or more) body (only for a POST request)  Main request types: GET, HEAD, and POST GET http://www.comp.polyu.edu.hk/~comp526/INPSI/T CP.pdf HTTP/1.0

8. 8 HTTP/1.0 responses  The format of an HTTP/1.0 response: status-line (HTTP-version response-code response-phrase) (e.g., HTTP/1.0 200 OK) headers (0 or more) body  Response classes: 100 (informational), 200 (successful), 300 (redirection), 400 (client error) to 500 (server error) Redirection: additional action is needed to complete the request, e.g., 304 Not Modified.

9. 9 Headers in HTTP/1.0  Headers can be added to provide more infor-mation about the requests, responses and body. General, request, response, and entity headers 16 in HTTP/1.0 and 52 in HTTP/1.1  General headers, e.g., Date: Tue 16 May 2000 11:29:32 GMT  Request headers, e.g., GET /foo.html HTTP/1.0 If-Modified-Since: Sun, 21 May 2000 07:00:25 GMT

10. 10 Headers in HTTP/1.0 The server simply returns a 304 Not Modified response if the object has not been modified since the specified date and time.  Response headers, e.g., Location: http://www.foo.com/abc.html Redirect the request to where the resource can be found.  Entity headers, e.g., Content-Type: image/gif Content-Encoding: x-gzip Content-Length: 125

11. 11 Headers in HTTP/1.0

12. 12 HTTP/1.1  New methods, headers, and response codes  Caching  Bandwidth optimization  Connection management  Message transmission  Extensibility  Content negotiation  Security, authentication, and integrity

13. 13 Connection management  HTTP uses TCP and port 80 for the server.  In HTTP/1.0, a TCP connection is open (by the client) to retrieve each object in a document. A container page and embedded objects. Upon responding to the request, the server closes the TCP connection. Some browsers, like Netscape, open up to a certain number of simultaneous TCP connections (4 for Netscape).

14. 14 Nonpersistent connections GET /home.html HTTP/1.0 TCP FIN : : client server TCP SYN : HTTP/1.0 200 OK

15. 15 Keep-Alive option in HTTP/1.0  Motivation for opening multiple, parallel HTTP connections: Reduce the overall latency for downloading a document. A Web object is typically small in size.  Some HTTP/1.0 implementations use a Keep-Alive header to request (sent by a client) that a TCP connection persists. GET /home.html HTTP/1.0... Connection: Keep-Alive

16. 16 Keep-Alive option in HTTP/1.0  The server may send a response back to the client. HTTP/1.0 200 OK... Connection: Keep-Alive...  If an HTTP/1.0 server was transferring dynamic content, the client detects the end of the response from server’s TCP FIN. The content-header is usually not used due to the additional delay to compute the length.

17. 17 Persistent connections in HTTP/1.1  The down side of using parallel connections: Introduce a lot of TCP setup and teardown packets in the network. Overload the server when each client opens several parallel connections to the server. Abort several connections after aborting the download.  HTTP/1.1 makes persistent connections the default. Reuse the existing TCP connection. Request pipelining.

18. 18 Persistent connections in HTTP/1.1 GET /home.html HTTP/1.0 HTTP/1.0 200 OK : client server GET /foo1.jpg HTTP/1.0 : GET /foo2.jpg HTTP/1.0 HTTP/1.0 200 OK

19. 19 Persistent connections in HTTP/1.1  Head of the line problem Pipelined or not, requests sent over a persistent connection are served in the order they are received. A “large” object delays servicing the subsequent requests. To reduce the head of the line blocking, HTTP/1.1 allows clients to open up to two parallel connections to a server.  Closing persistent connections HTTP is not responsible for the “when” question.

20. 20 HTTP/TCP interaction  TCP SYN retransmissions Losing one or more SYN or SYN-ACK packets has a significant influence on Web performance. Stop and Reload: abort the current TCP connection and restarts a new one. The stop-and-reload action typically reduces user-perceived latency in the expense of higher load on the server.

21. 21 Retransmissions and HTTP  Data retransmissions Web responses involve a relatively small amount of data, in the range of 8 to 12 KB. Mostly stay in the slow-start phase. Unlikely generate enough duplicate ACKS for fast retransmission and fast recovery.  Slow-start restart Persistent connections help TCP get out of the slow-start phase. After a connection is idle for a while, a response message may generate a burst of packets.

22. 22 Slow-start restart in HTTP Allowing the previously idle connection to transmit at its old rate could introduce substantial congestion.  As a result, a TCP sender may be required to repeat the slow-start phase after a period of inactivity. The beginning of the idle period, e.g., use the RTO. resetting of the congestion window, e.g., 1 MSS.  Other approaches: gradually decrease of the congestion window, and rate-based pacing.

23. 23 TIME_WAIT state and HTTP  TCP requires one of the two end hosts to retain the connection states for a period of 2xMSL (4 minutes).  For HTTP, the server is more likely ending up in the TIME_WAIT state. HTTP/1.0 servers always terminate TCP connections immediately after sending responses. In the case HTTP/1.1, the server often has more incentives to close the connection using an application-level timer.

24. 24 TIME_WAIT state and HTTP  Reducing TIME_WAIT overhead: Reduce the memory requirement necessary for the OS to retransmit the final ACK and to hold on to the socket address.  Move the TIME_WAIT state to the client side: Change TCP: how to do this? Change HTTP: introducing a new request header to request clients to close the connections?  In practice, the TIME_WAIT timeout is reduced (e.g., 5 seconds).

25. 25 Aborted HTTP transfers  A user may abort an ongoing Web transfer by clicking the Stop/Reload button or by retrieving another page.  HTTP does not provide a way for the client to communicate its desire to terminate the ongoing transfer. HTTP/1.1 could have included an abort request method. Complicate the handling of pipelined requests. E.g., abort the transfer of a 20-MB file after 5-MB have arrived.

26. 26 Aborted HTTP transfers Two choices: receiving the 15 MB of unnecessary data or terminating the TCP connection.  Aborting the TCP connection by sending a FIN or RST segment to the server. The FIN segment triggers an EOF to the server application.  Stop writing data to the send buffer, but continue to transmit the data in the send buffer. The RST segment discards any data in the send buffer.  Disconnect immediately but cannot recover lost packets.

27. 27 Nagle Algo., delayed ACK, and HTTP  It has been observed that for a persistent HTTP connection, a temporary deadlock occurs whenever a response message requires an odd number of full-sized TCP segments, plus an additional partial segment.  The sender does not send the partial segment if the Nagle algorithm is on.  The receiver side does not ack. the last full- size segment and the partial segment due to the delayed acknowledgment.

28. 28 Nagle Algo., delayed ACK, and HTTP  In the case of nonpersistent connections, after writing the last segment (partial segment), the sender closes the application. The connection closing indicates that there are no more data sent from the application. Therefore, TCP sends out the partial segment immediately, regardless of whether the previous ACKs have been received.  Disabling Nagle’s algorithm? Prevent applications from writing data in small increments, e.g., separate calls to write each line of HTTP response header.

29. 29

30. 30

31. 31 Nagle Algo., delayed ACK, and HTTP  Delayed ACKs reduce the number of packets by piggybacking ACKS on the outgoing data segments, and sending an ACK for every other full-sized segments.  Except for the pipelining of requests, piggy- backing of ACKs is very unlikely for Web traffic.  Even when Nagle algorithm is disabled, sending a number of small segments may not be enough to trigger an immediate ACK.

32. 32 Initial window size and delayed ACK  A straightforward implementation of delayed ACK can cause unnecessary delay during the initial data transfer.  Every time slow start begins, the congestion window is set to 1 or 2 MSS. If the window size is 1 MSS, the receiver is unable to acknowledge immediately. Thus, an RTT plus 200 ms is required to ACK the first full-sized segment. A solution is to ACK every segment at the initial start of a TCP connection.

33. 33

34. 34

35. 35 Summary  The HTTP traffic has made up more than 75% of the Internet traffic today.  The HTTP is a very simple application protocol based on URLs, request- response, statelessness, and meta-data.  HTTP/1.1 offers significant improvement over HTTP/1.0.  Particular focus here is on the persistent connection feature and the interaction between HTTP and TCP.

36. 36 Acknowledgments  The slides are prepared mainly based on B. Krishnamurthy and J. Rexford, Web Protocols and Practice, Addison Wesley, 2001.  Slides pp. 29-30, 33-34 are taken from Eric Chan, Improving the Performance HTTP Persistent Connections, MSc dissertation, The Hong Kong Polytechnic U., Dec. 2001.