Electrical computers and digital processing systems: multicomput – Computer network managing – Computer network access regulating
Reexamination Certificate
2000-10-13
2004-11-02
Vu, Viet D. (Department: 2154)
Electrical computers and digital processing systems: multicomput
Computer network managing
Computer network access regulating
C709S219000, C709S226000, C709S227000
Reexamination Certificate
active
06813635
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates generally to World Wide Web servers and, more particularly, to techniques for distributing load among World Wide Web servers.
2. Related Art
Current World Wide Web servers (“web servers”) are accessed by client computers using the Hypertext Transfer Protocol (HTTP) or its encrypted form (HTTPS). A typical interaction between the client computer and a web server consists of several HTTP and/or HTTPS requests. For example, when a user of the client computer first accesses a web site, an HTTP connection request is sent to a web server maintaining the web site. The HTTP request contains a Uniform Resource Identifier (URI) which specifies the web page being requested. The web server, in turn, responds to the HTTP request by downloading the requested web page (e.g., a Hypertext Markup Language (HTML) file) to the client computer. The HTML file is then interpreted by a web browser executed by the client computer and displayed to the user. If the user selects a hyperlink on the web page, a new HTTP/HTTPS request is sent to the web server, which may result in a new web page being downloaded to the client computer.
In addition, the Domain Name System (DNS) protocol is used to translate user-friendly server computer names (e.g., hp.com) into Internet Protocol (IP) addresses (e.g., 191.24.0.2). When the user of a client computer first selects a hyperlink for a web server whose IP address is not already known by the client computer, the client computer uses DNS to obtain the IP address for the web server from a DNS server. Subsequently, the client computer is then able to initiate the HTTP/HTTPS transaction with the web server. DNS servers typically maintain tables mapping names to IP addresses. Included with this mapping is a Time To Live (TTL) value, representing the number of seconds for which a client computer may confidently retain the IP address for a given name once the IP address has been returned through DNS. When a DNS server contains a mapping for a given name, the DNS server is said to be “authoritative” for that name.
In some cases, DNS servers are arranged in a hierarchical fashion (i.e., one DNS server may transfer a DNS name resolution request for a specific name to another DNS server). In these cases, such DNS servers typically do not only contain authoritative mappings, but also temporary, non-authoritative mappings obtained previously via recursion into the DNS hierarchy. These non-authoritative mappings are only retained by the DNS server for such time as permitted by the TTL values.
Since the HTTP/HTTPS protocols are inherently stateless (namely, an HTTP/HTTPS request intrinsically contains no information about the outcome of a prior request), a web server communicating with a client computer cannot rely on these protocols for maintaining state (i.e., storing information about the stage of processing of the client computer's overall interaction with the server). The series of discrete HTTP/HTTPS transactions over which state is maintained is typically referred to as a “session.” As the amount of state data to be maintained increases, or sensitive information is included among it, techniques for exchanging the state data explicitly across HTTP/HTTPS become unsuitable and the state data must be maintained locally on the web server or some other computer (e.g., a database server) to which the web server has direct access. Instead of transferring a large amount of sensitive state data, a small token uniquely referencing the state data is exchanged by the client and server across HTTP/HTTPS, while the state data itself is kept on the server. This general architecture is referred to as “server-resident state,” and the reference token as a “session ID.” Server computers in this architecture are thus referred to as “stateful.”
Server-resident state is typically not a problem when client computers interact with a single server computer. Due to the number of requests received by server computers, however, typically a pool of server computers is used rather than a single server computer. These stateful server computers are referred to as “redundant” in that they are all capable of being used to initiate a session with a client computer. In such a situation, the client computer would ordinarily connect to different server computers in the pool on successive connection requests during a session. This would require sharing the state information for each client among all servers in the pool. This is feasible when the repository for the server-resident state is a shared database or similar resource, or when state data is replicated across multiple repositories. But when the redundant, stateful server computers are remotely located from one another, or the state data is large, or performance considerations outweigh their use, such techniques for sharing server-resident state amongst all of the servers become impractical. That is, in some of these cases, it is impractical for any of the servers in the pool to share state. In other cases, some of the servers in the pool may share state amongst themselves, but not with the others. In any case, each unit of one (or more) redundant, stateful server computers sharing state amongst themselves, but not with other such units in the pool, is referred to as a “site.” Furthermore, the redundant, stateful server computer sites are referred to as “independent” because state data is not being shared among them.
Thus, for a pool of multiple stateful web server sites which are redundant of one another, yet which maintain state independently of one another, the problem arises of distributing sessions across the pool when they are initiated, while maintaining affinity between a particular client computer and server computer site for the duration of a session. The problem is compounded when provision for failure of a server computer site must be made.
A device such as a web proxy may be used to ensure that each client computer always connects to the same redundant, independent, stateful server computer site during a session. Such a system is illustrated by
FIGS. 1A-1B
. In
FIG. 1A
, a client computer
110
is connected to a pool of server computer sites
120
n
(where n=A, B, . . . ) and a web proxy server
140
over a computer-network
130
. As illustrated in
FIG. 1B
, client computer
110
first sends an HTTP/HTTPS connection request to web proxy server
140
. DNS server
150
translates the web proxy server name from the URI sent by client computer
110
into a corresponding IP address for web proxy server
140
(IPP). Web proxy server
140
, in turn, selects one of server computer sites
120
n
and sends the connection request along to the selected server computer site
120
n
. The selected server computer site
120
n
initiates a new session and responds by downloading the requested web page, including the new session ID, to client computer
110
. Web proxy server
140
, in turn, maintains a table mapping each client computer
110
's session ID to the selected server computer site
120
n
. As a result, when a new connection request is received from client computer
110
, web proxy server
140
is able to forward the request to the selected server computer site
120
n
using an IP address for a server computer site (e.g., IPA or IPB).
This approach, however, presents several limitations. First, since every connection request is sent to web proxy server
140
, web proxy server
140
progressively becomes a performance bottleneck as the number of server computer sites
120
n
in the pool increases. Similarly, web proxy server
140
creates a single-point of failure for communications directed to the entire pool of server computer sites
120
n.
Finally, session state must be synchronized between web proxy server
140
and the selected server computer site
120
n
. That is, the web proxy server
140
must recognize when the session of the client computer
110
with the server pool first begins, so that a mapping to the selected server computer site
1
LandOfFree
System and method for distributing load among redundant... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for distributing load among redundant..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for distributing load among redundant... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3361129