CS 3214 Introduction to Computer Systems Lecture 25 Godmar Back
Announcements Read Chapter 12 “Networking” Project 5 due Dec 11 Exercise 13 (Virtualization) Handed out later today, due Dec 11 Grading Status Exercises 1-10 are graded Minimum requirement criteria Projects 1-2 are graded You have pre-indication on project 3 Can verify minimum requirements for projects 4 and 5 yourselves CS 3214 Fall 2009 5/20/2018
Some of these slides are substantially derived from slides provided by Jim Kurose & Keith Ross. Copyright on this material is held by Kurose & Ross. Used with permission. The textbook is Computer Networking: A Top Down Approach Featuring the Internet Jim Kurose, Keith Ross, Addison-Wesley, July 2004 Part 2 Networking CS 3214 Fall 2009 5/20/2018
Application Protocols Part 1: HTTP
Recall how the Web works Web page consists of objects Object can be HTML file, JPEG image, Java applet, audio file,… Web page consists of base HTML-file which includes several referenced objects Each object is addressable by a URL Example URL: www.someschool.edu/someDept/pic.gif host name path name CS 3214 Fall 2009 5/20/2018
HTTP Overview HTTP: hypertext transfer protocol Web’s application layer protocol client/server model client: browser that requests, receives, “displays” Web objects server: Web server sends objects in response to requests HTTP 1.0: RFC 1945 HTTP 1.1: RFC 2068 HTTP request PC running Explorer HTTP response HTTP request Server running Apache Web server HTTP response Mac running Firefox CS 3214 Fall 2009 5/20/2018
HTTP Overview (continued) Uses TCP: 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 Web server (HTTP server) TCP connection closed HTTP is “stateless” server maintains no information about past client requests aside Protocols that maintain “state” are complex! past history (state) must be maintained if server/client crashes, their views of “state” may be inconsistent, must be reconciled CS 3214 Fall 2009 5/20/2018
Nonpersistent HTTP time (contains text, references to n images) http://courses.cs.vt.edu/~cs3214/index.html 1a. HTTP client initiates TCP connection to HTTP server (process) at www.cs.vt.edu on port 80 1b. HTTP server at host www.cs.vt.edu waiting for TCP connection at port 80. “accepts” connection, notifying client 2. HTTP client sends HTTP request message (containing URL) into TCP connection socket. Message indicates that client wants object /~cs3214/index.html 3. HTTP server receives request message, forms response message containing requested object, and sends message into its socket time CS 3214 Fall 2009 5/20/2018
Nonpersistent HTTP (cont.) 4. HTTP server closes TCP connection. 5. HTTP client receives response message containing html file, displays html. Parsing html file, finds n referenced image objects time 6. Steps 1-5 repeated for each of 10 image objects CS 3214 Fall 2009 5/20/2018
Response time modeling Round Trip Time (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 time to transmit file initiate TCP connection RTT request received time CS 3214 Fall 2009 5/20/2018
Persistent Connections initiate TCP connection Idea: reuse same connection to retrieve multiple objects Saves repeated connection establishment & teardown total = RTT+ N * (RTT + transmit time) RTT request file time to transmit file RTT File 1 received RTT File 2 received RTT File 3 received time time CS 3214 Fall 2009 5/20/2018
Pipelining initiate TCP connection Idea: send next request before response for previous request arrives Server should receive next request even before last response is sent total = 3*RTT+ N * transmit time RTT request file time to transmit file RTT File 1 received RTT File 2 received File 3 received time time CS 3214 Fall 2009 5/20/2018
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 CS 3214 Fall 2009 5/20/2018
HTTP Request Message two types of HTTP messages: request, response ASCII (human-readable format) Needed because multiple sites may be hosted on same host request line (GET, POST, HEAD commands) GET /~cs3214/index.html HTTP/1.1 Host: www.cs.vt.edu User-agent: Lynx/2.8.4rel.1 Connection: close Accept-language: en, fr (extra carriage return, line feed) header lines Only if non-persistent Carriage return, line feed CS 3214 Fall 2009 5/20/2018
HTTP Request Msg: general format CS 3214 Fall 2009 5/20/2018
Grammar Formulation HTTP-message = Request | Response Request = rfc822-generic-message Response = rfc822- generic-message rfc822- generic-message = start-line *(message-header CRLF) CRLF [ message-body ] start-line = Request-Line | Status-Line message-header = field-name ":" [ field-value ] Request-Line = Method SP Request-URI SP HTTP-Version CRLF CS 3214 Fall 2009 5/20/2018
Method types HTTP/1.0 GET POST HEAD HTTP/1.1 GET, POST, HEAD PUT asks server to leave requested object out of response HTTP/1.1 GET, POST, HEAD PUT uploads file in entity body to path specified in URL field DELETE deletes file specified in the URL field CS 3214 Fall 2009 5/20/2018
Uploading Form Input GET method: POST method: Uses GET method <form action=“/form” method=“get” …> <input name=“username” type=“text”> …. Uses GET method Input is uploaded in URL field Needs RFC 2396 encoding, e.g. “ “ %20 POST method: <form action=“/form” method=“post” …> <input name=“username” type=“text”> …. Input is uploaded to server in entity body POST /form HTTP/1.1 Host: www.cs.vt.edu Content-Length: 12 <CRLF> username=Joe&… GET /form?username=Joe&… HTTP/1.1 Host: www.cs.vt.edu <CRLF> CS 3214 Fall 2009 5/20/2018
HTTP Response Message status line (protocol status code status phrase) Only if non-persistent 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 ... header lines data, e.g., requested HTML file CS 3214 Fall 2009 5/20/2018
HTTP Response 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 CS 3214 Fall 2009 5/20/2018
Trying out HTTP (client side) for yourself 1. Telnet to your favorite Web server: telnet www.vt.edu 80 Opens TCP connection to port 80 (default HTTP server port) at www.vt.edu. Anything typed is sent to port 80 at www.vt.edu 2. Type in a GET HTTP request: By typing this in (hit carriage return twice), you send this minimal (but complete) GET request to HTTP server GET / HTTP/1.1 Host: www.vt.edu 3. Look at response message sent by HTTP server! CS 3214 Fall 2009 5/20/2018
Historical Note First version by Tim Berners-Lee Aka HTTP/0.9 % telnet www.vt.edu 80 Trying 198.82.160.129... Connected to www.vt.edu. Escape character is '^]'. GET / ← I typed this + single CRLF <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title>Virginia Tech -- Home Page</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> …. CS 3214 Fall 2009 5/20/2018
User-server state: cookies 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 accesses 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 CS 3214 Fall 2009 5/20/2018
Cookies: keeping “state” (cont.) client server usual http request msg usual http response + Set-cookie: 1678 cookie: 1678 usual http response msg cookie- specific action spectific Cookie file ebay: 8734 server creates ID 1678 for user entry in backend database Cookie file amazon: 1678 ebay: 8734 access one week later: access Cookie file amazon: 1678 ebay: 8734 CS 3214 Fall 2009 5/20/2018
Mashups Web applications that combine and mix data from different sources CS 3214 Fall 2009 5/20/2018
Base Server http://www.lib.edu Source A http://www.lib.edu/sourceA Mash-Up Server http://mashup.lib.edu Source B http://opac.lib.edu/sourceB HTML Source C http://any.host.domain/sourceC Client Browser Base Page A C B Server-side Mash-Up CS 3214 Fall 2009 5/20/2018
Base Server http://www.lib.edu Source A http://www.lib.edu/sourceA HTML+JavaScript Proxy http://www.lib.edu/proxy Source B http://opac.lib.edu/sourceB XMLHttpRequest Source C http://any.host.domain/sourceC Client Browser Base Page A C B Proxy-Based Mash-Up CS 3214 Fall 2009 5/20/2018
Base Server http://www.lib.edu Source B http://opac.lib.edu/sourceB HTML+JavaScript Same Origin Restriction Same Domain Restriction Source A http://www.lib.edu/sourceA XMLHttpRequest + XML/Text XMLHttpRequest + XML/Text No Domain Restriction Client Browser Base Page Source C http://any.host.domain/sourceC A B C B (via hidden frame) <SCRIPT> + JSON Client-side Mash-Up CS 3214 Fall 2009 5/20/2018
HTTP & JSON In modern web applications, HTTP is increasingly initiated from code Either directly, e.g., XMLHttpRequest Or indirectly, via SCRIPT/JSON Example: http://books.google.com/books?jscmd=viewapi&bibkeys=0060731338&callback=callThisFunction callThisFunction({"0060731338":{"bib_key":"0060731338", "info_url": "http://books.google.com/books?id=HCInGwAACAAJ\x26source=gbs_ViewAPI", "preview_url": "http://books.google.com/books?id=HCInGwAACAAJ\x26source=gbs_ViewAPI",“ preview":"noview", "embeddable":false}}); CS 3214 Fall 2009 5/20/2018
HTTP & AJAX AJAX Frameworks no longer build entire web pages from an HTML description Rather: bootstrap small amount of code, then dynamically load and update page “piece-by-piece” CS 3214 Fall 2009 5/20/2018
Goal – Use of AJAX Page 1 Page 2 Page 3 Conventional Navigation Model Submit button pressed Submit button pressed Page 1 Servlet1 Servlet1-1 Update portion of page HTML Page returned Page 2 Submit button pressed Mouse Hover Servlet 2 Servlet 1-2 Page 3 HTML Page returned Update Portion of Page Popularity of ajax over recent years because of advtgs AJAX is the technology responsible for the Web 2.0 hype. Many companies have started using AJAX for their projects because of the notable advantages that it offers in terms of user-interaction Our first goal was to implement the Edition Builder as a web application because Web-applications can be accessed by any user with a computer and an Internet connection. Moreover , web applications can be updated and maintained without installation of software on the client side. Hence, deployment of changes and updates can be done transparently from the user and in an expedited fashion. Problems in conventional navigation model Disruptive page refreshes after each user-interaction Confusing because of hyper-links and page layout AJAX Asynchronous JavaScript and XML Incremental update of pages (No page refreshes) Higher levels of interactivity and responsiveness Explain Working of AJAX An AJAX application has an intermediate layer between the user and the server called the AJAX engine. Each user interaction results in a call to the AJAX engine. The AJAX engine decides, whether a call requires action from the server. If the AJAX engine itself can service a call, it does so without resorting to communication with the server. In this way, unnecessary http requests to the server are avoided and user-interaction can proceed smoothly with other components that do not require server-processing at that moment. Thus, due to the interposition of the AJAX engine, a user interacts with the application without interruptions Conventional Navigation Model AJAX Navigation Model CS 3214 Fall 2009 5/20/2018
Server centric vs. Client centric AJAX frameworks Browser Browser Generated HTML+ JavaScript Client Side AJAX Engine Application HTML+ JavaScript Client Side AJAX Engine Dom Dom Server Side AJAX Engine Web Application Web Application Scraps of sample code that you find on the Web and that you can cut and paste into your own application, to comprehensive frameworks. Just above the level of code scraps are individual JavaScript components that present an API for a specific purpose. Some of these represent UI widgets that will appear on a Web page, like the Dojo Button, and others are for solving lower-level, plumbing-related issues like communicating with the server or manipulating the browser DOM (for example the Prototype APIs). Fundamental choices Give examples of toolkits that follow either model Explain dom If you look at the diagrams in Figure 2 below, you can see that in the server-centric model, the application programmer develops the entire application in what appears to the programmer to be server-side code. Of course, DHTML and JavaScript are involved when the application runs, but the framework does not expose these to the programmer. The framework provides both a server-side and client-side Ajax engine. The server-side engine generates HTML and JavaScript that is served into the browser along with a client-side engine, which provides APIs used by the generated code to manipulate the browser DOM, receive events, and push them back to the server-side engine, which communicates events back to the application. A client-side framework, on the other hand, expects the application programmer to write both the server side of the application and the part that will run in the browser. The client-side code is served into the browser along with the Ajax engine, which performs the same intercession functions between the DOM and the application code that it does in the server-centric model An advantage of client side frameworks is that developers can leverage JavaScript skills to combine features from various frameworks and create a complex application. But, client side frameworks entail significant amount of JavaScript programming, which can still give rise to unmaintainable JavaScript code. Moreover, with client-centric AJAX frameworks, the programmer needs to take the responsibility of sending client state to the server periodically. If the client fails to send state information to the server then the server may not be able to retain consistency of the application based on the client-state. Server Server Server-Centric Client-Centric Framework code Application Code Generated Code CS 3214 Fall 2009 5/20/2018
Architectures and Protocol on top of HTTP REST: Representational State Transfer URL represent resources SOAP: Remote-procedure call abstraction CS 3214 Fall 2009 5/20/2018