200 likes | 333 Views
HTTP. Hypertext Transfer Protocol. http request. PC running Explorer. http response. http request. Server running NCSA Web server. http response. Mac running Navigator. Introduction. WWW’s application layer protocol Client/server model http1.0 : RFC 1945 http1.1 : RFC 2068
E N D
HTTP Hypertext Transfer Protocol
http request PC running Explorer http response http request Server running NCSA Web server http response Mac running Navigator Introduction • WWW’s application layer protocol • Client/server model • http1.0: RFC 1945 http1.1: RFC 2068 • http: TCP transport service: • Client initiates TCP connection (creates socket) to server, port 80 • Server accepts TCP connection from client • http messages (application-layer protocol messages) exchanged between browser (http client) and WWW server (http server) • TCP connection closed • http is “stateless” : Server maintains no information about past client requests
initiate TCP connection RTT request file time to transmit file RTT file received time time Response time modeling • Definition of RTT: time to send a small packet to travel from client to server and back. • Response time: • one RTT to initiate TCP connection • one RTT for HTTP request and first few bytes of HTTP response to return • file transmission time Total = 2RTT+transmit time
initiate TCP connection RTT GET index.html time to transmit index.hml RTT file received GET page1.jpg time to transmit page1.jpg Classical HTTP/1.0
Persistent HTTP Nonpersistent HTTP issues: • requires 2 RTTs per object • OS must work and allocate host resources for each TCP connection • but browsers often open parallel TCP connections to fetch referenced objects Persistent HTTP • server leaves connection open after sending response • subsequent HTTP messages between same client/server are sent over connection Persistent without pipelining: • client issues new request only when previous response has been received • one RTT for each referenced object Persistent with pipelining: • default in HTTP/1.1 • client sends requests as soon as it encounters a referenced object • as little as one RTT for all the referenced objects
http message format: request • two types of http messages: request, response • http request message: • ASCII (human-readable format) request line (GET, POST, HEAD commands) GET /somedir/page.html HTTP/1.1 Connection: close User-agent: Mozilla/4.0 Accept: text/html, image/gif,image/jpeg Accept-language:fr (extra carriage return, line feed) header lines Carriage return, line feed indicates end of message
http message format: reply status line (protocol status code status phrase) 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 datadatadatadata ... header lines data, e.g., requested html file
http reply status codes • In first line in server->client response message. • A few 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 (Location:) 400 Bad Request • request message not understood by server 404 Not Found • requested document not found on this server 505 HTTP Version Not Supported
usual http response msg time User-server interaction: authentication Client Server Authentication goal: control access to server documents • stateless: client must present authorization in each request • authorization: typically name, password • authorization: header line in request • if no authorization presented, server refuses access, sends WWW authenticate: header line in response usual http request msg 401: authorization req. WWW authenticate: usual http request msg + Authorization:line usual http response msg usual http request msg + Authorization:line
Cookies: keeping “state” Many major Web sites use cookies Four components: 1) cookie header line in the HTTP response message 2) cookie header line in HTTP request message 3) cookie file kept on user’s host and managed by user’s browser 4) back-end database at Web site Example: • Susan access Internet always from same PC • She visits a specific e-commerce site for first time • When initial HTTP requests arrives at site, site creates a unique ID and creates an entry in backend database for ID
usual http response msg User-server interaction: cookies Client Server • server sends “cookie” to client in response Set-cookie: # • client present cookie in later requests cookie: # • server matches presented-cookie with server-stored cookies • authentication • remembering user preferences, previous choices usual http request msg usual http response + Set-cookie: # usual http request msg cookie: # cookie- specific action usual http response msg usual http request msg cookie: # cookie- specific action
usual http response msg Example Client Server usual http request msg amazon: 1678 ebay: 8734 amazon: 1678 ebay: 8734 ebay: 8734 entry in backend database server creates ID 1678 for user usual http response + Set-cookie: 1678 usual http request msg cookie: 1678 cookie- specific action usual http response msg usual http request msg cookie: 1678 cookie- specific action
User-server interaction: conditional GET Client Server • Goal: don’t send object if client has up-to-date stored (cached) version • client: specify date of cached copy in http request If-modified-since: <date> • server: response contains no object if cached copy up-to-date: HTTP/1.0 304 Not Modified http request msg If-modified-since: <date> object not modified http response HTTP/1.0 304 Not Modified http request msg If-modified-since: <date> http response HTTP/1.1 200 OK … <data> object modified
Web Caches (proxy server) • Goal: satisfy client request without involving origin server • user sets browser: WWW accesses via web cache • client sends all http requests to web cache • if object at web cache, web cache immediately returns object in http response • else requests object from origin server, then returns http response to client origin server Proxy server http request http request client http response http response http request http request http response http response client origin server
Web Caching Hierarchy national/international proxy cache regional proxy cache local proxy cache (e.g., local ISP, University) client
Why Cache? • Reduce response time for client request. • Reduce traffic on an institution’s access link. • Internet dense with caches enables “poor” content providers to effectively deliver content Some Issues • All objects can’t be cached • E.g., dynamic objects • Cache consistency • strong • weak • Cache Replacement Policies • Variable size objects • Varying cost of not finding an object (a “miss”) in the cache • Prefetch? • A large fraction of the requests are one-times
Weak Consistency • Each cached copy has a TTL beyond which it must be validated with the origin server • TTL = freshness life time – age • freshness life time: often heuristically calculated; sometimes based on MAX_AGE or EXPIRES headers • age = current time (at client) – timestamp on object (time at which server generated response) • Age Penalty?
Why WWW Caching? origin servers Assume: cache is “close” to client (e.g., in same network) • smaller response time: cache “closer” to client • decrease traffic to distant servers • link out of institutional/local ISP network often bottleneck public Internet 1.5 Mbps access link institutional network 10 Mbps LAN institutional cache