5. To direct all requests from a particular client to the same server even if the connection is to
a different virtual cluster, check the
inter-cluster sticky
checkbox. You can turn on inter-cluster
stickiness only if you have enabled sticky connections by specifying a
sticky time
greater than
zero.
6. Click the
commit
button.
Enabling the Once Only and Persist Options
Since HTTP 1.0, web browsers and servers have been able to negotiate persistent connections
over which multiple HTTP transactions could take place. This is useful when several TCP
connections are required in order to satisfy a single client request.
For example, before HTTP 1.1, if a browser wished to retrieve the file
index.html
from the server
the browser would take the following actions:
Browser opens TCP connection to
2. Browser sends request to server
“GET /index.html”
.
3. Server responds with the content of the page (HTML).
4. Server closes connection.
5. Browser determines that there are objects (images) in the HTML document that need to be
retrieved, so the browser repeats Steps 1 to 4 for each of the objects.
There is a lot of overhead associated with opening and closing the TCP connections for each
image. The way HTTP 1.0 optimizes this is to allow multiple objects (pages, images, etc) to be
fetched and returned across one TCP socket connection. The client requests that the server keep
the connection open by adding the request header
Connection: keep-alive
to the request. If the server
agrees, the server will also include
Connection: keep-alive
in its response headers, and the client is
able to send the next request over the persistent HTTP connection without the bother of opening
additional connections.
For HTTP/1.1, persistent connections are the default.
For a Layer 7 cluster, Equalizer evaluates (and possibly changes) both the request and response
headers that flow between the client and server (the request and response bodies are not
examined). Match rules are applied to each client header, cookies may be inserted, and headers
may be rewritten. When a client includes
keep-alive
in its headers, there is a fair amount of work
required by the Equalizer to determine when the next set of request headers is ready to be parsed
(evaluated), since there may be quite a lot of data going across the connection between sets of
headers.
To reduce this workload, the
once only
flag instructs the Equalizer to evaluate (and potentially
modify) only the
first
set of headers in a connection. So, in our example above, only the headers
in the request for the
index.html
file are evaluated; the subsequent requests to obtain the images
are not load balanced, but sent to the same server as the first request.
Enabling
once only
can be incompatible with persistence and Layer 7 HTTPS clusters (which
rewrite HTTP to HTTPS links in server response headers), since in these cases we generally want
to examine every request in a connection. However, in configurations where examining the
headers in every transaction in a connection is not required, enabling
once only
can significantly
improve performance.
Copyright © 2014 Coyote Point Systems, A Subsidiary of Fortinet, Inc.
All Rights Reserved.
373
Equalizer Administration Guide
Summary of Contents for Equalizer GX Series
Page 18: ......
Page 32: ...Overview 32 Copyright 2014 Coyote Point Systems A Subsidiary of Fortinet Inc ...
Page 42: ......
Page 52: ......
Page 64: ......
Page 72: ......
Page 76: ......
Page 228: ......
Page 238: ......
Page 476: ......
Page 492: ......
Page 530: ......
Page 614: ......
Page 626: ......
Page 638: ......
Page 678: ......
Page 732: ...Using SNMP Traps 732 Copyright 2014 Coyote Point Systems A Subsidiary of Fortinet Inc ...
Page 754: ......
Page 790: ......
Page 804: ......
Page 842: ......
Page 866: ......