the case for persistent-connection http telecommunication system lab 최 명길 western research...

The Case for Persistent-Connection HTTPThe Case for Persistent-Connection HTTP

Telecommunication System LAB

최 명길

Western Research Laboratory Research Report 95/4

(Proceedings of the SIGCOMM ’95 Conference on Communication Architectures and Protocols)

2

ContentsContents

1. Introduction

2. Overviews of the HTTP Protocol

3. Analysis of HTTP’s inefficiencies

4. Proposed HTTP modifications

5. Design issues

6. Competing and complementary approaches

7. Simulation experiment design

8. Simulation results

9. Related work

10. Future work

11. Summary and conclusion

3

CritiqueCritique Strong Points

As the way of decreasing web latency, protocol level method proposed Analysis of existing HTTP protocol, alternative protocol is suggested To prove the usefulness of the P-HTTP protocol suggested, the

simulation is experimented in term of variable respects

Weak Points The paper does not clearly present the way of using P-HTTP protocol

with existing HTTP protocol together The P-HTTP protocol proposed In this paper does not clearly prove the

usefulness in real web client-server environment in terms of functionality

The paper does not experimental data concerning P-HTTP protocol compared with the existing approach adopted in Netscape

Suggestions Make a brower program to support HTTP and P-HTTP protocol

simultaneously and distribute it through Internet Before spreading it, the brower supporting HTTP, P-HTTP in

private network

4

Introduction and HTTP OverviewIntroduction and HTTP Overview

Web Latency Network Communication Propagation Delay

The Solution of Web Latency Minimize the number of network round-trip Modifying HTTP protocol Network Communication

HTPP Request GET, PUT, POST, URL, HERQ header, Optimal Data field

Server Response Status Code Object Header Data Field

5

Analysis of HTTP’s inefficiencies Analysis of HTTP’s inefficiencies

The Present HTTP Round trips

6

Other inefficiencies Other inefficiencies

Other inefficiencies Connection setup requires additional costs to network

latencies (new port, resource, data structure) Processing overhead at server and clients TCP Spec per connection require for certain time

7

Proposed HTTP ModificationsProposed HTTP Modifications

One TCP connection for multiple request Persistent-connection time HTTP Method : Server mark the end of a response

8

Protocol NegotiationProtocol Negotiation

Protocol negotiation • Current HTTP client, server -> P-HTTP protocol

(infeasible)

• PHTTP client, server : HTTP client, server (unpractical)

• P-HTTP server, HTTP client (proposed)

9

Design IssueDesign Issue

Effects on Reliability Server close connection arbitrarily impair reliability Race between client request and server termination Non-idempotent operation such as form to order

products Interactions with current proxy servers

• Client (P-HTTP) – Proxy(HTTP) – Server (P-HTTP) Server expects TCP open Proxy does not know P-HTTP, so server close connection Proxy waits forever

• Solution : Adaptive time scheme Server lists IP address Client use P-HTTP Server give a second for first request, and increase time for

subsequent request P-HTTP client realize that a HTTP only proxy is in use Client do not attempt to use P-HTTP

10

Design IssueDesign Issue

Connection lifetime The server has too many open connections in P-HTTP Server close an idle connection at any rate

Server consumes resource CPU time, active connection, protocol control block(PCB)

table space : the influence of persistent connection model to resource utilization

• The maximum number of open connection as parameter P-HTTP serve close idle connection as needed

• The number of PCB table entries has two components Open connections number (ESTABLISHED, CLOSING) Closed connections number (TIME_WAIT connection)

11

Design IssueDesign Issue

Server congestion control HTTP client never know the status of server P-HTTP protocol control the request arrival time

Network Resource P-HTTP reduce the number of overheads packets and

reduce the bandwidth load Improve the congestion behavior of the network by

giving the state of network In P-HTTP, requests and replies could be streamed at

full network bandwidth User’s Perceived Performance

The time required to retrieve and display web page User prefer response times below two to four seconds User likes to know a high mean retrieved time and low

variance

12

Competing and complementary approaches Competing and complementary approaches Simulation DesignSimulation Design

Netscape open multiple connections in parallel Eliminate unnecessary latency without requiring a new

protocol Drawbacks of Network Resource

Increase the chances for network congestion Do not know the state of the network

Simulation Experiment Design The behavior of P-HTTP server using log of actual HTTP

The specific question to address by simulation The sufficient locality of reference in clients Reduction of server resource utilization The adaptive timeout mechanism destroy the ability of

the proposal

13

Trace Data SetTrace Data Set

Data set 1994, CAL. election servers (1.6M HTTP requests in a 10 day) Large Corp. Public web site (3.4M, HTTP requests in a 82 day) Election Service has three servers, load sharing (intensive, very few

days, 24,000 clients) Corp. server has low peak load (low peak load, 134,000 clients)

Different Access Pattern [fig 4] : the cumulative distribution of retrieval size [fig 5] : the retrieval time

14

15

Simulator OverviewSimulator Overview P- HTTP Server behavior

Open Connection, Server’s PCB table TIME_WAIT entries, Adaptive timeout database

The connection(session layer) behavior The simulator process order

Parse the log file, connection open, connection close Sorts the event records in time-sequence order Go through the event record in time stamp order 1) Already connection open event – update statistic counters

2) Connection create or connection close (above max) 3) Connection close Longer Idle connection remove Adaptive timeout mechanism

16

Summary of Simulation ParameterSummary of Simulation Parameter

P-HTTP mode

Maximum number of open connections

Idle-timeout

2*MSL timeout

Adaptive-timeout table size

Initial idle-timeout

17

ValidationValidation

Election Server HTTP Protocol simulation PCB Table 15 minute 2*MSL timeout : 60 sec TIME_WAIT overestimate Underestimate the number of ESTABLISHED connection Many connections longer than log record The logged connection fail to round trip Network

18

19

Simulation ResultsSimulation Results

Connection Refusal Rates The number of connections refused in terms of idle-time out and max connection limit Support at least 32 simultaneous connections

20

Connection Re-use RateConnection Re-use Rate

The frequency P-HHTP protocol pay off in term of reduced latency The number of times a request arrives for an already-

open connection P-HTTP optimal hit rate for election service

21

22

Connection Re-use RateConnection Re-use Rate

Complement of the number of open connection hit The success rate of the persistent connection approach by

number of HTTP request per TCP connection

Not hard to satisfy ten or more HTTP request with one TCP connection

23

Connection Re-use RateConnection Re-use Rate

Cmax, Standard Deviation different according to Cmax

24

The Effect of a Web IndexerThe Effect of a Web Indexer

One client responsible for most HTTP retrieval in Corp. Serve

Filter out Indexer

25

26

Success Rate views by clientsSuccess Rate views by clients

What fraction of the Clients hosts saw a high rate

TCP connection limited to a small subset of the client hosts

clients distributed among a wide set of clients

Individual client send 20 HTTP request over a single TCP connection

27

Success Rate views by clientsSuccess Rate views by clients

The distribution of the P-HTTP depend on the server parameter

28

Frequency of forced closes Frequency of forced closes P-HTTP server close an idle TCP connection

Make a room for a request from a different client The connection longer idle than idle timeout parameter The Election service run Cmax and close idle connection

29

Frequency of forced closesFrequency of forced closes

Many connection persist for many seconds

30

PCB table usePCB table use

The simulator counts ESTABLISED and TIME_WAIT entries Few PCM table entries (good open connection hit rate) TIME-WAIT entries does not depend on idle timeout parameter Most of TIME_WAIT entries by forced closes

31

PCB table usePCB table use

32

Adaptive timeoutAdaptive timeout

The result for P-HTTP server without adaptive timeout

33

Adaptive timeoutAdaptive timeout

Overlap with the curve for the adaptive timeout case

34

Network Loading, Related Work, Future WorkNetwork Loading, Related Work, Future Work

Network Loading• Difficult to predict P-HTTP affect the network load• P-HTTP improve the dynamics of the Internet• Possible to estimate congestion avoided by P-HHTP

Related Work• Locality of reference in the context of intermediary caching• Feasibility or performance of intermediary caching server

Future Work• By assumption, the simulator could generator a modified event trace

reflecting these short times• Using some semantic information, simulate the actual response times

seen by users• The simulator could be modified to provide periodic statistics

35

Summary and ConclusionSummary and Conclusion

Summary and Conclusion• P-HTTP reduce the response time, server overheads and network

overheads of HTTP• Maximum number of active connections increase user’s perceived

performance• The feasibility of P-HTTP depends on the availability of robust client and

server implementation and the conversions of proxies