WWW's Client/Server Architecture

The basic WWW architecture, shown in the figure, below, is based on the client/server model of distributed systems. In the model, a client process makes a request to a server process, normally running on a different machine and using a network such as the Internet for communication. The server process receives the request, establishes a connection with the client, performs the desired function, returns the result to the client, and breaks the connection. The server is then available to receive requests from other clients and perform similar services for them. In some implementations, the server may create a copy of itself (called forking) immediately upon receiving the request; the child process then establishes the connection with the client and performs the desired service while the parent process goes back to listening for other request. This design enables a single server to provide services for a number of clients at the same time.

In the architecture of the WWW, the client is normally a Web browser, such as Netscape or Internet Explorer. The Server may be any of a variety of servers. The common element among them is that they all support a high-level set of conventions - a protocol - called HTTP (HyperText Transfer Protocol). HTTP messages are embedded as the data portion of TCP segments which, in turn, are embedded in IP datagrams, which in term are embedded in Ethernet frames. The whole thing is like a set of nested Russian dolls.

HTTP messages normally include a header, which contains a verb such as GET, and a body which contains additional data. Thus, a frequent interaction between a browser and a WWW server is to request a particular document or "page" of information. After parsing the request, the server fetches the requested data from its local file system, constructs a HTTP message, places the file contents in the body portion of the message, and returns the entire package to the client, once again using TCP, IP, and, most like, Ethernet.

In some cases, the request sent to a server will not be to fetch an existing file but to execute some program, such as a database access program, to generate the desired results. In this case, the WWW server uses a special interface, called the CGI (Common Gateway Interface), to run the desired program. That program is then responsible for constructing the HTTP message that includes the data requested by the user, which it passes back to the server for delivery to the client.

The mechanics of establishing the connection between Web browser and HTTP server are outlined below.

---

Communication between WWW browsers and servers

• Perspective
  • Goal is to establish the connection labeled HTTP in the figure, above
  • Discussion cast in the context of TCP/IP and WWW
  • TCP connection terminates in endpoints, defined by IP address and protocol port number; endpoints commonly accessed through sockets supported by operating system
  • Web architecture based on client/server model; that model commonly uses sockets
  • Will discuss sockets, ports, and client/server model as used in basic web architecture
• Port concept
  • Addresses supported by the operating system
  • well-known addresses are static and (usually) <256 (e.g., 80 for WWW, 21 for FTP, 25 for SMTP)
  • dynamic addresses are temporary, assigned by the os, and have higher values
  • Applications commonly use higher level abstraction of sockets, with respect to which port is part of an address (along with IP address), through which to transfer data
• Socket Concept
  • Provide application-level endpoints, supported by the os, for connections through which data can be transferred from one computer/process to another
  • Permit transfer of data between hosts analogous to transfer of data between application and file
    • read/write(file_name)
    • read/write(socket_name)
    • effect is to transfer stream of bytes (other forms of transfer supported, but will not be discussed)
• Creating a socket
  • produces a name that is an integer
  • socket_name = socket(protocol_family, type, protocol)
    • protocol_family: PF_INET
    • type: SOCK_STREAM
    • protocol: 0 (subprotocol)
• Associating a socket with a local address
  • bind (socket, local_addr, addrlen)
    • socket: socket_name
    • local_addr
      • address family: e.g., PF_INET
      • protocol port: e.g., 80
      • IP address
  • commonly used by server to associate socket with well-known port
• Connecting a socket to another machine (socket)
  • connect (socket_name, dest_addr, addrlen)
    • socket_name on local machine
    • dest_addr address structure for socket on destination machine
• Data transfer
  • Once socket connection established, can use read/write verbs to transfer data
    • read/write (socket_name, buffer, length)
  • In client/server model, read/write often done after several additional socket operations, described below
• Setting buffer length for transfer
  • listen (socket_name, qlength)
• Creating a new socket as a result of receiving a message on another socket (e.g., through well-known port)
  • new_socket = accept (socket_name, null_addr, addrlen)
    • socket_name: socket awaiting message
    • null_addr: address structure, to be filled in by os, that will store address of client
  • accept often placed in main processing loop
  • accept blocks until message received
• Creating a new server process to handle client messages
  • fork
  • produces a child process that is a duplicate of the original, parent process
  • often placed in an IF or CASE statement
    • fork returns "1" to parent, "0" to child
    • "1" option continues
    • "0" option calls procedure or otherwise branches to place where child can process messages
• Preparing to receive next message
  • Parent process closes new_socket while child is processing messages from client
    • close (new_socket)
    Returns to accept state
• Putting it all together: Summary of basic interaction for web client/server
  • Startup and processing for server
    • s = socket ( )
    • bind (s, local_addr, addrlen) where local_addr is server IP and port 80.
    • listen (s, qlength)
    • main server control loop
      • new_s = accept (s, null_addr, addrlen)
      • If fork then continue in loop, else call child subprocedure to process client messages (e.g., read/write(new_s))
      • close (new_s)
  • Connect and processing for client
    • t = socket ( )
    • build serv_addr structure
    • connect (t, serv_addr, addrlen)
    • read/write (t)