Application Protocols and HTTP 14-740: Fundamentals of Computer Networks Bill Nace Material from Computer Networking: A Top Down Approach, 6 th edition. J.F. Kurose and K.W. Ross
Administrivia • Lab #0 due in a week • Next time: Paper Review of Mockapetris88 • Quiz #1 approaches (29 Sep, 2 weeks away) • Designed for ~45 minutes • Multiple choice / Short answer questions • Covers everything up until 25 Sep lecture • Layered architecture, Design Principles, ISPs & Peering, Web & HTTP , DNS, P2P , Queuing Theory • Note: TAs hold o ffi ce hours ➙ go talk to them 2
Last Lecture • ISPs, Backbones, Peering • Motivations to peer • Tier-1 • Tier-2 • Content / Enterprise Companies • Interconnections • Private vs Public Peering 3
traceroute • Application Layer • Web and HTTP • Message format • Persistent connections • Caching 4
In the app layer DNS HTTP SMTP VOIP (queries) • Abstract transport TCP UDP • Use transport services: TCP or UDP or ... • Think about transport as a channel for data from client to server and back • TCP requires setup and teardown • UDP has no such requirement 5
Setup Overhead • Client initiates transport Client Server connection to server initiate transport • API: Creates socket connection accept connection • Server accepts connection request file • Application-layer protocol send file messages exchanged between browser and web server file received; • Transport connection closed close connection closed 6
Operations • Mission (i.e. fundamental reason it exists) • Addressing • Network data type 7
traceroute • Application Layer • Web and HTTP • Message format • Persistent connections • Caching 8
HTTP Overview • HTTP: hypertext transfer protocol HTTP Request HTTP Response PC running IE • Web’s application layer protocol • Client / server model HTTP Request HTTP Response • client: browser that requests, Linux running Apache (web server) receives, renders web objects • server: stores objects, sends in Mac running Safari response to requests • Many implementations in various operating systems communicate using HTTP 9
History Lesson • HTTP 0.9, circa 1990 • Original release, first described in W3 mailing list • “HTTP as implemented in WWW”, by Tim Berners-Lee http://lists.w3.org/Archives/Public/www-talk/1992JanFeb/0000.html • HTTP 1.0, started 1993 • RFCs for HTML and URI published the same year • Informational RFC-1945, 1996 • Not a standards document, merely common usages • A number of problems • Caching control • TCP overhead for short responses 10
History (2) • HTTP/1.1 • Backward compatibility big issue • RFC 2068, proposed standard, 1997 • RFC 2616, draft standard, 1999 • Some web server products claimed compliance to HTTP 1.1 even before it became standard! • RFC 2616 had to be “backward compatible” with 2068 • Pressures from vendors, technologist, etc • This lecture focuses on HTTP/1.1 11
History (3) • HTTP/2 approved May 2015 (RFC 7540) • Somewhat slow adoption rate • Changes how data is transferred • Avoid head-of-line blocking • Compress headers • Allow server push • Violates layered architecture principles 12
traceroute • Application Layer • Web and HTTP • Message format • Persistent connections • Caching 13
HTTP Message • 2 types of messages • Requests from client to server, and • Responses from server to client • RFCs use Backus-Naur Form (BNF) to formally specify formats (RFC 5234) HTTP-message = Request | Response or 14
Request / Response • Both request and response consist of: • Start line, followed by ... • Zero or more headers, followed by ... • An empty line, followed by ... • Message body (optional) generic-message = start-line *( message-header CRLF ) Zero or more times CRLF optional [ message-body ] start-line = Request-line | status-line 15
Request Format Request = Request-Line *(( general-header |request-header |entity-header ) CRLF) CRLF [ message-body ] Zero or more of general, request or entity headers followed by CRLF, followed by an optional message body
What are those headers? • Headers provide metadata about the request or response • Dates/times • Application or Server information • Caching control • 46 defined headers • Host: is required on requests 17
Request Format (2) Request-Line = Method SP Request-URI SP HTTP-Version CRLF Method = “OPTIONS” | “GET” | “HEAD” | “POST” | “PUT” | “DELETE” • You get the idea .... 18
Example: Request • Note: ASCII (human-readable format) Request-line (GET, POST, ... commands) GET /images/logos.html HTTP/1.1 Host: www.cmu.edu message-header (x4) User-agent: mozilla/5.0... Connection: close Accept-language: en-US ¶ CRLF: Carriage return, line feed ¶ (extra carriage return, line feed) 2nd CRLF indicates no message-body, thus end of message 19
Request Methods • GET: Retrieve an object • “Conditional GET” if header includes If- Modified-Since, If-Match, etc • “Partial GET” if header includes a Range field • Essential for restartable transfers such as scrubbing and bu ff ering a media stream 20
Request Methods • HEAD: Retrieve metadata about an object (validity, modification time, etc) • Same as GET but MUST NOT return a message body 21
Request Methods • OPTIONS: Request info about the capabilities of server (or a resource) without requesting the resource • POST: Upload data to server • E.g. posting a message to mailing list, submitting a form, etc 22
Example: Response Recall: start-line = Request-line | status-line Defined as: status-line = HTTP-version SP Status-Code SP Reason-Phrase CRLF Status code HTTP/1.1 200 OK Connection close Date: Wed, 01 Sep 2018 12:16:15 GMT Server: Apache/1.3.0 (Unix) Header lines Last-Modified: Mon, 22 Jun 2016 ... Content-Length: 6821 Content-Type: text/html data data data data data ... data, e.g. requested HTML file
Status Code • In first line of response from server to client • 3-digit integer result code • 1xx: Informational – Request received, continuing process • 2xx: Success – Action successful • 3xx: Redirection – Further action needed to complete request • 4xx: Client Error – Request has bad syntax or cannot be fulfilled • 5xx: Server Error – Server failed to fulfill a valid request 24
Sample Status Codes • 200 OK • request succeeded, requested object included in this message • 301 Moved Permanently • requested object moved, new location specified later in this message (Location:) • 404 Not Found • requested document not found on this server • 505 HTTP Version Not Supported 25
Google.com/index.html • HTML file (index.html) describes layout, links, scripts, etc • Includes a reference to the logo image file (logo.gif)
Question • Does the following request retrieve the logo file as well? GET /index.html HTTP/1.1 <CR> Host: www.google.com <CR> <CR> 27
HTTP Request • Each HTTP Request retrieves a single object per message • An object (e.g. HTML file) can contain links to other objects (e.g. images, HTML files) • Client must send separate request to retrieve each additional object 28
traceroute • Application Layer • Web and HTTP • Message format • Persistent connections • Caching 29
Connection Management • HTTP uses TCP as its transport protocol • TCP not optimized for short-lived connections typical of HTTP message exchange • Often simple pages, which result in short messages 30
Nonpersistent HTTP Suppose user wants cmu.edu/index.html 1. Client initiates TCP connection to cmu.edu on 2. Web server at cmu.edu port 80 waiting for connection on port 80 “accepts” 3. Client sends HTTP connection, responds to request message sender (containing URL /index.html) into 4. Server receives request connection socket message, fetches object, formats response message, sends message into connection
Nonpersistent HTTP (2) 5. Server closes connection 6. HTTP client receives response message. Parses HTML file, discovering 10 referenced image files 7. Repeat steps 1-5 for each of 10 image objects
Response time modeling • Round Trip Time (RTT): time to send a Client Server small packet from client to server and back initiate transport • Calculation for HTTP response time connection RTT accept • One RTT to initiate TCP connection connection request • One RTT for HTTP request and first file RTT byte of response send file • file transmission time Transmit Time file • response time = 2RTT + transmit time received; close connection closed
Problems • A separate transport connection is established to fetch each object • Requires at least 2 RTTs per object • High overhead in terms of packets in the network • Long user-perceived latency 34
Problems (2) • Transport protocol (TCP) is optimized for large data transfers. Pays extra startup time to avoid congestion (slow-start, windowing, etc) • HTTP request for small objects never gets past initial phase • Connection closed before window size can be increased significantly • Available bandwidth never fully used • Details in Transport lecture 35
Recommend
More recommend
