Client-server Basics. 1. Motivation

Transcription

1 Page 1 of 8 Client-server Basics Oxford Brookes University 2004 Contents 1. Motivation 2. Basic Model of the Web 3. Extensions - Caching and Proxies 4. High Performance Web Servers 5. Web Services Appendices A. References 1. Motivation Resource naming, sharing and allocation are fundamental issues in computer science. In the earliest days computers were single processor entities and there was no communication between computers. A computer would run a single user-job to completion, then the next would be loaded and run. This was perceived to be inefficient usage of a scarce resource which led to the development of time sharing, multi-tasking operating systems which could share the single processor resource amongst multiple jobs loaded onto the computer. Sending a job to another computer involved sending a physical deck of cards, paper tape or magnetic tape and the results would be returned in similar manner usually as physical printer output. One of the early motivations for computer networks was to eliminate the need for physical media and enable a direct communication path between computers. In the 1960s host-satellite systems started to emerge. Graphical displays are a good example. The processing power needed to drive the display was considerable and to drive a display from the same processor that was running the application took too much resource away from the application. Thus architectures emerged in which the graphics display was driven by a separate processor, the satellite processor, linked in some way to the main processor, the host; an early example of distribution. As computers became more powerful and the demands for computing resources grew, distributed computing systems emerged. A distributed system can call upon a range of resources in order to carry out a computation, for example, multiple processors, filestores, peripherals etc. Two general models emerged, depending on how the resources were coupled. The two are known as tightly-coupled distributed systems and loosely-coupled distributed systems. Multiple processors communicating through shared memory is typical of the former class. A collection of workstations accessing resources such as printers and filestores is typical of the latter. Tightly-coupled systems occupy a limited geographical area (the same chip, or rack) in order to maximise interconnection speeds. Looselycoupled systems can operate over local or wide area networks. The client-server model is a particular kind of loosely-coupled distributed system. The basic idea of a client server system is that a client can send a request to a server to perform some task and receive a response. A time server is a simple example. The client requests the server for the current time, the server sends the current time to the client in the response. A print server is another example, the client sends a document to the server, the server prints it and sends a response to the client that this has been done. A file server is another. The client requests a file from the server, the server returns it. The basic request/response idea is illustrated in figure 1.1. below.

2 Page 2 of 8 Figure 1.1: Request/response Model Benefits of this approach include: Resource allocation: server can provide same kind of service to many clients Server can be optimised/specialised to provide particular kinds of service What price do we pay for this? Loosely-coupled systems introduce delays, not least due to the time taken to transmit requests and responses over a network. Delays may also occur if the server is heavily loaded because requests are arriving faster than the server can service them. Client-server systems can fail in different ways to, say, a local procedure invocation. Server might not be able to provide requested service, e.g. requested file might not exist (easy: send error response) When client sends request to server, server might not be operational Server might receive request from client, start to process it, then fail Client might fail whilst server is processing request Network might fail to deliver request or response correctly Network link might fail whilst request or response is being transmitted Client-server systems have to be able to handle such situations gracefully. Further issues arise when we study client-server systems more closely, for example: Protocols: request and response messages need to be transmitted correctly; client-server systems require data to be delivered reliably and in the correct order Naming/addressing: how are names and addresses of services allocated? The number of services is potentially very large Scalabiliy: how easy is it to extend a system to deal with increasing demand? Caching: what economies are possible if the same client asks for the same thing repeatedly, or different clients ask for the same thing? Security: transmission of request and response, denial-of-service attacks (bombard a service with "false" requests, thus denying service to genuine clients) Authentication: who is allowed to use a service? If a request is from a client that is allowed to

3 Page 3 of 8 use the service, how do you know that that client is who it claims to be? Control flow: can a server invoke other servers in computing the response to a request? Some of these issues will be explored in this module, and others in the Semester 2 modules in the course. These issues are instances of more general issues that arise in distributed systems. It is likely that you will have encountered these if you have studied a course on distributed systems. The key notion is transparency: concealment from user and application programmer of the separation of the system into components. The system is perceived as a whole rather than collection of individual components. There are different kinds of transparency (see Emmerich, 2000): Access Interface to service request is same for communication between components on same host and on different hosts Location Components can be identified in service requests without physical locations being known Migration Components can be migrated to another host without affecting operation of users or programs Replication Users and programmers not aware service is provided by replica of original component rather than master Concurrency Several components may concurrently request services from a shared component, while shared component s integrity is preserved, and neither users nor programmers have to see how concurrency is controlled Scalability Transparent to users and designers how system scales to accommodate growing load Performance Transparent to users how system performance is achieved Failure Concealment of faults from users, clients and server components We conclude this introduction by looking at how these ideas and issues apply to the Web. 2. Basic Model of the Web In order for the Web to work, there was a need for a way of requesting Web pages and having them delivered from a remote server to the browser. In December 1990 when the first web pages were served from a server in CERN, the decision had already been made to use a very simple protocol called HyperText Transfer Protocol (HTTP) running over the Internet using TCP/IP. Routing the pages through the network and uniquely addreessing the destination is done by the Internet Protocol (IP). Communication between the hosts is achieved by the Transmission Control Protocol (TCP). The HTTP architecture agreed is shown in Figure 1.2. Only the Client is allowed to make requests. It asks the server on the Internet at the site to deliver the page file.htm to the Client for browsing. The Server may be able to find the file (called a document or a page) and, if so, it will deliver it to the Client. If the file cannot be located, an error response is sent instead.

4 Page 4 of 8 Figure 2.1: Request/response Model of HTTP A simple example showing the format of the HTTP request and response messages is shown in Figures 2.2 and 2.3. The request message requests a particular resource, in this case the document The response message either returns the document or includes an error message. The structure of the request and response messages is explained in detail in the HTTP Primer. Figure 2.2: HTTP Request Message

5 Page 5 of 8 Figure 2.3: HTTP Response Message The protocols involved in HTTP message transfer are illustrated in Figure 2.4. More details are given in the HTTP Primer. Figure 2.4: Protocols used in HTTP Message Transfer 3. Extensions - Caching and Proxies As soon as the web started getting used, it became clear that this simple model was not that efficient. Suppose the user downloads a web page and then a second. If the user wants to refer back to the first page, then the model as it stands would require the page to be requested again. In consequence, almost

6 Page 6 of 8 from day one the possibility of having a cache of already downloaded web pages was seen as useful. When the user hits the back button on the browser, the page is retrieved from a local cache on the computer running the browser rather than request the page again. Browsers have over the years added other features such as History files and Bookmark lists which also can make use of a local cache. At the Server end, there is also a use for a cache. If the server has a large main memory, rather than retrieve each file from disc, it is able to keep the last set of pages requested in main memory in order to improve its response to users. Organisations soon began to find that their staff were using the Web a great deal. In some cases this was good news as they were accessing relevant information needed to do their job. Sometimes the staff were downloading information of a more private nature, organising their holidays, purchasing goods etc. This led to the introduction of a device called a proxy which to the Client looks like a Server and to a Server looks like a Client. Proxies have a wide range of uses. They can be used to control what pages the organisation's staff are allowed to access. If the proxy is placed on the firewall between the company's Intranet and the Internet, it is possible to check what documents are being requested. The organisation can set up the network so that all external requests go the proxy which onward routes the ones that the organisation is happy with and sends back an unavailable error message otherwise. Figure 3.1: Caching and Proxies Proxies also can contain caches. In this case, the cache serves a set of users rather than a single user. In an organisation, it is likely that a set of users will request similar pages due to the nature of their work, so a proxy cache also has value. User A requests a page that is stored in the proxy cache and when user B requests the same page, it is returned from the proxy rather than requesting it from the Server. Figure 3.1 shows the overall arrangement of a site with a proxy cache. If a proxy is of use to an organisation, it may also be of value to a Department, to an Internet service Provider, to a Community and even a country. For example, the UK has an academic cache aimed at reducing the traffic between the UK and the USA to lower the need for expensive bandwidth between the UK and the USA. Some countries have national caches to censor information that arrives in the country. Information cannot be left in a cache forever as eventually it will be out-of-date and the cache will fill up. The Server may have updated a Web page but all the caches are still returning the old version. With the potential of there being a whole series of caches between the user and the site from which a page is required, mechanisms are needed to handle stale pages in the various caches and to ensure that pages of the appropriate freshness are returned to the user. 4. High Performance Web Servers Web sites that receive thousands or millions of hits per day cannot be implemented as single server

7 Page 7 of 8 systems. One type of technique that can be employed is for requests to do to a front-end server that then distributes them to one of a set of back-end servers in such a way that the work is spread evenly across the back-end servers. The idea is illustrated in Figure 4.1. Figure 4.1: Workload Distribution Further consideration of this topic is outside the scope of this module. A very good survey article is Cardellini et al, Web Services The request from the client to the server may be more complex than a request for a pre-existing document. Some computation might be involved. One generalisation of this is the Common Gateway Interface (CGI), another is Java Servlets. These topics are considered later in the module. Another generalization is to Web Services. This topic will be covered in a later module in the course (P00773 Web Deployment). The basic idea of a Web Service is a software application: identified by a URI whose interfaces and bindings are capable of being defined, described and discovered by XML artifacts and which can support direct interactions with other software applications using XML-based messages via Internet-based protocols The general idea is illustrated in Figure 5.1.

8 Page 8 of 8 Figure 5.1: Web Services Architecture Appendix A References 1. Wolfgang Emmerich (2000), Engineering Distributed Objects, John Wiley & Sons, ISBN V. Cardellini, E. Casallicchio and P.S. Yu, The State of the Art in Locally Distributed Web-Server Systems, ACM Computing Surveys, 34(2), pp Available through ACM Digital Library.